Sometimes rare games show up when you least expect them to, not in expensive yahoo.jp auctions, just in the hands of good natured people who want to see them emulated.

Planet Probe falls into that category, a PCB was recently sourced by Alberto Grego, in Italy. Some had started to doubt the game really existed, and believed it to be a figment of somebody’s imagination, with the only reported sightings in and around Italy.

The board wasn’t in very good condition, booted, but was very glitchy, the roms were troublesome to read (Kold666 couldn’t get consistent reads, but thankfully f205v could) This game was very much at risk of being lost forever, but luckily all the roms still seem to be present, and the dumps correct.

One amazing fact about this game is that one of the Italian players ‘Bisboch’ actually found the high-score entry music so memorable he was able to compose a rendition of it 20+ years after playing the game as detailed here, the even more amazing part is that his memory was very close to being correct even after all those years; I’ll post a video with the second part of the update so that you can compare.

You may have noticed the game lacks a manufacturer in the copyright message, ‘so who made it’ and ‘is it a bootleg?’ become valid questions. Personally I don’t believe it’s a bootleg, the styling of the high-score tables hints strongly that the game was created by Orca / Kyugo who we know had a troubled past. The hardware turned out to be the same as Vastar, a game released by Orca / Kyugo under the Sesame Japan moniker, because Orca had gone bankrupt and they no longer had the right to use the name (according to the comments in mame.lst anyway)

I believe this game falls into the same category, it lacks a manufacturer simply because they had no trading name at the time they wanted to release it and were trying to sell it to potential distributors etc. Ultimately, based on it’s scarceness it appears nobody took this opportunity, effectively relegating the game to failed location test / prototype states or an incredibly limited release at best.

As you can see, there are some video glitches still, this is because the vastar.c driver doesn’t implement some of the tile flipping (large planet on the last shot) and the game uses a priority mode unused by Vastar and I haven’t determined the exact order of the layers yet. Once I’ve addressed these issues I’ll post a video as Part 2 of the update.

Thanks to everybody involved, especially Alberto Grego, hopefully he’ll be able to repair his PCB to working state :-)

UME (Universal Machine Emulator) combines the features of MAME and MESS into a single multi-purpose emulator. The project represents a natural course of development for the emulators which already share large amounts of code and is part of an ongoing effort to unify development efforts and provide a single emulation platform for users and developers alike.

0.147u2 Windows binaries (32-bit and 64-bit)
0.147u2 Source

What’s New

You can read the various whatsnew files on mamedev.org
From MAME, From MESS

Obviously UME contains all these updates

Points of Interest

Starting with things I’ve looked at / worked on…

Between 0.147u1 and u2, after much suggestion that I should take the Amiga drivers under my wing by R.Belmont I decided to take a look at why the Amiga 1200 didn’t boot, as well as add very preliminary (just one or two images for testing) Softlists to the driver, including system software, to make things a little more usable to people unfamiliar with the system. Unfortunately I’ve since decided to drop work on the driver because it seems to be rather ‘hot’ with more people complaining about petty things w/regards the changes I was making than actually contributing, despite nobody lifting a finger to work on it in the last 5 years. Between all that I did however fix the Amiga 1200 boot problem, so it now boots floppies, although like most Amiga stuff the compatibility is rather low. You can however have a bit of fun with Pinball Fantasies AGA now, which is in the softlist. Pinball Illusions was also added to the softlist, but is very glitchy, probably a good test case if somebody does want to start improving the driver tho (from what I’ve seen you could probably improve compatibility 4x with some very basic improvements)

Note, due to a current bug concerning Softlists and the new floppy code the only way to successfully run it is to tell the emulator that your emulated Amiga has 4 floppy drives, which thankfully the game supports.

ume64 a1200 -fdc:1 35dd -fdc:2 35dd -fdc:3 35dd pballfnapdy

