Spectrum Computing

Last Christmas, Magnus Lind released version 2.0.10 of Exomizer, his data compression utility, after more than two years from the previous update.

The utility is very efficient, although decompression is on the rather slow side. However, if data size is your priority, I think it is the better choice available at the moment. I had to use it for Lost In My Spectrum v2.0 to keep compressed files under 16384 bytes, in order to fit each game section into the 128K memory banks.

More information and download at the Exomizer web page. The package also contains the Z80 decompressor routines by Jaime Tejedor Gomez (Metalbrain), optimized by Antonio Villena and Urusergi.

Thanks for the heads up. Excellent stuff, although I assume the unclear licensing status for the Z80 decompressors will prevent it from seeing more usage in original projects.

Urgh. I recently used a nice Z80 heapsort routine that has a callback function to sort complicated datastructures. I'm really grateful to the author, am glad he made it available, and happy to comply with an opensource licence.

But I'm still annoyed I have to fill up valuable Spectrum RAM with unnecessary references to the Regents of the University of California, just cos he used a boilerplate copy of the 2-clause BSD licence instead of one that refers to "the copyright holder" :/

Hello,
I tried the new z80 decruncher, but with data compressed with the old version as used by wav2ay.

I manualy replaced the exomizer decruncher in the created asm but it fails, the screen is filled with a kind off 'square' blocks hieroglyph style
this is the 'original' but with out decruncher. this is the suposed result as datablocks
http://www.cborn.nl/zxfiles/plop-bump-flut.z80
this is the 'original' with OLD decruncher
htpp://www.cborn.nl/zxfiles/48k_plop-bump-flut.asm

this is with v2.0.10 z80 decruncher
http://www.cborn.nl/zxfiles/pbfexb0003.z80
http://www.cborn.nl/zxfiles/pbfexb0003.asm
i moved hl' and iy to the stack, but probably i forgot something Or perhaps the crunching changed to much inbetween different exomizer versions.

Hi,

I am having similar issues with exomizer. I have tried both versions of the decruncher that come with the main zip and both just don't decompress properly, fill the screen with garbage and then reset.

I am passing the compressed data to HL and target memory to DE and calling the deexo function.

I was wondering if perhaps I am calling exomizer wrong - the following works for decompressing if using the 6502 decruncher:-

exomizer level test1.dat,0 -o test1.pak

The .pak file that is created is of course smaller as expected.

Is there a way to get it to work anybody?

D

Just to add to my last post, in the z80 readme says

The deexo_simple.asm and deexo_simple_b.asm decrunchers don't handle literal
sequences and assumes that the table for bits and base is aligned to a
256 boundary.

Although I am not sure what part of the example deexo.asm files the above bits and base relates to ?

D

dwinters18 wrote: ↑Sat Dec 01, 2018 6:49 pm Hi,

I am having similar issues with exomizer. I have tried both versions of the decruncher that come with the main zip and both just don't decompress properly, fill the screen with garbage and then reset.

I am passing the compressed data to HL and target memory to DE and calling the deexo function.

I was wondering if perhaps I am calling exomizer wrong - the following works for decompressing if using the 6502 decruncher:-

exomizer level test1.dat,0 -o test1.pak

The .pak file that is created is of course smaller as expected.

Is there a way to get it to work anybody?

D

Are you defining exo_mapbasebits? Or are you perhaps overwriting this buffer with your decompressed data?

Thanks for the reply.

I have tried exo_mapbasebits at the end of the deexo source code (where it was originally when first removed from the zip) and I have also tried org'ing it to for example 49152 (for testing) which I think caters for the 256 boundary thing (correct me if I am wrong please).

But both cases don't work. They just make spectrum emulator reset.

The exo_mapbasebits org at 49152 is below my test compressed data (only about 80 bytes) org'd for test at 50000 and the destination org'd at 52000

D

Is your code returning to BASIC? If it is, you'll need to push IY to the stack beforehand and pop it back afterwards.

Hi

No its not returning to basic. It is part of a setup of a main loop that will eventually be using the unpacked data. (if that makes sense.)

Its all an assembler thing no basic (apart from what runs it)

D

dwinters18 wrote: ↑Sat Dec 01, 2018 6:49 pm I was wondering if perhaps I am calling exomizer wrong - the following works for decompressing if using the 6502 decruncher:-

exomizer level test1.dat,0 -o test1.pak

If you are using this command then you are running it in the wrong mode, you need to replace "level" with "raw" for compression in this case.

For decompression you need to use the correct .asm file depending on whether you're decompacting forward or backwards which in the case of the command above is forwards so not one with "_b" in the filename.

Align exo_mapbasebits to a page boundary otherwise it will in all likelihood crash.

Works properly if you do all that, just tested it with a .SCR file since once you've decompacted it all you have to to is LDIR it to main screen to see if it's all good or not.

Hi,

Thanks for your reply.

That worked perfectly thank you!

I changed the mode to raw and using the exo_simple asm code everything as expected.

Thanks again!

D