Reading the USE 6800 floppy disk

I've finally had a look inside the first disk imaged from the LM Ericsson USE 6800. The programs turn out to be for the 6809, and the disk contains rather more than its directory admits to: alongside a small working filesystem, there are recoverable assembly sources carrying Håkan's name and dates from 1987 and 1988. Quite a good return from one floppy :)

Starting with the image

The disk is labelled HJRESERV #1, JOBBDISK (RESERV), FLEX 9.0. What I have here is a decoded raw sector image, not raw flux data. That means the magnetic transitions have already been turned into sector bytes. The filesystem is still there to investigate, but the image alone cannot tell us whether the original reader saw CRC errors or had to retry a difficult sector.

The first useful clue is its size: 733,184 bytes, which divides exactly into 2,864 sectors of 256 bytes. This fits the layout seen in the floppy imaging software: 10 sectors per side on track 0, then 18 per side on the remaining 79 tracks.

That unusual first track matters. Treating every track as 36 sectors would put the rest of the disk at the wrong offsets. For this image, the first data sector of track 1 is at byte 5,120, after the 20 sectors of track 0. From there each track occupies 9,216 bytes. Following the sector links confirms that this mapping makes sense.

The FLEX Advanced Programmer's Guide explains the next part. A data sector spends its first four bytes on a pointer to the next sector and a logical record number, leaving 252 bytes for the file. A file is therefore a chain to follow, rather than necessarily one continuous run of bytes. The directory has its own chain, beginning at track 0, sector 5.

Six files and a small surprise

The volume calls itself HJ-RESER, number 11, with a recorded date of January 18, 1988. Its live directory contains these files:

Every file chain reaches the end recorded in the directory, with the expected number of sectors and consecutive logical record numbers. There are 42 allocated data sectors and 1,362 on the free chain. Together they account for all 1,404 data sectors declared by the filesystem, with no overlaps or missing sectors. Those checks give me rather more confidence than a plausible-looking filename would on its own.

The surprise is that the filesystem only declares 40 tracks, numbered 0 to 39. The image contains 80. There is no need to choose one number and throw the other away: the first describes the filesystem's stated extent, and the second describes the image we actually have. There may have been an earlier disk layout, a later reinitialisation, or another part of the imaging history to untangle. The bytes don't establish which happened.

Is it 6800 or 6809 code

The label says FLEX 9.0, but labels can outlive their contents. The older file dates don't answer the question either. For that, we need to look at the instructions.

The boot loader gives us a particularly useful clue. At image offset $000C, after the initial branch, the bytes 1F 8B decode as TFR A,DP. That transfers accumulator A to the direct-page register, a 6809 feature. This is not a 6800 boot program with an optimistic label.

The operating system agrees. Its binary load records specify a transfer address of $C850, where the code begins:

C850  1A 50        ORCC  #$50
C852  10 CE C0 80  LDS   #$C080

The five utilities also decode consistently as 6809 programs. COPY starts its working code with an X-based clearing loop using LDX, CLR ,X and LEAX 1,X. DIR sets up a stack frame with LEAS -33,S and LEAU ,S, then uses a long subroutine branch. DELETE and LIST use the 6809's register-list stack instructions. Even the tiny RENAME program uses the 6809 encodings for loading X and writing a function code through it.

This needs a little more care than searching for a particular byte. Bytes can be instructions, operands, strings or data, and some opcodes mean different things on the two processors. In COPY's loop, for example, the 6809 LDX opcode would load the stack pointer on a 6800, and LEAX would no longer advance X. Looking at the instruction sequence and its entry path is what makes the identification useful. The instruction definitions can be checked against Motorola's MC6809 programming manual.

So the boot loader and all six live binary files target the 6809. That is an architecture identification from the code, not yet a successful boot test. The kernel contains the banner FLEX - Version 2.8:4 -; I've kept that exact string rather than trying to force it to match the disk label. It also contains machine-specific I/O code, which will need attention before trying to run it somewhere else.

The part the directory doesn't mention

The extra tracks aren't empty. Beyond track 39 there are 566 sectors with nonzero file payloads. Following their surviving links, while checking the logical record numbers, produces 53 complete text chains, covering 365 sectors. There are 52 distinct payload hashes, so at least one is a duplicate, and several others are different versions of related code. Another 18 candidate chains survive only in part.

These have no surviving entries in the live directory. I've given them names based on their starting track and sector, and kept their exact payload bytes alongside readable text copies. A NAM NUMREG statement inside a source file is a useful clue, but it doesn't prove that the original filename was NUMREG.TXT. Likewise, a complete sector chain isn't a promise that the program within it was finished.

There are routines for reading and decoding keys, rejecting contact bounce, talking to the terminal, initialising a PIA, and handling time. Several larger chains contain versions of NUMREG, described in their headers as an H-19 terminal version. Many headers carry hjoel and dates in late 1987 or early 1988. Håkan Joëlson, my former teacher and friend who gave me the machine, manuals and software, was using it as a student. Finding his source alongside his handwritten manual notes makes this feel considerably more like preserving somebody's working environment than collecting a few old utilities.

The sources provide another CPU check. 38 of the 53 complete chains contain explicit 6809 instructions or addressing forms, including PSHS, PULS, TFR, LEAX and auto-increment indexed operands. One string-output routine, for example, reads the next character with:

WRISTR  LDA     ,X+
        CMPA    #STRSTP
        BNE     GO
        RTS

The remaining 15 chains are mostly short routines that don't, by themselves, require those distinctive instructions. They fit the surrounding 6809 development material, but I wouldn't call a few shared instructions proof of a CPU target. Some source also names addresses such as $E004 and $E005 for the terminal ACIA, which agrees with the local USE 6809 address sheet appended to the annotated system manual.

Keeping the evidence

The recovery bundle contains the unchanged image, extracted files, readable source, sector-chain provenance, the CPU evidence and the small Python tools used to inspect it. The image's SHA-256 is:

09683af63fceb7e5ed0f5fba32f88ef56ac05b62016a1245545d5b4fada4a43d

I've also saved both TSC programmer's guides: the 6809 guide, apg09.pdf, and the 6800 guide, apg.pdf. The latter isn't a file found at the matching Setton URL, which returned 404; it is the 6800 Advanced Programmer's Manual from another location in the same archive, saved under that shorter name. Their prefaces explicitly identify the respective CPU versions.

The raw image has been left unchanged. The recovered source includes partial and possibly superseded versions, and the unexplained extra tracks deserve a closer look. But we can now read the live filesystem, identify its programs as 6809 code, and inspect a sizeable collection of Håkan's source. Next comes working out how much of that environment can be brought back to life. Preferably without the fire mentioned elsewhere on this site :)