Overclocking Your Sega Genesis/MegaDrive

Deven "Epicenter" Gallo writes "I've recently been working on a project to alleviate the slowdown inherent in older game systems. How you ask? By overclocking them! I've managed to perfect overclocking the Sega Genesis / MegaDrive. The processor (a Motorola 68000, running at a stock speed of 7.6 MHz) can be pushed to 16.0 MHz in my experience, and I am still working on higher. The machine doesn't overheat and is entirely stable at these higher speeds."

Hmmm..

[LordK3nn3th]

If you can overclock it so much with a noticeable performance, then why didn't Sega set it like that already, if it's so stable? Certainly it would have given them an edge...

Pushing a 7.6 --> 16MHz is over 100% more than the original! I have yet to see most people get anywhere near that on normal processors.

hrm

[Vacuous]

This probably applies more to the NES then anything but... I never understood why developers would release games that had obvious slow down problems in the first place. I mean if they did any kind of testing they should have noticed them. Another thing I don't under stand is why didn't emulator authors ever consider upping the speed or the emulated processor to fix these type of things? I am not much of a programmer but could anyone maybe explain this to me.

Boy do I remember the slowdowns

[General Sherman]

Whenever I would play Road Rash 2 in split screen mode, the Genesis was noticeably slower. I was always disappointed with this, shame I don't have it anymore.

Re:Hmmm..

[BW_Nuprin]

Its possible that later production Gennys had better processors that were clocked down to maintain the same speed as the older models. In the five or so years that Genny was around, I'd expect that there were many many improvements to the 68000. I'd wager that the last couple Gennys off the line could be overclocked three or four times over without a sweat.

Re:Correct me if I'm wrong...

[YOU LIKEWISE FAIL IT]

But since games that can't run well on a console platform simply aren't published for that platform, isn't this somewhat useless?

There isn't enough correction in the world. A lot of games get released for consoles with noticable periodic slowdown - the classic example is the Metal Slug series. Still happening today too, I notice the occasional wad of dropped frames playing my XBox or Gamecube.

Re:I already have a hard enough time...

[LostCluster]

keeping up with Sonic ;)

That may be justification alone for why the systems were underclocked at the factory. The clock in many games is based not on an actual clock but the speed of the processor... speed things up and you speed everything in the game up, and that's not very playable.

Unless somebody's found a way to get this thing to run Linux and other non-cartrige programs, this isn't going to be very useful.

Re:And this is good?

[... James ...]

You'd think it would be most, but that doesn't appear to be the case:

I've written my own Nintendo Emulator. Just modified it to execute 5000 CPU instructions per scanline instead of the typical 114. Fired up Super Mario Brothers, Contra, and a few other games and they all appear to work fine.

