David Haywood's Homepage
MAME work and other stuff
May 31, 2012 Haze Categories: General News. 167 Comments on Emulation Status

Right, I wanted to do a refresher on tasks in MAME / MESS in need of attention so that people were mostly informed / updated on the current state of various drivers and what needs doing to them.

However, I’m going to start off with the reverse approach. Use the comments to ask me about the status of things instead, and I’ll try my best to explain where the current issue lie. Please read any existing comments first because I *will* delete duplicates and off-topic material without warning.

(I make no promises to work on anything mentioned, this is NOT a ‘what should I work on post’ it is simply an experiment to spread knowledge and gauge interest because it isn’t always obvious to people who haven’t worked on the code what the issues are)


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

Forgive two questions..

The current method I believe is that there are softlists for MESS which are basically a whitelist of software that has been software for the emulator. Is this the final implementation or are the dev’s going to move across to a ‘load whatever you want approach’?

Has there been final agreement on the LDCHD quality/format and what is stopping the implementation of Dragons Lair and Space Ace? (I know about daphne, I am just interested in the MAME driver).

Sorry if the questions were not exactly specific, but these two questions have been bothering me for some time. :)

MESS can already ‘load whatever’ for many systems. There are cases where the softlists are essential for telling the emulator how to load the software (proper headerless, split NES dumps for example) but many common formats are already supported; I can for example easily load many spectrum games by selecting the tzx files directly from the file manager (creating a software list for such a system would be a lifetime commitment..)

Softlists are an attempt to document the software, and provide a system for bug tracking etc. as well as making people who want to work on a system aware of what the known software library is like (how many good test cases they have and such) which is really quite important for obscure Japanese systems where information is otherwise only found deep inside almost entirely Japanese sites. Essentially it’s to keep all interested parties on the same page if you see where I’m coming from with that?

MAME / LDs, I think the current format is ‘final’ but hardly anybody has the correct ripping setup and it doesn’t seem perfect either (maybe due to poor source material) because games like Mach 3 exhibit problems in MAME (there are a variety of Mametesters reports, the most concerning of which is http://www.mametesters.org/view.php?id=3223 )

LD emulation will be important for MESS too, there are things like the Laseractive which is getting very rare and very expensive..

The problem is it was Aaron driving it and I don’t think there was a great deal of enthusiasm from others for doing it properly when Daphne exists (which to most users is ‘better’) Some devs who do have the setup also seem to think the emulating Dragons Lair will mark the start of the apocalypse (I disagree, crappy old LD footage has nothing on the versions being sold today, and emulating the likes of the SegaCD and JaguarCD versions has never caused any issues for anybody)

So in the end I’d say it was a combination of bugs needing to be ironed out in the way things are done (as to avoid issues like we’re seeing with Mach 3), a lack of people with the setups, and a lack of interested / capable people in general who actually *want* to see it done.


I am curious about LD. Why LD dumps are compressed losslessly? And make sense to have a software list of dumps that no one can create? Couldn’t be possible to use any video stream with the rom files?

Sorry if I’ve said something stupid, I’m just a basic user.

I remember maybe a year or two ago there was a big push on playstation emulation, I think by smf.

I’ve noticed that memory card support has been added to the saturn driver and I think to n64, but no one has added it to psu.

Is there a technical reason? If it were ps2, I could imagine that the MagicGate encryption or something might be copyrighted or some sort of issue.

Btw, thanks for all you’ve done for MAME and MESS! It’s really fun to watch the emulation improve over the years!

LD is compressed losslessly as not to further degrade any captures that are done. Also there are heavy patent issues surrounding most lossy video / audio formats anyway, MAME wants to keep away from those, and forcing anything into such formats.

Most of the actual Playstation improvements for Mess were done by etabeta (fixing video playback) and RB, I think smf is just trying to ignore the actual PSX side of things? Really the entire code should probably just be ripped out at this point and replaced with the pSX implementation as a fresh base, R. Belmont has expressed similar feelings and with MAME / MESS being c++ now there is one less hurdle in the way there. pSX isn’t perfect, but it should be much better than what there is already and gives a clear upgrade path for current users of pSX.

Afaik there are no technical / legal reasons, just it hasn’t been done, and the author of the code doesn’t seem to like anybody touching it (which is also why there is a general feeling it should just be replaced, to ‘free’ it of that situation, although personally I think people should just ignore such politics and improve it anyway as eta did back then)

Zillion: that was me, not smf. In fact, memory card support was added as part of that “push” (which consisted primarily of porting components from pSX), but it doesn’t currently work properly because our PSX core has what I will charitably describe as very loose timing. PSX games and libraries are remarkably forgiving of imperfect emulation in the aggregate (the real hardware actually changed timings with each revision – late PSXes and all PSones could draw Gouraud polygons 9 times faster, for instance), but in this case we’re so far off forgiveness is impossible ;-)

I do plan to look at it again sometime if it’s not improved by someone else before I get there, but I can’t say when that will be.

Dragon’s Lair is a little more complicated than Haze knows; Aaron tried to get a Daphne-like license from the rightsholders, but their position is basically that Daphne already exists and is GPLed and cross platform so they shouldn’t need to deal with MAME too. Unfortunately that also means they’re keeping an eye on MAME doing anything like adding those games. :-(

Other less-problematic LD dumps do exist and I’d like to see them come out some time as the associated hardware for a lot of those games would be a series of pretty easy wins.

Sounds like somebody will have to do Dragons Lair in an unofficial version / fork then, afaik there are similar things for Daphne created by people who wanted to use the original LD material, not the remastered stuff, although none of it is ‘MAME standard’ dumps

I’m a bit surprised the sets haven’t been removed from MAME completely if that’s the stance tho, right now the general message being given out is that they’re open for improvement because they’re in the main source unlike say the Cave stuff which people are free to maintain in their own distributions (and deal with Cave directly if it comes to it) but the official ones have taken a very clear position to not include.

If I understand correctly, the Don Bluth footage is what’s still copyrighted and controlled by the rightsholders, they don’t care about the ROMs. After all, the footage is why people play DL, while the gameplay is the best reason not to ;-)

I’m sorry this is off-topic but since you mentioned Cave, I was wondering how a certain Bitcoin user that you mentioned a while back is getting away with charging to “fully emulate” the games he’s offering. I don’t understand how he thinks he can make any money doing that when the source is available to add those games yourself if you’re willing to dig a bit.

I’d like to know the status of Atari 2600 driver, esp. compared to Stella project.

I have an off-topic question (or set on a specific topic) though, please allow me to ask it here (this is where a proper forum is missing):

Can I safely merge my MAME and MESS paths?
More specifically, will I have any conflicts if I drop all MAME and MESS artwork together? Or more importantly roms?

Talking about roms… In mame we use this path for erm… rom zipped files and CHD folders (each CHD set a separate folder). Right?
In mess? I used to use “roms” to store the machine roms (or firmware) and a separate folder “software” for the software lists. What are the common paths for this in normal mess? (I’ll talk ume next) Maybe indeed store firmware files in “roms” folder but software lists in separate folders directly under “roms”?

And then again ume… Should I (and will face no conflict) use “roms” folder for ALL mame + mess?

Help me with this please. In fact spell to me what I should do like if I was an idiot… (…HEY!) :D

Re:Cave, his posts were made before said games were emulated in public builds (but after Luca had shown emulation to be possible) I don’t think he stands a chance in hell of getting anybody to pay him to emulate them now, which is exactly how things should be, people can spend their money on the originals / ports instead.

The Atari 2600 emulation seems solid, very solid. Apparently people have been using it to develop software which runs on the original systems, which for a system so heavily dependent on timing shows it must be of a very high quality.

There are reportedly some custom mappers used by 3rd party aftermarket stuff not quite working at the moment, but the core emulation of the system should be good.

For MAME/MESS/UME you can really put your roms wherever you want, as long as you’ve got them all in places where the emulator will find them I don’t see the issue, it’s down to you as an individual user what you do (for example I have a ‘MameROMs’ folder for regular stuff, including MESS, and a ‘MameDEV’ folder where I keep sets I’m working on which haven’t been added yet, but you’re not going to have the same use case…)

Yes I know I can use any folder (as long as I set it in mame/mess/ume settings)… The two basic questions remain though (well actually one basic, the other not, except in relation to the first):

1- Will there be any CONFLICT by dumping all my MAME/roms and my MESS/roms in a single (let say UME/roms) folder? (same artwork etc.)

2- Is it proper (is it even commonly like that) to have MESS software lists as a separate folder in mess root (with system subfolders) OR take this whole thing in “roms” folder (again keeping separate system subfolders like what we do with CHD)?

Thanks, you understand I want to be very clear and want stupid-proof answers before I mess my system. :)

merging the base MAME/MESS roms into the same folder won’t result in any conflicts, everything in MAME/MESS has a unique 8 (or something a couple more) letter unique shortname.

the software lists should be kept in named folders as the shortnames will clash between systems if you attempt to put them in a flat folder as attempts have been made to ensure naming of the listed versions is the same across systems and the same as their arcade counterparts.

you could in theory put all the different versions of a game in the same zips in a flat folder structure and it would still work, but that isn’t recommended.

artwork should be fine, although I don’t know how the MESS components handle artwork w/regards to softlists, I assume it will just use the system name for now rather than allowing individual software titles to have their own artwork. This may need to change because I think things like Pico really need the art scans from the books to be fully playable.

