Jr Cartridge blank for eprom

[Shaos]

Russian demosceners use MegaLZ, so I may try it instead

LZ4 and ZX7 max out their respective pareto frontiers. I co-wrote the x86 decompressors for both, so I'm biased, but they are the fastest 8086 decompressors for their formats, and both have optimal parsing built into the compressors so they achieve competitive results. ZX7's size-optimized decompressor is 71 bytes and it compresses better than LZ4, so maybe look into that?

OK, I tested a few compression tools on JRCARTS7.IMG that is image of the disk without ColorPaint (and JRCARTS8.IMG is compressed by my "naive" compression with 3 zero bytes explained above):

Code: Select all

-rw-r--r-- 1 shaos shaos 147456 Jan 11 14:02 JRCARTS7.IMG
-rw-r--r-- 1 shaos shaos 130281 Jan 11 16:53 JRCARTS8.IMG
-rw-r--r-- 1 shaos shaos 101009 Jan 23 11:48 JRCARTS7.ZX7
-rw-r--r-- 1 shaos shaos  99974 Jan 11 14:27 JRCARTS7.MLZ
-rw-r--r-- 1 shaos shaos  80016 Jan 11 14:02 JRCARTS7.IMG.bz2
-rw-r--r-- 1 shaos shaos  79098 Jan 11 14:02 JRCARTS7.LZ4
-rw-r--r-- 1 shaos shaos  71950 Jan 11 14:02 JRCARTS7.ZIP
-rw-r--r-- 1 shaos shaos  71808 Jan 11 14:02 JRCARTS7.IMG.gz
-rw-r--r-- 1 shaos shaos  65765 Jan 11 14:07 JRCARTS7.RAR
-rw-r--r-- 1 shaos shaos  62543 Jan 23 11:41 JRCARTS7.7z
-rw-r--r-- 1 shaos shaos  62508 Jan 11 14:02 JRCARTS7.IMG.xz


So LZ4 is better than ZX7...

P.S. MLZ is MegaLZ that Russians like to use on ZX-Spectrum clones and Russian 8080 machines

[Trixter]

I would not have guessed that would work due to protocol differences. I guess it uses the Microsoft Mouse protocol standard?

[Trixter]

So LZ4 is better than ZX7...

...on this specific material. There must be a lot of opportunities for RLE-like runs in the data, which zx7 doesn't do as well with. Not only does LZ4 compress runs better, I wrote the faster version of the decompressor (the larger one, assembles to 446 bytes) to recognize RLE runs and handle them with a REP STOSW, so they expand faster than a memcpy() would. But this material only gets decompressed once, so the 71-byte decompressor is fine.

P.S. MLZ is MegaLZ that Russians like to use on ZX-Spectrum clones and Russian 8080 machines

Yep, seems very comparable to ZX7. ZX7 uses elias gamma coding for its order-0 phase; MegaLZ uses something it made up itself (looks like 2-pass statistical method?).

There's always Rob Northen's compression library, which was made free when the company dissolved. Look for RNC_ProPack.lha floating around. It compresses better than LZ4, ZX7, and MegaLZ because it uses a real huffman table. x86 asm source included.

Exomizer beats them all, but the decompressor is really weird so I haven't tried to tackle it yet.

Yes, I am an x86 compression nerd.

[Shaos]

I would not have guessed that would work due to protocol differences. I guess it uses the Microsoft Mouse protocol standard?

Yes, I used this mouse as "a Microsoft mouse" 13 years ago in one Russian high-end ZX-Spectrum clone called "Sprinter"

Surprisingly everything pictured is working with ColorPaint pretty well

[Shaos]

Yep, seems very comparable to ZX7. ZX7 uses elias gamma coding for its order-0 phase; MegaLZ uses something it made up itself (looks like 2-pass statistical method?).

Authors stated that MegaLZ compression utility uses guaranteed optimal way to encode biggest possible patterns - something like that...

There's always Rob Northen's compression library, which was made free when the company dissolved. Look for RNC_ProPack.lha floating around. It compresses better than LZ4, ZX7, and MegaLZ because it uses a real huffman table. x86 asm source included.

Exomizer beats them all, but the decompressor is really weird so I haven't tried to tackle it yet.

Ok, I'll try to find all these out...

Yes, I am an x86 compression nerd.

This is great

[Trixter]

Authors stated that MegaLZ compression utility uses guaranteed optimal way to encode biggest possible patterns - something like that...

Is there a link to that info? All I can find is the source. I'd love to read actual documentation about MegaLZ.

As for "optimal way", that's called "optimal parsing", which is a way to guarantee the most efficient matches (offset+length) of the source material, at the cost of speed. Storer and Szymanski described it in their 1984 paper that described LZSS, if you want to look it up out of curiosity; their solution was to parse the data BACKWARDS which initially seems wacko but makes sense if you think about it. LZ4, ZX7, MegaLZ, and exomizer all have an optimal parsing option. Don't know if RNC Pro Pack does, but it still performs competitively.

[Shaos]

I don't think there is any documentation on MegaLZ - it was written by hackers from deep russian woods

P.S. There is a Russian description of the format itself (autotranslated by Google):
https://translate.google.com/translate?sl=ru&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Fzxpress.ru%2Farticle.php%3Fid%3D8664&edit-text=&act=url

P.P.S. I've just forked last known source code of MegaLZ packer to preserve it: https://github.com/shaos/mhmt (and added README from earlier MegaLZ distribution). It's mhmt - extended MegaLZ packer that also can produce Hrum and Hrust archives (with options -hrm and -hst respectively):

Code: Select all

-rw-r--r-- 1 shaos shaos 100180 Jan 24 17:14 JRCARTS7.IMG.hrm
-rw-r--r-- 1 shaos shaos  99974 Jan 24 17:14 JRCARTS7.IMG.mlz
-rw-r--r-- 1 shaos shaos  67437 Jan 24 17:15 JRCARTS7.IMG.hst


P.P.P.S. It looks like they used "Optimal LZH" approach, described by Igor Pavlov (author of 7-Zip) in 1999 in RU.COMPRESS newsgroup (autotranslated by Google): https://translate.googleusercontent.com/translate_c?act=url&depth=1&hl=en&ie=UTF8&prev=_t&rurl=translate.google.com&sl=auto&sp=nmt4&tl=en&u=https://github.com/shaos/mhmt/blob/master/descr/optimal_lzh.txt&usg=ALkJrhgPCAYgoSi0V7Af5hE4PBtVvQfp9A

Well, half a liter is not a problem

They were talking about vodka of course

[Shaos]

Does JR-IDE BIOS do something with sound? Gamecartridge became silent with JR-IDE installed

Also BASICs stopped working completely - any of them - cassete one (it's simply unreachable), cartridge one and disk one (from DOS 3.20 - both BASIC and BASICA)...

[Brutman]

JrIDE should not affect sound at all.

Also, you can't get to cassette BASIC because the hard drive is bootable; remember, cassette BASIC is only reachable if nothing else can boot.

You should be able to tell it to boot straight to Cartridge BASIC by pressing ESC at the boot menu and selecting 'D' to boot from a cartridge.

If you boot DOS with a device driver to recognize the extra memory then all forms of BASIC fail to load. There are device drivers you can use to fix that problem; each of the memory managers (except for Jrconfig) came with one; look for jrBASIC in the Microsoft Booster drivers for one such device driver.

[Shaos]

ok, understood