Boxer (Boxing? name changed somewhere in there) started out as part of what some of us saw as a need for a more physical experience, later to manifest in the Football game, whose cabinet was (in my opinion) derived from the Boxer one.  I believe Jerry Lichac came up with the original controller, although it may have been another mechanical designer.  Picture the sort of control an R/C model might have, with a twist knob atop a standard analog joystick.  Now imagine the "knob" being a pair of handles you could grip, at the ends of a 6-inch or so bar, and that bar atop a shaft that moved in X and Y - three axes.  You moved your boxer with the X/Y position, and punched by rotating those handles.  Now, imagine someone getting "really into" the game, and breaking the control in a few minutes.  Several revised designs followed, with the last few being variants where the Y axis (forward/back) was removed in favor of a beefier slider, and several software variants to "make it fun" despite the reduced physicality.  I believe Ed Logg took a crack at doing Version 14.  The rest is non-history.

A nerd-note: This was my first 6502-based game (Pool Shark and Drag Race used the 6800).  It also went through a major redesign early on.  The first design was by Howard Van Jepmond, who did Drag Race, Highway, and maybe Stunt Cycle, Outlaw, and Qwak! (the duck-hunt game, not the touch-screen puzzle game that never made it past focus group).

My biggest technical challenge was reading 6 potentiometers whose interface was a "nearly all software" minimal hardware thing, with code the tightest I had ever written.

I have been asked about the very first game I worked on at Atari and how my first creation took place.  That would be the coin-op version of Cannonball.  The game was one of the very early microprocessor games created at Atari in early 1976.  I liked playing the game Stunt Cycle, a hardware only game where you jumped a motorcycle over an ever increasing array of busses, and wanted something that easy with increasing difficulty.

At that time, video games were almost completely created by four people: The hardware engineer, the software engineer, the mechanical designer (cabinet and controls) and a tech.  There were some support people to the hardware engineer for building prototypes, and the software engineers had computer operators, but I did not even know about them at this time.  The entire game, graphics, and sound were created by the software engineer for the most part.

I received a very basic motion object hardware (Black, White, and Grey objects) with a simple bitmap stamp playfield and told to create a game.  I had not been at Atari long, so I had no idea HOW a game was built, just that there were a few people there doing it.  I was amongst the first 5 programmers so we sort of made it up as we went along.

Ok, so they set me up in a small lab next to my small office, and I got to work.  First, I created the graphics for a small man running, flying through the air, and hitting the wall, including a “squish” animation, and a man walking off holding his back.  This was all done in 8x8 motion objects, several put together to make a bigger object.  So on graph paper, I created these objects.  I was no artist, but it was easy at that resolution.  I then did the same thing to create the cannon, the wall with a hole in it, a powder keg, and a smoke blast!  These I hand programmed into a small PROM (this was before EEPROM), so you wanted to be sure you did it right.

After I got the graphics installed, I sat down at a device called MicBug, a 6800 (NOT 68000) Motorola “development” system.  This was a small computer board that had a cable that plugged into the processor socket of the game board with some RAM.  You entered instructions at a model 33 teletype!  With this device you could put in a breakpoint, alter memory and registers, run and stop the processor.  Very basic.  So, with a small card with 6800 instructions on it, I began writing AND HAND ASSEMBLING my code on paper, then I would type it into the model 33 teletype into MicBug, and save it on paper tape.  Editing was done by creating small “patch” paper tapes with changes.  I had a big box of changes, and would eventually punch out a full dump.

After a number of months, my boss suggested a review of the game.  No problem.  We set it up.  I had the game running, simple sounds, self test, and all coin routines.  I would guess about 75% of the project.  A man came out, stood next to the cannon and waited.  On the opposite side of the screen was a tall wall with a hole in it (that moved each round).  Pulling on the handle caused the powder keg to add powder to the cannon.  The more powder, the higher the shot.  Releasing, the man jumped into the cannon.  Push the fire button and the man flew out of the cannon towards the hole.  Make it through and you scored.  Miss, and you splat into the wall or floor and limped off.  Simple but fun.

Towards the end of the review, my boss asked if he could see my program code listings.  Listings?  What listings did he mean?  Well, as it turns out, there was a way to create programs for games, I just never knew about it.  Rather than hand assembling, one simply wrote the program on paper, handed it to a computer operator who then edited it into an early DEC PDP computer (like an 05 for example).  These operators would assemble the program and produce a paper tape output and a listing of the assembled program. Oh! Then the program remained on the PDP.  Later changes were simply scrawled across the listings and edited by the same two people into the PDP, and a new listing and paper tape was created.  What took me months I probably could have done in half that time.  Oh well, so much for the easy way.  But since I was so far along, inputting this into the PDPs was going to be a long process.  But a Model-33 teletype listings, lots of pen scrawls and I was 'up-to-date'.