There is a UME thread down the page somewhere if you have any further questions on this. The thread here is meant to be for people to be able to get an idea of the state of progress, and what needs doing on unfinished _drivers_. I may remove off-topic posts to keep it on topic in a few days.

I never expected 2600 has gone that far. :) Good to know btw.
BTW VICE project seems to go slower and slower. No release for more than 15 months (!!! and 13 months before that!). Web page old, outdated, nobody cares (in fact google points to an even older version which is not under the control of vice team). There are some code submissions (although I think not that much now), but nobody even bothers to assign support cases etc. in sourceforge. It is a pity.
On the other hand, this is either opportunity for MESS to catch up OR someone to take over and make VICE progress.
Check it out if you can.

Thanks for folder structure replies (clear now). I didn’t post in UME thread because I wasn’t sure if you follow comments on old posts.

Arbee: Thanks for your reply! Very informative!

I was also curious (your comment about playstation revision differences reminded me), is there a consensus on the accuracy of playing playstation games on the various playstation 2s?

I know that the backwards compatibility is provided by hardware (I think something like the psx cpu and gpu being used in the ps2 to handle i/o), but I wasn’t sure if anyone had actually investigated to see how accurate it was.

Also, recently someone brought up Connectix Virtual Game Station on the shoutbox (I think in reference to Oracle vs Google court stuff). I read that Sony bought VGS from Connectix and discontinued it. Is there any evidence that the playstation emulator used for PSP and PS3 is based on VGS? Just curious! It would be neat if Aaron’s code were still being used!

Alright, one question on an admittedly previously touchy subject. Is there even the faintest hope we might be able to see *optional* XInput support on Windows? With the signed drivers mess that x64 has turned into, it’s becoming increasingly irritating to resort to custom drivers for devices like my TE Fightstick.

Also, it was me that brought up the VGS case in the shoutbox. I’m pretty sure no Connectix code or anything even similar is in use. Sony has better documentation and specsheets and likely would rewrite everything to tighter spec.

Whoops, just caught that bit about wanting focus on drivers. If my question (admittedly very much grey area for that focus) bothers you, feel free to delete it. No offense will be taken.

I have a quick question Haze, on the fruit machine side, how is it all progressing? I’ve seen a few updates on the git but nothing spectacular to get us all excited over at DADs, i know its not really a priority of the MAME team (seeing as some techs are already in a semi working state) but a small update/peek at how things are progressing is nice.


Oh and Zillion, if its any use to you then when the PS3 was torn apart a lot of its files were dumped/made available, the PS3 Dev Wiki may be of some use in finding out about it


If you fancy a nose around any of those files it may be worth downloading a copy of the 3.55 firmware & using one of the PUP Unpackers to have a look around it (might need an Unselfer aswell, there should be one in the tools below)

Firmware: – http://www.ps3devwiki.com/wiki/3.55_DEX
PS3 Tools: – http://www.ps3hax.net/2012/05/released-ps3tools-gui-edition-v1-2/

hmm. can i ask about raiden2 hardware type games…
anything realy new??

ideas… :)

First let me say I think this is a great initiative and I really appreciate it, as probably other users will too. I have two questions:

1. What needs to be done for no imperfect_sound or imperfect_graphics flags on Naomi?, is something holding that progress or there is no interest in it?

2. I’ve read many times that theoretically, using techniques involving shaders on modern graphics cards, there could be a very significant boost on performance for certain drivers (including naomi). Is this still on the “idea stage”?, what’s holding that progress and what are the challenges?

This is a multi-part question. Feel free to lump multiple questions together when answering.

What’s the status of discrete audio in MAME?

Which games are still completely missing discrete audio?

Which games have discrete audio, but are still imperfect?

Are there any grand plans to re-write the discrete audio system for optimization reasons, or to make it more accessible to aspiring contributors?

I know that Derrick Renaud did a lot of breadboard mockups using real components in order to get things “right”… http://derrick.mameworld.info/docs/Tutorial/Phoenix/Phoenix_From_Start_to_End.html …is this level of effort needed for the remaining games going forward?

On a tangentially related issue… What (if anything) still needs to be done with speech synthesis in titles like Qbert, Wizard of Wor, Gorf, etc…?

Is anyone actively working on the BBC Micro in MESS? I’ve posted on the MESS forum but after over 150 views, no replies.
I’m sure the current emulation is pretty good, but it’s usability is limited in that it doesn’t support double sided floppy images (dsd, only supports ssd).
It’s ROM management could also be improved. A standard Beeb had 4 ROM slots, one of which contains BASIC, the other 3 should be assignable to insert utilities such as Disk Doctor, or word processing such as WordWise.
Finally, I could probably help out with BBC softlists, especially the ROMS. What is the criteria for adding games as most were released on tape only. My floppy images are mostly homebrew compilations, but I do have a few originals I’d like to submit, but in what format?

re: Xinput, IIRC it wasn’t available on Win9x (no DX9), and until recently (146) MAME has tried to retain compatibility with 9x, that may, or may not have an influence on the situation. Of course somebody would still have to write the code. As you acknowledge, it’s more a question for the people working on the core tho :-)

re: Raiden 2
the *encryption* was properly figured out recently by Andreas, which is why the sprites are now ‘clean’ and Zero Team also has correct sprites. That was done a few versions back making things a lot nice to look at, especially on Zero Team.

the *protection* is still in the same state it’s been for the last year or so, no progress has been made at this time.

As for the nature of the protection I think describing it as a ‘Game Acceleration Library’ is appropriate, it provides various helper functions to the games including custom (undocumented) macro style command chains which can make use of all sorts of maths operations and the whole thing acts a bit like a virtual cpu. This remains the problem with many Seibu games.

re: Naomi
It’s a complex 3D system, many, many operations (especially depth sorting, blending, filtering, mipmapping etc.) aren’t full supported, video precision isn’t perfect either (although that could come down the SH4 core FPU precision issues) anyway, that’s why you have the imperfect graphics flag (it’s slow enough already without adding all that …)

imperfect sound, the ARM crashes sometimes, maybe due to timing issues, or register readback issues, it’s very difficult to judge if the sound is working correctly due to the slow speed of emulation.

for shader work I don’t think anybody has actually committed to anything, although some kind of accelerated rendering is going to be essential if the graphical effects are to be all fixed up.

for good performance they’d also need an SH4 recompiler, which again there hasn’t really been much progress on.

I don’t think there is a great deal of interest in this at the present time, bit of a vicious cycle, poor performance makes people disinterested in the driver, people being disinterested in the driver means it sees no improvements. Olivier did mention in the MESS / bannister.org shoutbox that 3d acceleration interested him, but his timeframes tend to be in “years” not months so I wouldn’t hold you breath, use Demul instead (and for the record enough people complain about performance in that already, but their DX11 model is probably rather close to what MAME would do and it’s almost certainly faster than even the most optimized of implementations MAME could have)

re: discrete audio

the status is really that Derrick Renaud is your discrete guy, it requires a rather different skillset to traditional development.

there are a lot of games with missing audio, I don’t have a complete list, but there are even games which use discrete audio for drum effects in their music and such (irem / alpha games?) plus some of the ‘clones’ used different audio circuits which is why many people think that the Space Invaders firing effects in MAME sound wrong. you’ve only got to start with the number of games which still require samples (excluding tape loops obviously) and then add to that many of the games so obscure nobody has actually managed to record samples from them yet…

not sure exactly what you mean by ‘state’ in this case tho? ‘discrete audio’ is a very broad subject. I don’t see any grand rewrites happening because Derrick barely has time to do the existing simulations, and debug them etc. Also keep in mind that because they’re analog simulations one person’s opinion of imperfect may differ to another simply because of variations in the components used on the boards…

If MAME at some point starts supporting discrete *games* then maybe we’ll see new systems in place for those, and the audio sims adapted to use them, or maybe they’ll build on the code used for the audio sims, I really don’t know, and again there isn’t really anybody to do that work…. (common theme..)

Gorf etc. saw recent progress from Olivier, Lord Nightmare etc. although it’s disabled by default because it still doesn’t sound good yet, but you can if you want change a line to
#define USE_FAKE_VOTRAX (0)
in astrocde.h before compiling to force it to use the emulated chip instead of samples (you’ll need the sc01.bin which isn’t part of the regular romset tho)
More specific questions can probably be directed LNs way on that one, because it’s very much an active work in progress.

if you’re getting no replies it could well indicate that the driver has no active maintainer / nobody interested in it. It’s one I don’t really know much about. Might also be worth prodding around on #messdev (on efnet I believe) and seeing if you get any answers there.

MESS’s ability to support multiple slots / devices has come on leaps and bounds in recent years, so the BBC driver probably just needs modernizing to take advantage of that, traditionally you were required to have a hardcoded fixed configuration, but things are very different now.

Re: softlists, originals should be documented as a priority, but common pirate compilations should also be documented, as long as they’re tagged appropriately. (If the BBC is anything like the CPC/Speccy you might find a lot of originals don’t work in MESS due to timing bugs making it think you’re trying to run an illegal copy)

