- News for June 15, '98 -





Neil Bradley, pioneer, InterViewed - June 15, '98 by JoseQ
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.

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 emulator@synthcom.com, 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 (Targ/Spectar/Blasteroids).
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 blessing.
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 about it?

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 Asteroids Emulator.

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?
Several things:

  • 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 thumb? Why?

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 them.
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 emulator@fensende.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 world?

*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 machines.

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 either way:

  • 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 backbuffers.
  • 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, etc..)
  • 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.
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.

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 brought 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:
  • Save game capability
  • Backdrop support for games that have them (Asteroids Deluxe)
  • CD Quality sound through samples or through circuit simluation
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!

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 Retrocade?

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 megabyte.
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 even there.

19. Message to emulator authors, and readers alike?
Emulator authors:

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.


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?

Post Some NEW Comments on this topic...

2001 EmuViews