will launch the PDY cracked version of Pinball Fantasies AGA from the softlist while enabling 3 extra drives, and automatically mapping the disks to them. For reference the non-AGA version was also added, if you fancy comparing then the following launch syntax applies (due to the same issue)

ume64 a500pl -fdc:1 35dd -flop1 pballfnt:flop1 -flop2 pballfnt:flop2 (for the first table disk)
ume64 a500pl -fdc:1 35dd -flop1 pballfnt:flop1 -flop2 pballfnt:flop3 (for the second table disk)

The automatic softlist mapping doesn’t work here because the game will only look for the first course disk it finds. Course disk 3 has further cut down versions of the tables for 512kb unexpanded Amigas and MESS doesn’t currently offer that configuration. Anyway for the interests of readers, here are the games running in UME / MESS (PBF AGA has a slight glitch when you lose the ball, not shown) AGA version which runs as of u2, on the right.

As you can see, the AGA chipset and extra power from the Amiga 1200 allowed for the same basic game, but with more colorful graphics, so it’s good to finally be able to boot it in MESS. It also saw a CD32 release, which is identical to the Amiga 1200 version but with CD music, however last I tried inputs in the CD32 driver didn’t work (probably an easy fix too mind you) The prequel, Pinball Dreams was also added to the general softlist and works (well at least the pirate version)

The Amiga wasn’t the only system to grab my attention during the u1-u2 period anyway. Part of what I wanted to do was add preliminary softlists to a number of other systems, to give people a starting case to create more complete ones as well as highlighting interesting / useful test cases for further improving the emulation while actually giving some of the MESS systems a quick run through to see how well they really worked. One of these systems was the Sam Coupe, an ill-fated machine released towards the end of the life of the ZX Spectrum, building on said technology while really failing to provide anything substantial over the previous machine or 16-bit competition which was rapidly dropping in price.

The first issue I noticed was that the speed had severely regressed, running about 20% speed on my machine, this was another victim of the more flexible, but ultimately rather useless in dynamic / run-time situations due to performance cost newer bank install handling, the same thing which plagued Wardner in MAME for a while. I improved this and added the demo disk for Manic Miner, as well as a cassette for Snare (found on the b-side of the Spectrum version of the game) to the softlist. The Manic Miner demo runs, although seems too fast due, probably due to missing waitstates. Snare fails to load (black screen after loading has finished) but both do show how the Sam had more colours and screenmodes available than the Spectrum. The driver however is in need of a lot of work by the looks of it and I’m guessing, like the Spectrum is going to prove to be heavily dependent on correct timings and wait-states.

To launch Manic Miner

ume64 samcoupe manic (to start the emulation)
then within the emulation Press Enter to get past the initial boot screen, then NUMPAD 9 to tell it to boot the disk

To launch Snare (non-working)

ume64 samcoupe snare (to start the emulation)
then within the emulation Press Enter to get past the initial boot screen, then NUMPAD 7 to tell it to load a SAM game from tape (I think NUMPAD 8 is speccy compatibility mode) You’ll also have to press SCRLOCK to turn off the MESS full-keyboard emulation, and tab into the menu to get to the Tape Controls and start the tape. Unfortunately it doesn’t get ingame tho, as mentioned

Hopefully somebody can build on this and produce a more complete Softlist with some more titles and useful test cases listed in it. It seems like support for one of the main SAM Disk formats is missing, and an awful lot of files out there are demo versions, even those in the Tosec lists.

I mentioned the Spectrum above, and that’s another system to catch my eye, having owned one growing up. The problem with the Spectrum is that in terms of hardware it’s about as simple as you can get (basically a single fixed position RAM based tilemap, no sprites) however much of the software requires absolutely perfect timing in the emulation, as well as various subtle hardware side-effects being emulated for special effects. This is a problem for MESS for two reasons, firstly there is no concept of blocking / waitstates, you can’t pause a CPU mid-operation and wait for something else to happen, second even with that you’d need a sub-instruction accurate Z80 core where the fetch / execute cycle for multi-byte opcodes was handled in realtime, not blocked together, until those things happen MESS is always going to lag severely behind to level of other Spectrum emulators released in the last few years.

