Sector zero says BASIC PL5 30.09.84, and for a month I let that stand for the whole side. It is true of the first slot. The other three hold BASIC 01, a different interpreter with a different entry vector, and treating them as backup copies of the first cost me the most expensive mistake in this archive.
No picture. The side is a boot image with no catalog and no program file on it, four slots of the BASIC PL5 interpreter. An interpreter is processor code, and what runs here is the BASIC software on a disk, not the processor, so there is nothing on this side to start.
The image, 256,256 bytes
There is no catalog here. The entry scan runs across all 1001 sectors and finds nothing: no index header in sector 0, no sixteen-byte entries, and not one file header sector in the whole image. What sits there instead is four interpreter images of 63,744 bytes each, at byte 0, 63744, 127488 and 191232. Together they fill 254,976 of the 256,256 bytes on the side, and 979 sectors come back non-zero. A boot side is not storage with software on it. It is the state the machine is in after power-on, and the only reason there is any slack at all is that four images of that size stop five sectors short of the end. Those four offsets are not only my measurement, either. The 1987 Balasanian programming textbook says the interpreter takes 249 consecutive sectors and that version number 0 is written in sectors 0 to 248, version number 1 in sectors 249 to 497, and so on. At 256 bytes a sector that is byte 0, 63,744, 127,488 and 191,232, which is where I found them.
Slot 0 begins 9006 9009 9007, three little-endian words that are the cold start, warm start and test vectors. Slots 1 to 3 begin AD43 8092 ACFB, and their keyword table sits at byte 6604 instead of 6208, 396 bytes further in. The keyword list behind that pointer runs identical to the PL5 one for 637 bytes and then parts company. Two entry vectors, two layouts, one shared vocabulary that stops halfway. This is not one interpreter in four revisions, it is BASIC 01 in the builds 12.07.82, 27.12.82 and 15.12.81, sharing a side with PL5 from 30.09.84, and the slot order is not chronological either.
I had read the four slots as four writings of one image, and I majority-voted them into what I called an error-corrected master. On this side the vote lost outright. It carried BASIC 01 three times and wrote it out under the PL5 name, 58,587 of 63,744 bytes away from the real thing, and it carried a build date that never existed, because averaging four slots averages the date digits too. The correction is not a better vote. There was nothing to correct: every build is byte-identical wherever it occurs, and the slots simply hold different programs.
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. If you mirror my repository, mirror their names with it.
firmware_extract.py writes the four slots out by signature, one file per build. Slot 0 of this side is byte for byte the same PL5 image as all four slots of disk2side0, and every build recovered from the archive is 63,744 bytes and byte-identical wherever it repeats.
The BASIC-level emulator that runs the application disks never executes this image, and the CPU-level tool has only been pointed at the 22.04.84 build on disk1side1, not at PL5. The eight bytes after the eighteen-character signature are still unexplained. And where PL5 stands in relation to BASIC 01 and BASIC 02 is not settled: I have the dates and the vectors, not the lineage.
I wrote about this at the time