aehowto.txt

This document is designed to aid anyone considering whether to write an emulator for an arcade gam

   "When doing something with the Z80, for example, it's quite extensive. 
   You've got the functions of 300+ opcodes to deal with, and permutations. 
   Not to mention that some arcade manufacturers' code use the Z80 
   'undocumented' opcodes (though they're not so 'undocumented' anymore...).
   Grab yourself a book on Z80, 6502, 6809, or whatever CPU you're working 
   with. That's the best way to start. The 8080->Z80 processors are actually
   much more complex than the 6502."

Q.4.1    CPU emulation sounds VERY complicated, how should I START?

   Mike Perry offers the following:

   "I recommend that you read a few good books on computer architecture and
   digital circuits and/or boolean algebra. If you understand how the
   basics behind the following, you'll be well prepared to emulate a
   microprocessor:

   1) Fetch-decode-execute process
   2) Buses and memory/data reading/writing
   3) Interrupts and their implementations
   4) Stack operations
   5) Registers and flags
   6) Binary arithmetic, two's complement representation, boolean algebra

   I suggest 'Computer Hardware' by M. Mano.  Another good book is
   'Computer Architecture: A Practitioners Approach' (or something like that)
   by Patterson and Hennesey. These are both college textbooks. Of the two,
   the Patterson book would probably be the most helpful as it covers
   architecture on the system level rather than the gate level. It covers
   MIPS assembly language, pipelining (unimportant to emulation, although
   you could use a similar technique to speed up the emulation), memory
   addressing, virtual memory and IO devices/DMA."

Q.4.1.1  Is the 68k series of processors 'easy' to emulate on PCs?

   Phil Morris found the following on a UseNet newsgroup:

   "68k emulation can be done VERY quickly on intel... Check out ARDI's
   Executor. They use a combination of an interpreter and a dynamic 
   recompiler. It reaches 68030 speeds on pentiums. Very cool. Their white 
   paper is good reading for anyone looking to write an emulator.

   Maybe this White Paper is available on Ardi's Web site? (www.ardi.com)"

Q.4.1.2  Why were only a handful of processors used in arcade games?

   Neil Bradley offers us a bit of history:

   "Most of the issue was cost back then. The 6502, Z80, and 6809 CPU's were 
   the cheapest, and most of the games in the early 80's and late 70's 
   didn't need 68000's or 8086/80286's. The cost of a 6502 compared to an 
   8086 was about a quarter the price.

   The 6502 got its start by doing about 30% of the functionality of the 
   8080. Throughout the years, the 6502 has been known by many programmers 
   as being a collosal piece of garbage. I always did hate the chip. It 
   worked, but barely. No 16 bit pointer registers, only 256 bytes of stack, 
   etc... It was the first CPU at the time that actually chaged its flags by 
   a register load. It was a pretty weak CPU in terms of functionality (as 
   evidenced by BattleZone & Red Baron). They could have implemented that 
   game with a higher CPU (like a Z80 @4 MHZ) and eliminated the mathbox 
   altogether. I think at the time it would have almost been cheaper to do 
   it this way.
 
   The 6809 made quite a few improvements over the 6502 and the 8080/Z80. It 
   had the opportunity to learn from the 8080's & 6502's mistakes and was an 
   all around better chip. In some aspects the 8080 was superior (I.E. more 
   registers), but the 6809 had lots of nice features and was extremely 
   consistent.

   The Z80 started when some guys who worked for Intel split off and made 
   their own company (Zilog). They took the 8080 design and added lots of 
   nice features to it to make it a REAL powerful chip. Of that era, the Z80 
   was the most popular CPU and the most powerful. Built in block move 
   commands & all kinds of register indirection. Most games of that era used 
   the Z80."

Q.4.2    Should I use CPU emulation code that is freely available?

   Dave Spicer suggests:

   "Writing a processor emulator is a big job and is very difficult unless
   you know your your emulated processor fairly well.  You might be better
   off starting out with Marat's C based emulation code as that's a proven,
   albeit slow, technology."

   Neil Bradley says:

   "If you are goal oriented, learn from their emulator first, then write 
   your own. If you want an education, by all means, but that's a big chunk 
   to bite off."

Q.4.3    How do the CPU and ROMs interact?

   Neil Bradley instructs:

   "Create your entire memory space, including loading the ROMs, and start 
   your execution wherever the processor starts. Don't try to interpret the 
   ROMs - you'll never get it right because it's completely unpredictable."

   Mike Perry adds:

   "As for variables and stuff, thats the beauty. You aren't SUPPOSED
   to have to know how the processor is being used. You emulate all
   of the opcodes and interrupts, and have a simple fetch-decode-execute
   loop. You also emulate the supporting hardware (controls, gfx and
   sound) to be called during interrupts. If those are written correctly,
   the emulated game will run itself... You don't need to know the details
   of the game code."

Q.4.4    How should I handle CPU opcodes?

   Neil Bradley has this to offer:

   "If you're going to be handing off a single opcode between classes, the
   overhead will completely nullify any speed you could even hope to get. 
   Try using a pointer to the current virtual program counter and fetch 
   bytes as you need them. Use an array of function calls - one for each
   opcode... Point invalid opcodes to a NOP function... [Pointers are] 4
   bytes if you're doing 32 bit code."

Q.4.5    What is Pokey?

   He is Gumby's friend! :)

   Seriously, for a great description of what the Atari Pokey is, see the
   Pokey section below.