I also had to do some work in figuring out which Spectrum emulators were actually worth using these days, as references to what should / shouldn’t work, and while using an emulator isn’t the best reference, it’s better than nothing.

That’s not to say I didn’t do some work on the Spectrum, first on the agenda was a code cleanup, the existing driver had a very large chunk of code, and the concept of an event manager to handle rendering of the border area on the system. In reality the border area is just the area around the tilemap part, it has a fixed colour determined by a 3-bit register, nothing more, nothing less. Special effects, and loading effects happen on this border simply because that register can be changed during the active display, so you can change it on different lines, or even in the middle of lines; many demos use this and a knowledge of the system timing to actually draw blocky graphics in the border area. The MESS code was excessive and confusing, trying to buffer up all the screen changes into said event list, so that it could be rendered later. In reality all you need to do is get the current display position from MESS and render with the current border colour up to the current position, much easier.

The other issue with the Spectrum driver is that it hadn’t been touched for many years, there were some old legacy MAME hacks in there from a period where MAME couldn’t handle fetching of a z80 opcode across different banks etc. These could be cleaned up too. For some reason the 128 systems also had the ROM area set to writable, so games could trash their own ROM, not good. Overall timings and CPU clocks for the 128 systems also didn’t match reference material, although fixing those actually caused some more issues than it fixed which I’ll still need to investigate, but given how little of the timing we have correct anyway there probably isn’t much I can do about that at this moment in time.

The TZX handling in MESS also needed attention (and still does) TZX is a ‘compressed’ format for storing tape data, it attempts to represent all the data on a tape with a number of block types, and is flexible enough that you can encode the same thing in many different ways, add comments etc. Several of the cassette images I had used block types not supported in the MESS parsing so they were simply being ignored, one such missing feature was the ability to loop blocks, which a number of tapes images used to compress protection information (a series of short pulses / tones repeated many times) adding that, and one or two other bits has helped to improve compatibility with a number of tapes, although there is still much work to do, and some uncertainty over certain aspects of the TZX format, which I think various people have implemented in different ways, and possibly means some images might not even be perfectly to spec. The MESS handling is certainly wrong, but because the protections are incredibly timing sensitive as well it can be hard to know which issues are caused by what.

Anyhow, I added a preliminary placeholder software list there too, where I can list TZX images I’m working with in, and note good test cases for the emulation, like with the other systems. It helps to keep everybody on the same page. I wanted to do a similar list for Spectrum +3 Disks, but the new floppy code can’t currently handle the ‘.dsk’ files (or extended variations of them) which also means the Amstrad CPC floppy list handling is completely broken at the moment too. Hopefully this is just a temporary issue and Olivier, who is working on the new floppy code, can restore support for the format, even the old support didn’t handle the protected disks correctly.

That’s a big block about MESS anyway, for my work on MAME see the previous updates here, not much more to say about them, u2 had 3-on-3 Dunk Madness etc. No real progress has been made on the Puzzli 2 stuff yet because I put it on the backburner while I took a look at the above things in MESS, and I can only work on so much in a given period ;-)

When it comes to work other people have been doing there’s also some good stuff in u2. iq_132 has been putting in an effort to remove a lot of ROM patches in the MAME source, usually where protection devices haven’t been emulated properly, but rather the ROMs patched at runtime to avoid any issues. Many of these are trivial but it was simply quicker / easier to patch out the offending code at the time, than figure them out, some are more complex. From the point of view of an end-user it’s unlikely (and obviously preferable) if you don’t notice any difference, but from the point of view of keeping the emulation clean it’s always one of the goals to be able to run the original, unmodified code rather than cheating by patching things out. Some of the higher profile cases of his work include Metal Slug X, Caveman Ninja, an actual bugfix to the Knights of Valor protection simulation, and SunA’s Ultra Balloon. iq_132 doesn’t have a dedicated WIP page, but he does mention this work in the forum thread he usually uses to show what he’s been working on in Final Burn Alpha over

