Conversion from 83+ to 83

[Matrefeytontias]

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

[ralphdspam]

Are you porting your own program, or are you porting someone else's program?  If you're porting your own ASM program, you know how what each subroutine does and can easily change the addresses and system calls.  If it's someone else's program, you have to be aware of how much memory each array requires and which optimization hacks the programmer used. Note that some programs are impossible to port due to the hardware differences.

Make sure that you read WikiTI and the documentation on TIcalc.org.  Those will be invaluable resources.
Take a look at this: http://www.ticalc.org/pub/text/calcinfo/83rom.zip
And this: http://wikiti.brandonw.net/index.php?title=Category:83:RAM:By_Name

[thepenguin77]

- 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

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9

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

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

#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.

[FloppusMaximus]

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

[Matrefeytontias]

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.

[Matrefeytontias]

Up !

I replaced nearly all the things I needed to replace, else appID and appBackUpScreen : since they are respectively 20 and 768 bytes large, which are can I use to replace them ? I can found for appID but I didn't found for appBackUpScreen ...

EDIT : in fact I don't know how much bytes appID is large ...

[thepenguin77]

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

[Matrefeytontias]

As I remind (I don't have the source right now) the program use 75 bytes (since I saw (appID+74))

I also find that I needed to replace the variable flags (the IY register) : on a 83+ it's $89F0, but on a 83 ?

So for recap, I need to replace appBackUpScreen, appID and flags, and then it's done (according to the fact that flags don't move )

[FloppusMaximus]

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

[Matrefeytontias]

Okay, thanks a lot for your explanations, I'll try it

[aeTIos]

I suggest taking a look at wikiti.brandonw.net

[Matrefeytontias]

I already read all the site before opening this topic ...

[tr1p1ea]

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.

[Matrefeytontias]

Ok, here is an update.

I had to convert two programs : an installer (done) and a huge executable (51K of source). I have very big problems with this one, and I'm since I'm not really good at z80 ASM, I'm searching for someone who could look over a huge 51K ASM source file to find errors, but that's not errors that stop the compilation, just bad programming (since it's only disassembled Axe). Of course, this is 83 ASM.

If you can help me, please do, I can't carry on anymore

[thepenguin77]

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)