During development traces are a really helpful source of information when doing debugging or if you simply want to understand how a system works. When developing for the classic Amiga platform you learn a lot about the inner workings of applications if you could see what library functions they call and what parameters they pass in and get out. You can observe its behavior without having the source code and all that almost live…
Here libtrace comes into play: Its a debugging extension I have written for the famous FS-UAE Amiga emulator that allows you to take this look behind the scenes of the system: You can trace any library and any function set and you will see what function was called by printing its name, the arguments and the values passed in an out…
First you need to build a new FS-UAE from source with the libtrace feature. Use my libtrace branch on GitHub for this.
You need to write a small config text file that defines the trace profile, i.e. what libraries you want to see and what functions.
Name the file e.g. libtrace.cfg with the following contents:
dos.library fd/dos_lib.fd +* !Open # exec.library fd/exec_lib.fd InitResident #
Here we will trace dos.library and exec.library. In dos we want to see all functions (*) but not the Open() call. In exec only the InitResident() function is traced. The .fd files need to reside on your host in the given directory (here in the fd folder of the current directory). Take them from the AmigaOS NDK.
See the libtrace documentation for more details on the config file
Now run FS-UAE and enter the debugger with F11+d.
In the Debugger load the config file and enable tracing:
Lc 'libtrace.cfg' Le 1 x
Exit the debugger and reset your Amiga to activate the trace (F11+r).
With the new Amiga startup you should see the traces popping in on your console.
It looks like this:
@00f81014 0000f8c8:Initial CLI exec InitResident(resident[a1]=00fbf080, segList[d1]=00000000) @00fbf100 0000f8c8:Initial CLI dos CreateProc(name[d1]=00fbf09a, pri[d2]=00000000, segList[d3]=003efcdb, stackSize[d4]=00000800) @00fbf100 0000f8c8:Initial CLI dos CreateProc -> d0=0001bd44 @00f81014 0000f8c8:Initial CLI exec InitResident -> d0=000160e0 @00fb85f0 0001c620:CON dos WaitPkt() @00fb85f0 0001c620:CON dos WaitPkt -> d0=0001c5f0 @00fb85f0 0001c620:CON dos [DosPkt: Type=00000000 Args=00005883,00000000,0000084b,00000000 Res=00000000,00000000] @00fb8490 0001c620:CON dos StrToLong(string[d1]=0001e06c, value[d2]=0001d0b8) @00fb8490 0001c620:CON dos StrToLong -> d0=ffffffff
You’ll see the PC calling the function, the exec task with name, the lib and finally the function with all argument names and values. A second line reports the return of the function and prints the result value.
You can filter the trace and focus on a single task if you give its name in the debugger with the Lt option. Furthermore, you can write the traces to a file instead of the console with the Lo command.
Lt 'CON' Lo 'out.txt'
That’s it… Read the libtrace doc for more details and a technical description of the inner workings of this feature.
Have Fun and Happy Amiga Coding!
Recently, I was thinking about a minimal Amiga emulation setup that is required to run Exec and Dos from a Kickstart ROM image. Think of a reference platform for vamos. I soon came to the conclusion that all kinds of boot types result in accessing a device that provides the requested file system blocks. As a consequence the emulation also needs to emulate some kind of device accesses next to the essential CPU, memory, and CIA (timer, serial) emulation we will need at least. Trackdisk device needs custom chip support for track reading, while scsi.device needs some IDE host emulation.
If you compare a classic Amiga with modern embedded devices (like a Raspi or a Beagleboard) you see a difference: the modern devices often allow to boot directly their filesystem of the on-board flash. “Why not create a ROM bootable device for Amigas?” was the next question that came to my mind. With such a device it is sufficient to emulate CPU and memory and the Amiga can already boot…
The result of this initial idea is a small project called romdisk: It offers a romdisk.device that can auto-boot a modern classic Amiga (OS 2.x or 3.x) and also a tool to embed disk images into an ext. ROM image. Without compression you get ultra fast data access, but with compression you can even fit a complete Workbench floppy disk image (880 KiB) into your 512 KiB ext. ROM.
The first public release is now available and can be found on my new romdisk project page!
While it started as a helper project for my emulation tests, I am sure you can think of new uses for romdisks, too. E.g. some diagnosis tools that do not need external devices to run, or a rom disk stub that loads non-rommable modules and then heads over to full boot from hard disk, or a small network boot disk that loads the main file system via network…