Marching On

If previous recent years are anything to go by we’ve probably seen the early year flurry of activity MAME gets towards the end of December through to February. So a summary of the major things.

CHD Changes

Some simple CHD changes to add FLAC for Audio ended up turning into a complete rewrite of the format. The FLAC support is there, now, as is LZMA support in CHDs, although the latter gives disappointing results compared to when it’s applied to standard ZIPs. There probably is room for further improvement with the compression of data tracks on CDs because generally you can calculate error correction information and check it matches the source data you have instead of storing it (except in cases where it’s intentionally wrong for copy protection purposes in which case you’d have to store it) but that depends on the sector format and other things, so probably won’t be done especially as other recent changes have already made compression many times slower. As it stands there are decent gains on a set of MESS CHDs, less so for a MAME set, although the savings on the Beatmania CHDs aren’t shabby at all.

Unfortunately as part of the process the SHA1s for CHDs with older style metadata did change, although this only really affects MAME because all the CHDs supported in MESS were created with newer CHDMAN versions which already had the newer style metadata. This is something of an inconvenience and means ~200 SHA1s will need updating in MAME, forcing people to use V5 if they want to avoid SHA1 error reports. This is a shame because ideally I wanted the changes to be entirely optional so that people could simply stick with V4 if it suited them better but Aaron clearly had different ideas and wanted to ditch the legacy metadata.

There are still some outstanding bugs with the new tools at the time of writing, which I hope get ironed out before a proper release hits. Of note:

1. Converting a CD CHD with ‘chdman copy’ will NOT update the default hunksize to a larger one, which is optimal in more cases. To do that you’ll have to manually extract and re-create the CHD, be warned tho, certain CHDs won’t extract to .cue/.bin because they contain data the format is incapable of representing. Minor issue, but one to be aware of. It’s quite easy to hack up your own CHDMAN build to automatically force the correct hunk size when updating a CD.

2. Laserdisc CHDs (the big ones) aren’t safe to convert yet. The metadata in them is changing for unknown reasons, and decompression fails (although bypassing the code where it fails seems to result in a correctly output file?) This is a major issue, be careful.

3. GD-ROMs might not be safe to convert. R.Belmont says the old code worked more by chance, and had bugs. This is also potentially a major issue

4. Random hangs when converting. For some reason CHDMAN sometimes hangs when converting HDD CHDs, this appears to be random, possibly a thread safety issue. This almost certainly makes it unsafe for reading real drives to a CHD file. Again I’d consider this a potentially major issue, although it won’t affect you if you’re just using MAME.

I’d also probably add a ‘fast’ preset option for reading actual drives, which only uses the basic compression schemes. If you’re reading a drive you don’t want to be sitting around 20x longer than you need to while it finds the best compression, you can do that later as part of an off-line process.

7Zip Support

Romsets, Artwork, Cheat Files, Samples etc. can now be stored in .7z archives rather than plain zips. This gives compression advantages, and as long as you’re sensible about the compression options doesn’t incur too much additional memory / processor overhead when loading.

The implementation is currently tested and working for most use cases, and I’ve yet to see any bug reports for it (which to be honest surprises me) It’s beneficial for things like the cheat XMLs where you can use 7z to compress them down to a nice neat 600kb file with almost no noticeable loading delay!

The -romident function of MAME is also hooked up to handle .7z files, however romcmp.exe isn’t yet (shouldn’t be too hard) I’m also told that loading MESS software directly rather than via the software lists requires a bit of extra code, probably something as simple as it not seeing a .7z as a rom extension.

FLAC Sample Support

Your samples can also be encoded with FLAC if you desire, and while this was initially used as a testbed for the format support before adding it to the CHD spec you might find it handy. The APE support was never added (a shame, I think it’s a good to have as a demonstration for people to at least see why it isn’t the preferred method)

There should be no issues here at present.

Merged Builds

