simonowen / samdisk

A portable disk image utility, specialising in copy-protected PC-compatible formats.
http://simonowen.com/samdisk
MIT License
86 stars 11 forks source link

Add support for DVK MX format and --scale option #1

Closed shattered closed 7 years ago

simonowen commented 7 years ago

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.

shattered commented 7 years ago

Yes, I do -- where do you want them?

simonowen commented 7 years ago

Sending to <snip> would be great, thanks! Or a share link to any external service if they're >10MB, and if possible.

shattered commented 7 years ago

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           
simonowen commented 7 years ago

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 :)

shattered commented 7 years ago

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);