MAMEWorld Forums - EmuChat - Re: Undumped earlier Sega Hang-On revision

> My general impression is that a lot of drivers
> in MAME have been written more by bashing away against the games than from testing
> and verifying behaviour on the hardware.

That's correct, the majority of the emulation in MAME is figured out from game behavior, with a sprinkle of testing for some of the more non-obvious cases, but even then we don't have all the behavior perfectly nailed down (hence why even things like Sega System 32, and Jaleco Megasystem 32, where hardware tests were done, still aren't properly understood)

Things like sprite limits, edge cases and other hardware limits (waitstates, hardware DMA delays etc.) are rarely measured or implemented.

I know somebody did some tests with the Taito L hardware not long ago and documented some interesting findings about the behaviour of certain opcodes on certain regions, although due to the way the Z80 core is structured it couldn't be easily implemented.

> I'd like to start more fully documenting
> some of these physical chips, and mapping out all their behaviour in various corner
> cases by constructing test programs to run on the physical systems, and publishing
> notes of my findings.

Yeah, that makes a lot of sense. I'm actually hoping MAME moves in a direction where if somebody writes comprehensive test software for a certain platform it can be included as to do regression testing against etc. That kind of thing is just as important as the actual games.

> At this point I've got most Sega arcade systems starting from
> the System 1 through to the Naomi 2. I've got a bit of an affinity for the
> 68000-based platforms, but out of curiosity, if you could pick any Sega arcade
> hardware to more fully verify its behaviour on the physical hardware, which one would
> you pick?

There are a number, things like System32 and Multi32 I'd definitely like to see 100% figured out as right now we still have video effects missing in Golden Axe ROTD (light turning on / off in caves) as well as holes in the background in places for Rad Rally / Rad Mobile and on Title Fight (Multi32) the background has been broken since the previous rewrite. Charles did a lot of documentation of the platform back in the day, but either some bits of it have been misinterpreted / implemented incorrectly or there are still gaps in the knowledge.

Really tho, take your pick, I'm sure there are things that haven't been fully documented for all the platforms.

Outside of Sega, the Taito systems like F3 need further testing, MAME's emulation is still lacking in places. Even a lot of the older Taito boards aren't fully understood. Plenty of the Jaleco and Namco systems have surprisingly weak emulation too, eg. even for Jaleco Megasystem 1 things like the raster interrupt effects aren't emulated (although it isn't clear if the protection devices are interfering with that) SNK's Hyper Neogeo 64 is a beast too, the driver there is almost entirely guesswork and the games make rather conflicting use of it.

but yeah, any kind of work in the field you're talking about is welcome, because while consoles tend to be comprehensively documented (because they need to be due to the sheer amount of software) most arcade stuff has not had that level of research applied.

even outside of arcades some of the less popular platforms are poorly documented, the Super A'Can is a fascinatingly flexible system for example, but the games make sure weird and inconsistent use of the hardware it's been virtually impossible to tie down specific registers to specific behaviours, or understand if some of the stranger modes it uses are just one-off hardcoded modes, or part of some more complex setup (eg the 1bpp mode used for the startup logo)

anyway that's drifted a bit off-topic, but yeah, there's a HUGE window for anybody still wanting to do actual hardware research and either document it or improve MAME directly.