rensoup

Well that's some weird stuff Not sure it's worth it, let me pm you to explain...

Damn and I was hoping for an existing solution

Ok that was confusing... you're saying that instead of of using the regular LZ4 encoder, I could use the LZ4 api to set the LZ4 dictionary to come from the previously compressed source data, instead of the decompressed destination ? something like: For every new chunk of 9 bytes to compress: -Set dictionary to be compressed source data, so the dictionary grows a bit more for every 9 byte chunk which in theory improves compression every time -Compress 9 bytes using new dictionary. ? Yes that bit I know, but these are offset in the decompressed data but from you're saying above I could change that to use offsets in the compressed source ?

Ooops you're right. dmsc's version seems a lot faster though.

found this post: https://forums.nesdev.com/viewtopic.php?f=2&t=13671 ouch...

Thanks, I found a 65c816 decoder for it ( https://forums.nesdev.com/viewtopic.php?f=12&t=5771) but its author says it requires 4KB of mem... that unfortunately seems like a no go for me! Well that's why I was hoping for a modified RLE, because the non repeated bytes are already stored decompressed in the source. So if some sequences are repeated, you could just store an offset and length. I'm just surprised that nobody has done that. I actually gave it a shot yesterday... it was a lot more annoying than I thought but it seems to work. The gains vary from nothing to about 25% compared to regular RLE and I get the feeling there's more that can be done. At 300-600 bytes/frame I would agree but dmsc's LZ4 decoder benchmark seems promising though.

Indeed, not what I want to do at all though... sorry for the confusion Yes unfortunately for SAP-R, the window has to be 128-256 bytes for any decent compression, 128 *9 *2 =~2.3KB just for buffers, you're starting to lose the benefit of the compression. I get the feeling that the code would be clunky too. A cheaper compressor might do just as well.

Ok, so I guess that was a little confusing. I mixed 2 use cases into one question. My first use case was simple: Like pirx said a decent streaming compression scheme would be perfect for SAP-R which exactly what I was trying to do! lz4 deinterleaved Pokey data compresses pretty well... so I modified XXL's lz4 decompression code to only output 9 bytes per frame only to realize that it didn't work because it was trying to copy data that I'd already discarded (yeah I know very little about compression ) I also realized that it was taking about 10 scanlines to output 9 bytes! I had another use case in mind (compressing sprites) but at 300 bytes/frame, it just wouldn't cut it either. With the code posted before, I have hope for this one.

well 15.3KB/ 55 =280 bytes per frame which is what I was seeing as well... Sure it's faster than exomizer/deflate but they're at the far end of the spectrum when it comes to speed. I was looking for something between lz4 & rle in terms of speed and compression ratio. Looks like I've got 2 possibilities with dmsc & irgendwer at least when it's ok for self referencing. btw I tried compressing data with your rle implementation that I found in MADS, it seems to perform a litte worse than this one sometimes (files can be 1-10% bigger): https://csdb.dk/release/?id=34685

Sounds interesting as well, 1700 bytes best case is a lot better for lz4.

Thanks! I will give it a try for sure. Sounds like it would be a good fit for one of my use cases. I've got another use case which requires -no- self-ref so I will look into what's in MADS and possibly have to try my own RLE variant (not even sure it will compress much better than RLE though)

Well there's various things I want to do... and decoding gfx data is one of them. A single 32x32 1 color sprite would take about half a frame to decode... That hurts.

I've started using MADS and indeed there's plenty of crunchers. I will take a closer look but perhaps some folks here have experience with them and can tell me if one of them fits the requirements? Can't find any ref to "B2" but pucrunch/exomizer aren't quite what I'm after... way too slow to decrunch.

Really ? well I tried Fox and XXL's version, it's optimized for size so probably not for speed. It looks like it can decrunch about 200-300 bytes max per frame at 50fps. The other problem with LZ4 for what I have in mind, is that it can't decrunch chunks as it uses previously decrunched data (while RLE can) I would still be interested to get a faster version if you have one. Thanks!

Hi, I'm just wondering if there's anything between these 2 as RLE just doesn't compress too well and LZ4 compresses well enough but is a little to slow when decrunching ? Perhaps some modified form of RLE ? Thanks

I'm not entirely sure this answers my question but I'll do some more digging, thanks

Well I'm still stuck on W8 I was asking for a dark background colour in debug windows not necessarily something that strictly follows windows conventions. I thought that'd be an easy change but I'm not a Windows expert. I've only ever used Winforms and it's easy with those. maybe I phrased that wrong again. I'm already using source debugging with Alt-Sh-O and it works great. It just doesn't seem to default to using it and I have to use ALT-Sh-O, then point to the masm file to activate it. I was hoping it would do this automatically but that's not a big deal if it doesn't.

Damn I somehow missed that... Much better now Might there be a color setting that I missed too (the white background is a little harsh) ? I'm loading from the command line and I wasn't paying attention again because it does indeed load the symbols... but it doesn't have all the comments that I wrote in the source (I still have to use Sh-Alt-O for that )... comments should be loaded from the lst file, right ? That sounds like a dealbreaker...

Thanks for the source! A screen kernel like an A2600 kernel with WSync every scanline ? Doesn't seem too good for what I want to do... I'm going to study this a little more.

I've recently started a bit dev on the A8 and I'm using Altirra for debugging and while it's working pretty well overall, there are a few things that could help: Could I make the debug fonts (much) bigger ? i tried the /portable switch which created an .ini file which has fonts settings but don't seem to do anything ? Is there a command switch to automatically load the .lst file because I'm using Alt-Shift-O every time ? Although I'm using an obj file right now, I'm planning on using xBios to be able to use the whole memory space as well as loading extra data. So that means an ATR file. Any way making the loading time instant ? not like warp speed where everything get speed up (although I guess I could use it if I could bind it to a key). Or perhaps there's a way to mount a directory as if it was an ATR? Thanks

Hi Snicklin, Well the code could store some internal state in that buffer, maybe even just one byte. Although that's unlikely, I'd rather be absolutely sure. Same as 1) but that's a lot more likely. Let's say I create a disk with xBios, run it, then break into the debugger to dump the $0800-$0BFF area. Perhaps that area contains the current directory structure as well as internal states? I then add more files or update the files on disk, changing their filesizes. The initial load from the bootsector would be up to date but after decrunching the old xBios, I'd end up with old data and almost certainly a crash. Just speculating

I'm planning to use xBios (seems like a great tool btw) and I'm wondering if I could get even more RAM back. the wiki says: $0700-$07FF xBIOS I/O buffer$0800-$0BFF xBIOS 1) I'm guessing I can use the IO buffer safely between loads ? 2) Assuming I've got a decompression routine already in memory that I use for other purposes, could I keep a compressed version of the $800-$c00 area ? I assume there is some data in there that is dependent on disk layout, and perhaps temporary variables so I can't just dump the memory and compress it ? Thanks.

That was fast, thanks! The 2018 release would be great indeed, I'm interested in understanding how to play samples while modifying PM graphics and position every scanline.

Hi, Just wanted to say this the most impressive 2600 game I've seen so far. It does have gameplay limitations but damn it doesn't look like a 2600 game, heck it looks better than the Atari 8bit conversion which was great (and the first game I ever got). Bravo

Hi, I'm just curious if there's any plan on releasing the source code ? or maybe just the sampled sound replay code ? Cheers.