Posted September 05, 2024 by howprice
Aira Force 0.8 brings source level debugging, improved emulation and many UI improvements.
Previously pointers could only be added on code lines. Now they can be added in data too.
An address input widget has been added to the Add Label popup. This allows labels to be added at any address. For example, a label can be added at an unreferenced data address.
The internal instruction disassembler can be configured in the options.
Equivalent options are available when exporting disassembly. File > Export Disassembly...
If an internal error is encountered (assert or fatal error), a crash log file is written: AiraForceLog.txt
Please look at the last entry in this log when reporting errors. For example:
Version: 0.8.0 ASSERT: lineNumber >= 1 Message: Line numbers are 1-indexed by convention Function: SourceCodeWindow::GotoFileAndLineNumber File: C:\dev\howprice\iragui\src\IraGui\Windows\SourceCodeWindow\SourceCodeWindow.cpp(536)
The debugger has been split out of the analyser. Programs can now be debugged with analysis disabled, or enabled.
For programs built with vasm or vlink, the debugger can load debug data to associate symbols and source code with the program addresses. Source level debugging is available for 68000 binaries built in 4 different ways:
Debug information is parsed from several sources:
Many thanks to Frank/phx for adding lineoffsets output to vlink, which allows debugging of linked raw binaries.
This video demonstrates the process:
The 68000 emulation in version 0.7 was designed to be just good enough to traverse the program flow. As a mid-term goal, I would like the tool to be able to actually start running programs. The first step was to improve the 68000 instruction emulation.
I have used the excellent 680x0 SingleStepTests by Tom Harte to test each instruction. This is a huge data set of before and after states for the CPU to test each instruction behaves as expected. The emulator is not currently cycle exact, so the tests did not make use of the timing data. This also means that the PC in the stack frame on address error can be incorrect.
but it's reasurring now to know that the 68000 emulator is much more trustworthy.
I was horrified by how many instruction bugs I had to fix. I had made silly mistakes in many common instruction such as multiply and shift. The tests run on each push to the main branch on GitHub.
Chip, Fast and Slow RAM and ROM are now available and mapped.
With improved 68000 emulation I thought it might be nice to try to visualise the results. I implemented the bare minimum subset of Amiga hardware registers to generate a video display buffer at the end of the frame.