WYSIWYG Web Builder Welcome to 'TURBOSUB'
A Website Dedicated To The Only Two Games Ever Produced By Entertainment Sciences
BOUNCER and TURBOSUB
Ulrich Neumann
(VP of Engineering, Designer of The RIP system)

I recently had the opportunity to speak with Dr. Ulrich Neumann about Entertainment Sciences, Bouncer, Turbo Sub, and the RIP System.  Ulrich was very kind and provided a lot of great information which follows below. 

Please note that Ulrich does not have a Bouncer machine, or ROM images so please be respectful of his privacy and enjoy his comments below.

Ulrich's shares his memories of Entertainment Sciences

I was working at Gremlin Inc. in San Diego in 1981 - before they were bought by Sega Japan around the time of Zaxxon.  I left to start Entertainment Sciences (ES) either in late 82 or early 83, hard to remember...  Just to follow that thread - Sega moved Gremlin operations to Rancho Bernardo (north of SD) and went into big production on Zaxxon.  It had a spike sales curve and they had acres of unsold production - classic bad planning - wishful thinking.  Anyway, a short time later the facility/company shut down. 

On to ES   I was made tech guru (VP Eng) and off we went.  The president and CEO raised money and I dreamed up a systems.  Based on my time at Gremlin, I had some ideas on a game system that would be "easy" to program and reusable.  It seemed like such a waste that all the electronics were designed from scratch for each arcade game - and then tossed out when it dropped off in income.  Why not build a better box for a little more money and get 2-3 game income cycles out of it (or more) and save on the cost of programming each game so update software would be cheap...  All this sounded good at the time (I was in my mid 20's) and I figured we had a great concept.

It took about 9 months for me to develop the system.  I designed a set of cards and a backplane to connect them.  I did the design, wirewrap prototype, and PC layout (with some help from a guy who had access to a CAD layout system - they were pretty pricey back them. Lots of lost sleep later, we had a set of about a 20 proto card sets.  Reality was starting to sink in.  These were multi-layer circuit boards that cost real money back then.  The cost of this thing was starting out pretty steep.  If I recall, there was a game processor, a frame processor, the RIP image generator, a sound card, and a memory card to hold all the software and images that would be updated for each game, and the backplane with connectors for all the other cards.  That's 6 pricy circuit boards, before we even add the parts.  That alone probably cost more than the complete electronics for many games (like pac man).  We pushed onward we kept telling ourselves costs would drop with quantity - and that's true... more about that later.

Around the time the proto system was coming up, we hired Rob Patton to be the SW developer and game designer.  He used an HP emulator to write assembly language for the game processor (GP).  The other processors only ran firmware that I wrote.  The GP was a 6809 running at about 2MHz, (maybe 4?) and it had some banks of memory to allow multiple chunks to overcome the 64K limit of the 16-bit address bus.  Pretty usual stuff at that time although it seems pretty crazy in hindsight.  Anyway, the programming model was pretty simple.  The GP created a simple data structure to control graphic sprites.  The structure specified a sprite ID, its screen position, its scale (X and Y), and it's depth (among ~128 depth layers).  That was it - the GP simple executed the game logic - read input, modify game state, and set up these objects (and sound commands) in a specific part of it's memory.  There was no actual pixel drawing or any graphics at all for the GP to do so it was in fact relatively easy to program games since the time critical image generation process was done elsewhere.

The Frame processor (FP) was also a 6809 and it shared some of the GP memory so once the object structures were setup, it took them and converted them into data instruction format that was easily processed by the RIP image generator.  This was a pretty simple program and it was all the FP had to do - but it hid all the ugly aspects of the RIP processing from the GP - like having to sort the objects from top to bottom of the screen) and it gave us an extra CPU to do other work like collision detection or whatever...  Anyway, the FP output was another data structure suited for the RIP and it was again in a memory that was shared between the two processors.  The GP and FP were on the same physical game processor card.

The RIP took another card. It was a 29116 processor (from AMD) which was pretty fast for it's day (~16 MHz).  This cpu interpreted the FP data structures as they were processed.  The top to bottom sort was important since the RIP didn't have a frame buffer to hold a complete image.  It only had 2 lines of memory.  One was being filled by the RIP and there was being scanned out to the monitor - yeah - this was pretty nasty technology and technically difficult.  It did work however, unless you put too many objects in the scene on one scan line.  Then the RIP would not have time to draw everything before it was time to output that line.  This would cause tears in the image on occasion and was the chief weakness of the system.  Anyway, the RIP was a bit TTL/ECL beast. The parts cost a lot and there were plenty of them.   By this time, we were hitting about $2500 in electronics for each of the prototypes.  That's what other games cost to the distributor - we were in big trouble - but the system did work and worked really well.  Another innovation/cost was that we output 512 pixels per line, as opposed to 256 for all other systems.  Our images looked great!  We also had 16K colors as apposed to 256 or less in other systems.  Again, the images were very good for the time.  Lastly, we tried to slow the frame rate down (to 45-50 fps non-interlaced) to allow the RIP more time to draw more objects.  This meant finding special monitors with long persistence phosphors so you didn't see any flicker.  This did cause some trails on moving objects, but it actually looked pretty cool and most people liked it.  To cut costs on the monitors, we started modifying standard monitors (from Electrohome), but you could see some flicker with those since they had fast phosphors.

The Sound card had another 6809 and it basically played sampled sounds (like a wav file today).  This was also novel and cost us some money since other systems had simple/cheap (and limited) analog beeps and sweeps for their sounds.

The image creation process was another innovation - one of the biggest ones and I consider it a success since it set the direction many people went.  We used real animators to draw real animation cells - I still have some of them.  We hired an artist from Sweden via Disney animation studios.  We had a system programmer who built a unix-based video digitizer system with a camera shooting the hand drawn cells on a big custom camera rig we built.  The images were traced in software and then painted with colors using a program we developed.  So artists drew cells and painted them by computer.  Hanna Barbers "introduced" basically the same idea and used it for years of production.  I'm not sure if we were first or they were, but no matter, neither knew of the other at that time.  Anyway, the painted images were tagged with IDs and managed by the UNIX system.  The final images were processed into a horrible format that was optimal for the RIP to use in it's drawing of the images into the scan line memory.  The munged images were then burned into banks of EPROMS and stuffed into the memory card.  A text file was also generated by the UNIX system that had all the needed index info that was linked in with the GP processor code so it could tell the RIP where to find a specific object ID in the image memory.  This was really a complex (hideous) process so automating it was essential.  There was no way a person could do this or keep track of things.  I all worked and we made a lot of animations for bouncer.  We had megabytes of image memory - way more than typical games - and the animations were nice since they came from cells - the best medium for any animator.

There are plenty of other details, but I think I hit the main point. Another programmer worked on the real time OS that the GP ran.  He made a process scheduler so the game was composed of processes that would run at some rate or wait for events - basically one big state machine.  It was pretty cool for that time - I didn't know of anything like that at Gremlin or other game system at that time.  We could do things like that because we didn't have the graphics process to worry about in the GP.  The programmers cranked out a lot of code over the 2+ years they did all the system tools and bouncer and turbo sub.

Now to the sad part - we never sold any boxes to speak of.  We tested them in Huntington beach and at Del Amo mall (Torrance).  There may have been other placed, but they were all tests, not sales.  We negotiated with Atari forever... they strung us along on a licensing deal, but never delivered.  In then end a lot of similar ideas were used to make Paperboy and some other games for a "reusable" system with 512 pixels of resolution.

We did a lot of scrambling to try to get the money needed to buy parts in quantity.  We felt that if we could afford to make 300-500 units, the cost would be low enough to allow us to make a small profit on the box and first game.  More money would come for the updates since the production cost would have been very low - we used EPROMS so we could swap game cards and reuse them.  It never happened.





Q&A with Ulrich Neumann

Q) Besides Turbo Sub & Bouncer, we're there any additional  games in development? One of the people who found one of the warehouses claimed they found information about a 3rd game.

