Home Page Forums MAME MAME The SNES WIP topic

I mean things like enforcing no VRAM writes during active display. It's probably mostly harmless, but without proper timing that could certainly break correctly functioning games.

Also, be warned: bsnes's CPU is heavily integrated with (H)DMA and other stuff that's on-die with the S-CPU. (What's the Ricoh number again?) That's how it should be from a design standpoint (and especially for getting all the timing corner cases right), but it makes it more difficult to integrate with MAME/MESS where all the peripherals are in machine/snes.c, and it also means it's unusable for other 65816 systems (Apple IIgs, C64 with SuperCPU expansion).

well, I have seen no regressions in any game I tested (and I think it's because the code checks the real hpos/vpos rather than the latched ones): the games which are currently broken were broken in 0.135-0.136-0.137 as well

those handlers can be made optional though, by always entering in the disabled display case (which directly reads/writes vram/oam/cgram), if any bad side-effect surfaces

Discovered why 3�3 Eyes - Seima Korin Den doesn't work.
Basically, 0x8128 is the IRQ vector, hence it fires the IRQ but it mustn't. If you comment out line 126, game boots and works fine ...
Stay tuned for a reason about why it fires that.

EDIT: Now it's official, MAME irq system sucks ass, because 3x3 Eyes does something VERY demented / twisted (take your pick). It has the NMITIMEN enabled all the time (0xa1), then it DISABLES the register (by writing 0x00) and executes a CLI opcode. Spurious IRQs happens due of that, because MAME, for whatever reason, remember that the irqs are called when in STI-mode.

Fun.

Meanwhile (did some tests to check if I was right about this, I am so going to submit it):



My heart cries for this

Eh? Most processors really do "remember" IRQs raised while the status register has them disabled and trigger them when you CLI or equivalent.

Why are the IRQs firing in the first place?

In those cases we had something pretty solid at least, a key, and some strings we knew were returned. In the case of the palette it's just made up data isn't it?

Due of the IRQ scanline triggering. Line 128 is that. My guess is that g65816 DOESN'T actually remember the IRQ firing, because I don't see any other solution to that. NMITIMEN bit 5 is enabled during STI, then the game clears it and clears the CLI too.

Oh, BSNES doesn't trigger that breakpoint at all, so I suppose that it behaves like I'm just saying.

I'm considering a MAME bug because you don't have any control over that, processors cores always acts as they remember the IRQ line raised, and the result is: a similar issue happens to Night Gal & friends system, I call a blitter write then irq the ncs and expect it to call just one irq ... no, MAME calls something like +1 irq for every time a blitter is executed, hence you have garbage for that game.

So the game sets an HIRQ it doesn't want to ever get? That's perverse.

ETA: Clearing NMITIMEN is supposed to disable/ack the interrupt? In that case it should lower it in g65816 and then there's no problem when it hits CLI.

Regarding the NES palette, my understanding is it was measured from the R/G/B output levels of various model PPUs running a test program. So it would at least have some hope of being correct. If that's not the case, then yeah it's just crap and putting it in MAME at all is probably of questionable value.

Good point, I'll try it when it recompiles.