David Haywood's Homepage
MAME work and other stuff
April 5, 2012 Haze Categories: General News. 21 Comments on Get Over Here!

Emulating Fruit Machines is in many ways a process quite different to emulating a video based system. With video based systems you tend to get obvious large ranges of data writes relating to sprite lists, tilemaps, palettes and the like which usually allow you to make easy headway with the drivers, leaving the trickier more intricate IO details for later.

Fruit Machines are the opposite way around, they’re primarily IO, and if you don’t get that right, you don’t see anything. Almost everything is driven through ports, data often doesn’t get written at all unless status bits are correct, and you’re dealing with interrupts from multiple sources rather than having an obvious ‘trigger every frame’ vblank interrupt.

Thankfully there was a lot of part reuse, and for the majority of cases the boards are stacks of off-the-shelf components, for which documentation is available, and many of the needed components are already emulated in MAME, although not always to the required level.

One of my initial goals is to at least get everything doing *something* Allowing sets to run their ROM/RAM tests is good for sorting things out, and providing a base for further progress to be made. If they test other ROMs like their sound roms that’s even better because an awful lot of these fruit machine dumps are missing their sound roms, or have been paired up with the wrong ones, and it helps to know.

One of the systems I’ve been looking at a little bit lately is the Scorpion 4 one, it’s been emulated elsewhere for a while, and uses a 68000 based processor which makes it easier for me to work with due to familiarity. It’s not all plain sailing however, the 68000 it uses is actually a 68307 which means it has a number of onboard peripherals in order to simplify the actual PCB designs. These include a timer unit, serial unit, custom interrupt controller and hardware for ‘memory protection’ In addition there are other similar peripheral chips on the actual board, all of which need emulating properly.

Scorpion 4 Motherboard (source unknown)
Scorpion 4 Motherboard

It’s quite a cute looking board with the colourful dipswitches, and as you can see there are only a handful of actual components on there, with the 68307 doing the majority of the work. All the additional hardware driven by the board plugs into the various ports positioned around the edge (lamps, reels, hoppers etc. all marked near the connectors) with the game card and optional graphics expansion board going in the slots near the CPU. One thing to note, the sound chip (a YMZ280B) is on the game cards, odd design choice, but there you go.

I’ve spent the last couple of days stubbing up support for some of these and hooking up devices and peripherals that we already emulate to the driver, including the VFD ‘display’ which is on one of the ports. Quite a few things, including the timers and interrupt generation are hacked up for now, but it at least gives up a few pictures of the system booting and testing the game ROM + sound ROMs. I also had to fix up an issue with the YMZ280B data readback, which could have potentially crashed anything else in MAME using that chip and attempting to read the ROM data!

Fever Pitch
Fever Pitch

Fever Pitch

Fever Pitch

Fever Pitch

Fever Pitch

The majority of games have a 4 letter manufacturer assigned game code, and 8 digit ROM code associated with them which matches what’s printed on the ROM labels. This is important because there are many, many sets for each game to comply with different regulations, or use different additional hardware.

Lucky Balls
Lucky Balls

Crazy Climber
Crazy Climber


Club Class
Club Class

South Park
South Park

Obviously not much to look at, and if you want to play these things you’re still best off using the existing emulators for now, but it’s a sign of some progress being made. Most of the sets which boot this far complain about the reels, or meters, which I believe should be the same as the older Scorpion 2 platform, meaning much of the code is already there.

Roughly half the games in the driver don’t at all boot yet, they appear to be communicating with a different kind of VFD, or don’t use one at all (it isn’t actually visible on many of the cabinets anyway, but provides useful diagnostics information) Quite a lot complain about missing sound ROMs, or bad sound ROMs, although having them boot this far has allowed me to sort out a good number of the ones which were just being loaded incorrectly.