I’m not familiar enough with the BBC to tell you what formats to use however, general rule would be the ‘best quality format available’ for every revision of every game even if it means mixing lesser format images with better ones for revisions where the ‘best’ isn’t available. (I suggest this as to make sure no unique code is lost / undocumented) Unfortunately I was looking at the ZX Spectrum recently and it looks like for some of the games the best available versions of some revisions are z80 ‘snapshots’ (ie old emulator save states) which is really quite disturbing, I hope the BBC doesn’t have such problems ;-)

My best suggestion is that you just get on with things, and see what feedback you get that way, the best way to get the attention of a developer is often to actually touch something they’ve worked on / have an interest in.

re: Fruit Machines

JW is doing a few bits and pieces at the moment while I look at other things. Essentially it’s important to make sure the foundations are good before starting to support more reel types and the visualization of said types.

The work RB has been doing on the Ensoniq synths should also help the fruit machines in the long run as the synths make use of the same peripheral serial chip (68681) which has seen a few improvements as a result of adding things to keep the synths happy.

One thing I definitely want to investigate is why the ‘stoppa’ feature in “Dough Ho Ho” doesn’t actually light anything up, I need to check if it’s some kind of lamp persistence issue or just a good test for actually hooking up the timers and things properly rather than the current rather kludged hookups I have.

Also, it’s summer, and it’s nicer outside than it is inside ;-)

Hi Haze

What is the status of :
namco system 10
sound system for Taito FX 1B, Gnet
sound status of Eoltih and newer SemiCom games

Thanks you for this nice opportunity to keep memomy of the current status of unfinished drivers.

Best regards

I’m more of an archivist my concern is the non-cpu based arcade boards that use proms/roms. Is there any movement on creating cpu-less skeleton drivers for the known dumped roms for these.

re: system 10

it’s encrypted, work has been done on that recently (again, Olivier + Andreas, those names keep popping up mainly because Olivier is one of the few capable devs of old left)

I guess how far it progresses now will depend on what challenges remain with the encryption (dunno if it’s 100% done yet) and if any further protection pops up + how well the basic PSX emulation holds up. (none of them look like overly abusive games, so hopefully it’ll be ok)

re: FX1B / Gnet:
no activity seen there recently, I imagine the CPU core needs a bit of polishing off (it isn’t used anywhere else, so we don’t know how reliable it is) and then the actual sound chip emulating. It would appear the games use proper sequenced sound rather than big sample loops, so getting things like the timers and various channel handling correct will be essential and it remains to be seen if the timers etc. are provided by the undocumented sound chip, or if it just acts as a ‘dumb’ sample decoder/player for the CPU. The sample compression format is at least partially understood tho, which is good. There are no real technical roadblocks here, it’s something a newcomer could easily pick up and do if it was their field.

re: Eolith / Semicom (QDSP / Q1000 stuff)
Phil B. mentioned in the bannister.org shoutbox that he had them producing sounds after finding out that the chips were the same as some other PC soundcard chip, but with an integrated CPU core. He did quickly add that the emulation currently sounds nothing like the hardware tho, so much work to be done, and no eta was given on submission.

re: Non-Cpu skeletons
I think tafoid was looking at doing this. He mentioned it to me a couple of months back, but he might have put it on the backburner?

What about the remaining decappe roms which haven’t been decoded/hooked up yet? Q-Sound is the most famous one, but IIRC there are more.

The problem is most of the chips which were decapped aren’t really important, even Qsound. Hooking it up is probably just going to result in slower, buggier emulation (due to having a complex CPU core not used anywhere else, and the potential of bad bits in the decap)

Also with some there is confusion over bootleg / original chips (eg for Kyros we have bootleg 68705 decaps as well as an original HD6805U1 decap, and for the likes of Arkanoid we have all sorts of dumps)

There are also a fair number of decaps which are just plain bad (some of the PICs look completely toast, quite a bit already added had to be hand repaired too eg. the Sega 8-bit MCUs) or don’t make sense if you try to hook them up (Empire City)

All these were done while chips in vital need of decapping for proper gameplay / sound were passed over (c-chips, toaplan sound MCUs etc. HNG64 I/O MCUs)

Personally I can’t find much enthusiasm to hook up an entire MCU when the entirety of it’s protection function is returning a fixed value when queried a grand total of 1 time by the main game (eg the Golden Tee & Midway protection chips, which are beyond pointless)

Dump interesting MCUs with real tangible benefits and people will find the time to hook them up..

While I agree that there are more important chip out there which could use decapping, for the whole accuracy thing shouldn’t all these “useless” decapped chips be hooked up.
I’ve read you many time complaining Mame’s inaccuracy that goes unnoticed, so if even you can’t be bothered improving Mame’s accuracy, I don’t know who will..

I don’t really think hooking up such ‘dumb’ MCUs is making anything really that much more accurate at all, it only makes the emulation more *complex* and prone to errors. Their functions are already fully understood. Only when the actual behavior of the MCU is complex and the simulation code to replicate it is huge and prone to errors itself does the emulation become more accurate by emulating the MCU.

for the simple cases the end result is the same, for some of these you could achieve the same effect just by having a jumper block on the pcb with some lines cut or similar.

at the end of the day MAME does not attempt to emulate *every* component on a board at component level, just the major ones, a ‘black box’ approach is taken to the rest, which for common logic chips is just fine. When an MCU only performs a really dumb, simple task it’s hard to consider it a major component.

I’d be more interested in finding out if something like the ‘Roz / blit’ chip used on the SegaCD is actually some kind of MCU, it’s behavior is certainly a bit peculiar.

Ok, one last reply otherwise you might think I’m trolling you. ;)
I read you see MAME and MESS as hardware emulators first and foremost. Still you seem contempt going with the blackbox approach, as long it works. This seems a contraddiction to me.
I thoroughly understand it when documentation about the chips or internal rom dumps are missing, but when everything is there, I don’t understand it that much. Aside from lack of time, of course.

They are hardware emulators.. but always have to decide at what level do you draw the line.

As has been shown, emulating even just Pong requires something like 10ghz+ for a solid framerate because you DO have to emulate every single little circuit on the PCB. Try applying the same logic to something like PacMan and you’d probably need 100ghz+ ….. You’d also end up with a driver which was MUCH harder for a regular user to understand, and a learning curve for contributions to MAME which was closer to a brickwall (which is why nobody does discrete level emulation right now really)

So you have to make decisions based on what’s practical, what’s understandable, what’s sensible, and what actually has benefits. There will always be compromises otherwise we’d be ’emulating’ all the atoms and stuff ;-) Just think how much (little) MAME would have actually preserved if that was the **required** level of accuracy for contribution.

That’s why I don’t think it’s worth going to great lengths in some cases (very simple behavior), but other cases (especially Taito MCUs) it’s near essential that they get emulated for accurate emulation. While it’s not such an extreme example as the one I provide it’s still a similar principal.

I know that work is being done on it but no idea what needs to be done and when.

The sound issue with Tie Fighter in Atari Star Wars game is wrong.

Think Lord Nightmare is working on it.

any ideas?

Zillion: PS2’s PS1 emulation is hybrid. The CPU, DMA controller, root counters, SPU, SIO, and CD controller all have back-compatible modes that PS1 software uses. The GS isn’t remotely like the GPU so software running on the EE side translates the display lists to a format the GS can draw. So basically it’s all hardware except for the graphics, which is why it’s really compatible.

Regarding discrete audio, Derrick pretty much lost interest in contributing after the troll Abracadabra attacked him, but Couriersud does have the relevant skill set and he’s been adding emulation of each arcade board’s analog section for the ones with Pokey chips lately.

For Naomi, Aaron rewrote the graphics emulation recently to work like real hardware (one thread per tile, etc which should be both faster *and* more accurate, not a combo you hear much in MAME) but it’s not complete and hasn’t been submitted yet. Once it’s in and working properly, it should provide a good platform to build the DRC on.

Pernod: BBC Micro needs what I call a “platform champion” – someone who loves the original system and understands it well, and is willing to fiddle with the driver. We can teach the MESS-specific aspects. (Mizapf on the TI-99 family is the most visible example, but we have several new contributors recently who look likely to assume that role for some systems).

FB1/GNET sound: the MN10200 core has some issues (The current implementation of the timers completely wrong because the documentation is quite vague). It’s one of many, many things I’d like to get back to at some point, but nobody’s come up with a cloning machine yet ;-)

Hardware 3D: Olivier, Aaron, and JD are all interested in seeing this happen if done properly, but nothing’s surfaced in terms of actual working code yet. I know JD has a fairly major rewrite running that makes the backend renderers more modular and generally better suited for hardware 3D (including DX11 support) but even when that lands it’s just a first step.

re: star wars / tie fighters
Yes, Lord Nightmare was working on that, luckily it’s one of the things where there are active devs interested. To get such things perfect requires accurate, lossless, high quality audio recordings direct from the boards tho (plus a lot of knowledge to understand those recordings and allow the same output to be generated by the chips in MAME)

For Qsound there is interest to run the decapped code and get the proper HRTF effects, but as Haze notes it’s a giant mountain of work just to get (hopefully) back to what 98% of users will perceive as the same sound we have now.

one (maybe dumb) question:
old good scramble and all their clones: i play this game too much as kid and find some original recordings @youtube today (original arcade machine, not mame) and looks like sound section is not emulated enough to represent real sound…. as i remember, real scramble have much noised explosions, better bass, mame version is somewhat messed with noises.. explosions not sound same as in original…

can someone other confirm this or …. :)

