aehowto.txt

hao

   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.1.3  Should I try to learn the assembly of the target platform?

   Martin Scragg says:

   "It would probably help, even if you get a memory map etc. there are going
   to be certain things that will require you to disassemble the code to
   figure out."

   SolarFox says:

   "Again, your task will be a _lot_ easier if you do, because you'll have a
   better understanding of what the game is up to if it starts poking values
   in odd places or behaving unexpectedly.

   Basically, it works out like this. It's _easiest_ if you understand
   _both_ the schematics _and_ the assembly-code of the game you're trying
   to emulate. It's considerably more difficult if you only know one, but
   not the other. If you don't understand _either_, then I'd guess it'd be
   all but impossible."

Q.4.1.4  How did games with multiple CPUs work?

   Mike Cuddy says:

   "On classic arcade games, the usual method is to have them share a portion
   of the address space through an SRAM chip (if they need to share alot of
   data, like sprite control stuff), or sometimes they only share a couple of
   latches or a small register-file (there are single TTL chips which to
   this). Since SRAM is so much faster than these "slow" processors could
   ever deal with, the SRAM's is time-multiplexed between the two processors.
   (i.e: the SRAM is clocked at 6Mhz while the two cpus toddle along at 3mhz
   each... They never even know the other is using the ram -- no wait states,
   etc.) This makes it up to the programmers to decide how to synchronize the
   CPUs.

   Usually, one of the cpus is a "master" cpu, and the other CPUs will do
   thier work for one frame of animation and then spin-wait on a certain
   address;  to get the most speed, I have disassembled the code used in the
   game looking for those "trigger" points, and then set up the cpu emulation
   to stop running where the original program would just be spin-waiting. And
   then when I detect the stimulus from the main cpu that would cause the
   subordinate CPU to start running, I run the subordinate cpu until it gets
   back into it's idle loop."

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.2.1  Where can I find freely available source code?

   Refer to the Arcade Emulation Programming Repository at:

   http://valhalla.ph.tn.tudelft.nl/emul8/arcade.html

Q.4.2.2  How do I install DJGPP and Allegro taking only *limited* space?

   Vince Mayo instructs:

   "Here are the necessary files (that I know of) to install DJGPP, Make,
   and Allegro:

   djdev201.zip
   gcc2721b.zip
   bnu27b.zip
   mak375b.zip
   alleg211.zip

   When you go to uzip these, use -d option. And to make the install
   easier, install it to C:/djgpp.  You will have to modify the *.env file
   to put it on a different drive or directory.  

   Add these 2 entries accordingly to autoexec.bat:

   In path statement add c:\djgpp\bin
   In set statements add set djgpp=c:\djgpp\djgpp.env

   Unzip all these files -d to the c:\djgpp directory. Give allegro its own
   directory under djgpp. You will need to run make on Allegro because the
   libraries are not compiled to save space.

   I think this might take up around 13 meg on your hard drive. Some files
   might not be needed but I do not know which."

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, pinouts, and schematics?

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