aehowto.txt

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

   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: (see section R.4.1.3)

   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.5 under References.

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

   See section R.4.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.4.1.2 and R.4.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.4.1.3 and R.4.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 published song. As a published
   producer and musician, I can assure you all that this is not the case."

Q.9.2    What is the difference between a speech synthesizer and a
         sample playback device?

   Joel Rosenzweig says:

   "The difference between a speech synthesizer and a sample playback device
   is a little fuzzy, but I'll describe the two so you'll see why I call
   Star Wars speech reproduction 'sample playback' instead of 'speech
   synthesis.'

   In sample playback, a waveform is stored in a compressed or decompressed
   state in memory. This waveform is generally longer than a phoneme, and
   when played, an entire word or phrase is heard.  Generally, an entire
   sentence would be stored as 'one sample', so that when the microprocessor
   signals that some speech should occur, it says to the sound unit, play
   speech sample number 'x' which might be the entire sample 'Use the force,
   Luke.' This playback device then reads data from an EPROM starting at the
   location of the sound sample for this speech, and reads the data. After
   the decompression step, a digital to analog conversion step takes place,
   and the analog waveform is output. When this single operation is finished,
   the entire 'speech phrase' is complete.

   In a speech synthesizer, speech is produced by the catenation of small
   sounds called 'phonemes.'  The English language has a little over 50
   phonemes. You can create any English word with the right combination of
   phonemes. These phonemes can be stored as programming data for a
   'synthesizer'' (it says to the FM synth, 'how to generate this sound
   programatically') OR the phoneme data could be live samples from a human.
   In order to create a 'WORD' the microprocessor determines the correct
   string of phonemes that need to be played in order to generate the correct
   sound. A string of phonemes are sent to the speech synthesizer which then
   will play the phonemes in order using the technology for that chip (either
   sample playback or by programming an FM synthesizer.) Many phonemes are
   read in precise order to generate a word, and then a sentence. Whereas
   only one read/playback cycle is needed to play a sentence with a sample
   playback device implementation, the speech synthesis implementation is
   required to do many shorter cycles to achieve a similar outcome.

   A speech synthesizer by nature, is able to reproduce ANY 'English' (say)
   word because rather than storing the words themselves, it just stores all
   the phonemes needed to produce these words. A sample playback device, is
   not capable of reproducing ANY English word because it only knows how to
   play back the samples that are stored in memory. (these might be words, or
   it could be a sound effect)

   Now, certainly, if you wanted to, you could record all the English
   phonemes, store them as samples, and then use a sample playback device and
   a microprocessor to ACT like a speech synthesizer. In fact, this scheme
   works quite well and you can get some 'human like' sounding speech out of
   them. But the main point is that a sample playback unit is capable of
   playing back ANY sampled sound and is not bounded to generate speech only.
   A speech synthesizer then is a more limited device that might employ the
   use of a sample playback device in order to play its phonemes (if they are
   stored that way). And yes, if perhaps a phoneme were stored as a sample,
   then you could store an entire speech sample as one 'phoneme' but then
   you'd technically have a sample playback device, and not a speech
   synthesizer.

   So, to wrap up, the biggest difference is that sample playback devices are
   used to play back any sample of sound imaginable, and can be used to play
   back whole samples of speech. A speech synthesizer is a device that in
   some instances behaves just like a sample playback device, but its VALUE
   is that it can produce any word from a set of phonemes, and is not limited
   to 'pre-recorded' speech or other sounds.

   In Star Wars, the TMS 5220 is a device that plays back pre-recorded
   samples of speech data, stored in the EPROMS of the sound board. It is not
   capable of producing any speech we could dream up, because it does not
   have individual phonemes stored anywhere accessable to it, hence it is not
   a speech synthesizer. The advantage here is that Luke's voice sounds like
   Luke, and Darth Vader sounds like Darth Vader, etc. A rudimentary speech
   synthesizer is not capable of copying different 'voices' and is usually
   limited to small changes in pitch,