Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > Exomizer on-the-fly loading/decompressing
2015-09-17 14:05
cadaver

Registered: Feb 2002
Posts: 1160
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....
 
2015-09-20 09:58
cadaver

Registered: Feb 2002
Posts: 1160
Krill: sure, the depacker cycle use measurement as I imagined would only be useful within a track, and only as long as the depack CPU time dominates.

In my case I need to minimize the loader/depacker resident code size so unfortunately that means multiple sector buffering and/or out-of-order loading are out of question for me.
2015-09-20 10:20
Krill

Registered: Apr 2002
Posts: 2980
Why are buffering multiple sectors and out-of-order loading out of the question for you?

The former is not a big issue, as the packed data can be stored at the end of the unpacked area, plus the safety margin to prevent unpacked data writes from happening before the packed data read on the same memory cell.

And out-of-order loading... i see no problem there at all, save maybe for some more resident code.

So the main downsides are a few bytes wasted for the safety margin at the end of each uncompressed file, and some resident code to handle ooo loading.

So why are those such big problems? :)
2015-09-20 10:24
Bitbreaker

Registered: Oct 2002
Posts: 508
Quoting cadaver

In my case I need to minimize the loader/depacker resident code size so unfortunately that means multiple sector buffering and/or out-of-order loading are out of question for me.


Regarding the size of the exomizer depacker (including tables) this would just be a small addition. Quite some of the out-of-order (and serialization) handling can be offloaded to the floppy, where you don't have much code yet, right?
2015-09-20 10:31
Krill

Registered: Apr 2002
Posts: 2980
Quoting Bitbreaker
Regarding the size of the exomizer depacker (including tables) this would just be a small addition.
Right, why does it have to be exomizer in the first place, which is neither fast nor small? :)
2015-09-20 10:56
cadaver

Registered: Feb 2002
Posts: 1160
My top priority is still the compression ratio, over loading speed or runtime size.

Also, I have cases where a file is not only a single packed stream, but might consist of..

- first subfile memory allocation info (3 unpacked bytes)
- first subfile packed stream
- second subfile..

in which case out-of-order loading would need to support reading those unpacked bytes in between the packed streams.

+ have to support also Kernal loading with preferably drop-in replacements for opening a file and reading a byte, without any mandatory buffering. In this case Exomizer's API allows the easiest replacement, though the performance is not optimal compared to e.g. Doynamite, which always reads from a buffer.
2015-09-20 11:52
Krill

Registered: Apr 2002
Posts: 2980
You don't want any of those pesky crackers come up with a shorter version, eh? :)

So yes, if 3 bytes shorter is what you want, and having the best pack ratio so far, then exomizer indeed.

The subfiles could be split into separate files for unpacked and ooo-loading. Then slap "IFFL"-style loading on top to make up for the block granularity overhead.

Kernal loading is not a problem, as ooo-loading and buffer-based depacking do not contradict it. My loader has Kernal load fallback and still supports ooo-loading and Doynax LZ.
2015-09-20 14:03
cadaver

Registered: Feb 2002
Posts: 1160
I'll stop when I reach 0 blocks free on the diskside, so using Exo allows to cram the most content in :)
2015-09-20 19:16
lft

Registered: Jul 2007
Posts: 369
Nah, you don't stop when you reach 0 blocks free. That's the starting point. From there on, you have to do some actual thinking about how to best represent each individual effect/level/whatever based on its content, to produce optimal input for the generic cruncher.

I admit I have limited experience of this for C64. For other platforms, though...
2015-09-20 19:50
cadaver

Registered: Feb 2002
Posts: 1160
In MW4, I remember shuffling some dialogue around to improve compression, as well as saving only one way facing sprites (generate the flipped ones at runtime after loading) quite late into the project, when I had hit 0 blocks. This time I'm already doing the sprite flipping from the start though.

But yeah, something like reordering tiles/chars in levels (or patterns in songs) has the potential to save some additional space, without changing anything functionally.
2015-09-21 07:15
Krill

Registered: Apr 2002
Posts: 2980
Why is adding another disk side not an option? :)

(Since you want Kernal loading as a fallback, denser custom formats and extended tracks are out of the question. Oh, and i guess you're using the directory track for storage already?)
Previous - 1 | 2 | 3 | 4 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
LordCrass
USID/The Guards; Tra..
Chrx/Design/Chaos
zscs
macx
Guests online: 96
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 Edge of Disgrace  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 No Listen  (9.6)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 Dawnfall V1.1  (9.5)
7 Rainbow Connection  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Triad  (9.3)
5 Censor Design  (9.3)
Top Organizers
1 Burglar  (9.9)
2 Sixx  (9.8)
3 hedning  (9.7)
4 Irata  (9.7)
5 Tim  (9.7)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.039 sec.