Back in 2004 we lived in a time when not all ports of games were simply emulation based, but instead many were genuine reprogrammed piece of software. I briefly mentioned the Radica ‘5-in-1’ Space Invaders TV Game in my previous update, and that’s what I’ve been working on over the past week. If you follow my YouTube channel you’ll have noticed various Work in Progress updates on it.
It’s an interesting piece of hardware / software, and emulating it has so far been a lot closer to emulating a console than a piece of arcade hardware. Everything is driven off a 6502, but with various DMA channels and an unusual video system which stores graphics in texture pages, but then for the tilemaps, still addresses them as tiles etc. and in the case of Qix can also change the base pointer from ROM to RAM.
It also shows that back in 2004 this kind of thing was a viable product. Sure, there were emulators, and you could easily make a case that MAME ran all the games in this collection just fine back in 2004, although truth be told MAME wasn’t actually great back then (which is why it’s so painful to see people using MAME cores older than that just for the sake of running it on some god-awful hardware like the SNES mini)
So far I’ve managed to get most of the video features working, or at least have some understanding of them, although I don’t think anything is quite perfect yet. Transparency pen is definitely wrong, as is palette selection on the 8bpp sprites. Palette itself was an interesting one, it’s clearly based on some kind of HSL type colour model, not RGB, again making it very unusual compared to most arcade hardware I’ve emulated. Colours are mostly correct in MAME with this model, but certainly not quite right yet.
Sound, which I haven’t got around to emulating yet, appears to be 6-channel ‘DMA’ DAC style, where the game code sets pointers to rom and fires off a trigger. It looks like these might also generate a custom ‘finished’ interrupt too, as well as setting ‘finished’ flags (which the games wait on sometimes, hence the Radica logo vanishing so quickly I believe, because we’re always reporting sound finished right now)
Before continuing, here are some shots of the Space Invaders one running.
The programming on these is interesting too, the hardware clearly has a way of having higher priority tile clip out sprites and based on real hardware footage Lunar Rescue uses this at the edges of the screen to create a slightly narrower view. Strangely Space Invaders doesn’t, and instead has some ugly wrapping effects with the UFO even on real hardware. It seems like the individual games might have had different programmers behind them, because each one seems to make use of the hardware in slightly different ways. Aside the aforementioned clipping there are a number of other annoying issues issues too, for example the code buffers the sprites, so there’s a noticeable input delay. This delay is really noticeable in Qix where the background layer isn’t buffered so while moving you can see your line being drawn where the player sprite should be, ahead of the actual sprite! I’ve checked real hardware videos and the same is present there.
This is really where I was going when I said in 2004 these things were more viable than maybe they are today. None of the reproductions on offer here are perfect, it’s easy to tell them all apart from the arcade originals, but at the time standard definition CRT TVs were still in the majority and a number of these games ran on vertical monitors, so you’ve automatically got a resolution issue with most TVs being unable to display the required resolutions without at least altering the graphics / screen arrangement. It would also have been relatively expensive to have a CPU capable of emulating these things back then (the mainstream consoles of the period were only just capable of it) Likewise filling the units with the CPUs etc. that the original games used would also have been expensive (and likely the parts difficult to source) so instead you got ports, rewrites of the games that were suitable for the hardware available at the time. It’s not actually too different to how/why the 8-bit computers got ports in the 90s, except by 2004 it was much easier for developers to get access to original resources such as graphics / sound rather than having to do those from scratch too.
These days emulation has set the bar much higher, and while you still do see sub-par products like the NES Classic and various Raspberry Pi based solutions somehow selling despite still based on 15-20 year old emulation knowledge, they’re still a step up in quality than something you could just plug into your TV in 2004. Admittedly there are still hundreds of cheap Chinese handheld devices based on similar evolved 8-bit tech to these things, but very few of those claim to be in any way licensed.
I guess that’s what makes this kind of device fascinating to me, they’re official ports of the games just like any other, but they’re also “dead-end” ports, versions of the codebase that existed at the time and have no commercial reason to be brought forward; creations that exist because limitations of the time made them more acceptable back then.
Obviously MAME has roots in arcade emulation, and being able to show the course of evolution of these arcade games, how they ended up on home systems and in devices like this one actually means the path of the project is reflecting the course of the original material. How was Taito giving access to their 1978 hit Space Invaders in 2004? By allowing Radica to license the IP produce these devices so people could play it at home. Now, thanks to emulation, we can help to document that part of the story too, show where these things got it right, and where they got it wrong, and what possible reasons there were for that.
Radica didn’t only use this hardware for the Space Invaders product, there was also a gimmicky version of Tetris running on it, and probably plenty of other titles. We know they switched to a XaviX based solution at some point (which is more complex and has actual custom CPU opcodes etc.) but there are almost certainly a whole bunch of other products running off the same hardware as this one.
The Tetris one is interesting for many of the same reasons I highlighted above, it’s another thing that was licensed and ported all over the place, and being able to document / show that is culturally and historically important. Unfortunately the Tetris one crashes in MAME when you try to start a game at the moment, so it’s not too interesting to show at this point.
One thing of note about the Tetris one is that you can access a hidden test mode by holding Down and Anticlockwise. Space Invaders contains images for a similar test mode, but I haven’t worked out how to access that one.
This also allows player 2 inputs to be tested, which is going to be fun to figure out because I think they’re being read in a strange way, maybe via Serial or some hack of the ADC because they’re not read directly (which maybe shouldn’t be surprising, the P2 controller is optional and plugs into the P1 controller)
Anyway, I’m going to continue to try and improve these, look into adding the sound, see if I can figure out why Tetris crashes, and fix up the transparencies. I’m also hoping some more games on this hardware get dumped. Sean Riddle picked up a “Golden Tee Home Edition” and “Skateboarding” which both look like they might fit here (and if they do, both use horizontal scrolling to, so will provide additional evidence for improving the hardware emulation as nothing we have so far does)
*edit* I’ve improved the video emulation a bit, here’s an updated video showing the current state, some of this is a bit hacky due to lack of software to make conclusions, but at this point I think any visual problems aside the slightly off colours are the same as the real hardware.
Need to look into adding sound next.
Thx for your great work so far! it’s amazing to see the Space Invaders running in MAME.
I hope we get more games from RADICA soon!
Very interesting Haze Thanks for the write up.
What do I look for on YouTube to find your channel as it’s nice to read bit watching what you do would be fantastic
as I like watching how things in the emulation world get solved. You live in UK anywhere near M1 junction 30 & fancy letting me spend the day with you as an apprentice? lol….. Thanks again for all your work
I read your comment about the snes mini and awful hardware and awful older version of mame.
Yes mame in 2003 was not as good as now, but it run games already good, not with arcade preservation perfection, but it did it and also that was made the project move forward so long.
I think is fair and is ok to dig in older mame versions, at expense of accuracy and quality, to have some fun on older hardware.
There are faster emulator out there that concentrate on a single platform and do a better job than an older mame, but is also true that there is not always the emulator you are searching for and mame has a wide range of options.
For my YouTube channel just click through on any of the videos I post of emulation work in progress like the one in the article.
Have you got any videos showing the actual things that you do in getting things working from start to finish ?
As it would be nice to show us & talk us through what your doing & obviously you can’t do it all the time but as you have been doing pgm2 I would like that, including what stuff you did try but was wrong & then stuff that gave you the breakthroughs in getting it to work up to now.
THANK YOU.
The videos I already made of the progress on these show more steps than the PGM2 stuff ever did.
I can’t show everything I tried because that would be hundreds of videos and paragraphs of text that I simply don’t have time to write.
Just found out about your Youtube channel. Thanks a lot for the write ups on this blog. It’s really cool to read through this.
Quick question, most games in mame have around 4 ~ 6 frames of input lag which are not present in the real arcade.
I’ve heard bgfx’s non-exclusive mode implementation adds about 1 on Windows.
I know you guys are aiming for the perfect emulation when possible. Is this input lag on a list of being fixed soon, or would this be an issue until maybe it’s fixed at a distant future?
It’s OK i’ll watch all those that i haven’t seen. Maybe in the future you can have a cam pointed at the screen where people can watch on youtube live or facebook live as your trying to get stuff to work, it can show people how many hours you all put in for the greater cause of preservation. It might attract a good few viewers, you never know & maybe if it does get a good few watching some of the others can do the same to show what they contribute to the preservation cause. Thanks Haze
> Quick question, most games in mame have around 4 ~ 6 frames of input lag which are not present in the real arcade.
If you’re getting 4-6 frames of extra input lag you’re doing something *very* wrong, MAME out the box definitely doesn’t add that much, in fact most people have found it to be one of the lowest latency emulators, moreso if you use something like GroovyMame and the low latency audio drivers too.
BGFX might add an extra frame, but it isn’t default, and that is out of MAME’s hands.
Best case with emulation is ‘1 frame’ of extra lag from the emulator, because the game renders a frame in realtime, then the emulator presents it at the first opportunity it has. If you’re running at double the usual refresh rate you might cut that down to half a real frame as the next frame is presented more quickly.
On real hardware, obviously depending on the design of the hardware, it’s theoretically possible that you would see a change on the screen immediately after you press a button, because for the older systems the buttons are directly wired to bits on ports, which could be read, and change the position of something a scanline ahead of where the CRT scan is, before it gets there.
Modern PC hardware doesn’t really work like that at all, nor do modern displays, you render to a buffer and that buffer is then presented (after any post-processing effects are applied) so usually you’re going to get an extra frame or so there, some displays are better than others, some video cards / drivers are better than others, some cards have better drivers on one OS than another. I always found that any OGL / SDL solutions on either Linux or Windows were worse than the D3D mode with my hardware for example.
Some input devices will also add lag, wireless ones I’ve found to be worse than wired, but again you’re often at the mercy of the drivers for said devices and even the hardware inside the devices that might, for example, be sampling button inputs over multiple frames to ensure the input is stable (especially with Analog style inputs) I’ve noticed a lot of adapters for console controllers and the like have this problem, as do some of the modern reproductions of older pads.
Again all that is out of MAME’s hands tho, best you can do is run a gsync / freesync setup I believe. Using options in MAME like Vsync and Triplebuffer will add frames of lag because you’re *telling* MAME to add frames of lag with them (the irony is 15 years ago everybody demanded these options and wanted them as the default)
but no, if somebody is going around telling you that MAME is adding 4-6 frames they’re talking nonsense or they’ve intentionally configured it in a way that does. It’s more likely they’re just using hardware that adds said lag, nothing to do with MAME.
I notice people have been going around spamming that RA can do ‘0 frames of lag’ now, but in reality it’s doing nothing a properly configured MAME / GroovyMAME have done for years. If anything I found RA to be noticeably more laggy out of the box than MAME, with worse sound delay too, with the problem on some low-powered & mobile devices to be so bad it was very off-putting.
Byuu did a good write-up on this
https://byuu.org/articles/latency/
and MAME should be following the best principles without potentially causing compatibility issues.
It’s interesting how this has become a major issue for people all of a sudden tho, because it’s one area in which manufacturers stopped caring fairly on. Even in the 80s / 90s Namco had started using MCU chains that passed inputs from one place to another, adding frames of lag to their games etc, and as I mentioned, 15 years ago people were asking for features in MAME that explicitly added lag, not only vsync / triple buffer, but ‘steady key’ and the like too. The newer JVS standard for arcades also apparently adds extra lag by having additional MCUs passing the inputs around, acting as an ‘intelligent’ layer between the game and the controller. It’s funny how times change really.
Also re: videos of me doing MAME work, that wouldn’t work.
I’m rarely *only* doing MAME development work, so I’ll write a bit of code, do something else while I consider what worked / didn’t work, test another bit of code, do something else entirely etc. If I just sit there trying to force a solution to the problem I get nowhere, need time to actually just think things over.
Also I don’t think anybody needs videos of me singing along badly to my favourite songs, which is what I’m doing half the time when developing anyway :p
@Andrea Bogazzi: It’s personally embarrassing to the devs because we know all the things that were wrong in 2003 (the gameplay speed in Donkey Kong, to name one classic). And there’s a wide range of mini-ITX and small-form-factor PCs these days, which can also run Plex videos and PC/Steam games in addition to keeping you current on MAME.
Yeah, it’s a bit like the guy on Reddit doing a review of Outfoxies, but doing it on a SNES Mini using MAME2003 where sound wasn’t even emulated.
It’s a 15 year old version of MAME, there’s very little value to somebody trying to upload a journalistic review of a game using a MAME build that old. It makes the game look bad, it makes MAME look bad, it makes the SNES mini look bad, and it makes the reviewer look unprofessional at best.
We fixed sound, or at least had somewhat working sound in the game around 2005, which is 13 years ago anyway so maybe you can understand the frustration when people start saying such devices are good for MAME and people start porting MAME to it similarly weak platforms. It’s another case where Retroarch / Libretro has done considerable damage by making it such options seem like they might in some way be good ones. Mame4all etc. were starting to die out before they resurrected them all and started another wave of people running terrible old MAME versions on terrible hardware as if it were a good thing. It would have been far better if use of those old versions had simply died out and people realized they needed better hardware for MAME.
To add to the discussion, while I agree that MAME has a pretty good accurate emulation it does have 4-6 frames input latency. You can hop on any twitch arcade shmup streamers and ask around and they’ll all agree with this. It’s a widely known fact. That’s why some prefer re-releases of these games on modern consoles as they provide better response time. I don’t think OP is doing anything wrong. I use 8700k + gsync monitor with all bgfx, vysnc and buffer options off on default settings and I do get about 5-frame (for example in Battle Garregga) input lag. Feel free to test it yourself.
BTW, MAME doesn’t add all of that 6 frame latency. bgfx adds 1-2 frames. bgfx’s fullscreen implementation has been half-assed on Windows because the developer has/had a dated information on DX and openGL differences on resource rebuilding. It has been suggested to use the exclusive mode before, but they have been ignoring it for nearly 2 years so 2 out of that 6-frame input latency is a lost cause. MAME dev even opened an issue about it once and it got zero response like 3 years ago. However, the rest 4-frame latency is definitely coming from MAME. You can test this by using a keyboard rawinput, and setting any on-screen display software to respond keypresses while running MAME. When the OSD responds to a key press, MAME would respond it after 4 frames.
Battle Garregga is a poor example, because the actual GAME contains a lot of frames of input lag. MAME isn’t creating 4-6 frames of input latency. MAME can’t do anything about that input latency.
Please stop confusing the two or using poor examples to mislead people.
You got atrocious hacks like shmupmame that hacked the Battle Garegga game code to remove the built in lag at the expense of completely breaking the graphic sync. This *proved* that the game itself was the source of most of the frames of lag, not the emulator.
As long as you avoid BGFX, and don’t turn on silly options like Triple Buffer or Vsync then MAME is giving you as good as you can get, and as I said, BGFX isn’t even the default.
MAME, in it’s default configuration, has 1 frame of lag, that can’t be avoided. Lag in the original games, and any of your other components will add to that, but that is not MAME adding it. There is no magic “ADD LAG HERE TO PISS OFF PLAYERS” code anywhere in MAME.
Of course if you’ve got a port where the actual GAME code has been changed they can take out some of the lag that was originally programmed into the game, but that’s again something entirely different.
The subject has been researched extensively.
btw, some game designers intentionally added input delay to make the games harder, or to give the AI an advantage in knowing where you’ll be before you’re displayed in that position, cheap trick, but yes, it happened.
yeah no way MAME adds that much lag.
isn’t bgfx recommended by the devs though? arbee once told me to use bgfx from now on since mamedev wants to move to that eventually for 3d games
It was intended to become the new default with D3D going away, but issues like the one mentioned are the reason D3D is still there and the default. It might also be one of the reasons the devs haven’t dived headfirst into adding 3D rendering using BGFX just yet; if those issues never go away something else might need to be considered.
Is there a tutorial on how to configure Mame on how to get it running as smooth as possible for different specs of pc? I have a i5 with 6gb of ram & I find it sometimes is a bit jerky or the sound sort of skips,
My settings.
throttle video mode auto use bilinear filtering triple buffering refresh speed frame skipping auto emulation speed 1.0 sound auto sample rate 44100
audio latency 2/5 use external samples
i see
yeah bgfx development is slow
is using hlsl ok on d3d? or does it add additional lag?
I don’t think HLSL adds any lag, although it is a risk with any kind of post processing as it is an additional pass on the image before it gets presented.
agard, if you want MAME to be 100% smooth you’re going to have to get a gsync / freesync setup, and make sure there’s nothing in the background interfering with it (software that causes lots of IO operations or CPU spikes like torrent software is especially bad to have running at the same time)
without a proper gsync / freesync setup yes, you’re relying on things like triple buffer to get rid of tearing (but add lag) refresh speed (which afaik forces the video to run at the wrong speed at the expense of sound skipping every now and again) or emulation speed (which adjusts the speed of the whole thing, changing sound pitch) the problem is your monitor can only display 60hz, the majority of old software does not run at 60hz, even NTSC stuff isn’t exactly 60hz.
keep in mind that in some cases the actual games are a bit jerky anyway, so again MAME isn’t going to fix that.
I completely agree people should not take in consideration snes mini and mame2003 core, nor libretro to talk about mame.
But i can testify that having a snes mini with the cores it can run ( mame2003 and mame2010 i believe ) is a lot of fun.
Even on a 2010 build there are so many flaws we’ve fixed since then that personally I can’t find it to be a ‘lot of fun’ at all. All I can think of is when the next game breaking bug or annoying glitch that we fixed 8 years ago is going to rear it’s head.
I’m not saying newer versions are perfect, or don’t have bugs of their own, but overall it’s been 99% improvements and bugs fixed, maybe 1% bugs introduced.
It’s not just the newer games either, the classics have received a lot of fixes in that time, especially protected ones where protection sims have been improved or replaced by real emulation of the MCUs. 2017 was a huge year for Taito improvements in that area for example.
There are even classics we know are still wrong today and are waiting on somebody to decap them etc. to improve matters, so it’s not like MAME is ‘done’ now either, anybody with an interest in Kangeroo is surely still keeping an eye out for any note of decapping and emulating the protection devices on there because the game simply doesn’t play correctly at the moment meaning any scores are completely incomparable to real hardware ones. Tracking MAME progress is actually rather important.
yeah, but latest mame can’t run on a crappy arm. and if all you have connected to a tv with an arcade stick is a crappy arm cpu, a glitchy mame is still a gift compared to no mame.
I follow mame progress since 0.36 i believe
I was a cp2shock website reader because i find all the processes for dumping/debugging/understanding awesome and interesting.
A side question, unreleated, what is keeping speed racer on mame to run good? emulation problem, protections or good dumps?
Honestly I’d rather people weren’t running MAME at all than running some crappy version for the sake of running it on crappy hardware, because it just encourages nobody to actually do it correctly. If people hadn’t got the choice to run it on a crappy ARM maybe they might invest in something better, which is what we were starting to see until somebody made it easy to run it on these crappy devices, a real shame.
Speed Racer, I think simply nobody cares, or it’s some combination of CPU bugs (it’s an obscure CPU) and Namco weirdness because from what I can see the correct data doesn’t even get put into the tilemap ram.
And ironically, latency-wise what you want is the most powerful pc you can afford, so you can use features like frame delay also with the most demanding systems.
We have tested this stuff extensively and the only source of latency that really matters at a macroscopic level is the frame queue that video drivers surreptitiously create when any sort of vsync is enabled. All other suggested sources have negligible effects.
If people who have “updated information” can create a patch for BGFX that eliminates the latency, we’ll accept it, and I imagine upstream will take it as well. It’s important to note that upstream uses BGFX primarily for PC games, where fewer people pay attention to latency, and so they’re less likely to fix things especially for us.
Thanks for info on what options not to use.