| |
cadaver
Registered: Feb 2002
Posts: 1153 |
Exomizer on-the-fly loading/decompressing
Hey,
anyone want to share, what is the lowest disk interleave you've managed to use with on-the-fly Exomizer decompression while loading?
I'm currently at 11, using 2-bit transfer and a lame drivecode (using jobcodes only) + 1 sector buffering. However I don't think the drivecode is the problem; if I try to decrease to IL 10 the C64 often doesn't have to wait for the drive at all for the next sector's data, but occasionally the depack will take too long, resulting in missed revolution.
I've already done some optimization to the depack routine, including inlining getting a single bit (literal/sequence decision, and reading the gamma).
Don't think I would switch to another packer just for speed, but nevertheless interested in any battle stories. |
|
... 23 posts hidden. Click here to view all posts....
|
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
in my world, exomizer is too slow to be used in constant-loading production, so i never would.
with some buffering, the problem is solved, instead complicated code to make it "real time".
no ? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
cadaver: make sure to also use 40 tracks then :) |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
make that 41 + kabuto's encoding scheme... ;) |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
Minor update to this subject: dug up ideas to speed up drive->c64 sector transfer (for example Newcomer has a nice near-optimal transfer routine, and V-Max games like Rocket Ranger transfer multiple bytes per sync). Could get below interleave 10 that way. Custom decode in drivecode still wasn't necessary, as Exomizer (and potential slowing conditions like sprites) are still the bottleneck, but when the transfer is tuned for speed, it can be hard for drive to keep up, so I used a 256-byte table for speeding up the high nybble transfer. If custom GCR decode leaves high & low nybble in separate buffers, then it's probably also going to be fast enough without a large table. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
I'm still not sure whether you're going up the right alley. Why is decoupling block download and decompression using out-of-order loading and in-place depacking between the arrival of new blocks not an option, again?
You'd combine good pack ratio and as-quick-as-possible loading times while being able to independently tune the serial transfer protocol. The sub-files must be split up into separate files, then, but the overhead should be negligible.
But another thing: I've considered patching Exomizer (and other compressors) to get rid of the "safety offset", i.e., the handful of clobbered bytes beyond the unpacked data after depacking in-place.
That is, ensure that the write (decompressed data) pointer always points to memory before the read (downloaded blocks, packed data) pointer. This requires picking different (possibly less efficient) packed representations of data, but this might not be required so often and may be relevant only when crossing block boundaries. Having looked at Exomizer more recently than i, do you think this is possible? |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
I could examine the in-place depacking, but I'm not sure if it will work due to the safety offset requirement. For example, assume that rest of the memory is used by code, level data and graphics, and thus can't be clobbered, and I need to load & depack new music into a 2KB buffer. In worst case the music module will utilize the full 2KB. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
But with Exomizer, this is really just a few bytes, like 3. Surely you can work around that? :) |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
True :)
Another matter though is, that I like to keep just one copy of drivecode which I modify for 1581 & other drives, to keep the bootpart size low. The 1541-specific out-of-order scanning & possible custom decode would necessitate a whole 1541-specific second drivecode and would make the bootpart larger.
Anyway, this is already quite specific to my requirements, and in general I'm already happy with loading speed, though in theory I'm operating a technically substandard loader. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
You can let the drives get their custom drive code directly from the disk rather than the roundabout way of loading drive-specific code into C-64 RAM, then write just a part of it back to the drive in question. This will make the boot part smaller than it is now, too. |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
Good point, naturally the different drivecodes still exist as part of total data (which can mean few blocks less free for game data) but the initial boot-up time can be reduced that way, as I currently have quite a M-W + M-R + M-E monstrosity going on for the drive type detection on the C64 side :) |
| Previous - 1 | 2 | 3 | 4 - Next |
