Super Breakout preview

[james1095]

I've been tinkering away, working on implementing the bronze age Atari arcade game Super Breakout in VHDL. Just thought I'd show off the playfield generation subsystem which I've successfully got displaying random data I loaded in the video RAM for testing purposes. What this shows is that the video sync circuitry, playfield generator and video RAM are all working properly, next step is to add the CPU and IO subsystems.

 

In hopes of inspiring others to implement other games, I've shared the tested working VHDL for the sync and playfield circuitry, these are used in quite a few games of that era with only minor changes needed from game to game. I've been using an Altera FPGA for development but this code should be platform agnostic, just use romgen to create ROM images. I've got a version of the sync PROM written as combinatorial logic that I'll share once I verify that the result is identical.

playfield.vhd

sync.vhd

[james1095]

Just an update, significant progress has been made. Over the weekend I finished up the CPU section and for the first time I got a recognizable screen for the attract mode, that's when I took the attached picture. Over the last couple evenings I've debugged the motion object generator so the balls are working and I'm able to coin up and start the game, woohoo! Fixed a few more bugs, sound works, outputs for the start button lamps and serve button LED are working. The only major part still missing is the paddle control and I've started on that, the plan is to use an encoder rather than a pot like the original so I can avoid adding external circuitry but it will be easy to connect the original pot circuitry. Then I need to finish the configuration dip switches, figure out why one block is missing out of the left border and code the watchdog timer just for completeness and then I'll post the code. This is all rather exciting as I've had a goal for a long time to recreate an arcade game rather than just porting other people's code.

 

Next up I'll get to work on other games that use very similar hardware. Watch this space for Sprint 2, also considering Sprint 1, Atari Football, Fire Truck and other bronze age classics. If anyone has a particular game of that era that you remember liking feel free to share and I'll take it into consideration. There is a lot of collector focus on the 80s golden age games but there are some classics from the 70s B&W era that I think are under appreciated.

[vlait]

Nice:)

The bronze age games definitely deserve to have more attention!

I guess one  needs to be past certain age to really appreciate them as most of them really aren't that good compared to post space invaders releases.

Otoh many of them are actually protos to modern one button mobile games with less eye candy

 

[james1095]

Further progress has been made and at this point the game is working and playable. I fixed a problem with the RAM write enable which fixed the missing border section and some other weirdness. I added some code to use an optical encoder to control the paddle rather than the potentiometer originally used. If one wanted to use a pot instead it's fairly trivial but would require an external comparator, a transistor and a few passives, I've tried to make this change as simple as possible in the code. All that remains is to polish up the code that handles the configuration dip switches and then do a bit of general tidying to make it fit for public consumption and then I'll post it. I'm actually using a small Altera board for this as I've grown to prefer Quartus over ISE but it should be trivial to port to the Papilio, I've made everything as platform-agnostic as possible.

 

Yeah the bronze age games are primitive compared to the golden age classics but a lot of the heritage is clearly visible in later games, both from a hardware and gameplay standpoint so they are of historical significance. There is also something I find pleasing about the soft glow of a B&W CRT though I've used a small TFT monitor for much of the development simply for reasons of convenience. The thing that attracted me to Super Breakout aside from the game being relatively fun is that the hardware is very simple, the schematic is legible and the theory of operation in the manual is quite good. It's simple enough to be fairly easy to understand how it all works yet complex enough that a lot of the concepts can be carried over into newer games. Another advantage of these early games is that they will fit entirely in very small and inexpensive FPGAs which are much faster to compile for than bigger more capable parts.

 

In between things I've also done some work on Sprint 2 and I have the playfield displaying. This means not only that the playfield generation circuit is working but the CPU is executing the code from the program ROMs and writing something sensible to the video RAM so that's the next one in the queue.

[Jack Gassett]

Hello James, 

Killer! I'm curious about the tools, workflow, and methodology that you use while working on these games. Is it something you can write some more about? I don't know if you saw that I'm working on a cloud based ide solution for the Papilio, I can't help but wonder if we can package up everything needed to work on these types of games into Docker and make it easier for people to start hacking on these types of projects? What do you think? The big roadblock to this type of thing in the past has just been getting all of the tools setup to hack on your own arcade games. But if we can automate that process and just provide a link that people click (which I have almost ready to go) on and have a web ide with all the tools setup and ready to rock, then they can just look at source code and do stuff like change "High Score" to "My High Score" then it would be awesome.

