Home Page Forums MAME MAME SVN builds - new driver flood

At least in Zero Wing, it seems some weird z80 reset - 68k timing issue. The z80 seems to be running while the 68k is writing stuff to the shared ram but timing causes the z80 to screw up it's own ram in such a way that it enters an infinite loop.

Ahh. On real h/w the Z80 must be halted for the 68k to access that RAM. There's a register the 68k writes to halt the Z80 and grab it's bus. That must be what's gone wrong.

Yeah, but inverting that behavior of that register does not fix it

I'm not in a position to be able to test and fix everything. I've documented the reasons for this before, ie, I have little desire to maintain trees for 2 projects, and can't work well without my fixed set lists.

For that reason, it's all yours / whoever wants to fix it. AFAIK it worked fine last time I checked it, and all the flags to halt / resume the z80 / 68k depending on accesses are full implemented. If somebody has broken it since then however, I can't tell you.

I remember your reasons, so I won't try to make you change idea. however, I wanted to add that, since last time you looked at it, I re-factored a bit the source and now MESS code is much closer to hazeMD.

MESS only defines the memory map and input handlers [1] in mess/drivers/genesis.c and then uses mame/drivers/megadriv.c for everything else. mess/machine/genesis.c only contains local code for cart loading and sram handling (which basically do not affect any other aspect of the main emulation).

therefore, if you ever get back to megadrive in MAME, MESS can inherit any change with no additional efforts!


[1] this is needed to offer options between 3-buttons pad and 6-buttons pad

I'm willing to bet that if I grab the current Mess code, and unzip it over my current MAME tree / any current SVN build, then all hell will break loose.

This means that unless I create a specific tree for working with Mess, which I don't sync to the MAME SVN, then I can't work on MESS. That means having to manually merge back in changes, and not being able to test the MAME/MESS side of things together in the same tree. It's also extra effort, and generally annoying.

The projects should co-exist in the same tree *somehow*, and should always compile, major changes should be made to both projects at the same time. Developing things which share code is more difficult than it needs to be otherwise.

For systems where it's appropriate MESS should have set lists like MAME in addition to the current open ended approach (which is ueful for homebrew & systems where the media isn't really 'fixed')

I don't dislike MESS (some of the recent changes have been very impressive thanks to Judge etc.) but it simply doesn't fit in my development methodology.

Sorry if others disagree, but that's just how I see things.

This is perfectly fair. And as I said, I didn't want to force you to change your mind.


If you means: grab current MESS genesis code, you're true. you need a complete MESS tree to test the changes.

if you means: grab the whole MESS tree, you're wrong most of the times (unfortunately, these days you would be right due to the malloc changes)

my point was: if you keep two separate source folders, you make changes to megadriv.c in MAME and you copy it in the MAME part of MESS source, you can compile and test the results without the need of any change in the MESS part of the source (except if you want to change the memory map). earlier, you would have needed to tweak more MESS files.

In general, MESS source is sync'ed right after an intermediate update happens to MAME. this means you have de-sync'ed sources for more or less 7 days and it only greatly affects development when Aaron does huge changes (like the malloc ones). Usually, copying any MAME drivers and/or machine change (like any megadriv.c one) directly into the MAME part of MESS source and recompiling work like a charm.


As a first step in this direction, we could add a warning (a red screen?) when a known bad dump is loaded. We have .hsi files for reasons like these. And adding fixed lists to the current approach (without replacing it completely) is possible as well, it just requires some more coding.

replace 'these days' with 'quite often' and you'd be right. Significant changes are seem to be being made more often than not. As soon as I dump MESS in a MAME tree it means I can no longer update that MAME tree from SVN due to the chances of everything breaking.

This has been the case the last 5 or 6 times I've decided to take another look at MESS. Call me unlucky with my timing, but that's what I've found.

There are also a couple of changes in mame files which are local to the mess tree. The number of changes is low and should eventually be cleaned up such that the differences are only in the mess files. One of these things is the 8042 keyboard controller code. These are usually not the cause of builds breaking though.

The bigger mame changes do tend to break building of mess but these issues usually get resolved by the time the regular uX update gets applied or reasonably quickly after the update is applied. From past experience, I'd say about 1 out of 3 uX updates break a straight mess build. So I can imagine Haze being unlucky with the updates of his source tree. Also there the situation is improving with cleaner code in mess and more shared devs between the two teams.

Anyway, back to genesis/megadrive: There are no obvious changes to the code, the reset handling all looks ok, so I don't have an idea what is wrong.

In Zero Wing I see the 68k switching off the z80, copying a bit of z80 code, turning the z80 on. When the 68k starts copying some more z80 code it seems the z80 _is_ running, but looking at the writes to the z80 reset register it should be running. Perhaps a bug in the original code which just happens to work on real systems?

a lot of the games have buggy code, yes. In some cases it just happened to work on the real hardware. (In others, it did if you were lucky, but if you ran the game on a different model it would fail)

One of the sound programs a lot of Accolade games use for example checks completely the wrong flag and instead of reading the z80 status, actually does an open bus read.

I wouldn't rule out Zero Wing having some buggy code, but OTOH I can't remember any problems with it.