I think everyone knows them, but do you all know what it actually takes to execute just a comon bcall?
Well let me tell you that it takes a whole lot of code before it actually starts executing the romcall, it even checks which kind of calc you have through port 2 and port 21 , and maps some memory through port 6, its crazy*..
*:not the memory mapping, but the HW checking
Well it could have been worse, but you would think it shouldn't have to check the HW version at every BCALL.
Thank you Dwedit for writing a Z80Disassembler
ROMcalls
Moderator: MaxCoderz Staff
-
- Calc King
- Posts: 1513
- Joined: Sat 05 Aug, 2006 7:22 am
what do you mean?kalan_vod wrote:Where is the disassemble?
Does that mean you want to have the disassembled code?
I just dumped 16k, starting at 0, in an appvar, changed the extention to 8xp and disassembled it with Dwedit's Z80disassembler, I then asked the Frontend program to look at the code starting at $00EF (bcall is rst 28h so it jumps to $00EF), and then it took around 2 hours to firgure out what all that code was meant to do (but I dont fully understand it yet)
-
- Calc King
- Posts: 1513
- Joined: Sat 05 Aug, 2006 7:22 am
I've stepped through bcall as well, and it's not very pretty.
And it tests the hardware version to see where pages map to in apps. Bcall also handles calls between app pages. It even tests if the app is stored in a ram page or not, and refuses to switch ram pages for apps stored in RAM.
And it tests the hardware version to see where pages map to in apps. Bcall also handles calls between app pages. It even tests if the app is stored in a ram page or not, and refuses to switch ram pages for apps stored in RAM.
You know your hexadecimal output routine is broken when it displays the character 'G'.