aehowto.txt

hao

 * S.3.2    Memory Maps: The "Easy" way...
 * S.3.3    Emulator Memory Maps: The "hard" way 
 * S.3.4    Other Common Chips
 * S.4   How to Create a Memory Map for Moon Cresta
   
 * References
   ----------
   R.1   List of Currently Emulated Games
   R.2   List of Games People Want to See Emulated
   R.3   Internet Resources
   R.3.1    WWW Resources
   R.3.1.1  General Arcade Emulation Links
   R.3.1.2  ROM Images
 * R.3.1.3  Processor Information
   R.3.1.4  Schematics
 * R.3.1.5  Miscellaneous Information
 * R.3.2    FTP Resources
   R.3.3    FSP Resources
   R.4   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 ([e-mail])
   - Neil Bradley ([e-mail])
   - Don Carmical ([e-mail])
   - Clay Cowgill ([e-mail])
   - Mike Cuddy ([e-mail])
   - Jim Dankiewicz ([e-mail])
   - Laurent Desnogues ([e-mail])
   - Bryan Edewaard
   - Chris Hardy ([e-mail])
   - Ed Henciak ([e-mail])
   - Joe Husosky ([e-mail])
   - Paul Kahler ([e-mail])
   - Ralph Kimmlingen ([e-mail])
   - Thierry Lescot ([e-mail])
   - Moose O' Malley ([e-mail])
   - Alan J McCormick ([e-mail])
   - Ivan Mackintosh ([e-mail])
   - Vince Mayo ([e-mail])
   - Phil Morris ([e-mail])
   - Brian Peek ([e-mail])
   - Mike Perry ([e-mail])
   - Alan Pope ([e-mail])
   - RisqMan ([e-mail])
   - Pete Rittwage ([e-mail])
   - Adam Roach ([e-mail])
   - Joel Rosenzweig ([e-mail])
   - Trevor Song ([e-mail])
   - Gary Shepherdson ([e-mail])
   - Martin Scragg ([e-mail])
   - SolarFox ([e-mail])
   - Dave Spicer ([e-mail])
   - Brad Thomas ([e-mail])
   - Allard van der Bas ([e-mail])
   - Nemoto Yohei ([e-mail])
   - 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 *much* of this
     document using DOS's edit in a DOSemu window under Linux X!!
   - And, anyone I forgot!  :o

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

   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.

   Martin Scragg suggests:

   "Get hold of some source (try the Arcade Emulation Repository). See what
   other people have done. Get a feel for how the games that you want to
   emulate work. Pick a game that you like and try and find out information
   about it. The less information there is about a game the harder your job
   will be. Don't try to go overboard with your first emulator, even doing a
   game that has already been done is good because you can compare your
   product with an existing one, and if it has been done befaore then there
   is a good chance that you can get some good info about it."

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