Omnimaga
Calculator Community => TI Calculators => ASM => Topic started by: Matrefeytontias on June 08, 2012, 08:10:41 pm
-
Hi guys !
I'm trying to do a mad thing translating an 83+ ASM program to 83 ASM O.O
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 :)
-
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
-
- 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 (http://education.ti.com/calculators/downloads/US/Software/Detail?id=177&ref=%2fcalculators%2fdownloads%2fUS%2fSoftware%2fSearch%2fResults%3fcp%3d28%23view-11) and the two you want are TI-83 Plus Developer Guide and TI-83 Plus System Routines.
-
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.)
-
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.
-
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 ...
-
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...
-
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 :/ )
-
'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.)
-
Okay, thanks a lot for your explanations, I'll try it :)
-
I suggest taking a look at wikiti.brandonw.net (http://wikiti.brandonw.net)
-
I already read all the site before opening this topic ...
-
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.
-
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 :'(
-
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)
-
Nope, that's not it, my disassembler supports label names, datas and texts :(
The problem is inside the code ... I'll send you when I can
-
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 (https://en.wikipedia.org/wiki/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.
-
disassembly is hard.
That's something that is totally true (too bad)
-
That's true, I really have a disassembler recognizing labels, datas and texts. Unfortunately, it's unnamed, but you can download it here : http://mattias.refeyton.fr/espace-ti/z80disassembler.zip
Also, I have my code here : http://mattias.refeyton.fr/espace-ti/jetpack82/JETPACK.z80 , but remind that it's 51K large.
There aren't any error at the compilation, but here is a screenshot of it working with the installer on a 83 :
(http://mattias.refeyton.fr/espace-ti/jetpack82/1.gif)
EDIT : in fact, there isn't any _DelVarArc in the file ... <_<
-
Could I just try running it through IDA? (I need the 8xp)
That looks like a good disassembler, but one mistake can break the program.
-
Yeah sure, I join the *.8xp I compiled from the source I posted.
Oops, I forgot to join the installer, you need to launch it before prgmJETPACK :/
-
You know, before I finish off this disassembly, what does the setup program do? The reason I ask this is because if it gets some variables prepped, then we'll have to store those variables in a static memory location. You can't allocate space after a program and then expect that memory to remain constant.
Edit:
After disassembling it, it would appear that you make an appvar and store some data to saveSScreen. I think I can work with that.
-
The setup creates a program named prgmJTPKSTUP, stores three 768 bytes images in it and then quits.
What the main program does is accessing to this program and read the three images with a 768 or 1536 offset.
Now that I think of it, I remind that there is a bcall named _DelVarArc on the 83+ that doesn't exist anymore on the 83, I'll try to replace it with _DelVar and see if it works better.
-
Also, I don't have a way to test this in wabbitemu. So if you could help me out there... (email)
-
Ah yeah, I'll send you something to test it.
-
Complete!!!
Now, there were two specific parts that I know you missed. First, run a Ctrl+F for $522, $533, and $FADB. These numbers are correct on the 84+, but what they actually represent are
- appBackUpScreen-plotSScreen
- appBackUpScreen-plotSScreen+1
- plotSScreen-appBackUpScreen+13
respectively. Since we moved these memory locations around, those numbers were now no longer correct.
The second part actually slipped by your disassembler twice. Run a Ctrl+F for "ld bc,$B978". This address was actually 1 byte past the end of your program, so your disassembler assumed that it was a constant memory address.
For the second part of this problem, go to the very end of your data. You'll see .db $F1,$9D,$73,$9F, which we could rearrange to .dw $9DF1, $9F73. These are actually pointers to certain locations in your code and need to adjust with the change in running location. That means they should be more properly written as labels: .dw loc_9DF1, loc_9F73.
But, in all, it's done. So enjoy. I included the source I used as well as the source compiled for use with venus. (That's why there's an awkward header on the files).
Also, this screenshot was the first time I ever got the grappling hook thing, so that kind of freaked me out.
Edit:
I have no idea how big loc_8079 should be. You can remove all the zeros before it and probably give it like 2 after. (Rather than 96)
-
Is it only me or is the gs the same on the real 83? Since uh, then you can better remove the gs part <_<
-
Waaaa thanks a lot thepenguin77 ! :D
You'll be in the credits ^^