DEVICE: GreaseWeazle 4.1
DRIVE: TEAC FD-55GFR
SUITE: FluxEngine (decoder.retries=3, drive.revolutions=1.2)
ARCHIVER: Lee Smallbone
ARCHIVED: 2026-04-20 13:00 (GMT/UTC)
NOTES:
Disk absolutely fine physically, and read perfectly first time with no retries.
Biggest issue has been the garbage BPB (BIOS Parameter Block) throwing off the X86WORLD Disk Library scanner to make this page
which I talk more about below, as well as the 'real' disk image refusing to mount in NetDrive for similar reasons.
The eventual successful read:
-----------------------------------------------------------------------------------------
PCPlus_Issue-64_Jan-1992.img
Fingerprint : 9290856dbe622da734e69417df9c1ac1…
Cache : BYPASSED (--rescan)
Filesystem : FAT12 (assumed — non-standard BPB)
Size : 360 KB (360KB 5.25" — IBM DOS 2.0 DS/DD)
Mounting : [mtools] mdir found=yes mcopy found=yes
[mtools] which mdir: /usr/bin/mdir
[mtools] PATH: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
[mtools] img_size: 368640
[mtools] Strategy A: patch BPB — total=720 spc=2 fat_size=2 root=112 media=0xfd
[mtools] BPB patched in temp copy /tmp/diskimg_C34tAI
[mtools] mount patched img: rc=0
[mtools] mounted ok, visible entries: 14
[mtools] Skipping garbled entry: 3f34c949424d2e332e33
[mtools] Skipping garbled entry: 061feb47023f072b2e7c3f3f
[mtools] Skipping garbled entry: 74183f777d3f6a2e323f3f
[mtools] Skipping garbled entry: 360b7c3f3ff33c7c2eed377c
[mtools] Skipping garbled entry: 063c7c7303e13c7c2e703f6e
[mtools] Skipping unreadable file: tem disk. or
[mtools] Skipping unreadable file: and stri.ke
[mtools] Skipping garbled entry: 0d0a4469736b20422e6f6f74
[mtools] Strategy A succeeded: 33 entries
OK (mtools) → extracted 28 file(s)
Files found : 28 (via mtools)
AV scan : ✓ Clean [ClamAV 1.4.3 / DB 27977 0.01s via clamdscan]
Cache : saved
----------------------------------------------------------------------------------------
The January 1992 PC Plus Superdisk (Issue 64) presented an unusual challenge during archival. Unlike the majority of disks in this collection, the image initially appeared to contain zero files despite the disk mounting correctly in VirtualBox and DOS reporting 28 files and several directories without complaint. The cause turned out to be a deliberately non-standard boot sector.
A standard DOS floppy boot sector contains a BIOS Parameter Block (BPB) at bytes 11–61 of the first sector — a small table describing the disk geometry: bytes per sector, sectors per cluster, number of FATs, root directory size, and so on. On this disk, those fields have been overwritten by executable bootstrap code. The first two bytes of the boot sector are EB 3C — a JMP SHORT instruction that jumps forward to offset 0x3E (byte 62), deliberately skipping the entire BPB region. The bytes that should contain geometry data instead contain fragments of a custom boot program: offset 11 contains 0x93, offset 12 0x00, offset 13 0xF0, and so on — values that make no sense as disk geometry (147 bytes per sector, 240 sectors per cluster, 55,438 sectors per FAT) but are perfectly valid 8086 machine code.
The OEM label field at bytes 3–10 reads MSDOS5.0 — almost certainly spoofed to make the disk appear to a casual inspection tool as a standard MS-DOS formatted disk, while the geometry fields behind it tell a different story entirely.
The technique was likely deliberate and served two purposes. First, it allowed the publisher to embed a custom boot experience — when a reader inserted the disk and powered on, the bootstrap code could display a welcome screen, run a menu, or launch the main program automatically, rather than showing the generic Non-system disk or disk error message. By writing code into the BPB area, the boot program gained an extra 51 bytes of executable space in the 512-byte boot sector, a meaningful amount in 1992. Second, it functioned as a rudimentary copy protection measure: most disk copying utilities of the era read the BPB to determine geometry before duplicating a disk. Presenting them with a fat_size of 55,438 sectors and 240 sectors per cluster would cause them to either refuse to copy, produce a garbled output, or generate a disk that appeared structurally corrupt to any tool that trusted the BPB.
On real hardware and in VirtualBox, this is invisible — DOS determines floppy geometry from the BIOS INT 13h drive controller interface and reads the media descriptor byte from the first byte of the FAT (0xFD, confirming a standard 360KB DS/DD disk), never needing to consult the BPB at all. On modern Linux, however, the loopback mount mechanism has no concept of a physical drive — it reads the BPB directly and trusts it unconditionally, resulting in a completely wrong filesystem interpretation and zero files found.
The recovery process involved writing a corrected 25-byte BPB into a temporary copy of the image — 02 00 (512 bytes/sector), 02 (2 sectors/cluster), 01 00 (1 reserved sector), 02 (2 FATs), 70 00 (112 root entries), D0 02 (720 total sectors), FD (media descriptor), 02 00 (2 sectors/FAT), 09 00 (9 sectors/track), 02 00 (2 heads) — leaving the bootstrap code, both FATs, the root directory, and all 28 files completely untouched. The corrected image mounted immediately, though the kernel's vfat driver also surfaced several phantom directory entries caused by the bootstrap code bytes being partially interpreted as directory records: one decoded as ?4IIBM.3.3 (a fragment of the IBM 3.3 bootstrap string from the overwritten area), others as sequences like 06 1F EB 47 02 3F 07 2B — raw x86 opcodes mistaken for 8.3 filenames. These were filtered out automatically, leaving the 28 genuine files intact and verified. This 'temporary' disk image was then used to populate the disk library, as mTCP NetDrive refused to mount the original for the same reasons!
----------------------------------------------------------------------------------------
Disk returned to original sleave for archiving.
