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

[migry <hatari@xxxxxxxxxxx>]

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.
https://www.avast.com/antivirus