Add C64 GCR support #10
Comments
|
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 |
|
Can do. What's the best way to share these with you? ~10MB each, and I
have some very questionable disks (1984 era) so I have 4 or 5 scans for
each.
My code then combines them to try and find a good version of each block
(checksum is simple, and only one byte - so it can sometimes get a false
good read on a block).
I'll find the best read and then a border line one (which still eventually
reads good). So around 50MB
Paul S.
…On Mon, Mar 4, 2019 at 7:19 PM Jasper Renow-Clarke ***@***.***> wrote:
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
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#10 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAxsE7hKlO1DXf_EppgeCGUMbAALFwSPks5vTOU7gaJpZM4TGnRI>
.
|
|
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. 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). Disk 141 Background: Disk 141 C64/1541 - same drive/hardware 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 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? |
|
The “force index” is to trick the (non C64) drive into allowing it to be a flippy disk. Without it the drive simply stops producing any output (even though it spins). The added code just forks and pulls the line for 5ms at 300rpm. I connect to the top side of the photodiode - it means I don’t need to break tracks on the drive nor rig up other mechanisms.
Using 64 (instead of 32) for C64 disks was just a result of earlier experimenting with GCR decoding success rates. I seemed to get slightly higher good block reads - but I do not have factual evidence of this. For IBM 1.44 3.5s I use 16.
I may have some C64s read at 32.
Paul S
…Sent from my iPhone
On 6 Mar 2019, at 01:56, Jasper Renow-Clarke ***@***.***> wrote:
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?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
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 disk141-drive0-525-b1.rfi disk114f-drive0-525-a1.rfi 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. |
|
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. |
|
Am still fine tuning but getting closer - I want to refactor the code (then regression test it) then I will gitify it as a stand-alone bolt on, to enable reference / share.
Latest incarnation is closer to one pass (with a single pre-pass to determine bucket sizes)
But interestingly it is tripping up on things earlier versions didn’t, still tweaking.
The key is in the bucket edges.
Theoretically, for any given track, if you get told the correct bucket edges (perhaps determined by trial and error) you can get a 100% read. This is what I’m tuning.
…Sent from my iPhone
On 12 Mar 2019, at 02:18, Jasper Renow-Clarke ***@***.***> wrote:
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.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Still need to get to a shareable state - still working on speed and accuracy - but I'm sharing files as is for the moment: |
|
Thanks, I'll take a look |
|
It’s far from consumable yet.
Debug is switched off (compile time) change the #define and extremely verbose debugging is generated
It also makes pictures of data (for debugging ) with the right options set in ripit1
…Sent from my iPhone
On 14 Mar 2019, at 23:38, Jasper Renow-Clarke ***@***.***> wrote:
Thanks, I'll take a look
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
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.
The text was updated successfully, but these errors were encountered: