Mike's PCjr Page

Trixter wrote:LZ4 has an optimal parser; ZX7 claims something similar, but does not. There might be a special case in that data (like, a lot of runs) that LZ4's compressor is able to tackle better.

yes, it's about 20K zeros in that file (most of them located together)

P.S. Interesting fact - ZX7 shows much better results than LZ4 on compression of Z80 code, for example: ZX7 always compresses smaller than LZ4 because ZX7 has an entropy encoder (range coding) on the back-end, whereas LZ4 does not... But it's not the case for JRCARTS7.IMG: 101,009 JRCARTS7.ZX7 .......

Very cool. But looking at LZ4 size, I don't know why you just don't use that. My LZ4 decoder only decodes up to a single segment, so you'd have to compress and decompress each ROM by itself if you wanted to use my code, but even still it seems like a win... Yea, may be I should try that... P.S. Int...

Actually I found some sample of data that gave me 4% improvement by using rarest byte instead of FF, so I think I can support it as an option... It's the best kind of 4% -- it's for free . I wish all my schemes could have better compression for free. OK, for JRCARTS7.IMG I've got these results (wit...

EDIT: I just thought of another optimization: Don't use FF for the code; instead, use the value that shows up the least. Scan the entire file before compressing to determine which value shows up the least, then use that as the code. Otherwise, data that has a lot of FFs in it (like most 8-bit progr...

That way you can shift-and-branch and the value is already in the correct format once you get to the code that handles it. But you still need to add 4 to get the value, right? So instead of adding 4 you may add 84H, as I said before, and highest 1 will not be involved :) P.S. Thank you for your gre...

LENGTH is 1 or 2 bytes: 1xxxxxxx - for 4...131 01xxxxxx - for 132..195 00xxxxxx xxxxxxxx - for up to 16383 If you care about decomp speed, you might want to put codes at the end instead of the beginning. For example, 1xxxxxxx means this is necessary: cmp al,10000000b je handle_1 ... handle_1: and a...

I'm not going to win this competition anytime soon ... my general LZW algorithm took 147456 bytes of input and produced 132797 bytes of output. Which is reasonable considering the binaries look like random data, but not great when simple heuristics that take advantage of the structure of binaries c...

SHAFF0 format is very simple: XX - any byte other than #FF is a single data byte #FF #00 - single byte #FF #FF 0xxxxxxx LENGTH (distance -1...-127) #FF 10xxxxxx LENGTH (distance -128...-190 and -191 means last distance longer or equal to -191) #FF 11xxxxxx xxxxxxxx LENGTH (directly encoded distance ...

I finished version 0 of my LZ77-like compression (byte-oriented) that I designed in October 2013: https://github.com/shaos/shaff and it put me closer to RNC Pro Pack 2 and ZX7 in terms of compression ratio: 147,456 JRCARTS7.IMG - original 130,281 JRCARTS8.IMG - my 00-00-00 compression 112,715 JRCART...