I wrote: > So what needs to happen is: > > - libdsk's dg_opusgeom() needs to get more discriminating, at the > very least, so it doesn't misfire on disc images like yours (but I > don't know enough about the Opus Discovery to speculate how); > > - maybe libdsk could usefully learn about TIM 011 boot sectors > specifically, especially if they have geometry information embedded > in them. (Again, I know nothing about these; do you know of docs/ > people who might know more? Ideally English-language, but > understand if not.) > But this isn't strictly necessary; if none of the boot sector > heuristics misfire, libdsk's dsk_defgetgeom() should return an > inoffensive default geometry that doesn't cause trouble. > > - probably cpmtools' device_libdsk.c:Device_setGeometry() needs to be > more thorough about sanitising DSK_GEOMETRY if it decides the > autodetected geometry was garbage.
Some more brain-dumping, mainly for the benefit of upstreams trying to fix this. tl;dr: I'm reasonably sure there isn't any geometry information directly included in the TIM-011 boot sector, so it's probably not worth libdsk learning to spot one. (This is all freelance research; I started knowing nothing about the TIM-011 or the SB-180 it's based on, and I'm sure you know a lot more, so apologies if I got it wrong or missed existing documentation.) I think: The boot ROM decides between three formats by issuing a READ ID command to the FDC, and looking at the length of the first sector it finds. It loads the first 1024 bytes off the disc into memory starting at 0x8000, and passes control to that, providing format info in the A register. (see https://github.com/msolajic/tim011-system-software/blob/main/bootrom.z80 and particularly DISKTYPE) >From disassembling the boot tracks (I didn't find existing disassembly/source), the first 128 bytes loads the first two tracks (total 10 kibyte) -- head 0 cyl 0 then head 1 cyl 0 -- and passes control to them. (I guess this is the CP/M / Z-system code.) This boot track is clearly designed to be used on discs of multiple geometries, since it tests for whether the boot ROM determined the disc had a 40-track format, and adjusts its own FDC parameters accordingly. (I don't know the provenance of the boot tracks in this image -- they're almost identical to https://bitbucket.org/zzarko/tim011-tools/src/master/empty.img -- or if there are different ones out there for this platform. I can provide my partial disassembly if it's of interest.) I think these are the three formats the boot ROM understands, in libdsk terms: FDC sec size 1 2 3 (or anything else) Description = Hitachi 40 trk 80 trk Secsize = 256 512 1024 Sectors = 16 10 5 Secbase = 1 17 17 Cylinders = ??? 40 80 Heads = 2 Sides = Alt Recmode = MFM (And the provided boot sector is able to cope with being on the latter two.) I've also tested that if I nobble dg_opusgeom() in libdsk to always return DSK_ERR_BADFMT, the original symptom goes away. I'll alert John Elliott (libdsk upstream) to this bug now.
