| |
Mantiz
Account closed
Registered: Apr 2006
Posts: 36 |
Decrunching from ram with Exomizer 1.1.5
Howdy!
I have tried to study the tutorial for quite a long time how to decrunch and run a file from ram with Exomizer, and I've reached a point where I just about have had enough. I just don't get it. The docs and decruncher sources are like hebrew with a lot of text but makes very little sense to me. Implement a get_byte routine? zp_len_lo? I admit I have always had difficulties to understand other peoples code most of the time so that could be a big part of the problem I'm having. Okay okay, I've had problems understanding my own code too but that's another story :)
I've got a file which I have crunched with the -l parameter and put it at $9000. At some point in a demopart (like pressing space or whatever), I would like to call the decruncher to work on that data and the execute the results. I understand I have to put the decruncher in a safe area which won't be overwritten. The uncrunched data will fit between ~0800-~8000 something. But how to feed the decruncher with the location and range of the data that it should decrunch and where the results should go? And how do I get the thing to cooperate? :)
Many thanks,
Mantiz |
|
| |
Mace
Registered: May 2002
Posts: 1799 |
Did you check the source code?
; zero page addresses used
; -------------------------------------------------------------------
exod_zp_len_lo = $a7
exod_zp_src_lo = $ae
exod_zp_src_hi = exod_zp_src_lo + 1
exod_zp_bits_hi = $fc
exod_zp_bitbuf = $fd
exod_zp_dest_lo = exod_zp_bitbuf + 1 ; dest addr lo
exod_zp_dest_hi = exod_zp_bitbuf + 2 ; dest addr hi
exod_tabl_bi = exod_decrunch_table
exod_tabl_lo = exod_decrunch_table + 52
exod_tabl_hi = exod_decrunch_table + 104
This looks like you have to put the 'source' in $ae/$af and the destination in $fe/$ff. |
| |
Raf
Registered: Nov 2003
Posts: 343 |
now I don't remember how it all looked like exactly , but I used exo 1.1.5 in '69 positions' so you may have a look into source code I released - it works okay in the collection - I load packed music using fastload to $c100 or so and then I do memory-to-memory unpack (music is placed @ $1000)
However I remeber that one address in original depacker's soure has got reversed lo/hi nibble ;-) this confused me a lot when I started using exomizer.
www.vulture.c64.org |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
No, you don't have to put anything into the ZP variables, as src/dest addresses are contained within the crunched datastream. Just make sure you don't use those areas for something important you need preserved, and that there's enough space reserved for exod_decrunch_table (all 3 sub-tables are same size, so 156 bytes total). Isn't there a sample getbyte routine? Like..
getbyte:
lda $9000
inc getbyte+1
bne getbyte_ok
inc getbyte+2
getbyte_ok:
rts
So the idea is to return the next byte of datastream in A and you're not allowed to touch the carry flag.
I never remember though, if you should use the forward- or backward-crunching datastream, and if it has changed in new exomizers. In old versions it was backwards I think. But you can try both until it works :)
|
| |
Mantiz
Account closed
Registered: Apr 2006
Posts: 36 |
You guys are simply the best. I finally got it to work.
Mace: I had read the sourcecode but I didn't get much smarter from that. The zeropage adresses confused me a lot, I didn't understand they were handled automatically by the datastream so I got very frustrated since it crashed no matter how I'd set them up.
Raf: Very kind of you to share the whole source to the public. And I must tell you that even if my Polish could need some polishing (oh how funny I am), I really see that one day I need to learn to write more structured sources. The stuff I write ends up in a mess within the main file.
Cadaver, finally: You helped me understand my biggest error I made from the whole beginning. It was indeed a backwards crunched datafile you needed to make it work with no mysterious crashes.
I owe you all a big thank you.
/Mantiz |
