Arcade hardware question

[Hoopz]

This is NOT a knock on Mamedev or anything like that.  I simply don't know much about how the hardware was setup in some newer arcade games so I wanted to ask.

What was different in the hardware for games that can't run at full speed in Mame now (Gauntlet Legends, Blitz etc) compared to the hardware that was available in pc's at the time or even pc's now?

I don't know enough about how these games were made to understand it will take a 10 Ghz cpu to run some of them (Mame .120 changes notwithstanding).  If someone could explain the difference between how the hard drives connected, what kind of cpu's were used, or _____ (whatever made the big difference), I would appreciate it.

Again, I am not bitching or complaining that something isn't running at 100% speed in Mame.  I just don't know enough about it to understand the gap between what they did then compared to now. 

Thanks.

[u_rebelscum]

Ever noticed slowdown playing an old 16 bit DOS game on a modern 32/64 bit CPU in winXP?  That's only emulating the software (dos).  Ever ran windows on an intel mac?  That's virtualization (windows has access to the real hardware) not emulation like mame.

You are not playing ports of the games, nor is mame virtualizing the hardware.  Mame is emulating the original hardware that is running the arcade game.  This has more steps than the PC running the PC game, so you can't compare mame to a PC game + PC hardware.  MameDev FAQ if you haven't read it yet.

arcade game --> arcade hardware -->  mame --> PC hardware
PC game       ------------------------------------>  PC hardware

Notice how the PC game directly goes to the PC hardware.  Think each step as a 30 to 150 pound weight on your back.

Another way to look at it, a very general rule is: it takes 10 to 100 times the speed of the original hardware to emulate said hardware on a modern PC.  This is so wide, as emulating an 8-bit CPU is generally easier (read: faster) that emulating a 32-bit CPU, and analog & DSPs are harder (read slower) to emulate than fixed CPU.  And since all the hardware is being emulated on the PC's CPU, the sound, video, O/I, and all other chips also are counted in addition to the arcade CPU.

If you want info on the hardware, look at mame's source (the best place, but not easy to read ), or www.system16.com (some boards more documented than others).  Call GL as total of 250 "Mhz" (200 + 16 + 16 + ), times a IMO low factor of 40x, and you get 10 Ghz.

[MonMotha]

The big culprit in the case of Blitz/Gauntlet Legends is the video hardware.  Most of the old games that you can emulate in real time use simple sprite/tile based video architectures.  This is pretty straightforward to implement on a general purpose CPU and modern PCs are so fast that they can keep up.

Blitz/Gauntlet Legends (the hardware is very similar) use a 3dfx Voodoo (yes, the same thing you could have bought in ~1996 for your PC).  3d hardware is a different beast altogether, and there's a reason modern PCs now include 3d accelleration capabilities.  In a nutshell, for every clock, a 3d device can complete several more operations, within the narrow set of operations it is designed to perform, than your CPU can.  Your CPU can perform about 2-4 operations per clock, but a graphics processor can perform on the order of 8-256, depending on the device.  Emulating this on a CPU is entirely possible, but even if you completely discount any "translation" that has to be performed, it'll run 2-128 times slower than a GPU clocked at the same speed.  GPU operations are also specifically tailored to graphics usage and are in most cases SIMD type operations (they operate in a single instruction on more than one set of completely independent data).

