Add C64 GCR support
picosonic opened this issue · 17 comments
I've tested C64 GCR processing against the raw sample files, so examples for this should be added.
It would be good if the raw sample parser was able to detect any valid sector from FM/MFM/GCR.
I am creating GCR interpreter - currently works inputting from rfi files. Will look to incorporate into main code. I have many GCR examples - including some damaged and difficult disk reads.
Hi, thanks for your message. I would be very interested to see some of your rfi files which are encoded with GCR. I've only got access to a couple of C64 disks. I've added what I'd done so far on GCR to the project incase it's useful, but I know there is still more to do. Thanks
Any file sharing service which you can send a URL would be good. The files may well zip down too as there will be a lot of repetition in the timings even with the RLE coded data. Cheers
Okay, first two to get started (one has two passes), will look for other candidates.
Google docs shared files:
Disk 114
Background: Disk 114 (flip side) C64/1541 - read in a regular Newtronics HD 1.2M PC drive - used an extra piece of hardware (non-destructive) and code to do the flippy disk (it spawns a background process to generate the index signals).
My decoder registers 1 checksum error block, and 1 missing block (both on Track 1). I can read the couple BASIC programs on it.
Disk 141
Background: Disk 141 C64/1541 - same drive/hardware
BASIC programs (mine from circa 1984) - My decoder registers all block good - but only if you read both rfi files. I can read (petcat) all programs on the disk.
There's a catch (there's always a catch): The modified (simplified) hardware does not use inverters for the three inputs including /RDATA - this means it has an inverted signal. But as it uses a leading edge - it shouldn't be a problem - just to be aware.
For reference, this is the logical circuit I am using (modified inputs & force index for flippy disk - these require code changes)
(I don't have the extra in-line resistors to RDATA and TRK00 - which means some (other) program changing these to output and logic 1 will be bad)
I only use the INDEX line for estimating drive rotation speed and to try to synchronise the capture to the same point on the disk for each track. Although in practice the capture seems to start a little late, which is one of the reasons for capturing 3x rotations per track.
I did notice that your captured rfi files were half the resolution I normally use - was there a reason for this?
In my diagram the reason I mention the /INDEX read shouldn’t work is I effectively have a voltage halved (middle of two 220Rs) on read which puts it in the undefined range - but I can tell you it does detect the index perfectly.
The reason I asked about the capture resolution was that there were multiple times when the level change was only 1 sample wide. So there is a danger that a level change could be missed and you'd end up with corruption.
I've run the disk images you linked to through my rudimentary GCR processor and have been able to extract the following (given a standard C64 disk is 683 sectors) :
disk141-drive0-525-a1.rfi
638 sectors ~ 93%
disk141-drive0-525-b1.rfi
79 sectors ~ 11%
disk114f-drive0-525-a1.rfi
173 sectors ~ 25%
These are extracted using an "ideal" bit window with not much variance allowed for. I need to improve the PLL sync code to increase the reliability.
I did notice the RPM was different between disk114 (340) and disk141 (300) which I assume is down to your use of the faked INDEX since most 5.25 inch drives used 300 RPM such that a data rate of 250kHz allows for up to 7958 flux transitions per radian.
I physically changed the drive speed (found a place to put a jumper that changed it from 360 to 300). But true, it may have been the fake INDEX.
I will try to "productionise" code for the GCR decode - will try to see what minimal changes can be made to improve the read rate. With my prototype method, 114 dropped only 1 block, the other all good. But it does multiple passes. I want to get this to one pass (yes PLL sync may be the way).
It'd be useful to see your method of data recovery / data separation. I have done some work on software PLL instead of just using a timings to bits translater using ideal bit cell sizing with a small margin for error.
However this has not made it into my repo yet as occasionally it misses sectors which the current method finds.
I've also got some proof of concept code for doing a directory listing of C64 disks when detected and -c is used on the comman line, so I'll need to put that in at some point too.
Still need to get to a shareable state - still working on speed and accuracy - but I'm sharing files as is for the moment:
https://github.com/paulrho/gcr-decode-exp
Thanks, I'll take a look