Q.4.6    What is Slapstic?

   It's a form of comedy. Nyyyuk nyyuuuk nyyyuuk... Woo woo woo woo woo!

   Actually, it's a security chip Atari introduced in some of their games.

   Suzanne Archibald provided this information:

   "Unfortunatly, I don't have any information on the chip per se, just how
   to avoid it in Gauntlet. See, for each machine using a slapstic chip
   (each was different - the name being a generic term to Atari's copy
   protection) the chip would have a unique function, in the case of
   Gauntlet I/II the chip decoded the top 2 bits of the Maze data. With this
   in mind, getting around Slapstic on Gauntlet isn't too difficult, you
   simply use a ROM that is available, that has the correct Maze layouts
   without needing decoding, you then disable the slapstic, and hey presto."

Q.4.7    What about translation? Would it be easier to translate the code
         into a language the PC can compile rather than emulate the CPU?

   Here's what I mean by translation: Write a program that reads in each
   machine code instruction from the ROM (where the CPU instructions are
   stored) and outputs a line of code in say, Assembly or C. If you devise
   a set of translation rules from the machine code to your target code,
   and if this idea works, you should get a program that you can compile
   (and optimize if you like) that will perform the same operations as
   the original ROM.

   After I had this thought, Moose told me:

   "This idea was discussed in c.e.m years ago.

   The problem (as I understand it) with translation is :

   - How do you ever know when you have translated all instructions/data?
     Some bits of a game (say) only get called / run under real unusual
     conditions.

   - Where code is loopy, your translator would have to be super intelligent
     to recognise the loop (which might span 1,000's / millions of
     instructions).

   - How do you ever know when / if you have captured all instructions / data.

   The way I understand things, translation is extremely difficult, but not
   impossible. However, I think it is several orders of magnitude in
   difficulty above straight emulation. Then again, maybe it can be done."

   Neil remarked:

   "I've actually kicked around the idea of writing an emulation compiler, 
   which would actually take the native object code of the game and convert 
   it into the native machine's code, and execute THAT instead of emulating 
   the processor. That would allow the game to run at the native processor's 
   speed, and you'd get 5-10X speed improvement in CPU emulation. Even the 
   simplest of instructions winds up taking 20-30 clock ticks in emulation
   land."

Q.4.8    Is there anything else I should know about CPU emulation?

   Neil Bradley reminds:

   "[Don't forget] to include events that happen at regular or random
   intervals (like NMI's or interrupts)."

Q.5   How useful are the switch settings and pinouts?

   Mike Perry suggests:

   "Switch settings are important, but only because you'll probably want
   to let the user initialize them to whatever they want. Even if you
   don't, you still will need to emulate them because they are probably
   memory mapped and the game code uses the information to set things
   like number of lives, etc. If you dont know exactly what they do, 
   you'll probably have really weird settings in your game."

   Neil Bradley adds:

   "The switch settings are useful only once, usually. That's the time when 
   you first fire up the code and wonder whether or not the code is going 
   into self-diagnostic mode. Knowing what the switch settings were once 
   helped [Emu] get out of diag or halt mode. Knowing the pinouts didn't do 
   anything. Knowing where the address (from the CPU's standpoint) of the 
   switches were was MUCH more helpful!"

   Dave Spicer says:

   "[A knowledge of] electronics helps because it means you can use
   schematics to fill in some awkward gaps. That said, most of the time I
   just work from the original program code and make guesstimates as to what
   everything should do."

Q.6   How do I produce a memory map?

   Kevin Brisley offers:

   "Well, I've been plugging away at trying to figure out the inner workings
   of Burgertime and thought I'd try to get some discussion going in the
   area of trying to create a memory map for an arcade game.

   So far I've managed to determine the addresses the ROMs containing code
   mapped to by checking for IRQ/NMI/Reset vectors and then looking through
   the disassembled code for hints (eg. checking jmp's and jsr's to get an
   idea of where the ROM goes). 

   The next step is determining where the rest of the ROMs go. I had planned
   on doing this by scouring the code for references to addresses that I had
   not found a ROM for and trying to determine the context of the access.  
   For example, if a piece of code looks like it's copying the bits to make
   the letter 'A' and I know which ROM contains the charset then I'd have a
   place for the ROM.

   But I also have the schematic for Burgertime and was wondering if there
   was an easier way. I thought that there must be a way to determine from
   the schematic where the various ROMs go. Unfortunately I'm not an 
   electrical engineer and my talent for interpreting schematics is not
   great.

   The question also holds for memory mapped I/O. I was going to apply the
   same logic to determining where the buttons mapped to but all of the 
   buttons and joystick appear on the schematic. Is there a way to trace
   the connection to a button back through the schematic and figure out
   what bit gets flipped in memory?

   If this is not possible, how have the emulator authors out there 
   determined this stuff? Through the scouring code method or some other
   method I haven't thought of?"

   [I'm sure everyone would be happy to get more information on this...
    anyone out there want to help?]


   (I received this information from someone who is staring to work on an
   emulator. He asked me not to reveal his name, because his time is limited
   and the emulator may not be finished any time soon) :

   "During the initial scan [of the ROMs] I used some tools that might be of
   use to other emulator developers. Specifically Marat's DASM that's
   supplied with the Z80 emulation package and a DOS tool that I found.
   It's intended for debugging PCB mounted CPU's but can also be used to