With all those pixels, they couldn't have used a less ugly font?

That would require a massive rewrite of their math engine and variable handlers, and even the variable formats, basically anything that accesses user RAM.

They already did so once (the TI-86) and if it were done intelligently, it wouldn't need to be significantly slower.  Whether TI would be willing to go to the extra effort is another question.

Basically, if AsmPrgm:210080:36E1:23:36E5:23:36C9:CD0080:EF0745:C9 crashes instead of spitting out a number, we're screwed and won't be able to do anything until getting our hands on the hardware ourselves.

I think you underestimate this community.

I'm curious about the LCD.  Is it supposed to use a color palette or individually-controlled RGB pixels?  I'm a little skeptical that you could get good performance either way - and I'm even more skeptical that TI could pull it off (these are the same people who brought us MathPrint.)

But in the general case, determining what is a label and what is a constant is not something any automated disassembler can do.  (For one thing, determining all the possible code paths reduces to the halting problem.  For another thing, when you start getting into seriously optimized code, like some that I've written, the distinction between "constant" and "label" becomes somewhat fuzzy, as optimizations can imply constraints on your labels that can't even be expressed in standard assembly language.)  But for even a moderately complex assembly program, I wouldn't trust any automated disassembler to understand everything - it requires human eyes to figure out exactly what the program is doing.

That said, if you know the code is produced by a compiler that doesn't use any outlandish optimizations (and more to the point, if you know beforehand exactly what programming techniques that compiler uses) - then some heuristics able to recognize those techniques might be sufficient.  (Note that I'm assuming the programmer has used "pure" Axe, or Axe with a well-defined set of simple assembly libraries - in other words, that the programmer has not made any assumptions that depend on the implementation of the Axe compiler or the target machine.)  I don't know enough about Axe to say how hard it would really be, but I would be somewhat surprised if there were any existing disassembler able to do that in general.

OK, this is getting a bit off-topic; sorry.  In conclusion: disassembly is hard.

Runer112: cmdShadow is used for MirageOS internal storage.  If you overwrite that area, it will break both the MirageOS GUI and some of the MirageOS library routines.  The same is true of some parts of statVars, I don't remember which exactly.  And you can expect the same is true of other shells.

The other thing about cmdShadow is that it is used for Ion's program loader (and, of course, the Ion libraries) so you absolutely must not overwrite that area in an Ion program.

Also, thepenguin77, you didn't mention that appData can be overwritten when APD occurs.

'flags' (the usual value of IY) is 8567h.  As far as I know, it's true that all of the TI-83's flags are located at the same bit/offset on the 83+, but the converse is not true.  I can't easily check this at the moment, but I think that 23h (35 decimal, aka asm_Flag3) is the end of the system flags on the 83.  So you will want to be certain your program is not using any flags beyond that point; if the program is relying on those flags, then it may need to be substantially modified.  Two popular 83+ flags that the 83 doesn't support are bufferOnly (draw only to plotSScreen, not the LCD) and fracDrawLFont (use the large font for _VPutMap.)

As far as RAM areas go: first of all, what shell/loader are you using?  I highly recommend that you use Venus, if you're not doing so already.  If you are using Venus, then you can use cmdShadow (128 bytes at 9157h) for temporary storage.  You can also use textShadow if you take some precautions - clear the appTextSave flag while your program is running, and set it again and call _ClrWindow when your program exits.

If you are using Ion or another "traditional" 83 shell, then the rules are slightly different - you can use textShadow if you like, but absolutely not cmdShadow.

You can use statVars (858Fh, somewhere around 500 bytes but I don't remember exactly) for temporary storage, but if you're using Venus you will need to call _DelRes when your program exits (Ion does this for you, I think.)

If you are not already using saveSScreen, that would make a good alternative to appBackUpScreen.  But if you are already using saveSScreen and plotSScreen and you really need a third 768-byte buffer, you'll need to make one yourself.  The quick and easy way is just to stick an extra 768 bytes of zeroes into your program; the less greedy way would be to dynamically allocate it in free memory.  (Free memory starts at (FPS), (930Dh).  You can use _EnoughMem - see the 83+ SDK docs - to check whether there's enough memory available.)

Yup.  I guess it's time for me to hang up my hat.  Well, it's been fun.

squish.inc is the file you want; it was included, I believe, with TI's SQUISH/ZASMLOAD package.  You can probably find it somewhere on the web.  That file contains names for all of the TI-83 ROM calls.

There's no _BufClr on the TI-83.  There's no _SaveDisp either, but maybe you can get around that by using _SaveOScreen (which copies the LCD into saveSScreen.)

kbdGetKy = kbdScanCode + 6.  It holds the scan code most recently pressed, and is called that because it's used to implement the BASIC getKey function.  It's 8006h on the TI-83.

keyExtend = kbdScanCode + 7 (8007h on the TI-83.)  It holds the "extended" keycode returned by _GetKey (or by the menu system.)  But the TI-83 doesn't support lowercase, nor hooks, so it seems unlikely that you would ever use keyExtend in a TI-83 program.  What's the program you're trying to port?

ramStart is just the start of RAM - that's 8000h for every model - but again, I'm not sure why any program would ever use that symbol.  On the 83+, ramStart is the same as appData, which is the start of 256 bytes of more-or-less safe memory that programs can use (it's used for Flash-related stuff and also for OFFSCRPT/ONSCRPT, so it may be overwritten by _GetKey or by _Arc_Unarc or similar.)

I don't think there is any routine to do exactly what you're saying.

CursorToOffset (BC 494B) will scroll the editor to a given offset; i.e., it rewinds to the start of the buffer, then moves forward by (errOffset) bytes, displaying tokens as it goes (using the large or small font depending on the API flags.)  It then calls DispEOW to display the remainder of the screen after the cursor.  BC 4CD8 does the same as CursorToOffset except without the DispEOW.

(Displaying tokens one at a time is, as far as I know, the only way the OS ever handles scrolling.)

If you want to use one of these routines, you need to set curRow/curCol to the initial cursor position beforehand (e.g., for the program editor, you'd want to start at row 1, column 0, and display a colon character), and of course winTop and winBtm need to be correct.

To move to a given position without displaying anything, you could do something like this (untested):
B_CALL BufToBtm
ld hl, (editTop)
push hl
ld bc, (errOffset)
add hl, bc

ld de, (editCursor)
sbc hl, de
add hl, de
jr c, offset_invalid

ld (editTop), hl

B_CALL BufToTop
pop hl
ld (editTop), hl