A) I don't recall a third.  There was no game development after that.  It was a complex affair to do games for this box - unlikely anyone else would have figured it out.

Q) Some have claimed to have played Bouncer in the early to  mid 80's.  If memory serves me right I believe the two cities mentioned  we're Huntington Beach, CA & Chicago, IL.    Is it possible that these  machines we're market tested in these cities?

A) Chicago was probably at the AMOA show - we were a hit, but so was Dragon's Lair - and it was cheaper and shipping...  We may have had marketing tests in other places too, I don't recall.

Q) Did any Turbo Subs or Bouncers ship commercially?  How  many prototypes exist for each?

A) No - we had about 15 or so machines overall that we could use for either game - I don't recall actually selling one to a customer.

Q) The people who claimed to have played Bouncer indicated it was a really fun game, did the market research reflect this as well?

A) Yes - I agree - it's hard to be objective when you see it 24/7 for months on end, but we'd see people play in the test locations and they had fun.   It had a very unique look and feel for that time - people thought it was a laserdisc game since the hi res graphics and color range were clearly beyond the other video machines.

Q) There has been some debate among the collectors as  whether Bouncer used a standard or medium resolution monitor.

A) Hi res initially - total pixels were 512x480 if memory serves me.  The number of lines was variable - just a constant in the RIP firmware so we could tweak it.  Normal video game monitors were putting out 256x192 so our images were pretty nice by comparison.  The cheap monitors really didn't show the quality of the image we produced since their phosphor masks were too coarse for our pixel count.

