Closed shattered closed 7 years ago
Yes, I do -- where do you want them?
Sending to <snip> would be great, thanks! Or a share link to any external service if they're >10MB, and if possible.
http://wikisend.com/download/838688/a-a3-07.scp.gz -- will expire in 7 days. contains RT-11 filesystem with a few games:
ACG1 .LZS 234 24-Feb-93
ACG2 .LZS 214 22-Feb-93
ACG3 .LZS 140
LIFE .LZS 24
PACMAN.LZS 51 24-Feb-93
STALK .LZS 86
TENNIS.LZS 20
TETRIS.LZS 39
UZ .SAV 15 26-Aug-92
XONIX .LZS 15
ZMEI .LZS 13
Thank You for the sample disk image. I downloaded it a few days ago, but I've only just found time to look at. A few follow-up questions:
I noticed the sample image only scans error-free with --scale=120, since the data rate is 300Kbps (typical for double-density in a 5.25" drive which spins at 360rpm). Is there a reason the track scanning code uses 250Kbps instead?
If real disks could be seen at 250Kbps and 300Kbps data rate, scan_bitstream() could test both and return whichever sectors were found on. That's what the PC MFM/FM formats do when detecting content. It could immediately reject any others that would never be seen, to save a little time.
If the MX track signature is relatively distinct, it may even be worth having it enabled by default, so the --mx isn't needed. The only reason Jupiter Ace needed --ace is that the disk system stopped writing track data at the end of the content, so there may be old PC sectors on the end of the track. If the DVK MX tracks are always written index to index, there's no similar risk.
I've made some of the above changes to my local version, but I've not done much testing yet. I wanted to run them by you to see if they made sense :)
Real floppy drives were 300 rpm. I guess checking two data rates wouldn't hurt.
MX is like Ace -- the driver can choose to stop writing at end of track. Some drivers do fill entire track, some don't.
I've found that converting MX images to .dsk doesn't work because sector.add() sets DAM to 0 -- 0xfb works much better :)
I.e. sector.add(std::move(block), cksum != stored_cksum, 0xfb);
Do you have any sample flux files for DVK MX? It'd be useful to include in testing, to help avoid regressions in future versions.