Home Page Forums MAME MAME The SNES WIP topic

I don't quite understand how this 256/512 switch thing shows a "major flaw" in MAME/MESS architecture. Why not always render at 512 and artificially pixel-double lines that are 256?

Because you need the playfield to be 512, so you need to double the horizontal resolution also, otherwise you'll get exceptions.

That's what I said, I think. When rendering each scanline, render it as 512 pixels wide. If the scanline is actually in 256-pixel-wide mode, then double the width of each pixel.

Exactly. Several drivers in MAME/MESS already do it.

...and the SNES driver does it too. What I'm saying since day one is that the beam timing gets screwed in MAME/MESS if you need to stretch the screen like SNES, like is currently happening.

How is that happening? There's no way it should be possible to throw off the beam timing. beam advances 1/256th of a scanline per rendered dot (that is, dots that are not h-blank). All that changes is that 512 pixel modes output twice per dot. The counters still move just like 256-pixel mode, and beam timing should respect that...

MAME's H and V counters are strictly in terms of real pixels. That said, I had passable raster timing working previously in the driver (not enough for hardcore, but it passed the various checks in the famous Electronics Test) so some /2s sprinkled around should at least restore that state of affairs.

I don't think you're going to be able to fully duplicate the SNES H/V counter behavior by using what's built into MAME. There are some really odd things, like scanline 240 on non-interlace odd fields on NTSC sets missing one pixel (something to do with color burst, I've been told), and dots 323 and 327 lasting two clocks longer than the others (except on the short line mentioned above.)

Really, the PPU and CPU need to run on their own clocks, and you also have to support the bus communication delays between them, eg CPU write to a PPU reg takes 6 clocks to acknowledge, where a read takes 2 clocks to acknowledge.

Without this stuff, you won't be able to make use of most of my regression test ROMs
Those will save you a ton of headache with IRQ / NMI bugs.

Yeah, I've got to be honest here: I once tried to make some improvements to the MESS SNES driver's video hardware emulation. I ran, screaming, within 5 minutes, because it has practically no similarities to any other emulator's codebase.

I'm pretty sure that devices can have their own clocks now, so I dare say that the driver would seriously benefit from just scrapping the entire video hardware emulation and duping the g65816 core into an S-CPU core, and then trying to take as much of bsnes's code as possible.

I'll leave aside the part where you're screaming from the rooftops that Kale and etabeta suck and focus on one fact: MAME/MESS architecturally cannot achieve full bsnes level accuracy as is and I'm not convinced that should be the goal. Yes, we can get much better CPU timing than we have now and that's important, but from what I've seen commercial games are generally a lot more forgiving then byuu's synthetic tests.