💾 Archived View for gemini.spam.works › mirrors › textfiles › games › ARCADE › aehowto.txt captured on 2022-06-12 at 07:34:03.
⬅️ Previous capture (2020-10-31)
-=-=-=-=-=-=-
d8888 888
d88888 888
d88P888 888
d88P 888 888d888 .d8888b 8888b. .d88888 .d88b.
d88P 888 888P" d88P" "88b d88" 888 d8P Y8b
d88P 888 888 888 .d888888 888 888 88888888
d8888888888 888 Y88b. 888 888 Y88b 888 Y8b.
d88P 888 888 "Y8888P "Y888888 "Y88888 "Y8888
8888888888 888 888 d8b
888 888 888 Y8P
888 888 888
8888888 88888b.d88b. 888 888 888 8888b. 888888 888 .d88b. 88888b.
888 888 "888 "88b 888 888 888 "88b 888 888 d88""88b 888 "88b
888 888 888 888 888 888 888 .d888888 888 888 888 888 888 888
888 888 888 888 Y88b 888 888 888 888 Y88b. 888 Y88..88P 888 888
8888888888 888 888 888 "Y88888 888 "Y888888 "Y888 888 "Y88P" 888 888
888 888 88888888888
888 888 888
888 888 888
8888888888 .d88b. 888 888 888 888 .d88b.
888 888 d88""88b 888 888 888 888 d88""88b
888 888 888 888 888 888 888 888888 888 888 888
888 888 Y88..88P Y88b 888 d88P 888 Y88..88P
888 888 "Y88P" "Y8888888P" 888 "Y88P"
Version 0.25
Compiled by Michael Adcock
email: adcock@menudo.uh.edu
January 7, 1997
--------------------------------------------------------------------
Yb dP 8 w w dP"Yb
Yb db dP 8d8b. .d88 w8ww ." d88b 8d8b. .d88b Yb db dP " d8
YbdPYbdP 8P Y8 8 8 8 `Yb. 8P Y8 8.dP' YbdPYbdP dP
YP YP 8 8 `Y88 Y8P Y88P 8 8 `Y88P YP YP w
--------------------------------------------------------------------
- Updated Q.2
- Added M.1, M.1.1, M.1.2, M.1.3, M.1.4 (Crazy Climber)
- Updated M.5, M.5.2 and added M.5.8, M.5.11 (Sega System 16)
- Added B.2, B.3.1, B.6, B.8, B.9, B.12, B.14 (Lot's of bits and things)
- Added S.2, S.2.1, S.2.2, S.2.3, S.2.4 (Space Invaders step-by-step)
- Updated R.1 (Emulator updates!)
- Updated R.5 (Game listing updates!)
--------------------------------------
888b.
8 .8 8 8 8d8b 88b. .d8b. d88b .d88b
8wwP' 8b d8 8P 8 8 8' .8 `Yb. 8.dP'
8 `Y8P8 8 88P' `Y8P' Y88P `Y88P
8
--------------------------------------
This document is designed to aid anyone considering whether to write an
emulator for an arcade game machine. It will attempt to answer frequently
asked questions, give a step by step tutorial, and provide the resources
necessary for a capable programmer to begin work on an emulator for an
arcade game.
Please note that although some of the information provided is generic
enough to apply to emulation of any system, the primary focus of this
document, and the resources provided, is arcade game emulation.
This document contains no information about the commercial emulation
packages that are available.
If you have any information that should be added to this document,
then please email adcock@menudo.uh.edu or moose@rocknet.net.au !
Table of Contents:
Q and A
-------
Q.0 Trying to write an arcade emulator is crazy, isn't it?
Q.1 Which game would you recommend starting on?
Q.1.1 Which games are 'easiest' to emulate?
Q.1.2 Which games have the most available documentation?
* Q.2 How do I START?
Q.3 What language should I use?
Q.3.1 Do I *have* to use Assembly?
Q.3.1.1 Are you SURE about this Assembly business? :)
Q.3.1.2 Doesn't the choice of language depend on the target game/system?
Q.3.1.3 What about portability?
Q.3.2 But haven't some arcade emulators been written in C/C++?
Q.3.3 What about Java?
Q.4 Could you explain CPU emulation?
Q.4.1 CPU emulation sounds VERY complicated, how should I START?
Q.4.1.1 Is the 68k series of processors 'easy' to emulate on PCs?
Q.4.1.2 Why were only a handful of processors used in arcade games?
Q.4.2 Should I use CPU emulation code that is freely available?
Q.4.3 How do the CPU and ROMs interact?
Q.4.4 How should I handle CPU opcodes?
Q.4.5 What is Pokey?
Q.4.6 What is Slapstic?
Q.4.7 What about translation?
Q.4.8 Is there anything else I should know about CPU emulation?
Q.5 How useful are the switch settings and pinouts?
Q.6 How do I produce a memory map?
Q.7 How can I find what processor(s) the game uses?
Q.7.1 Where can I find information for a specific processor?
Q.8 Where might I find the ROMs?
Q.8.1 How do I disassemble the ROMs?
Q.8.2 How do I decode data from the ROMs?
Q.9 Should the sound be emulated or should samples be used?
Q.9.1 What about legal issues? Are samples copyrighted?
Q.9.2 What is the difference between a speech synthesizer and a
sample playback device?
Q.9.3 What was used in Williams Arcade Classics? (It sounds good!)
Q.9.4 Why is sound so *hard* to emulate?
Q.10 Where can I find other documentation for the game?
Q.10.1 What about schematics for the game?
Q.11 How might I contact someone who owns the machine hardware?
Q.11.1 Todd Krueger's offer to help
Q.12 Where can I find general descriptions of arcade games?
Q.13 Did other emulator authors keep any notes while they were working?
Q.14 Where can I find more information on the internet and WWW?
Q.15 Should I release my source code when I'm finished?
Memory Maps
-----------
* M.1 Crazy Climber
* M.1.1 Video
* M.1.2 Sound
* M.1.3 Other Details
* M.1.4 Memory Map
M.2 Dig Dug
M.2.1 Memory Map
M.3 Ms. PacMan / PacMan
M.3.1 ROM Files
M.3.2 Memory Layout
M.3.3 Memory Mapped Ports
M.3.4 OUT ports
M.3.5 Character Sets
M.3.5.1 Pascal Source (ZIPed an UUencoded)
M.3.6 Ms. PacMan ROMs are identical to PacMan?
M.4 Phoenix
M.4.1 Components
M.4.2 Functionality
M.4.3 Colors
M.4.4 Memory Map
* M.5 Sega System 16 Games
M.5.1 Hardware Information
* M.5.2 Memory Map
M.5.3 Scroll Video RAM
M.5.4 Fixed Video RAM
M.5.5 Color Video RAM
M.5.6 Main RAM
M.5.7 Video Registers
* M.5.8 I/O Registers
M.5.9 ROM Files
M.5.10 Graphics Formats
* M.5.11 Sega GFX Viewer V1.0 Source Code (ZIPed an UUencoded)
M.6 Sega Vector (Converta) Games
M.6.1 Components
M.6.2 Memory Map
M.6.3 I/O Inputs
M.6.4 I/O Outputs
M.6.5 Vector Processor
M.7 Space Invaders
M.7.1 Board Spec
M.7.2 Memory Map
Graphics Hacking
----------------
G.1 Who wrote this section?
G.2 Introduction
G.3 Location of Graphics in Specific Game ROMs
G.4 General Information
G.4.1 Pixel Layout
G.5 Notes and Requests
G.6 Mode Q (256x256x256) Source Code (ZIPed an UUencoded)
Pokey
-----
P.1 Who wrote this description?
P.2 You mean Pokey isn't just that guy that hangs around with Gumby?
P.3 Where did they come up with a name like Pokey?
P.4 General Description
P.5 Technical Description
P.5.1 Pin-outs
P.5.2 Address Lines
P.6 Where can I find source code and more info. for Pokey emulation?
P.7 Finding and using *real* Pokeys
AY-3-8910
---------
A.1 Who wrote this description?
A.2 Introduction and Disclaimer From Original Document
A.3 Technical Information
Game Bits
---------
B.1 What is this section about anyway?
* B.2 Commando [provided by edoardo (gambare@iol.it)]
B.3 Crazy Climber [provided by Vince Mayo (14u2c@diamond.nb.net)]
* B.3.1 Decrypting the ROMs by Lionel Theunissen (lionelth@ozemail.com.au)
B.4 Crush Roller [provided by Vince Mayo (14u2c@diamond.nb.net)]
B.5 Gyruss [provided by Mike Cuddy <mcuddy@scitexdv.com>]
* B.6 I, Robot [provided by John Manfreda (jmanfred@fh.us.bosch.com)]
B.7 Juno First [provided by Mike Perry (mj-perry@uiuc.edu)]
* B.8 Penia [provided by Perry McFarlane (ce596@torfree.net)]
* B.9 Space Invaders [provided by John Manfreda (jmanfred@fh.us.bosch.com)]
B.10 Star Wars [provided by Peter McDermott]
B.11 Tapper [provided by Clay Cowgill (clay@supra.com)]
* B.12 Toki [provided by David Winter (winter@worldnet.net)]
B.13 Turbo [provided by Patrick J. O'Reilly (oreillyp@execpc.com)]
* B.14 Tutankham [provided by Moose O' Malley (moose@rocknet.net.au)]
Step-by-Step
------------
S.1 Step-by-step implementation of an emulator for Phoenix
S.1.1 Part I: Pre-coding
S.1.2 Part II: Low/High Endian
S.1.3 Part III: Let's start coding!
S.1.4 Part IV: Run it!
S.1.5 Part V: To be continued...
* S.2 Step-by-step discussion of an emulator for Space Invaders
* S.2.1 My Background
* S.2.2 Getting started
* S.2.3 Disassemblers
* S.2.4 Space Invaders Specifics
References
----------
* R.1 List of Emulator Authors
R.2 List of Currently Emulated Games
R.3 List of Games People Want to See Emulated
R.4 Internet Resources
R.4.1 WWW Resources
R.4.1.1 General Arcade Emulation Links
R.4.1.2 ROM Images
R.4.1.3 Processor Information
R.4.1.4 Schematics
R.4.1.5 Miscellaneous Information
R.4.2 FTP Resources
R.4.3 FSP Resources
R.5 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 (suzanne@crysalis.com)
- Neil Bradley (neil@synthcom.com)
- Don Carmical (dcarmical@tri-lakes.net)
- Clay Cowgill (clay@supra.com)
- Mike Cuddy (mcuddy@scitexdv.com)
- Jim Dankiewicz (james.dankiewicz@resnet.ucsb.edu)
- Laurent Desnogues (desnogue@aiguemarine.unice.fr)
- Bryan Edewaard
- Chris Hardy (chrish@kcbbs.gen.nz)
- Ed Henciak (ethst3@pitt.edu)
- Joe Husosky (scubajoe@ix.netcom.com)
- Paul Kahler (phkahler@oakland.edu)
- Ralph Kimmlingen (ub2f@rz.uni-karlsruhe.de)
- Thierry Lescot (ShinobiZ@mygale.org)
- Moose O' Malley (moose@rocknet.net.au)
- Alan J McCormick (gonzothegreat@juno.com)
- Ivan Mackintosh (ivan@rcp.co.uk)
- Vince Mayo (14u2c@diamond.nb.net)
- Phil Morris (pmorrisb@cix.compulink.co.uk)
- Brian Peek (peekb@union.edu)
- Mike Perry (mj-perry@uiuc.edu)
- RisqMan (RisqMan@aol.com)
- Pete Rittwage (bushwick@ix.netcom.com)
- Adam Roach (adam.roach@exu.ericsson.se)
- Joel Rosenzweig (joelr@an.hp.com)
- Trevor Song (Sharrier@hotmail.com)
- Gary Shepherdson (od67@dial.pipex.com)
- Dave Spicer (emuchat@hubcap.demon.co.uk)
- Brad Thomas (bradt@nol.net)
- Allard van der Bas (avdbas@wi.leidenuniv.nl)
- Nemoto Yohei (BYY03025@niftyserve.or.jp)
- 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 *most* of this
document using DOS's edit in a DOSemu window under Linux X!!
-------------------------------------------------------------
8 8 8 Yb dP w 8
8www8 .d88b 8 88b. Yb db dP .d88 8d8b. w8ww .d88b .d88
8 8 8.dP' 8 8 8 YbdPYbdP 8 8 8P Y8 8 8.dP' 8 8
8 8 `Y88P 8 88P' YP YP `Y88 8 8 Y8P `Y88P `Y88
8
-------------------------------------------------------------
Phil Morris brought an issue to my attention, and I decided to add
this section.
There are many arcade emulation projects in progress now. As far as I
know, no emulator author is doing this full-time. In other words,
it's a hobby, done in their spare time (They have *real* lives!).
However, it seems that some emulation projects may have become 'stalled'.
For some, new versions have not been released for a month or so.
This is a plea to emulator authors whose projects may be stalled:
Would it be possible to make your source code available?
This is for two reasons:
a) If you are tired/unable to do more work on your emulator(s), it
would be a shame to see your hard work wasted. If you're not going to
work on the emulations any more it would be great if someone else
could pick up where you left off and implement things you've so far
missed, such as sound, accurate colours, etc.
b) One day the big companies may take legal action against all the
emulator coders (I doubt it very much, but you never know) - if the
source code for the emulators is in the public domain then at least it
won't be forever lost.
-------------------------------------
.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?
At the present time, there is very little documentation freely available.
Phoenix, Sega (Converta) vector games, and Space Invaders are described
in sections M.1, M.2, and M.3 (Memory Maps) of this document. You may also
want to check section R.4 (References). If anyone can provide information
on other games, I'll be happy to add it to this HowTo!
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.
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
you out. Pascal is dead as a new development language, except maybe for
hobbyists, though I must admit Borland did a pretty damn good job of
making Turbo Pascal a viable entity. With all of their extensions and
nicities, it rivals C in its functionality. The same holds true for Visual
Basic. It's not really BASIC in the literal sense anymore - it's a C-like
language. The other reason is that about 95% of the CPU emulators I've
found are written in C. I think I found 1 that was written in Pascal.
[If you decide to use C++] you'll never make it on anything less
than a Penitum Pro 200. CPU emulation is very time consuming, and even
a single instruction or two can kill processor performance. To give you
an idea, my original 6502 emulator ran at 1.2MHZ when written in
optimized C (not C++). That was on a Pentium 120, and I'm no slouch
when it comes to optimizing. I rewrote my 6502 emulator in 32 bit
assembly and it's running at 15MHZ. Compilers are still no match for
a seasoned assembly programmer. Add in the extra overhead [of C++], and
you're toast. You'll never get good performance out of OO CPU emulation
code... Add in big-time overhead for class alignment [and the] CPU
emulator will be HORRIBLY slow... This is a really bad place to use C++.
C++ has its place in UI and API abstraction, but when you're talking
performance it's a *BAD* idea... Not to be too frank, but writing
something like a CPU emulator in C++ would be considered shitty
programming practice. ;-) If you'll notice, all well-performed emulators
are written in assembly - at least as far as the CPU emulation goes."
Mike Perry adds:
"I can tell you now that you do NOT want to use Delphi. Delphi is for
rapid prototyping and for developing graphical applications. An emulator
is not an application that is suited for development in Delphi.
Additionally, Delphi applications are only usable in Win95 and NT.
DOS, being a single user, single-tasking OS, is more likely to bring
better performance. [Using] Pascal is a possibility but Borland Pascal
has serious limitations in terms of efficiency. For instance, someone
was handling opcodes using a case statement
case op1: blah blah blah; return;
case op2: blah blah blah; return;
case op3: blah.....; return;
....
Now any reasonable C compiler, including Borland C++, converts this to
a jump table (ie, code array) for fast case determination. BPascal
on the other hands generates a series of mov, cmp (compare) and jmp
instructions, like a big if-else. This means that opcode 212 will
take around (212 * 4) cycles just to GET to the code using BPascal
while it takes less than 6 cycles using C!! Even if you DO use C,
your task is made MUCH easier using inline assembly. Better yet,
make assembly the main language and link in external C or pascal
function if necessary. The graphics routines should DEFINITELY
be in assembly. [You] WILL be better off learning [assembly]."
Dave Spicer warns:
"IMHO, writing an emulator in Pascal is not a particulatly good idea.
You'll be emulating machine code, so you want something that resembles
that in form."
Q.3.1 Do I *have* to use Assembly?
Neil Bradley says:
"Regardless of what some academics would like to believe, a compiler
can't outclass a good assembly programmer. You'll spend plenty of time
optimizing, and if you rewrote it in assembly, you're almost assuredly
going to get a 30-40% speed improvement. C compilers (and others for
that matter) solve for the general case, and make assumptions on what
registers/variables need to be saved. In assembly, you know the code,
and can write, at the CPU level, and write the most optimal instruction
sequence to match the common-case path of your code.
You really do need to know assembly to do a project like this - that is
to do it in an effective amount of time."
Mike Perry says:
"Normally I would not recommend writing an application primarily or
entirely in assembly. Assembly is minimally portable and if an
application spends 90% of its time executing 5% of its code, it does
precious little good to hand optimize the remaining 95% in assembly.
An emulator, on the other hand, is not your normal application. An
emulator's job is to emulate hardware. In emulation, you will be dealing
with registers, memory addressing and memory reads/writes. The
instructions the real processors use to do this sort of stuff are very
"basic". They are so basic that its actually easier to use x86 asm and
the intel registers to do what you want than it is to use a high level
language. Assembly makes it easy to manipulate 8-bit, 16-bit and 32-bit
values. C and Pascal make it downright tedious to manipulate more than
one size variable in an expression. At the least, your HLL code will
contain many many typecasts, making it very hard to read."
Q.3.1.1 Are you SURE about this Assembly business? :)
Paul Kahler points out:
"A number of people indicated that assembly is the only way to get good
performance on anything short of a pentium pro. I'd just like to say that
the first rev of the Cinematronics emulator was written in TURBO PASCAL
and seemed to run just fine on a Pentium-90. That was almost 2 years ago,
so we were trying to run on a 486 and had to move on to assembly. TP
allowed me to create an array of functions so I could grab the opcode and
call the proper function. That's really good performance considering the
CineProcessor doesn't map at all to x86 or anything else, and it ran at
1.7 MIPS! A 6502 should be no problem for C code on a Pentium or even a
486. But then there's graphics and sound also... I just wanted to point
out that ASM isn't the only way to go, and if you do things in C they'll
be portable. BTW I used the BGI drivers for the vector display back then
too!"
Pete Rittwage adds:
"I've been able to get stellar performance out of my 6502 purely in C,
including graphics overhead, even on my lowly 486/100.
I've also seen people get pretty good performance out of Marat's Z80 code
in such things as the Donkey Kong emulators, and that code is FAR from
optimized. It accesses things a couple of structures deep at times, which
is very inefficient."
Q.3.1.2 Doesn't the choice of language depend on the target game/system?
Neil Bradley clears things up:
"Writing an emulator strictly in C++, including CPU emulation and graphics
emulation will not give you good performance on anything short of a
pentium pro. The author of the Tempest emulator that runs under Windows
runs fine at 150MHZ, and it's written in C. If that's your target
platform, great. And if your target platform is a 486/66 and your graphics
are heavily intensive or running on a slow ISA card, you better not use C
or C++. To give you some benchmarks on some "famous" CPU emulators, here
are some #'s (not including graphics - just RAW CPU time) that indicate
the emulated speed on a 486/66 running Asteroids, compiled under Watcom
C++ 10.6 with the 486 compile option thrown:
Emulator Emulated speed
Marat's 6502 1.6MHZ
Apple IIe emu 800KHZ
Optimized Apple IIe emu 1.9MHZ
EMU's first 6502 C emulator 2.5MHZ
EMU's 100% Assembly 6502 6.8MHZ
My background is assembly & C optimization. I've spent greater than 20
years on numerous processors, and have programmed everything from tiny
microcontroller circuits to multi-CPU applications, so I'm no slouch when
it comes to C or assembly optimization. ;-) . The results above speak for
themselves. Keep in mind that there aren't any graphics routines or sound
routines in this code under this test.
So I'll reiterate what I've tried to say in the past: If your target
machine is a 486/66 with a crappy ISA card, you'd better squeeze
everything out of the emulator that you possibly can, because you'll need
it. EMU Uses a single page of 256 color graphics. It erases the prior
frame and draws the new one. Typical frames are 300 vectors. 600 Lines per
"frame", and roughly 25 frames per second. That's 15000 lines per second
that must be drawn, and if we say that the average line is 50 pixels,
that's 750,000 pixels a second.
Most games, such as Donkey Kong or Space Invaders aren't coming even close
to moving that many pixels on the screen. So in that case, you can get
away with having a less than totally optimized CPU. But with EMU, I
couldn't get away with it. There was too much to do. Linedraws are
extremely expensive, and I spent days working on high speed linedraw
routines (those of you who've been with EMU since the early days know what
I'm talking about).
The point I'm trying to make is that the more you optimize your CPU
emulation, the less of an impact it will have on your graphics emulation,
and the faster your code will run on a slower machine. If you want to make
your minimum platform a Pentium 166, you can probably get away with
writing it in Quick Basic.
I want as little intrusion from the CPU emulation as I possibly can get,
and I got better emulation by almost a factor of 3 by rewriting it in
assembly.
I don't think anyone said that ASM was the only way to go. I remember
saying that it is the most optimal way to go."
Laurent Desnogues says:
"I got a two times speed-up when converting a 6809 emulator written in C
to SPARC assembly language.
So I'm one of the exceptions... I wrote a Phoenix emulator that should
run on any Unix/X platform (one or eight graphics planes); it uses Marat's
Z80 emulator package and I get decent speed even on low end Suns. The
problem with Unix is that most of its implementations can not handle
real-time programs; the game often freezes while the kernel is doing
internal jobs... So I have to admit these platforms are not very well
suited to arcade game playing; but programming an emulator is by itself
enjoing, isn't it?"
Q.3.1.3 What about portability?
Neil Bradley answers:
"Just because you do things in C doesn't mean they're portable. There
are basically two platforms that need any attention for gaming: PC & Mac.
That's it. I don't know of anyone owning a Silicon Graphics workstation
saying to themselves, "Gee, wouldn't it be cool to fire up an emulated
version of Space Invaders on this thing?". The people I know who own
SparcStations or run Unix aren't interested in emulation or gaming in
general. Granted there are exceptions to that rule, but for the most part
the "other" platforms aren't really in the running.
But if I'm forced into a corner where I can get 3X performance out of
something by coding it in assembly for a platform I know, I'll do it and
blow off "portability". At the same time, as I've said before, I'd gladly
help out others on other platforms, giving them hints and helping them
with their emulation projects that are for a platform that I'm not
familiar with.
Besides, most code written to be "portable" isn't. It starts off that way,
but ends up using OS specific calls to improve speed, etc... The road to
non-portable code is paved with portability in mind. ;-) BTW, I run Unix
on synthcom, Win 95 on my sequencer/sound studio, Windows NT 4.0 Server on
one of my development machines, and DOS on the other. Guess which one I
use for games..."
Q.3.2 But haven't some arcade emulators been written in C/C++?
According to what I've heard, C and C++ have been *used* in some
emulators, but an entire emulator has not been written in only C or C++.
Neil Bradley says:
"Name one emulator that was written in C++ that runs reasonably on
anything less than a Pentium Pro 200. ;-) I don't know of an emulator that
is ENTIRELY written in C. EMU, for example, is written in C and assembly.
C for all the glue code and non-speed critical things, and assembly for
everything else. That's why it runs reasonably on a 486/66 with a decent
PCI video card.
[Chris Hardy's Phoenix emulator was coded in VC++ using Direct/X...
Note that it was written in C (not C++!) and compiled on VC++]
Not to lessen anything that Chris has done, but Phoenix isn't exactly a
CPU hogging game, as is something like Tempest, Battle Zone, or Red Baron.
The vector emulation is very time consuming, and even the originals slow
down in spots."
Q.3.3 What about Java?
Neil Bradley, after cringing in terror, says:
"The only way that you'd even have a prayer to get something to run fairly
quickly in Java is to make sure the client compiles it for their native
CPU (Visual J++, anyone?). In the case where you write an emulator in
Java, and it runs on a browser, you'd have an interpreter interpreting an
interpreter of a CPU in addition to the interpreter interpreting the
hardware actions as well. Interpreted Java is not built for speed.
The guys at Microsoft are getting almost identical performance out of
Visual J++ as the Visual C++ guys are (according to a Java proponent at
the last PDC), so compiled Java apps are a possibility.
It's hard enough getting optimal assembly emulations to run at full tilt
on a 486/66 without having an interpreter interpreting the emulator. Your
hit by doing that would be about 30:1.
If we had 2 Gigahertz Pentium PROs, it might be possible, but not with the
speed of the Java virtual machine interpreter. Don't bother unless you're
compiling it. You might have a chance then, but interpreted, no way. I
wouldn't bother trying it. ;-)"
Q.4 Could you explain CPU emulation?
The CPU emulation is the heart of any emulator. If the code is correct,
it will handle the ROM data, so you don't necessarily have to worry about
how the game ROM itself operates.
Since the CPU is the 'brains' of the machine, it can get very complicated.
Neil Bradley had this to say:
"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
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 emulator@synthcom.com
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, speed, etc.
I believe that Atari named this chip a speech synthesizer because they
used the word 'synthesizer' loosely, to mean 'speech production' which is
what it does. Though, its not strictly limited to speech as they could
have put any sounds in memory that they wanted to."
Q.9.3 What was used in Williams Arcade Classics? (It sounds good!)
Neil Bradley answers:
"All of the WA classics are *SAMPLES*. Even the original sounds that go
into the sound roms for Joust, Robotron, etc... are samples of
synthesizers. They are mixed off line, and played back real-time."
Joe Husosky says:
"To recreate the sound they hooked up the sound board and instructed it to
play each sound the game has one at a time. The really cool thing about
the WIN95 WAC (DOS version also included) is that they have all the sounds
included as WAV files. You can really customise WIN95 with all the WAC
sounds."
Q.9.4 Why is sound so *hard* to emulate?
Neil Bradley complains:
"I've been asked multiple times why I don't 'just add sound'.
Well, the lousy sound cards we've been cursed with have different
structures from almost every other form of synthesis known to man. I'm
talking filtering, pitch, etc...
Sorry to say it, but not even the most expensive Sound Cards are high
quality. They are cheap, piles of garbage. Compared to their big brother
counterparts (I.E. the digital or analog synthesizer), they are noisy,
brash, cranky, and of such low quality it's amazing they work at all. Just
so you all know, my reference equipment consists of racks of synthesizers,
and compared to them, no sound card is even moderately close to their
quality.
So partly the reason I don't bother with sound is that the quality is so
poor. It's better than a PC speaker, and it gives SOME sound, but saying
that it has synthesis capabilities is like saying a Moped is well suited
for transportation in all weather conditions.
For specifics: The Pokey. The only proper way to emulate this chip is to
sample it. FM Syntehsis doesn't sound like top octave divided square
waves. FM Sounds thin by comparison. So if you want the character of the
Pokey, you sample it. This is called true emulation. Anything else is an
imitation. Lots of circuits have bass boost and image enhancers to get
their "sound", and without sampling the real thing, you're going to get
thin & cheesy sounds in a lot of cases.
There aren't enough oscillators on all sound cards to emulate a 2-4 Pokey
configuration, either. So what do you do? Sounds like a mixed sample
playback is the correct thing. That means you'd better have damned
efficient mixing code! I keep telling people over and over that if you
want good performance on a particular low-end platform, machine code the
thing! I've seen mixing code speed up 4X after being recoded in assembly.
It doesn't make much difference on a Pentium 166, but the 486 users will
really appreciate it.
Okay, now that we've all decided that sampling is the way to go for Pokey
emulation, let's consider a few things. First, you need to have access to
the game. Second, you need to get every sound that a game will make
sampled. In most cases, getting all these sounds seperately isn't
possible (I.E. Battlezone's engine noise & firing sounds). Lastly, once
you have each individual sample, you need to reverse engineer the
commands to the Pokey that would cause that sound to occur, and more
importantly, when it should stop.
These aren't straightforward steps. Getting a correct sample (and I don't
mean sampling it with a $20 Radio Shack mic and a Sound Blaster) is hard
work. You'd spend hours getting a good, high quality sample, necessary
for true emulation.
In a lot of cases, there aren't enough oscillators or waveforms to choose
from when emulating other sound chips. The envlope types don't match,
Sound Blasters lack resonant filters or other filter modes, and waveforms
don't match up to the ones availale on the game to be emulated. So what do
you do? Sampling is the answer. This means that the CPU spends time mixing
sounds, which makes the game slower. Recoding in assembly (hint hint) is
a good way to maximize your performance. ;-)
In most cases, sound chips used in video games don't have primitives that
match up to the primitives that your average sound card has, so using the
synthesis part of the card to emulate the sound is in a lot of cases a
lost cause.
So the lack of sound emulation in all kinds of emulators should tell you
something. ;-) The sound architecture in sound cards is almost completely
different from that of your favorite video game, and emulation is a
collosal pain in the ass, if not impossible, to pull off.
So have some mercy on us emulator authors, will ya? ;-)"
Q.10 Where can I find other documentation for the game?
You might try to contact someone who owns the machine. See Q.10.
Q.10.1 What about schematics for the game?
You might try to contact someone who owns the machine. See Q.10.
Also, see R.4.1.4 under References for some schematics available on
the web.
Q.11 How might I contact someone who owns the machine hardware?
The Video Arcade Preservation Society (VAPS) maintains a list of
people who own arcade games. These folks might have technical
documents that came with the machines. They may also be able to dump
ROMs if they are not already available on the internet. If you ask
nicely, you might be able to find what you are looking for...
See section R.4.1.5 for information about VAPS on the WWW.
Q.11.1 Todd Krueger's offer to help
This message was sent to the emulator mailing list by Todd Krueger
[ToddK52685@aol.com] :
[I've taken some parts out of it that do not relate to arcade emulation...]
"To all it may concern,
My name is Todd Krueger. I have been (for many years now) a video game
collector. At first I started with the likes of the original Atari
machines then it followed with the Nintendos, Turbo Grafixs ect. Then my
collection continued to include arcade machines starting with Golden Axe
then back to Space Invaders then Pacman and so on. To date, my collection
includes 200+ arcade titles (Some with books and docs some without) and
near every home video game machine released. (Alot were donated) My
intention of this is to start a museum in Las Cruces, NM.
My collection started as a hobby and now is an honest attempt to save
this important part of history. I believe that emulation is an important
part of this preservation. So I would like to be a source for emulator
programers. I can provide photos, sounds, some schematics or the loan of
the original boards (on a case by case basis). All I ask in return is to
be a beta tester.
Some of the popular titles in the collection are: Space Invaders
(original b/w, part II b/w & color), Galaga (original and plus),
Pacman (orig., MS. & super), Gauntlet, Dig Dug, Bubble Bobble,
Asteroids (orig. & deluxe), Tempest, Battlezone, Arkanoid
(orig. and Revenge of Doh), Ikari Warriors, Contra, Donkey Kong
(1, 3, and junior), Frogger, 1942, Berzerk, Star Wars (orig. and Empire),
Defender, Golden Axe, Street Fighter II, Mortal Kombat (orig. and II),
Time Pilot 84, Time Soldiers, Mr. Do, Galaxian, Block Out, Shinobi,
Altered Beasts, and many others (new titles in all the time).
Some of the systems are: Atari (400, 800, 520ST, 1040ST, Jaguar), Coleco,
Sega (master, Genisis, CD, 32X, 32X CD, Saturn), Turbo Grafx, Nintendo
(8-bit, Super, Pocket, Super Gameboy, N64, Virtual), 3DO, Playstation,
Vectrex, Amiga, TI 99/4, and many others. Many references.
I will give any help I can in your programming endeavors and I promice I
will not use any of your products or betas for personal profit nor would
I even show your products to anyone without your permission. I further
promise to be an honest and good beta tester if you choose to use me.
Also, if you or anyone you know has old video game equipment that they
would like to donate to our Video Game Museum project (We need name
suggestions) you may do so to:
Mission Computer Enterprises
c/o Todd Krueger
412 LaCrosse St.
W.S.M.R., NM 88002
This address is temporary because the store is not fully open and I am
still in the midst of my Army Retirement, but this should be good for a
couple of months. Just in case, before you do or send anything, email me
at ToddK52685@aol.com
Todd H. Krueger"
[Sounds like a damn good deal to me!!]
Q.12 Where can I find general descriptions of arcade games?
The VAPS (see Q.10) also maintains a searchable database containing
information about virtually every arcade game ever made. Most entries
include the company resposible, the year released, and a brief
description of gameplay. The database is the KLOV (Killer List Of
Video games). The search engine can be found as a link off the main
VAPS site.
Q.13 Did other emulator authors keep any notes while they were working?
In Neil Bradley's case:
"Mental notes. Sometimes printouts of my code when I knew it was buggy.
Sometimes I collected info about the game platform in stacks of paper for
reference, but nothing proprietary or non-commonly available material was
kept (at least in my case)."
Dave Spicer's experience:
"Yup, I have about 10 notebooks full of scribbles. Usually my notes
consist of rom locations and register lists with occasional outlines of
various techniques for implementing a game's hardware. Lately I've tried
to get into the habit of documentating hardware within the driver source
code."
[When asked if he wrote detailed specifications for each game...]
"Not for individual emulations, no. It's usually impossible as I'm finding
out how a game works, and what's required, whilst I'm writing the
emulation. You can't spec something that you don't fully understand!
Emulator core resources are another matter. Before adding anything to the
emulator core (something I haven't had to do for months now), I write
documentation covering what's required and how the programming interface
will work."
Q.14 Where can I find more information on the internet and WWW?
See section R.4 under References.
Also, Neil Bradley suggests:
"Do an infoseek search on '+cpu +emulator'. There is a page that has
emulators, and many, many other links that will give you more than you
asked for. ;-)"
Q.15 Should I release my source code when I'm finished?
By all means YES!! :D
It's really up to each individual author. Some people (I won't name names)
have chose to keep their emulators from the public, with thoughts of a
commercial release. Others have released their emulators as freeware.
Still others plan to release the source code with their freeware
emulators. I, personally, think that emulation is a hobby to be shared
with the rest of the world...
Mike Cuddy says:
"I plan on releasing every scrap of code, documentation, etc. when I'm
done. Making emulators is hard-enough without charging people money, or
hoarding information (dig, dig ... you know who you are ;-) -- besides,
given the quasi-legal status of most of the ROM images, it's hard to
justify charging people -- I'd rather have more emulators floating around!
And like I said, when this ordeal is done, the release will be a SOURCE
release."
--------------------------------------------------------------------
8b d8 8b d8
8YbmdP8 .d88b 8d8b.d8b. .d8b. 8d8b Yb dP 8YbmdP8 .d88 88b. d88b
8 " 8 8.dP' 8P Y8P Y8 8' .8 8P YbdP 8 " 8 8 8 8 8 `Yb.
8 8 `Y88P 8 8 8 `Y8P' 8 dP 8 8 `Y88 88P' Y88P
dP 8
--------------------------------------------------------------------
M.1 Crazy Climber
CRAZY CLIMBER HARDWARE DETAILS AND MEMORY MAP
by Lionel Theunissen (08/01/97)
Please don't take any of this information as gospel. This is what I have
gleaned from my analysis of the CC ROMs and circuits, and I could be
wrong about a few things. Some of it is best guess, but most of it
should be correct. Bear in mind that it was quite a while ago (3 years)
that I was originally working on this, so coming back into it I'm a
little fuzzy on details.
M.1.1 Video
The video circuitry for Crazy Climber is similar to other early 80's
games, but has some unique features. The display is character generated,
32 characters across and 28 high, which makes 256*224 pixels. The 1k of
screen RAM addresses the character ROMs (ROMs 3-6); a pair for each
character set, which give two bits per pixel, and along with the colour
RAM, determine the colour for each pixel. Each vertical character column
(32 in all) can be scrolled independantly using the column scroll
registers at 9800h. Note that unlike most other games of the time CC
uses a horizontally oriented picture tube (as in a VGA monitor), rather
than the vertically oriented tube as used in Pacman, Galaxians, and
Space Invaders.
As in most character generated displays of the time, the colour of each
pixel is determined by a combination of the lower 4 bits of the colour
RAM and the two bits per pixel from the character generator ROMS. Bit 4
of the colour RAM selects between two character sets.
An unusual feature of the display circuitry is what I call the Big (or
main) sprite. There are 256 bytes of RAM at 8800h which are attached to
their own character generator ROMs (ROMs 1&2). This can be moved as one
big block using the control registers at 98dch-98dfh. This sprite is
used for the logo in the opening screen, the bird, and other large
objects in the game.
I have yet to work out much of the detail regarding the small sprites,
but they seem to be similar to pacman/galaxian. Anyone who would like to
help out with this please contact me (I have limited time at the
moment.)
M.1.2 Sound
Crazy Climber uses an AY-3-8910 addressed at I/O 8&9 for music, and has
a sample playback system for other sounds controlled by the two ports on
the AY-3-8910 and registers at a004h, a800h, and b000h. ROMs 12&13
contain the sample data. From the circuit it appears that the sample
information is 4 bit with two 4 bit nybbles per byte of ROM which are
read sequentially. I haven't confirmed this though.
M.1.3 Other Details
There is a watchdog circuit which will reset the processor if the
machine switches (coin, player start, etc) at b800h are not read for a
certain period of time. This ensures that if the program crashes due to
a power glitch or whatever, the program will reset. There is little
point in emulating this.
M.1.4 Memory Map
Note that the address decoder on CC only decodes to 2k blocks, therefore
1k of RAM at 9800h will also appear at 9c00h. In places the software
will write to a mirror address; Eg. the Colour RAM is addressed at 9c00h
and the column scroll registers at 9800h. These are actually both part
of the same 1k RAM on the CC boards. The column scroll registers take up
the first 32 bytes of the colour RAM. Since these bytes correspond to an
area of the screen which is not displayed they can be used for this
purpose.
0000h-4fffh ;20k program ROMs. ROM11=0000h
ROM10=1000h
ROM09=2000h
ROM08=3000h
ROM07=4000h
8000h-83ffh ;1k scratchpad RAM.
8800h-87ffh ;256 bytes Bigsprite RAM.
9000h-93ffh ;1k screen RAM.
9800h-981fh ;Column smooth scroll position. Corresponds to each char
column. *This is actually part of the colour RAM.
98dch ;big sprite control.
98ddh ;big sprite colour.
98deh ;big sprite y position.
98dfh ;big sprite x position.
9c00h-9fffh ;1k Colour RAM: Bits 0-3: char colour scheme.
Bit 4: 0=charset1, 1=charset2.
0a000h ;RD: player 1 cntl. WR: NMI: 0=disable, 1=enable.
0a001h ;WR: Video horizontal invert.
0a002h ;WR: Video vertical invert
0a004h ;WR: dig sound trigger?
0a800h ;RD: player 2 cntl. WR: dig sound speed?
0b000h ;RD: dip switches. WR: dig sound volume?
0b800h ;RD: machine switches/watchdog.
I/O 8 ;AY-3-8910 Reg?
I/O 9 ;AY-3-8910 Reg?
*If anyone can help fill in some of the blanks or has corrections please
email me.
Lionel Theunissen (lionelth@ozemail.com.au)
M.2 Dig Dug [provided by Ivan Mackintosh (ivan@rcp.co.uk)]
M.2.1 Memory Map
Taken from the "Dig Dug CPU PCB Schematic Diagram" - Sheet 3a
HEXA- R/W DATA FUNCTION
DECIMAL
ADDRESS D7 D6 D5 D4 D3 D2 D1 D0
0000-3FFF R D D D D D D D D 1st Priority Z80 CPU ROM (16K)
0000-1FFF R D D D D D D D D 2nd Priority Z80 CPU ROM (8K)
0000-0FFF R D D D D D D D D 3rd Priority Z80 CPU ROM (4K)
6800-680F W D D D D Audio Control
6810-681F W D D D D Audio Control
6820 W D 0 =3D Reset IRQ1 (Latched)
6821 W D 0 =3D Reset IRQ2 (Latched)
6822 W D 0 =3D Enable NMI3 (Latched)
6823 W D 0 =3D Reset 2nd and 3rd Z80 CPUs
(Latched)
6825 W D Custom Chip 53 Mode Control
(Latched)
6826 W D Custom Chip 53 Mode Control
(Latched)
6827 W D Custom Chip 53 Mode Control
(Latched)
6830 W Watchdog Reset
7000 R/W D D D D D D D D Custom Chip 06 - Data
7100 R/W D D D D D D D D Custom Chip 06 - Command
8000-87FF R/W D D D D D D D D 2K Playfield RAM
8800-8BFF R/W D D D D D D D D 1K Motion RAM (HPOS, VPOS)
9000-93FF R/W D D D D D D D D 1K Motion RAM
9800-9BFF R/W D D D D D D D D 1K Motion RAM (PIC)
A000 W D Playfield Select (Latched)
A001 W D Playfield Select (Latched)
A002 W D Playfield Color Select (Latched)
A003 W D Alphanumeric Color Select
(Latched)
A004 W D Playfield Select (Latched)
A005 W D Playfield Select (Latched)
A007 W D Flip Video
B800-B83F W D D D D D D D D Write EAROM Address and Data
B800 R D D D D D D D D Read EAROM Data
B840 W D D D D Write EAROM Control
M.3 Ms PacMan [provided by Allard van der Bas (avdbas@wi.leidenuniv.nl)]
I'm stuck at the moment, so it wouldn't hurt to get some feedback on what
I found out so far. The information holds for mspacman (non bootleg
version, the bootleg version is only different in how it processes it's
interrupt).
[Note: This information also applies to PacMan. See section M.2.6]
M.3.1 ROM Files
name type location
--------------------------------------
mspacman.6e code $0000-$0fff
mspacman.6f code $1000-$1fff
mspacman.6h code $2000-$2fff
mspacman.6j code $3000-$3fff
mspacman.5e char non memory mapped (see pascal source)
mspacman.5f char ? non memory mapped (see pascal source)
mspacman.u5 ??? non memory mapped
mspacman.u6 ??? "" """ ""
mspacman.u7 ??? "" """ ""
M.3.2 Memory Layout
ROM $0000-$3fff code + data
RAM $4000-$43ff video 1 (filled with $40 means clear)
$4400-$47ff video 2 (filled with $0f means clear)
$4c00-$4fff general purpose RAM
M.3.3 Memory Mapped Ports
$5000-$5007,$5040,$5080,$50c0 ($5050-$505f).
$5080 : dipswitches ?
$50c0,$5040 : joystick / slots ?
$5000 - $5007 : timers (for interrupt) ?
$5050 - $505f : ??? <- referenced only once.
M.3.4 OUT ports
$00 : interrupt chooser
An OUT $FA at port 00 chooses interrupt routine at $3000.
This one is only activated once ($3000 has some sort of machine check).
An OUT $FC at port 00 chooses interrupt routine at $008d.
This is the general interrupt used throughout the game.
The bootleg version handles interrupts in a different way, (not IM2). But
accesses the same interrupt routines.
M.3.5 Character Sets
The chars are built up really weird, chars are encoded using 2 bits per
pixel, but chars are 8x8, so 1 char takes 16 bytes. The first 8 bytes are
the lower pixels and the second 8 bytes are the top pixels. Look at the
include pascal source to figure the chars out.
M.3.5.1 Pascal Source (ZIPed an UUencoded)
I've ZIPed and UUencoded two pascal source files Allard van der Bas sent
me. The information is much more compact in this form -- including the
full pascal source would have taken up too much space!
From the comments:
{ Used to find characters in rom files. Mspacman chars are really 2 bits
per color, but use only one color to detect shapes, Dumps both character
roms on a 320x200 screen }
And Allard said:
"The mode13h Unit isn't fast enough to support the screen updates needed
for decent emulation. (I got about 30 fps using predefined sprites on my
P120/Mach64; the overhead of the emulator will kill this to about 5 fps).
But you're free to do what ever you want with it. (Just loose the (c)
notice in mode13h.pas)."
Just cut and paste this UUencoded block to a new file and decode it.
If this is a problem, let me know and the source files can be distributed
with the HowTo as separate files...
begin 644 avdbas.zip
M4$L#!!0````(`,^^<B'<H%/0<P,``-X*```,````1DE.1$-(05(N4$%3[59=
M3]M*