I’ll spend some time looking at the BBC implementation with a view to adding the popular dsd format, and documenting the known good dumps of ROMS that I have. I understood the system from a programmers perspective very well 25 years ago, but would not be capable of improving hardware emulation.
I’m mainly a C# and PHP developer so should be able to make some sense of C++.

I think the explosions in scramble are back to the discrete sound issue. People have actually been complimenting MAME as of late saying how good the discrete stuff is in that area, so I’d be surprised if it was far off. The problem with discrete games and real hardware videos (and games like scramble which were heavily bootlegged) is that as the components age the sound changes, and also the cabinets can have a huge effect on things like bass reproduction. Essentially no two boards will sound exactly the same.

@Pernod: the BBC driver has been created and mainly worked on by Gordon S Jeffreys. Ages ago he basically stopped working on it (I think due to a mix of real life issues and of emulation being quite good for the time).
he suddenly re-appeared a few months ago, fixing a few problems and starting some improvements/modernizations, but then he disappeared again (at least from what I can tell, maybe he’s still around on IRC…)

so basically the driver is an orphan looking for parents.

concerning a BBC softlist, I’d be really interested, so feel free to PM me on bannister.org forums if you need any info or if you have files to send :)

Is there any work being done to get controlls hooked up for Top Skater?

@etabeta: I’ll be in touch with the softlist, could be a few weeks though, thanks.

I’d say that model 2 / top skater had bigger problems than the controls not being hooked up, the game showing no 3d and crashing being rather major ones ;-) I’m sure if those were fixed up then fixing the controls would be trivial in comparison.

Top Skater is Model 2C and the TGPx4 DSP isn’t emulated in MAME so controls are far, far down on the list of things wrong with it.

Arbee: Thanks for your reply! I’ve been curious about that for a long time.

When you mentioned later psx revisions and the psones generating more Gouraud polygons, would that actually be noticeable in any games?

Haze: Sorry for being off topic! :)

What is a current state of model 1/2/3 ? Any future plans (in our lifetime)?

Since someone else brought up controls, I’d be interested in knowing how accurate they are for games that use rotary sticks.

Personally I’d be more interested on seeing some of the older systems emulation improve on MESS, namely Bally Astrocade Tape emulation or Philips Videopac+ emulation I’m sure these 2 wouldn’t be too much work (but what do I know lol) considering the VP+ driver could probably use a lot of the Odyssey2 code and tape emulation on astrocade shouldn’t be too hard considering you can already run tape games if you convert them to basicarts.

I’d really like to see things that aren’t yet emulated properly by anyone else instead of improvements on drivers like psx,n64,etc. where there are already plenty of good emulators around.

Even VTech VFlash emulation would be nice now that TOSEC added that set :)

On MAME I’d say sound support for FX 1B and Gnet would be the things I’d like to see sooner. Of course I’d love to see Triforce or Chihiro emulated on MAME, but they could never run at decent speeds so…

Zillion: He didn’t say more polygons, he said it can draw them 9 times faster. I guess to see more polygons in a game on a late rev PSX it would have to have been programmed by someone who knew that the hardware would eventually be capable of drawing them faster.

Zillion: the visible difference, if any, would be constrained to a higher framerate/less slowdown.

@mfc: VTech VFlash images have been in a MESS software list for over a year (even if TOSEC added some discs we don’t have), but there is not much to work on without a dump of the console…

@etabeta: They are? Never noticed them before, my fault then. What’s the reason for not having a bios dump yet, no one able to dump it or simply no one actually owning the actual console?

Another system I’d really like to see is Epoch Cassette Vision, but seems no progress has been done regarding dumping these. Hopefully one day someone will figure how.


two MESS questions:

Apple II: Lots of cool stuff changed recently, with the slot system and many cards emulated (Mockingboard and Phasor, yeah!) thanks to Arbee. Now I’m wondering about the whole NTSC color issue. Wasn’t the plan to use the HLSL functionality to get that right (also for CoCo and other systems, IIRC)? What’s the status there?

Mega Drive/Genesis: Kega Fusion is fine and all, but closed source. I remember reading the MESS implementation is mostly guesswork regarding timings and such. So is there hope for this really important system to have its architecture properly preserved via open MESS/MAME code?

TerokNor: we can’t rely on HLSL for NTSC until it works on non-Windows. The Apple II maintainer (me) would be Not Pleased if I suddenly couldn’t see color ;-) And no, I don’t know what that status is there. Both Olivier and JD have made noises about porting it to OpenGL, we’ll see what happens.

An architecture question:

What are the reasons for keeping both regular (windows) MAME and SDLMAME?

Not really advocating for SDLMAME (this is what I use personally), but it doesn’t make much sense to me to be developing two different builds and having to port features from one to the other, when SDLMAME already compiles on every platform and their feature sets are mostly identical (sans HLSL?).

Drifting a bit off-topic here in places, it’s not meant to be a list of things you’d like to see, but questions on the status / current issues facing emulation ;-)

Model 1, I think people were waiting on decaps, would be a better long term solution than simulation, although I have a feeling that’s never going to happen and people will need to simulate them anyway.

Model 2, Just use ElSemis emulator, there aren’t really any technical hurdles at this point because people have his code, just nobody has made use of it yet. In MAME terms I imagine all the CPU cores involved are out of date, and the handling of most of the video pipeline needs work (MAME ends up with all sorts of FIFO issues despite having a huge FIFO buffer). I think ElSemi HLEs some stuff MAME already attempts to emulate, but it would probably make more sense to just use his approach to get everything working before doing it at a lower level. I guess it could be seen as a problem that progress is basically locked to people who have his code (as to avoid reinventing the wheel) but there are plenty of other 3D systems people could work on to prove they’d be capable of porting it first ;-)

Model 3, Use Supermodel for now. Again SuperModel is open source, and the dev is MAME-friendly, so getting permission to use the findings / code there wouldn’t be a problem IMHO. The real issue is the lack of HW accelerated 3D, as already mentioned; SuperModel I believe isn’t even using a recompiler CPU core, just idle skipping / severely underclocking the emulated ones because the games (aside Virtua Striker 2) barely push the emulated CPU.

MD/Gen: There is better info out there now than when it was written, it’s getting rather old now, could certainly be improved or rewritten to be better than it is, especially on the timing front, and things like the accuracy of the sprite masking. Also I should *really* hook up the Save States, completely forgot it didn’t have them until I was working on that fighter with the SF characters.

Rotary controls are a core thing, not a driver thing, all I can say is they’re emulated well enough for use on a PC, using real controls would probably require a more ‘direct’ hookup to the ports however.

Re: HLSL see RBs reply, also it’s not the most user-friendly of systems compared to the ‘just turn it on’ NTSC simulations already out there.

regular Cassette Vision I’ve not heard any progress about regarding either dumps or emulation. Obviously MESS has a driver for the Super Cassette Vision, but I think it still needs a fair bit of work on the graphics and timing. No idea if the systems were in any way compatible?

MAME / SDLMAME, I’ve generally found SDL apps to be a bit klunky on Windows, also afaik the SDL stuff is a bit more limited (you lose some of the rawinput benefits? multi-keyboard, multi-mouse etc. which last I heard the SDL guys had deemed unimportant)

RB can correct me if I’m wrong there tho.

haze: Super Cassette Vision and Cassette Vision aren’t compatible, afaik the current issue is that no one can dump it’s carts so no progress can be made.
The SCV driver needs some work indeed, Takeda’s Common Source Project has a much more accurate emulator for it and it’s open source as well.
I believe the bios of SCV still need to be redumped too.

This really isn’t on Haze’s topic of “emulation status”, but I’ll clarify briefly: maintaining SDL is simply not a thing the way it was prior to 0.106 when half of drawgfx and all of the input handling was down in OSD. All of my SDL work since SDL landed in mainline at 0.138 has been dealing with external changes impacting MAME/MESS compiles (new GCC versions, Clang, etc), not SDL problems caused by MAME/MESS changes.

I’m interested in acquired but undumped roms. Some were listed years ago as being found, but are still undumped. “Elfin” was acquired in 2009, but it was said that it needed to be sent to “Guru” for dumping. There is also “Battalion” which needs decapping, and that “Taito” game that starts with “W” . I think another rom from years ago is “Happy Hunter”. What is the outlook on dumping these roms?

Thanks for an answer. I have one more question: what is the status of hng64? AFAIR You worked few years ago on that driver. Any hope for that one?

also, without SDL we would not have out-of-the-box support for Linux and OSX builds :)

Regarding the epoch Cassette Vision, it isnt compatible at all. It’s a CPU in the cart jobby and a custom NEC chip too that I cant find any solid info on (NEC D774c).

I have a cart (Battlevader) from the system but with it being some 42 pin custom chip I have no idea how to dump it. If somebody is interested and capable I will send it to them, I wont need it back, I only collect this stuff to dump and archive.

Pic: http://i.imgur.com/ATaPa.jpg

Ahh.. like the Microvision thing I just asked the MESS guys about then

I think people underestimate just how secure such solutions are, especially when there are no external roms to help exploit code weaknesses. In arcade games MCUS tended to just be used for security (except some gambling games, where they are used like here, as the main and only CPU with no external program)

Given that the entire reason the decap project was founded was to dump such things it’s entirely feasible that each and every single one will need to be decapped to actually dump it (if there is no readout mechanism / weak security due to them being early chips)

