Hi guys !

I'm trying to do a mad thing translating an 83+ ASM program to 83 ASM

I know that's possible, even it's long and difficult, but right now I have some issues with replacing adresses, so I ask several Ti-83+ related questions :

- What is the use of the variable appID $838D ?
- What does the romcall _saveDisp do ?
- Is there any extended ti83asm.inc, like for BrandonW's ti83plus.inc ?
- How (or with what) can I replace _bufClr, appBackUpScreen, appID, keyExtend, kbdGetKy, _saveDisp, ramStart ?

Many questions, I hope that you'll can help me

- AppID is used when searching for apps. This program is either using it as temporary space or is doing some OS hack.
- _saveDisp saves the screen to a 768 byte buffer pointed to by HL
- I've never programmed for the 83, so I don't know if there is a better include, but there probably isn't.

_bufClr
bufClr:
ld d, h
ld e, l
inc de
ld (hl), 0
ld bc, 767
ldir
ret

appBackUpScreen and appID - these are probably just free ram areas appBackUpScreen is 768 bytes and appID is no more than 20

keyExtent - this is specific to _getKey, the 83 should have it's own version

kdbGetKy - I ran a quick test and this appears to be the getCSC code for the most recent key scan (these happen every interrupt)

_saveDisp
#define DWAIT in a, ($10) \ or a \ jp m, $-3

saveDisp:
ld a, $80
out ($10), a
ld c, $20
saveColumn:
DWAIT
ld a, c
out ($10), a
cp $2C
ret z
ld b, 64
ld de, 12
DWAIT
in a, ($11)
saveByte:
DWAIT
in a, ($11)
ld (hl), a
add hl, de
djnz saveByte
ld de, -767
add hl, de
inc c
jr saveColumn

ramStart - this is for free ram, it offers up to like 1000 bytes, but most people use less than 100


Edit:
   For these routines, you're actually better off looking at TI's official docs. They can be found here and the two you want are TI-83 Plus Developer Guide and TI-83 Plus System Routines.

In fact, I'm trying to port an Axe program to the 82 stats (my Jetpack for instance, see the topic in the Axe projects subforum), so I disassembled it and I ask for advices here.

@thepenguin77 @FloppusMaximus thank you very much thepenguin77 I'll try to replace the calls with your code.

The amount of space used at appID cannot be more than 178 bytes. The reason for this is 178 bytes after appID is where the memory locations for getCSC are stored.

However, this program might not use all 178...

'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.)

I suggest taking a look at wikiti.brandonw.net

Id just include appropriate buffers in the program itself to see if the port at least runs properly. Then you can look at allocating them somewhere.

I know what the problem is, there are a lot of pointers inside this program that are simply numbers now (they used to be labels). The problem is that now the code is executing from a different location (because of 83 reasons as well as adding/removing code). What you need is to have all your labels in line.

If you post the .8xp, I'll get you a disassembly with all the labels in the right spot. (I'm going to use IDA)