Speaking of SunA, that’s another hot topic right now and u2 includes Luca’s progress on Sparkman to add to the list of working SunA titles supported.

For MESS, R.Belmont has continued his undisturbed work on the earlier Mac systems, adding support for a host of new peripheral cards, Curt Coder his c64/c128 work, Olivier floppy / floppy controllers, smf SCSI rewriting / refactoring, and Mooglyguy has been improving something called ‘Craft’ which I have no idea what is, but he posted some screenshots of the bannister.org (MESS WIP) forums, looks demoscene-like.

I started by talking about the Amiga and Pinball games, so on the topic of Pinball games Robbbert has continued working on fleshing out the skeletons for the actual mechanical ones, as mentioned last time, not especially useful right now, but it does position MAME for potential reworking into a more modern PinMAME port based on the current codebase, although there’s still a long way to go before that happens.

Aaron has been pushing through more code modernization which seems to be low impact (not observed any breakage as a result) we’ve also seen various i386 improvements. For shits and giggles I tried installing Windows ME on a 486 in MESS by forcing it to ignore the hardware checks, amusingly it actually installed, only crashing the emulator once during install (same as Win 98) but it took over 12 hours and was really too slow to use, ran in 16 colours because I don’t think Windows ME works with any ISA / VLB video cards, and only had 3 meg space left on my virtual 500MB HDD after install, not recommended unless you don’t value your sanity ;-)

Finally Roberto Fresca has continued his dedicated work on old video gamblers, and dealing with the mess many operators left behind.

As you can see, it’s been more of a MESS focused update this time really, which makes a change from the last couple where most of the changes have been to the MAME side.

I know a lot of people want to see the later PGM games working in MAME, but I still deem them to be basically impossible to emulate properly, however, Smitdogg & Tormod did just pick up a more interesting / viable emulation target, a Puzzli 2 board.

What’s interesting about the board he picked up is that it’s the original release, simply titled Puzzli 2, rather than the Puzzli 2 Super set we have in MAME. This version is from 1999, whereas the existing version was a 2001 release.

At a glance the protection appears the same, with the Super version in MAME just being a program ROM upgrade.

I’m not sure if we’ll be able to get the actual internal ROM out of this one, because while it is one of the earlier IGS027A chips without the execute-only protection it lacks an external ROM, which means there is no real way to run your own code on it, you have to rely on finding weak table functions in the protection routines, and if a game doesn’t use table functions, or doesn’t have any with insufficient bounds checking & the ability to read a negative position from the intended table then you can’t really extract the ROM.

However, when the functions are simple enough (unlike the later games, where most of the game runs on the ARM) you can attempt to simulate the device, which is a logical first step anyway. At first glance it would appear that the first protection commands are used to get Z80 pointers for the attract music because even with Demo Sounds ON it lacks any music in MAME. It probably also fetches data pointers for the level data.

One other interesting thing about the new set is that it has an actual Japanese title screen, so it’s likely that this non-super version was distributed in Japan whereas the super version might not have been. The cart we have is a Hong Kong region tho, so who knows. Also of note is that when set to Taiwan it doesn’t show ‘Super’ for either version which might suggest either the Super version was the only actual release there, so didn’t need the Super subtitle, or it was never updated for release there. Knights of Valor Plus is similar in that the Korean region (which we know exists because we have the cart) also doesn’t show the PLUS subtitle. Naturally it’s quite hard to know which regions were actually released because the actual region code is supplied by the protection device, not the game code.

Here is the Japanese title screen (only present in this version) for reference.

and the English title screens side by side, so that you can see the different (c) year

