nesdev.org

I always thought it would be easier to manage sprite VRAM allocation on the Genesis because it's not as cramped, has slightly higher DMA, and isn't arranged in collumns and rows like the SNES. How much memory are you saving for backgrounds? I think you have more freedom on the Genesis, as you can a...

By resource allocation i mean VRAM and hardware sprite object and the underlying Sprite structure (small block of memory) which own current state of your sprite (the later one is not a big deal, you can even statically allocate it). My sprite engine allow you to just create a new sprite without havi...

I mean, I guess I'm not one to talk as I don't know enough about the 68000, but that seems a little exaggerated? In the case of an actual game from the time period, not when you're trying to do software 3D rendering which makes use of 32 bit operations and multiplication/division (Even the video ha...

Really impressive psycopathicteen

Well i think this has been already discussed quite a bit... I'm the first to admit you just can't compare the SNES 65816 to the MD 68000 on their clock speed as these CPU uses complete different architecture. The SNES CPU runs synchronously with RAM and so can access it at each cycle while the 68000...

GARTHWILSON says MVN is interruptible . Oh, that is definitely a nice advantage over the Hu6280 TAI instruction, that can explain the extra cycle as well. About the compression, there is unfortunately no way to obtain good compression ratio for gfx data when you are using lossless compression (exce...

I don't know if that is the same for MVx instruction on 65C816 but i guess it is, it probably can't interrupt it and restore the internal state.

Yes but not by much ,6 cycles/byte for the 6280 vs 7 for 65816, but the CPU's frequency makes the difference . Yeah of course the CPU speed make the difference, still i would have expected to see the cycles the other way and the 65816 having the better block move instruction ;) Yes but this is not ...

Here's 9kB of graphical data. Ok, here are the result : Original: 9216 bytes APLIB: 3968 bytes (43%) LZ4HC: 4577 bytes (49%) LZ4W : 5972 bytes (64%) LZ4HC does a really good job here. LZ4W start to does a lot of miss as data get bigger (76 miss on 526 encoded segments). Actually SNES GFX data does ...

Thanks, I just tested, 1536 bytes by default. APLIB : 885 bytes (57%) LZ4HC : 1061 bytes (69%) LZ4W : 1048 bytes (68%) I'm glad to see my custom LZ4W does even better than LZ4HC (by a very small margin) :p The thing is that it's a really small dataset so it can't compress much, even APLIB is not tha...

Thanks for the clarification about the CPU speed, it was always intriguing me ;) About the DMA, the thing is, does it worth it if you need to transfer only a few byte ? Maybe it does.. after all to use software copy you also need to initialize stuff for the jump table... You can find my LZ4W impleme...

Don't increment the index registers. Start with an of offset of 254, and go down like this: lda $00fe,x sta $00fe,y lda $00fc,x sta $00fc,y ... lda $0002,x sta $0002,y lda $0000,x sta $0000,y Let the legnth factor is an index to a LUT of entry points. If it's an odd number it gets rounded up. I jus...

I calculated ~7.5 kB per fame for block moves, and the 65816 can outperform it's block move by using an unrolled loop. If you have enough room in the first 8kB, you can use Direct Page, and optimize it even more. (2.68 / 7 cycles) / 60 = ~6.5 KB pere frame. If we use fast rom we can consider this :...

Ok, it looks like you still have limitations in your use case of your LZ4 unpacking implementation. I understand the TAI instruction can be problematic as well (for interruption or just about bank crossing). The original LZ4 code for 65C816 was also limited to 64KB bank for that reason. My version d...

Wow 13 to 17 KB/frame ?? Did you measured it ? That is amazing and even more that what i can achieve with the 68000. Actually depending the compression level it can go up to ~16 KB/frame but usually it varies between 10 and 14 KB/frame. LZ4 i really well suited for 8 bits CPU (and the PCE is using a...