|Re: [hatari-devel] Using Hatari to debug custom version of EMUTOS
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel 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
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.