rensoup

Looks like you added it in 3.10, it doesn't work in that version either. I tried launching Altirra without any image so it just goes into Altirra OS, also used an empty Altirra.ini file just in case then went into PerfAn->profile->crash Is it the same thing as profile->profile view ? because that one is greyed out for me I'm on W8, maybe that makes a difference? Suggestion: Would it be possible to have an auto-update disassembly window flag ? (by right clicking on said window perhaps?) so that whenever some self modifying code trickery occurs you don't miss it... just an idea... Thanks

That works, would it be possible to have it as a checkbox in the debug menu (to make it permanent) ? Not sure what you're saying... I just tried the -c switch you suggested and it seems to work perfectly... so ? ? Also Got a crash (3.90 test 3) when going to performance analyzer -> profile (straight after launch, tried with different xex/atrs) Thanks

More questions/requests regarding the disassembly window: Any way of disabling OS variables lookups? I'm not using the OS at all so lots of my ZP variables get labelled wrong. Is it possible to display labels with regular caps ? Thanks.

I'm using dark mode (thanks again!) in 3.90 test 3. It has a small issue when loading source files: empty lines show up as white lines and lines with labels show up as white with light grey text.

Dark Mode, YES! ?

To be clear, I don't want to include C libs or compiled C code, I thought maybe a compiler may still be able to optimize inline ASM code. There is more or less 25KB of 6502 code, and about 13KB of game data. I can give a bit more detail but the consensus seems to be negative. Right now the game runs in a "virtual" 6502 environment, that means there's no hardware specific emulation (no graphics no sound), except for input. The draw functions are intercepted and redirected to D3D. Here's a screenshot at init: -each square is a byte. -each white frame is a label (I can hover over it and get its name) -each black byte has never been accessed -each red byte is byte that's been written to -each blue byte is byte that's been read (uninitialized access!) -each green byte is byte that's been written to and read. After running the game for 2 frames: The area between $2700-$7d00 is the code. Before/After that it's data. All the memory up to $9200 is used (the black areas will be used) ZP is almost full and gives back some decent amount of code space. I'm already using the bottom of the stack. After just 10 seconds of gameplay it's mostly all green, so yes the game touches a lot of code and data. I'm using 37KB of RAM *without* Screen buffers (modeE 2 * 160pix*216 lines ), PMG Area, DL, disc buffer, Atari code. I think my 64 KB are pretty much full. Not counting graphics/sound yet! Dmsc, another forum member provided a fast lz4 decompressor at +-1500 bytes/frame. The game touches a lot of code per frame so decompressing code on the fly doesn't seem like a good option. I'm hoping I'll be able to decompress graphics data on the fly though. The project is 128KB. All the graphics/sound data will go into the extra 64KB. Nope the code is 6502 originally. I've done a little bit of code/data optimization on the project and I'm not very good at it , managed to save a few KB though. Not yet but perhaps people will be interested in contributing once it gets a public release.

So I've got this porting project that I'm working on... I've got about 25KB of 6502 code which I would like to reduce if possible. Is there a tool that could automatically optimize it for space? Perhaps I could use a c compiler and convert the code to inline asm and let the compiler do some magic ? Any thoughts ? A quick search reveals these: http://web.archive.org/web/20010627195141/http://www.heilbronn.netsurf.de/~dallmann/lunix/src/opt65.c https://github.com/RussellSprouts/6502-enumerator Does anyone have experience with them ? Thanks

Looks like pipemania on the XL, nice! I'm far from being qualified to answer but since nobody else has... RMT seems to be the music player of choice. It allows you to mix in sounds effects as well. Does it work with basic? I don't know... probably ?

In the NMI code I found, there was this sequence(in blue): I'm guessing that's not required, but I'm not sure. It also checks for the Reset button on the 400/800... again I don't really know if that needs to be there. From the Altirra Hardware Reference Manual p55: I left it in the VBi for safety but then I chain DLI handlers which don't do any tests and then in the last DLI handler I set the NMI address back to the VBi. Just hoping that's ok because I don't have real HW for testing.

I wasn't asking for myself, just suggesting that a tutorial with a working example is even better (just something simple like a color change) I've seen some multiplexor demos, I was complaining about changing multiple sprite positions/color every scanline not being practical One thing I'm not sure of and I see you don't mention it, is checking for the source of the NMI when one occurs. I made the assumption that it can be omitted but I'm not sure how safe it is. Another trick to get some cycles back when chaining DLIs is to only update the low byte of the NMI vector if you're not crossing a page... that's pretty obvious indeed but that's my modest contribution to this thread

Nice of you doing this tutorial, a fully working sample would be great! I actually found code posted on AA for doing this (Thanks to Popmilo I think!) and it really helped. My brief experience with them: -I was naively hoping I could get around the sprite limitations by changing their positions/sizes/colors every scanline. As it turns out, it's practically impossible. Even though you may have the CPU time, the changes would occur all over the scanline and cause all sorts of glitches. -I think the concept was a little ahead of its time. It would have been ok with a 6502 at twice the clock speed. It works great on an ST or Amiga. -I woud like to know why on earth they didn't time DLIs to actually start towards the end of the scanline. From my tests, they start in the middle of it... this means you have to waste a lot of cycles with a costly WSYNC to hide colors changes. Those colour changes every scanline which the Atari is famous for can't actually be done with DLIs without wasting most of your CPU cycles... It's crazy.

