Emulation Status

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..
http://en.wikipedia.org/wiki/Pioneer_LaserActive

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 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!

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.

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’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

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…)

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.

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.

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.

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

http://www.ps3devwiki.com/wiki/Emulation

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/

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?

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: 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: BBC
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.

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

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?

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..

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.

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.

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.

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.

Re: BBC
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++.

@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 :)

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

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.

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

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: the visible difference, if any, would be constrained to a higher framerate/less slowdown.

@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.

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.

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?

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.

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?

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

Ahh.. like the Microvision thing I just asked the MESS guys about then
http://en.wikipedia.org/wiki/Microvision
http://atarihq.com/danb/MicrovisionCarts.shtml

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.

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

It uses the konamim2.c driver.

http://www.progettoemma.net/gioco.php?game=polystar

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.

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.

There is room for improvement in most Konami drivers.

I don’t think anybody is working on them.

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.

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)

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

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.

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

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

Thanks Haze.

http://git.redump.net/mame/commit/?id=808639188a63c5b0dfe300e5ef9906f7f13cbd87

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

Regards bazar77

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?

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.

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

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.

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.

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.

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 ;-)

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. ;)

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 ;-)

Haze. Become an amiga hero! ;)

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)

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.

Thanks

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.

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.

@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

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 :)

i5/i7 >= 3.2 GHz should do fine.

@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! ;)

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.

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 ;-)

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’?

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’

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)

@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.

Peter: Yes.

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?

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?

@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.

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)

Regards.

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)

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

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.

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.

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.
http://decap.mameworld.info/

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.

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?

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.