| |
Shadow
Account closed
Registered: Apr 2002
Posts: 355 |
Load first decrunch later or stream decrunch?
Work on my first attempt on an IRQ-loading demo continues. I am using Dreamload, and everything is working great.
However, some parts tend to be rather big and eat both diskspace and load time.
Obvious solution would of course be to compress the data.
As I see it, there should be two options.
1. Load entire compressed part, then decompress.
2. Load byte-by-byte and stream-decompress
At the moment I am leaning towards solution 1. To get this working, the unpacking must allow for overlapping between packed and unpacked data, since I don't have space for both obviously. But I guess a smart decompressor works 'in reverse' so to speak, so overlapping should not be a problem as long as unpacked data is larger than packed...
I have looked at Exomizer, and it seems like it does things that way, and the decompressor code is fairly compact, so it could be a way to go.
Option 2 I have not looked into as much. Dreamload does support a callback on byte-for-byte basis, so it should be possible I guess.
So, I ask all veterans in this field - how is it usually done? Any tips and general good ideas? |
|
... 59 posts hidden. Click here to view all posts....
|
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Yeah, that sounds kinda funny, JackAsser was babbeling about it also (non-soberly ;). But how do you avoid loading stuff that might belong to another phile!? You're wasting data for knowing that!?
Dunno, since we have all forgot about the interleave by now, what's the use of catching sectors!? ;).
Nevermind me dear chap! ;D |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
Perhaps sacrificing a byte or two in the track with a file ID or something?
Just guessing here. I'm not that deep into the mutual dynamics of loading-depacking dependencies. ;) |
| |
Trash
Registered: Jan 2002
Posts: 122 |
One byte for file-id, two bytes for destination in C-64 memory perhaps would do it? |
| |
TNT
Account closed
Registered: Oct 2004
Posts: 189 |
Three bits for file ID, five for offset inside current track. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
8 files should be enough for everyone ? |
| |
TNT
Account closed
Registered: Oct 2004
Posts: 189 |
Eight different files on a single track should be enough for everone who is not trying to break the loader deliberately. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
I'd rather use 2 bytes, than mess with the extra complexity&data needed to keep track of what track has what file ids for what files...
(edit: not to talk about the mess the only 5 bit offset means) |
| |
TNT
Account closed
Registered: Oct 2004
Posts: 189 |
lda sector_id
eor wanted_id
cmp #$20
bcs .skip
tax
lda track_address
adc offset_lo,x
sta sector_address
lda track_address+1
adc offset_hi,x
sta sector_address+1
wanted_id = full_8_bit_index<<5 so it's in top bits. Offset table is X*253 if you have normal T & S links. track_address updated when track changes.
I see very little extra complexity, data and mess :) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
nice one indeed. but it looks to me you'll end up this way having to store extra track/sector_id and track/file/offset tables, with the extra routines to handle them. Do you want to load those tables before starting to load a file, or keep it in memory? why not waste instead that extra 1 byte/sector ? |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
@hcl: Any idea where I might find the source for ByteBoozer's decruncher? In my tests it gets compression ratios in the same ballpark as Exomizer (which itself has a scary tendency to beat zip, gzip, bzip, and 7z on small files) and I'm in need of something with a better chance of keeping up with my new-and-improved loader.
I began disassembling the binary embedded in cruncher.c but gave up when it turned out to relocate itself to the zeropage, abusing the same word both as absolute addresses in instructions then reference them as indirect addresses as well..
By the way do common formatting utilities, and the 1541 ROM's implementation for that matter, line up the sectors nicely when changing tracks? That is when you've just finished reading the last sector on a track can you expect to see roughly the same sector number under the read head? After all just missing that new sector is in practice roughly equivalent to increasing the interleave by one. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
