| |
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.... |
| |
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: 2839 |
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). |
Previous - 1 | 2 | 3 - Next |