search

picosonic / exomizer-3.1.0

Demo of using exomizer v3.1.0 decompression on the BBC Micro
MIT License
3 stars 2 forks source link

Previous experiments #1

Open hexwab opened 3 years ago

hexwab commented 3 years ago

This is just a heads-up to say I've been quietly noodling around with this for a couple of years now. I started with exomizer-3.0 and have modified it as I needed for various projects:

https://github.com/hexwab/beebsides get_crunched_byte reads directly from tape, buffers live in zp for extra size savings

https://github.com/hexwab/vgm-player-bbc/commit/50a54c9341d888a34b81edbd579b9e5bc7c2c333 65C02 optimizations, including inline get_crunched_byte to avoid a subroutine call

https://github.com/hexwab/beebdrod/blob/master/exo.s Decrunch to arbitrary addresses (in case you want the same file decompressed to different locations), allow not storing the decrunch address in the compressed data at all (normally the first two bytes; this saves two bytes per file if you have many files you want decrunched to the same address)

Is it your goal for this repo to be the starting point for people wanting to get exo working on the Beeb? I've accumulated a bunch of knowledge at this point, would be good to have it all in one place.

picosonic commented 3 years ago

Thanks for your message.

Yes this was created as a sample for people wishing to try exo compression in their own projects. I came across the original code but it seemed a bit complicated to get going from scratch.

I was shown the 3.0 stuff on the Beeb/Electron by 0xC0DE and have seen it used by bitshifters. I couldn’t find a 3.1 update so wanted to create one incase there were space or speed gains to be made.

I like the idea of having multiple small compressed blocks using a shared exo header (but haven’t got that working yet). Also forwards decompression in 3.1 - which I have got working.

I’ll take a look at the links you’ve sent.

Thanks

hexwab commented 3 years ago

Bitshifters: my 65C02 optimizations (second link) were used in Wave Runner (and possibly Stunt Car Racer, I forget). These are for the "stream" decompressor which was used for music playback. (It's not ideal for this though, as cycles per byte output varies wildly. https://github.com/hexwab/vgm-player-bbc/blob/master/speedtest.ssd <-- yes I took the trouble to graph this.)

I too like the idea of a shared exo header. I've not delved deeply enough to know whether the lookup tables that are the first thing the decruncher creates are (or can be made to be) common across files. In my particular use case (DROD) I have 350 rooms, around 2.5K each, that are individually compressed, and just stripping the target address alone saves 700 bytes (around 1%). Having a shared lookup table sounds like a potential win both in terms of compressed size and avoiding repeated table creation (decompressing up to 25 rooms for the map screen is not fast!).

AFAICT Markus's design goal for exo was for it to be run once to decompress an executable in-place. There seems lots of low-hanging fruit if that's not what you're doing.

I like that you have forward decrunching working; I've always used the backwards decruncher as it seemed the path of least resistance.

Rebasing all my various hacks on 3.1.0 sounds like a thing it would be good to do. (I haven't looked at 3.1.0 at all yet.) Will I get round to it? Maaaybe. I suspect the number of IFDEFs is going to balloon if they're all in a single source file though. Perhaps some kind of automated testing would help.

Also I don't know whether upstream accepts patches, but the seeming lack of a repo I can fork and send pull requests to has put me off trying so far.