While the official teams still seem to have some inexplicable hangups over offering the source to build these, or the binaries themselves it’s pleasing to see that the code previously posted still works, and all the patches to resolve both compile and runtime errors with such builds have been accepted. I haven’t posted a build recently because I’m still waiting for the CHD changes to settle. I do still hope that one day this becomes the primary target, with the MAME/MESS individual builds offered for people who want ‘stripped down’ versions, but with the current teams I think it will be a cold day in hell before that ever happens. Power struggles would simply get in the way.

x86 Progress

The recent x86 progress is a good example of why MAME needs MESS. Contributions to the MESS side from ‘carl’ have made great strides with the x86 emulation in MESS, edging it closer to Dosbox in terms of compatibility, as opposed to before when nothing requiring protected mode would work at all. You can even install Windows 95 within MESS now, although it isn’t fully functional yet. MAME benefited a bit as well, a few x86 based games now do more, California Chase for example, although face it, nobody would have bothered to improve the x86 emulation to the level needed for that if it wasn’t for MESS and PC support ;-)

Fruit Machines

Fruit machine progress is slowly getting back into gear after the initial burnout, more sets have been split (mainly by J.Wallace) and I’m looking into the extras the various CPU cores need now. I know a lot of people seem to think these are things which can never work in MAME because they had no displays, but MAME already emulates several games without monitors (look at 30test, another recent addition, it doesn’t even look bad without artwork!) MESS also emulates a number of systems without real displays (Chess computers for example) I know it’s going to be hard to live up to big expectations with these, but they will get there, eventually. Mooglyguy has also expressed an interest in rewriting MAME’s presentation layer, which is of great interest when it comes to these machines which are going to depend heavily on good looking light simulations when artwork is used. It also needs it, the current artwork code is IMHO horrible.

3D Systems progress

Ville has been active again, and submitted updates for a number of 3D systems in MAME, improving the graphics in GTI Club for example. Mooglyguy has also been working on N64 MESS side trying to squeeze a bit more performance out of the drivers. This has had benefits MAME side with a number of Aleck64 games now booting and/or running faster. Sadly for a lot of these systems things are still out of the performance envelope for current PCs and considering we’re at least 10-20x slower than things like Demul, which is already getting a public roasting for being too slow because you require a modest PC to get 60fps on Dreamcast games and lacking artificial enhancements I have a feeling that 3d in MAME is never going to be well received or accepted.

Deco Cassettes

As shown on the previous updates here there has been a fair amount of progress with Deco Cassettes, and they can once again be dumped safely, although all that needs saying has been said already :-) Probably the highlight of the last few months this one.

New games / clones

Not a great deal to write home about here. A couple of new Korean games showed up and were working, including the now legendary Boonga Boonga / Spank ‘Em although from an emulation point of view that isn’t very interesting, just running on an already emulated Hyperstone platform. Gameplay wise it isn’t very interesting either, it’s not much more than a gambling game where you can win medals at the discretion of the machine. 2 Semicom titles were added, and while I’m usually enthusiastic about these both are very generic, and not too interesting. There was Toyland Adventure, which is a ‘clear the screen’ game in the vein of Tumble Pop etc. but offers nothing new in terms of gameplay while suffering from frustrating controls and slow-paced action. There’s also Diet Family, which is a Galaga style shooter on ‘cute’ scrolling backgrounds but also lacks any distinguishing features or polish. Compared to their other Hyperstone titles such as Wyvern Wings and Mr. Kicker these are both very poor efforts.

Some clones showed up, the most recent revisions of the 2 Jojo games on CPS3 are now supported (although the most recent revisions of the first 2 Street Fighter 3 games still remain unsourced)

The unlicensed NeoGeo title ‘Super Bubble Pop’ was added, but controls for P1 are non-functional (possibly protection, although Player 2 controls work fine) Game seems to be rather buggy, so might just be bad code which out emulation is sensitive to.

