Spectrum Computing

jimmy wrote: ↑Tue Oct 12, 2021 9:56 amUnfortunately I can't tell you how many bytes it now uses because after 37 hours of CPU time my laptop is still trying to compress 33887 bytes into ZX5 format. ZX5.exe is currently using 1.5Gb of RAM too...

Uaaaaa! 37 hours!!! What game are you compressing?
 

The "experimental" ZX5 compressor is now available Hurrah! I have won my own bet!! :lol: Several things catch my attention, why did you move the first lenght bit of the new offset block? is the offset limit still 32Kb or does it improve? and was there no way around the use of alternative ...

OK, give me a few days to put together a proper release. Bets are allowed! ;) We are intrigued. Which format the compressor will use? Is it possible that the new compressor uses more than one "last offset"? Yesterday I found out that lzma uses the last 4 offsets, so I wasn't really wrong ...

When I was working on ZX0, I also created another more complex format that I used for comparison. I'm so curious! could you please briefly explain that format? thank you. It's true that my last code made the stack grow a lot but I've improved it. Now it only grows when a "new offset" occu...

That's a very original idea but probably too crazy. :) :lol: Yeah, sometimes I get so bored that these things come to me. However to test the idea I would need to learn C programming first :oops: There's an execution flow with LDIR followed by LDI, thus I think you could have bc=$ffff at this point...

I can't find any more optimizations, so this afternoon I started to think about a possible evolution of the format, and again, I had a new crazy idea. What if we don't discard the last offset and use the stack as a stack & buffer mix? I'm not sure if this can improve compression but I had nothin...

Another little optimization. This time for fast 2.0 routine: ld b, &ff ; the top byte of the offset is always $FF at this point bc is always 0 so it can be safely changed by: dec b On the other hand we have a lonely "jp": jp nz, CopyMatch1 I think it was a "jr" in the past, b...

Thanks to your extremely creative suggestion! You are properly mentioned in the credits :) Thank you very much :D Sorry, I forgot to post a reply for your last post. Problem is, the "standard" decompressor is intended to be as small as possible. The idea of sacrificing size for better per...

Einar Saukas wrote: ↑Thu Sep 09, 2021 6:49 pm OK, it's done! The latest optimizations are now available in the official ZX0 repository:

Bravo!!!

I'm really glad it works

Congratulations.

EDIT: you didn't like my last forward standard optimization? in exchange for a byte you get 2% extra speed. I found it interesting enough

This could be the definitive standard forwards version (if the modifications work on the compressor). Still occupies the same bytes as before (69, magic number :mrgreen:) but we take advantage of the speed optimizations of the standard backwards version. in this way the forwards version is slightly ...

You're right, brilliant!! This means that b doesn't matter and we can optimize 1 byte more? :o dzx0s_new_offset: pop bc ld c, $fe call dzx0s_elias_loop ; obtain negative offset MSB inc c ret z ; check end marker ld b, c

A crazy idea? if we use a totally negative newoffset (forwards) I think it would work, and pretty fast and the best thing is that we would stop using alternative registers. ; ----------------------------------------------------------------------------- ; ZX0 decoder by Einar Saukas ; "Standard&...

This time I have achieved a more important speed optimization, around 2% 8-) ; ----------------------------------------------------------------------------- ; ZX0 decoder by Einar Saukas ; "Standard" version (69 bytes only) - BACKWARDS VARIANT ; --------------------------------------------...

With all of you, an incredible optimization of..... 8 T-cycles :lol: (it seems that no more can be achieved :cry:) ; ----------------------------------------------------------------------------- ; ZX0 decoder by Einar Saukas ; "Standard" version (69 bytes only) - BACKWARDS VARIANT ; ------...

I can't edit my previous message so....

My mistake I've already realized that it does not work, but i'll keep looking for some optimization

Congratulations, again.

Hi Einar! Congratulations on this new compressor, it's amazing!! I took a look at the standard decompressors a couple of hours ago (very good both, especially forwards variant), and I haven't found any optimization, which indicates that the code is already very mature. However, there's something I t...