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…
DMA.
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.
Multimedia Mike said
Heh, blast processing brings back memories. Silly memories. Those commercials inspired much contempt, perhaps for their condescending tone, but mostly for the utterly transparent marketing term. Besides, I doubt that any Sega marketing folks would be able to produce the letters ‘DMA’ if pressed to define blast processing.
I don’t doubt that the Genesis had some DMA facilities (and its grandchild, the Dreamcast, had extraordinary DMA hardware). But that doesn’t really distinguish it from its Nintendo competition– the NES had DMA (used for rapidly transferring 256 bytes from main memory to sprite memory). I would have to look up the SNES capabilities again, but I know it had DMA as well.
However, I always found it interesting that the Genesis was only marketed as a 16-bit console. The prevailing measurement for a console’s bit-ness at the time seemed to be the size of its internal registers. NES = 8-bit (6502); SNES = 16-bit (65816); but the Genesis had its 32-bit registers, courtesy of the 68000. Maybe Sega didn’t want to push their luck by claiming they had a 32-bit console when Nintendo was still on 8 bits.
Nate said
Mike, I think the reason they claimed the Genesis was 16 and not 32-bit is that they were already working on the 32X. That way they could sell the Genesis as leading the NES, and in a couple years, the 32X as leading the market in the “bit race”. Of course, this assumes the engineers actually gave the marketers this option. They may have been conservative in telling the marketers only the external bus size, and so they never had the option of saying differently.
Optimus said
I always thought that 68000 was a 16bit CPU. I was initially confused when reading here that it’s a 32bit processor. In wikipedia I just read that it is a 16/32bit and while it may have also 32bit registers the external bus is 16bit. Z80 also has 16bit registers but it’s considered an 8bit processor. What really defines the bits of a CPU? I once thought it was the external bus transfer or something but now I am not sure..
Trixter said
The “bit-ness” of any CPU is defined by the size of its internal registers. So that makes an 8088 a 16-bit CPU, and a 68000 (with it’s eight 32-bit general-purpose registers and another eight 32-bit address registers) most definitely a 32-bit CPU.
Both hobbyists and the media have repeatedly made mistakes about that. They tend to label CPUs as “8-bit” or “16-bit” based on the time period they were used the most and not based on their actual capabilities.
One of the most irritating examples of this is here:
http://en.wikipedia.org/wiki/List_of_8-bit_computer_hardware_palettes
CGA, in that list, is considered an “8-bit computer” graphics palette. After a ton of fighting on my part, I got the self-appointed article czar (ie. someone who simply reverts any changes not made by himself) to at least put this sentence in: “It must be noted that this n-bit distinction is not intended as a true strict categorization of such machines, due to mixed architectures also exists (16-bit processors with 8-bit data bus, for example). The distinction is more related with a broad 8-bit computer age or generation (around 1975-1985) and its associated state of the art in color display capabilities.”. Which is still wrong, but at least it’s detailed in why it is wrong.
Optimus said
Hmm,. interesting but I am still confused with that notion. Should the Z80 (and thus CPC, Spectrum, Gameboy and another hardware with this CPU) should be considered as 8bit or 16bit. It sounds a bit vague to say the second. Actually are there some rules about these registers? The 16bit registers on Z80 take more cycles for the same operations than the 8bit registers. They are build as pairs of the primary 8bit registers. Maybe the opcodes that utilise these 16bit registers are really doing work on the pairs of the 8bit registers and not in real 16bit registers. Did the Amiga 32bit registers spent the same cycles for primary operations as with it’s 16bit registers? (at least not the ones that needed communication of CPU with the external world). Are there some signs that they are true 32bit registers and not I presume something like on the Z80 with it’s 16bit registers made out of 8bit pairs (and this hidden by opcodes seeming to operate on true 16bit registers)? I am a bit confused here and maybe I confuse most of you too :)
Optimus said
[quote]Both hobbyists and the media have repeatedly made mistakes about that. They tend to label CPUs as “8-bit” or “16-bit” based on the time period they were used the most and not based on their actual capabilities.[/quote]
This is true. A lot of people (even programmers) have asked me whether the Atari2600 is a 4bit console because they compare graphics and age. I’d say to them it’s 8bit because it has a 6502 if I recall well. Another point is whether the bits of CPU is also defining the bits of a computer or console. There are so many different hardware there with different bandwidth. I am still confused with the Atari Jaguar which for obviously marketing reasons was presented as a 64bit console (it has a 68000 CPU and some custom gfx chips iirc). I am not sure whether it can be said about a computer that it’s n-bits. Many PCs have a 32bit CPU (except the new Athlon64) and are way ahead of others.
Trixter said
Yes, an additional clarification is the size in bits that single instructions operate on.
So let’s take the 8086: It has a 16-bit memory fetch, 16-bit registers, and operations occur across all 16 bits for most instructions that use 16-bit registers (ie. ROR AX,1 will indeed rotate all 16 bits in the AX register to the right). Nobody would argue that it isn’t a 16-bit CPU.
Here are some common areas people trip up in describing the 8086 as anything other than a 16-bit CPU:
“Does that mean it is limited to 2^16 memory (64KB)?” No, the combination of two 16-bit registers allow the 8086 to access up to 1MB — but that doesn’t mean it is now magically a “20-bit” CPU.
“The MUL and DIV opcodes can generate/divide 32-bit numbers stored across two registers (DX and AX); does that make it a 32-bit CPU?” No, because the 32-bit value is stored across two 16-bit registers.
“The 8088 only has an 8-bit BUS and can only fetch 8 bits at a time from memory. Does that make it an 8-bit CPU?” No, because internally it still operates on all 16 bits at a time.
It is the media’s insistence of trying to group consoles and computers into “eras” that perpetuate bit-ness misclassification.
Regarding the Jaguar, it truly was a 64-bit console, as it contained two 64-bit RISC processors with 64-bit internal registers.
mesa said
Just want to add a (very late) correction to this article. Blast Processing is indeed DMA, but it is one specific use of DMA – using it to rewrite the palette during display time, giving a full 512 colour picture, albeit with an inconsistent pixel size (as the dot and CPU clocks don’t sync up quite right). The name is a misunderstanding of a techie speaking of ‘blasting data into the DACs’.
Despite Sega’s marketing, this wasn’t used in a single Megadrive/Genesis game – probably because the timing broke depending on what revision machine you had.
Trixter said
Thanks for the clarification! But didn’t Eternal Champions use it? If not, how did they get more than 256 colors onscreen?
TapamN said
There’s so much wrong with that that I don’t know were to begin. I guess the first would be that the SNES did have DMA, and DMA was used frequently on all systems.
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,
Multiple DMA VRAM copies during vblank were how games did scrolling and animation. It was even common on the NES: games would transfer sprite position data via DMA during vblank. The Master System, Genesis, and SNES used DMA to upload new frames of animation to VRAM, update tilemaps, and sprite position data.
And the point of VRAM is that it takes little effort to do large copies, independent of the CPU speed, so your argument about how the Genesis CPU is powerful enough to use DMA makes no sense.
Blast Processing is indeed DMA, but it is one specific use of DMA – using it to rewrite the palette during display time, giving a full 512 colour picture, albeit with an inconsistent pixel size (as the dot and CPU clocks don’t sync up quite right). The name is a misunderstanding of a techie speaking of ‘blasting data into the DACs’.
You visit Beyond3D? (Or saw it repeated somewere else…)
Despite Sega’s marketing, this wasn’t used in a single Megadrive/Genesis game
…then why was Sega claiming that blast processing was making Sonic 2 faster than ever, when it was never used?
FYI, there’s some homebrew demos that do more than 512 colors, IIRC, there’s one that does 960 with the shadow/highlight colors.
mesa said
This the CD or cart version you’re asking about? Regardless, I’ve had a look and I can’t find a screenshot of either with more than 64 colours on, so I suspect the >256 colours claim was rubbish.
Mike Sylvester said
I don’t think more frames could be stored with more than 64 colors, but with palette swaps between scans, there would be more colors per frame on the screen.
Multimedia Mike said
I was re-reading this post today and it reminded me of this “toasted” clip from the show Mad Men:
http://www.youtube.com/watch?v=E0L8f1IY1Vk
In case the clip gets yanked, it shows an advertising executive trying to come up with a new marketing campaign for a cigarette manufacturer. He asks the tobacco man to describe the manufacturing process and when Big Tobacco mentions the “toasting” step, the ad man finds inspiration.
Cigarette Guy: “Everybody else’s tobacco is toasted.”
Ad Man: “No. Everybody else’s tobacco is poisonous. [Your cigarettes] ‘are toasted.’”
I can just envision a similar conversation taking place between Sega and their marketing firm:
Ad Man: “Describe how the Genesis works, internally.”
Sega: “Well, it has a CPU, some RAM, some DMA hardware that blasts data around between processors…”
Ad Man: “That’s it! Sega has ‘Blast Processing.’”
Sega: “But Nintendo’s console also has DMA facilities.”
Ad Man: “No, Nintendo’s console can’t get out of first gear. Sega’s console is a formula-1 race car.”