Blitter Information

Defender, Stargate, Robotron, Joust, Bubbles, Sinistar and Splat all run on very similar hardware. The video display is a bitmap; each byte of RAM is displayed as two pixels. There are no sprites. That means a lot of data has to be moved around in memory while the game is playing. Defender and Stargate use just the CPU to move that data. It's a testimony to the 6809 and the programmers that a 1MHz CPU can do that.

The Williams games that came after Defender and Stargate were augmented with direct memory access hardware. Two integrated circuits (the Special Chips) were added to the ROM board. These chips can move blocks of memory from one place to another without using the CPU. Since they do block transfers, they are also known as blitters. When a program writes to registers on these chips, the CPU is halted and the chips take over the address and data busses, reading data from one memory location and writing it to another. Each Special Chip handles 4 bits, which is one pixel.

The CPU takes several 1 microsecond bus cycles to read a byte and write it somewhere else, while the Special Chips can copy a byte from anywhere in ROM to anywhere in RAM in one 1 microsecond. This order-of-magnitude speed increase is nice, but the Special Chips offer other functionality, as well:

1. They can shift the source data right one pixel when writing it. This is extremely useful because every byte of RAM holds 2 pixels. To move a shape horizontally one pixel is too time-consuming for the CPU to do quickly, so Defender and Stargate had duplicate images of every shape, with the second copy shifted one pixel right. The Special Chips handle this task at the same speed as a regular copy. Since the duplicate graphics are no longer needed, a lot of ROM space is freed up for additional shapes or more complicated game programming.
2. They have a mode where color 0 is not copied to the destination, allowing for transparency. When this mode is used, pixels that are color 0 in the source data remain untouched in the destination, allowing for non-rectangular shapes, or even shapes with "holes" in them where the background shows through.
3. Instead of copying bytes from the source location, the blitters can be told to replace the destination pixels with a given color. Coupled with transparency, this is used to draw text, as well as in effects such as player materialization in Joust.
4. Screen memory is setup such that successive bytes are displayed below one another; the next pair of pixels to the right of the previous are 256 bytes away in memory. This is an awkward format to store graphics in the game program, though; it's much easier to store them in memory one row after another. The Special Chips can take pixels stored sequentially and blit them to the screen in its format. (Another way of saying this is that the blitters can take source data with stride 1 and write to the destination with stride 256; actually, both source or destination can have either stride 1 or 256, independently.)
5. RAM used for screen memory is being accessed half the time by the video hardware to display the graphics on the monitor. The blitters have to respect that, or else there is bus contention and data is scrambled. So blits from RAM to RAM have to run at half speed, 2 microseconds per byte. Blits from ROM to RAM, or from Sinistar's extra RAM to video RAM, can be done twice as fast.
6. Either or both of the even and odd pixels can be suppressed from being blitted. I guess you could use this for special effects.

The basic operation of the blitters has been understood for some time from disassembling game code- there are 6 registers: address 0xCA00 is the control byte; writing it starts the blit. The value written to it determines the "flavor" of the blit: the source and destination stride, if the data is shifted, if a solid color is blitted instead of the source data, if transparency is used, etc. Address 0xCA01 is the solid color that can be substituted for the source data, 0xCA02-0xCA03 are the source address high and low bytes, 0xCA04-0xCA05 are the destination address high and low bytes, $CA06 is the width in bytes and $CA07 is the height in bytes. There is a bug in the Special Chips that requires bit 2 of the width and height to be inverted (XOR 4). The later version Special Chip 2, used in Splat and the more advanced games such as Blaster, Mystic Marathon, Joust 2, Turkey Shoot, etc seems to have the same functionality, but the width and height bug is fixed.

The core functionality of moving a block of data in memory is accomplished with 4 counters: one 16-bit counter for the source address, one for the destination address, one 8-bit counter for the width, and another for the height. The counters are preset to the values written to the registers. The CPU is halted, giving the Special Chips free access to the address and data busses. The source address is put on the address bus, and a read is initiated. That puts the value stored at that address on the data bus, which is read. Then the destination address is put on the address bus and the data byte on the data bus, and a write is initiated. The source and destination addresses are incremented. If the width is greater than zero, it is decremented and the process happens again. If the width is zero, the height is decremented. If the height is greater than zero than the width is reloaded with the initial value and the process happens again. Eventually the width and height are both decremented to zero and the blit is finished; the CPU is allowed to run again.

In older versions of MAME and in several xx-in-one boards, blits happen pretty much instantaneously, unlike the real games where the Special Chips have a maximum throughput of 1 MB/second (not counting the time it takes to write to the registers to start the blit). This results in games that appear normal at the beginning levels, but become much harder at the later levels. Robotron can have so many enemies on screen at once that all cannot be moved in one video frame. So the game moves as many as possible, then moves the rest in the next frame. With an "instantaneous blitter", all the enemies can be moved in one video frame, making the game play much faster. This is masked in the lower waves because time delays are added to make the game easier in the beginning, but the later waves are much harder than on a real game.