Now the fun began.  They wanted more sounds, and most of all, a sound when the man hit the wall.  So I set out to create a bone crunching, splat sound.  But how?  All we had was a modulated white noise generator.  So we took a microphone and a recording scope into the bathroom, and began throwing wet towels onto the tile floor and recorded the waveform.  I programmed this into the noise generator and there it was.  Every time the man hit the wall, SPLAT!  It was great.  But the game was still too silent.  What about music?  Not with this hardware, this was long before games could generate music.  So we added an Eight Track Tape unit on a relay and licensed some circus music, so every time the game started, you heard the looping circus music.  The game operators where we tested this unit hated that after several weeks, but the game actually did fairly well.

The kicker to this story was that during a later review, management said they hated the splat sound and thought it was too graphic.  Several months later I started my next project, Sky Diver.  Knowing they hated the splat from Cannonball, I decided to have the divers over water and splash into the water if they did not open their shoots.  First review, two managers said “…remember that sound in Cannonball when the man hit the wall? Can we have that sound here instead of the splash? Let the man hit the ground and splat!” Of course, I made it comical, but that is how the splat came about in Sky Diver, which is another story.

Captain Seahawk was basically a straight port of a 2600 game.  One of the corporate guys decided instead of letting the programmers come up with game ideas, he'd tell them what to make.  He said he wanted a version of game 7 from Air-Sea Battle since it was a popular part of the 2600 game.  Mike told him that it's fun to play at home but wouldn't work in the arcade.  Mike had to make the arcade game, anyway.  So, he did a straight port, and as he expected nobody was interested in playing it in the arcade.  It tested very poorly.  Management decided to let the programmers design the games after that...

I don't recall what bright spark thought it was a good idea.  You may be aware of the most terrifying action workers can take against management: "Work to Rule".  I was actually surprised to be asked about that game.  One of these days I'm going to organize and document my most notable failures, not just in games.

There were a variety of other games that I worked on that were handed off to other programmers, such as a variant of Dirt Bike that Ed Logg took over and finished, and another variant of Sea Wolf (a popular game by a competitor) that was never finished called Wolf Pack.  The team members varied with the project, but I worked with Howard Delman and Dan Van Elderen and shared an office with them for a time.

Dragster was an early concept sketch that used rear-screen projection and a vibrating seat.  We wanted to have it do a wheelie, but decided the screen was too small and never got to it.

Fast Draw was a video game - it was like Gunfight except you pushed a button instead of pulling a trigger.  It was a flat game, like Atari's Football.  Two people stood facing each other and whenever the light came on you had to hit the button.

The gameplay is very much a simulation.  The other tanks do not fire at you, and the only way to end the game is to run out of ammo or shoot a 'friendly' tank or helicopter.

The Turret is controlled by a Star Wars style yoke controller.   It turns the guns and lets you change the elevation of the gun. There are 3 type of weapons - 25mm cannon; 7.62 mm coaxially mounted machine gun; TOW missile launcher with twin tubes.  The upper left of the bezel hold the Range control, and also the magnification switch.  The range control sets the height of the gun before you launch rockets or shoot the machine gun.  The magnification switch changes your view from 3x to 10x.  On the right side of the bezel, there is a switch for arming the TOW missiles.  Once you fire these missiles, you can guide them with the 'laser' sights.  You can steer the missile into targets, or into the ground if you overshoot the target.  At the lower right near the yoke, are 7 buttons for selecting the 'AP' (armor piercing) rounds, or the 'HE' High Explosive rounds.  You also have the choice of 'SS' single Shot or 'CF' Continuous Fire modes.  You can also switch to the '7.62mm' machine gun also.

It usually takes one hit from a TOW missile, 5 from the rockets/shells, or 10-20 from a machine gun to bring down an enemy.  Some tanks can only be shot with the TOW missile.  The helicopter is the most difficult target to destroy.

NO SCHEMATICS came with the board (I have never seen any schematics for any proto, as the schematics are the last thing completed when a game goes into production).  The board is basically a standard Battlezone board with a wire-wrap add on board for all the additional inputs.  It features a D/A converter for input from the yoke and the Range controls.

In order to convert a Battlezone, you would have to add a Star Wars controller with two independent sets of triggers on the front side, a buttload of wire jumpers, an I/O board with a D/A converter, a ROM daughter card, 11 buttons, 3 pots, two pedals, and a bunch of cabinet wiring.  The wire-wrap board has a zillion traces that go to the AVG board.  The Mathbox proms, seems to be stock and have production part numbers on them.

I'm not sure why there are a set of handles screwed to the side of the cabinet.  It seems like they wanted an easy way to move it around, but they drilled holes right through the sideart.  There are reinforcement plates behind the handles.

Here is an email I exchanged with an ex-Atari Employee:

---------------------------------

Hi, Scott.

Thank you for your email.

I will do my best with your questions about Army BattleZone.

(It was a long time ago.)

(Scott Evans): 1. Is the tank supposed to move?  I can only turn the turret.

I know the tank is not under the player's control.  I don't remember if it Moves by itself.  If it doesn't, it was supposed to, but we ran out of time. The purpose was only to train gunners.

I noticed some mounting holes on the bottom of the cabinet, but there are no pedals there.  There is a long unused harness with a molex connector inside, but i cannot get the tank to move forward when I connect the wires.

