The Altuim NanoBoard
PACE was simply a pipe-dream until good fortune intervened and I found myself with access to what has proven to be the perfect prototype platform for PACE development. The Altium NanoBoard, together with DXP and the Nexar development platform, comprise a complete FPGA development system on a self-contained PCB complete with flash and SRAM, PS/2 inputs, audio and VGA outputs and interchangeable daughterboards for both Altera and Xilinx FPGA silicon. The Nexar tools include PS/2 and VGA controllers as well as a complete Z80-compatible soft core.
Through our work with Altium, we had also developed a tile-map and sprite system modelled, incidentally, after that of Pacman.
It was obvious, given that we had a Z80 core and the graphics hardware from Pacman, that the first prototype was always going to be the original Pacman arcade game. It wasn't perhaps the easiest game that we could have attempted, but I had spent some time studying the architecture of both the hardware and certain aspects of the software and it didn't take too much work to get to the point where I could watch the tile-map change as the game code executed.
At this point I was hacking together the various components in schematic with little thought towards the architecture of the design. I developed some simple software tools to pre-rotate the graphics and modelled a video ram "mapper" that translated writes that the Pacman CPU made to the video ram into a map that was more conducive to scanning horizontally by the video controller - a technique I used in all later games. Soon I had the correct display on a VGA monitor.
Sprites followed and I made some inroads into correcting the colours but ran out of RAM on the Cyclone to finish the job. I also write a module to translate PS/2 keyboard commands into control panel events required by the game - I could now actually coin-up and play a game. The screen was also quite small (as you can see in the photo) but since this was simply a prototype I wasn't concerned - all that mattered was that I could play Pacman on the NanoBoard.
Having intricate knowledge of both the hardware and software of Space Invaders from my TRS-80 Bootleg Project, I decided to tackle the Midway 8080 games next. I also wanted to try the opencore Z80 and adapt the graphics system for a bit-mapped display. Space Invaders proved relatively straight-forward, and with pixel-doubling the game was expanded to fill the entire VGA screen, albeit with an aspect ratio not faithful to the original. Still, it looked good!
Galaxian and Frogger came next - mainly because they ran on hardware not too dissimilar to Pacman and they're really good games! And colourful! In the process of addnig more games I was refining my approach by getting the video hardware working from a MAME screenshot loaded into video RAM on the FPGA - without a processor at all. Each new game brought changes to the PACE architecture which, whilst inevitably breaking every game before it, was getting a little closer to a generic framework that could cater for many different games. I was also favouring VHDL over schematic entry; in a lot of cases it was faster, much more compact and ultimately (and most importantly) more portable.
Later I added Zig-Zag and Jump Bug on (essentially) Galaxian and Frogger hardware, and then Pengo on Pacman hardware. But next came sound!
Chris had originally attempted Galaxian sound; discrete circuits some of which are yet to be implemented even in MAME, for good reason. They're difficult enough in C - a nightmare in an FPGA! After a few weeks he decided that perhaps emulating a more digitally-friendly sound circuit would be more prudent. Since Pacman was the first game we emulated, he chose the relatively simple custom Namco sound chip on the Pacman board.
Even without the external audio filters on the original circuit, it sounds damn good! It really was impressive to see and hear Pacman running on the Nanoboard - with close to the correct colours! We'd certainly proven that PACE was viable, even on hardware not designed specifically for our own purpose.
The AY-3-8910, a common sound chip found on dozens of games, proved relatively easy. And although it took me a few months to get to the point where I could hook it up to a game, I got it fully working in ZigZag after a frustrating time trying to get Frogger sound going. Although the sound is reasonably expensive in terms of FPGA resources, we were very happy with the results.
Most recently we built Mike's Atari Pokey core and hooked it up successfully on Centipede.
An aside - the 8-bit microcomputers
Just for fun I put together a TRS-80 Model III ROM BASIC design. I was amazed at how simple it was; simpler than any of the arcade games I had done up until that point. There's no secondary storage I/O at all, but I was able to use the Virtex II internal RAM blocks to store a few of the more famous TRS-80 games and use them to verify the TRS-80 sound.
After working on Centipede solely to test the opencore 6502, I decided to have a go at the Apple II+. Not knowing anything about the hardware, there were a few stumbling blocks along the way but it wasn't too difficult to get Applesoft BASIC running complete with hires graphics and sound. There are still problems with the design, but they're not high on the PACE priority list.
Preparing for our PACE hardware design
The prototyping has been fun and we had managed to implement a dozen or so games on a handful of platforms, with two distinct CPUs, three sound chips, bitmapped displays, tile-map and sprite displays with various planes and palettes. It was time to move on and consider the remaining aspects of the PACE hardware design before we commit to a PCB.
One task that we've neglected is a hardware audit of our target games. Chris, Amber, James & I have compiled a wish-list of classic arcade games that we'd eventually like to see (or otherwise deserve to be) running on the PACE board. We've reduced the list to a couple of hundred candidates that we realistically believe are achievable on current or next-generation silicon. Although we have the list, we really need to do a more detailed study of the resources and capabilities of each system to determine what our hardware must be able to emulate.
One requirement we have specified for PACE (in addition to VGA output) is composite video output - primarily for use on TVs. Whilst we could certainly add video chips to the board, it is a very instructional (and interesting) exercise to attempt to implement composite video directly within the FPGA. Aside from further refinement of the PACE design framework, it may even prove practical to forego any external chips and implement our own composite video logic after all.
Monochrome composite video is reasonably simple, and we've managed to get Space Invaders running on my TV (see photo). The composite controller is very preliminary and still undergoing refinement but gives an idea what we are able to achieve. Adding a few more resistors (well, ~25) and we have the Pacman tile-map displaying in 240 shades of gray. The sprites should be similarly straight-forward, but at this point will require some changes to the somewhat hacked-together video framework. A complete re-write of the VGA controller for our PACE hardware has always been intended.
I've just started on colour in the last day or two, with no success thus far.