|  Post Your Message | |
| |
| | Previous Messages | Posted By
Mad
on 2021-01-27
22:01:22
|  Re: Decrunching from ROM help...
Great news! 
|
|
Posted By
crock
on 2021-01-27
14:54:04
 | Re: Decrunching from ROM help...
Thank you so much for the replies gentlemen. I will try and use exomizer and see if I can get it to work. I'll report back in a day or two...
Update 27/01
So after messing around for about 8 hours, I have got it to work! The first challenge was porting the decrunch source to 64tass, which wasn't too hard. Then, much harder for someone who has never had cause to look at decrunchers, was figuring out what all the compiler directives were to create the smallest code footprint, followed by how to then crunch the source data with the right options.
Thanks for all the pointers and suggestions!
|
|
Posted By
siz
on 2021-01-24
09:04:20
| Re: Decrunching from ROM help...
Just checked: Exomizer decruncher is not self-modifing code, so probably you can use that (I use it in my IOLib too). It requires some zero page addresses (8) and a 192 byte RAM buffer. You can compress your data with exomizer mem option and provide the memory reading reading routine (get_crunched_byte). The decompressor routine takes about $180 bytes of memory.
|
|
Posted By
Mad
on 2021-01-24
09:16:34
| Re: Decrunching from ROM help...
Biggest problem is most probably that almost all the decrunchers use selfmodifying code.. Perhaps someone knows one which doesn't..
Even if it is not a big help. You could write an own cruncher.. Mainly it's just replicating the last built memory or adding some literals.. I know it's not a big help, but here is the internal layout of a "stb" called compressor.. Seems like it has almost same performance like .tar packers.
The compressed stream is a sequence of the following tokens:
TYPE BYTE SEQUENCE
[dict] 00000100 yyyyyyyy yyyyyyyy yyyyyyyy xxxxxxxx xxxxxxxx
[END] 00000101 11111010
[dict] 00000110 yyyyyyyy yyyyyyyy yyyyyyyy xxxxxxxx
[literals] 00000111 zzzzzzzz zzzzzzzz
[literals] 00001zzz zzzzzzzz
[dict] 00010yyy yyyyyyyy yyyyyyyy xxxxxxxx xxxxxxxx
[dict] 00011yyy yyyyyyyy yyyyyyyy xxxxxxxx
[literals] 001zzzzz
[dict] 01yyyyyy yyyyyyyy xxxxxxxx
[dict] 1xxxxxxx yyyyyyyy
xxxxxxxx: match length - 1
yyyyyyyy: backwards distance - 1
zzzzzzzz: num literals - 1, followed by the literal bytes
Actually it seems the only thing you need to build a cruncher decruncher (lz77 like) is
a backwards distance and a match length.. And some tokens for literals..
Sorry for this senseless post crock, but personally I would try to just build a simple cruncher from zero in this case I think.. If there is some ROM cruncher already out there then this post here is nonsense of course..
edit: stb scheme is mostly for larger amounts of data. For 64k at least a better/simpler scheme would be needed.
|
|
Posted By
gerliczer
on 2021-01-24
06:45:48
| Re: Decrunching from ROM help...
If data is reasonably compressible then it may even be not that hard to generate, too. I think NinjaDRM or bubis could help you how to investigate that. They did this kind of thing in some products they were involved in, AFAIK.
However, I don't think Exomizer can't be made to create compressed data sitting in ROM with the corresponding decruncher. Decompression routine is part of the distribution and comes in source form. Unfortunately, that's not something I have actual experience with. But I'm quite sure, as a last resort, the author could give you some pointers. He listened to input of people from our scene and incorporated them in the product.
|
|
Posted By
crock
on 2021-01-24
05:27:08
| Decrunching from ROM help...
Hi Gents.
As I posted about last week, I'm in the process of a significant Diag264 update. As it runs from ROM, I am limited to less thank 16k. For the kernal version especially, you lose a couple of kb for the character bitmaps and pretty much everything above FC00, so I get about 13k of space, most of which is code, but I have a couple of use cases which need a few kb of data.
I suspect the data is reasonably compressible, so am wondering if any of the available crunchers out there can support the scenario of decrunching from a ROM address to a lower RAM address. The other limitations are that the decrunch code needs to be source, as it needs to be compiled and built as part of Diag264 and the Low-ROM and kernal versions obviously live at different locations. Also, there is no available kernal routines.
There is a mountain of information out there re: exomizer etc, but did not find what i needed so far. Any ideas from this wonderful community? - Rob
|
|
| |
Copyright © Plus/4 World Team, 2001-2024. Support Plus/4 World on Patreon |
