davidgiven / fluxengine

PSOC5 floppy disk imaging interface
MIT License
357 stars 69 forks source link

Problem decoding C64 floppy #159

Closed dwillmore closed 4 years ago

dwillmore commented 4 years ago

I've recently started trying to recover a lot of the data from my old disc collection. I've got lots of IBM-PC media which all seems to work fine. I've got Apple ][ discs (haven't tried them). And plenty of C64/1541 media. The C64 is the first non-IBM media I'm attempting. I did a read of the disc with greaseweazle (because I have blue pills all over the place and it only takes a few dupont jumpers to make up the interface). After converting it to a flux formated file "convert scptoflux", I attempted to decode it "read c64" which gave a lot of errors so I thought maybe ripping with a PC style HD 5.25 drive might have been the issue, so I tried "read c64 --index-mode 2" and that made little difference.

Any advice on what to try next? 15_read.fluxengine.read.txt

davidgiven commented 4 years ago

Looking at the mapping between physical and logical tracks, I suspect this was read on the greaseweazle in double-stepping mode. The physical tracks in the file go from 0..39, rather than 0..79 as the fluxengine software expects. It's not a problem; just read with :t=0-39 and no x2. (That's why no data gets read on tracks 36 to 79 in your dump; those tracks are not present.)

That doesn't explain all the bad sectors, though. Can you tell me which version of the software you're using? The flux file format changed recently and it's possible that the scp importer doesn't work any more. I don't have anything that generates or uses scp files so the importer and exporter don't get a lot of exercise.

If you're comfortable sending me one of the scp or flux files, I can dig into them myself, too.

dwillmore commented 4 years ago

And here I was thinking I was being all helpful by only reading the even tracks. sigh That'll teach me to assume. I am rereading the disc with no special options. I'll pass that file through format conversion and retry.

I am using fluxengine-FluxEngine-Windows-client-version-389.

I don't know what's on the disc as it was given to me by a friend to try to read. If this next attempt fails, I'll send you the .scp file for you to look at. Not knowing what's on it, I don't feel comfortable just putting it up on github for the whole world to see. :) Who knows, might be love letters to his wife who's passed away.

This looks better: 18_read.fluxengine.read.txt

dwillmore commented 4 years ago

These are flippy discs, so I'm guessing I'll have to do the mod to the drive to add a Hall effect sensor index faker as it doesn't look like the c64 decode can decode the 'backwards' side of the disc from a doulble sided capture.

davidgiven commented 4 years ago

The fluxengine client normally uses 80-track physical numbering throughout, but of course it has no way of knowing the settings on the greaseweazle... but now I think of it, there might be an scp header field which specifies this? I actually have a blue pill, and should make my own greaseweazle to test this.

Disk 18 looks completely clean. You should be able to pass that disk image to an emulator or file extraction tool and get the files out. I assume the other disks still seem bad?

Re flippy disks: there's no reason why I couldn't simply reverse the flux image, but it's worse than that: the head on side 1 of a PC drive is in a physically different position to the head on side 0. It's offset by 8 tracks. So without modifying the capturing drive to allow the head to seek to track -8, you can't capture the back of a flippy disk using head 1.

There's a good writeup on doing the drive mod here: http://cowlark.com/fluxengine/doc/Index_sensor_mod_FDD_1.1.pdf

dwillmore commented 4 years ago

Oh, crud, yes, the head offset, I completely forgot that, sorry. Thanks for the link to the sensor mod. The drive has plenty of space for all the components I'll need, so it looks pretty trivial.

I'm numbering my reads, so 15 and 18 were of the same media, just different scanning parameters. So, yes, they scan perfectly now. Thank you! I wil close this issue.

I would recommend you build a GW just for fun if no other reason. :) The only caution I'll give you is that the diagram on the wiki for GW shows the wiring from the blue pill to the Male pin header--not the female drive cable. So, if you're sticking dupont wires into a cable, you have to flip it left to right. Makes sense if you want to make an adapter board, but it's very confusing if you want to physically build up the adapter from a blue pill and a cable. Optionally, cut the end off a cable and solder the wires directly into a blue pill (that hasn't had the headers installed). I'm going to make up another one that way. They're so cheap, it seems silly to keep moving the adapter from drive to drive, might as well make up one for each drive. Thank you for your help. I'm going to go open a different issue for the apple ][ issues I'm having. :(