Oldskooler Ramblings

the unlikely child born of the home computer wars

Archive for December 5th, 2008

Blast Processing 101

Posted by Trixter on December 5, 2008

I hit my inaccuracy limit today listening to the umpteenth oldgaming podcast to refer to Sega’s “blast processing” as only a marketing gimmick.  The common reference goes something like this:

…which many people assert was a completely factitious term invented to sell Sonic the Hedgehog carts.  Not that it makes much difference nowadays, but I want to set the record straight:  Blast Processing was not just marketing; it was a real hardware feature that could drastically speed up certain operations.  Marketing only chose the term Blast Processing because its real name is fairly dull and boring.  Blast Processing was… get ready for it…


In layman’s terms, a DMA controller is typically added to a system to assist in copying memory around independently of the CPU.  The CPU can issue a memory operation, and then perform other calculations while the memory gets shuffled around by the DMA controller.  For example, the original IBM PC has an Intel 8237 to offload the task of moving data between main memory and I/O ports, because I/O operations are typically incredibly slow and it’s a waste of everyone’s time to have the CPU wait for I/O to get its ass in gear and cough up the next byte/word.  So the 8237 does this, and the CPU is free to perform other work.  If you’ve ever wondered how early DOS backup programs were able to update the screen and compress data while the floppy drives were fully active, you have the 8237 to thank for it.

So what did DMA do for the Genesis?  Actually, not as much as you would think, but it did help out.  As confirmed by Bruce Tomlin, Genesis had a DMA unit which could be programmed to do copies and fills both to and from main memory, as well as VRAM-to-VRAM copies, with an arbitrary increment so that you could do column fills as well as row and block fills.  During display time, it was about the same speed as doing CPU writes, but — here’s the part that could arguably be called “blast processing” — during vertical blanking it was much faster than the CPU.  You may not think that the CPU in a console could get everything ready fast enough to take advantage of VRAM copies during the vertical blanking interval, but you have to remember that the Genesis sported a 7.6MHz 68000 — a 32-bit CPU with no less than 8 32-bit general-purpose registers as well as 8 address registers.  That is huge, and Genesis could easily give the DMA controller enough to do.

So there you go.  While the name could have been better chosen, it was a real thing that could offload a significant amount of work for the CPU.

Update:  It turns out that the creator of the term Blast Processing has publicly apologized for the marketing.  Read that link, not because of the marketing but because it goes into detail as to what exactly Blast Processing was referring to.  Quite specifically:

“Marty Franz [Sega technical director] discovered that you could do this nifty trick with the display system by hooking the scan line interrupt and firing off a DMA at just the right time. The result was that you could effectively jam data onto the graphics chip while the scan line was being drawn – which meant you could drive the DAC’s with 8 bits per pixel. Assuming you could get the timing just right you could draw 256 color static images. There were all kinds of subtleties to the timing and the trick didn’t work reliably on all iterations of the hardware but you could do it and it was cool as heck.”

Posted in Gaming | 36 Comments »