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.
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.”
Oldskooler Ramblings 
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..
Scali said
It is officially a 16/32-bit hybrid. That’s how Motorola marketed it, and how companies like Commodore and Atari advertised the CPU in their systems as well (The ST actually stands for Sixteen/Thirty-Two).
The instruction-set is 32-bit, but the databus is only 16-bit, as are most of the execution units.
Since the databus was only 16-bit, it would interface with 16-bit chipsets, which is why the systems using a 68000 CPU were always advertised as 16-bit machines.
There is no clear definition of ‘bitness’ of a CPU, or a system, because most CPUs and systems are a hybrid of some sort.
Scali said
“Officially” as the term “16/32” is literally what it says in the Motorola documentation.
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.
Scali said
See above, the 68000 is not a full 32-bit CPU, and Motorola never claimed it was :)
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?
ModernDayWarrior said
They didn’t. Have you even seen a screenshot?
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:
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.”
andy said
Both Snes and Genesis have DMAs but the Genesis has better DMA than the Snes has.
1) Snes’s DMA is 2.68 Mbps, whereas Genesis’s DMA is 3.35 Mbps
2) Snes can’t DMA during active display at all, whereas Genesis can, only at a slower pace.
3) Snes’s sprite pattern table is only 16-kB of the 64kB v-ram. Genesis can store sprite patterns ANYWHERE in it’s 64kB of v-ram just as long as you leave room for everything else. Snes is forced to DMA sprites more often, despite having the slower DMA.
4) A 16×16 sprite on the Genesis is stored with it’s bottom 2 8×8 tiles stored directly after the first. On the Snes a sprite patterns are stored in two tables that are both 16 tiles x 16 tiles with tiles being 8×8 pixels, and a 16×16 sprite is stored with the top half in one row of tile patterns, and the bottom half in the row underneath. Thus 2 dma fills are required on Snes, compared to 1 on the Genesis.
Trixter said
Thanks for the clarification; I was unable to get these details through conventional searches.
Someday I’d love to know how (and WHY) the Road Rash engine was made. Someone told me once that the inner loop ran in the vblank interrupt yet took several vblanks to execute (evidenced by the low framerate of the game); it also appears that sprite resizing is happening on the fly, as I was — moving very slowly through the game world — counted much more mipmaps than could be stored in 64k of vram. Interesting stuff.
munch said
I would like to clarify also that the 68000 is a 16-bit CPU, not a 32-bit CPU. Why? It’s not because of register width, but it’s because of ALU width. The processor is able to crunch only 16 bits of data per clock cycle. If register width alone were the sole determinant of “bitness,” the Intel 8080 and 6809 both would be considered 16-bit CPUs. Observe that Motorola did not include the 68000 or 68010 in the CPU32 architecture family.
Does this make the 65816 an 8-bit CPU instead of the oft-repeated claim of being a 16-bit CPU? I really hate to admit it, because I really love the CPU, but yes it does. But, because it’s a little-endian CPU instead of big-endian, it can afford to overlap 8-bit processing of 16-bit quantities with fetches for operand bytes, so it looks very much like a real 16-bit CPU (limited naturally by an 8-bit bus). Contrast the 65816 with the 68008, however, which despite its 8-bit bus, remains a true 16-bit CPU (since it has a 68000 core). Another example is the Intel 8088, which has an 8-bit bus, but is otherwise a 16-bit processor.
I think this is all semantics though. At the end of the day, I’ve seen 32-bit CPUs run slow as a dog (*COUGH*386*COUGH) and some 8-bit CPUs blow past its 16- and 32-bit competition (1MHz 65816 against 4MHz 80286, 50MHz Z80s, etc.). The moral of the story is, frankly, who cares? Write your code, and measure its performance. Optimize accordingly, and if it still doesn’t meet your performance requirements, migrate to another architecture.
Trixter said
I can agree on ALU width. That’s a good measure.
bhtooefr said
Using ALU width gives you some fun side effects, though, as far as bitness measurements go.
Z80 becomes a 4-bit CPU (and therefore the Master System, Game Gear, and Game Boy all become 4-bit consoles, if you want to play that game), Pentium 4 (even the “EM64T” ones) becomes a 16-bit CPU IIRC (Intel made the ALU half as wide so that they could clock it up faster on the NetBurst chips).
IIRC, that’s why width of general purpose registers became the standard – because as far as software’s concerned, except for timing, the Z80 is 8-bit, the 65816 is 16-bit, the 68000 is 32-bit, and the Pentium 4 is 32 or 64-bit depending on version.
BillyHW said
“Bitness” is measured in different ways and different contexts. The whole idea was a marketing crock of $hit to begin with. Same with MHz. Trying to discern meaning simply by comparing these numbers is useless. I’m so glad we’ve moved beyond all that lately.
Trixter said
MHz is a perfectly valid measure of computing speed if the processors are from the same family. For example, it’s obvious that a 386dx-16 is slower than a 386dx-40.
Blast Data Processing: DP and the games industry « Brodies TechBlog said
[…] I could find, and humourlessly lecturing my Nintendo-owning friends about the merits of Blast Processing. (Sega’s European marketing, incidenally, was carried out by Virgin Interactive – a […]
Blast Processing? « Jump'n Shoot 9000 said
[…] more highbrow discussion? Share this:TwitterFacebookLike this:LikeBe the first to like […]
Blast Processing? | Jump'n Shoot 9000 said
[…] Some more highbrow discussion? […]
On the X Box Backpedal and Digital Distribution | Quijano: On Stuff said
[…] processing” was eerily similar to Sega’s early 1990s concept of “Blast Processing” – a fancy marketing term for Direct Memory Access, which improved processing speeds […]
Neb6 said
Blast processing appears to be an implementation of the Blitter (the hardware accelerator in the Amiga and Atari STE machines that was prototyped in the Atari 8-bit computers).
Take a look at how the term is referenced in this Emulator programmer’s forum:
http://dextremes.com/genesis/gen-spec.html
If you see terms like BitBlt, Blitter, Bimmer, or Bit Block Transfer, you’re likely dealing with a blitter GPU.
Neb6 said
I suppose I should give you the actual link and not just the basic specs. The following link includes programming information for the purposes of creating a Sega Genesis/MegaDrive emulator.
Note the use of the word “Blitting”:
http://www.aep-emu.de/PNphpBB2-file-viewtopic-t-19870.html
Blast Data Processing: DP and the games industry | blogs said
[…] I could find, and humourlessly lecturing my Nintendo-owning friends about the merits of Blast Processing. (Sega’s European marketing, incidentally, was carried out by Virgin Interactive – a […]
Blast Processing - GameReport said
[…] paso del tiempo hizo el resto, y hoy en día hay que acudir a páginas de fans como Oldskooler Ramblings o Sega Retro para descubrir que este término era algo más que palabrería de charlatán […]
Michael Latham said
Bayless and Franz didn’t create the term. The term was created by a marketing person and producer who told her about the burst mode as it was noted in the Sega technical manual. She wanted anything that the Genesis could do that Nintendo didn’t match. She said the term burst mode didn’t sound sexy and renamed it to blast processing. There was a later meeting with Bayless joining to help find a better technical explanation but the term and commercial were already under way. So I’m not sure why this falsehood persist as in all books about Sega the story is covered correctly. In only one book which is SEGA Mega Drive/Genesis: Collected Works is the story not correct and it is currently about to be re-printed and will make the correction to the origin story as stated above.
Blast Data Processing: DP and the games industry | Recent News said
[…] I could find, and humourlessly lecturing my Nintendo-owning friends about the merits of Blast Processing. (Sega’s European marketing, incidentally, was carried out by Virgin Interactive – a […]
Parece que o "Blast Processing" do Mega Drive era real, afinal... - Memória BIT said
[…] explicou o programador Jim Leonard em seu […]
marketing said
marketing
Blast Processing 101 « Oldskooler Ramblings