I can’t give a time estimate for getting this done (and currently this set crashes exactly like the existing set in MAME) but having a working cart does bump it up the priority list.

The original post on Mameworld with hardware pics and an original hardware video is here.

There are a couple of drivers I’ve been working on lately which are *almost* right, but at the same time still have a long way to go.

Starting with Black Touch ’96. BT96 is a Korean Beat ’em Up and a driver I started a long time ago. The video system is a bit funky, so so was the focus of my attention. Essentially there are sprites, and tilemaps, but the confusing thing is that the sprites aren’t really sprites at all, infact they just appear to be 4 additional tilemaps with positional strips, however they must be rendered as 4 distinct layers in order to get the priority correct (in terms of list order the background sprites end up sandwiched between two of areas containing character objects) There’s also RAM for another 4 potential layers, but it never seems to be used beyond the initial RAM clear / initialization (and I’m guessing it doesn’t work on real hardware)

I think this video setup, along with some shoddy programming caused issues for the developers of the game, it seems to have a number of bugs, including one where if you attack the enemy with your kick attacks at the top of the playfield you can cause them to fall into, and start walking through the background, complete with momentary priority glitches because the rest of the code really isn’t sure what’s going on. There are also various bogus ram writes to unmapped areas, I’m assuming these are just bad / buggy code, maybe they should end up going to a RAM mirror, but that isn’t clear. Amusingly the Seibu games act in a similar way with bad protection emulation (incorrect collision boxes and movement calculation code causing enemies to walk off-screen) but these tasks aren’t handled by any kind of protection in this game.

Anyway, before the last ‘u’ update I made some improvements to the sprite system incorporating the new findings and also improved the tile layer which is equally deceptive. Tile RAM is written as 16-bit, but the upper 8-bits really don’t seem to matter, the upper bits of the tile number are instead controlled via a bank register, I’ve added support for that, fixing (I hope) the text on the story screens.

The sound is handled by a PIC ‘MCU’, which thankfully we have a dump of because it was one of the old games which actually got decapped, and for which the MCU serves a useful purpose. The bad news is I’m entirely unfamiliar with the PIC series, and haven’t managed to hook it up, I did put in a request to the rest of the devs but haven’t heard as much as a peep back over it, so I’m guessing there are no devs familiar with it either.

So why isn’t it working? Well the major remaining issue is that the timer doesn’t decrease, I wonder if the PIC is involved in this as well as sound, but it could probably do with some tracing of the 68k code to find out if there isn’t a more simple explanation. Obviously the sound could do with hooking up too. You can play it, I’ve played through a few levels (and you even get a Bikini girl between each level like so many Korean titles..) but without the timer I can’t really consider it to be working.

As a game, it’s terrible, the screenshots below make it look better than it is.

The second game I’ve been looking at, albeit indirectly is Tecmo’s World Cup 94.

I say indirectly because I’m in the middle of doing some work to all the Video System drivers, as I believe I mentioned in the 3-on-3 Dunk Madness post below. I’ve identified 3 main Video System sprite systems, 2 of which are used on a wide variety of games. Like many early things in MAME which haven’t been touched for a while every game had it’s own implementation of the sprite chip based around what that game, and only the game needed, needless to say most of these implementations were incomplete.

By unifying the code I’ve not only managed to fix the problems with 3-on-3 Dunk Madness player sprites (still some tilemap priority bugs I need to fix there however) but also Tecmo World Cup ’94 has seen benefits from this in two ways.

First of all the players now correctly get rendered in the attract mode, previously the code was actually ignoring half the Sprite RAM because Grand Striker (the game the driver was originally done for) doesn’t use it and we were masking too many bits of the index. The code was also using the wrong sprite enable bit, which was leading to random stray shadows and injured players getting stuck on the screen, that’s also been fixed. Furthermore because the zooming code for sprites has been unified with the other implementations which are apparently more accurate, you no longer get sprites breaking up when they zoom to full-size. There are still some flickering sprites when you score and at the end of matches, but that might be an original game issue.

