Archive for May, 2014

I’ve been spending a bit of time looking at the various Tecmo drivers (hence asking if anybody has an original Final Star Force video) and decided to look at the ‘Master Ninja’ bootleg while I was at it. There were various issues in MAME, and still are, however I’ve improved the sprites so you can actually play it now.

it turned out that the sprite system was actually the same as the ‘Dragon Bowl’ hack of the game, while the game code is clearly derived from the World / European ‘Shadow Warriors’ release. it’s possible the bootleg is part of the chain between the original game and Dragon Bowl; the tilemap handling is also the same as Dragon Bowl. I’m guessing neither game supports the ugly blending effect the original has when an enemy is lying dead on the ground and about to vanish.

While I was doing this I noticed that the game tells you to ‘INCERT COIN’ and was wondering if any of the sets had this corrected, they don’t not even the Japanese release which is dated 1989 on the title screen instead of 1988, I guess they didn’t care or didn’t notice, but it’s unusual to see such a common message mangled like that. Here are the various title screens for comparison.

As you can see the bootleggers actually drew their own logo using the basic Shadow Warriors one as the starting point.

I still need to figure out what sound system the bootleg uses and tidy up the code.

(and yes, I know somebody is bound to ask about Automat in the comments ;-)

UME is the complete/combined version of the MAME / MESS project.

There was a mixed reception to the previous post about the new colours for Nemesis etc. They’re not going to be reverted (the new code IS more correct even if some people apparently don’t like it as much as the old hacks) but if you want to try them yourself here are some new binaries. I was going to post some at the time but ran out of time to do it.

0.153ex4 is built from SVN revision 30687

UME 0.153ex4 Windows binaries – 32-bit, 64-bit and all tools
UME 0.153ex4 sources

Here is the 0.153ex3 to 0.153ex4 SVN log

other misc binaries (if you don’t know what these are you don’t need them)
Split MAME/MESS 0.153ex4 binaries (32-bit and 64-bit builds) are here
UME/MAME/MESS 0.153ex4 binaries (32-bit and 64-bit) built with Intel C++ Compiler 14.0.3.202 Build 20140422 are here
UME/MAME/MESS 0.153ex4 binaries (32-bit and 64-bit) built with Microsoft C++ Compiler 18.00.30501 (VS2013 update 2) are here

Points of Interest

As mentioned above the main reason you might want to give these a test-drive is the new code for the Nemesis colours, as covered below, however there are some other things worth talking about.

There have been a number of additional regression fixes etc. from the team submitted over the last week or so to combat issues caused by recent refactoring so these builds should be once again more stable than the last ones. Work has also continued on the MSX and Amiga driver reworking, check the change logs for details there.

One thing that seems to have slipped under the radar on all the MAME news sites is Any’s dumping / addition of the Konami game ‘Step Champ’ This, until now, was an unemulated Konami competitive Minigame collection with a step pad a little like the Dance games they made so popular (and no surprise one of the mini-games is a dance based one)

Skeleton drivers for some later Stern Pinball titles have also been added lately, along with set-syncing against PinMAME, probably not the most interesting piece of news, but a lot of people might wonder what the bulk of the new additions are, so worth mentioning.

Sometimes I’ll use this blog to cover MAME updates that have nothing to do with my work, especially if the developers involved don’t have their own pages to highlight the changes. The following post is one such example of this.

As well as the impressive netlist work done for Pong (and Pong Doubles) Couriersud (along with AWJ) also took a look at the palette handling in the earlier “nemesis.c” driver games from Konami, a bugbear in MAME for a number of users due to the poor colour reproduction we’ve had for a while.

Really old versions of MAME used some palette hacks, these were incorrect, andwere eventually dropped from MAME leading to rather washed out colours in the baseline build. These hacks were allowed to live on in MAMEFX based builds, but unless you wanted to risk use of an unofficial build you were stuck with with the bad colours or old versions.