The graphics device in Blitz is clocked at (IIRC) 200MHz and for some reason I'm thinking the Voodoo pipeline is 8 wide (i.e. it can complete 8 ops every clock), so you'd need a "1.6GHz" CPU (or so, using very rough examples here) just to complete operations as fast as the Voodoo on Blitz does, plus you need to translate Voodoo instructions (which are very graphics specific) into CPU instructions (which are not), and this inevitibly requires more than one CPU instruction for every GPU instruction.  THEN, you also need to emulate the CPU (again, often more than one CPU instruction for every GPU instruction, though the MIPS arch used by Blitz and Gauntlet Legends is pretty straightforward), AND you need to emulate the sound DSP (which again can complete about 4-8 instructions per clock, usually), AND you need to handle mapping the controls (which are very easy to talk to on the arcade hardware) to PC controls (which aren't nearly as easy to talk to, in comparison).  PLUS you have a behemoth of an OS running in the background, while the arcade hardware does not.

Now, all this is exacerbated by the fact that MAME is not multi-threaded!  Modern CPUs are getting faster because they are more than one CPU in a package.  MAME is emulating 2-4 pieces of discrete hardware (or more, in some cases) that all ran on their own clocks, completing instructions all in parallel, but MAME only uses one of your processors (if you have more than one), so your ONE processor has to do the job of ALL the hardware that was on the original board, and your ONE processor isn't even particularly good at most of it.

I guess I do feel it necessary to point out that comparing wildly different architectures using clockspeed as the chief measure of comparison is a horrible thing to do, but with appropriate context it can at least give you an idea of what's going on.  Take all numbers with an ocean's worth of salt, but the general principle is what matters.

[Hoopz]

Thanks guys for the answers.

Robin, I was hoping you would answer as I have always found you to be very helpful and probably the best person on the boards explaining different concepts re: the Mame code, inputs etc.  While I appreciate the offer to look at the source code, my last programming class was in 1986 and I'm not really able to understand any programming now.  I had read the MameDev FAQ but it had been awhile ago.  I looked through it again tonight.

I would say ultimately that my lack of understanding is because I don't have any recent programming experience.  While I can understand the analogies, I don't have the frame of reference to understand more than a basic concept.  Now you see why my last programming class was in the 80's.     You people that can do all that stuff and make it look so easy really have talent.      Thanks Robin, I appreciate your time with the answer. It does help.

MonMotha, thanks for the help too.  I actually understand more about modern cpu's, video cards etc.  The Voodoo information sounds familiar and I remember choosing the Riva TNT over a Voodoo card in 1997 or so.  I probably shouldn't have used Gauntlet Legends as an example because I did know that one was more advanced graphically and used a "real" video card.  Since Mame has the cpu handle all those processes instead of having the gpu do it, I understand why that aspect is slower.

The example of playing the 16bit game in XP helps too. 

Thanks guys.

[Avrus]

Now, all this is exacerbated by the fact that MAME is not multi-threaded!  Modern CPUs are getting faster because they are more than one CPU in a package.  MAME is emulating 2-4 pieces of discrete hardware (or more, in some cases) that all ran on their own clocks, completing instructions all in parallel, but MAME only uses one of your processors (if you have more than one), so your ONE processor has to do the job of ALL the hardware that was on the original board, and your ONE processor isn't even particularly good at most of it.

As of 119u3 I believe they're working on that.

Changed implementation of OSD work queues that are created with the
WORK_QUEUE_FLAG_MULTI hint. Such queues now create n-1 threads, where
n in the number of logical processors in the system. This allows the
main thread to continue accomplishing things while other threads
process the work. If the main thread subsequently calls
osd_work_queue_wait(), it will then dynamically "jump in" and help
the other threads complete all the work items. [Aaron Giles]

Added support for controlling multithreading behavior through an
environment variable OSDPROCESSORS. To override the default behavior,
set OSDPROCESSORS equal to the number of logical processors you wish
the OSD layer to pretend you have. [Aaron Giles]

Changed the 3dfx Voodoo emulation code to take advantage of the new
threading mechanisms above. It now creates a work queue with the
WORK_QUEUE_FLAG_MULTI flag set, and uses shared work items to spread
rasterization work across multiple processors. Note that this support
should be considered experimental; under some circumstances it is
known to deadlock. If you encounter problems, set OSDPROCESSORS to 1
to effectively produce the previous behavior. [Aaron Giles]

[Spaz Monkey]

From my understanding, you have a specific piece of hardware doing a specific job.  Would you use a house hold vacuum to rake up leaves?  Yes you could, but using a shop vac as a blower might be better.  Same thing but with a computer (Word, Excel, Powerpoint) vs dedicated game board.  In addition, you have everything standardized (sp?).  I can't take my video card and go to your house and you'll have the same hardware.  I also remember something about a RISC processor vs some other type of processor on the video games vs computer.

[u_rebelscum]

Just minor points, otherwise good inof MonMotha

The big culprit in the case of Blitz/Gauntlet Legends is the video hardware....

I'd say "A big culprit".  Mame is able to emulate this chip surprisingly well (especially with all the stuff you posted), and disabling the emulation of the video in this game only gives you IIRC ~10-20% speed increase.  IOW, emulating the video chip is accounting for only 10 to 20% of the work emulating. 

And even without the video, no PC is fast enough to emulate the rest of the hardware in mame ATM.

...The graphics device in Blitz is clocked at (IIRC) 200MHz

That's the main CPU.  The video CPU is running at 90 MHz, from comments in scr/mame/video/voodoo.c.  (I was wrong too and assumed 16 MHz.)


So to update my estimate: 200 (CPU) + 16 (DSP) + 90 (voodoo) + 18 (same guess at everything else) = 324 "MHz".  With an even more generous factor (then my prior post) of 31x, you get about 10 GHz.

Thanks guys for the answers.

Welcome. 

...While I appreciate the offer to look at the source code, my last programming class was in 1986 and I'm not really able to understand any programming now....  While I can understand the analogies, I don't have the frame of reference to understand more than a basic concept....

You don't have to understand everything to get the the general idea.  I don't know much more than the generalities of emulating, and some more on inputs.

Try looking at an easy CPU like the z80 and reading the comments, and check how many lines of C code it takes to emulate one assembly command.  Say, line 700 in scr/emu/cpu/z80/z80.c file for a jump conditional: five lines in C to execute one in z80's assembly.

[Hoopz]

Try looking at an easy CPU like the z80 and reading the comments, and check how many lines of C code it takes to emulate one assembly command.  Say, line 700 in scr/emu/cpu/z80/z80.c file for a jump conditional: five lines in C to execute one in z80's assembly.

Ah, that helps.  Any if an easy CPU takes 5 lines, a more advanced one will take X. 

Gotcha!   

[ark_ader]

I think the main issue is optimization of the main core.  Cure that and there will be no more excuses.  If the MAME Devs fixed half of the mess in the main build like getting the duff code out and improving frame rates, and concentrate less on incorporating new games, which demand more from our hardware, we would see some progress.

But with so many contributors to the project, the above suggestion would be difficult to accomplish without a stop work order.  I don't think the hardware has anything to do with it today.  You could come up with that argument 5 years ago, but with better coding skills and a better understanding on how the target platform works and whats out there, would see a major improvement.

Like the previous poster said about it being years since he coded, I too am in that bracket, but even C was harder to implement than Assembler back in the day.  With all the libraries and toolkits available the mere suggestion of coding woes is just an excuse. 

I like the comment about non standarisation of hardware, but vanilla Windows can operate in plain old VGA in just about any graphics card out there. 

More excuses.

I'm just glad Aaron Giles is leading the project, and he is doing a great job.   

[u_rebelscum]

Ark_ader, please learn more about emulation before bashing those who do it.

[Hoopz]

My question was definitely not intended to bash anyone, let alone Mamedev.  Just asking for some help understanding.  I have the utmost respect for those who do this in their spare time for everyone's benefit.

[ark_ader]

Apparently making accurate suggestions which have already been echo'ed equals bashing now. 

I'll keep on bashing thank you until someone wakes up.

[u_rebelscum]

I don't know if you're trolling or not, but assuming you're not...

I think the main issue is optimization of the main core....

This paragraph is so full of wrong connotations and other non-facts that I can't address them all.  I'll point out just this.

There is little optimization that can be done in the core except what's Aaron is already working on (multithreading).  That is if mame sticks to it's goals: document the original hardware, document as many games as possible, document as close to the the original as possible, be portable, be open to outside contribution, and be actively developed in the future.  In the long term, the last three help optimisation (example: the switch from 16 bit to 32 bit to, currently, 64 bit would not be possible without major headaches). 

More effective (but less global) optimization can be done (and is being done) in the CPU, sound, etc drivers.

But with so many contributors to the project, the above suggestion would be difficult to accomplish without a stop work order.

Agree.  Each person contributing to mame picks what they want to work on, which is usually what games they like and know most about, and what programing areas they're best at.  They all do it for the fun of it.  So you'll get zero progress anywhere in mame if you tried to force everyone to optimise code, as optimising code isn't on most contributors list of things to do for fun.

I don't think the hardware has anything to do with it today.  You could come up with that argument 5 years ago, but with better coding skills and a better understanding on how the target platform works and whats out there, would see a major improvement.

The computation power of the original hardware has a lot to do with it.  Not all, but a lot.  Mame not liking speed hacks also has a lot to do with it, too. 

Like the previous poster said about it being years since he coded, I too am in that bracket, but even C was harder to implement than Assembler back in the day.  With all the libraries and toolkits available the mere suggestion of coding woes is just an excuse. 

You're confusing porting a game with emulation.  Mame does not re-write the original code; that's why you need the original ROMs.  So this whole paragraph is irrelevant and shows you didn't understand what I meant in my example.

I'll repeat it.  Mame emulates the original CPU.  The original ROM has a command (conditional jump in my example).  The original game has no idea it's running inside mame, so it "sends" the command to the "CPU".  Mame does what ever the original CPU would do with that command.  And to fake it, it takes (in this example) 5 lines of C code, which means more than 5 lines in assembly/machine/binary.

I like the comment about non standarisation of hardware, but vanilla Windows can operate in plain old VGA in just about any graphics card out there.

You're missing the point again.  Do you have the same computer as he?  No.  Windows running or not doesn't matter.  That's not what mame does.

I'm just glad Aaron Giles is leading the project, and he is doing a great job.   

Agreed.