I suspect (and I would've thought otherwise before this test) that many games are sychronized with the v blank interval or interrupts. I haven't tested sound, however, since I haven't written that part of the emulator yet.

Re:Hmmm..

[LordK3nn3th]

Yes, it's very possible they were underclocked for compatibility reasons. But I doubt they would've gotten a freak chip that could handle so much... I'm sure if that one could get so high, others could get high too (maybe not as high, but still high).

Re:That does it...

[fpga_guy]

Or better still, build a Timex/Spectrum in an FPGA [sourceforge.net] and clock it as fast as you like...

How does it work with other genesis attachments?

[Recovery1]

Now here's an interesting thought. What would happen if you hooked one of these overclocked Genesis into the Sega CD or 32X attachments? As I recall the whole process of getting the Genesis and Sega CD to work together in parallel was a challenge to begin with because of different clock speeds between the two CPUs in each device.

My guess is he hasn't tried it or it doesn't work, as he doesn't elaborate on it.

Re:And this is good?

[LostCluster]

The article seems to imply that Sonic 2 was the only game checked, and that it was fine in normal play but glitched in the 3D half-pipe bonus levels...

3D Graphics on a TI-85

[KalvinB]

While in High School I was always coding various things in BASIC on it and one day when I demonstrating how to map 3D objects by placing the sonic sensor on an overhead cart and rolling it under light fixtures, this kid in my calc class goes "you expect that thing to act like a Pentium." I used TI-BASIC to learn how to do 2D translation and rotation and touched on some 3D. I made the first and possibly only graphical adventure game for it complete with text entry and a cursor to click on objects.

A few years ago I gave it to a friend who needed a TI but I'm pretty sure the Intel Inside Pentium MMX sticker is still on the back of it.

Ben

Re:I already have a hard enough time...

[kisrael]

That may be justification alone for why the systems were underclocked at the factory. The clock in many games is based not on an actual clock but the speed of the processor... speed things up and you speed everything in the game up, and that's not very playable.

Err, you might be right about programmer's being relatively lazyish (/efficient) and relying on the processor speed for timing...but they could always easily slow down a game that was too fast, but not the opposite.

Actually...programers don't JUST use the processor speed, or else slowdown would never happen, there wouldn't be a "correct" pacing for a game, just a continuum...few objects -> fast game, some objects -> medium game, many objects -> slow game. Instead, a game has a 'desired' speed, and probably just burns cycles if it's done everything but it's not time to proceed. If there's too much happening, the gmae slows down, and no cycles are burned.

The underclocking was probably due to the tolerances of the manufacturing process at that point. At this lower clockrate, virtually every chip is usable, at this higher rate, more can't keep up.

Yeah... I rmemeber 12 years ago...

[Anonymous Coward]

I was tinkering with this on my Amiga 2000 almost the same exact hack... a switch that let you choose between the standard 7MHz and 14Mhz tapped from elsewhere on the mobo. It worked well once I finally sourced a 16MHz 68000 instead of the stock 8MHz. Cheap and dirt simple hack... helped out with DigiPaint rendering among other things, but then again... on a console... why?

WRONG, WRONG, WRONG, WRONG, ALL WRONG

[LocalH]

NTSC does 60Hz, PAL does 50Hz. Most games update the screen every frame, a few will do it on two's. This actually has a use with all games that are programmed correctly, especially those which rely on raw CPU time.

It'd also be nice to play around with in a C64-styled demo, banging on the VDP with the increased cycles available at the higher clock speed. I wonder what happens when you try to hit the VDP too fast. To compare, with a SCPU-equipped C64, the 65816 simply blocks until the 1MHz bus frees up, if it needs to.

street fighter 2 SNES

[sewagemaster]

i remembered having massive slowdowns in streetfighter - especially if you're using guile and execute any combo more than 4 hits

my favorite combo... but lags in SNES...
jumping fierce + close fierce uppercut + sonic boom + referse fierce + sonic boom.

ironically this was under SF2 TURBO

Any way to get homebrews on real hardware?

[Kris_J]

Overclocking an; Atari 2600, Atari 7800, Gameboy, GBA, C64 (or any system with a disk drive option) or even a PSX/PS2 is really cool because you can get homebrew code onto real hardware with some sort of RAM or flash cart, or writable media. Enthusiasts can subsequently write new programs that use the extra clock cycles. However, I don't know of any way to get ROMs onto a Genesis/Mega Drive -- is there one?

Meanwhile, anyone in the Perth area that wants a Mega Drive to try this on, you can have one of mine if you'll convert a second for me.

Re:WRONG, WRONG, WRONG, WRONG, ALL WRONG

[Phybersyk0]

Um. You must have owned an AMIGA also. What you're referring to was quite an issue on the AMIGA, either timing your graphics/music to it's CIA (complex interface adapter) chips or VBI (vertical blanking interval) timing in the FAT AGNUS animation co-processor.

There were always hacks for the Amiga that allowed you to alter the timing for things like graphics, or in most common cases, the playing of music modules (MODS).

The Motorola MC68000 was a comparitivly fast cpu amongst it's peers (IIRC the MAC LCII & the Atari ST had this too), HOWEVER, the CPU was much slower that what was needed in the Amiga, and why job-specific custom chips were created.. but I digress...

Later revisions of the Amiga 500 included a Motorola MC68010 cpu which was electrically compatible with the MC68k, and was a reasonable replacement.. It ran at something like 11Mhz...

So... You should be able to do that to the Megadrive/Genesis also, without any real problems. I remember specifically playing Altered Beast, and each time you'd take on the 2nd level boss (the wierd octo-eye-puss thing) and it would get slow.. man that sucked.

What about the Z80??

[Anonymous Coward]

The Sega Genesis is a dual processor system containing both a 68K and Z80. Some games are sensative to the timing between the two processors. If you overclock one and not the other some assumptions about the timing is going to break. In the cases of his tests it appears to produce problems with the music since that is what the Z80 gets used for in Sonic. But in other games the Z80 is also used for video effects such as flashing icons. Even if you can get the 68K another 50% faster, you still haven't gotten the entire system correctly clocked at the new rate unless the Z80 can also handle being clocked another 50% faster.

Re:And this is good?

[pidge-nz]

Virtually every video consoles' game timing is tied to the screen refresh i.e. the game carries out the operations required to move sprites, update the background, update the sound being played etc, based the "vertical" refresh rate. There's no point in trying to update any faster, as that's a waste of time, since the changes will not be seen at best, or you get some "tearing" at worst.

Of course, if you insist on programming in BASIC, instead of assembler like a real programmer (ducks), you deserve to have you game made unplayable :D

<RAMBLE>

However, some games which rely on the CPU timing of the console to be a certain number of clock cycles per scan line may get messed up, if that timing is used do things like display a sprite in multiple places on a single scanline. Those of you who have seen/programmed C64 demos with the entire screen in use (no borders) will know about that - that required careful synchronisation with the scanline to fool the Video chip into not turning the border on at the end of the scanline - or simply moving the sprites "down" the scan field so that they are redisplayed. This allowed the 8 sprites the Video chip provided to be used over and over again, so long as the code didn't try to no display more than 8 sprites on a single scan line - extras would go missing - one thing that the game "Commando" violated - it didn't have a very good sprite management system to prevent this occuring. But that never caused it to crash thankfully.

</RAMBLE>

Re:This is about as interesting

[toddestan]

The factorial function is about the most intensive thing you can do on a little scientific calculator. 69! is ~1.711E98, which is the largest most calculators can go, as 70! factorial has an exponent of over 100. Unless your calculator can handle 3 digit exponents, then you can compute 449!

Ahh... the memories... back in middle school we used to glitch our solar powered calculators by doing 69! then covering the solar cells, which sometimes resulted in some pretty weird stuff (we could make TI-30's go into some kind of octal mode, also the calculator could sometimes go into some kind of trippy looped animation on the display, or it could change layouts to another TI model, like the TI-30STAT).

To bring things kind of back on topic, I once overclocked my TI-85. And some of the games did break, though the good ASM programmers didn't rely on the CPU speed, as it would slow down as the batteries wore out, even if you didn't overclock.

Re:I already have a hard enough time...

[chiller2]

Remembering back to my demo coding days (on various Acorn/ARM systems) the reason the game doesn't scream along at some insane rate when the machine is clocked higher is because the update of the framebuffer is synchronised with the v-sync of the display, which on TVs / non multisync monitors was either 50Hz or 60Hz depending on where in the world you bought your equipment.

If the machine is clocked higher, the only difference is that more code can execute between v-syncs, so the game appears not to slow down when more than a certain number of sprites are being thrown around, etc.

Kind'a hard to see the difference

[Aqua OS X]

it's kind'a hard to tell the difference when we're looking at an AVI file with a set frame rate.

68k Amiga500 too

[Anonymous Coward]

The Commodore Amiga500 computer was also based on a 7.14MHz 68000 processor. This CPU was as slow as dirt plus some. Commodore was stuck putting in this slug of a CPU model for the longest time because most software made for the Amiga was timed down to the CPU in the original 1985 Amiga (and the chipset - practically like a game console, but that's another story).

The CPU in the Amiga500 could easily be overclocked to 11MHz or even 14.2MHz. This would obviously yield a massive improvement, making the computer significantly more usable as a desktop system. It's the difference between opening a drawer (folder) and it popping up almost instantly vs taking a second or two.

Fixed speed difficult without external timebase

[noidentity]

A game with a varying number of on-screen objects which achieves consistent speed without relying on an external timebase is somewhat difficult to code because the execution time of every routine must be taken into account to determine the proper delay until the next frame. It's unlikely that the overall frame rate of a game would be normally determined by CPU cycles used (it will be when there is too much to process in the usual frame interval). In addition, video hardware on some consoles only allows access between frames (during vertical blanking). Even where it doesn't, if the game's frame rate isn't synchronized with the video frame rate, when updates are made in the middle of the video frame, the next completed video frame will have a split across the middle with the old frame on top and the new frame on the bottom.

Depending on the CPU speed for short self-contained routines which access hardware in a time-critical way is probably more common, and not bad practice, since the older consoles were kept compatible at the hardware level. Keeping hardware the same across board revisions allowed elimination of a cycle-consuming software abstraction layer.

Re:I already have a hard enough time...

[zeno_2]

I used to work the help desk at microsoft. (Ok, it was another company, I was never employed by microsoft, thank god.). Anyway, there was this problem when Links 2003 came out, with pretty much any Dell laptop. The problem was, the golfer would swing about 10x fast as normal. After infestigating the problem, we found out that these specific dell laptops would not keep track of windows uptime correctly. We would reboot the laptop, and bring up a program that showed windows uptime, and it would give us completely wrong times. As an example, we would reboot, and the dell laptop would show 48 days uptime. Now, as a "microsoft employee", we didn't have a lot do to, when it came to fixing that particular problem. (it only happened on dell laptops, and we could use windows to verify the uptime was not being recorded correctly. Links 2003 would use that uptime figure to calculate how fast the golfer should swing). In any caes, I was never able to get a straight answer from either Microsoft or Dell as to why the newer dell laptops would not keep the Windows uptime correctly. It was kinda one of those issues that was swept under the rug. So, I can atest to the games out there that use the system clock as a timer to find out how fast to play certain things (probably mainly with animation). This is probably something that is used quite often, especially in a situation (like the xbox)where every system is the same. Oh ya, and I hope the Xbox dies a miserable death.

Re:Wow

[hyc]

Thanks for the thought.

I think it's ironic, in an industry where the common practice was to build chips targeted at a particular speed, and sell the ones that didn't pass certification as slower parts, that Motorola was stuck selling perfectly good 16MHz chips as 8MHz chips just to keep that price point open. (There was absolutely no difference between an 8MHz and 16MHz chip by the end of their product life.) And there were people routinely running their 16MHz chips at 32MHz, because the fact was that they were produced off the same process used to make the 25MHz 68020s, and that core was the same as the 32MHz 68030. It was all the same silicon, all of it good enough for 32MHz.

Re:I already have a hard enough time...

[cemaco]

Isn't that why old P.Cs had turbo buttons?

Whenever I ran into an old DOS game that wast too fast on the newer machine I would just disable Turbo and it would run fine.

Turbo started disappearing on P.Cs around the time of the mid 486's. That would also coincide with Windows 95.

Re:Any way to get homebrews on real hardware?

[Eil]

However, I don't know of any way to get ROMs onto a Genesis/Mega Drive -- is there one?

Cart copiers exist, but they tend to be either incredibly expensive, incredibly hard to get, or both because the companies that made them stopped selling them once new systems came out. The biggest market for copiers were asian countries with lax copyright laws and rampant piracy. Reportedly, a year or two after the PSX came out, it wasn't uncommon to see someone throwing their perfectly-working copier and stack of floppies (games) right into the dumpster. Now a decent SNES copier can go for upwards of $250 on ebay.

that 'slow-down' was a feature

[CAIMLAS]

I don't know about anyone else, but I actually appreciated it when my NES or genesis would slow down. It usually happened in a particularly difficult spot, and it allowed for quicker response on my part. Such slowdown is the only reason I ever managed to beat Super Mario Brothers.

Since I couldn't afford a game genie, it was a nice substitute at times. :)

Or...

[Bert64]

Why not pull the 68000 out and replace it with a 68010 chip, which is pin compatible, faster at the same clockrate and able to run at higher clock rates anyway...
I always thought the megadrive 68000 cpu was clocked at 12mhz anyway, it was the Amiga 500/600 series machines which used 7mhz 68000, and one cheap upgrade path was to pull the 12mhz cpu out of a megadrive

Re:That does it...

[Kazymyr]

I know the parent is supposed to be funny - but I did have my Sinclair ZX Spectrum overclocked to 6 MHz (from the original 3.5). Some games would run, some not. The clock speed could be changed on-the-fly without any ill effects. Of course at 6 MHz the cassette load/save routines were totally off, so that for loading commercial programs I needed to switch it back to the original speed. But files saved at 6 MHz would load back perfectly fine at 6 MHz. Loading/saving was quicker, too (higher pitch of the carrier + shorter pulses equals more bits per second).