Not a pretty picture, but some companies DID secure their stuff well compared to others but many people fail to grasp this due to the sheer amount of things which have been emulated.

HNG64, I hooked up a bit more of the sound CPU a week or so ago, it at least seems to jump to the right places at the start now, but the behavior of the code still seems a bit funky. It’s possible they have DMA devices in there to copy data around rather than a mirror as things have been hooked up. Still it’s a step to giving them sound. Having the I/O MCUs dumped would really help with inputs tho, and possibly timing, the games are checking a few addresses in the shared I/O space. Another decap job for that I’m afraid, and even then the video system is nasty and setup in very different ways per-game.

Diet Go Go Fan> I can’t really answer questions regarding Guru…

Elfin would almost certainly drop into one of the Eolith drivers, so he’s either forgotten it, or it was never sent / turned out to be something else. You’d have to ask him.

Battalion iirc was just an updated / rereleased ‘modern’ Tank Battalion board with the program in an MCU… as you say, decap job, and decap progress is 0

Wyvern F-0 is entirely held up by politics, plus has an MCU too which will need simulating or decapping (it’s Taito and their behaviors tend to be subtle and complex eg. the way they’ve protected the level number wrap on Rumba Lumber by doing various operations between each level and only really checking it after you complete all of them)

Happy Hunter, no idea, again, you’d have to ask him.

Rom dumping isn’t really mamedev activity, it’s Guru / Dumping Union activity.

Has there been any progress on Konami’s “Tobe! Polystars” ?

It uses the konamim2.c driver.


Do you think anyone will ever take on the task of emulating the protection in Space Lords? :)

Tobe! Polystars (Konami M2) was last looked at by Phil B. but apparently there are some complications with him submitting anything (possibly the ‘incomprehensibly stupid’ FreeDO license which more than a few have complained about) he definitely had significantly more progress made than shown in the current drivers tho.

Space Lords, Charles was sent one what must be several years ago now, I don’t know if he ever ran any extensive checks on the protection devices tho, it’s definitely one where you need hardware tests to emulate it. I haven’t seen any evidence of progress being made. Charles is another one of those with a rather large workload unfortunately as he’s one of the few devs who works with the actual hardware to figure things out.

Has there been any progress on bootleg “Automat” ?

The game had serious differences of the original “Robocop” that make it more attractive.

It uses the dec0.c driver.


I haven’t looked at it recently, although the device conversions of the Deco stuff mean I’m more familiar with Data East hardware, and could probably get it running (add support for the bootleg style tilemaps + mixing). There are substantial changes from a hardware point of view, although it surprises me to hear there are software / game ones..



Well that’s certainly a colourful comment….

I think you’ll find Cave moving to more recent hardware has more to do with their old platform being obsolete and no longer visually competitive against newer arcades than anything to do with emulation, it had already been pushed past it’s limits with previous releases.

As for Nessica instead of plain Taito 2X, that’s probably got more to do with people hacking the 2X platform so that games can be extracted, run on a regular PC and also bootleged on dirt cheap PCs with no emulation involved at all, ie regular 0-day piracy.

But yes, you are correct, with that live service you won’t be able to own any of the games, it’s locked to specific locations / machines using a rental type model, and the games only exist as long as they’re available on the services, afaik the arcades won’t even have control over software revisions either, they’ll just get whatever the latest code on offer is just as the same type of services work on Xbox and PS3.

I have a question about some imperfect Konami hardware,the mystwarr driver and asterix driver if can consider fix,or people have some information on how to fix it?

There is room for improvement in most Konami drivers.

I don’t think anybody is working on them.

To Haze, Thank you for trying to say why the games are undumped. I asked about “Elfin” yesterday, and it looks like I may not get a response. I was not going to respond until I got an answer, so I could say why it is undumped.

Haze thank you for your prompt response.

About “Automat”:

The changes are:

– difficulty more easier (I think it’s because it runs a bit slower).
– different music “from Section Z”.
– different title and some messages in game.
– different end of game (no roll credits).
– other ¿?.

In other forum that I not remember, someone say that “Automat” it´s a Korean bootleg that were sold in Italy and Spain and could be based in a “Robocop” Prototype.

One Spanish person said in a forum that he sold a “Automat” P.C.B. to smitdogg some time ago.

So Haze, what you’re saying is that the Nesica system is going to make it almost impossible to emulate any games from this system, because of the hyper-centralized control that Taito will have over the games themselves?

There must be some way to counter it, but it’s gonna take something creative to pull that off.

yes, the games are only available to arcade operators, and afaik they only work when there is a live connection to verify them.. getting new games will clear off old ones etc, it’s very much ‘temporary culture’

if you think it’s hard to get pcbs of rare games now……

essentially it’s pure rental, pure digital distribution, with no way for a regular home user / pcb collector to get a look in unless you’ve got arcade ops actively hacking the hardware, and I doubt they’d do that as there isn’t the demand (plus where is the pride in owning a bootleg board, most collectors want originals) and the risk of being caught is too great.

the only thing worse would be pure ‘games as a service’ where the game doesn’t even run locally (many of the more advanced casino games are like that, central computer with the actual on-location boxes just being dumb windows machines running the content of a website)

The original Tetris ran on a Soviet clone of a PDP-11 with a VT52-compatible terminal. I’ve played it using SIMH and an xterm, but has there been any progress on the relevant drivers for MESS?

One of the MESS guys will need to chime in with an answer to that one.. far outside my area of knowledge

Is there any (behind the scenes) progress on SEGA System H1 / Cool Riders? I’d love to see that properly emulated someday…

H1/Cool Riders: Last I heard there were people looking at the sprite compression… was a couple of months ago tho. There is a patent which probably has the details, either that or a similar scheme which didn’t really offer great compression either, some other devs who looked couldn’t quite line it up with Cool Riders, but it’s similar, 10-bit based compression scheme.

any further progress with double wings a nice little
shooter by mitchell

nothing is being done to my knowledge about double wings or any of the remaining data east protection issues.

Original Soviet Tetris: You should ask on the MESS forum to get a definitive answer. I want to say it’s the bk.c driver (which is Soviet, PDP-based, and from the right era) but I don’t know for sure.

Cool Riders: It’s similar but not identical to the patent. The major issue was determining how the ROM data lines up with the patent; Guru ran some tests on the board that ended up inconclusive.

thx for your reply i guess for the most part
double wings is mostly playable a niggles though
on a seperate have enjoyed reading QA session
ive learned some stuff which is always good

insert these words into text above and it will make sense :) few note

Thanks Haze.


Unmap the devices for Automat from dec0 and give it its own state, making it easier to work with. From Haze (nw)

Regards bazar77

yes, I think it’s good to get the current knowledge ‘out there’ sometimes.. it’s good so that people know what is free to work on and what is just going to clash with unsubmitted progress etc. too

I was looking through the Sidearms driver and saw notes mentioning “unknown PROMs” but only one PROM in the driver is noted as unknown. Does that mean there’s a possibility it was not dumped correctly, that the data itself could have already been damaged when it was dumped, there are more that haven’t been dumped at all or none of the above?

I guess it would have been easier to ask what “unknown” means in that context.

“Unknown PROMs are mostly used for timing. Only the first four sprite encoding parameters have been identified, the other 28(!) are believed to be line-buffer controls.”

Is “encoding parameters” a fancy way of saying encryption?

How far from WinUAE is mess amiga driver? What is missing/incomplete?

Moo: The ‘unknown’ PROM is used for address decoding and partly determines the memory map of the sound Z80.

“Encoding parameters” in this context just means parameters used to draw the sprites.

It looks like whoever originally wrote the driver didn’t have schematics to hand. The driver could do with a little clean-up based on them.

Mess and WinUAE are miles apart in every possible area except maybe the basic 68000 emulation.

(Win)UAE is a project which has existed for as long as MAME, seen activity levels similar to MAME, and yet is still trying to perfect a single system, that’s how complex something like the Amiga is. The MAME/MESS driver IIRC is just something Aaron and friends knocked together quickly to run the arcadia stuff, compatibility is very hit & miss; the A1200 won’t even accept disks and afaik there’s no extended device support _at all_, CD32 controllers don’t work and most models aren’t represented at all (to use a KS2 bios you have to run the A500 and change the bios option, which is completely wrong because it should be a different chipset etc. such options aren’t even saved between sessions) It’s one of the most underdeveloped MESS drivers for a mainstream system.

What a pity. I thought that it’s in better shape.

in fact, A500 emulation is not bad (there was a very good bunch of improvements by Ernesto Corvi after the initial quick addition) and a lot of demos and games just run fine.
but as soon as software abuse the hardware (like some demos do) or if it needs an A1200, then MESS is definitely not a good option atm

I found a lot of software just caused the a500 to reset, some of that was fixed by adding extra memory (an unexpanded a500 was a rather rare configuration) but MESS doesn’t really make that obvious (and I don’t remember stuff crashing on an a500 for that, it usually just complained so I have a feeling it’s not being detected as an unexpanded a500 in all cases…) This mostly comes down to a lack of sensible visual defaults / quickstarts etc. which WinUAE offers you. Also MESS not having ‘disk sound’ simulation means it’s not always obvious if something is hung or still loading, the obvious signs of the drive lights and sounds aren’t represented at all. Combine that with the lack of fast-loading, and the fact the driver isn’t very fast unthrottled and you’re left wondering if it’s still doing anything half the time ;-) Also the fact that the default joystick is P2, and therefore maps over the regular keyboard keys, because the P1 port is the mouse is another one of those annoying quirky MESS behaviors which you don’t realise until you go digging in the (very disorganized, non-visual) input menus.

