Home Page Forums MAME MAME The SNES WIP topic

Are you buffering CGRAM accesses properly? When you write the first value it gets stored in a buffer, and it writes the 15-bit pair on the second write. Writing to $2121 clears the "latch" so to speak so that the next write after will be buffered. Reads are immediate, however. d7 of every second read returns the PPU2 MDR, or open bus.

How about wrapping around? After writing to $2122 at $01ff, it wraps back to $0000.

We're lucky that the test doesn't try writing to CGRAM during active display, heh.

SVN r5826
snespal driver



This was the reason why I gave a comment.


SVN r5839
snespal driver



Seems to be ok now.

PS: Using GCC for compiling.

I suggest you to use either nsrt or goodsnes to remove header from your roms. with proper headerless images you would have had no corruption.

however, we fixed the problem

Thank you for the info, etabeta78.

It'd be great if you guys were willing to enforce a no-copier-header rule for MAME/MESS images

They serve absolutely no purpose other than making IPS patch applications a crapshoot, and only remain due to popular emulators refusing to remove support for them.

It was a rather silly bug on the read cgram data, something like:


case RCGDATA: /* Read data from CGRAM */
if (cgram_address & 0x01)
{
snes_ppu.ppu2_open_bus = ((UINT8 *)snes_cgram)[cgram_address] & 0xff;
}
else
{
snes_ppu.ppu2_open_bus &= 0x80;
snes_ppu.ppu2_open_bus |= ((UINT8 *)snes_cgram)[cgram_address] & 0x7f;
}


...instead of...


if (!(cgram_address & 0x01))
{
snes_ppu.ppu2_open_bus = ((UINT8 *)snes_cgram)[cgram_address] & 0xff;
}
else
{
snes_ppu.ppu2_open_bus &= 0x80;
snes_ppu.ppu2_open_bus |= ((UINT8 *)snes_cgram)[cgram_address] & 0x7f;
}


...guess that I need to check the other errors as well (first off the APU fail)

All working again. Thanks!

That may be a tough one. Surprisingly even Super Sleuth is failing it. Made this for fun / bragging. May help troubleshoot the remaining issues.
http://img242.imageshack.us/img242/8840/agingcassette.png

If you want to go at it anyway, I'd suggest referencing blargg's GME S-SMP core. It's also fully cycle-accurate for every testable opcode, and even emulates a special feature I don't, a glitch involving the counters.

But if you get them all, it's pretty neat. It runs a slightly different version of the SNES character test afterward while playing "When you wish upon a star" in the background. Would've been more fitting had I kept the name StarSNES

"EXT LATCH" would probably be the next one to target. It's probably using STAT78 and PIO for that.

EXT LATCH tests the horizontal latch at 0x213c (OPHCT) (puts it at work ram $0054-5 then checks with various values, put a breakpoint at pc=9226 to quickly check it). I can workaround it but it's directly related to the maincpu/pixel clock timings, so it'll do damage in the long term. Same goes for the VH flag test, in the end the fault is shared of that 256/512 switch thing that I've putted up that shows one of the major flaws in MAME/MESS architecture...

The DMA MEMORY fail is probably a bit scarier