[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-02 20:53

Krill

Registered: Apr 2002
Posts: 2982

Yes, and soon you'll end up with an algorithm very similar to ByteBoozer and other LZ77 variants. Good speed, good pack results, often best combined loading+depack performance. :)

2013-04-02 21:18

Clarence

Registered: Mar 2004
Posts: 121

Cruzer, next time for a similar task, consider using Werner's LZWVL packer. If you need something fast, and with a better compression ratio than RLE, it is great I think: LZWVL

2013-04-02 21:36

HCL

Registered: Feb 2003
Posts: 728

..Ok, so it sounds like i should bring back that zero overhead read-loop with all illegals and release together with a new version of EoD? Then Cruzer has to promise to start using ByteBoozer, and we will all be happy :).

2013-04-02 21:40

Clarence

Registered: Mar 2004
Posts: 121

HCL, I think avoiding support for non C= brand drives is acceptable, then again I don't have any drives as such, so I might be biased. :D

2013-04-02 21:45

WVL

Registered: Mar 2002
Posts: 903

My 2 cents :

I see more profit in finding a way to read from disk and transfer to c64 at the same time. Should really have a go at that once.. :) prolly i'll quickly see why that isnt possible though..

Also have a look at Doynax's packer, my tests showed that it both compressed better + was faster in decompressing than Byteboozer (sorry David!)

2013-04-02 22:20

Cruzer

Registered: Dec 2001
Posts: 1048

Thanks for the tips on packers. LZWVL looks promising, at least from the lovely chart Werner did. If I get the time I would like to do a similar test for loading + decrunching combined, with different kinds of files, to see where which kind of compression should be used, and where it should be avoided. E.g. I doubt that it makes sense to pack code, unless it's mixed up with data or full of "align to next page" statements.

2013-04-03 05:24

Krill

Registered: Apr 2002
Posts: 2982

Quoting WVL

I see more profit in finding a way to read from disk and transfer to c64 at the same time. Should really have a go at that once.. :) prolly i'll quickly see why that isnt possible though..

It is very much possible. But it isn't suitable for IRQ-loading and very probably needs a disabled screen, too. Have a look at Mafiosino Trackloader (19x) which reads a track in two revolutions.

2013-04-03 05:29

Krill

Registered: Apr 2002
Posts: 2982

Quoting Cruzer

If I get the time I would like to do a similar test for loading + decrunching combined

Keep in mind that this involves actually adding the missing decompressors to a loader, as combined loading + decrunching involves decrunching between fetching sectors (hence it is faster than loading first and decrunching after).

2013-04-03 06:14

Krill

Registered: Apr 2002
Posts: 2982

Quoting Cruzer

E.g. I doubt that it makes sense to pack code, unless it's mixed up with data or full of "align to next page" statements.

My experience with packing code has shown that it can indeed be sensible to pack code by separating op-code stream and operand stream. For even better compression, make sure to actually add redundancy to the code (e.g., lda #$00:ldx #$00 is likely to pack better than lda #$00:tax in the end). However, it is not feasible to go to these lengths for anything bigger than 4K :)

2013-04-03 06:15

HCL

Registered: Feb 2003
Posts: 728

@WVL: Yes i know about Doynax's packer. It was based on ByteBoozer, at least from the beginning, and optimized from there in all (?) possible ways. I'm just honored by his work :). ..and again, transferring while reading is a no-go if you want to be interruptable, and i would not sacrifice that.