Correct colour reproduction in the driver benefited from Couriersud’s knowledge of discrete components, the actual PCBs used a rather odd setup resulting in an unusual gamma ramp for the colours. Working with AWJ this was correctly implemented in MAME, so all future versions will have correct colours again

Older MAME / MAMEUIFX (hacked colours)	Current MAME (bad colours)	Next version of MAME (good colours)

I’m always glad to see things like this improving in MAME.

The other reason for doing this update is I’m wondering if anybody has a Final Star Force PCB and can record the attract mode intro sequence for me and maybe make some close-up shots of other areas? I’m 99% sure it’s wrong in MAME, but need to know what it should look like.

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.

UME is the complete/combined version of the MAME / MESS project.

Some recent regression fixes have prompted me to put out a new ‘ex’ build, I’ll talk about them below.

0.153ex3 is built from SVN revision 30471

UME 0.153ex3 Windows binaries – 32-bit, 64-bit and all tools
UME 0.153ex3 sources

Here is the 0.153ex2 to 0.153ex3 SVN log

Also split mame/mess (non-ume) binaries of this revision can be found here

Points of Interest

As mentioned in the opening statement some significant regression fixes have gone in over the last few days. While the Amiga emulation has never been a strong point of MAME / MESS it had regressed to the stage of not even booting floppies (and several arcade games failing, eg. Upscope) in 0.153, those issues have been resolved by the developers over the last week. The codebase is now more flexible and more organized which should make emulating some of the more exotic add-on boards possible in the future (the base Amiga emulation hasn’t really improved much tho, so compatibility with games is still sketchy at best)

The reorganization of the MSX drivers continued as well, bringing those more or less back to where they were before the work was started too.

In terms of new additions I feel the most interesting one is ‘Coco Loco’ which Roberto mentions on his WIP page (I linked to the update in the comments of one of the previous updates)

This game is interesting because Petaco S.A were a Spanish company best known for their bootlegs but this (unless it’s bootlegged from a Console game?) appears to be an original rendition of Pacman, it also supports up to 4 players (one at a time, not simultaneously!) The gameplay (AI etc.) doesn’t really play like Pacman, and it has a ‘Speed Up’ button like a number of the Pacman bootlegs added so it’s interesting to see it in action.

Another piece of progress that has happened over the last week and is worth taking note of is the addition of Pong Doubles. This is the first discrete game other than the regular ‘Pong’ to be supported. Couriersud has been very busy with this discrete code, and it’s encouraging to see more titles working with it. The speed is understandably slower than Pong tho. (Please note, if you attempt to compile MAME with the Intel Compiler you’ll have to disable these drivers as it REALLY doesn’t like the way the Variadic Macros have been set up.)

The ‘midas.c’ driver was created by Luca a while back, it runs 2 games ‘Live Quiz Show’ and ‘Hammer’

One of the observations Luca made at the time is that the hardware was basically an enhanced clone of the NeoGeo, especially the video system which essentially worked in the same way but with some improvements (support for 256 colour tiles instead of 16 colour tiles being the main one)

There has been a ‘merge with NeoGeo driver’ note in the source for a while, and the game ‘Live Quiz Show’ had some noticeable graphic glitches on certain mini-games. I decided to find out if actually using the proper NeoGeo video code instead of the driver’s local implementation would help.

This required some refactoring of the NeoGeo video code in order to handle the different format graphics, and there were also a few other oddities I had to deal with such as the Y-Zoom table on the Midas hardware being uploaded by the main CPU rather than contained in a ROM.

Interestingly this uploaded Y-Zoom table ended up being the key to solving the graphic glitches, the table they upload is NOT the same as the regular NeoGeo ROM table, and treating the zoom as a simple linear zoom is what was causing the errors.

Anyway, with the NeoGeo sprites refactored to be a device, and the Midas sprites being a simple class inheriting the base NeoGeo sprite class with the various difference implemented there we end up with the following improvements. On the LEFT you can see the old glitched images, on the right are the images with the new code.

Comparison shots showing the bug fixed in Live Quiz Show

Less code, less duplication, less bugs, everybody wins.