MAME fixed this one some time ago, making the emulation much better. But it did not implement SLOW mode for RAM-to-RAM transfers until recently, since its emulated hardware doesn't have that restriction. And without a schematic or even instructions as to how the Special Chips actually work, the details of many features were figured out by trial and error and lots of test play to see how the games were affected with each change. For instance, what happens if you specify a width or height of 0? Does anything change if you do a blit with both even and odd pixels suppressed? How exactly does shift work? What are the largest and smallest blits that you can do?

In order to better understand how the Special Chips work, I wrote a program in 6809 assembly language that performs a couple hundred blits with different parameters. I timed how long it took to do 1000 blits with each set of parameters, then dumped memory to a file to see exactly what the results of each blit were. Before each blit, the first 1/4 of RAM was cleared, the next 1/4 set to 0xFF, the next 1/4 to 0xA5, and the rest to 0x5A. I ran this program on two Joust machines, using 5 sets of Special Chips to see if there was any difference; there was not. I also ran this under MAME version 0148.

About 13% of the blits had different results in MAME than on the real game, and about 11% of the blits took a different amount of time in MAME than on the real game. I'm sure that these blits represent a very small proportion of blits done in actual game play, but they may still contribute to game play anomalies.

After making modifications to the MAME source code to make the results match, the blitter code is actually simpler than before; this makes sense, since the Special Chips are not programmed CPUs, but a collection of logic gates. That means that they probably don't have a lot of if-then exceptions that code would have, but use a more straight-forward approach.

This information may be useful to people creating multigames, either emulated with CPUs, or in hardware using FPGAs. Here is a table showing the blitter parameters that I tested, a CRC of memory after 1000 blits, and time it took per blit (in milliseconds). There are links to the test program source code and the memory dumps from an actual Joust machine for all the blits. The dump file consists of 16 bytes containing the parameters for the blit, then 49,152 bytes of RAM, repeated for all 256 blits. Note that the first entry in the table isn't actually a blit: I ran through the loop 1000 times, but instead of storing the control byte at $CA00 to start the blit each time, I executed NOPs. This gives baseline timing that can be subtracted from the times in the table to obtain the time spent doing the actual blit.

My program

Memory dumps

A few things of note: using a width or height of 0 gives the same results as 1. Even if the odd and even pixels are suppressed, the destination will be changed if the mode is FOREGROUND ONLY. A SLOW blit of 255x255 bytes (which is larger than RAM so probably not useful) takes just very slightly less time than the watchdog timeout (255x255/500,000=0.1301 seconds versus 8/60=0.1333 seconds). A blit can write to $CA00, which will cause another blit, and can cause an infinite loop of blits, until the watchdog resets the game.

Here's a list of the Special Chip signals:

• /EVIE - chip select input, active low. Decoded on the ROM board; low when addresses $CA00-$CAFF accessed.
• /BABS - input from CPU board, active low. Logical not of (CPU BA and CPU BS). Low when CPU is halted.
• /4MHz - input from CPU board. 4MHz clock.
• /E - input from CPU board. Inverted CPU E signal (1 MHz).
• /HALT - output to CPU board, active low. Request to halt the CPU.
• /WINHx - output to CPU board, active low. Write Inhibit Upper and Lower. When low, inhibits writes to upper or lower nibble. Used for FOREGROUND ONLY mode.
• R/W - Bidirectional. High means read, low means write. Driven by Special Chips while blitting.
• /RESET - input from CPU board, active low. Reset signal - stops blit. Registers are unaffected.
• A15-A0 - address bus. A7-A0 bidirectional, A15-A8 output. Driven by Special Chips while blitting.
• D7-D0 - data bus. Bidirectional. Driven by Special Chips while blitting.
• PIN2 - Input signal between Special Chips. UPPER pin 2 grounded. LOWER pin 2 to UPPER pin 3. Labeled TCF in Mystic Marathon schematics.
• PIN3 - Output signal between Special Chips. UPPER pin 3 to LOWER pin 2 mirrors /HALT. LOWER pin 3 has 1 pulse per horizontal row blitted. Labeled /HTCF in Mystic Marathon schematics.
• PIN10 - input. Grounded on both chips. Usage unknown.
• PIN14 - input. Assumed chip address: high means UPPER, low means LOWER.
• PIN15 - +12V, but ROM board not supplied with 12V. Maybe previous version required 12V in addition to 5V? N/C on Mystic Marathon schematics.
• PIN24 - input. Grounded on both chips. Usage unknown.

