aehowto.txt

hao

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

   Martin Scragg comments:

   "Schematics can help a great deal, they can help to generate a memory map
   that you will need to emulate a game. Basically when you write an emulator
   you are duplicating the hardware shown in the schematics with software, so
   the more you can get from them the easier it will be. Some memory maps for
   certain games are available in the HowTo or for download, so this is
   possibly a good place to start if you can't read schematics. If you can't
   get a memory map either off the net or by making it yourself from the
   schematics then writing an emulator is going to be a very slow process as
   you will have to disassemble the game and try to determine what it is
   doing with the hardware."

   SolarFox says [about using schematics]:

   "While probably not 100% essential, it will make your life a _lot_
   easier... Otherwise, you _will_ have to disassemble a fair amount of the
   game code and try to figure out where the RAM, ROM, and I/O devices are
   based on what's being read from or written to the various addresses..."

Q.6   How do I produce a memory map?

   First, read sections S.3 and S.4 of this document...

   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
   disassemble and debug romfiles. It's called NOI25Z80.zip and is written
   by John Hartman. This one is specifically for the Z80 ,but there are
   versions for 6502 and other processors. It gives you a fully interactive
   disassembler and memory dumper (HEX and ASCII). It can also trace (debug)
   ROMS. Input files have to be in INTEL HEX format, so you need a utility
   like BIN2HEX to convert ROMS to HEX files. Use ftpsearch
   (http://ftpsearch.unit.no/ftpsearch) to find places to get it."

   Note: I found the files in the SimTel archives:

   Directory SimTel/msdos/debug/
    Filename   Type Length   Date   Description
   ==============================================
   noi25370.zip  B  179655  951111  NoICE 2.5 remote debugger for TMS370
   noi25_02.zip  B  167495  951111  NoICE 2.5 remote debugger for 65(C)02
   noi25_09.zip  B  185554  951111  NoICE 2.5 remote debugger for 6809
   noi25_11.zip  B  178389  951111  NoICE 2.5 remote debugger for 68HC11
   noi25_51.zip  B  170645  951111  NoICE 2.5 remote debugger for 8051
   noi25_96.zip  B  170411  951111  NoICE 2.5 remote debugger for 80(1)96
   noi25_z8.zip  B  180580  951111  NoICE 2.5 remote debugger for Z8
   noi25z80.zip  B  191219  951111  NoICE 2.5 remote debugger for Z80   

Q.7   How can I find what processor(s) the game uses?

   See section R.4 under References. Also take a look at the Game Data
   section...

Q.7.1    Where can I find information for a specific processor?

   See section R.3.1.3 under References.

   Adam Roach also suggests:

   "...most processor manufacturers will provide free or cheap data on
   their processors if you call or write them."

   Dave Spicer had this to say:

   "I don't know of any really good info on the net. However, you might
   like to try and get hold of "Programming the Z80" by Rodney Zaks
   (ISBN 0-89588-069-5). This is the book I use if I need to look up any
   Z80 info... I'm not so sure about books for 6502. I always used to use
   the Commodore 64 programmer's reference guide!"

   Neil Bradley's source for the 6502 was:

   'Programming the 6502' by Rodnay Zaks was my bible for developing the
   6502 emulator used in EMU."

Q.8   Where might I find the ROMs?

   Try the resources in R.3.1.2 and R.3.2. If all else fails, find someone
   who owns the machine, and see if they can help you (see Q.10).

Q.8.1    How do I disassemble the ROMs?

   If you are lucky, someone may have already written a disassembler for
   the processor in your target game. Check sections R.3.1.3 and R.3.2
   under References.

Q.8.2    How do I decode instructions, variables, data, sprites, colors,
         graphics, etc. from the ROMs?

   Neil Bradley's answer:

   "Trial and error. Seriously. Anything beyond this explanation can't be 
   described in 30 words or less... It's a mix of RAM and ROM in that space,
   in addition to hardware in that space as well. It's different for each
   platform."

   Dave Spicer says:

   "Use a debugger and a graphics viewer to find the data (I wrote my own).
   Other things require you to make sense of the original game code and work
   out what it's doing."

Q.9   Should the sound be emulated or should sample be used?

   This has been a hotly debated question on Neil's [e-mail]
   mailing list, so I thought I'd address it here.

   It seems there are two factions in this debate:
      - Those who want an emulator to be 100% emulated.
        No samples should be used because this is 'cheating'.
        Even at the risk of having poorer quality sound, or slower
        overall emulation, these "purists" would like to see the
        sound emulated...
      - Those who want an emulator to be as close as possible to the
        real thing.
        Samples should be used because they provide better quality sound,
        and can produce bass effects that were produced by the arcade
        cabinet.

   Neil Bradley says:

   "The whole purpose of emulation is to EXACTLY DUPLICATE the look, feel,
   sound, etc... of the game.

   The Pokey uses a top octave divider that basically pulls pulses off the 
   data & addressing bus to generate its sound. Because of the odd frequency 
   of the Pokey, everything is slightly flat, and off key (musicians, ever 
   notice this?). The sound of a top octave divider circuit sounds nothing 
   like FM synthesis that's found on the SB and other boards. You can get 
   somewhere in the ballpark, but you'll always find that FM synthesis in 
   sound cards is somewhat thin. That's totally opposite of the Pokey.

   For other games that use more conventional synthesizer chips, sound is
   much easier, because they use standard waveforms, etc...

   Sampling gives you the truest to life representation of the real thing,
   which is exactly what emulation is going for.

   With all due respect, the average individual can't tell the difference
   between a sample and the real thing. The only thing that would make it
   fake to you is knowing that it was a sample.

   Sorry if I come across as a bit agressive about the sample issue, but it's
   one of my hot bottons. So I'll ask the question again - do you want the
   sound cards to attempt FM synthesis on something that doesn't sound like
   FM synthesis and won't sound like the original, or would you like it to
   sound like the original?"

   Ed Henciak adds:

   "I'd also like to emphasize sampling in game emulation. I have begun work
   on a Sega vector game emulator (primary focus is Star Trek). You may have
   seen this on Moose's page as my senior project here at Pitt. Anyway, I
   don't even plan on emulating the sound. I have a Star Trek set and will
   use samples for all audio. The goal of emulating old arcade games (to me)
   is to bring back the experience of playing these games. If you have a
   'finished' emulator (i.e. the final revision you release) with weak/no
   sound, it just misses the point of emulation. I understand 'EMULATION'
   refers to emulating all hardware in the game, but I think an arcade
   emulation should be limited to only having to emulate the cpu and video.
   Audio is critical to any game playing experience (in my opinion, Gyruss
   would have been kinda lame w/o that killer soundtrack). And from what I
   have been reading in this group, it is way too wacky from game to game to
   make it 'perfectly emulated'. Plus, it hogs CPU time. In games such as
   Dave Spicer's Pac Man, the audio is perfectly emulated. I believe Pac Man
   uses 1 Z80 CPU and 1 Sound Chip. Not too much overhead!!! Star Wars, on
   the other hand, uses 4 POKEYS, and Major Havoc uses 3 CPUs in addition to
   the 4 POKEYS!!! I believe that if we want to see these games emulated w/o
   additional hardware, and, more importantly, the authors are up for it, we
   should focus on sampling audio from our games, make an 'audio archive' of
   sampled sounds at 44KHz (possibly make a small circuit to take this input
   from our machines directly to the sampler), and pray the authors take
   advantage of this. Granted, I have only been an 'emulator programmer in
   training' for a couple weeks now. I still have a long ways to go in this
   area and fully respect all you authors out there for such incredible work!
   I just want to push sampling because it helps to fully bring back the
   arcade experience!!!

Q.9.1    What about legal issues? Are samples copyrighted?

   Neil Bradley counsels:

   "There are only two conditions where you can copyright a sound:

   #1 If the sound itself is a sample (as in the samples in the Star Wars &
      Empire Strikes Back games)
   #2 If the sound itself is contained within a sample playback unit (I.E. 
      Joust, Robotron, etc...). There are some direct waveforms that can't be
      copyrighted (Sine/Sawtooth, etc...)

   If #1 is the case, the only way you can get legal right to redistribute is
   to license it.

   If #2 is the case, the only way you can legally utilize the sound is to 
   re-sample it, otherwise you'd be copying the data right out of the EPROM.

   Both case #1 and Case #2 above are legally considered "creative works".

   The Pokey is a sound synthesizer chip (among other things). It is designed
   to generate a wide variety of sounds. If it were true that you couldn't
   legally sample a real world synthesized sound, then no one would be using
   synthesizers.

   Plenty of lawsuits were filed with large musical instrument corporations 
   due to sample stealing (Roland & Yamaha both stole Fairlight's "chior" 
   sample that's used on quite a few big-time hits in the 80's). In all
   cases, they were sample-sourced lawsuits. Not one has ever been filed
   where the source was synthesis.

   There have been suits filed under patches being stolen and reused in other
   synths, but under copyright law it's considered software since it's stored
   as data.

   Atari can't copyright the sound that the pokey generates. If that were the
   case, then any sample-playback synthesizer (like almost everything sold
   today) patch preset couldn't be used in a