There is a particular kind of debugging problem that only old computers can provide.
The software is nearly forty years old. The media is magnetic. The operating system lives partly in ROM. The documentation assumes you remember what a key is. And somewhere along the way somebody installed an antivirus written when “computer virus” was still a sufficiently new concept that people were not always entirely sure how one moved from machine to machine.
This investigation started with an old Amiga copy of Battle Chess.
Which is appropriate, because Battle Chess gave software development one of its better debugging metaphors: the duck.
Battle Chess and the duck
According to a piece of Interplay lore, the artist responsible for the queen’s animations knew that the producer had a tendency to request some change during every review.
So he prepared the queen exactly as he wanted her, and added one deliberately unnecessary feature.
A pet duck.
The duck was carefully animated alongside the queen, but kept separate from the actual animation. When the producer reviewed the work, everything important survived untouched. There was just one requested change:
lose the duck.
The trick was not that the duck hid a defect. Quite the opposite: it provided an obvious, harmless target for scrutiny so that the thing the artist actually cared about could pass through review unchanged.
Years later, Battle Chess provided me with another duck.
This one lived in its boot block.
And I fell for it completely.
Enter Greaseweazle
The whole investigation started because I was preserving old Amiga floppies.
For that, I was using a Greaseweazle.
This is particularly interesting with Amiga disks because the Amiga and the PC approached floppy disks almost from opposite directions.
A traditional PC floppy controller is heavily format-aware. Software normally asks the controller for a particular cylinder, head and sector, and the controller takes care of finding the sector, decoding the MFM data, checking the CRC and returning the contents.
That works very well as long as the disk looks like something the controller understands.
If it does not, software has very little room to negotiate.
The Amiga floppy subsystem was deliberately much less opinionated.
The hardware can DMA the encoded track data into memory and leave interpretation to software. Normal AmigaDOS tracks have a defined format, of course, but software is not limited to that format.
That freedom is one reason Amiga software accumulated such an impressive collection of custom track layouts, unusual sync words, protections and other creative abuses of magnetic media.
Very approximately:
PC: software: give me sector 7 controller: certainly I know what a sector is
while the Amiga is closer to:
hardware: here is the encoded track data software: excellent I'll decide what it means
Greaseweazle goes lower still for preservation purposes.
Instead of returning decoded sectors, it records the timing of the magnetic flux transitions coming from the drive.
For a normal AmigaDOS disk, it can decode directly into an ADF:
gw read --format=amiga.amigados disk.adf
For preservation, however, I also like keeping a flux-level image:
gw read --revs 5 disk.scp
That records several revolutions of the disk.
Those transitions can later be decoded again, compared between revolutions, interpreted by other software, or written back to a floppy.
So, roughly:
PC floppy controller: sectors Amiga floppy subsystem: encoded track data Greaseweazle: flux-transition timing
For old-media archaeology, that lowest layer is extremely useful.
Battle Chess, however, did not initially look like a magnetic-media problem.
The disk read cleanly.
The filesystem was there.
The strange part came afterward.
The original mystery
Opening the Battle Chess disk window in Workbench produced:
The timing was interesting.
Workbench opened the window.
The icons appeared.
Then, just before it seemed to finish opening the drawer:
Guru.
My first thought was damaged media.
So I found another Battle Chess image online.
It crashed in exactly the same way.
That was the first major clue.
And the beginning of several excellent wrong ideas.
Comparing the two disks
The next tool entering the story was amitools,
particularly xdftool.
If Greaseweazle lets me ask what was physically recorded on the
floppy, xdftool lets me ask what the Amiga filesystem
structures say about it.
It understands OFS and FFS volumes and can inspect directories, files, root blocks, allocation bitmaps and other filesystem structures directly from an image.
For example:
xdftool battle_chess.adf list / detail
showed:
Battlechess BattleChess.info Chesstodh0 ChessToDH0.info Disk.info EndCLI Icon.Library LoadWB s System-Configuration
Nothing obviously missing.
Then I compared my image against the one found online.
They were remarkably similar.
The actual game and filesystem contents were essentially the same. Apart from a few administrative differences in the root block, the significant difference was at the beginning of the disk.
My copy contained a custom boot block:
This disk was installed with TRISTAR-Viruskiller V1.1 Written 1988 by Transformer (Disk is protected against the SCA-Virus)
The online image did not.
There were also a few differences in the root-block metadata around block 880.
But the content of the disk was, for practical purposes, the same.
That made the boot block extremely difficult to ignore.
The virus hypothesis — and my own bias
The antivirus explanation was especially attractive to me because I grew up in exactly that period.
Computer viruses in the late 1980s and early 1990s occupied a peculiar place in popular computing culture.
They were very real.
But the understanding of how they propagated was not always equally real.
I still remember a computer-science teacher in high school, around 1992, asking us to unplug the PCs from the mains because a virus had been discovered and there was concern that it might propagate through the electrical wiring.
That memory matters because it explains my own bias here.
When I found:
TRISTAR-Viruskiller SCA-Virus
inside the boot block of a disk producing a mysterious Guru, my brain immediately assembled a satisfying story:
The disk had a virus.
Somebody tried to clean it.
Something survived.
Now that something is upsetting the system.
It was plausible.
It fit the period.
And it was dramatically better than “some filesystem bit is wrong.”
That should probably have been a warning.
All the boot block actually proved was:
Someone, at some point, was concerned enough about viruses to install TRISTAR-Viruskiller.
It did not prove that this particular disk had been infected.
It did not prove what the owner understood about boot-block viruses.
And it certainly did not prove that the present failure had anything to do with malware.
Still, it was difficult to resist.
It was our first duck.
Another suspicious
character: chesstodh0
The disk startup sequence was very short:
chesstodh0 LoadWB endcli > nil:
LoadWB and EndCLI are ordinary enough.
chesstodh0 was more interesting.
Looking into the executable revealed:
UNIT A && World of Wonder presents NR. 47: BATTLECHESS Thanx to Blackie for the original ...
It also contained references to graphics.library,
dos.library and icon.library.
A crack-group executable.
Running before Workbench.
On a disk that crashes Workbench.
This was an exceptionally good duck.
Perhaps it installed something resident.
Perhaps it changed DOS state.
Perhaps it left something behind that later failed.
So I removed it from startup-sequence.
Its messages disappeared.
The crash did not.
Remove the whole Battle Chess boot environment
There was an even cleaner way to eliminate that branch.
I booted a known Workbench 1.3.2 disk instead.
Once Workbench was running, I removed that disk, inserted Battle Chess and opened its drawer.
Now none of the Battle Chess boot-time software had run:
no Battle Chess boot block no TRISTAR code no chesstodh0 no Battle Chess startup-sequence no Battle Chess LoadWB no Battle Chess EndCLI
And yet:
87000008So whatever the problem was, simply mounting and opening the Battle Chess disk was enough.
The surprisingly important write-protect tab
Then came the observation that changed the investigation.
Make the ADF write-protected:
works.
Make exactly the same image writable:
Guru.
That was much more interesting than another ROM revision or another executable.
Nothing about the visible contents had changed.
Workbench could clearly read the disk.
It could find the directory.
It could load the .info files.
It could draw the icons.
But whether the disk was allowed to be written determined whether the system survived opening the drawer.
At this point there were two facts:
same disk same Workbench operation write-protected -> works writable -> crashes
The obvious next question was no longer “what strange thing is the emulator doing?”
It was:
Does the real Amiga do the same thing?
Ask the Amiga
My first physical-hardware test had been misleading for a wonderfully mundane reason:
the disk had been write-protected.
So I returned to the physical Amiga.
Same disk.
Same operation.
But this time I opened the write-protect tab.
Workbench opened the drawer.
The icons appeared.
Then:
Guru Meditation.
Exactly the same behaviour.
That result was decisive.
There was no longer an emulator versus hardware problem to explain.
The real machine and the emulator agreed.
More importantly, they agreed on the one variable that mattered:
write-protected -> works writable -> fails
Only now did it make sense to stop looking at execution environment and start asking what the Amiga itself was complaining about.
What does 87000008
mean?
The Guru was not a random CPU exception.
87000008 is a DOS alert corresponding to:
key already free
Now the investigation had moved decisively into filesystem territory.
Classic Amiga filesystems use block numbers as keys.
They also maintain an allocation bitmap recording which blocks are occupied and which are available.
So “key already free” can be read fairly literally:
DOS is trying to release or manipulate a block which its allocation data already says is free.
That was a remarkably specific clue.
Especially given the previous experiment.
A read-only disk worked.
A writable disk did not.
Time to ask the filesystem what it believed.
Asking the filesystem
The volume is an Amiga OFS filesystem:
DOS\0.
An Amiga double-density floppy contains 1760 blocks of 512 bytes.
The root block is conventionally placed in the middle:
1760 / 2 = 880So block 880 is the volume root.
Among other things, the filesystem root leads us to the allocation bitmap: the structure responsible for recording which disk blocks are free.
xdftool can look at the same filesystem from two useful
directions.
First, which blocks are actually referenced by files and directories?
$ xdftool battle_chess.adf bitmap node / all entries brief 0: .........D. ........... 880: V.......... ........... 1408: ........... .....HdHdHd 1430: dHdEEdddddd ddddddddddd 1452: ddddddddddd ddddddddddd ...
Here:
V = volume/root D = directory H = file header d = file data E = extension block
Clearly the disk contains a filesystem.
Clearly many blocks are occupied by files.
Then I asked the allocation bitmap which blocks were free:
$ xdftool battle_chess.adf bitmap free brief 0: ..FFFFFFFFF FFFFFFFFFFF 22: FFFFFFFFFFF FFFFFFFFFFF 44: FFFFFFFFFFF FFFFFFFFFFF ... 880: FFFFFFFFFFF FFFFFFFFFFF ... 1430: FFFFFFFFFFF FFFFFFFFFFF ...
Almost the whole disk was marked free.
Including blocks that the filesystem tree was actively using.
There it was.
A full disk convinced that it was empty
The filesystem said:
these blocks contain my files
The allocation bitmap said:
never heard of them
That contradiction explains the strange behaviour remarkably well.
Reading the disk did not require repairing the inconsistency.
The directory structure existed.
The file headers pointed to the correct data.
The icon files were readable.
Workbench could populate the window.
As long as the disk remained read-only, nobody had to reconcile the filesystem tree with the allocator’s version of reality.
But once writes were permitted, AmigaDOS eventually entered a path involving allocation bookkeeping.
At that point it encountered a block that the filesystem considered occupied while the bitmap already called it free.
And DOS complained, rather accurately:
KEY ALREADY FREE
Now all the experiments lined up:
Amiberry + write-protected disk -> works Amiberry + writable disk -> Guru real Amiga + write-protected disk -> works real Amiga + writable disk -> Guru
The machine did exactly what its metadata told it to do.
The metadata simply happened to contradict itself.
Greaseweazle and amitools: two layers of archaeology
One thing I particularly like about this case is how well the tools complemented each other.
Greaseweazle answers questions about the physical recording:
Can I read the disk reliably? What flux transitions are actually present? Can I preserve several revolutions? Can I return to the raw evidence later?
amitools answers questions about the filesystem constructed from that evidence:
What does AmigaDOS think this block is? Which blocks belong to a file? Where is the root block? Which blocks does the allocation bitmap call free?
Those are very different layers.
And keeping them separate is useful.
In this case the magnetic media was readable.
The logical file structures were readable.
The allocation metadata was wrong.
Greaseweazle gave confidence that the image represented the physical disk.
xdftool made it possible to interrogate what the
filesystem itself believed.
Together they turned a thirty-something-year-old floppy into something surprisingly close to a modern forensic exercise.
What broke the bitmap?
That part remains archaeology.
Possible explanations include:
- a badly mastered crack release;
- a copying tool that reproduced the filesystem contents without correctly rebuilding the allocation bitmap;
- an interrupted filesystem operation;
- virus activity;
- antivirus activity;
- deliberate construction of a disk expected always to remain write-protected;
- or some forgotten utility doing something perfectly reasonable by the standards of 1989.
The comparison with the online image is particularly interesting here.
My physical image and the online copy were almost identical in their actual filesystem contents.
The conspicuous difference was the boot block: mine contained the TRISTAR Viruskiller installation.
Yet both copies exhibited the same writable-disk failure.
That makes the antivirus boot block very poor evidence for the cause of the problem.
But excellent evidence for how easily an investigation can be distracted.
It was the duck.
Looks great. Lose the duck.
This investigation had no shortage of attractive suspects:
- old magnetic media,
- an emulator,
- different Kickstart revisions,
- cracked software,
- a strange startup utility,
- an antivirus boot block,
- the SCA virus,
- possible resident malware.
Some were reasonable hypotheses.
Some were historically fascinating.
One of them literally contained the word:
VIRUS
And none was responsible for the crash.
The actual problem was much quieter:
filesystem tree: these blocks contain my files allocation bitmap: those blocks are free
For decades that contradiction could remain harmless as long as the disk stayed write-protected.
Nobody asked the filesystem to reconcile the two stories.
The moment we did, AmigaDOS answered with surprising precision:
KEY ALREADY FREE
Battle Chess had already provided the appropriate debugging lesson.
When something conspicuous is absorbing all the attention:
Looks great. Lose the duck. Check the bitmap.