Some people still seem to be under the impression that these things can’t be emulated further than this, but if you’ve been following MAME you’ll have seen several recent additions of non-video games. Robbie‘s work on Janken Man for example shows a non-video game using the MAME layout / artwork system. ’30 Test’ is another recent addition along similar lines. The existing system might have it’s limitations but is clearly capable of providing the basic framework needed for any non-video based system as long as it isn’t depending on physical elements which none of the fruit machines really do.

The Scorpion 4 motherboard did actually have a video expansion available for it, known as the Adder 4. This adds an additional 68340 processor (similar to the 68307 but with more complex peripherals and a 32-bit core like the 68020) Only one Adder 4 game is fully dumped (Skill Dice) but that will be an interesting target in the more traditional MAME sense once the basics are all emulated.

I’ll probably continue to work on this for a while (ideally I’d like everything in the driver to display *something*), then possibly bring another driver or two up to a similar level. Progress is admittedly slow (it’s more or less only myself and James Wallace looking at any of this stuff) but I’d like to see various drivers getting to a stage where there are enough good visual indications if changes being made are correct or not because this will make it easier for others to get involved if it takes their fancy.


You can follow any responses to this entry through the RSS 2.0 feed.

Very interesting stuff… never thought I’d see this sort of thing in the main MAME project. Hopefully the more progress is made the more it might stir up some interest from new external contributors. Especially anyone with the desire/vision/skills to overhaul the current artwork system into something more advanced/flexible.

All pinball games will have Artworks?

This post isn’t about Pinball games.

is very interesting how work this system, is possible this in others romsets or drivers working with the same options

Get in, thanks Haze.

It’s interesting to note, that despite the very neat looking connections and organization on the PCB the actual mapping of some things (especially the reels!) is all over the place.

The board has 2 output connectors
Reels A,B,C
Reels D,E,F
(or 1,2,3,4,5,6 as I’ll call them from here)

Each reel needs 4-bits to drive

Reels 1,2 are on Port A of the 68307 SIM unit (2x4bits of an 8-bit port)

Reel 3 is on Port B of the 68307 (4bits of a 16-bit port, other bits are used to drive the VFD and such)

Reel 4 gets mapped in a general purpose area near the volume control, hopper writes and data recorder

Reels 5+6 appear to be connected to the 68681 duart (near the CPU)

The Optical readbacks I think are all connected to the duart.

So while the PCB design appears to be neat it doesn’t correspond quite as neatly to the actual addresses used!

Of course not all games have 6 reels connected, most will have 3 main reels + maybe an optional spinner for the bonus games so it might be possible to get away with not mapping everything quite yet.

I’ll do another update on the reels later anyway, it’s an interesting subject area, and one which surprised me a lot when I started looking at these things (from a HW and SW point of view they weren’t designed at all like I was expecting!)

Oh sorry.
I think will be the same, as we can see.

That is kind of interesting. So does any of the software act differently depending on what is plugged in? Like does it act different if reel 4-5 is also plugged in vs just 1-3?

Well it will no doubt complain that the reels are missing if it needs them ;-)

Beyond that I don’t think there are any games which attempt to ‘detect’ the hardware they have connected and adapt the code-flow to match, although it would theoretically be possible (and they could probably have produced far less romsets taking that approach although I do wonder if regulation laws mean that every set has to be tailored to the specific hardware it’s meant to work with)

“I also had to fix up an issue with the YMZ280B data readback, which could have potentially crashed anything else in MAME using that chip and attempting to read the ROM data!”

For those of us who don’t use MAWS much, are there any games we might recognize that use the YMZ280B?

It’s good to see your work on this producing nice side benefits. Which I think you predicted anyway. :)

It’s a fairly common chip used on the likes of Kaneko Supernova, some Raizing titles, Tecmo System etc.

It’s doubtful they use the readback anyway (although I guess something somewhere did hence there being code for it in the first place, probably in MESS?)

The fruit machines very much use the readback to ensure you have the right sound roms installed and refuse to even attempt to play sounds if you don’t!

