BitBuster data superpacker

Hello Jerry The author of the original SjASM, Sjoerd Mastijn, has created a new Pletter compressor based on based on Bitbuster source codes - http://home.planet.nl/~realfun/pletter.html

Hello, Aprisobal So how's Pletter?

Hello, Witch Doctor Compared with UCL in the form of depacker uclz80. On full screens with good filling and sprite-like appearance it turned out best 1 method, apparently due to the 2kb window and the nature of the arrangement of bytes on the screen. The platter's winnings were within a hundred bytes. On Russian/English/programming texts, the best dictionary is about 8kb, 16 usually too much, those are apparently not optimally encoded by the platter with a large window size. On average, UCL wins on data of 16k up to 5-10%. On larger ones the data is tearing up the pletter like a hot water bottle, apparently a window into all the data and coding within the window is optimal. By code: uclz80 about 250 bytes. With some tweaking it doesn't use a stack, IY and alternative registers. There are no CALLs - everything is through JP, there is a possibility replace a good portion of them with JR. The pletter, on the contrary, uses all registers, many calls, and therefore the stack busy. about 110 bytes depending on the mode and poking around in it...

Hello NovaStorm If anyone else is interested, I compared pletter with megalz. On texts under 16k mlz Definitely better; for pletter you have to select parameters. On mlz screens usually (but it also happens the other way around) byte 20-40 wins. pletter on screens almost It's always better in mode 1. The speed of mlz is almost the same as ucl - I had about 1,000,000 clock cycles for unpacking the screen, for pletter 1 - about 600,000. So So far among them are mlz - for texts, pletter - for graphics. There is no UCL on spec suitable volumes of data, so within 16k it makes no sense to use it I see.