A whole bunch of non-working sets were also added, but with no devs showing a real interest in actually emulating these things, combined with them being relatively modern systems I can’t really see those additions coming to much.

Under the hood Changes

Aaron rewrote a whole bunch of core code as usual, end-user benefits are non-existent tho, so not much to write about here. From a code perspective things probably became a bit more complex, requiring extra attention to be paid to bitmap modes and such but assuming there are no remaining bugs there’s nothing a regular end user should notice from any of these changes. (Some people have reported less lag in the odd shooter, but I have a feeling this is more to do with games getting slightly broken due to adjusted timings, and sprites no longer buffering at the same point in time)

Lots of rom renaming, documentation fixes, things like that.. Kale stripped out the remaining deprecat.h usage in December (although I believe one or two things are still broken from that)

Other Stuff?

I optimized the PGM video code a bit, Sliver uses libJpeg to decode it’s bitmaps, and a couple of minor changes were made here and there. The last few days have seen preliminary Votrax support from OG/LN etc. go in which will eventually be used for Gorf etc. (not yet anywhere near the quality of distinguishable speech, so disabled) I also finished off converting some Data East drivers to use the sprite devices I added, adding support for bootleg variations at the same time, but that’s nothing really significant.

But… that’s about it off the top of my head, no decap news on the more interesting targets (Taito C-Chip, Toaplan sound MCUs) (actually no decap news at all) No progress on things like System 10 (which surprises me) No progress on Seibu (which surprises me less) Very little in the realm of long term broken games being fixed. No improvements to discrete emulation / games getting discrete sound systems emulated which is usually something done in the Winter months. I’m probably as guilty as anybody for spending the last 3 months focusing on tasks not directly related to the emulation (the 7-zip for example) but it remains worrying / disappointing especially in what is traditionally quite a busy period.

On the MESS / Console side Byuu is on the verge or emulating the final SNES co-processor after extracting the ROM from it (which would be a landmark achievement) but aside the recent x86 progress it’s been unusually quiet there too, some 68k fixes for the ‘NExT’ emulation and some obscure systems booting, and the previously mentioned N64 improvements but otherwise very little progress on the staple systems, although I do hope to resolve that by adding NeoGeo CD support sometime soon. At least with MESS there is a clear steady flow of improvements to drivers, old and new and the 3rd party contributions are encouraging showing a willingness to tackle difficult tasks like the x86 emulation head-on unlike MAME where even simple drivers seem to be left untouched with people almost afraid to even try when it comes to making progress.

Hopefully this year won’t see a dramatic drop-off of interesting contributions after this Winter period as has happened some years, because if it does we’re likely to be faced with nearly no development occurring at all.

Remember these projects are the result of hundreds of thousands hours work by people, all done for free. Continued code contributions ARE needed to keep it going. Don’t be selfish by assuming somebody else will do the work just because your favorite systems / games are already emulated, or it doesn’t matter because there is another emulator already doing a better job. If I’d taken that attitude you probably wouldn’t have the likes of CPS3….

 

11 Responses

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

