Re: [hatari-devel] Using Hatari to debug custom version of EMUTOS

[ Thread Index | Date Index | More Archives ]

Thank you again Eero!

I was able to use my linux version of Hatari to generate the list of functions/labels visited. I did the same using my "own" (when I say own, I modified someone else's great work to add extra features!) emulator. I get a disassembled trace of the full EMUTOS boot process. I then use grep to create a list of all the labels. I then used tkdiff to compare the EMUTOS boot log and my own. After some fiddling and removal of slight differences, I was able to find where the deviation was. This led me to find a bug in my code where I had incorrectly changed the AES process stack.

BTW. If I compile a custom version of EMUTOS and add the "ENABLE_KDEBUG" define to enable RS232 output debugging, is there a way to either view this separately in Hatari or capture the text? I have enabled this in my own codebase and this also has greatly helped to debug the EMUTOS boot problems in my own emulator. In the source code I "intercept" the write to the UART TX register (part of my customisation) and write a special string "UART TX" to the screen debug log which can be trivially filtered out using grep. I then join all the characters to get a nice clean log file.

I will say more about my custom version of EMUTOS (*) on that mailing list, once I have the code running on real hardware. Just today I finally have the emulator successfully reaching the GEM desktop and I see it stuck in a loop waiting for I/O. My emulator runs a fraction(!) of Hatari speed, so I see all the screen draws as if in slow motion :-) .. If I remove the disassembly then it should run a lot faster.

(*) Since my hardware is custom I cannot run the code on Hatari.

I appreciate you taking the time to reply to my questions, both here and on the EMUTOS mailing list.

This email has been checked for viruses by Avast antivirus software.

Mail converted by MHonArc 2.6.19+