Inconsistent adherence to config file parameters (e.g. number of tracks)

[cube1us]

I have a little script for my Micropolis drive which is set up to capture an image file, and also a copy of the flux in one command, to minimize wear and tear on the disks I am archiving.

But, oddly, it doesn't seem to always pay attention to the number of tracks.

A sample of the command I am using is:

D:\Download\Fluxengine\fluxengine read micropolis config.micropModI -o disk33-CPMBackups.img --copy-flux-to disk33-CPMBackups.flux --flux_source.drive.revolutions=3.5 1>disk33-CPMBackups.log

Sometimes this works right, sometimes not. this one read 77 tracks instead of the expected 34. And it couldn't decode the data - as though it ignored the config file entirely.

The config file config.micropModI reads:

decoder { micropolis { } } cylinders { start: 0 end: 34 } heads { start: 0 end: 0 } comment: "Micropolis Mod I MetaFloppy 143KB 5.25\" SSDD hard-sectored (ro)" image_writer { filename: "micropolis.img" img { } } flux_source { drive { drive: 0 hard_sector_count: 16 } } flux_sink { drive { drive: 0 } }

Log fiile attached.

disk33-CPMBackups.log

[cube1us]

Update. For a little while I thought I ,ogjt know what was behind this. In my script I have a number of seek commands (multiple to ensure the drive actually gets home):

%fluxdir%\fluxengine seek config.micropModI -c 0 %fluxdir%\fluxengine seek config.micropModI -c 0 %fluxdir%\fluxengine seek config.micropModI -c 0

These had been miscoded to config.micropModII (a 77 track drive).

Instead, it seems to be getting confused by this particular flux pattern (attached)

disk33-Flux.zip

[cube1us]

Ah, now I DO know what is going on. I had not realized this was a MOD II disk, so fluxengine was picking up high track numbers - and struggling with the disk because it was essentially reading two tracks at once. (It might be good to have it issue a warning when it sees track numbers outside the range in the config, though. ;) )

[cube1us]

The above was partly right. However, I also see that fluxengine will create sector images beyond the config'd tracks when it has trouble decoding sector headers. See attached. This was from a disk known to be Mod I, 35 tracks.

disk23.zip

[davidgiven]

Ah, yes, that'll do it. If you tell the image_writer the geometry of your output image it should discard out-of-range sectors. Otherwise it'll guess the geometry based on the sectors it's seen, so a bad sector with a high track or sector number will cause Bad Things™ to happen.

What's a Mod I / Mod II disk?

[cube1us]

Mod I 48 TPI, 35 Tracks, 143KB Mod II 100 TPI, 77 Tracks, 315KB

[davidgiven]

Sorry for the delay in response; working on other projects... this probably needs multiple Micropolis configs, for each disk variant. This should avoid the problem you were seeing earlier. If you've got anything which works, send me a PR please? I'll have to take your word for it as I can't test Micropolis hardware!

[cube1us]

I had two different configs, one for the Mod I and one for the Mod II, the difference being the number of tracks.