When it comes to emulator design, there’s something to be said for trying to capture the workings of the original system as accurately as possible, warts and all. But there’s also something to the idea that emulators can improve on the original hardware, smoothing problems like frame rate slowdown that plagued the underpowered processors of the day.
That brings us to the latest update for storied, accuracy-obsessed SNES emulator bsnes, which adds the ability to overclock the virtual SNES processor. While bsnes is far from the first SNES emulator to allow for simulated overclocking, it does seem to be the first that does so “without any framerate or pitch distortion, and without harming compatibility in 99% of games,” as bsnes programmer byuu puts it.
“Blast-processing” had nothing to with the SNES or overclocking. It was simply a hardware trick on the SEGA Genesis that allowed data to be pushed to the graphics chip while a scanline was being drawn. I forget the exact mechanism that allowed it, but I do know that it was extremely unreliable and didn’t work with all versions of the hardware so it was never actually used in any retail games.
SEGA used the term in their advertising campaigns, but it was basically weapons-grade bolognium.
And what does have it (supposedly) allowed to do ? Changing color palette like on the Atari ST and displaying more than 16 colors on each line ?
Kochise,
I think it was something like that. I believe it would change the color of every pixel during the active scan, but getting the timing right was extremely difficult and it took nearly everything the 68k processor could muster to make it work. It was just one of many low-level tricks, but SEGA’s marketing department thought “Blast-Processing” sounded cool and used it.
It meant a number of things, depending on marketing for various games. In general, it referred to the ability to DMA data to VRAM during the frame (you can only update VRAM in the SNES in the vertical blank period), which allows for a number of things from the mundane (DMA more data per frame than if you were restricted to just the vblank) to the more exotic (updating colors, scrolling, sprites, and tile maps on the fly). It has also been shown for a couple years now that you can stably DMA data to the background color register, in effect giving the MD 160×240 9-bit direct color graphics… at the expense of no cpu cycles during said display. That particular feature is not very useful for MegaDrive/Genesis games, but much more useful for MegaCD/SegaCD games. I did a demo that’s on youtube showing a simple raycasting engine for the SegaCD using Direct Color DMA.
https://www.youtube.com/watch?v=K-LQedrIQ_8