generally I found compatibility to be rather bad, and the way the a500+ / a600 are kludged in as a non-saved bios selection limited that further, a fair number of disks need KS2 to boot and you can’t even soft-reset the amiga driver without it messing up.

I was going to do an update about some of the stuff in MESS, including Amiga stuff, but didn’t really find anything about the driver adequate enough to do an update recommending it, it’s too awkward / buggy / incomplete / inflexible / non-obvious. I believe it’s still tagged as non-working, so that’s understandable, but it’s not really one of those non-working ones you can have a lot of fun with at the moment IMHO; the out the box use / experience you get with it is just too poor.

WinUAE and VICE are currently not even touched by MESS. They are miles apart.
Which makes sense in fact (Haze explained why).

Then again sources are open… maybe a good code thief…

UAE, maybe. VICE it’s less clear-cut: MESS’s VIC-20 is very good even for “tricks” and several people use it successfully as a development system for hardware. I can’t speak to the PETs or the TED machines.

Amiga’s ultimate problem is the lack of a maintainer who likes the machine and understands its internals. Haze meets both of those criteria but he’s not interested for whatever reason.

WinUAE (not UAE) definitely.
VICE, maybe less of a clear-cut indeed.
Still I am not convinced entirely.

Does this work properly in MESS?
(just curious)

I’m not that hot on the Amiga internals at the level needed to do something like MESS (or even UAE) development on that system. You’d want somebody who extensively hacked the hardware back in the day, and while I was coding stuff on the platform I wouldn’t say I was ever hacking / trying to understand things at a low level back then. Most stuff (copper effects and the like) I just took for granted as ‘this works’ without ever even trying to understand why. I suspect I wasn’t alone which is why you see the same cheap copper rainbow effects etc. in so many games.. It might have looked ‘cool’ at the time but it was just a cheap easy to pull off effect compared to the people making full use of it ;-)

It was only really the demosceners, and some of the euro (non-uk) developers who really pushed the system, exploited everything it could do, and understood it in great detail. That said there’s still a world of people out there who could do a far better job of the Amiga driver than me or anybody on Mamedev / Messdev, so it’s a shame it isn’t getting more attention.


Tony Wilen would never help eh? :D

Haze: I *know* you can reverse-engineer tricky stuff, I’ve seen it happen. And in this case, the UAE source already documents all the magic numbers. C’mon, be Amiga’s amigo ;-)

Re: Tetris and terminal emulation.

The original terminal (15ИЭ-00-013 / 15IE-00-013) is not emulated; neither is the follow-on display controller (КСМ ДВК / ‘Character Display Controller’). These are almost, but not quite, complete VT52 clones; one difference is that 0177 (DEL) character produces a filled rectangle — this is used by some versions of Tetris (not the original one).

There is a technical manual on the 15IE, so emulating it is not out the question.

Haze has plenty to do AFAIK.

Although since for me real computing starts with C64 and ends with Amiga, I would love for some “powerful force” to get things going even further. ;)

Wilen does a great job with WinUAE. He is quite a character though.(but this seems to be the fashion in emulation scene ain’t it? Inc. you Haze ;))
VICE team got way to slow last 20 months. Maybe they are not really interested any more. This project does need a boost.
MAME (with MESS in it) also needs to get going eventually.

Emulation does need to turn the page. It is ironic that people that use modern technology to emulate older technology, many times actually actively deny to go forward (and we have sooo many examples). Well maybe it is not ironic after all. ;)

I just tend to think sometimes it’s best to have people most suited to the job. There are already too many MAME drivers I’ve worked on more through necessity than anything else… plus I tend to like to discover things, and I’m not really sure there’s much left to discover with the Amiga.

Given you’re the one dictating how you think the Amiga driver should work I tend to think you should be the one doing it. I know you don’t want to put yourself in a position where your own past statements can be used against you, but live dangerously for once ;-)

“and I’m not really sure there’s much left to discover with the Amiga”

Blasphemy! Blasphemy!


Amiga never ends.

Haze. Become an amiga hero! ;)

Well basic stuff like having proper A500 / A500 Plus / A600 etc. models represented with the correct default configurations is kinda obvious ;-) At the very least the KS2 / ECS machines should be represented as different base entities than the KS1.2 , KS1.3 / OCS models. That’s a days work at most, anybody could sort that out properly.

The rest (quickstart configs for the most common base + expanded configurations, more organized config menus / defaults etc. more obvious ways to set up system specific stuff) is core work / mess policy, not driver specific.

I’m simply not interested in taking on that role, Amiga is something which would need a lifetime commitment, which is why WinUAE is still making compatibility fixes even after being around for as long as MAME, everything has to be *perfectly* timed and balanced, and that’s not something I’m good with. Believe me, you want one of the old demosceners on that one, somebody with an ACTIVE interest in the platform who is going to go to run tests on a great variety of hardware, or somebody who will just copy bits of knowledge out of winUAE (and where’s the fun in that?) The only Amiga I have left is an unexpanded A1200 which had dodgy video output, a failing floppy drive, and saw the rest of it (HDD etc.) recycled for use in a PC many years ago.

I tend to believe in ‘right person for the job’ if you want to see things get done properly, and historically that’s been the problem with Mess, the people doing the drivers tend not to have been the best people for the jobs (which is especially true of Mame drivers which then get turned into Mess drivers)

Unfortunately the best people usually just end up writing their own standalones, which is the bigger problem in need of addressing, why doesn’t Mess appeal to them? Is it a desire to understand things 100% from the ground up, or is the framework lacking something they need? are they just not team players? do they want more complete control over the end user experience that MESS can’t give? do they think it’s a competition? do they just not know about MESS and the vast resources it already supplies?

I agree with you on the first four paragraphs, I said so already.

Now about your questions. Good questions…
I am sure everybody has his own reasons.

I think desire to understand things from the ground up is one reason (most emu projects start exactly because of that).
– Not team players… Big discussion. Are MAME/MESS teams good teams to be a part?
– Certainly complete control is a MUST to reach the level of for example WinUAE. AFAIK in MAME/MESS if you make a core change because you need it, you might very well break 125 other systems. No good. I think MAME/MESS code needs more modernization yet I don’t claim to be an expert (I *do* come from programming background though, so I am also not clueless).
– Competition? Nah. I think the only project that thinks everybody else is competition, we know which is it…
– Indeed maybe they just don’t know about the vast resources behind MESS. Then again this might see them as overwhelming. Or they find this as a restriction.

I see only one way to boost MESS awareness. MAME. But let’s not start this discussion again.

This thread is loosely related and interesting I think:
— no big members only rom site links please —
(or how it turns… or I turn it? after a few posts)

If I may comment on Haze’s last post, I know it is drifting off topic, but I think it needs addressing. I am posting this message as a user, not a developer, and that is my perspective.

I think the way MESS handles software and it’s entire UI put me off using it. A unified emulator core can work over a number of systems (MAME proves that), but I don’t think you can transplant the MAME UI methodology over to a multiple computer emulator.

If we look at just one driver (close to my heart), the ZX Spectrum. There are inherent usability issues because of the MESS interface, i feel it comes between the user and the software. If we do a comparison to an emulator I have purchased, Spectaculator (www.spectaculator.com) , you can see for yourself that this emulators usability and UI are worlds apart from MESS (Windows, not iPhone version). I don’t mean to disrespect the MESS development community, it is my hope that MESS improves and exceeds this high standard. But for me, I wanted to actually have access to my retro collection easily, the fact it has an easy to use UI is a bonus.

So what would *I* do?
I understand you cannot compare chalk and cheese. I understand portability and the necessity to keep the UI text based for those reasons. So what to do? Well how about in the menu where you go UP/DOWN to select the system, what if pressing RIGHT swapped you over to the software list for that system, with ENTER starting the emulator with that game loaded? LEFT would take you back to the previous menu. PAGE UP/DOWN can move the selector to the options above and below the system list. For this to work, like MAME, there would have to be default paths for software lists, with pre-defined names.

To get developers interested in MESS, the user base needs to be there, to drive interest.

Speaking of usability and reducing S-n-R in communications. When MESS/MAME starts a driver that ‘Does not work’, is there a reason the driver starts instead of just throwing you back to the UI?

I want MESS to improve and grow, what you devs are doing is amazing, so don’t take any criticism as a slight or sign of ungratefulness.

What is the current status of the MD/Genesis driver with regards to battery back-up? – This may have been answered with the “Rally implement save states” comment above. I think this is currently unemulated for the Gen Driver.

Any progress on the SNES driver with regards to support chips SA-1? SuperFX? Not really sure who was working on this one.


when loaded from the softlists I think the genesis stuff should have proper backup ram hooked up, when loaded without the softlists, it probably won’t because I hate hacky ‘header based guesswork’ code (the built in rom headers are entirely optional and aren’t always right so you just end up having to add a whole list of one-off special cases)

If it isn’t working, then it’s probably a softlist issue, or the code was never properly ported from HazeMD (I didn’t transfer it to MESS myself)

