Talk:Blast Processing

Blast processing: Relevance/marketing?
It seems like a lot of this information (namely, everything past the third paragraph) doesn't really relate to blast processing, as the original 3 paragraphs explain it quite adaquately. Perhaps the rest of it should be merged to the SNES and Genesis articles? --Zorath 14:04, 27 June 2006 (UTC)

+ I have to agree. Actually I think this is prime for the Non-NPOV tag, as it looks like the author is trying counter an advantage of the Genesis with an unrelated advantage of the NES which doesn't really address the specific issue. (Unattributed comment left by IP 208.152.231.254)


 * I dunno, the article doesn't seem too bad. I think more technical information on what Blast Processing meant would help a lot, but the part about how Blast Processing was advertised is relevant to the topic. --six.oh.six 23:01, 17 October 2006 (UTC)


 * I tend to agree with six.oh.six, in that it's not really POV. It seems to describe its subject quite well, and while I admit that describing a marketing term intended to make one product appear better than another is sometimes difficult to describe neutrally, this article does a good job of it.  SchuminWeb (Talk) 05:54, 18 October 2006 (UTC)

+ You guys are over looking one thing, Blast Processing was just a marketing term. No programmer on the planet had ever heard of it before Sega coined it in the advert. Witch was aired long after the systems initial release. The tech data submitted here is purely fiction, or a clever description of a programing process all CPUs use when rendering a scene.


 * To the guy Above me:

Blast Processing is a marketting term yes, but it is actually used in development. It holds strong resemblance with Double Buffering (Or in case of Blast Processing Triple or Quadruple Buffering). Those terms didn't sound nice and too technical so I think that that is one of the reasons why they called it Blast Processing.

Anyhow what Double buffering basically does is draw the next frame in memmory while the previous frame is drawn on the screen. Then when the frame is finished the Screen that needs to be drawn gets replaced with the one in memmory (read swap em around, the drawn frame becomes the memmory frame the memmory frame becomes the drawn frame). This was mend to stop games from flickering and having to draw the frame while it is being drawn on the screen. It also makes the game smoother.

But I'm pretty sure that Nintendo's SNES must have used this principle, I just think that the CPU of the Genesis alowed a bit more things to happen while it draws the buffer. But the SNES had more hardware capabilities. So it was Software vs Specialized Hardware ;).

The Genesis was made from standard parts. The CPU was a standard Motorola 68000 nothing special, a  TI TMS9918 VDP (used in many systems back then by the way), and Z80 for backwards compatibility with the master system. All basically off the shelf parts. The 68000 could not access the vram directly, the VDP had to do all the read/write work. Making what was described in this article "the ability for the CPU to be working on one visible section of map while the graphics processor displays another" impossible. ;)
 * To this guy here:

Genesis and SNES did not use frame buffers at all. The technique is common in today's computer graphic systems, but due to high memory prices it could not easily be used for those low cost systems. Instead, they computed the pixel data 'on the fly' when the tv reached the position of the specific pixel. You could only tell the gpu what tiles you wanted to be dranwn in the background and what sprites should be visible. So 'double buffering' here means 'preparing the settings for the next frame, while the gpu renders another one'. This actually could be done with Genesis hardware.
 * To the two guys above:

Consensus

 * I've removed the NPOV tag, as the article looks fairly neutral right now. I would like for someone to clarify, however, if Blast Processing was real, or simply a marketing term.  Just wait for a consensus on the issue before editing. Zorath 16:00, 22 October 2006 (UTC)


 * I think the NPOV status is valid as this article is reaching to make a connection between a pure marketing term and tech guidelines which are honestly too esoteric to be understood by most people, and which further did not confer upon the Genesis any special or unique advantages over other systems. It's basically the Amiga hardware, with a different VDP (based off the Master System's). Basically, there are three things for us to sort out:

1.) The term as used for marketing (already covered fairly well) 2.) Short bit about the origin of the term - compositing scenes and then moving them to the VDP in order. Not to be confused with double buffering, where you take a completed image and copy it into a frame. The VDP composits the image ordered by the main CPU and then draws it. 3.) Contrast with the SNES. We should note that too many variables have changed from the Genesis to the SNES for any direct comparison between one style and the other should be made. I think it might be best to hold off until somebody appears holding the technical expertise and knowledge to make a fair assessment of the two different architectures.

