rensoup

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.