I don't remember any pedals.  The holes are for the step from when it was a Battlezone.

The unused harness sounds interesting.  Maybe it's supposed to go to one of the control panels we added.  Where does the harness connect?  Does it go to the BattleZone Main Board, or does it go to the add-on board we made so we could read more switches (and the range pot)?

There were switches added on the right side of the panel and I think a pot and more switches for the rangefinder somewhere.

(Scott Evans): 2. Do the enemies shoot at you, and can you see their shots?  I notice that the enemies guns will flash, but I do not notice any shots coming at me?

I think the enemies are supposed to shoot at you and you are supposed to see the gun flashes.  The idea is to learn to recognize which are enemies and which are not.  You are supposed to be heavily penalized for shooting at 'friendlies'.  I don't know if that got in either.

I am really curious where you got it.  As far as anyone knows (or is willing to admit) there were only two made.  One went to a conference at Ft. Eustice and was never seen again.  The other is in my old boss's barn.

Most of what is known about Army Battlezone is already on the Web.

(Scott Evans): My source needs to remain anonymous.  It was not working when I got it, but I was able to get it going with some minor fixes.  I heard the Rick had left his at Atari when he quit.  I think this is the same one.  If Rick has another one, I would sure like to see it in action

Rick brought ABZ to Atari on my last day.  I was disappointed because it didn't work.  Scott, thank you for rescuing it.  The first ABZ used a control that was adapted from an actual Bradley.

Before the called it the 'Bradley' it was just called the IFV (Infantry Fighting Vehicle).  The first ABZ went to Ft. Eustace.  The second ABZ used one of the first prototype Star Wars controls.

(It was a downsized version of the actual Bradley control.)

To: Distribution

From: Rusty Dawe

Subject: Quink Development Date: 2/6/85

The source code and text files for the game "Quink" have been transferred to the VAX and reside in KIM::[RUSTY.QUINK].  I have also examined the files and source code in an attempt to gauge how long it would take to translate this game for System I.

The source code is in IBM Basic with some routines (mostly screen writing and color change routines) written in 8086 Assembler.  There are no comments anywhere in the source code.  Fortunately, the Basic source code is not very lengthy or extremely complicated.

In my opinion, it would take someone who is well versed in IBM Basic (such as Kelly Turner or Bob Flanagan) about 1 1/2 to 2 months to convert Quink to System I (in a form ready for field test) with its existing set of questions.  Adding additional questions is NOT as easy as it might first appear.  The categories and lists are all organized very carefully to put close subjects next to other subjects with similar themes or similar sounding words.  In addition, I feel the existing questions are more difficult than an arcade audience would appreciate.  Looking over the questions that are given for difficult levels of play (about 1/2 the total number present) I find that unless I am well versed in that subject, the answers given are completely unknown or obtuse.

Owen and I realized that we had some leftover ROM space in Sebring, and arranged for it to work (after a fashion) with the two ROM chips swapped.  Most games at the time started with a brief self-test, that displayed "RAM OK" and "ROM OK" (or, of course "RAM BAD" etc) and then either started the game attract mode or the more extensive diagnostics.  If the ROMs were swapped, the message would be "RAM OK" and "ROM KO", and if the test switch was off (to go to the game) would trigger an explosion sound and show "THE ROMS ARE IN BACKWARDS".

Space Shoot was the game I was working on when I left Atari in 1981 to start Videa.  It was a one man show -- I was the project engineer, hardware engineer, and programmer.  The idea for the game came from a newly released movie, although I can't remember the name anymore.  In the movie, there is a scene in outer space, in which a young man is being trained to "fight the bad guys".  Bright colored disks are being launched into space, and he is trying to hit them with a hand held weapon.  Basically, it was skeet shooting in outer space.
For my game, I had the mechanical department design a futuristic looking handgun.  As in the movie, waves of "disks" would launch across the screen, and you got points for what you hit.  To be honest, the game wasn't developing well.  I never seemed to find the right features to make the game compelling.  I doubt it would have made it to field test unless someone had an epiphany.  I don't know what ever became of the gun, or the circuit board.  When I left Atari, it was all still on the lab bench.

I designed Spook - at least, the original version - with a guy I liked a lot at the time but whose name escapes me now (the down side of moving into and out of the industry).  If he's reading this: please get in touch.  It was going to be an arcade game; its transition to a computer game must have come post-Tramiel.  My buddy and I spent several days cruising Silicon Valley, exploring "spooky" houses pointed out to us by local realtors, and of course we visited the Winchester Mystery House on Atari's dime.  If you're not familiar with this place, Sarah Winchester, wife of the man who invented the Winchester rifle, was warned by a psychic that she was haunted by the ghosts of everyone the rifles killed, and she could only survive by building a mansion that would never be finished.  So the house is filled with projects that are essentially busy work: stairways that go nowhere, windows in the floor, and a door opening onto an 8-foot drop into a kitchen sink.

It doesn't look like much of that got into the cart.