Also, I think it is fair to note that while the Genesis allows more "flexibility," that comes at a cost. The VDP is still fairly oriented on sprites and a 68000 processor, while powerful, is wasteful to use on graphics processing effects for 2D games (as opposed to a dedicated processor like the SNES). There are games the Genesis does that could not be done on a stock SNES (3D games come to mind - Duke Nukem 3D and Zero Tolerance, etc. didn't use any special graphics chip to my knowledge), but on the whole the SNES processor has more features available. It has been noted elsewhere that there is a drawback in the SNES as the main CPU, normally used for data fetches from cartridge, can be a bottleneck to performance and not an especially strong performer for the game program (i.e. AI routines).

Note that none of this is "set in stone," just what I believe to be true after a while researching the subject. --Edwin Herdman 03:23, 18 February 2007 (UTC)

F1 Car?
I just re-watched the advertising video on YouTube, and the car nerd in me needs to make one correction. The ad does not feature a Formula 1 car, but a Top Fuel Dragster. It's really an inconsequential detail in the larger scope of the advertisement, but I am going to make the fix. —The preceding unsigned comment was added by Nmhansen (talk • contribs) 19:07, 27 December 2006 (UTC).

Reference
I don't have time to figure out the tags to make it a formal reference right now, but the 1UP article linked to from this wiki article includes the text "Technically, it was to describe the way the Genesis could display one image while loading another into memory -- something the SNES couldn't do -- but few knew that." which is essentially the same as the claims made here. So that's one source that helps substantiate the content of this article — ThomasHarte


 * ahem* signed incorrectly (three tildes instead of four), I meant: ThomasHarte 19:35, 20 February 2007 (UTC)


 * Yes, this concept has been mentioned elsewhere. Let's make sure this isn't read as something bigger than it really was: simply an anomaly in the processing system that allowed the Genesis some flexibility, but ultimately was a bit of a drawback. 1up is essentially parroting comments that have been made elsewhere, so I wouldn't view that as a source giving a technical comparision or even a description (the concept has been mentioned elsewhere in better terms, it seems). Incidentally, if you sign something wrong, edit out the previous signature and update it as a minor edit. --Edwin Herdman 23:36, 20 February 2007 (UTC)


 * Well, it isn't really an anomaly and wasn't a drawback. It's an optional alternative way of working with the tilemap in the same way that any optional double buffer is an alternative to a single buffer. Surely the best thing to do would be to link to technical docs demonstrating that the Mega Drive has two tile buffers, and use the 1Up article as evidence that Sega decided that particular feature was going to be rebranded "blast processing"? Or have you a more authoritative source for the latter? — ThomasHarte 19:10, 21 February 2007 (UTC)


 * Let's see the sources! I'm just working off the information I've been able to glean from here and there, so anything more authoritative would be good. But I still doubt that a blurb on 1up is worthy of being encyclopedic (and I don't even know who wrote said article; not a slam on it, just an opinion that anything written mainly to meet the grind of article deadlines must be considered suspect when in consideration for entry in an encyclopedia). --Edwin Herdman 03:03, 22 February 2007 (UTC)


 * Okay, I've been looking at sources and I think the current content of this article is wrong. Obviously it's hard without somehow jumping into the mind of a Sega marketing executive to find out exactly which technical aspect was meant to be "blast processing" but here's my best guess:
 * go to and grab the file "SNES Memory". Unzip and open "snesmap.txt". Find the entry for "$2118/$2119" and note the comment "Data Can Only Be Written During V-blank Or Forced Blank Period." (sic). Using the CPU to write to these ports and waiting as necessary is, as far as I can find, the only way to write to VRAM on a SNES.
 * go to and grab the file "GENESIS Technical Overview 1995" (which appears to be an edited version of official Sega documentation, so probably the best source we'll get on the Megadrive). Note that it makes reference to a DMA engine for transferring stuff from RAM to VRAM (on the bottom of page 3 if you open the doc in MS Word, at least in Office:Mac v.X)
 * From that, it seems to me that "blast processing" is the act of taking the 68000 off the bus and letting the DMA do a block copy to VRAM. So it's a blast because it's a very fast act that interrupts normal operation, and being a DMA engine is much, much faster than an equivalent CPU copy, even though the 68000 is generally better at copying stuff than the 65c816 which is highly optimised for certain types of data layout but not good at general block copying.
 * Anyone else got an opinion on this? — ThomasHarte 21:12, 22 February 2007 (UTC)
 * "So it's a blast because it's a very fast act that interrupts normal operation, and being a DMA engine is much, much faster than an equivalent CPU copy" - all things being equal, which they aren't here! You're right that the 65c816 is a much worse processor for general usage (being designed mainly with 8-bit program compatibility in mind), so touting "blast processing" as some sort of advantage on a processor which is generally superior is not at all equivalent - the real story is that they wanted to turn the conversation over to "main" CPUs and disqualify the SNES's video processor from the conversation. Given that this article exists, it seems that this was not an entirely misguided course of attack...it says more about the ingenuity of Sega's ad people at the time than it does about the architectures of either system. --Edwin Herdman 10:23, 15 March 2007 (UTC)
 * You talk as if "blast processing" is some sort of pure marketing ploy, intended to fool consumers. In fact, it seems to have been a marketing ploy designed to turn people's attention to the strengths of the Mega Drive architecture. Having the DMA chip and the faster processor are in fact genuine advantages, for example it explains why software companies were experimenting with full polygon 3d on the base Mega Drive (see LHX Attack Chopper, Corporation, Steel Tallons, etc) whereas the same thing wasn't even really attempted on the SNES prior to the Super FX, which is in essence a hardware expansion. It's true that most companies had no ambition beyond the ordinary platforming dross and the Mega Drive CPU/DMA is no great advantage for that sort of thing, but that doesn't mean it wasn't a genuine advantage. — ThomasHarte 12:57, 17 March 2007 (UTC)
 * Sorry for my hiatus from the article, but something caught my eye: "...the real story is that they wanted to turn the conversation over to "main" CPUs and disqualify the SNES's video processor from the conversation." Well, given that that's exactly what I said in substance, it seems we agree. My concern is that an article on this issue needs to recognize that there really is no "blast processing," only a different architecture. That said, I think this is fixed right now in the article.


 * What isn't fixed is that the article claims that the Genesis can calculate "faster motion." Nothing of the sort, really, since "motion" relative to other objects or the boundaries of the TV window is not the issue here. Anyhow, editing that, give me a holler if the replacement doesn't work right. --Edwin Herdman 04:37, 26 March 2007 (UTC)

Talk page fix
Remember that anything at the top not prefaced by two = signs goes above the table of contents box. I hope nobody minds that I've reordered things a bit; it seemed wrong to have a few comments stand out while the others were buried. --Edwin Herdman 23:39, 20 February 2007 (UTC)

Dubious claims
The third paragraph of this article seems to be factually inaccurate with respect to the claims of what the SNES cannot do. While the Genesis can write its VRAM during the frame where the SNES cannot, are 16 bytes per line significant? I suspect these are used for updating the scrolling and palette data rather than the name tables. The SNES can also adjust palette data and scrolling per-line, only the sprite RAM and character/name tables are inaccessible.

The SNES does include a DMA unit (look at registers $420b and $43xx in snesmap.txt) (in fact, from the document mentioned above it looks like the SNES unit is actually more flexible than the Genesis version), and can double-buffer the next frame's sprite data and name tables in RAM as well as the Genesis. There is nothing requiring tracking "the current position of the electron gun" besides Super Scope aiming, and the tracking there is done in hardware with software needing only to act on the stored position.

Personally, I think the whole third paragraph should be deleted, or completely rewritten if someone can come up with a credible description of what "Blast Processing" might be besides a marketing term and a decision to create games with more frenetic scrolling. Anomie 16:34, 23 April 2007 (UTC)
 * I'd like to get some input from people who work on emulators; I imagine Steve Snake might be a good one to go to on the Genesis side of things. Finding somebody with good experience in both the SNES and Genesis would be difficult, but maybe doable. Of course, it's doubtful that we need to be trying to make theoretical comparisons of the two machines here, but I'd like to see it tried anyhow. Currently, I am leaning in your direction as the article just leans too much towards advocating some minor architectural detail as major. —The preceding unsigned comment was added by Edwin Herdman (talk • contribs) 07:57, 7 May 2007 (UTC).
 * I'll keep this page in my watchlist in case a Genesis expert shows up. Anomie 13:24, 9 May 2007 (UTC)

I have done unofficial work on Gens, the open source Genesis/MegaDrive emulator, and can tell you that while the third paragraph is worded a bit poorly, it is basically only making reference to the fact that the Genesis/MegaDrive basically has a hardware frame buffer that can be used to prevent lag from being overly visible. As for the minor architectural feature being ascribed major importance, I think that all falls into place when you consider that the article is about the line of marketing wherein the same minor features were given major importance. Upthorn 17:05, 26 July 2007 (UTC)
 * The Genesis has a hardware frame buffer? How does that work, when I did a wuick look through some docs I didn't see any mention of it. Anomie 21:16, 26 July 2007 (UTC)