Zilong does not manufacture most Z80s; rather, they licensed the design to many other companies royalty-free. It is this license that lets TI manufacture calculator ASICs with an embedded Z80. Basically, TI paid a free for the Z80 design once more than a decade ago, and can now manufacture as many Z80-based graphing calculators as they want without having to pay anything more to Zilog. Also, the ASIC probably contains no other IP cores, so TI essentially manufactures ASICs for the literal silicon cost only. (And the LCD controller costs about a dollar a piece, and the flash chips are less than two dollars a piece, and the calculator contains no other digital ICs.)

It is a problem for me because if I want to add some ASM Code in an Axe Programm with the Asm() command, I don't really know where the ASM code is stored.

In that case, you may want to use an Axiom, since the Axe Axiom parser supports resolving jump references. (More information is in the SDK. The Axe Parser will parse the Axiom's bytestream so it can identify jumps and calls that need references resolved.) If you want to make Axioms on-calc, you can actually just use Mimas. It doesn't support the standard helper macro used for Axiom jump resolution, but there's an easy enough workaround you can use instead.

TI still has the option of upping to clock rate of the CPU to at least 20 MHz; supposedly, they experimented with clock speeds of up to 25 MHz on the TI-83+SE, which was, for the young folks, the beta version of the TI-84+/SE.

I also second the idea of it being based on the Nspire, with the OS user interface rewritten to look like the UI of the TI-83+ series so that it's more familiar to teachers, who are of course the people TI actually markets graphing calculators too.

The calculator does indeed use dynamic memory allocation for user data. And BASIC programs don't get moved before execution; the parser is able to parse BASIC programs from where ever they're located in memory. However, the Z80 CPU doesn't well-support doing that for assembly programs. In particular, the JP and CALL instructions have to know the exact location they're branching to before program execution begins. So the OS always copies assembly programs to the exact same location in RAM so that the assembler can always compute before hand the address to jump to.

In theory, you could have your program store a list of the locations of+ instructions in the program that need to be fiddled with before executing, but that's more complicated solution than anybody so far has been willing to deal with.

ERR:VERSION is definitely because the calculator thinks there's something in the file the TI-83+ won't like. The TI-84+ 2.22 OS also has tokens not present on the TI-83+, so there still could be something in the program you're not aware of that's causing the program.

The calculator keeps track of the supposed version in the VAT. I could throw together a program that resets the version field of all programs, so you can send them again. But probably not tonight, as I have homework and need to wake up early.

You could try putting the program(s) in a group variable, but if the TI-83+ accepts the group, it'll probably still throw an error upon extraction.

For the record, I got the list of hex codes by opening the .8xp file in the XVI32 hex editor. I looked for the tell-tale byte codes I know represent the untypeable tokens. The start 8xp program data is always somewhere between 0x40 and 0x50, and the last two bytes are always a checksum.

The idea is simple: You can now write an Axe app and an Axe program, and the program can call routines stored in the app. Since apps can be up to 16 K, and programs up to 24 K, you can now write combination Axe programs/apps with up to 40 K of combined code and data. (And if you need even more, there's still the files interface.)

Your way is definitely cleaner. I can imagine there being one reason for wanting to keep your extra code in a program---it lets users start the app, instead of the program. You're not far from writing a shell now.