Recently I performed a few modiifications to a Sega Genesis: - Composite/S-Video out - Stereo audio out - Overclocked to 10.0MHz, with a switch to choose between the stock clock (7.67MHz) and the overclock - Red/blue LED to indicate the clock speed (red = 7.67MHz, blue = 10.0MHz) - Universal pause switch (A switch which can throw the HALT pin of the CPU to ground) Most of the games I've tested seem to benefit from the overclock. Among the Sonic titles, this would include Sonic 2, Sonic 3, and Sonic & Knuckles (I haven't tested Sonic 1). However, a few games exhibit abnormal behavior at 10.0MHz, namely Sonic 3D Blast. I know no one really gives a shit about Sonic 3D Blast, so let me remind you that, when you boot the game, you see logos for SEGA and Traveller's Tales, and then a short pre-rendered FMV of Sonic running over a bridge while surrounded by Flicky's is played, and then the title screen is displayed. What I've noticed is that, when played at 10.0MHz, the video of the FMV is sped up, but the audio is played at the normal pace. The result is that the title screen is displayed early relative to the audio. Most peculiar is the effect of the HALT switch; in most game, the HALT switch forces everything but the audio to pause, and occasionaly odd screen effects occur. If you HALT Sonic 3D Blast while the FMV plays, you'll notice with much consistency that the entire frame of the video is fully displayed but shoved into half the frame (the top half usually), while the audio plays unaffected. Un-HALTing the CPU always has the same effect: everything returns to normal. Regular gameplay appears to be unaffected by 10.0MHz. If anyone is interested, I could later provide pics and/or video. I've only begun to experiment with games at 10.0MHz, and so I'm sure there is much to discover. And so I ask, what modifications have you made (if any) to your Genesis/Megadrive or other consoles, and what interesting effects have you experienced?
These effects are all perfectly predictable, seeing as sound is operated by the Z80 secondary to the 68000. HALTing the 68k does not cascade to the Z80. So, if the 68k has already gotten the Z80 started on doing something, the Z80 will carry on in blissful ignorance. This and other unaffected timings will be due to the program using something other than the CPU's clock speed as a reference for timing, which is a very sensible thing to do. The external reference might be VSync or, even better, some other crystal on the board that doesn't depend upon the main clock or the refresh rate (excuse me for being vague; I don't know the specifics here).
I believe I could explain that one. Given the screen resolution to be 0x20 by 0x1C tiles, means transfering 0xE000 pixels worth of art (I.e. 0x7000 bytes) and/or/within 0x700 bytes worth of mapping data to the VDP memory space, that's a lot of data to transfer and is not something that the main processor could do in a singular frame, so, what they did to compensate for this limitation is squash the frames down vertically to that the actual size is 0x20 by 0x0A tiles, this means only transfering 0x5000 pixels worth of art (I.e. 0x2800 bytes) and/or/within 0x280 bytes worth of mapping data to the VDP memory space: They then perform a raster effect, every H-blank (when the beam is off and is moving to the left of the screen ready to draw the next scanline), they alter the display plane's vertical position to deliberately cause the VDP to draw the same scan lines about 2 or 3 more times down the screen, this causes the image to appear stretched, at the same time they change the horizontal scroll lines so that every odd scanline is shifted right by one pixel (this causes what appears from our perspective as a form of dithering), additionally, they change the shifted scanlines from odd, to even, to odd, to even, and on, every frame, this causes a blur effect hiding the pixels dithering, and thus hiding the true nature of the FMV. When you pause the main processor, it is no longer altering the plane's vertical position during H-blank, and hence the image's scanlines are not redrawn several times over, that's why the images appears squashed, that's its true form.
Sometimes developers just rely on processor's speed. Basically, they expect it that processing a single frame will be slow enough to take several TV frames, therefore the game will work at a lower framerate (if the game lags for one frame, you'll get 30 fps instead of 60), but developers actually wanted this slowdown. Naturally, this makes game fixed to a particular processor's frequency and if you change one greatly, the framerate will increase, causing some unwanted effects. I think this is exactly what happens to 3D Blast's FMV. Here, we have a kind of video codec, that is likely designed for the original processor's frequency. In fact, it's quite easy to overpass this issue by coding a frame counter in VBlank code and checking if the needed number of frames passed, but it looks like developers didn't bother about that. As for other games that rely on processor's frequency, I've read that Zero Tolerance may also have issues on overclocked CPUs. Basically, what MarkeyJester said. If you're interested in other games where you can see similar effects on halting, here are few examples: Water Levels in Sonic games (screen becomes fully dry or water) 2P mode in Sonic 2 (half of screen goes glitched) Most of race games, like Outrun (you'll see original road's texture, without HInt effects) EDIT: GRAMMAR
Blast Processing is a marketting term. It's bullshit. Just to let you know. It just is a show-off way to say that the Genesis has higher processing power than the SNES, but you all know that in the console wars, Sega Marketting Team had to pull a term out of their asses to appear 'better' than the competition. Does this mod mean that certain hacks could work better?
only if they are played on an actual console, I don't know if there are any Genesis emulators that let you overclock the 68k
EDIT: This means there will be less lag in games. Some people overclocked their MDs in old days just because of that. Sonic 2 for example had unreal amounts of lag when you were playing 2 Player mode, and by overclocking CPU those could be played without any noticable slowdown. I even recall watching a video of old american TV show about video games consoles, where they where teaching people about overclocking MD, showing Sonic 2 as an example.
In all fairness, the questions being asked in relation to his hardware change can only be truly explained from a software point of view, or rather the resulting effects are caused by the way the software is written in contrast to the hardware, so this isn't strictly hardware related, but you're right in that the only engineering done here is pertaining to hardware, though I'm not sure it really matters at this point, it's on edge questions/answers balanced between software and hardware, and the relationship between them.
