This time we take a look at one
of the pioneers of Emulation itself, Neil Bradley. Neil
has achieved an incredible amount of goals in emulation and his contributions
are spreaded all over different emulators. Despite his vast experience and
amount of work on his back, he is a very friendly developer and has offered some of
his time to answer a few questions and talk to EmuViews about Emulation, and
the current projects he works on. Here are the Q's & A's.
|Neil Bradley, pioneer, InterViewed - June 15, '98 by JoseQ
1. First of all, can you introduce yourself to the readers? Including
previous works, your contributions to others projects, and your
current responsibilities in current projects.
Boy - OK - the old stuff first: I released an Asteroids emulator for the
PC in Sep '96. The only other freeware arcade emulator at the time that I
could find or knew about was Dave Spicer's Sparcade, which inspired me to
get into emulation. I started firstname.lastname@example.org, which was an arcade
emulator mailing list. After that I renamed it to EMU, and added a bunch
of new vector games (since I was a vector fanatic). Then came the deluge
of other emulators in the October timeframe, including Pengo and a few
others. It became sort of a bug, and everyone jumped on the bandwagon. ;-)
I've also helped other emulator authors out (countless at this point) in
their emulations, such as Chris Pile's Asteroids emulator and Peter
Hirschberg's most excellent Vector Dream emulator. I've helped various
MAME driver authors out in several situations, extensively in some cases
I currently have a 6502, 6808, and Z80 ASM based x86 emulator suite
available for use by anyone who wants it. Some emulators that use my
cores: Replay, Rockulator, Nofrendo (NES), Vector Dream, Shark,... Hm...
and a few others that I can't recall right now. There's even rumor that my
6808 core will make an appearance in MAME, to which it has my total
I'm also the head architect for Retrocade, the MAME-like emulator, that
focuses specifically on performance and ease of use. Though MAME and
Retrocade have similar functionality, our audiences are quite a bit
different and we really do serve two different purposes.
2. Can you tell us "relatively newbies" how different was the Emulation
World was back when you released "Asteroids Emulator" and tell us a little
That was a while ago. I had no one to talk to. I had no one to bounce
ideas off of. Basically, there *WAS* no arcade emulation scene then, with
the exception of Mr. Spicer's most excellent Sparcade. I saw his emulator
and said, "Hey! I can program! I can do that!". I actually started the
Asteroids Emulator right about the time I saw Sparcade, and in mid-Feb of
'96 I shelved it because I reached an impass with the digital vector
generator with scaling problems. I then talked with Al Kossow in late
August, and he provided the missing piece of the DVG I couldn't get
working, so I decided to pick the project back up and release the
3. In recent time, Emulation is a fashion, and something most programmers
find interesting and a challenge to do. Back then, what motivated you
to start emulating?
- I was reminded how much I loved video games and how just playing the
games again conjured up good memories
- It was a good chance for me to brush up on my reverse engineering skills
- I wanted to learn hardware a bit more indepth than I had in the past
- I wanted to interact with people in a company/product fashion - with a
product of my own design. It has taught me *TONS*.
4. You built the cores for the 6502, 6808, and Z80. What were the reasons
to emulate those chips? Are they used nowadays in games, or otherwise?
They're used in YESTERDAY'S games mostly. ;-) Occasionally you'll find a
more modern game (like the Shark emulator) that will have a 68000 CPU as a
main processor and a Z80 or 6502 as a slave processor. The 6808 was used
as a sound CPU for the Williams games. BTW, We've got a 6809 emulator core
we're getting some last minute bugs out of and will be releasing that,
too. I'm also eventually going to tackle writing a 68000 emulator in x86
asm, though that will be a while down the road. I've already got Neill
Corlett's Starscream core, which is great. I'd like to do it for the
challenge and to learn the 68000 a bit better.
5. Those cores are used inside many popular emulators, and serve as the
base for people to develop on them. Was that your idea behind releasing
the code? Has freely distributed code always been one of your rules of
Many emulator authors did have performance problems in some games. I
realized this and wanted a fast ASM core for myself, and I figured, "Why
not share?" So I did. I did a bit of selling, and several came to me for
I do not, however, believe in distributing completed works in source form,
especially when there's a warez market for it. The primary reason? Piracy.
I want to make it extremely difficult for custom CD makers to be able to
sell something that everyone can get for free. Don't laugh - IT HAS
HAPPENED on multiple occasions. I've been witness to two of them at a
local swap meet. Having the source available allows anyone to take out all
copyright notices and do whatever they please with it. Not having the
source available (and having internal tamper checks) can knock out most of
that. That's why I don't release a completed work, but I'm willing to let
people have my components or information.
6. Can you tell us about email@example.com? Goals then? Purposes now?
The original purpose was to get a group to together of people who were
interested in a common arcade emulation theme - developers and users
alike. There wasn't anything at the time. It was quite active in "the old
days". I eventually moved it off of Synthcom and Mike Cuddy (KEM author)
graciously offered to host it. Since around April/May of '97, the list
degenerated into a flame forum, and the signal/noise ratio became very
low. Late last year, the list died. The primary reason being that we now
have Dave's Classics and other sites to go to for our emulation fixes. An
email forum is no longer needed. Now all that happens is an occasional
announcement or a "Am I still subscribed?" message. ;-)
7. In your mind, do you think Emulation is going in the right path? If
not, what would you think should be happening that isnt? Or what is
happening that shouldnt?
Well, yes and no. I think it's great that more games are being emulated,
but I tend to not care much for the vertical nature of it. MAME's presence
has killed off other emulator authors. On purpose? I don't think so
anymore. But one thing that comes up time and time again is the issue of
performance. People beat MAME up about performance issues constantly, but
let's not forget that MAME's primary purpose is to document the operation
of the games, and high performance isn't their focus. I think now with the
advent of Retrocade, we can focus on performance and usability and get
some of the people who are complaining about MAME's performance to
complain about OUR performance instead and leave them alone. ;-)
8. As a guy with great vision, can you describe to us your perfect emulation
*GRIN* Well, I don't know about "great vision", but my perfect emulation
world is where every game runs full speed, no frameskip, CD quality sound,
works on all machines, and all popular platforms, even on lower end
9. Now to the good stuff. In your mind, what is Retrocade? Can you tell us
a little about the main people involved, and their parts?
Retrocade has two focuses: Performance, and ease of use. IT doesn't need a
front end. It doesn't need a bunch of command line options to get things
working optimally (but they're there if you want to run it from a command
prompt), and always selects the optimal sound and video settings for the
game that you're playing. We default to 44.1khz audio. All vector games
default to 640x480. Think of an emulator that you'd walk into a store and
buy. That's what we're designing Retrocade to do.
Currently we have quite a few people on the Retrocade team with varying
responsibilities. I do architecture, most of the sound work, integration,
platform/portability issues, and some games along with it. Mike Cuddy (of
KEM fame) has done the MCR series of games, performance optimizations,
debugging, the GUI, and basically keeps me in line. Patrick Lawrence wrote
our 6809 cores (we're on rev 2), and did the initial raster graphics work.
Zonn Moore donated his Cinematronics CPU core to the cause, and drops his
brilliance in from time to time on various issues, and is brilliant. Peter
Hirschberg of Vector Dream fame has put his artistic touch to Retrocade's
vector games by adding backdrops, transluscent and antialiased vectors, to
many games, including Armor Attack, Warrior, Asteroids Deluxe, and a few
others. Neill Corlett donated his Starscream 68000 core, his YM2151
emulator and 5220 emulator used in Star Wars. Brian Peek has done a couple
of games, and is responsible for the Windows version of Retrocade. Jeff
Mitchell works on the UNIX version. Brian Levine has added quite a few
games to the collection and has written the Namco sound engine. Paul
Biondich (ice.org) has done the artwork for the splash screen, our web
pages, and the GUI. Richard Bannister is working on the Macintosh port.
Edward Massey did the original graphics code and win32 work, but is
currently too busy with life to contribute actively to Retrocade (sniff).
10. How did Retrocade materialize?
The short story: I called Mike Cuddy up and said, "Hey, want to write a
high-performance easy to use emulator?". Both he and I at the time knew
that EMU (at version 2.3) and KEM were pretty much bursting at their
architecture's seams. They both needed a rewrite. Badly. I proposed the
idea to Mike in July of '97 and, well, we've been at it ever since.
11. What are the plans for Retrocade release? How is beta doing?
It'll be in July sometime - hopefully July 4th. ;-) Maybe on July 17th -
its one year birthday anniversary.
The beta is going well. We thought beta 1 was great and bug free, but our
beta testers found tons of bugs. We fixed several of those bugs, thought
they were all gone, and our beta testers found more bugs. etc... We're on
beta 4 now, and it looks like all the crash & burn bugs are gone. It's
healthy enough for release now, but I want to polish several sections of
it and improve performance of some of the games.
12. How come you're able to make it be "faster"?
Faster than MAME, or faster in general? I guess the answer is the same
Consider also that Retrocade is almost entirely in C, with two exceptions
- the CPU cores and the graphics libraries (Scitech MGL). It has been
ported to the Macintosh, UNIX (FreeBSD, Linux, and SunOS), Windows NT/95,
and DOS. We have C cores that have identical APIs to our processor
emulators, so parts can be easily interchanged.
- We have our own sound routines that are very lean and optimized. We have
our own mixer core and Sound Card drivers. SEAL Is the culprit of a few
performance problems from what I've been told by everyone who has used it.
- Our CPU cores are in x86 assembly for the x86 processor versions (UNIX,
Windows, and DOS)
- Our graphics code does not go through pixel-by-pixel color lookup
tables, and we do DWORD transfers from the emulation code to the
- All of our controllers are event based - not polled. Meaning that the
emulation doesn't need to stop and go check for controller input. It
happens when an event actually happens (mouse button click, keypress,
- Our sound code runs inside the sound card's ISR entirely, so we don't
need to stop periodically and push data out to the sound device.
13. What is the long run goal for Retrocade?
Emulate the games we think are cool, with our own twist in some cases, and
to make people happy.
14. Now Callus supports TCP/IP network play, that is a feature that has
new life to that emulator. Can it be that Retrocade will do to games like
Blasteroids what people can only wish MAME had done?
Anything is possible given enough resources and a strong will. ;-) There's
a few features that I'd like to see that will eventually be put into
(or already is in) Retrocade:
Net play looks like it will be righteously cool, and one of these days
I'll stick that feature into Retrocade as well. ;-) The thought of a Space
Duel net match just makes me grin!
- Save game capability
- Backdrop support for games that have them (Asteroids Deluxe)
- CD Quality sound through samples or through circuit simluation
15. What have been the major difficulties in getting Retrocade to work
to release status?
Our motto: If it doesn't do what you want it to do, rewrite it so it's
"right". WE DO NOT HACK IT. This is part of the reason it has taken so
long. I've rewritten some sections two or three times to accomodate new
features, or rearchitected major sections to accomodate new games or a new
platform (Windows, Mac, etc...) The controller code has been rewritten
three times. Instead of just hacking in new functionality, we coded it so
it would accomodate everyone - always keeping performance, usability, and
portability in foreground thought.
16. It seems you are developing to many platforms at once, has that affected
development at all?
Nope. We've kept that in mind since day one.
17. Is coding for portability maybe hindering the speed desires of
Nope. We've very carefully isolated the speed impacting operations to be
operating system dependent, so each platform can take advantage of
potential hardware accelleration (if available). That puts a greater
burden on the platform developer, but hey - we did say our primary goal
was performance! This has made some of the porting issues painful.
18. Will Retrocade be one huge monster like MAME or will you be splitting it
up in parts where you deem reasonable?
It will be one huge monster. Splitting it up doesn't make sense, really,
since the largest chunks are shared by a lot of the games. The biggest by
far is the 68000/68010 emluators, which, in combined form, take almost a
It's a common misconception that the bigger the executable is the slower
it will run. That's not so. If a particular game doesn't use a major
section of the code, to the computer and cache system it's as if it's not
19. Message to emulator authors, and readers alike?
Stay focused. Don't let the lamers get to you. Don't give up if you hit a
tough spot in emulation. Keep at it.
Readers: Be kind to emulator authors. ;-) We don't put out sucky, buggy code on
purpose. ;-) ;-)
We want to thank Neil for offering again for an InterView and for being
so friendly and down to earth despite his amount of time in the scene and
the numerous projects he works on. He has been the fastest responder to our
questionaires in all the InterViews over e-mail yet. For comments you can
contact Neil or Me.
One Article Up: EV News - Some Tidbits
One Article Down: Is It Really A Choice?