Amazing that SEGA didn't just set their Megadrive/Genesis systems at 10MHz (almsot twice the useful MIPS) and use 128KB of VRAM and 16KB of CRAM like the System C2 arcade board--4.096 colors out of 98,000 with 2x the bandwidth. The Sega CD+SVP would still be dominating the market to the late 1990s, almost matching the PS1 for performance.
Road Rash3roda perfeitamente utilizando overclock de15.36MHz pelo o que percebi no emulador,porém eu não sei se dar pra colocar essa quantidade toda no hardware original.
Thats "O.C" is at your own risk, at some point it fails and causes video corruption and crash. It's not as easy as changing the crystal oscillator, the synchronization between all parts of the console will be lost. The system try to compensate the discrepancy in order to synchronize and this cause lost of time. Write a bench program and compare how much gain vs how many times fail. If you are not care to kill the console then it's ok, good look.
It’s a simple setup and I’m sure you would be much cheaper off buying the components. You really just need the 5v 10MHz Oscillator ( I prefer the FOX branded). And a 3 pin on/on toggle switch.
I wonder if your problem is that your adding an external oscillator that isn't synchronized with the rest of the hardware and you're hitting weird harmonics / going out of sync with the VDP (might explain those BG tiles scrambling but sprites being OK) as you go higher? Apparently the Genesis has its own frequency doubler / supplier for Carts with their own chips (like Virtua Racer) and planned for future addons running somewhere around 13.5 MHZ. - pretty sure the 32x requires this. I think a lot of those 13 Mhz+ overclockers are done by cutting the trace that supplies the normal clock and splicing in the pin that provides the higher clock to carts. Since the frequencies are either doubled or derived from the genesis itself, it may keep it in sync. Also, there's always the possibility that Sega used cheaper 68000 chips - often CPU makers take chips from the edge of the wafer and downclock them to make their cheaper chips because they're flawed and less stable at higher speeds.It's WAY less expensive to make one chip and downclock than several different chips. So maybe you just have a sensitive chip. Alternatively, you might be able to synchronize your clock using the original or, use a frequency doubler instead of a crystal... Here's an early vid of overclocking the Genesis using the 13 Mhz source: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-zuHkq8uvnLc.html
Thank you for the insight! It does make sense that overclocking in the way I did could throw it just enough out of sync because I didn’t put together that some of the sprites were fine. What I really should have done too is checked the output clock on an oscilloscope to double check it was preforming the way I expected. You have given me more than enough to start working on how I might better achieve those higher clock speeds or how I failed this time. Hahaha. Thanks again!
@@dvgamerepair3448 You know, I couldn't help but think about this some more, especially how sprites seem OK but BG tiles don't and why you'd get that weird threshold near 10.175 MHZ... Overclocked systems *usually* don't run "faster" (aka, timers and gameplay work normally) but lack slowdown. I'm under the impression that it's because they use H-blank, V-blank and F-blank to time when they're doing various tasks. Since it has the native capability to run 13 Mhz cart chips in place of the CPU, it has to have the capability to handle at least that frequency but it needs a way to prevent being overwhelmed or going out of sync. I don't know for sure but, I imagine that the flags for blank intervals are being triggered by a signal from the VDP and NOT the CPU, as the CPU doesn't directly control the timing of the raster for the scanline, only the rendering for the data the VDP will display. Since it natively has that 13 MHZ clock for carts running faster chips too, it would make sense if the clock signal and the blank status' that trigger CPU flags are all on the VDP AND that it has (essentially) an internal interrupt that stops the clock it generates for the CPU or triggers a flag to halt while it processes visual information until ready for more data from the bus so data transfer rates aren't exceeded. It also makes sense that the 13 Mhz signal is being generated there too. I infer that this is the case because it allows those external chips to take the place of the onboard CPU in cases like Viruta Racer or other anticipated carts running the SEGA equivalent of the Super FX chip without the issues you're running into, even though they're operating at much higher frequencies. Therefore, it also implies that there's a mechanism to synchronize everything properly that you can tap into on the bus to the card slot and by running a isolated clock, you're losing that. It would be interesting to hook up an oscilloscope to the pin providing the 13 Mhz signal to the cart and see if it has a interrupted period keeping everything in sync or (more likely) another pin (or 3) calling a flag at the H,V & F blank frequencies. IF synchronization is in fact the issue, you should be able to use the 13MHZ signal to control your own oscillator and halt or adjust cycles when necessary, overclocking it to any frequency you want only when it can handle it, or find the pin(s) that's being used to trigger the halt state / flags and adjust your oscillator accordingly. Your goal is to OC the CPU so it can crank through data in the correct states but, you aren't just doing that - you're doing _everything_ faster - like memory transfers and calls to the VDP and RAM - and are probably exceeding the their capabilities. If you can get the triggers right, you could basically OC the CPU to its physical limit during the proper periods and relax it at others to prevent your problems. Probably. Maybe? If you watched that link I posted, the guy mentions that to change between normal and OC, he has to first stop the clock with a 2nd switch before adjusting the CPU speed or it'll crash. While he does so, the screen starts getting weird BG tiles from the VDP but recovers when the clock is restarted. Remind you of anything you're experiencing? The question is whether that's a flag / interrupt halting the CPU or if it's just disconnecting the clock but, you could probably examine the wiring to identify where you need to look with the scope...
@@bryanl1984 First off, my apologies for the late reply, life and work get overwhelming sometimes. With that said, dang, you sound about spot on. I think you are on to something with how the direct feed into the cpu is causing everything to speed and not isolating it like I want. analyzinginterrupt that I could exploit somehow inject a different clock speed. Again, thank you for the path! I will definitely keep you posted!
@@dvgamerepair3448 Good luck, I hope you make it work! It's the kind of thing I've been wanting to do for a while but I've been too lazy (90%) and lacked the hardware (10%).
Amazing work , in my experience I did the same with model 1 and I got the results of 9 .4 MHz is the safest cuz sometimes even on 10 MHz the game works but sometimes after couple minutes it freezes , but I my was exciting that you got better results than mine , however do you know a way to get color on AV/S Video after you mod the region switch from 60 to 50 hz ? Cuz I did it with the regular cutting the traces and add SPDT switch and I get black and white picture so is there a way to have a color with the Genesis at 50 hz while the system is modded with S video ?
If you want color on composite or s- video with a region mod you need a DFO, Dual Frequency Oscillator. The color signal doesn't get encoded correctly cause the timing is slightly off due different regions having slightly different oscillators. Otherwise you can use RGB SCART cables to get higher quality video with color, since that output is unaffected by this issue.
I actually haven’t done one on the model 2 but the Model 1 I have. I am certain it is the same circuit to accomplish it. It’s definitely worth it on the Model 1.
@@matmcpaul9060 I would assume so as well. Mainly because it would be cleaner. Audio would be pushed out the original av connector even if you modded S-Video but you would have multiple cables.
I was a SEGA fanboy growing up. But SNES could put co-processors on carts cheaply (like the 10Mhz SA-1), whereas the Genesis design is screwed up forever. There are pins for external Color RAM on the VDP but they don't have traces on the motherboard to connect to the expansion port or cartridge slot so you get 4 palettes...Snes has 16 palettes to use. There are only like 20 brownish shades and 20 grayish shades on Genesis (if we are being generous with some reds and purples) and tons of crappy neon pastel colors. If you want to see what SNES could do even without chips look at Tommy Moe's Winter Extreme/Val d'Isère Championship. Most of the bad rep SNES has is down to dev skill and publishers using cheap SlowROM (slows the CPU speed) instead of FastROM.
