0 Members and 1 Guest are viewing this topic.
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.
Quote from: souvik1997 on April 16, 2011, 05:41:55 pmIf 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
Quote from: Hot_Dog on April 16, 2011, 05:43:18 pmQuote from: souvik1997 on April 16, 2011, 05:41:55 pmIf 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 applicationsI'm pretty sure it is that easy. 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.
And to put it to rest:bcall address:0000h - 3FFFh -- Look at the currently running app4000h - 7FFFh -- Look at page 1Bh/3Bh/7Bh8000h - BFFFh -- Look at boot codeSo depending whichever range the bcall falls into is where the OS will look. And the data is always stored the same: addrLow, addrHigh, page
killCalculatorL: .dw killRoutine .db 1#define killCalculator killCalculatorL-$4000