| |
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....
|
| |
Clarence
Registered: Mar 2004
Posts: 121 |
I would opt for the fastest possible demo friendly loader also, but maintaining compatibility with all the standard C= drives including the different 1571 versions. That illegal opcode incompatibility HCL mentions, sounds bitter already. :/ |
| |
raven
Account closed
Registered: Jan 2002
Posts: 137 |
From memory, I think there is only one (or two) drive clones that have a problem with illegal opcodes.
I used SAX and didn't lose any sleep about it ;)
Also, I remember only one complaint about it - from HCL!
I wonder how many people still use these drives.
HCL: which make/model is it exactly? |
| |
enthusi
Registered: May 2004
Posts: 677 |
Just make it load fast from SD and 1541u !!!1111
Just kidding :)
But then again, if some non 1541-drives fail, well, they fail. |
| |
algorithm
Registered: May 2002
Posts: 705 |
The bottleneck in most cases seem to be certain types of decompressors (for example with exomiser it almost takes the same amount of time to load and more) just to depack (even if depacking while loading)
Can't a quick CRC be done at the beginning of each linked part (once all data is loaded and decompressed?) Sure, this would not be a solid way of doing things - in particular if the crc checker at the beginning has load errors., but should be a mimimum issue
@krill. interested in your 50speed non-irq loader :-) |
| |
tlr
Registered: Sep 2003
Posts: 1791 |
Quoting algorithmCan't a quick CRC be done at the beginning of each linked part (once all data is loaded and decompressed?) Sure, this would not be a solid way of doing things - in particular if the crc checker at the beginning has load errors., but should be a mimimum issue
Is there any gain in doing a separate CRC step? Another drawback is that you won't detect partially corrupt T/S links.
|
| |
algorithm
Registered: May 2002
Posts: 705 |
Yes, the data check would be sub-optimal, but may have some type of gain. |
| |
HCL
Registered: Feb 2003
Posts: 728 |
@Raven: You are funny :). You want me to fix the EoD loader to work on your c128D, but you don't want to care about my disk drive. It's a digilog drive btw, already mentioned in another recent thread. |
| |
tlr
Registered: Sep 2003
Posts: 1791 |
@hcl: Maybe you can put your digilog drive in his C128D?
There, problem solved! |
| |
raven
Account closed
Registered: Jan 2002
Posts: 137 |
@HCL: I believe many people have a 1571 compared to a few with the digilog ;)
Anyway, I seem to remember an email from you saying you removed the SAX's and got the demo working on your drive :) |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Quoting enthusiJust make it load fast from SD and 1541u !!!1111 Almost agree, actually. If it works on 1541, it works on 1541u, Chameleon, etc. That should be enough for everyone. It's ofcuz nice if it works on other drives as well, but no need to sacrifice speed for that.
Quoting algorithmThe bottleneck in most cases seem to be certain types of decompressors Which is why I think that in most cases it's not even worth compressing the files. For Pimp My Snail I skipped it, and I think it worked pretty well. I just placed all code/data/gfx togehter in a tight lump, and "unpacked" it using custom routines that could be optimized for the specific data and speedcode. It might have helped a bit compressing some of the simple gfx though, in a lightweight way optimized for decrunching speed. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 16 - Next |
