Slashdot Mirror
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."
for those of you who don't know, 'genesis' is the north american term whilst 'mega drive' is the UK (and european?) term
here are the specs and some history
Marge, get me your address book, 4 beers, and my conversation hat.
The site, including the videos, are convieniently mirrored to sq7.org
Colin Davis
NeoRageX lets you overclock the 68K in the .ini file. Set it to 24MHz and no more Metal Slug slowdown! :D
Just no slowdown! :)
Slowdown is an integral part of older consoles. Modern day emulators that can easily push these consoles with no slowdown at 60FPS impliment a technique to fake "slowdown." It's a lot easier to just grab a genesis emulator for your Dreamcast or Xbox than attempt a hardware mod like this.
I wonder if the author of the article at Epic Gaming read the Japanese article and got the idea from there?
I've also mad a NES emualtor before, and there is a reason the games arent running any faster.
:)
firstly, many of the games wait for an event (such as the vblank to occur), or sit in an infinite loop waiting for an NMI to process the next frames work.
Firstly, as you probably know, NES games tend to be very timming critical. Switch to a game that does any cycle counting to determine with things should happen (just about anything made by RaRE should do) and it'll be all fscked up
And as for the speed itself, you aren't executing the instructions any faster, just waiting till more work is done before showing rendering the scanline. This is not the same as the effect of overclocking would have on a real thing. The real with would still execute 113.66667 (or whatever the cycle count it) CPU cycles per scanline...just faster.
proxy
If the game just updates the screen whenever the hell it feels like it, busywaiting until it's time, then yeah, it'll fuck up. But any properly coded game will utilize the VINT to synch to the refresh rate. Sonic 2 does this for sure, you can even see the garbage in the bottom border where the game is initializing the VDP for the next frame.
FC Closer
"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."
You're right. Even on newer consoles, like the Xbox, a 1.4 ghz cpu and 128 mb ram upgrade tends to have problems in certain games. Most console games, unlike their PC counterparts, run proportional to the CPU clock for actual game speed.
In a PC, overclocking the CPU will usually increase frame rate in newer games. Consoles, with their unified architecture, begin to run into compatibility problems when you make certain components run faster, or will usually speed up gameplay proportionally to the clock speed increase.
Yes, the above applies to the PC-like xbox too, but not to every game. From what I've been told, running Halo co-op splitscreen on that 1.4ghz xbox runs as smooth as silk.
Sigs are for losers
That being said, ive never done any console programming, so who knows :)
Religion is a gateway psychosis. -- Dave Foley
The center of your mindset should rest on the vertical blank - that's your 'unit of time', unless you're doing some splitscreen stuff (like the water effect in Sonic), then you utilize the horizontal IRQ (I also call it a line IRQ) to get there. No busywaiting necessary. Frame rate is mostly constant on the classic consoles, in the sense that it's mostly synched with the refresh rate.
FC Closer
All units of the same console execute the code at the same rate, so it is common practice to use the hardware speed or frame rate as your time reference. This may not be the ideal, but it's how things are done in the console world (and was common in PC games before computers got so fast it was highly unreliable).
His site explains that the games don't, in fact, run faster. Most Genesis games must actually be based on a clock instead of the processor speed. The only effect of the overclocking is that slowdown is eliminated. Don't you remember in Sonic games how if you had more than 20 or so rings and you got hit, the Genesis would slow to a crawl as it drew all the rings bouncing around on the screen? In two-player mode slowdown was even more common. Well if you overclock your Genesis, that can apparently be fixed.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
You're off by at least a decade. Maybe the original Pong and Atari 2600 were cycle-counters. Everything made after that used VBI timing. Newer arcade boxes like the NeoGeo used 68020s, which of course had instruction caches that made cycle-counting impossible.
I'd love to get an Atari ST emulator up and running Spectrum Holobyte's Falcon, overclocked. It would be cool to see it running at a smooth frame rate.
As I recall, by the end of life the Motorola 68000s were all made as 16MHz parts. The slower parts were simply not made or sold any more. Also, even when they were genuine 8MHz parts, they were pretty reliable with 50% overclocking; we did this sort of thing all the time in Atari STs before the 68020 and 68030 upgrades got popular.
There were limits to what you could gain though, since the 68000 had no on-chip caches of any kind and the system bus generally couldn't handle as much of a speedup. The better upgrades included a memory cache with the accelerated 68000 on a daughterboard that plugged into the original CPU socket, to allow the processor to run at full speed without disturbing the rest of the system. It was all a dicey job though; the tolerances in the rest of the system were pretty ragged. I remember having to desolder a bunch of 74LS series buffers and replace with 74HC or AS series or somesuch that worked at faster clock rates, more noise immunity, etc., adding tantalum capacitors everywhere, etc... Ah, the good old days.
-- *My* journal is more interesting than *yours*...
At least with the SNES. Take Gradius 4 for example - one of the first releases for the SNES. The slowdown in that damn game was unbelievable at times and yet you look at something like Pilotwings or Mario and you'd never see it.
Why?
Well, as it turns out, Nintendo underpowered the SNES' processor BIG TIME. In the first releases only Nintendo was permitted to use cartridge-based 'assist' chips that assisted with animation of larger objects. This explains why Nintendo's games always looked so golden on SNES.
Later Nintendo licensed the chips for 3rd parties but really screwed them for it. This was back in the day when Nintendo made all the games themselves, chose which ones would see the light of day (yes, even 3rd party ones!), and charged an arm an a leg for those assist chips.
"...Well, there's egg and bacon; egg sausage and bacon; egg and spam; egg bacon and spam; egg bacon sausage and spam..."
A lot of SNES stuff had 'assist' chips in the cartridges. Most were basic 'blitter' chips, but there were some that actually had co-processing on board for 3D graphics (SuperFX). Games like Starfox and Stunt Race FX simply would not have been possible on that console otherwise.
I wonder if you're thinking of a special version of Ecco that ran on the 32X Genesis co-processor.
"...Well, there's egg and bacon; egg sausage and bacon; egg and spam; egg bacon and spam; egg bacon sausage and spam..."