I decapped a Special Chip 1 and took photos of the die. It has 38 pads, whereas the chip has 40 pins. Looking at the die, I think that pins 15 and 24, +12V and one of the grounds, weren't connected to the die. I also now think that pin 5, connected to /HALT, is actually an input, and the /HALT signal is generated by the LOWER chip's pin 3.

Here is the modified MAME blitter code from src/mame/video/williams.c

The actual hardware does not read the destination byte to implement transparency- it has a signal that inhibits writes to the upper and/or lower nibbles. Likewise, I'm guessing shifting isn't done in hardware with a 16-bit shift register like MAME does it. Of course the actual blitter is spread out over two identical Special Chips, one for the lower 4 bits and one for the upper. They must work simultaneously; if they worked sequentially, blits would take twice as long. I found that if the UPPER Special Chip is removed, blitting still occurs, although it is corrupted. If the LOWER one is removed then no blitting occurs. Looking at the UPPER chip with the LOWER one removed, the logic analyzer shows that writes to $CA00 do not cause the CPU to halt. With LOWER removed, if you pull pins 3 and 14 of out of the socket, ground 14 and connect 3 to pin 5, then it acts just like when UPPER is removed and LOWER is present. This means that LOWER is the master, and pins 3 and 14 tell the chips which is master.

After running these blits, I thought of some other cases, and ran another 222 blits, including many with overlapping source and destination addresses. My modified MAME code matched the results from both Joust machines, except for a few blits where I accidentally did RAM-to-RAM blits without the SLOW bit set. This caused the Special Chips and the video circuitry to fight each other to drive the address bus, so data was read from incorrect locations. The same blitter parameters sometimes resulted in slightly different results on the same machine, and always a little more different between the two different machines. It's probably not good for the Special Chips to do this!

I also ran some more test cases to answer specific questions:

• Q: Can you write to the color registers with the blitter?
• A: Sort of. Colors changed, but not always to what I set them to. I used a logic analyzer to figure out that the blitter was changing the address and data before the color RAMs' write enable signal became inactive.
• Q: Can you read the blitter registers?
• A: No. They are write-only. And a read of $CA00 does not start a blit - just a write.
• Q: Do you have to set all the registers every blit, even if the data is the same as the last blit?
• A: No - all registers retain their previous values, until written again. Even if you reset the game!

Here are some pics from a logic analyzer capture of the following code:

	lda		#0xff
	sta		blitter_mask
	ldx		#palette1
	stx		blitter_source
	ldx		#color_registers
	stx		blitter_dest
	ldx		#0x0514		;1x16
	stx		blitter_w_h
	lda		#0x04		;slow
	sta		start_blitter

	ldx		#blitdata
	stx		blitter_source
	ldx		#0x2880
	stx		blitter_dest
	ldx		#0x1414		;16x16
	stx		blitter_w_h
	lda		#0x02
	sta		start_blitter

I captured 8 control signals and the lower 8 address bits. I didn't notice until later that the test clip on A4 had fallen off. After the write to $CA00 to start the blit, the Special Chips assert the CPU signal *HALT. After the current instruction ends, the CPU sets signals BA and BS high, which results in the game signal *BABS going low. After nearly one instruction cycle, the blit begins. When the blit is done, *HALT is de-asserted, and after nearly 2 instruction cycles, *BABS goes high and the CPU starts running again.

overview of both blits The top signal shows writes to the Special Chip registers.

close up of first blit 16 bytes in SLOW mode

close up of second blit 256 bytes at full speed

HALT timing diagram from 6809E datasheet. It's confusing (and I think incorrect). The MC6809-MC6809E 8-Bit Microprocessor Programming Manual says "When BA goes low, an additional dead cycle will elapse before the processor regains control of the buses." This matches what I see.

I also captured the Special Chip signals and A7-A0 at 16MHz using a Saleae Logic 16 while doing one of each blit in the same order as the table above. Here is the capture of the "upper" Special Chip, and here the capture of the "lower" one. You can download Saleae's Logic software to view the captures in detail.

I'd like to purchase some Special Chip 2s to test them as well. If you have some, please email me.

Thanks to Mike, I was loaned a couple of Special Chip 2s to test. Other than the height/width bit 2 inversion bug, they tested out identical to the SC1s. I would still like to purchase one or two to decap and compare in detail.

Special Chip 1s are labelled VL2001; some have paper labels glued over them that say "SPECIAL CHIP 1" or "SPEC CHIP 1". The ones I have are date-coded 8220, 8224 and 8250. The manufacturer name is shown as VTI or VLSI, which is VLSI Technology, Inc..

Special Chip 2s are labelled VL2001A, with VTI's logo. The part number being the same with just an A suffix seems to indicate that there were only slight changes, perhaps only the height/width bug fix.