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."
keeping up with Sonic ;)
I'm going to overclock my Timex Sinclair!!!
I, for one, welcome our new robot overlords
... as the time I slapped a Type-R sticker on my Casio FX-1000 solar-powered calculator. Before I did that, it took 950 milliseconds to calculate 69! Afterward, it calculated 69! in 940 milliseconds flat.
Or, wait, maybe it was because the sun came out.
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.
---
Never criticize religion on Slashdot. You will be modded down for "Troll" no matter how factual it is.
Someone needs to recreate this with a NeoGeo. Metal Slug needs to be played free of all that ridiculous slowdown. =]
I don't recall exactly, but I think you could 'overclock' the genesis in older emulators like Genecyst, so perhaps that would be a good way to check to see how well games run overclocked before you actually futz with your real Genny. I would think that many games would have timing problems at a speed greater than stock, particularly those that use raster effects. I can't say for certain, but I know my old Gameboy Color raster effects would break completely if I overclocked them. I would wager that racing games would probably suffer the worst.
Granted, it's nice for the coolness factor, but unlike PCs, newer and flashier games only come out for beefier platforms and can't be run on the old ones anyway, no matter how fast they're going.
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.
- Sherman
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
16mhz is what the Palm Zire runs at too. That means if someone ports Palm OS 4.1 and you attach a VGA/LCD thingy you can have a Sega brand PDA. True, you are sacrificing portability, but hey, I think there are some kids at my school with pockets big enough for a Genesis.
So now kids will start bragging about how many frames per second they get on Flashback, eh? That's just what we needed right there.
In Soviet Russia, Jesus asks: "What Would You Do?"
as to how high his cute little hit counter registers before his server reaches critical mass? maybe he should've turbocharged that machine first...
Gentlemen, you can't fight in here! This is the War Room!
It's a shame he didn't overclock his server to twice it's original speed. Those 10-25MB .avi's really don't help.
- Sherman
Plug it into the 220 outlet behind the stove. It'll run really fast for a couple of seconds and then you can get on with your life.
- - - If the sun is a star, why can't I see it at night?
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.
get nemulator
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.
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
The machine doesn't overheat and is entirely stable at these higher speeds.
...
... ...work ?
The machine doesn't overheat and is entirely stable...
The machine doesn't overheat
The machine doesn't
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
Finally, we can recreate the glorious console wars of the 16-bit era!
I'm going to overclock my Super NES.
I'm not going to let those Sega fanboys get the upper hand on this. They already taunted us SNES owners about their "blast processing" in the early 90s.
"You spoony bard!" -Tellah
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.
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.
" ... as the time I slapped a Type-R sticker on my Casio FX-1000 solar-powered calculator. Before I did that, it took 950 milliseconds to calculate 69! Afterward, it calculated 69! in 940 milliseconds flat."
Personally, I prefer my sixty-nine bangs to take a little longer than that...
Do not look into laser with remaining eye.
I am glad to see this as a root post. Anyone who has ever dug into the internals of the Amiga, Mac, or Atari ST hardware has found that moving to faster 680x0 CPUs did not affect game speed, only the amount of lag (we called it "bog") in a game.
;) Hell, we might still be able to see that just for kicks.
I have nearly two decades of experience with the 680x0 CPUs in the Amiga systems. I remember being absolutely thrilled when Sega used the 68000 CPU in the Genesis. I hacked an original unit which had the 68-pin package with a 68010. Honestly, I do not remember the full results, but I recall I was still able to play the majority of my collection (two carts at the time, hahahaha.)
I also toyed with the idea to replace the 68000 with an MTec 68020 accelerator pulled from my Amiga 500. I never tried it, and I still am not so sure it would have worked anyway. If the AmigaOS was a little less hard-wired to the Amiga hardware architecture, given a little work, we might could have seen AmigaOS running on a Genny
Having gone from 68000 to 68040 in all its discernable steps (I still dream of a 68060/PPC accelerator for my A4000,) I have been able to bring all of my games with me. The only problem I have is with expected timing of the OCS chipset versus the AGA chipset. But there are a number of great hard drive installers which over come this, as well as system "degraders" which place the computer in a state almost identical to the original Amiga hardware.
In any case, I'm inspired by this article and look forward to dropping a 12MHz clock generator in my Sega II (provided its CPU will support it.)
(climbing up on soap box) It is also worth mentioning that us old-hat gamers take a lot of shit for being so nostalgic and blah blah blah, aching for an era long-past. I got news for those who cast stones, many of those games were FUN, and down-right phuqn great. I will not say that none of my collections are nostalgic -- I have a number of Atari 2600 carts which I never played then and do not play now other than for testing, simply because they are Atari. But the majority of the games I collect (Amiga, Atari, Sega, NES, TI, C64, and others) WERE fun, and are STILL FUN.
How many people are still playing a "dead" console because the games rocked and you cannot get them for "modern" consoles? PS1 is almost 10 years old, and yet it still has a large following. I bet in 10 years there will still be a large faction of people playing the original XBox because some of the titles will not be available on newer consoles, or just will not play the same. (I do wonder how game play of XBox 1 games will be on the XBox 2...)
Well, enough of that.
END OF LINE
First off, this place is for discussion and it is generally a good idea to counter opinions with your own rather than trying to censure people. Let moderators decide what is and isn't appropriate. That's what the system is for.
Secondly, it appears as if you've created multiple accounts so you can make posts supporting yourself without it appearing as if you're doing (even though it's patently obvious). If this is not the case, I find it to be a remarkable coincidence that three new users with almost consecutive IDs, you (761169), laggerzero (761187) and Light Serif (761190) all commented in the same thread right after one another. Further, those comments were the only ones those users ever made. Quite a coincidence indeed.
Last but not least, and please take this as a constructive suggestion and not an insult: Take a deep breath and try to relax. You're working yourself into a lather unnecessarily and in the process, making yourself look a tad silly. Remember, this isn't a popularity contest. It's just Slashdot.
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..."
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.