I'm dabbling around again with z80 asm on my 83+.
So I fired up tasm32 after messing around with some simple basic code.
Code: #include "ti83plus.inc"
.LIST
.org 9327h
bcall(_ClrLCDFull)
ret
.end
END
Used this to compile it:
Code: wine TASM.exe -80 -b -i hello.asm hello.bin
Then used bin2var to make it a .8xp. But after transferring it to the calc, I did the usual go into EXEC and picked HELLO, but when I ran it - I got this error. http://imagebin.org/index.php?mode=image&id=19964
I've never seen that before. Any ideas?
This is kind of off-topic, but how well does TASM work in Wine?
Back on track, I don't think I can help you a lot since I barely know anything about assembly. However, here are some things I have noticed:
- There is a .list after the include, but there is no .nolist before it. I think (note: think, not know) this might cause problems.
- You might want to try replacing the bcall with b_call
- Are you sure the .org address is valid? But what do I know; after all, all my programs started at 9D95h...
- I am not sure about this, but I know something about a batch file called asm.bat that might help your TASM woes by directly converting files from .z80 (not sure if it does .asm as well) to .8xp or .83p
Once again, I am sure someone will correct me on at least one occasion in this post, as I really am an assembly newbie.
EDIT: I am suspecting it has to do with the conversion process. You might want to try a different method of assembling your program, whether it is by the batch macro for TASM I mentioned, or by using a different assembler (like SPASM).
Your tasm command looks ok to me, but I've never used bin2var. Maybe you should try devpac8x, since it works fine for me.
Delnar_Ersike wrote:
This is kind of off-topic, but how well does TASM work in Wine?
[*]There is a .list after the include, but there is no .nolist before it. I think (note: think, not know) this might cause problems.
[*]You might want to try replacing the bcall with b_call
[*]Are you sure the .org address is valid? But what do I know; after all, all my programs started at 9D95h...
[*]I am not sure about this, but I know something about a batch file called asm.bat that might help your TASM woes by directly converting files from .z80 (not sure if it does .asm as well) to .8xp or .83p[/list]
EDIT: I am suspecting it has to do with the conversion process. You might want to try a different method of assembling your program, whether it is by the batch macro for TASM I mentioned, or by using a different assembler (like SPASM).
Works fine with wine, used to do it all the time.
nolist, bcall, and 9D95h were not the problems.
Batch files are a windows thing, and all that does is let you type one command, to execute all the other steps.
I'm going to try something other than bin2var, and if that fails, I'll try SPASM.
_____EDIT_____
I just tried to do it with spasm in wine, (and bin2var) and there is no calc error, I get Done. But I'm using bcall(_ClrLCDFull)..but it's not doing that. If I try to change it to b_call, that dosn't compile.
____EDIT____
Ok, not sure what I did, but I got it to work in TASM32. 
$9327 is the .org offset for the TI-83, while we're on the subject. $9D95 is for the TI-83+/SE/84+/SE.
Then I think I actually see the problem now: the program is made for the 83, but it is compiled in an .8xp file, not a .83p file.
Delnar_Ersike wrote:
Then I think I actually see the problem now: the program is made for the 83, but it is compiled in an .8xp file, not a .83p file.
Not really. $9327 is the only 83-specific thing here; when compiling for the 83, bcall() is just macro'ed to call(). If $9327 was changed to ProgStart and a $BB,$6D. Oh.
You're missing the $BB,$6D.
Code: #include "ti83plus.inc"
.LIST
.org $9d95-2
.db $BB,$6D
bcall(_ClrLCDFull)
ret
.end
END
When the OS thinks your program is a BASIC program (which it does because you were missing those bytes), it goes through every token in the program to determine the "version" of your variable. If it finds tokens that your particular OS version doesn't recognize, which it did (assembly garbage) (none of them will recognize it), then it thinks the version is 0FFh (this is the VAT version byte when the OS decides to actually store it), and will throw ERR:VERSION when running it.
When does it do the version determination check, when the program is loaded onto the calculator or when it's actually executed?
KermMartian wrote:
When does it do the version determination check, when the program is loaded onto the calculator or when it's actually executed?
I don't remember seeing the check when it runs a program, so I'm not sure, but you can check yourself by looking for references to http://wikiti.denglend.net/index.php?title=83Plus:BCALLs:510A which is what the OS uses to check the version of a variable.
I know for sure that it's checked when sending/receiving such a variable.
EDIT: actually, this is wrong...the parser's coded to throw ERR:VERSION if it comes across the 0EFh token, for whatever reason. 0EFh is the first byte it sees from your program because you had the BCALL macro at the beginning, which starts with rst 28h, which is 0EFh.
The OS doesn't check the variable version before running it, but it does update it when you leave the program editor.
Fascinating, that makes a lot of sense, especially why they'd choose the 0EFh toaken as something to watch out for.
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.
»
Go to Registration page
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
