As of the past month or so, I have been putting together a core for 2 games: NARC and Smash TV. More specifically, I have been writing a CPU/GPU core for the TMS34010 processor.

About How it Started

Originally, back in September, I found some older boards in my garage that I was transferring to storage. One of the boards I found, was NARC. I have very good memories of playing this game both when I was younger and also many years ago, so I thought of the idea to put a core together for this game.

The board isn’t particularly complicated, but it’s a series of 4 boards. There’s the main board, then ROM sidecar board, as well as I/O and sound. So, it’s a pretty large array of boards you have to string together to make the game work, and there’s a transformer thing that generates the power for all the boards.

In doing some research about the technicals of the game, I found that much of the work is really delegated to the TMS34010 CPU/GPU chip. There are a couple of 6809s that power the sound, but it’s not too complicated. Generally about 85-90% of the functions are accomplished by the TMS chip itself. So I knew that in order to progress, I’ll have to get into creating a core for this CPU.

Faced with lack of time due to other work projects going on, I thought I might be able to hire someone to create the CPU core for me. This turned out to be a big disaster, and the guy did not progress at all in 2 months of working on it. Motivated to proceed forward, I decided to take up the work personally in the beginning of December.

I had never actually done a CPU core before, so I didn’t know what to expect, but actually after reading all the information it was actually a lot simpler than the Raizing system and the GP9001. So, I started writing code for the CPU a week after looking through and understanding the design better.

About the TMS34010 CPU

The CPU itself actually is not complicated. It’s large, but it’s not complicated. It has a very simple structure that involves opcode processing, decoding, execution and interrupts. There are computational, memory and graphics instructions. The CPU was designed to be connected directly to DRAM, so it has a controller that allows it to interface with RAM (and ROM). In addition, it also handles all graphics drawing through blitter and fill instructions, handles blanking and all other video outputs as well.

From a graphics point of view, the system isn’t as complicated as the Raizing system. In the Raizing system, there are various tile layers and hardware based tiles and sprites. The TMS CPU only has blitter, so it’s basically just pushing pixels. The Game program is responsible for creating an organization system to do that (ie. Sprites, layers, etc.).

I am about 90% done with the CPU after about 3 weeks of work. It is composed of over 7000 lines of verilog code and covers mostly all the functionality needed to make the core work.

There are some design changes I’ve done to make life easier for consuming and using the CPU:

• Originally, the local data bus is triple multiplexed and outputs addresses and data as well as intakes data from the same pins (16 bits in length). So because the CPU has 32 bit addresses, it will use a complex scheme that transmits row and column information in specific cycles and then data, etc. It was designed to be connected to multiple DRAM devices at once, so a subset of the pins actually are replicated so that different devices can be connected without overlapping the same bus pins.
• Obviously, this system is not practical for FPGA use. I’ve replaced it with a 32 bit line going out, and separate data in and data out lines that are 16 bits.
• In addition, I’ve built in support for write masking in the DPram module I use as the CPU uses addresses that are bit-based. So, you have situations where your writes should not affect all 16 bits of the memory. It might give you something in the middle, overlapping multiple successive addresses, etc. So you need flexibility to perform writes without retrieving the data and manipulating it, then writing back again which wastes cycles.
• I’ve also added conversion functions to convert from 1-bit addressing to 16 and 8 bit addressing so I can work with things easier in the core outside the CPU. Internally, the CPU uses a 32 bit internal bus and 1 bit addressing.
• Generally the manual is very helpful for the CPU, and everything is completely documented. All algorithms and functions are explained clearly with test cases and examples that are simple to follow, so it wasn’t too hard to implement.

About NARC

NARC was the first game ever to use the TMS34010 CPU. It was also the first game to use digitized sprites with actors and the first game to feature the famous attract mode FBI logo. It was a big budget game that Eugene Jarvis put together at Williams that also had many ports to other consoles, though none quite as good as the NES version. The arcade version of the game runs in high res, something like 512×400, and the graphics look clean, and violent. Speaking of which, NARC was also the first game in the “ultra violent” game category. So, a lot of firsts for NARC.