aren’t most of the SNES chips hooked up, just requiring you to run clones of the base SNES driver due to mess limitations?

SA-1 doesn’t exist right now. It’s mine when I want to do it but much as Haze doesn’t want to touch Amiga because UAE exists, touching SNES when bsnes exists is a no-win scenario. SuperFX is hooked up and worked fairly well at one time (all the games using it worked properly except Yoshi’s Island) but it regressed hard about a year ago.

I’ve raised similar UI concerns with the MESS guys myself before, but tended to be buried by them saying things are just fine..

I 100% agree that the interface simply isn’t user friendly, it doesn’t present what’s relevant to you in an understandable way, you have to navigate through far too many menus to get what you want, things aren’t even in obvious places.. to just get from mounting a cassette, typing what you need to load it, then playing it is far too many keypresses, and you’re mounting the cassette in a completely different menu to playing it back; you don’t even have the option of keeping the cassette controls on the screen to be mouse driven or anything like that. ‘Please stop the tape’ on multiloads becomes a hilarious scramble through keys and menus.

The answer you’ll get from the Mess guys is basically that everything you need to know is on the wiki pages / info files / readmes.. but that’s simply never going to cut it for most people.

It’s not that MAME wouldn’t benefit from a friendlier interface too, editing things like the layouts isn’t intuitive at all right now, and the HLSL sliders, volume controls, lack of properly ordered key config menus, management of NeoGeo memory cards etc. all just feel very klunky, you just notice it a lot more with MESS where you’re forced to actually use the menus more, especially if you’re coming from other emulators.

The problem is it has to be done in a new cross-platform way, the general idea old versions of MESS had with the ‘newUI’ code wasn’t terrible, but it was too windows specific, and didn’t cater well for cases where you were running at low resolutions (which most of the emulated stuff runs at!) The UI in MAME has hasn’t really changed in meaningful ways since the very first versions, and the mono-pane culture you have with the menus etc. is starting to show it’s flaws against multi-windowed systems (even the old Nesticle, Genecyst, Callus, Meka* etc. emulators showed how to do a user friendly, powerful internal GUI if you didn’t want to rely on OS specific components, hence their popularity)

* yes, it really is nice and user friendly to be able to open little sub-windows with the palette in, vdp tiles in, hover over them and get specific colour information, or pixel information, to have file selection dialogs that can be open at the same time as other dialogs, know that if you open the controls menu but realise you forgot to stop a tape that you can still visually see that, and don’t have to go back 3 menus, and forward another 3 just to do it, but can instead just click on the stop button etc. etc.

The thing is you’ll now get all the devs pointing to Win8 and phones and say mono-pane is the next big thing.. but .. urgh.

Your ‘why do not working drivers start’ question has a more obvious answer tho… how would you develop something if it threw you back every time? ;-) ‘Not Working’ covers a broad range of stuff, some of which is perfectly usable for 50% of cases, some of which doesn’t do a damn thing. Filter such things out at frontend level if you must.

None of this is to say I don’t like MESS, or the idea of MESS, and I do think it’s absolutely invaluable when it comes to development to be able to emulate anything you want, and be able to have all possible resources available to you when developing something (hence UME in the first place) but without some improvements you’re 100% right, it will struggle to stand up against the standalones which is why I consider it’s strong point to be a convenience if you’re used to MAME / developing something for MAME rather than MESS being a first choice emulator for anything or anybody by it’s own merit at the moment.

I firmly believe that with the right developers on board MESS *will* be the future of emulation, and MAME will end up just being the arcade component of that, but the time period for that happening I can’t even begin to guess.

Solar Assault:

Ville said back in February that he had re-written the GTI renderer for Solar Assault and it looks amazing now, judging by the screenshots.


[from his February 11, 2012 update]

So is Solar Assault any closer to running in MAME now?

@rychem: backup ram for genesis worked perfectly last time I tried (except for the few games using an eeprom instead of the backup ram). have you found any game not working? from softlist it works automatically, if you load from fullpath it relies on the internal header so it might fail for some protos which do no set up the size properly

@KonamiFan, Solar Assault works, you just need to initialize the eeprom while booting (press F2). :)

Yeah, Solar Assault was even playable for 2+ years prior to when Ville wrote that. It’s fairly alarming how many people don’t know that :)

Do You need NASA cpu for it? ;)

i5/i7 >= 3.2 GHz should do fine.

@etabeta: I need to further investigate teh eeprom versus back-up ram. I have played a few Genesis games where the battery back-up was not saved (Evander Holyfield’s Boxing for instance), however I was not using the softlist at the time, so maybe that was the issue.

@Arbee, if you try loading Solar Assault in MAME 146, MAME still reports that Solar Assault doesn’t run, telling you to wait for the developers to improve the emulation, even though it does run after initializing the eeprom.

MAMEdev may wanna fix that message! ;)

how the status of Spectrim emulation in MESS ?
I mean is anyone planing to implement necessary “core” things to make speccy driver pixel accurate: raster effects (something similar current border emulation but for whole screen), memory latency, etc ?

I hope, some day, I’ve see nice scroll on border and raster effects in “Quarx”‘s high score screen under MESS ;)

Spectrum.. I think still needs a fair bit of work (probably pixel accurate timing as you say)

A fair number of original tzx tapes just fail to load (reset after loading, or never finish loading) forcing you to use pirate ones or tapes with different protection schemes. I also had issues with inputs in some games, although that was during Aarons input rewrite so I need to revisit those to make sure they weren’t just temporarily broken.

I’ve not really seen any active development on it so I guess nobody is looking at it.

Spectrum is again one of those systems where it really needs somebody who understands the workings of the ULA to get it right. Hap recently fixed some bad cycle timings in the Z80 which probably weren’t helping, but in general the video emulation needs to be reworked from scratch.

You could probably say similar (needs somebody dedicated) for the majority of drivers to be fair, it’s just the ones with a substantial software library with various bits of copy protection trickery and other hardware abuse where you notice the flaws.

CPC seems similar to the speccy in that an awful lot of the *original* discs fail (could be in the disc handling code of course)

Of course an awful lot of the machines MESS emulates are so obscure they have almost no software and so nobody is going to notice if they’re not 100% accurate, much like many MAME drivers which run one game. (Pretty sure you could do insane raster abuse on most of the 8-bits, even the ones with no games ;-)

Right, I rank the necessity of someone with advance knowledge of the system based on how abused it was. And by any measure, the Spectrum is some of the most-abused hardware ever released. Whereas Curt is likely very safe from any kind of vector balls ever happening on the Wang Professional ;-)

Next question. :)
I remember reading about some games being actual PC boards (I think 486) with voodoo cards. Is there a reason that for the actual CPU, that instructions are not passed on ‘natively’ to the host hardware and speed locked rather than write what amounts to a 486 emulator in MAME*? I know GLIDE will require emulation and kill the host CPU anyway, but my question is more angled to a technical why.. rather than any interest in those games anyway :D

*I understand documentation but the x86 instruction set rules, it runs Windows, Mac and Linux, so documentation now should not be a concern?

Also.. would a GLIDE > OpenGL ‘patch’ be ‘appropriate’?

Curt’s going to be hoping the demosceners don’t take adding some balls to the wang as a challenge now…..

MAME/MESS run on many other platforms other than x86 based, including ARM tablets etc. so it always has to have cores done in C.

I guess there will be an x86 recompiler at some point down the line (current performance is very bad, struggling to emulate a 25mhz 486) but right now there isn’t, and that doesn’t answer your question.

It can’t just be done ‘directly’ for a variety of reasons, x86 can’t really self-virtualize the way some other architectures can and there are significant differences in timing, and sometimes behavior between modes which means some code simply wouldn’t be happy with such an arrangement anyway. There are various extensions you will end up having to account for too, eg the AMD 3d-Now type stuff, which was different to the Intel acceleration… It’s just not as simple as saying ‘this is x86 code, we can run it natively’

Hello Haze, and thanks again for being such an open person willing to answer questions regarding emulation status. I have one such question regarding Konami System 573 Analog… (ksys573)

What exactly is the status of figuring out audio protection with this system for Bemani games? (ddr3mk, ddr4m, ect…) I know enough about the game to understand that the game draws the notechart from the audio track. Thus, if the audio isn’t functioning, the whole game won’t work properly, as in the state it’s at now. There’s been progress made with the driver since it was written, as the sound effects and voices work properly now, but not the audio. I was wondering what was giving the DEVs so much trouble with the audio, and what part was protected, in particular.

Thanks again in advance, and I’m glad you are willing to do this. ~Player PJK

problem #1, it’s encrypted, not sure OG could fully figure it out

problem #2, it’s MPEG, and somebody on mamedev is going to have to decide they don’t care about MPEG patents, or just give the option to build with/without the MPEG code and allow people to compile it themselves for use where the patent regulations don’t apply. (much as say LAME does by only offering the source, forcing people to actually build a binary)

Kyo: the 573 *analog* games (DDR1 & 2) do have music and are playable since it’s just Red Book audio tracks. You’re talking about 573 Digital, which is encrypted up the wazoo and neither OG nor Andreas Naive have been able to make head or tail of it unfortunately.

@Haze – Ah, I see. Legal Issues. Oh Well. Was worth a shot at asking, anyway. Now I know. AND KNOWING IS HALF THE BATTLE.

