BASIC PL5 30.09.84, four times over
The one side in the set that is what it looks like. Four slots, one build, BASIC PL5 30.09.84 in every one of them, identical to the byte. It is also the fullest side in the archive: 996 of 1001 sectors carry something, and the only zeros are the five sectors at the end that four interpreter images do not reach.
- sectors in use
- 996 of 1001
- catalog entries
- 0
- file header sectors
- 0
- slots
- 4 x 63,744 bytes, at 0, 63744, 127488, 191232
- all four slots
- BASIC PL5 30.09.84, byte-identical
- entry vector
- 9006 9009 9007
- also on
- disk1side0, slot 0, same bytes
No picture. The same BASIC PL5 as the first side, written four times over, and no catalog. Nothing on the side is a program in the sense that anything here can start it.
The image, 256,256 bytes
Full to the edge
No catalog, no index header, no file header sector anywhere in the 1001 sectors. Four images of 63,744 bytes at the usual offsets account for 254,976 bytes, and the remaining 1,280 bytes, five sectors, are zero. That is the whole map of the side. 996 sectors non-zero is the highest count in the archive and it is not because anyone packed it well: it is because a firmware side has no free space by design. The interpreter is the medium's entire contents, written four times, and the arithmetic leaves no room for anything else.
The control case
This is the side that let a wrong idea survive. When I treated the four slots as four copies and majority-voted them, the vote here was harmless: four identical inputs, one identical output, no artifact, no invented date. It looked like proof that the method worked. It was proof of nothing except that this particular side happens to be uniform, and one side over, on disk1side0, the same method wrote out a program that never existed.
What the uniformity is genuinely good for is calibration. The PL5 image here matches slot 0 of disk1side0 byte for byte, across two different physical disks in the same 2016 dump. So when the slots on the other boot sides differ by hundreds or thousands of bytes, that difference is content. It is not the drive, and it is not the read.
Where the bytes come from
The archive is 880.rar, published on oldpc.su by the forum user vazman, who owned the physical disks. dk_spb read them and made the images. The thread is on phantom.sannata.org and dates from 2016. The download link is dead; the copy I work from came out of a Wayback snapshot from that year, and as far as I can establish it is the only one left anywhere. Neither of them owes me anything, and both of them are the reason any of this exists.
What I checked
Four extractions, one file. The four slots come out identical to each other and identical to the PL5 image on disk1side0, 63,744 bytes each, and firmware_extract.py writes them as a single build under its real date.
What this does not show
Why a side would carry one build four times is not established. A factory duplication, a deliberate local backup, and a writing routine that fills every slot by default would all leave exactly these bytes behind, and the images do not separate them. PL5 itself is unplaced too: it shares its entry vector and its keyword table offset with the BASIC 02 family, and its date, 30.09.84, falls between the 22.04.84 and 10.10.84 builds, but whether it is a variant of that line or a line of its own is not something this side can answer.
Where to read more
- The post that put these disks online dk_spb on 24 June 2016, one line with the link and a thank you to vazman for the disks, reachable now only as a snapshot.
- 880.rar 301,403 bytes of archive holding all six sides. The address on oldpc.su has been dead for years, and this snapshot from August 2016 is the copy I work from.
- How the images come off a side The tool that lifts the four slots out of a boot side and compares them byte for byte, which is what makes this side the control case.
- The boot sides The three of them measured against each other, and the correction that took the word copies out of it.
I wrote about this at the time