lzs16: 3.7KB !! Can't wait for the next release

Well yeah I somehow missed it, sounds really nice (and cpu intensive)!

Tried it on 7 gates of Jambala (110KB SAP). Lzs8: 30KB Lzs12: 8.5KB The new version can be a tiny bit slower but still several times faster than the original player! Guess it's an all around solution now

I didn't know Sid2Gumby, was only aware of the latest iteration of your AtariSid... Honestly, S2G feels a little dated, especially stacked against AS5 . Wish I could SAPR those instead... but yeah at 15khz that's not going to happen (although only the first channel seems to vary much during a frame) I don't know the tech behind AS5, nor do I know anything about Pokey . But just out of curiosity, I think I read you were doing software mixing, does that mean a Sid voice is not mapped to a Pokey voice ? although according to the PMG visualizer that seems to be the case.

I tried on a 8KB RLE compressed song and all channels but one got bigger. The one that got smaller shrunk by 500 bytes! But I couldn't be bothered. Again I'm thinking I'd get better results by modifying the RLE format but I'd be trying to catch up with dmsc so not much point. Perhaps larger buffer sizes in dmsc's lzss would yield good gains too? It's pretty usable for any tune under 2 minutes right now. Just curious about your Sid player, are you feeding pokey at a higher frequency than 50hz ? (I'm guessing the sprites shapes in your player reflect that)

About looping, I did -some- of those things you mentioned, I'll give it another try. Thanks! I've been wondering about SAP->SAPR myself... Only found ASAP so far: http://asap.sourceforge.net/ There's a command line tool included which I haven't tried yet. On Win, there's a player called WASAP included in the package. If you load a song and go to info, you can save a XEX and SAPR it from Altirra. Best I found was to get an RMT and assemble it, then SAPR it in Altirra and KIL on song loop to get a perfect loop

Gave it a shot... the player is quite a bit faster indeed. Litterally 4-5 times faster than the original RMT sometimes! Only issue is that I can't seem to get it to loop 100% right with the new version... not excluding that I've done something wrong of course... zip contains just obxs for all versions for a quick perf compare. shadowsobx.zip

For ./lzss < test1.sap > test1.lzs, it's shadows.zip which I posted above. my sapRLE: +-8KB dmsc: 6.6KB Are we going to end up with 3 solutions ?

OOoops Sorry, I'd ORGd the tune at $1000 and forgot that your player is ORGd at $2000, so the player ended up playing itself! Verified to work again, added looping, looping perfectly!

actually, I'm still having an issue further in the song, it's still before the loop point I believe. Maybe another redirection issue ? I'm attaching the obj and the converted file lzsfail.zip

Yes I'm under Windows, so your fix worked perfectly. The files are a bit bigger now but still slightly smaller than my RLE. Thanks again! I'm still baffled that nobody has done this before Guess I won't use my RLE . Your code is much smaller, speed is the same, files can be a little smaller or quite a bit smaller, and there aren't any silly restrictions (I have to ORG the compressed data, and have to set manually the song duration in the code for looping. ) I'm just gonna go ahead and post it anyway so you can have a laugh If you look at some of the compressed channels files, the compression is outrageously bad. I could probably implement RLE on duplicate sequences and save a good amount of space but compared to your solution, it wouldn't be very elegant code. sapRLE.zip

Yes, very clear now, I thought you meant standard RLE. GREAT! :thumbsup: Well... almost. I've tried it on a bunch of SAPs and they all fail to decrunch/play at some point... not sure if I've done anything wrong ? I've attached an example that failed. (I did "lzss <shadows.sap >test.lzs") So I got my modified RLE to work and for a 35KB raw, RLE would get it down to 12.5KB, my modified RLE did 9KB, your LZS did 8.5KB. But your LZS did better on other files. The decode time on the 6502 was similar, about 10 scanlines. There are others things that I could do that might improve the compression quite a bit but I'm ok with what I got now. And if your LZS works I'll probably use that instead! Your method is much cleaner, my setup code is a lot more messy and I have to expand the files to make them multiples of 9 when packing. Sure a better compression ratio would be great but as it is, it makes it possible using some of those costly RMTs into actual productions. PS:People have suggested delta encoding, I gave it a quick shot but ended up with results slightly worse. shadows.zip

Yes, I wasn't very clear on that, speed isn't essential in this case (it is for decrunching sprites). I managed to get my RLE stuff working and the code is horrible... way too much setup code. dmsc' solution is much cleaner.

Well I got curious, so I took my 9 deinterleaved raw SAPR channels and compressed them with LZSS v0.01. and the total was about 4KB vs 2KB for LZ4 best setting. That's just one very tiny set of data and perhaps that wasn't the best LZSS compressor... Well thanks for that! The obvious reason for that would be that the compression ratio may be somewhat worse, I guess ? Well, call me lazy but I've not used C in years (I'm all C# these days) and I don't even think I installed it in my VS.