[CSDb] - User Forums - GCR decoding on the fly

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > GCR decoding on the fly

2013-03-31 12:46

lft

Registered: Jul 2007
Posts: 369

GCR decoding on the fly

Here's how to do it:

http://linusakesson.net/programming/gcr-decoding/index.php

... 149 posts hidden. Click here to view all posts....

2013-04-01 10:09

MagerValp

Registered: Dec 2001
Posts: 1078

Quoting Krill

You cannot transfer $fe bytes during the time a sector flies by, this is just barely possible with those $e0 bytes per sector schemes

So don't use the whole sector, only decode as much as you can transfer while the next sector flies by. You'd lose 20% but you can transfer a full track in two revolutions...

2013-04-01 11:03

Fungus

Registered: Sep 2002
Posts: 691

If you are ok with 20% data loss, might as well use a 3/4 encoding scheme like rapidlok which is much easier to decode, requiring only and'ing and or'ing.

2013-04-01 11:04

MagerValp

Registered: Dec 2001
Posts: 1078

Don't want to lose D64 compatibility though, but yeah, full sector and interleave 2 is probably more realistic.

2013-04-01 13:17

raven
Account closed

Registered: Jan 2002
Posts: 137

Fungus: combining the nybbles is what allows using the stack as decode buffer.
If you dont combine, you'll need to store each nybble separately, which means additional cycles in the read/decode loop.

I do agree about the overhead, but i think this seems like a necessary compromise in this case.

2013-04-01 14:41

Stone

Registered: Oct 2006
Posts: 172

Brilliant again, with easy to understand explanations. You are the Richard Feynman of C64 coding :)

2013-04-01 15:17

Ymgve

Registered: May 2002
Posts: 84

Eh, it's no Warp25.

(Just kidding, awesome work!)

2013-04-01 16:45

Mixer

Registered: Apr 2008
Posts: 455

Such things are the reason why I like the c-64 scene so much :)

But, how about writing to a disk? Is it doable in equally paced manner?

2013-04-01 17:00

Krill

Registered: Apr 2002
Posts: 2982

Quote: Quoting Krill
You cannot transfer $fe bytes during the time a sector flies by, this is just barely possible with those $e0 bytes per sector schemes

So don't use the whole sector, only decode as much as you can transfer while the next sector flies by. You'd lose 20% but you can transfer a full track in two revolutions...

You can still load a full GCR-encoded track in 2 revolutions. Just that the trick is somewhere else (and not applicable to IRQ loading). :)

2013-04-01 17:32

Krill

Registered: Apr 2002
Posts: 2982

Axis: The practical gain is somewhat of a mixed bag.

Generally, if you can decode a block while it's being read AND also do something smart with the checksumming, you save about one revolution per track. For reference: On 1541, my loader (v138) has (virtual) interleave 5, and on 1571 (2 Mhz) it's 4. (Plus a scan revolution, but that is another issue and will soon be optional.)

Lft's approach, however, moves the checksumming to the C-64, as the approach is still not fast enough to do that while reading as well. So there are two options now: Do a separate checksumming pass on the C-64 side (wastes valuable time for decompression), or modify the format on a high level (EOR all the bytes before saving, then EOR again during transfer), so checksumming basically comes for free with the transfer. The second option is more feasible speed-wise, but less so from a compatibility/useability standpoint, given that you save in a somewhat non-standard, albeit high-level D64-compatible, format.

Now, moving over the checksumming in a similar manner, pre-existing approaches (like in my loader) would shave off that one revolution as well.

So this is largely an academic problem in the context of IRQ loading.

Furthermore, Lft's approach does need quite a bit of memory in the very limited drive RAM, which i cannot afford due to a few architectural goals i'm not willing to sacrifice (ease of use and compatibility by loading via directory and filenames, support for non-1541 drives, disabled true drive emulation, etc. - Lft's system loads via a given set of tracks/sectors, limiting all that).
Since checksumming after transfer also solves another problem (flipped bits during transfer in heavy electrostatic environments like parties), chances are good i'll add such an option (which, as mentioned, will also have the same actual speed improvement). But then i always said there are a few more options to speed up things, yet nobody really ever needed it so far, seeming content with the speed as it is.

Bottom line: Limited practical gain, but awesome somebody finally made it after many have tried.

2013-04-01 17:43

Krill

Registered: Apr 2002
Posts: 2982

Quote: Quoting Krill
Cruzer: Was that sort of a challenge of who'd build the fastest IRQ loader now? :)
Yes please! :D

So will YOU need that speed? I have the vague feeling you're more the screen-off-non-IRQ-loading kind of guy, and for that... I do have two ideas on paper waiting to be tried out, both D64 compatible, giving 50x and 32x speed.