Q) There was also a rumor that Bouncer was to have initially  been a laserdisc game, and that Hanna-Barbera was responsible to the animation.  Is there any truth to these statements?

A) No - no connects to laserdiscs or HB other than those I've mentioned.  We looked like a laserdisc quality and our animation authoring system was similar to that developed at HB.  There was no contact from ES to either laserdisc co's or HB at any time.

Q) Was Bouncer intended to be an upgrade to Turbo Sub, the limited parts discovered for Bouncer do not seem to easily fit the Turbo  Sub cabinets.

A) Actually, Bouncer came first and TS was developed as the second game.

Q) In the movie "Ninja III" a machine bearing the name "Bouncer" makes an appearance,  a few seconds of screen shots look identical to the flyers pictures, later in this movie the machine is used as a special effect.  Do you know why "Bouncer" was used in this movie?

A) Yes, this is funny  I have some recollections of this - I think it was mainly for publicity.  We were always looking for any way to promote the machine and  game.  I suspect they ran into this "opportunity" and donated a machine to the cause.  I have no recollection of being involved in any way.  It may have happened towards the end of ES - I left around mid 1986.

Q) Was Bouncer ever completed and burned to ROMS? If so are these ROMS compatible with the Turbo Sub hardware?

A) Yes - probably EPROMS.  The exact same boards and EPROM chips (with different code burned into them) were used for both games.  It was designed to do that.

Q) Many of the game companies did their development on a  VAX, what system did Entertainment Sciences uses for development?

A) The code development for the GP (and the FP) was done with an HP emulator system in assembly language.  The RIP was programmed by hand on paper at first.  Later one of our programmer wrote a custom microcode assembler for me - bless him.  That assembler ran on a CPM system with 8-inch floppies.  The Unix system for animation development was a 68000 system from Charles River Data Systems.   We bought a frame grabber card (S-100 bus) from somebody and hacked the system to use it.

Q) Is the source code for the games still in existence?  Are  the rom images still in existence ?

A) Not that I know of - that would be a great find...  I thought I may have copies of the source for FP and RIP somewhere, but it's improbably since my files have the schematics but no source printouts.

Q) MAME (Multiple Arcade Machine Emulator) is a programs  that allows the hardware for any many older arcade games to be emulated  in order to play the games from the actual ROM images, it currently supports close to 4000 games, Are you familiar with it? As a game developer what are your feelings about it?

A) I think it's a great way to keep the old code running.  For most systems, it would be a complex task to emulate all the nuances of the hardware.  I'm amazed that there are so many games still running like that.  I don't think ES game ROMS could easily run on such a machine given the complexity of the hardware that would have to be emulated.

Q) Considering very little hardware exists for these games,  do you think the current owner would be interested in making the ROM  images for these games available to collectors for incorporation into MAME?  Many unreleased prototypes now live and are being enjoyed in MAME.

A) If I knew of any EPROM images, I'd be happy to help, but I don't know of any...

Q) Do you know of anyone that would have any spare parts  they would be willing to part with,  I'd love to get a "Bouncer" up and  running, and get one of my Turbo Subs built out.

A) Sorry - I wish I had kept a working system or set of board or something - I walked out empty handed - it was a sad day for me.   I also didn't want to do anything that could hurt or hinder the remaining people there.  It was like a family after all the experiences we shared.

Ulrich Neumann Today

Dr. Ulrich Neumann is an Associate Professor in the Computer Science Department at the University of Southern California.  He earned an MSEE from SUNY at Buffalo in 1980 and his computer science Ph.D. at the University of North Carolina at Chapel Hill in 1993 where his focus was on parallel algorithms for interactive volume-visualization.   His research relates to interactive media, tracking for augmented reality, and human facial modeling, rendering, and animation.

Dr. Neumann is the Director of the Integrated Media Systems Center (IMSC), an NSF Engineering Research Center (ERC), and he directs the Computer Graphics and Immersive Technologies (CGIT) Laboratory at USC.  Prior to his academic career, he designed multiprocessor graphics and DSP systems, cofounded a video game corporation, and independently developed and licensed electronic products.

Prof. Neumann holds the Charles Lee Powell Chair in Engineering. He is recipient of an NSF CAREER Award (1995) and the USC Northrop Grumman Junior Faculty Research Award (1999). He is a member of the ACM, Siggraph, Eurographics, and the IEEE Computing Society.