| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
Pack chunks and depack anywhere EXOMIZER
I have a question about the exomizer. In my demo part there's a lot of empty bytes between specific parts. For example, my code starts at $0801 and ends at about 2500, my music is at 2700, then i put stuff in the vic bank $4000, inside the bank i skip forward to $5000 to load bitmap etc...
Of course exomizer is quite good at packing this anyway, since it's just zeros, but I'm sure it can be better. I could put all my data back to back, compress that, extract and then copy it where I want it, but I'm sure there's an option to pack the stuff separatelly and just extract it to a specific address. The question is, how do you do it ? I can't find any exomizer tutorials or documentation except on how to do a basic sfx program.
This is what I'm looking for more or less
*=0801
; the addres of packed stuff
; and destination on some ZP addr
lda #<packed_for_0x1000
sta $10
lda #>packed_for_0x1000
sta $11
lda #$00
sta $12
lda #$10
sta $13
jsr depacker
; depack next stuff
lda #<packed_for_0x4000
sta $10
lda #>packed_for_0x4000
sta $11
lda #$00
sta $12
lda #$40
sta $13
jsr depacker
; depack next stuff
lda #<packed_for_0x6000
sta $10
lda #>packed_for_0x6000
sta $11
lda #$00
sta $12
lda #$60
sta $13
jsr depacker
depacker:
!binary depacker.bin
;-------
packed_for_0x1000:
!binary some_stuff_for_0x1000.bin
packed_for_0x4000:
!binary some_stuff_for_0x4000.bin
packed_for_0x6000:
!binary some_stuff_for_0x6000.bin
....
|
|
... 8 posts hidden. Click here to view all posts....
|
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Quoting Groepazno point Quoting iAN CooGwhy even bothering? To save time by not zerofilling areas that don't need to be zerofilled? |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Yeah, if it's OK that a specific compressed chunk is always depacked to the same address, then disregard my advice on the modification and stripping, and follow just the advice on the mem command (as given by others). I just took literally the requirement to specify the destination address in code at runtime. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Quoting CruzerQuoting Groepazno point Quoting iAN CooGwhy even bothering? To save time by not zerofilling areas that don't need to be zerofilled?
Decrunching slabs of memory and moving them around will take more time and memory than just zero-filling gaps. |
| |
Zirias
Registered: Jan 2014
Posts: 48 |
Quoting Compyxmoving them around
Uhm, just because you can waste even more time? |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
I don't want to move the memory around, that's why I didn't want to put all data back to back, pack it, depack and then move it, but pack chunks and depack them to the desired destination. Calling the packer (5-6 instructions) is prolly faster than filling a page with zeros (sometimes even more) |
| |
Zirias
Registered: Jan 2014
Posts: 48 |
Quoting HughJassCalling the packer (5-6 instructions) is prolly faster than filling a page with zeros (sometimes even more)
Actually, you'd probably have to measure that to be sure. Exomizer "decrunch" will recalculate the decrunching table on every invocation, this takes time as well. But I agree there's a chance, just use something similar to the code I posted above to test it. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting HughJassCalling the packer (5-6 instructions) is prolly faster than filling a page with zeros (sometimes even more) You do realise that the decompressor executes instructions itself as well, and with a very high chance of being less optimal than a purpose-made zero-fill routine at that? :) |
| |
Zirias
Registered: Jan 2014
Posts: 48 |
Krill, this was about zero-filling as a side effect of decrunching vs. calling the decruncher multiple times for individual chunks (and **not** zero-filling at all between them). |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting ZiriasKrill, this was about zero-filling as a side effect of decrunching vs. calling the decruncher multiple times for individual chunks (and **not** zero-filling at all between them). Alright, sorry then. But yes, calling a decruncher multiple times for several chunks adds not only table-building overhead, but also decreases overall pack ratio. The zero-filled areas themselves might not be filled that much slower than with a dedicated zero-fill routine, and in the multiple decrunch scenario, the decruncher would have to fetch more literals than copy sequences, with the former seeming a tad slower than the latter. |
| |
Zirias
Registered: Jan 2014
Posts: 48 |
Indeed, that's why I suggested to measure the individual case in order to be sure ;) That is, *if* you want to optimize the total decrunching time.
Another option might be to use a stream decruncher and implement the logic for skipping areas yourself, but that's probably just over the top. |
| Previous - 1 | 2 - Next |