[james1095]

Setting up the tools is trivial compared to the actual work of recreating a game from start to finish, for anyone with access to broadband I'm not sure why this is even an issue. Super Breakout is one of the simplest arcade games I could find hardware-wise and it still has taken me tens of hours to write and debug the code but much of that time was spent wrapping my brain around how the original circuit works. There are a couple of critical aspects I took into mind when starting this out, one of which was that the manual is available with a nice clear schematic, many classic games have hand drawn schematics that are nearly illegible. In addition to the schematic, the manual had a rather good theory of operation that I was able to read to gain a deeper understanding of how the hardware works. The next criteria was that no complex ICs are used that aren't already available in HDL. In the case of Super Breakout, the 6502 microprocessor is the only such IC and the well known T65 core covers that. As far as the actual process it was just a matter of sitting down with the schematic and writing VHDL to model the various portions of the circuit and then connecting everything together in the top level file. Anyone who is curious can look at the sync generator and playfield generator code I attached to my initial post. In addition to that there is the motion object generator, CPU/memory subsystem, sound, and I/O blocks.

Changing text that appears in the game is actually not trivial because it is written to the screen by the program code which was written and assembled by Atari. From a hardware standpoint the Super Breakout playfield is a matrix of 32x28 cells and displaying something in one of those cells - say the letter "B" or part of a brick is a matter of writing the byte code corresponding to the desired character into the location in RAM representing the cell you wish to display it in. The original hardware multiplexes the RAM between the CPU and display subsystem according to the state of the Phi 2 clock but I simplified things somewhat by using a dual-ported RAM instead as it's already available in the FPGA anyway. The end result is exactly the same, but I don't have to care whether the fact that the CPU is not quite cycle-accurate affects critical timing.

Now having a solid understanding of how the hardware works, someone who knows 6502 assembly (I don't) could write a new game to run on the existing hardware, or even modify the hardware (since it's defined by VHDL) to change or expand its capabilities any way they wanted. For example you could copy/paste the motion object generation to add the ability to display more than 3 balls if you wanted, or you could add color, or better sound effects or anything you can think of. It would also be easy to use the video subsystems with a completely different processor since it's just a matter of writing to locations in RAM which has a port that is entirely independent of the one used by the video hardware to generate the display. Hack, slash and experiment all you want without damaging or altering original vintage hardware.

I've made the code as modular as possible and I've tried to comment it sufficiently and keep it similar enough to the original design that someone can reasonably follow the schematic for Super Breakout and see what is going on in the VHDL. Given similarities from one game to another, my hope is that more and more games can be created, reusing bits and pieces, for example Sprint 2 uses exactly the same sync circuitry as Super Breakout, the playfield generator is nearly identical, the CPU/RAM/ROM is extremely similar, the motion object circuit is similar, just expanded upon. Even newer Atari games like Centipede use a similar architecture, nearly identical sync circuit, same CPU, when you start looking at schematics you start to see common themes. That shouldn't come as much of a surprise really, if you were trying to get a new game out quickly there's no sense in reinventing the wheel if an existing circuit block already does what you need.

[james1095]

This is now complete and working, source is attached. Currently this is targeted for an Altera EP2C5T144C8 mini board but porting it to the Papilio should be very easy, doing so is on my list of things to do but I think I'll take a break after debugging the last few issues with this. All it should really take is replacing the Altera PLL with a Xilinx DCM and replacing the ROMs with something Xilinx compatible. Several of them are only 4 bits wide and it seems like Romgen doesn't support that but I'm sure it could be modified. Also I intend to replace the sync and address decoder PROMs with combinatorial logic since they're such small devices that it's a bit pointless to use ROM for that application these days.

 

For the control input I'm using one of these https://www.ebay.com/itm/new-incremental-optical-rotary-encoder-600-pulses-line-AB-two-phase-5-24V/272391186094 but if you prefer to use a pot as originally used in the game, duplicate the ramp generator and analog comparator from the the schematic in the Super Breakout manual. I've already designated some pins for that purpose and included a second paddle interface file to substitute for the one that interfaces to the encoder.

 

To make it really authentic, some strips of colored lighting gels could be stuck to a B&W CRT as was done in the original game, or the color could be added with a bit of additional code was was done with the FPGA implementation of Space Invaders. If one wishes to use a VGA monitor instead of the original composite type, the scan doubler from Space Invaders could also be added easily enough.

Super_Breakout.zip