search

davervw / c64-io_monitor

Commodore 64 Kernel I/O entry point monitor utility
https://techwithdave.davevw.com/2021/12/trace-c64-io-kernal-jump-table-calls.html
MIT License
22 stars 3 forks source link

Supermon64 doesn't use Kernal jump table #3

Open davervw opened 2 years ago

davervw commented 2 years ago

For instance, S"TTT",08,0800,08FF

calls SAVE via the vector instead of the jump table .C:99f2 6C 32 03 JMP ($0332)

May need to hook the vectors instead of the ROM table

Whammo commented 2 years ago

I think the Kernal doesn't use the jump table or the vectors. I'm certain it jumps into the low level stuff at odd places too.

davervw commented 2 years ago

Absolutely. You are correct. Though I'm not interested in tracing the Kernal's own activity (at least not in my current context -- maybe for other endeavors). Was focusing on high level documented entry points.

(When I wrote my emulators, I trapped execution to specific routines, and it appears I missed that the vectors were in use by this supermon64 program. The trace monitor was supposed to help me fix that, but as we all know, plans can change at any moment. It's actually good news for the emulators -- the vectors are good documented entry points and should be straightforward to support. BTW, my emulator traps the call, does all the work, and returns without running any further 6502 code. It's definitely cheating, but it's an emulator.)

The other interesting thing is to trap the vectors instead of ever patching the KERNAL ROM (for those entries that it works, so may be a different set), thus could avoid the banking altogether. But for those jump table entries that don't use any vectors, sigh.

And if one is interested in seeing what is going on in the ROMs for a specific operation, then the "Walk a ROM" feature of one of my emulators is a good starting point. Emulator with Walk a ROM Feature. I did this the other day for LOAD FFD5, and it did happen to use the jump table for some stuff, and made other internal calls for other stuff like low level IEC.

davervw commented 2 years ago

I had also implemented a busy flag. If we are already hooking a routine in process, another incoming one is not traced. So if the KERNAL calls itself, only the original call is logged, nothing else is logged until that call is finished, because potentially logging its results. Again, because interested mostly in incoming (not internal) requests.