Jets from Emu-France and Layer from Neo-Arcadia recently teamed up to dump a Japan set of Gang Wars, this prompted me to look into some of the currently logged bugs on Mametesters.
It’s fair to say that Gang Wars isn’t really a memorable game for any of the right reasons, but the driver still deserves some attention. In present versions of MAME when you get to the 3rd stage of the game you see the following, with the ‘World’ version on the left, and the ‘US’ version on the right.
As you can see, in the World version the ‘On The Way’ sign has corrupt lines going through it, on the US set it’s missing entirely.
The issue with the World set hasn’t always existed, for a long time the World set was a ‘bootleg’ set, using bootleg graphic ROMs, but a real World board was then dumped (including Mask ROMs for the graphics) and it was discovered that the program ROMs matched the already supported bootleg set, so the bootleg set was removed. Anyway, the source of that problem is actually simple, one of the newly dumped MASK roms was a bad dump, and has a ‘fixed bits’ problem in the first couple of tiles, it slipped under the radar when it was added (likely my fault)
A fresh dump of that ROM reveals it to be the same as you’d get if you combined the bootleg roms.
with that ROM being used the World version of the game now looks correct again
The issue with the US set is a little different. Those graphics aren’t actually used in the US set because when the US set was produced they made a number of enhancements, first of all they translated all the speech (the World version still plays Japanese speech samples for the story) and they polished up that sign post too, replacing the ‘ON THE WAY’ graphic with a more logical ‘ONE WAY’ graphic. Obviously they didn’t / couldn’t change the MASK roms for this, so instead they changed the 4 additional socketed graphic ROMs.
The World / bootleg versions have the following tiles near the end of the ROM (see position 9 on the first row)
The US set attempts to draw this sign using the tiles from this position in ROM, which obviously gives the incorrect results you see at the start of this article. A dump of the graphic roms from the US set shows that the tiles in these positions have been changed.
Using the correct graphic roms therefore gives the correct results for this scene in the US set too.
The newly dumped Japan version is like the World version, but with the story / power up screens shown in Japanese. It has the ‘On The Way’ sign.
One thing that did cross my mind is that maybe some of the MASK roms for Gang Wars were manufactured in a defective way, it could explain why they decided to move those tiles in the US version, however that theory doesn’t really hold weight because they still use some of the ‘blank’ tiles surrounding the sign from that part of the ROM (and so would stlll have graphic corruption) It’s most likely just coincidence, we’ve seen the first part of roms read badly (or simply go bad) in the past.
I’ve also readded the bootleg set, even if for all MAME purposes it matches the ‘World’ set aside from the split graphic roms. It has the potential to be interesting later on however because these Alpha bootlegs tended to use 68705 MCUs instead of the regular Alpha ones. We’ve seen this on a number of the boards, and for Kyros we actually currently load 2 MCUs
// not hooked up yet
ROM_REGION( 0x1000, "mcu", 0 )
ROM_LOAD( "kyros_68705u3.bin", 0x0000, 0x1000, CRC(c20880b7) SHA1(b041c36cbc4f348d74e0548df5cb14727f2d353b) ) // this one is from a bootleg PCB, program code *might* be compatible.
ROM_LOAD( "kyros_mcu.bin", 0x0000, 0x0800, CRC(3a902a19) SHA1(af1be8894c899b27b1106663ffaf2ab43fa1cdaa) ) // original MCU? (HD6805U1)
Eventually we should support these as 2 sets, each with the different MCU hooked up, but for now we just simulate the MCUs so it doesn’t matter.
What? Someone actually fixing bugs in games instead of pointlessly refactoring shit that doesn’t matter while introducing regressions?
You don’t say!
as if the refactoring of midas video would not have fixed any bugs, or if the refactoring of amiga devices would not have allowed for these
http://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=94302#Post94302
http://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=94337#Post94337
http://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=94360#Post94360
or if the msx refactoring would not have fixed emulation in hx23, hbf9sp, fs4500, fsa1fx, tpp311, tpp312 and more…
and no, neither of those was possible without some refactoring
oh god, if people would try the emulator instead of brainlessly repeating what they have heard…
What have you done…
The Amiga changes are neat, but our base Amiga emulation is still so shitty (easy to gauge by game compatibility) I’m not sure that many people are going to care just yet.
Emulating all the bits people don’t care about while getting the basics wrong is unfortunately something MESS has been very good at over the years and can be applied to an awful lot of the systems in there; like I’ve said before with the SNES etc. it doesn’t matter how many fancy add-ons you make work with the slot system people are going to hate it if it still falls over it’s own arse completely running Super FX games like Super Mario World 2, if anything they grow to hate the refactoring more because they associate it with no visible progress being made.
Likewise very few people are going to care if 100 MSX models run in some form, they just want to see one that actually runs well with a high level of compatibility when it comes to the games etc. (although for a plain MSX we did a fairly good job last time I tried) Don’t get me wrong, personally I’m enjoying seeing all the different models start to do something.
I can kinda see where the OP is coming from tho, an awful lot of the development cycle over the last year has simply been ‘refactor then repair’ with the ‘repair’ bit sometimes taking quite a while. People are saying it, not because they’re just repeating it, but because it’s kinda true and what they’re observing. I’ve had to apologize / point out that 0.153 is ‘broken’ for classics like Galaga several times now when people have reported the ‘stuck in service mode’ bug, with the latest instance being today. ( http://forum.arcadecontrols.com/index.php/topic,139286.0.html )
It’s true however some of the refactoring does fix bugs, that’s why I do like to highlight it here, although I guess most people would consider it a waste of my time to have fixed a stupid bug in the Midas games with that refactoring, or the later levels in the US Pushman sets with that merge / refactor too.
Just because somebody is being critical of things you can’t really rule out them having a point, the way a lot of the userbase sees things, and prioritizes things is very different to the team and I find it difficult to believe you can’t sympathize with the point being made on some level. Back to the point about Galaga, I’m sure most users would consider having such a game in the currently offered binary to be a critical problem, one that should be resolved swiftly, instead the team don’t seem to care much and either expect people to compile their own with the fixes, or wait several months for a new fixed release. The result of this is people are going to find out what caused it, see that it was some refactoring, and think that refactoring is bad, and that the team have lost the plot by not taking the bug seriously enough to offer a fixed binary.
Refactoring is always painful. However, it is the way forward. As you have pointed out on many posts it lets re-use happen more easily between the systems. It will shine a spotlight on areas where there should be code re-used. I was just happy to start to see it showing its stuff. Its been a rough year.
With something like galaga getting stuck shows something a bit more fundamental going on. At *least* run the code you just change before checking it in (not saying you did this haze). If you have people doing that you may want to add in some simple tests for the ‘top 100 must run stuff’ or you will continue to have people breaking things like this and no one finds out until release week. I myself long got over ‘oh its just one line’. Lack of automated testing is going to hurt you guys in the long run with continued instances of things like galaga being broke. The downside is *no* one likes to write the tests. The are boring and prone to breakage and even worse a pita to add after the fact.
Well I’m sure whoever did the Galaga change did run it to test it, the problem came down to something being uninitialized, so the error doesn’t always show up for everybody, but more annoying for those who experience it the behavior is random and therefore not easy to understand.
I made a similar mistake with the Midas stuff actually, there was one NeoGeo bank register I forgot to setup properly, didn’t notice it here, but AWJ caught it his end.
The main thing end users aren’t going to understand is why we haven’t tried to put up a replacement version as quickly as possible tho, and until we do people are going to keep downloading the broken versions and find them to be broken, and when you’re talking about classic games like Galaga that doesn’t go unnoticed.
Actually, we do have (semi-)automated regression testing, done by Tafoid. It was invaluable during the 0.153 cycle; without Tafoid’s weekly regression tests, the current official binaries would be much, much more broken than they are.
However, automated regression testing can’t catch everything. Specifically, the galaga regressions were caused by uninitialized variables, so differences between operating systems, compilers, and runtime environments (e.g. the difference between a -bench run and a regular run) can change whether the code trips up or not.
If you look at the SVN log over the past month, you can see that Firewave has been doing a ton of (presumably very very boring) work fixing uninitialized variables throughout MAME, so future releases will hopefully have fewer regressions like the 0.153 galaga one.
I noticed an anomaly recently that effects several drivers (possibly even more) relating to cpu usage.
For some reason metro.c, hyprduel.c, seta2.c, ssv.c all want to take up around %100 of the the cpu
Now I know mame is about accuracy above all else, but by comparison other drivers like cps1.c, cps2.c, cps3.c, mysticwar.c, macrossp.c ..etc are exceptionally well-behaved and only use between about %40-70.
This is using an old Core2Duo laptop from 07 with 2GB ddr2 running SDLmame on osx 10.6.8 using activity monitor to look at cpu usage, using a 64 bit clean build.
Actually started to notice this behaviour in these drivers sometime in the mid-late 0.140’s, but just assumed it was a consequence of refactoring a would get smoothed out when it was done.
I realise this isn’t the most scientific of tests, but I thought I’d mention it here in case it might be indicative of a bigger problem that might have gone unnoticed by people using more powerful hardware that might not make the differences as noticeable.
I’m a little surprised metro.c pushes your C2, hyper duel does seem to have slowed down quite a bit tho (they really abuse raster effects, and it needs tight sync, although the current performance doesn’t seem quite right)
ssv will vary wildly, some emulate the MCUs for protection which really drags things down.
seta2 can draw a lot of zoomed sprites and can be slow on startup when they do ram checks does seem a bit slower overall than it used to be tho but again I’m surprised it pushes a C2.
I spent a bit more time doing some digging..
Seta2.c
High cpu usage across most sets especially noticeable in grdians & gundamex.
cpu usage is about 60% at stratup quickly rising to over 100% during attract sequence. Sound becomes noticeably crunchy in grdians.
ssv.c
Actually well behaved in most sets stays around the 40-50% mark, with the exception of twineag2, drifto94, stmblade which climb to around 90-100+%
na1.c & na2.c
High cpu usage in all sets. With sound becoming crunchy and distorted in fghtatck.
nb1 & nb2
High cpu usage in all sets, with sound distorted in nebular, machbrkr.
hyprduel.c
hyprduel is particularly abusive to the cpu, magerror is still around 80-90%
metro.c
Is actually the most puzzling as most of the games on the 12mhz 68000 version of the board (pangpoms, gunmast..etc) are getting excessively high cpu usage in the 100’s without any noticeable sign of a struggle with sound or framerate, however msgogo & gcpinbal are less abusive.
Hope this might at least be of some help.
Although I guess it’s kind of stating the obvious – “drivers that have popular games, that receive a lot of attention run beautifully drivers that don’t have as popular games or receive much attention degrade”
>> ssv.c
>>Actually well behaved in most sets stays around the
>> 40-50% mark, with the exception of twineag2,
>> drifto94, stmblade which climb to around
>> 90-100+%
these are the ones where the MCU is emulated, note the extra CPU in the list.
>> hyprduel.c
>> metro.c
I think it’s probably when the drawgfx stuff (and sprite drawing) were refactored because the old method Luca coded was declared an abuse of the system.. can’t think of much else that’s changed recently.
>> na1.c & na2.c
>> nb1 & nb2
the dynamic graphic decoding is used extensively with these, maybe it’s also become more expensive?
namcona1.c and namconb2.c just got a huge speedup from r30579. And the MCU is *still* the single largest entry in the profiler; I’m going to see if I can speed it up more with some inlining.
r30579 does seem to have made a difference to namcona1.c and namconb2.c.
Cpu usage is still high, but nebular, machbrkr run much smoother till the huge cpu spike as the mach breakers title screen zooms in.
I rolled back to the 0.130’s and metro.c was still quite greedy, it’s possible it’s always been a bit like that, Hap even comments on the driver having become a bit of a mess as new additions have been made here.
http://mametesters.org/view.php?id=4561
Turning off -mt also seems to improve cpu usage.
the metro issues talked about there aren’t with the CPU requirements, but instead relate to the actual game performance (irq generation being wrong can cause things to run at the wrong speed even when 100% is displayed)
it does seem to have dropped recently, and could probably be better optimized however.
re: na1, Nebulasray has other issues at the moment, the music / sound appears to be very wrong again.
You’ll probably hate me for saying this but I was also looking at trying to find out how the extra fancy scrolling on the backgrounds is done, performance will probably get worse again if I figure that one out (so far no luck tho ;-)
“If you have people doing that you may want to add in some simple tests for the ‘top 100 must run stuff’ or you will continue to have people breaking things like this and no one finds out until release week.”
Everyone will have a different opinion about what the top 100 must run stuff is. Galaga wouldn’t make mine.
The only way to get what you want is to start release branches and then test those and fix minor bugs while trunk is progressing. Nobody is available to do that though and I’m not sure whether anyone would want to be running months behind trunk.