Omnimaga
Calculator Community => TI Calculators => ASM => Topic started by: Hot_Dog on April 16, 2011, 05:38:31 pm
-
Let's say that in an application, I use B_CALL _getKey. Since applications run from $4000, how does the calculator know that the 3-byte _getKey data is in the OS and not in the application?
-
I believe your answer is found inside ti83p.inc, since that's where all the bcalls are referenced. Might be wrong though :P
-
If you look at $0028, and follow the code from there, you'll see that the OS swaps out the Flash page that your application is on with a page that has the OS routines. Then, when the routines are finished executing, it swaps the page back.
-
If you look at $0028, and follow the code from there, you'll see that the OS swaps out the Flash page that your application is on with a page that has the OS routines. Then, when the routines are finished executing, it swaps the page back.
'Fraid it's not that easy. Remember that you can create your own B_CALL routines for Multi-page applications
-
Because the bcall is really rst 28h followed by a two byte address. The rst 28h is a one byte representation of the three byte call $0028 At 0028h, there is another jump that actually jumps to the bcall call. There, the two bytes following the rst 28h is used to determine which page the call info is on. If the address has bit 7 set, it goes to one page (0**11011b I believe, where ** is 11 on an +SE, 01 on an 83+BE and 10 on an 84+BE) . Either way, on that page, it finds the page number of the actual call as well as the address.
TL;DR
bcall is executed on page 0, not page 1, that is why :)
-
If you look at $0028, and follow the code from there, you'll see that the OS swaps out the Flash page that your application is on with a page that has the OS routines. Then, when the routines are finished executing, it swaps the page back.
'Fraid it's not that easy. Remember that you can create your own B_CALL routines for Multi-page applications
I'm pretty sure it is that easy. :P And what do you mean by creating your own B_CALL routines? The B_CALLs are the OS routines, so anything you have in your app isn't a B_CALL, and you can't use the B_CALL macro to call a routine in the app of your choice.
-
Hehe, actually, apps can create bcalls :) The special thing is that bcalls from apps have to have an address of a multiple of 3, I believe, and bit 6 is reset as opposed to set. I think that is how it works...
*bit 6 of the MSB of the address
-
If you look at $0028, and follow the code from there, you'll see that the OS swaps out the Flash page that your application is on with a page that has the OS routines. Then, when the routines are finished executing, it swaps the page back.
'Fraid it's not that easy. Remember that you can create your own B_CALL routines for Multi-page applications
I'm pretty sure it is that easy. :P And what do you mean by creating your own B_CALL routines? The B_CALLs are the OS routines, so anything you have in your app isn't a B_CALL, and you can't use the B_CALL macro to call a routine in the app of your choice.
Maybe I'm just dead lost. But here's the deal:
In a multi-page application, you could have a function called PutSprite on page 1.
PutSprite:
.dw 4135
.db 2
Suppose that the application is on flash page 14. How does the calculator know that PutSprite is a label on page 14
and not an OS routine? For all it knows, label 4135 could be a function in the Operating System
-
When all else fails, wikiti (http://wikiti.brandonw.net/index.php?title=83Plus:OS:How_BCALLs_work).
I have many a wondered the same question.
-
if 4135h is the address you are looking at, the bcall would be bcall(4135h-4000h) or bcall(0135h)
-
And to put it to rest:
bcall address:
- 0000h - 3FFFh -- Look at the currently running app
- 4000h - 7FFFh -- Look at page 1Bh/3Bh/7Bh
- 8000h - BFFFh -- Look at boot code
So depending whichever range the bcall falls into is where the OS will look. And the data is always stored the same: addrLow, addrHigh, page
-
And to put it to rest:
bcall address:
- 0000h - 3FFFh -- Look at the currently running app
- 4000h - 7FFFh -- Look at page 1Bh/3Bh/7Bh
- 8000h - BFFFh -- Look at boot code
So depending whichever range the bcall falls into is where the OS will look. And the data is always stored the same: addrLow, addrHigh, page
So to make sure I understand, $4000 is always subtracted from the label?
-
Only when the bcall info is in the app
-
Ugh, here's a problem I'm confused about. Sorry I'm still confused. So, applications are run from $4000, .org $4000 right?
What's the difference between
PutSprite:
.dw 4216h
.db 2
and _OP2ExOP5 EQU 4216h ? I still don't understand how the calculator tells.
-
Yes. For in-app bcalls. You take the <label for the bcall> - $4000. And that's what you throw in bcall. You should probably use some defines to make it less confusing.
killCalculatorL:
.dw killRoutine
.db 1
#define killCalculator killCalculatorL-$4000
Edit:
Ninja'd with a question. But do this for all of them and you should be good.
-
Because the bcall for the app is bcall(0216h) instead of bcall(4216h) even though they are still the same address. Once the routine figures out that it is less than 4000h, it realises it is from an APP and then adds 4000h to the address :)
-
But if the application runs from $4000, how can it run from $0216? If indeed $4000 is subtracted, why isn't $4000 subtracted from
B_CALL _OP2ExOP5 ;EQU 4216h
whenever it is in the application?
-
Because it isn't run from that :) The bcall sees it is from an app so it takes the address and adds 4000h to it then jumps to the correct address
-
Hold it:
I should have looked at my S.A.D. code. What was I thinking? Values are defined as less than $4000 from the start! 40 * 3 is NOT $4000 + (40 * 3)
:banghead: :banghead:
-
Hehe, I was making this post waiting for a response, so I will just post anyway...
This is why I like hex.... it makes much more sense...
EF1602
Step1:
calls 0028h which jumps to another location
Step2:
analyses address. Sees that 0216 does not have bit 14 or bit 15 set so it handles it as an app bcall
Step3:
Adds 4000h to 0216h and stores it to HL. Then it fetches the call info at that address.
Step3:
stores address elsewhere, gets the current app page and uses the offset page to adjust
Step4:
Calls the call.
Step5:
Restore the page and rets to return.
-
Also a ninja for me. So here's my explanation.
Ok, I'll break this down all the way.
bcall(_OP2ExOP5) is actually bcall($4216) which is actually
rst 28h
.dw $4216
my previous bcall(killCalculator) is actually bcall($0083) which is actually
rst 28h
.dw $0083
When the calculator encounters the rst 28h, it goes to $0028, which takes the next two bytes and parses them.
If the next two bytes are in the $4000 - $7FFF range: It looks on page $1B/$3B/$7B for the location data.
If the next two bytes are in the $0000 - $3FFF range: It looks on the first page of the app that is running for the location data.
The data that it is looking for is going to have this format:
.dw address
.db page
So when bcall(_OP2ExOP5) is executed. The OS is going to look on page $7B at $4216 for the data, which happens to be (in 2.53) $C8, $1D, $00. So the calculator is now going to call $1DC8 on page 0.
When bcall(killCalculator) is executed. The OS is going to look at the current app page ($69) at $4083 for the data. Which might be: $00, $40, $01. So the calculator is now going to call $4000 on app page 1, (which might be $68).
-
Well no more explinations needed. I simply forgot that the branch table consists of equates less than $4000. I got confused thinking they were $4000 or more.