| |
ZIG
Registered: Feb 2004
Posts: 37 |
Another different Exomizer question...
Hey there folks. I am having some trouble with Exomizer in memory decrunch. Seems like it decrunchesm but never actually writes to the RAM it's meant to.
Let me explain...
1. For example, I have an exo compressed file as follows:
exomizer mem -l 49152 tune.prg,3840 -P0 -o packedtune.prg
with the intention to load the compressed data into $c000 and depack it into RAM from $0f00 (tune.prg actual start address is set to $0f00 but I am assuming this makes no difference)
2. I then use the exo depack source code https://bitbucket.org/magli143/exomizer/src/master/exodecrs/kic.. and add the following standard 'get next decrunched byte'
exod_get_crunched_byte:
lda opbase + 1
bne nowrap
dec opbase + 2
nowrap:
dec opbase + 1
// change the $ffff to point to the byte immediately following the last
// byte of the crunched file data (mem command)
opbase:
lda $ffff
sta $d020 //<-- I use this to see it working...
rts
...and yes, I also do what it says and use load address of the file + 1.
3. The compressed file loads into RAM from $c000 to $c42b, I set the 'opbase' to lda $c42c and then jsr exod_decrunch.
It seems to decrunch backwards as expected, however, it keeps going until it then crashes - when I check the value of 'opbase' it is lda $AF60! It should have stopped at $c000... Weirder still is that I look at the expected decompress address and it's untouched. Nothing is actually being uncompressed.
...does anyone have any ideas what is going on here?
Much appreciated! -Zig |
|
| |
spider-j
Registered: Oct 2004
Posts: 444 |
I don't know what you are trying to achieve with all those address parameters, but with normal PRG files (two byte header) it just works like this for me:
exomizer mem -l none -o $OUTFILE $INFILE
And then include $OUTFILE at *= $C000 in the source. |
| |
ZIG
Registered: Feb 2004
Posts: 37 |
Ah, I tried what you had recommended. Had the same issues as now and I have taken the recommendations from https://codebase64.org/doku.php?id=base:exomizer_level_compress.. using the parameters I have in my example. Either way I seem to get the same issues. |
| |
Krill
Registered: Apr 2002
Posts: |
Quoting ZIG // change the $ffff to point to the byte immediately following the last
// byte of the crunched file data (mem command) I also do what it says and use load address of the file + 1.
You mean end address of the file (which already is one byte beyond the last crunched byte)? If yes, then i guess you're still off by one.
Make sure that the first byte returned by exod_get_crunched_byte really is the last byte of the crunched file. Notice that the last two bytes of the crunched file are the starting address to write the decrunched data to, which is the last unpacked byte. |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Quoting ZIG[...]
2. I then use the exo depack source code https://bitbucket.org/magli143/exomizer/src/master/exodecrs/kic.. and add the following standard 'get next decrunched byte'
exod_get_crunched_byte:
These terms 'get next decrunched byte' and exod_get_crunched_byte are a bit confusing, but your additional lines of code are meant to be a get_byte-routine that fetches an unpacked byte which is ready to be stored at its destination adress - right?
Quoting ZIG
lda opbase + 1
bne nowrap
dec opbase + 2
nowrap:
dec opbase + 1
// change the $ffff to point to the byte immediately following the last
// byte of the crunched file data (mem command)
opbase:
lda $ffff
sta $d020 //<-- I use this to see it working...
rts
...and yes, I also do what it says and use load address of the file + 1.
[...]
Just wondering if the routine should really just get the unpacked byte into accu or if it actually has to do the write to the dest adress, i.e. if a STA $0f00 (plus the necessary INC/DEC handling) is missing here... |
| |
Krill
Registered: Apr 2002
Posts: |
Quoting CopyfaultJust wondering if the routine should really just get the unpacked byte into accu or if it actually has to do the write to the dest adress, i.e. if a STA $0f00 (plus the necessary INC/DEC handling) is missing here... It's really just a routine to retrieve the next byte in the crunched stream. If it were also writing data, you'd have some weird memcopy for crunched data. =) |
| |
ZIG
Registered: Feb 2004
Posts: 37 |
Woohoo. ok, so combination of factors. Let me explain so if anyone else needs to face this issue they know what to do.
1. Exomizer mem decompress needs the developer to implement a 'get next crunched byte' function. This requires the address to be the byte after the last byte of the file loaded - because we decrunch backwards through memory. Code example:
lda $fe
sta opbase + 1
lda $ff
sta opbase + 2
jmp exod_decrunch
My IRQ loader would store the destination address to $fe/$ff - so I just need to pass this value to the decruncher. I had gone past one extra byte - this was my first mistake.
2. The second issue was actually following the instructions in Codebase64 - SpiderJ's recommendation to remove all the address parameters etc was correct as well.
Upon following the decrunch routine it became obvious the two things were at play - to figure it out, zero page is initialised in reverse from the data at the _end_ of the compressed file. This helped me identify the correct end byte of the file and helped me figure out how to treat the zero page values coming from the IRQ loader.
Anyway, that's it and now its working. Thanks everyone for chipping in your ideas!
Regards
Zig! |
| |
Krill
Registered: Apr 2002
Posts: |
IRQ-loading a file before decompressing it (rather than decompressing while loading) isn't very efficient, though. But then Exomizer itself is already one of the slowest (de-)crunchers, which you should only use if you really need the size. |
| |
ZIG
Registered: Feb 2004
Posts: 37 |
Thanks for that feedback Krill. I didn't want to use a framework, so I am currently using the IRQ loader from the old game called StreetGang that I ripped back in 1988 just for my own nostalgia. I then started reversing it here:
https://github.com/defame-demogroup/street_gang_loader
Just for fun...
Anyway, I have put together a bespoke pipeline that dynamically generates code for Kick Assembler that renders, compresses everything and generates the disk image.
So yeah, I will take on your advice and once I get a baseline of this program running, then I will look at changing the compression method to streaming in the Exomizer pipeline and modify the decompression to use forward streaming and integrate that into the loader routine. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 500 |
Framework is maybe a bit overdone as a definition, basically it is more like a bunch of very handy calls that nowadays loaders bring with them, to easily load or depack files. In fact, they might occupy even less memory that you need with a combination of your ripped loader + exomizer. But reinventing the wheel is fun and a good exercise, did so myself pretty often, and sometimes it leads to a new way to approach a problem, after starting from a naive view :-) |