Both comments and pings are currently closed.

  1. krick says:

    Haze,

    Check out this holy mess of a CD. I feel bad for anyone who tries to make a MESS CHD from it…

    http://dknute.livejournal.com/40102.html

  2. Haze says:

    yeah, there are some *fucked up* CDs out there, just like floppies if not worse. If the ‘raw’ reading ever actually happens they’ll be fine, but trying to represent some discs with the existing formats is simply futile, they’re all approximations of the real format.

    The only way to properly read a disc is probably some low-level reprogramming of a drive firmware, but even then despite being a ‘digital’ format CDs have a good number of analog properties.

  3. fred says:

    “It’s quite easy to hack up your own CHDMAN build to automatically force the correct hunk size when updating a CD.”

    Any pointers?

  4. andi says:

    i used the “-hs 19584″ option of chdman to convert CHDs containing cd images to get the wanted hunksize…

  5. greg says:

    Maybe not much at this time regarding discrete components audio emulation, but I still believe some progress will happen later this year.

    One recent find of a Tranquilizer Gun parts catalog helped confirm that both Borderline and Tranquilizer Gun use same audio board and (play same sounds?)…
    an opportunity to get two games done.

    Derrick has most of the Midway paperwork and fortunately Atari, Exidy, Cinematronics schematics are online.

    For Gremlin/Sega vic-dual games manuals for following games are still needed: Samurai, Space Attack, Space Trek. And same thing with Ramtek Barricade.

    The tough task is finding logic/audio schematics for most of the Taito games (discrete audio) such as Lunar Rescue or Balloon Bomber. I have only seen Lunar Rescue schematics on online auctions just once over past several years.

  6. Stojan says:

    Ninja Assault (Naomi) & Techno Drive (Namco System 12) were acquired and/or dumped long time ago, but never added to MAME.
    Do You know why ? – These games are old enough and should be easy to emulate, simply drop in adequate driver.
    Some time ago, I asked for Donggul Donggul Haerong why was not added in MAME and at the end it turned out that Guru dumped the game, but named wrong the zip.folder ?!
    Shortly after that DDH was added and Luca Elia got in-game.
    Is there some politics behind curtains ? I could not understand prolonging already dumped roms to MAME .
    P.S. There are other not yet added games with/out reason… …among them is Wyvern F0… Where is this game, too ?

  7. F1ReB4LL says:

    “now, as is LZMA support in CHDs, although the latter gives disappointing results compared to when it’s applied to standard ZIPs” — chunks should have a single common dictionary and no per-chunk err correction crc.

  8. Haze says:

    Ninja Assault and Techno Drive I really have no idea about.

    It’s possible they were received and turned out to not be what they were meant to be, or bad. It’s also possible they’ve just been missed, when you have a couple of thousand arcade boards it’s easy to misplace one ;-)

    Wyvern F0 is political tho, due to the price of it Guru wants money off Smit before he’ll release the dump, but also wants devs to work on it to show pics and put pressure on Smit to pay (afaik all devs have refused and have no desire to be part of such games)

    It’s also has an MCU which will probably need trojans running to work out the basic behavior, then possibly decapping to clear up any uncertainties. I’ve been told Guru has also apparently scrapped the unique cabinet it came with, which reduces it’s resale to almost nothing.. (and might make running trojans harder?)

    Basically I doubt you’ll see it unless one of them steps down and let’s it be worked on without conditions. More likely another will just show up for next to nothing.

  9. dave says:

    I noticed this in the 145u4 notes: “Fix for potential driver conflicts with same named machine states
    between MAME and MESS. [David Haywood]” Good sign for the merged builds.

  10. RColtrane says:

    I would like to ask about discrete ‘games’ emulation (or simulation, I don’t know). Will it happen someday in MAME, or only discrete sound will be worked on?

    I’m asking this because I have interest in those 70’s discrete games and would love to see at least some of them running in MAME, such as Pong did a couple of years ago. Some of these games in fact do actually have graphic ROMs, only using discrete logics to move them around…

  11. Haze says:

    Well they could do with being done one day.

    The problem is getting somebody to
    a) write a framework under which they can be supported

    and
    b) actually emulate them

    it’s *nothing* like traditional emulation at all, it’s entirely tracing circuits and trying to simulate every last little IC on the board, even for *simple* games like Pong a proper simulation gives you 4-5fps and there’s no real benefit from multiple cores either.

    you’d probably need a file format to represent the board schematics (having something emulated entirely in MAME and not requiring even ROMs would probably get some lawyers interested) so deciding on how to represent that would be a big challenge alone, and if you look at the frequency and number of people who do discrete work for MAME as things stand you’ll see that submissions are very rare, and by a limited number of people for what are in comparison to a complete game absolutely trivial sound circuits.

    It’s in a completely different field to anything I do, so I can’t even be of help.