Of course Kerm, whoever can give me an idea of how to implement bcalls, oh my god... That would be perfect!
http://pastebin.com/cA2PdkwX
What I need:
> Bcalls;
What I don't need:
> Optimizations;
> Blaming my code.
;D Sorry, but I showed my code to a few python experts, and they all went crazy due to the structure of my code.
It's too bad Python doesn't have Goto
Qwerty.55 wrote:
It's too bad Python doesn't have Goto
Most PC languages don't have Lbl's and Goto's, but I'd love it
ScoutDavid wrote:
Qwerty.55 wrote:
It's too bad Python doesn't have Goto
Most PC languages don't have Lbl's and Goto's, but I'd love it
You have a list of explicit bcalls?! What the heck is wrong with you? That makes me so depressed.
Edit: OK, Merth pointed out that you have text equates. That's still not an efficient way to do it though, since every bcall starts EF. You should have EF XX XX always be a bcall, and a list of two-byte -> label equates to put names on the ones we have names for. It doesn't look to me as if you have that.
Edit #2: Also, as Merth also mentioned, many languages, including C/C++/(and C#?) have labels and gotos, and there are circumstances in which they're quite handy.
KermMartian wrote:
You have a list of explicit bcalls?! What the heck is wrong with you? That makes me so depressed.
Edit: OK, Merth pointed out that you have text equates. That's still not an efficient way to do it though, since every bcall starts EF. You should have EF XX XX always be a bcall, and a list of two-byte -> label equates to put names on the ones we have names for. It doesn't look to me as if you have that.
Well, could you say that in other words, I am sorry but I can't understand very well
Concerning my code, meh, it's what I have since I have no idea of how to do it.
He meant that instead of reading, say, EF0A45 as bcall(_PutS), you should code Assemblex so that as soon as it sees EF, it'll know it's a b_call, then look through a list of equates such as ti83plus.inc to find the name for the b_call.
Deep Thought wrote:
He meant that instead of reading, say, EF0A45 as bcall(_PutS), you should code Assemblex so that as soon as it sees EF, it'll know it's a b_call, then look through a list of equates such as ti83plus.inc to find the name for the b_call.
Exactly. That way you can handle any EF XX XX, even ones that aren't in the list of bcalls that you know. 
Hum, can't EF be rst 28h too? Or is it always bcalls?
The TI-OS bcall handler is at address $28 so will always be a bcall as far as the TI-OS is concerned.
benryves wrote:
The TI-OS bcall handler is at address $28 so will always be a bcall as far as the TI-OS is concerned.
Well, then Bcalls were implemented 
And they work really well, no bugs at all!
I have a doubt:
EF0000
It's a bcall that doesn't exist, what should I do, warn the user or just skip it, so EF0000210100 would return ld hl,1.
Which one? Alert or Skip?
Probably best to just leave it as bcall($0000). You won't necessary have a list of all of the legal bcalls (as not all of them are documented and TI do add new ones from time to time) so it's best to keep it as it is rather than potentially breaking something.
benryves wrote:
Probably best to just leave it as bcall($0000). You won't necessary have a list of all of the legal bcalls (as not all of them are documented and TI do add new ones from time to time) so it's best to keep it as it is rather than potentially breaking something.
I'm not sure if people really like B_CALL ($EF0745), I prefer B_CALL (_DispHL) much.
UNDERSTOOD
For existing Bcalls, it puts the name, for non.existing bcalls it puts B_CALL ($EF0745).
Please discuss it
ScoutDavid wrote:
benryves wrote:
Probably best to just leave it as bcall($0000). You won't necessary have a list of all of the legal bcalls (as not all of them are documented and TI do add new ones from time to time) so it's best to keep it as it is rather than potentially breaking something.
I'm not sure if people really like B_CALL ($EF0745), I prefer B_CALL (_DispHL) much.
UNDERSTOOD
For existing Bcalls, it puts the name, for non.existing bcalls it puts B_CALL ($EF0745).
Please discuss it
Exactly right, merthsoft. $EF is the RST $28 opcode (bcall(xyz) is turned into rst $28 \ .dw xyz by an assembler macro).
Yeah, I mean bcall($0745), but don't you think the name of it is better?
If you have the name, include the name. If you don't have the name, just include the address as a four-digit hexadecimal number.
That's what I was trying to say previously: just because you don't have it in your list doesn't mean it's not a real bcall. Just display the hex address of it if you don't have it in your list.
KermMartian wrote:
That's what I was trying to say previously: just because you don't have it in your list doesn't mean it's not a real bcall. Just display the hex address of it if you don't have it in your list.
´
Which is already done:
Code: if b[i] == 'EF':
bCallUsed = ''.join([b[i],b[i+1],b[i+2]])
if bCallUsed in bCallsCode:
bCallLocation = bCallsCode.index(bCallUsed)
if i != 0:
program += "\n"+ "B_CALL ("+bCallsName[bCallLocation]+")"
else:
program += "B_CALL ("+bCallsName[bCallLocation]+")"
i=i+3
else:
if i != 0:
program += "\n"+ "B_CALL ($"+b[i+1]+b[i+2]+")"
else:
program += "B_CALL ($"+b[i+1]+b[i+2]+")"
i=i+3
If I could make a suggestion: is it too difficult to read a .inc file, like the DCS one, or the ti83plus.inc file and get your bcall/call equates from that? Then all we have to do is set the place where the .inc file is to read, and it will work with any equate table (even if we make them up ourselves).
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
