d8888 888 d88888 888 d88P888 888 d88P 888 888d888 .d8888b 8888b. .d88888 .d88b. d88P 888 888P" d88P" "88b d88" 888 d8P Y8b d88P 888 888 888 .d888888 888 888 88888888 d8888888888 888 Y88b. 888 888 Y88b 888 Y8b. d88P 888 888 "Y8888P "Y888888 "Y88888 "Y8888 8888888888 888 888 d8b 888 888 888 Y8P 888 888 888 8888888 88888b.d88b. 888 888 888 8888b. 888888 888 .d88b. 88888b. 888 888 "888 "88b 888 888 888 "88b 888 888 d88""88b 888 "88b 888 888 888 888 888 888 888 .d888888 888 888 888 888 888 888 888 888 888 888 Y88b 888 888 888 888 Y88b. 888 Y88..88P 888 888 8888888888 888 888 888 "Y88888 888 "Y888888 "Y888 888 "Y88P" 888 888 888 888 88888888888 888 888 888 888 888 888 8888888888 .d88b. 888 888 888 888 .d88b. 888 888 d88""88b 888 888 888 888 d88""88b 888 888 888 888 888 888 888 888888 888 888 888 888 888 Y88..88P Y88b 888 d88P 888 Y88..88P 888 888 "Y88P" "Y8888888P" 888 "Y88P" Version 0.25 Compiled by Michael Adcock email: adcock@menudo.uh.edu January 7, 1997 -------------------------------------------------------------------- Yb dP 8 w w dP"Yb Yb db dP 8d8b. .d88 w8ww ." d88b 8d8b. .d88b Yb db dP " d8 YbdPYbdP 8P Y8 8 8 8 `Yb. 8P Y8 8.dP' YbdPYbdP dP YP YP 8 8 `Y88 Y8P Y88P 8 8 `Y88P YP YP w -------------------------------------------------------------------- - Updated Q.2 - Added M.1, M.1.1, M.1.2, M.1.3, M.1.4 (Crazy Climber) - Updated M.5, M.5.2 and added M.5.8, M.5.11 (Sega System 16) - Added B.2, B.3.1, B.6, B.8, B.9, B.12, B.14 (Lot's of bits and things) - Added S.2, S.2.1, S.2.2, S.2.3, S.2.4 (Space Invaders step-by-step) - Updated R.1 (Emulator updates!) - Updated R.5 (Game listing updates!) -------------------------------------- 888b. 8 .8 8 8 8d8b 88b. .d8b. d88b .d88b 8wwP' 8b d8 8P 8 8 8' .8 `Yb. 8.dP' 8 `Y8P8 8 88P' `Y8P' Y88P `Y88P 8 -------------------------------------- This document is designed to aid anyone considering whether to write an emulator for an arcade game machine. It will attempt to answer frequently asked questions, give a step by step tutorial, and provide the resources necessary for a capable programmer to begin work on an emulator for an arcade game. Please note that although some of the information provided is generic enough to apply to emulation of any system, the primary focus of this document, and the resources provided, is arcade game emulation. This document contains no information about the commercial emulation packages that are available. If you have any information that should be added to this document, then please email adcock@menudo.uh.edu or moose@rocknet.net.au ! Table of Contents: Q and A ------- Q.0 Trying to write an arcade emulator is crazy, isn't it? Q.1 Which game would you recommend starting on? Q.1.1 Which games are 'easiest' to emulate? Q.1.2 Which games have the most available documentation? * Q.2 How do I START? Q.3 What language should I use? Q.3.1 Do I *have* to use Assembly? Q.3.1.1 Are you SURE about this Assembly business? :) Q.3.1.2 Doesn't the choice of language depend on the target game/system? Q.3.1.3 What about portability? Q.3.2 But haven't some arcade emulators been written in C/C++? Q.3.3 What about Java? Q.4 Could you explain CPU emulation? Q.4.1 CPU emulation sounds VERY complicated, how should I START? Q.4.1.1 Is the 68k series of processors 'easy' to emulate on PCs? Q.4.1.2 Why were only a handful of processors used in arcade games? Q.4.2 Should I use CPU emulation code that is freely available? Q.4.3 How do the CPU and ROMs interact? Q.4.4 How should I handle CPU opcodes? Q.4.5 What is Pokey? Q.4.6 What is Slapstic? Q.4.7 What about translation? Q.4.8 Is there anything else I should know about CPU emulation? Q.5 How useful are the switch settings and pinouts? Q.6 How do I produce a memory map? Q.7 How can I find what processor(s) the game uses? Q.7.1 Where can I find information for a specific processor? Q.8 Where might I find the ROMs? Q.8.1 How do I disassemble the ROMs? Q.8.2 How do I decode data from the ROMs? Q.9 Should the sound be emulated or should samples be used? Q.9.1 What about legal issues? Are samples copyrighted? Q.9.2 What is the difference between a speech synthesizer and a sample playback device? Q.9.3 What was used in Williams Arcade Classics? (It sounds good!) Q.9.4 Why is sound so *hard* to emulate? Q.10 Where can I find other documentation for the game? Q.10.1 What about schematics for the game? Q.11 How might I contact someone who owns the machine hardware? Q.11.1 Todd Krueger's offer to help Q.12 Where can I find general descriptions of arcade games? Q.13 Did other emulator authors keep any notes while they were working? Q.14 Where can I find more information on the internet and WWW? Q.15 Should I release my source code when I'm finished? Memory Maps ----------- * M.1 Crazy Climber * M.1.1 Video * M.1.2 Sound * M.1.3 Other Details * M.1.4 Memory Map M.2 Dig Dug M.2.1 Memory Map M.3 Ms. PacMan / PacMan M.3.1 ROM Files M.3.2 Memory Layout M.3.3 Memory Mapped Ports M.3.4 OUT ports M.3.5 Character Sets M.3.5.1 Pascal Source (ZIPed an UUencoded) M.3.6 Ms. PacMan ROMs are identical to PacMan? M.4 Phoenix M.4.1 Components M.4.2 Functionality M.4.3 Colors M.4.4 Memory Map * M.5 Sega System 16 Games M.5.1 Hardware Information * M.5.2 Memory Map M.5.3 Scroll Video RAM M.5.4 Fixed Video RAM M.5.5 Color Video RAM M.5.6 Main RAM M.5.7 Video Registers * M.5.8 I/O Registers M.5.9 ROM Files M.5.10 Graphics Formats * M.5.11 Sega GFX Viewer V1.0 Source Code (ZIPed an UUencoded) M.6 Sega Vector (Converta) Games M.6.1 Components M.6.2 Memory Map M.6.3 I/O Inputs M.6.4 I/O Outputs M.6.5 Vector Processor M.7 Space Invaders M.7.1 Board Spec M.7.2 Memory Map Graphics Hacking ---------------- G.1 Who wrote this section? G.2 Introduction G.3 Location of Graphics in Specific Game ROMs G.4 General Information G.4.1 Pixel Layout G.5 Notes and Requests G.6 Mode Q (256x256x256) Source Code (ZIPed an UUencoded) Pokey ----- P.1 Who wrote this description? P.2 You mean Pokey isn't just that guy that hangs around with Gumby? P.3 Where did they come up with a name like Pokey? P.4 General Description P.5 Technical Description P.5.1 Pin-outs P.5.2 Address Lines P.6 Where can I find source code and more info. for Pokey emulation? P.7 Finding and using *real* Pokeys AY-3-8910 --------- A.1 Who wrote this description? A.2 Introduction and Disclaimer From Original Document A.3 Technical Information Game Bits --------- B.1 What is this section about anyway? * B.2 Commando [provided by edoardo (gambare@iol.it)] B.3 Crazy Climber [provided by Vince Mayo (14u2c@diamond.nb.net)] * B.3.1 Decrypting the ROMs by Lionel Theunissen (lionelth@ozemail.com.au) B.4 Crush Roller [provided by Vince Mayo (14u2c@diamond.nb.net)] B.5 Gyruss [provided by Mike Cuddy ] * B.6 I, Robot [provided by John Manfreda (jmanfred@fh.us.bosch.com)] B.7 Juno First [provided by Mike Perry (mj-perry@uiuc.edu)] * B.8 Penia [provided by Perry McFarlane (ce596@torfree.net)] * B.9 Space Invaders [provided by John Manfreda (jmanfred@fh.us.bosch.com)] B.10 Star Wars [provided by Peter McDermott] B.11 Tapper [provided by Clay Cowgill (clay@supra.com)] * B.12 Toki [provided by David Winter (winter@worldnet.net)] B.13 Turbo [provided by Patrick J. O'Reilly (oreillyp@execpc.com)] * B.14 Tutankham [provided by Moose O' Malley (moose@rocknet.net.au)] Step-by-Step ------------ S.1 Step-by-step implementation of an emulator for Phoenix S.1.1 Part I: Pre-coding S.1.2 Part II: Low/High Endian S.1.3 Part III: Let's start coding! S.1.4 Part IV: Run it! S.1.5 Part V: To be continued... * S.2 Step-by-step discussion of an emulator for Space Invaders * S.2.1 My Background * S.2.2 Getting started * S.2.3 Disassemblers * S.2.4 Space Invaders Specifics References ---------- * R.1 List of Emulator Authors R.2 List of Currently Emulated Games R.3 List of Games People Want to See Emulated R.4 Internet Resources R.4.1 WWW Resources R.4.1.1 General Arcade Emulation Links R.4.1.2 ROM Images R.4.1.3 Processor Information R.4.1.4 Schematics R.4.1.5 Miscellaneous Information R.4.2 FTP Resources R.4.3 FSP Resources R.5 List of Arcade Games ----------------------------------------------------- 88888 8 8 88888 8 8d8b. .d88 8d8b. 8.dP d88b 8 .d8b. 8 8P Y8 8 8 8P Y8 88b `Yb. 8 8' .8 8 8 8 `Y88 8 8 8 Yb Y88P 8 `Y8P' o o o ----------------------------------------------------- - Suzanne Archibald (suzanne@crysalis.com) - Neil Bradley (neil@synthcom.com) - Don Carmical (dcarmical@tri-lakes.net) - Clay Cowgill (clay@supra.com) - Mike Cuddy (mcuddy@scitexdv.com) - Jim Dankiewicz (james.dankiewicz@resnet.ucsb.edu) - Laurent Desnogues (desnogue@aiguemarine.unice.fr) - Bryan Edewaard - Chris Hardy (chrish@kcbbs.gen.nz) - Ed Henciak (ethst3@pitt.edu) - Joe Husosky (scubajoe@ix.netcom.com) - Paul Kahler (phkahler@oakland.edu) - Ralph Kimmlingen (ub2f@rz.uni-karlsruhe.de) - Thierry Lescot (ShinobiZ@mygale.org) - Moose O' Malley (moose@rocknet.net.au) - Alan J McCormick (gonzothegreat@juno.com) - Ivan Mackintosh (ivan@rcp.co.uk) - Vince Mayo (14u2c@diamond.nb.net) - Phil Morris (pmorrisb@cix.compulink.co.uk) - Brian Peek (peekb@union.edu) - Mike Perry (mj-perry@uiuc.edu) - RisqMan (RisqMan@aol.com) - Pete Rittwage (bushwick@ix.netcom.com) - Adam Roach (adam.roach@exu.ericsson.se) - Joel Rosenzweig (joelr@an.hp.com) - Trevor Song (Sharrier@hotmail.com) - Gary Shepherdson (od67@dial.pipex.com) - Dave Spicer (emuchat@hubcap.demon.co.uk) - Brad Thomas (bradt@nol.net) - Allard van der Bas (avdbas@wi.leidenuniv.nl) - Nemoto Yohei (BYY03025@niftyserve.or.jp) - All the emulator authors out there... (And all the potential ones too!) - Ian Chai, Glen Chappell, and everyone else responsible for Figlet v2.1.1 (It generated the ASCII fonts you'll see in here!) - Everyone responsible for the creation and maintenance of Linux, X, and DOSemu. Believe it or not, but I've actually written *most* of this document using DOS's edit in a DOSemu window under Linux X!! ------------------------------------------------------------- 8 8 8 Yb dP w 8 8www8 .d88b 8 88b. Yb db dP .d88 8d8b. w8ww .d88b .d88 8 8 8.dP' 8 8 8 YbdPYbdP 8 8 8P Y8 8 8.dP' 8 8 8 8 `Y88P 8 88P' YP YP `Y88 8 8 Y8P `Y88P `Y88 8 ------------------------------------------------------------- Phil Morris brought an issue to my attention, and I decided to add this section. There are many arcade emulation projects in progress now. As far as I know, no emulator author is doing this full-time. In other words, it's a hobby, done in their spare time (They have *real* lives!). However, it seems that some emulation projects may have become 'stalled'. For some, new versions have not been released for a month or so. This is a plea to emulator authors whose projects may be stalled: Would it be possible to make your source code available? This is for two reasons: a) If you are tired/unable to do more work on your emulator(s), it would be a shame to see your hard work wasted. If you're not going to work on the emulations any more it would be great if someone else could pick up where you left off and implement things you've so far missed, such as sound, accurate colours, etc. b) One day the big companies may take legal action against all the emulator coders (I doubt it very much, but you never know) - if the source code for the emulators is in the public domain then at least it won't be forever lost. ------------------------------------- .d88b. 8 db 8P Y8 .d88 8d8b. .d88 dPYb 8b wd8 8 8 8P Y8 8 8 dPwwYb `Y88Pw `Y88 8 8 `Y88 dP Yb ------------------------------------- Q.0 Trying to write an arcade emulator is crazy, isn't it? Neil Bradley (author of Emu) said himself, "Being unbalanced REALLY helps." However, this has not stopped the dozens of emulator authors from pursuing their goal. Anyway, most programmers are a bit crazy, right?? :) Q.1 Which game would you recommend starting on? Neil Bradley suggests: "Good question. I'd recommend picking one you like, because if you're emulating a game just to emulating a game, there's no fun in it. Fun is what keeps an emulation project goin." Mike Perry suggests: "I will go off on limb and suggest that you try to successfully emulate a machine using the 6502 processor. The 6502 is a very simple and powerful processor with has the 'feature' of having an instruction set with a 1-1 correspondence to the x86 instruction set. By this, I mean that every instruction on the 6502 instruction set also exists on the intel x86. Better yet, in all but a few exceptions (1 or 2), the intel instructions modify the exact same flags as the corresponding 6502 instructions, so there is little work needed to generate the resulting 6502 flag register settings. To top it all off, the 6502 was WILDLY popular in the early-mid 80s so you can be sure that there are _many_ classic-era games which use this chip." Q.1.1 Which games are 'easiest' to emulate? I have been told by Moose that a number of sources suggest Phoenix is the easiest game to emulate. Wiretap appears to have some good documentation for Phoenix. See also Q.1.2. Chris Hardy (author of Phoenix emulator for Win95) agrees: "[Here are some reasons why I started with Phoenix...] - Most importantly it has a good concise accurate description of the hardware memory map. [Wiretap archive and section Q.1.2] - It uses a 8085 which has an instruction set which is a subset of the Z80, therefore you don't have to implement all the z80 instructions, only the 8085 ones. (or borrow Marat's one and solve the problem) - It only uses character graphics, which means you don't have to do any sprite routines. - The 8085 is slow enough to emulate completely in C. (ie. my emulator is completely C). Although it is important to remember that the graphics side of my emulator(s) is in assembler and hardware. It's just that I didn't have to write it ;-) (Microsoft did!)" Neil Bradley recommends: "I wouldn't attempt Crystal Castles or Marble Madness, for example, as a first emulation, because it has lots of custom chips that aren't documented anywhere. Something simple, like Space Invaders, might be a good place to start. Your biggest hurdle in making that one run will be the Z80 emulation. In a nutshell, don't bite off so much that you can't chew it. A new graphics system, new sound system, new processor, and new mathbox board all make things futile for you. Start with games that, for instance, use a CPU that you know, or a graphics chip that you know (if applicable)." Mike Perry has this to say: "Which game is easiest? Gah, thats relatively hard to say. As long as the game only has one processor (or two if one is used for sound) then it will probably not be a terribly difficult task. If the game is vector based, that will increase the difficulty level considerably. The simpler the processor, the easier the programming task will be and the more likely it is that the emulator will run at a decent speed on a slower computer. In other words, an emulated 8088/z80/6502/6809 will not be difficult to handle on intel 486, but a 68000 will be a challenge!" Q.1.2 Which games have the most available documentation? At the present time, there is very little documentation freely available. Phoenix, Sega (Converta) vector games, and Space Invaders are described in sections M.1, M.2, and M.3 (Memory Maps) of this document. You may also want to check section R.4 (References). If anyone can provide information on other games, I'll be happy to add it to this HowTo! Dave Spicer says: "I can't think of any with detailed documentation. The easiest game I ever wrote a driver for was Space Invaders. It was a doddle!" Q.2 How do I START? Neil Bradley suggests: "If you don't know at least one assembly language, emulation is going to be a very difficult thing for someone to accomplish for two big reasons: Most games written prior to 1985 were written all in assembly. That means you're not going to have the luxury of looking at wonderful source code - you're going to have to guess what it's doing by what a disassembly is doing. Secondly, the concepts of I/O & memory, paging, etc... are all familiar to the assembly programmer. Knowing hardware, and how to read schematics helps immensely. I find a game I want to emulate. Then I find out what other games are similar enough to the platform of the game I want to emulate. If there aren't any, I seriously reconsider doing it. If there are others, I go ahead. Implement the CPU emulator before anything else. Writing sound & graphics engines won't do you any good if you don't have anything to drive them with. ;-) You need to know at least one high level language and an assembly language - preferably the one contained on the video game you're trying to emulate." Neil Bradley summed it up on the emulator mailing list: "Pick a game you want to emulate and stick with it. Get a CPU emulator that you know and trust and use it to get things running. Grab a disassembler and write yourself a small debugger to allow you to step through code, stop at specific points, etc..." Mike Perry offers this informative list of things to obtain: "[You will need] information on the microprocessors used in the game. Knowing the manufacturer and device number should be sufficient. You must then seek out a technical reference for the appropriate processors. In many cases you can mail the manufacturer for a free (or cheap) copy of the tech specs. You will need the specs for 1) The opcode matrix: This will have the hexidecimal values for the opcodes. 2) Instruction details: This will tell you exactly what each instruction does. If the processor has a flags register (it probably will!), it will tell you which flags are modified/set/cleared and under what conditions. 3) Instruction cycle counts: Depending on the machine, it may be necessary to keep an exact count of emulated cycles so that interrupts can be triggered at an _exact_ time eg 50 mhz, no more, no less. On vector machines, this may be a big deal. According to the author of the Vectrex emulator, the interrupts had to be trigged on the exact cycle or the whole display could be screwed. For raster games, I seriously doubt a few cycles will hurt anything. 4) Interrupt information: You need to know what interrupts can be triggered and when. If the processor uses an interrupt vector, you need to know the locations of the vector entries. You also need to know whether interrupts are prioritized. 5) Addressing information: You need to know exactly what kind of addressing modes are available on the microprocessor of the machine. These modes must be emulated for memory reads and writes, including instruction fetches and stack operations." Chris Hardy had this to say: "Hints on starting an emulator: - Write a 8bit binary dumper. This allows you to dump the ROMs in a form so you can work out which roms are the character roms and how the graphics are formatted. - Contrary to popular belief you don't have to have a complete character graphics system going to have some fun. Work out where the ASCII and number characters are in the character ROM's and display the display memory as ASCII on the text screen.(Just replace anything else with an "X" or something). I played my first emulated Phoenix game this way. (It even scrolled the background!). If you have a background and forground, just put them side by side. 80 columns is usually enough for most arcade displays. - As part of your processor emulator have a table in which you have a count of the reads and writes to every memory location. This allows you to immediately find what memory locations are being used by the emulated code, ie. screen memory, other "device" memory locations. If you need to, this can also be done for IN's and OUT's. - You don't have to always draw the whole screen. If you use offscreen buffers and a change table, you can work out which characters have been changed and just update them. This speeded Phoenix quite a bit, as drawing 1664 characters every frame took a while." Dave Spicer offered this: "I start on an individual emulation by finding the character hardware of the game in question and implementing a simple version of it. This is usually enough to see text on the screen and get some idea of what the game is doing. Q.3 What language should I use? I suppose it's possible to use almost any language available. However, for performance, assembly is definately the language of choice. High level languages used in current emulators include C and C++. Neil Bradley had these comments about languages to use in an emulator: "You might be wise to learn C. The biggest reason is that it is the most widely used language, and there are plenty of experts in the field to help you out. Pascal is dead as a new development language, except maybe for hobbyists, though I must admit Borland did a pretty damn good job of making Turbo Pascal a viable entity. With all of their extensions and nicities, it rivals C in its functionality. The same holds true for Visual Basic. It's not really BASIC in the literal sense anymore - it's a C-like language. The other reason is that about 95% of the CPU emulators I've found are written in C. I think I found 1 that was written in Pascal. [If you decide to use C++] you'll never make it on anything less than a Penitum Pro 200. CPU emulation is very time consuming, and even a single instruction or two can kill processor performance. To give you an idea, my original 6502 emulator ran at 1.2MHZ when written in optimized C (not C++). That was on a Pentium 120, and I'm no slouch when it comes to optimizing. I rewrote my 6502 emulator in 32 bit assembly and it's running at 15MHZ. Compilers are still no match for a seasoned assembly programmer. Add in the extra overhead [of C++], and you're toast. You'll never get good performance out of OO CPU emulation code... Add in big-time overhead for class alignment [and the] CPU emulator will be HORRIBLY slow... This is a really bad place to use C++. C++ has its place in UI and API abstraction, but when you're talking performance it's a *BAD* idea... Not to be too frank, but writing something like a CPU emulator in C++ would be considered shitty programming practice. ;-) If you'll notice, all well-performed emulators are written in assembly - at least as far as the CPU emulation goes." Mike Perry adds: "I can tell you now that you do NOT want to use Delphi. Delphi is for rapid prototyping and for developing graphical applications. An emulator is not an application that is suited for development in Delphi. Additionally, Delphi applications are only usable in Win95 and NT. DOS, being a single user, single-tasking OS, is more likely to bring better performance. [Using] Pascal is a possibility but Borland Pascal has serious limitations in terms of efficiency. For instance, someone was handling opcodes using a case statement case op1: blah blah blah; return; case op2: blah blah blah; return; case op3: blah.....; return; .... Now any reasonable C compiler, including Borland C++, converts this to a jump table (ie, code array) for fast case determination. BPascal on the other hands generates a series of mov, cmp (compare) and jmp instructions, like a big if-else. This means that opcode 212 will take around (212 * 4) cycles just to GET to the code using BPascal while it takes less than 6 cycles using C!! Even if you DO use C, your task is made MUCH easier using inline assembly. Better yet, make assembly the main language and link in external C or pascal function if necessary. The graphics routines should DEFINITELY be in assembly. [You] WILL be better off learning [assembly]." Dave Spicer warns: "IMHO, writing an emulator in Pascal is not a particulatly good idea. You'll be emulating machine code, so you want something that resembles that in form." Q.3.1 Do I *have* to use Assembly? Neil Bradley says: "Regardless of what some academics would like to believe, a compiler can't outclass a good assembly programmer. You'll spend plenty of time optimizing, and if you rewrote it in assembly, you're almost assuredly going to get a 30-40% speed improvement. C compilers (and others for that matter) solve for the general case, and make assumptions on what registers/variables need to be saved. In assembly, you know the code, and can write, at the CPU level, and write the most optimal instruction sequence to match the common-case path of your code. You really do need to know assembly to do a project like this - that is to do it in an effective amount of time." Mike Perry says: "Normally I would not recommend writing an application primarily or entirely in assembly. Assembly is minimally portable and if an application spends 90% of its time executing 5% of its code, it does precious little good to hand optimize the remaining 95% in assembly. An emulator, on the other hand, is not your normal application. An emulator's job is to emulate hardware. In emulation, you will be dealing with registers, memory addressing and memory reads/writes. The instructions the real processors use to do this sort of stuff are very "basic". They are so basic that its actually easier to use x86 asm and the intel registers to do what you want than it is to use a high level language. Assembly makes it easy to manipulate 8-bit, 16-bit and 32-bit values. C and Pascal make it downright tedious to manipulate more than one size variable in an expression. At the least, your HLL code will contain many many typecasts, making it very hard to read." Q.3.1.1 Are you SURE about this Assembly business? :) Paul Kahler points out: "A number of people indicated that assembly is the only way to get good performance on anything short of a pentium pro. I'd just like to say that the first rev of the Cinematronics emulator was written in TURBO PASCAL and seemed to run just fine on a Pentium-90. That was almost 2 years ago, so we were trying to run on a 486 and had to move on to assembly. TP allowed me to create an array of functions so I could grab the opcode and call the proper function. That's really good performance considering the CineProcessor doesn't map at all to x86 or anything else, and it ran at 1.7 MIPS! A 6502 should be no problem for C code on a Pentium or even a 486. But then there's graphics and sound also... I just wanted to point out that ASM isn't the only way to go, and if you do things in C they'll be portable. BTW I used the BGI drivers for the vector display back then too!" Pete Rittwage adds: "I've been able to get stellar performance out of my 6502 purely in C, including graphics overhead, even on my lowly 486/100. I've also seen people get pretty good performance out of Marat's Z80 code in such things as the Donkey Kong emulators, and that code is FAR from optimized. It accesses things a couple of structures deep at times, which is very inefficient." Q.3.1.2 Doesn't the choice of language depend on the target game/system? Neil Bradley clears things up: "Writing an emulator strictly in C++, including CPU emulation and graphics emulation will not give you good performance on anything short of a pentium pro. The author of the Tempest emulator that runs under Windows runs fine at 150MHZ, and it's written in C. If that's your target platform, great. And if your target platform is a 486/66 and your graphics are heavily intensive or running on a slow ISA card, you better not use C or C++. To give you some benchmarks on some "famous" CPU emulators, here are some #'s (not including graphics - just RAW CPU time) that indicate the emulated speed on a 486/66 running Asteroids, compiled under Watcom C++ 10.6 with the 486 compile option thrown: Emulator Emulated speed Marat's 6502 1.6MHZ Apple IIe emu 800KHZ Optimized Apple IIe emu 1.9MHZ EMU's first 6502 C emulator 2.5MHZ EMU's 100% Assembly 6502 6.8MHZ My background is assembly & C optimization. I've spent greater than 20 years on numerous processors, and have programmed everything from tiny microcontroller circuits to multi-CPU applications, so I'm no slouch when it comes to C or assembly optimization. ;-) . The results above speak for themselves. Keep in mind that there aren't any graphics routines or sound routines in this code under this test. So I'll reiterate what I've tried to say in the past: If your target machine is a 486/66 with a crappy ISA card, you'd better squeeze everything out of the emulator that you possibly can, because you'll need it. EMU Uses a single page of 256 color graphics. It erases the prior frame and draws the new one. Typical frames are 300 vectors. 600 Lines per "frame", and roughly 25 frames per second. That's 15000 lines per second that must be drawn, and if we say that the average line is 50 pixels, that's 750,000 pixels a second. Most games, such as Donkey Kong or Space Invaders aren't coming even close to moving that many pixels on the screen. So in that case, you can get away with having a less than tota