Overclocking Your Sega Genesis/MegaDrive 372
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."
sega genesis (Score:5, Informative)
here are the specs and some history [retrofaction.com]
Re:hrm (Score:2, Informative)
Comment removed (Score:5, Informative)
Re:Now what about other consoles? (Score:4, Informative)
Most of them... (Score:3, Informative)
When you're developing a game for a specific platform that will never change, why would developers use any sort of time-based algorithm to determine game speed? You'd end up with a smoother/prettier game if you merely used the limits of the hardware to control the speed of your game.
Especially back in those days where most of the games really DID push the limits of the hardware. Almost any game would slow down with too many sprites on the screen, etc.
I'd assume almost any Genesis game would play very, very quickly on an overclocked system.
Re:sega genesis (Score:5, Informative)
- Overclocking DOES NOT cause games to speed up! - (Score:3, Informative)
Sega slowdown... (Score:5, Informative)
Re:How does it work with other genesis attachments (Score:2, Informative)
Great, it's in English... (Score:3, Informative)
I wonder if the author of the article at Epic Gaming read the Japanese article and got the idea from there?
Re:And this is good? (Score:3, Informative)
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
Re:Most of them... (Score:3, Informative)
Re:This reminds me of the time.... (Score:1, Informative)
Re:I already have a hard enough time... (Score:5, Informative)
You're right. Even on newer consoles, like the Xbox, a 1.4 ghz cpu and 128 mb ram [gamestron.com] 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.
Re:I already have a hard enough time... (Score:4, Informative)
That being said, ive never done any console programming, so who knows :)
Re:We can't let the Sega fanboys beat us. (Score:2, Informative)
Re:I already have a hard enough time... (Score:5, Informative)
Re:I already have a hard enough time... (Score:4, Informative)
Re:Any way to get homebrews on real hardware? (Score:2, Informative)
Re:I already have a hard enough time... (Score:5, Informative)
Re:What about the Z80?? (Score:2, Informative)
Re:lol (Score:2, Informative)
Alternate suggestion. (Score:3, Informative)
Re:I already have a hard enough time... (Score:3, Informative)
Re:How does it work with other genesis attachments (Score:2, Informative)
Re:I already have a hard enough time... (Score:3, Informative)
What units this clock runs in varies from chip to chip, but most of the time, the OS that you're using provides you with a decent way of using it, in some sort of standard measure of time (vxWorks with the BSPs that I've used, for example, provides you with 60ths of a second, which is very convenient).
This is very important, since especially in cable modems, there are a lot of events that need to be synchronized, and the CPUs change in clock speed (i.e. MHz) on a regular basis.
In terms of consoles, timing things to the VSYNC is generally popular. In order to properly do double buffering, you need to swap the buffers during the point of time when the raster isn't being shown within the visible screen, or at least in the section you're drawing (otherwise, you'll get tearing).
That, and it's a fixed timing, either 50Hz (PAL) or 60Hz (NTSC).
-- Joe
Many games use the Vertical refresh interrupts (Score:2, Informative)
The logic parts of the game (AI and so forth) are usually done asynchronously, then the redraw is done on that edge so as to avoid tearing.
It's much the same as modern day graphics cards frequency lock settings, except that in older games everything tends to be dependant on the graphics refresh.
No... (Score:4, Informative)
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.
Uh... The answer lies with Nintendo... (Score:4, Informative)
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.
Nintendo did this... (Score:5, Informative)
I wonder if you're thinking of a special version of Ecco that ran on the 32X Genesis co-processor.
Re:Fixed speed difficult without external timebase (Score:3, Informative)
Re:I already have a hard enough time... (Score:3, Informative)
You can often "overclock" emulators too. Many have a setting somewhere that say something like "instructions per scanline" or "percent of instructrions to execute". Just increase that number and you have an instantly faster (emulated) processor.
Re:I already have a hard enough time... (Score:2, Informative)