Good to see, its cool how the VFD display can also help clean up the dumps even more

Unfortunately the current submission delays are slowing down progress even more here.

In order to develop reliable code, and make sure I don’t make any bad changes I need my code putting in the main tree fairly quickly to create checkpoints (makes for easier regression testing etc. too) Currently there seems to be a ~48 hour delay in anything I send which means for every day of work I do on this I’m waiting 2 days for it to be added.

When there are only bursts of time in which I feel like looking at this stuff that means a lot less gets done than could be done.

It seems there are still big issues with trust in Mamedev, all relating to the fear of having to revert something bad after the crap that kicked off when I did that in the past (and why I was stripped of my SVN write access in the first place, reverting somebody’s bad code who then kicked up a fuss…..) In the end all they’re doing is hindering progress on the project tho. I thought the entire point of an SVN was to be able to track changes, pull the source at any point, and revert bad changes while leaving them in the history if somebody wants to review them again later, but whatever…

This doesn’t really cause problems with regular sized submissions which aren’t part of something bigger, but when trying to work on significant changes such as the ones required here it becomes an issue due to the number of areas changing and desire to make changes easy to follow for other developers.

(and if I just keep working on things in my own time when there are other big changes going on, as there are at the moment, it tends to result in messy merge situations, and things breaking)

anyway, flipping the topic, hopefully the final revision of the new CHD format is checked in now, and SHA1s in MAME/MESS will be updated over the next few days where they need updating.

I don’t know if the hanging issue when converting some HDDs has been fixed yet however, it doesn’t seem to be obvious what’s causing it and it’s completely random.

I think for people dumping real drives CHDMAN should have a ‘safe’ option, whereby threading is turned OFF and only the most basic compression types are used, this would ensure dumping is still fast and the files can be recompressed later. The last thing you really want to be doing while reading a HDD is taxing other parts of the system as well (potential errors introduced through overheating, possibility of drives failing if they’re old and powered up for too long etc.)

The requirement of some Linux distros to use build in libraries for FLAC / LZMA etc. does still concern me, because if the formats change with new versions it’s always possible it will create incompatible files, linking against the actual versions we provide is a lot more sensible because it’s under our control, and if we upgrade the encoders / decoders because of significant change we can also bump the format versions.

The “is LZMA worth it on CHDs” debate is an interesting one too, FLAC gave big margins for improvement, as does ECC compression on images with ECC data, but the LZMA margins are small and it is quite a bit slower when dealing with lots of small bits of data (I guess due to dictionary allocations frees for every call) Shared dictionary isn’t an option because blocks shouldn’t be depend on each other. Overall tho it doesn’t seem to have any noticable impact on performance compared to the actual emulation requirements, so it may as well be used.

The CD format will probably need to be bumped again some point down the line to better handle seek based protections, at the moment to get the seek data from a hunk you have to decompress the entire hunk, and because the drives can read this data very quickly when seeking it should probably be separated from the main decompression, otherwise things will be slow (even with standard zlib compression) That’s not a change likely in the immediate future tho IMHO.

Ok, it seems RB has decided that 0.146 will use a mix of v4 and v5 CHDs, so I won’t be updating the SHA1s ;-)

The MESS Saturn softlist you talking about? (/confused)

The MESS lists are mostly fine, only a handful of CHDs used the old (bad) metadata, 99% of images convert to v5 just fine. The ECC stuff just added will help compression in them tho :-)

MAME has a LOT of sets with bad metadata because people making the CHDs used ancient CHDMAN versions which produced bad (but still working) files and nobody picked up on it. Those ones (where the SHA1s change on updating) should be left in V4 until they’re redumped properly.

just see RB’s update really :-)

I just I update the CHD’s when you have the correct crc to do that. Some people have updated almost everything.
Maybe still having problems in the future.
I just upgraded everything that crlmamepro spent the chd’s for the backup folder. So becarefull.

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.