What’s wrong here? Protection. We currently have a protection simulation, but it’s imperfect. The game always thinks it’s the first match, the attract sequences probably aren’t in the right order (it displays ‘INSERT COIN’ over the high-score table erasing some parts of the text tilemap, which looks glitchy) and I’m not sure the ‘EVENT’ handling logic in the game works because it seems to do nothing if you compare it with the NeoGeo Tecmo World Cup ’96 released 2 years layer.

The protection is annoying because the original hardware MCU performs some kind of checksum on the main code, which means you can’t modify it, however, a ROM banking trick similar to what was used on DDP2 might get around this issue, by manually controlling the upper address pin on a double sized ROM it might be possible to get our own code running, and at least explore the jump addresses returned by the device during attract / gameplay and determine if the protection glitches we have are due to wrong jump addresses or something more (on V-Goal Soccer, which is the same hardware, it appears to control various counters directly instead)

There’s also the issue of the zooming tilemap. Tecmo World Cup ’94 makes light use of it, but you can still tell the implementation is wrong (things don’t align correctly in the various zoom states). Grand Striker and VGoal Soccer make more extensive use of it, and with those you can really tell how bad it is, and no matter how many times I’ve looked at it I can’t make any real sense of it, it feels like something must be non-linear at some point in the algorithm and even if I adapt the code to get the ‘Zoom into Stadium’ part of VGoal Soccer looking better the game is still broken. (I’d love some original videos of V-Goal Soccer for that sequence, but it never seems to show up) Due to these things I’ll probably demote Grand Striker to non-working too, the pitch has never been right, and what I thought at the time would be a quick fix from Imperfect Graphics to ‘fine’ turned out to not be a quick fix at all, essentially meaning the game has never worked.

Anyway, I just wanted to highlight that work does happen in MAME even if it doesn’t directly lead to more games being tagged as working in the immediate future; every little bit of progress does however bring us closer to ‘working’ and sometimes, as demonstrated here *real* refactoring and merging of old code can sometimes help.

In other news Luca, as expected got Sparkman going which means all the dumped SunA games now work.

Mariusz Wojcieszek submitted a driver for a Korean game called ‘3*3 Puzzle’

He doesn’t have a WIP page, and I helped with the driver (just a simple graphic decode plus a few minor fixes like adding the 2nd button mind you) so I’ll show it here.

It comes in 2 flavors, one with adult images, and one without. The images I’m showing are from the non-adult version.

I’d write something interesting about it, but it really isn’t that interesting at all, it’s just 3 poorly programmed near shovelware quality mini-games, a columns rip-off, a tile matching game, and a version of othello.

Hardware wise it stands as one of an odd group of platforms which lacks any kind of sprites at all, the whole thing is just 3 tilemap layers with ROM based graphics, which is rather limiting. I plan on doing an article highlighting some examples of games using such a configuration, a couple might surprise you, but this one does nothing to even attempt to hide the limitations, simply presenting a set of very basic games.

It can change resolutions, which is an unusual trick for non-major manufacturer games to do, the 2nd game uses that to run at a higher resolution than the others, but that’s the only real trick the hardware has. It might be able to scroll too (you can see a bad line of tiles in the 2nd game which might be because there’s currently no scrolling hooked up) but that’s hardly something to write home about.

UME (Universal Machine Emulator) combines the features of MAME and MESS into a single multi-purpose emulator. The project represents a natural course of development for the emulators which already share large amounts of code and is part of an ongoing effort to unify development efforts and provide a single emulation platform for users and developers alike.

This is based on the official MAME 0.147u1 source release found on mamedev.org. The binaries on offer here were compiled with ‘make all TARGET=ume’

As of 0.147u1 the official MAME / MESS diffs are unified like the source releases, so the single diff released is for both projects.

