Micropolis hard sector support

[keirf]

This ticket is to track landing the new feature, on branch micropolis, into master with appropriate options, names and features.

[keirf]

The latest build is: https://github.com/keirf/greaseweazle/actions/runs/11142350338

When logged in to GitHub you can see Artifact links for win32 and win64 builds at the bottom of the page.

In use, something like:

gw convert --format=micropolis.100tpi.ss Disk59.scp Disk59.img

Currently the formats are called micropolis.{48,100}tpi.{ss,ds}[.275]. This is a cryptic way of saying that formats support 48- and 100-tpi drives (35 vs 77 tracks), single and double sided (DS is untested), and 256 vs 275 bytes in the IMG file.

The only checksum supported is the Micropolis default, and ECC is ignored in dumped tracks and not generated in new tracks.

Any comments on performance, naming, or feature requests please fire away!

[GrahamLCV]

Being entirely selfish it would be great if the terminology was the same as fluxengine:

143: 143kB 5.25” SSDD hard-sectored; Micropolis MetaFloppy Mod I
287: 287kB 5.25” DSDD hard-sectored; Micropolis MetaFloppy Mod I
315: 315kB 5.25” SSDD hard-sectored; Micropolis MetaFloppy Mod II
630: 630kB 5.25” DSDD hard-sectored; Micropolis MetaFloppy Mod II

but it doesn't matter too much.

Fluxengine has options for sector size of 256 and 275 bytes. It calls the option VGI but i'm not sure why. 256 is all that's needed for cp/m. 275 is required for Micropolis DOS.

One thing that i haven't mentioned is that the micropolis drives have very long step time of 30ms with a settling time of 10ms. I haven't checked with the scope but i do often get track zero not asserted at the start of a read so i suspect the steps are coming too fast. It doesn't matter once the read starts. Maybe there's a setting but i couldn't see it.

[keirf]

The setting is gw delays --step=30000 to set a step delay of 30ms.

[keirf]

I'm kind of easy on the naming, it's simply done in a plain-text config file: https://github.com/keirf/greaseweazle/blob/micropolis/src/greaseweazle/data/diskdefs_micropolis.cfg

As you can see its just a case of picking a nice naming scheme. I would be happy to go by capacity (143, 287, 315, 630) but I wondered if tpi and sides was clearer here. Also I wasn't sure what to call the 275-byte sector versions, hence taking 275 on the end.

So if you have a really bright idea here, we can go with that.

[GrahamLCV]

Awesome, thank you. I'm more than ok with what you're doing. I'm down in Aus - not sure where you are - but if i'm quiet probably just means i'm sleeping.

[keirf]

No problem. I will leave this open so you can report results of any testing. If you can report further successes I will get the btranch merged into master for next tools release.

[GrahamLCV]

I've tried a couple of disks, one cp/m, one mdos, reading and writing - and it's working great! The IMG files are identical to the ones from flux engine and the sorcerer is swallowing them. I can see gw retrying from time to time during both reads and writes which is what i'd expect. I found that flux engine produced better results (less retries with poorer disks/drives) if i could tweak the bit error threshold: --decoder.bit_error_threshold=0.5 . Is there a similar option in gw?

[keirf]

In GW you can adjust the PLL parameters directly. Probably you have some high frequency noise in your read and you need an even more conservative PLL setting to filter that out. You could try --pll=period=1:phase=3. In general period values in the range 1-10, and phase values as high as 60 can be interesting. The higher you go, the more "jittery" and "aggressive" is the PLL, which can then be thrown off by jittery marginal reads.

[GrahamLCV]

All of my drives were probably created equal but they are no longer equal. My third drive, which is a single unit, is not playing nicely. There is a subtle difference that causes it to be unhappy with gw. Curiously if i try to write with verification it has huge issues. If i write without verification and read back the disk it is good (with 0, 1, or 2 retries). Curiously the same disk (275) which appears good does not boot on the sorcerer. It's quite a lot more successful with a 256 byte/sector cpm disk. This drive works fine on the sorcerer and with disks made on this drive or with the other drives. Never short of a puzzle.

[GrahamLCV]

Definitely some marginal disks and a marginal drive. Unfortunately fresh hard sector disks are hard to find. With a good disk writing with verification is fine on all three drives. It remains a puzzle to me that 275 byte disks made on my third drive will not work properly on the other drives with the sorcerer. They read back fine on all drives with greaseweazle. I've scrutinised the fluxes but have not been able to see any difference between the fluxes read by the third drive compared to those read from the other two. Maybe one day the penny will drop. 256 byte disks seem to be ok. I think it was a similar deal with fluxengine so for now i'm going to let it go. I think your feature addition is very usable!

[keirf]

Thanks! The feature is now committed to master.