good! eager to try it
Ops! 
I screwed it up when re-adding old comments to the new code, adding in the normal (non-simple) version an old line that shouldn't be and f*cks up everything. It's been fixed already and you may download again from the same link.
Isn't MSX-O-Mizer v1.5f derived by exomizer?
Yes ARTRAG, it is, but its from 2008, its Exomizer 2.0, so maybe this never version is better, but i tried, i dont see a very big difference. So I stick to MSX-O-Mizer
//CB
Yes ARTRAG, it is, but its from 2008, its Exomizer 2.0, so maybe this never version is better, but i tried, i dont see a very big difference. So I stick to MSX-O-Mizer
The new exomizer versions don't improve anything on the compression side, so the ratios are basically the same. MSX-O-Mizer's raw data compression is the same as normal exomizer when using the -c option, so it may compress a little bit less if literal encodings could be used. It also flips the bits order, but doesn't remove the 2 redundant bits as my optimizator does, so it has a 25% of probability of occupying an extra byte.
The depackers have been heavily optimized, so it takes less than my own ones, but some of those optimizations are too aggressive: using RRD to read 4 bits groups in the header instead of reading them bit by bit saves a few bytes and states, but also screws up the data in RAM, so it can't be reused. Besides, it doesn't work if the data is placed in ROM, so to compensate it the ROM depacker wastes lots of bytes to copy the data to RAM before decompression, needing to allocate those extra bytes in the buffer (though it shouldn't need them, I think the copy could be placed inside the 328 bytes buffer, somewhere between 108 and 240) and cancelling any advantage that RRD gave to the RAM-only-use-once routine. And another optimization used increases the buffer needed from 156 to 328. Even if it's space that can be recovered after the depacking, less is better.
In few words: if you're using the RAM version to depack once and then forget, use MSX-O-Mizer. If you need the ROM version, it's better if you stick to the original exomizer 2.
PD: MSX-O-Mizer also has VRAM decompression and some kind of binary files support, so it clearly has its uses.
Several months ago, Urusergi started optimizing the depacker routines, starting a process that has taken almost three months, involving great contributions by Antonio Villena and even a few bits myself. This process has recently culminated (or at least I hope so 
).
On one hand, the depackers have been reduced a lot, and they're also a bit faster. On the other hand, there are new alternate versions (not so small) optimized for speed, so we can choose between four variants (between 0: smallest size to 3: highest speed). Variant 1 is specially attractive, because at the price of 3-5 bytes, it has a 14% speed gain.
Also, the optimizator program (exoopt) has been rewritten from scratch by Antonio Villena, so now you can pass the speed variant (and direction, that used to be always forward) you want as parameter, and it will automatically generate the depacker you need. You can even enter several files and it will produce the simple version if there are no literal chains, and the complete one if they exist. This new optimizator, does what it did before (inverting the read order of the bitstream, and removing 2 redundant bits) and more, doing some other changes in the data that in rare occasions might be bad (increasing the data size a bit), but allow for futher simplification of the depackers.
The new versions can be found here:
http://emuscriptoria.svn.sourceforge.net/viewvc/emuscriptori...
And an already compiled exoopt, here:
http://retrolandia.net/foro/showthread.php?tid=48&page=6
The history of the optimizations, in case someone is interested, started here (in spanish):
http://amstrad.es/forum/viewtopic.php?f=6&t=2608