@Arbee = Whoops! My bad. I typed in the wrong thing by accident. Thanks for letting me know about that, though. Cheers.

Does drum mania emulation fall under the DDR games?

Peter: Yes.


Any progress on STV encrypted games (ie Decathlete)?


Keeping with the line of thought of the universal emulator, there are some things I’ve been wondering about.
First, now that pinball and slot machines are in MAME, what CPU based systems are not allowed in MAME(/MESS)? Pachinko? Pachislots?
Second, are any of the first generation consoles emulatable (or already emulated) by MESS? I suppose what I’m getting at here is, where any of those single-chip logic systems MCUs or where they all an IC of TTL?

See for instance the screenshot of Draw Poker (AY-3-8800) and others here:

I realize of course these chips would probably be hard to dump…

Hello Haze,

I have a question regarding Mega Drive / Genesis in MAME and MESS.

In Streets of Rage 2, in-game and in-menu sound effects are quite different than while playing the original cart. It’s easily noticeable while performing the jab move (B button) as it sounds really high piched.

However when playing sound effects from the sound test menu they seem to be correct: the jab noise (SE 00) sounds as it should.

I know that the Gen/MD part in MESS and MAME comes from your code, is there a chance you would look at this issue?

No progress on Decathelte, the (debug) code shows that we’re clearly processing the right data when copying it, but we don’t know what to do with it. Decathlete is actually different protection to the others in that they upload various tables first; I think it’s compression rather than encryption and is thus a bit trickier.

re: eligible systems
anything with a CPU, Pachinko, Pachislots etc. are all fine. They might never be playable in MAME alone (without 3rd party software to sim the tables) but they would definitely be added if they were dumped, simple fact is I don’t think any are. MAME and MESS will emulate *anything* with a CPU, as long as there is interest in doing it.

Genesis sound.. I can take another look, but that sounds like a rather odd issue, especially if it’s fine in the test mode.. I don’t know why it would differ, but enough people have complained about (minor) Genesis sound problems… I thought maybe it was just the Megaplay version being different to the regular Genesis one, but if it happens in MESS too then it can’t be that.

@Haze – Thanks for the answer. The sound problem in SoR 2 is indeed present in both Megaplay and Genesis/Mega Drive versions. The Japanese and European versions use a different cart than the North American one and have this problem too.

About Space Lords (and the other Atari games with identical protection) I need to make a circuit that will let the FPGA RAM be snooped, so the real (unobfuscated) RAM data can be observed and compared to what the FPGA returns. Right now it’s just an issue of no free time and being broke. :D But it will definitely happen someday, haven’t given up yet on this one.

Haze, thanks for your efforts on progress “Data East” drivers.

Now that you are checking the “Data East” drivers, What is the situation on implement the light guns control in the game “Locked´n Loaded” ???

What is the emulation status of this games ??:

– Big Fighter [Tatakae Big Fighter] (Nichibutsu, 89)
– Spark Man (SunA, 89)
– Gals Panic 2 (Kaneko, 93)


Haze just a note please: I have a new comment that begs for reply in your UME post.

And a side note, irrelevant: Seems I am still banned from that other forum. So much for temporary bans and/or respecting a nine years old account (older than most admins).

Big Fighter has a protection MCU, I think people were waiting on it being decapped because it controls a few game functions (more than Nichibutsu usually protect)

Spark Man has the usual mess of SunA encryption / protection / banking / dummy writes to banked out regions. No dedicated protection MCU on them, but it’s all very messy to figure out. We did want to run some Trojans, but the encryption makes it tricky (different code/data encryption) and the various z80 assemblers don’t support that so you’d be having to write + encrypt everything by hand, and even then it’s not easy to know what to test. They’re probably all possible, but somebody would have to invest an awful lot of time into each game and nobody has the required level of interest to do that.

Gals Panic 2 hasn’t really advanced at all recently. Like most Kaneko MCUs of the era it appears ‘functional’ rather than being something which supplies any vital data from an internal ROM (that’s the good news), however the functions it supplies aren’t all obvious and I’m not really sure the way it’s hooked up is perfect either. It *might* also be decompressing some of the BG data (the decompression routine on real hardware is very slow to say the least)

Haze, thanks for your information.

Lock ‘n’ Loaded I’ll probably take another look at soon.

I have a feeling people have tried to hook it up and failed for 2-3 reasons.

1) It’s a *real* light gun game (not the screen flash).. this possibly means it needs an extra interrupt or similar when the gun is fired. It’s also possible it will want to read back something like pixel colour as well as the positions.

2) The calibration menu is rather well hidden, and even if you hook up an interrupt and readback it probably won’t work until you access that menu.

you have to turn test mode by tapping the test mode switch (press f2), then hold down service1 (hold 9) then while holding that tap the soft reset (press f3)

that gets you to a calibration screen at least, although right now you can’t calibrate anything.

3) The sprite code is going to need a fair bit of work to make it more optimal because Lock ‘n’ Loaded will require proper priority mixing which Dragon Gun cheats on to avoid too much slowdown when rasters are going on etc. Needs a proper scanline based sprite renderer I think (don’t think you can even just create a large sprite framebuffer as the blending is too complex) — this one is more minor, you could make the game work without it, but the priorities would be wrong

I found out some more about the single-chip first generation consoles.

Atari Video Pinball (C-380) uses a micro-controller and a small amount of RAM.

Atari Stunt Cycle (C-450) uses a custom microcontroller and has minimal color.

I also suspect some other titles but haven’t looked into it further.

So, are MCU based consoles eligible for MESS?
Has there been any discussions, efforts, etc about this in the past?

Hi Haze, ist there any chance we will see Winning Spike properly emulated in MAME sometimes in the future? It’s by far the best volley game out there.

MCU based consoles are eligible as long as somebody can dump the MCUs*… that might mean they need to be decapped if they provide no readout mechanism.. and yes, that would be expensive, and risky, and there might not even be anybody active to do it.

* assuming we’re talking the same definition of micro-controller / MCU, ie a CPU with internal rom, if not, it’s just a traditional emulation task, but you’d still need a rom dump.

Winning Spike is as good as it’s going to get with the current Konami code… pretty much everything Konami needs rewriting from scratch with current levels of knowledge. That would be a massive undertaking for whoever does it. It should be fully playable tho, despite the graphical errors.

two of my favorite games back in the day were
vimana and fireshark bot of which at the moment
have no sound in mame due to the sound roms
not being dumped yet anyway just wondering
what are the reasons why there has been some long standing issues with some toaplan games regarding sound emulation

the sound CPUs are MCUs, with internal ROM.

There is no known way to extract the sound program without decapping them, these should have been amongst the highest priority decap chips, but unfortunately weren’t.

it’s an expensive, risky, and time consuming operation and only a few people in the whole world actually have the setup for it (and it usually results in a fair few chips being killed before success) but it’s the *only* way to properly emulate the sound (not just using crappy looped samples how a bootlegger would and some rough MAME hacks do)

As you can see the last decap update was in January of last year, and that was just a qsound chip imaging, not even vitally important.

Unfortunately this is the answer to a LOT of the questions being asked, because the simple fact is in many cases these things were 100% secure.

Fire Shark, Vimana, Teki Paki, Ghox and the Japanese version of Whoopee are all protected using this family of chips for the sound.

As a developer alone there’s nothing I can do for these cases, the data from inside those chips is *essential* because it contains all the original music sequences and code required to play them.

thx for your reply Haze as always an interesting read

Has anyone done any recent work on the CD-i driver? I seem to recall it got a flurry of attention a while back due to MAME getting some CD-i based arcade machines… I was looking forward to some MESS benefit as there really hasn’t been a good CD-i emulator, but nothing solid ever seemed to come from it.

Is this system held back by MPEG legality issues too?

What is the status of the N64 driver in MESS? I recall reading something a few years ago about a legal hangup regarding MooglyGuy’s work and was wondering if anything has changed since then.

The CDi and N64 are Mooglyguy’s 2 drivers.

There was some work on N64 a couple of months back, but due to the goal of it being full low-level emulation it’s never really going to rival the standalones for performance, and while the overall goal would be better compatibility it’s nowhere near there yet either. I think it still has crash issues on 32-bit builds too? You can see that there has been visible progress simply by checking ‘Tower & Shaft’ in MAME tho, which is basically fully playable these days, albeit at 50% speed. (and that’s a 2D game) In MESS terms it’s still very preliminary tho, with a fair amount of stuff still just crashing the recompiler, and the rest running so slow nobody has really played it beyond seeing if it boots.

CDi suffers from a ‘fix one thing, break another’ problem. Every time a bug fix is put in it seems to break something else. This surprises me a bit because the games are quite high level, designed not to be too fussy on their own so that the underlying hardware designs have room to change (which they did, quite significantly) but it’s still not an easy case. Ideally the ROMs for the various slave devices would be dumped to allow for a lower level of emulation, which might reveal some subtleties that were missed, but again these are internal ROMs with no known readout mechansim. CDi problems are also compounded by MPEG patents, with the vast majority of the library being MPEG material. Basically aside from MPEG the pieces are all there, but they’re not just quite fitting together properly.

The N64 legal hangup being referenced went away, by the simple fact of angrylion actually doing a majority of the work.

CD-i really needs to have the MCUs read out, but I’ve given up on anything else being decapped at this point.

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.