I thought I'd have a quick look at the new Repton3 loader to figure out why it won't load from ADFS / NFS. Got myself really confused when using the *REX disassembly tool that is part of the Advanced ROM Manager (ARM) Utility ROM. Initially testing on real hardware, this is what I was being presented with when issuing a *REX0 A9C command:
Addresses &AA2 thru &AB2 didn't make much sense. I thought the code was self modifying because if I changed address &AA2 to RTS, it would change back again. But I couldn't figure out what was modifying the code. Hmmm.
So I moved over to BeebEm to see if the debugger could shed any light on the matter, and I got different results! Now, that looks more sensible:
Why the difference??? So I run *REX0 A9C from within BeebEm, and I see the same as I see on the real hardware. Check the debugger, and it's changed as well!
I can only assume *REX is using Page 10 for its own workspace, and is therefore corrupting the code that I'm trying to debug . I've wasted a couple of hours on that . And now that I think about it, I'm pretty sure I've seen this problem before.
Advanced ROM Manager (ARM) 1.13 Limitations
Advanced ROM Manager (ARM) 1.13 Limitations
Last edited by KenLowe on Tue Nov 07, 2023 11:44 am, edited 1 time in total.
Re: ARM113 Limitations
("Advanced ROM Manager" in case it's not obvious - which it wasn't to me!)
Re: Advanced ROM Manager (ARM) 1.13 Limitations
Updated the title and some of the text to make it a bit clearer.
I've decided to try using py8dis instead of ARM113 to disassemble the code.
I've decided to try using py8dis instead of ARM113 to disassemble the code.