| |
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
....
|
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11101 |
no point, the few bytes you will gain will be eaten up by additional depack effort |
| |
iAN CooG
Registered: May 2002
Posts: 3132 |
If you move things around, why even bothering? Just let exomizer do its job, pack everything as a single prg. |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
Ok if you say so. But I'd like to know how to do this anyway in case I wanted to do let's say a single file demo with different effects. So I have let's say the depacker, 3 8kb binary blobs. How to depack them one after the other. (each packed part would have the call to the depacker in it, the depacker would be present in memory all the time) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1370 |
NuCrunch 0.1 does some of what you want; you give it a list of lists of .prgs, and each call to the decruncher unpacks a set of .prgs to their required locations.
But at the moment it doesn't do any checks for overwriting data it hasn't read from yet, and nor does it produce the final .prg for you; just a block of compressed data, and source for the decrunch routine that you need to assemble and put somewhere useful yourself. Adding a few of those is on my list of things to do Real Soon Now (hopefully sometime the next two to four weeks??); if nothing else I'd find them useful for my own productions.. |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
It's easier if you use forward mode. In that case, you can strip the first 2 bytes from the Exomizer output (which are the destination address, contained in the output itself) and modify the Exomizer decrunch routine to only read zp_bitbuf in the beginning, by changing the ldx #3 to ldx #1. Now you can write zp_dest_lo & zp_dest_hi with the destination address you wish, before calling the decrunch. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
arent level packers for this kind of shit ? |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
exomizer mem -q -l $0700 -o dest.exo src.prg
or
exomizer mem -q -l none -o dest.exo src.prg
You then need to have the emoxiser depack routine which in one of the folders with exomiser, to which you set the get byte address in the function and call depack. |
| |
Zirias
Registered: Jan 2014
Posts: 48 |
It's actually quite simple using the exomizer mem command, every crunched file will include the decrunching target address. I currently do something similar like this:
.import decrunch
.import start
.export get_crunched_byte
; BASIC PRG header
.word $0801
.word $080b
.word 2018
.byte $9e
.byte "2061",$0,$0,$0
; disable system IRQ
lda #$7f
sta $dc0d
lda $dc0d
; all RAM for the part going to D000
lda #$30
sta $01
jsr decrunch
; re-enable I/O area
lda #$35
sta $01
jsr decrunch
jsr decrunch
jsr decrunch
jsr decrunch
jmp start
get_crunched_byte:
lda _byte_lo
bne _byte_skip_hi
dec _byte_hi
_byte_skip_hi:
dec _byte_lo
_byte_lo = * + 1
_byte_hi = * + 2
lda end_of_data
rts
.incbin "part4000.exo"
.incbin "part5000.exo"
.incbin "part8000.exo"
.incbin "partc000.exo"
.incbin "partd000.exo"
end_of_data: .res 0
This is just slighly modified from original exomizer example code. Note that the last included binary will be unpacked first. |
| |
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: 1153 |
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: 2825 |
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: 2825 |
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. |