Note 1: to compile UME using the sources and diff from mamedev.org you must add the “ume.ico” Icon resource file to “src\ume\osd\windows” in the source. This file was added after 0.147, but because it’s a binary file it does not get added when applying the official u1 diff. If you instead check out the source from the SVN the file is already included. If you require the file separately it can be found here. Yes this does mean the UME Windows binary has a shiny new icon as of u1 :-)

Note 2: the official 0.147u1 patch doesn’t apply 100% cleanly to the official 0.147 source due to a last minute change being put in the 0.147 source release mess.mak file, the resultant files are correct however, and the warning can be ignored.

The package contains both the 32-bit and 64-bit binaries, due to the above issues I’ve also uploaded the source used to compile here.

The 0.147u1 UME release binaries can be downloaded here.

Note: as of 0.147 the sysinfo.dat is no longer distributed with MESS, it can be found in the ‘Extra Files’ section at ProjectMESS
furthermore the external artwork files, needed by some chess computers are also not included by default. They can be found at AntoPisa’s site.

Changes from MAME 0.147 can be read about here
Changes from MESS 0.147 can be read about here

General Release Commentary

As expected the ‘3 On 3 Dunk Madness’ progress below missed the submission deadline.

The 0.147u1 diff is deceptively large, weighing in at over 2MB when zipped you might imagine it to be a significant update, code-wise it probably is, but functionality-wise it’s about average for 3 weeks of work. The size of the diff comes mostly from refactoring, moving of more items and functions into the ‘machine states’ rather than them being global which is ultimately working towards the ongoing long term goal of allowing multiple instances of systems to be running at the same time etc.

In terms of new games, Hap’s work the old Model Racing gun games means that both Clay Buster (identified with flyers) and what we therefore presume to be Gun Champ are now working after Any dumped the former. Neither game has a title screen. Hap doesn’t have a WIP page, so here are some pictures of those running in 0.147u1

Clay Buster

Gun Champ

Both are very basic gun games but nevertheless interesting bits of history.

There’s also Star Fighter which Luca added, as I mentioned below. For an early Korean game it’s actually very interesting, taking influences from many other classic shooters and presenting a varied multi-round vertical scrolling shooter.

Robbbert has been working on improving the basic emulation of some of the Pinball systems, but until modern versions of MAME can be hooked up in the same way as PinMAME those aren’t too exciting as you don’t have any kind of table, just the ability to manually trigger sensors via the internal layouts etc. Worth a mention because it has potential to lead somewhere I think.

iq132 has been attempting to remove ROM patches from a number of drivers and instead simulating the protection devices, including getting rid of the long-standing ROM hacks Metal Slug X used, should be no visible changes, but it’s good to be clean.

There’s also the work on the Seibu COP mentioned below, nothing is magically more playable now but there are various subtle (and not so subtle) behavioral changes in various games, some improved, others, like Zero Team temporarily regressed until a few more mysteries are solved.

The MESS side has seen a number of refinements too, mostly small but important changes you’re not going to notice as well as ongoing improvements to the Software Lists and work on the Atari 2600 to handle some of the trickier custom hardware cases which regressed at some point, or were simply never emulated.

General improvements also see a bug which prevented 7-zip support from working in 64-bit Mac builds fixed, although sadly I don’t think the issue mentioned in the 0.147 release with redefining controls for some consoles is resolved, it actually looks like a very long-standing bug, likewise the issue with screenless games not actually updating their display as frequently as you’d expect is still outstanding.

Of course driver bug fixes are important too, and everybody will also be happy to know that the bug causing the Mortal Kombat games to crash / display corrupt graphics in the 0.147 release is fixed in this release, as are the problems which were introduced with Sega X and Y board emulations causing glitchy sprites which alone should make 0.147u1 preferable over the original 0.147 release.

Overall it’s a steady release and if you’re doing any development for MAME you’ll definitely want to pay attention to some of the structural changes which have gone in over the last 3 weeks.