Overclocking & 68010: Annotated Compatibility List

[Peeteris]

I have written this already, but now I hope someone could help me with this problem.
The thing is that in every game if there's water, there's garbage between water and land. Constant dots on the first lines of water. It's annoying. I have not seen any other graphical glitches (except in Comix Zone). Only graphical glitch is with garbage dots between water and land. In every game. Also these dots are in the same places in every game.
Any suggestions?

[CrossBow]

Sega Mega Drive (EU), VA6.5/8, region set to North America - NTSC, Motorola 68000, overclocked to 10MHz.
5 min - Psycho Pinball - title screen music sounds terrible.
30 min - Sonic 3 & Knuckles - no crashes, but graphical glitches between water and ground (white dots following between ground and water until entire screen is only water or ground), no ice cap music problems found.
10 min - Vectorman 1 and Vectorman 2 - no problems found at all, smoother gameplay.
5 min - Ristar - slowdowns not present in intro sequence anymore.
Completed game - Streets of Rage 3 (JAP, translation) - no problems found.

P.S. I found out that Sonic 3 isn't the only game with graphical glitches between water and ground. I found this in Ristar and some other games I can't remember. Probably every game with water like in these games is affected. So as far as I understand, there are graphical glitches (vertical pixelation) between color palete swaps. Correct me, if I'm wrong, as I'm not really sure, what's going on.

Have you tested this with the impressive mirror water effect in the intro of Wiz n Liz? Be curious to know what results you have with that game.

[goldenband]

A request for Todd's Adventures in Slime World, which suffers pervasive slowdown.

[Lycanphoenix]

A lot of the games on the chart don't actually have information listed for how they perform under different conditions. Also, there are no records for how Knuckles in Sonic 2 or Sonic CD (be sure to test when swapping both CPUs) behave on the 68010, nor miscellaneous software such as Flux (a commercially available music visualizer for music CDs, which you plug into the Genesis cartridge port) and compilations such as the infamous Action 52.

I actually had typed up a few ideas for hardware mods that might increase compatibility with the 68010, if anybody wishes to hear them. Until then, compatibility patches for some of the more popular incompatible games might be in order.

[Barone]

I actually had typed up a few ideas for hardware mods that might increase compatibility with the 68010, if anybody wishes to hear them. Until then, compatibility patches for some of the more popular incompatible games might be in order.

I'd love to hear about that.

[ironnick23]

10mhz overclock on the Adventures of Batman and Robin exhibit character sprite flickering and punching trash cans won’t show the cats flying in the air. Slowdown is improved in boss fights.

On Gunstar Heroes the intro scene shows some artifacts around the edges, those slowdown is reduced nicely in gameplay.

[MegaDriver]

I recently acquired a GameGenie and decided to try it with my 10Mhz overclocked Megadrive.

I noticed that games I played almost flawlessly before now crash much often.

Has anyone noticed this too? I guess that GameGenie does not like to be pushed or it introduces some kind of bottleneck?

[MegaDriver]

I noticed "Chaos Engine" is not on the list of first post, but I think there is occasional slowdown.

Playing the game on overclocked Megadrive (10 Mhz) seems to improve, although not very perceptible (?).

I maybe wrong but has anyone checked this game previously?

[Lycanphoenix]

I'd love to hear about that.

Oh crap, I never responded!
Well, the original idea I had wasn’t super feasible anyway. The new idea is a lot simpler;
Hack the Mega Drive’s BIOS so that it forces the 68010 to run in Supervisor mode at all times.

[ComradeOj]

Oh crap, I never responded!
Well, the original idea I had wasn’t super feasible anyway. The new idea is a lot simpler;
Hack the Mega Drive’s BIOS so that it forces the 68010 to run in Supervisor mode at all times.

The MD doesn't really have a BIOS in the same way that newer consoles do. Later revisions have TMSS, but AFAIK, it just runs once on startup. Someone please chime in if I'm incorrect though.

Games have direct hardware access and don't go trough a BIOS for things like system calls, accessory access, or memory allocation. I think a lot of compatibility issues with supervisor mode are down to MD game developers programming for the behavior of the 68k. I think games will just have to be hacked on a per-case basis.

[Lycanphoenix]

What about having an integrated circuit that continuously checks to make sure the CPU is in Supervisor mode, and if it’s not, just intercepts all User Mode instructions and converts them back into Supervisor mode?

As far as I’m aware, most of the 010-specific crashes stem from instructions being used outside of Supervisor Mode. (Well, that, and the later 680x0 chips trend toward a larger address space, so you’d want to only use chips with 24-bit address width.)

[ComradeOj]

What about having an integrated circuit that continuously checks to make sure the CPU is in Supervisor mode, and if it’s not, just intercepts all User Mode instructions and converts them back into Supervisor mode?

As far as I’m aware, all of the 010-and-020-specific crashes stem from that one instruction being used outside of Supervisor mode. (Well, that and the 68020 has a 32-bit address space, so you’d want to use the 68CE020 instead so that you get your 24-bit address space back.)

Maybe possible. You could have some sort of in-between cartridge to intercept and alter instructions that change the mode. Sort of like a Game Genie. I can't remember if hacking games by forcing supervisor mode had any odd consequences like stack issues or other bugs. I'll have to try and hunt down my old notes, if I have any. I haven't dealt with 68010 hacking in years. Another possibility could be to write a computer program that scans a ROM file and automatically changes instructions that switch the SP to user mode.

I actually thought of a 68020 mod, but I have no idea how feasible it is, and didn't want to try it. The 68010 is easy, since it's 100% pin compatible. I would love for someone to explore a 68020 Genesis in the future though.

[Lycanphoenix]

If anyone does end up doing a 68020 mod, it *needs* to be the 68CE020, as its address bus is the same as the 68000 and 68010 before it.

But as a completely unrelated mod, you could try swapping the Z80 for an eZ80 (preferably the version that comes with some internal SRAM). That would be 100% object code compatible, but be a lot more cycle efficient, potentially resulting in a considerable performance improvement (especially because it wouldn’t be hogging the 68000’s memory).

Edit — An update on the band-aid fix;
Before the 68010 came out, some systems would run two 68000’s offset by a couple clock cycles. You could probably use a regular 68000 to intercept the 68010/68020 whenever it fails, execute that instruction, and restart the failed processor. A lookup table may help as well.

Yet Another Edit — 68020 Microcode
The 68020 (and 68CE020) use Microcode, IIRC, and I believe the 68010 might possibly use microcode as well. If it’s possible to alter the microcode, then we could force it to be 68K-compatible.

[TmEE]

One cannot just make Z80 faster, most games will stop having proper sound. YM is *very* slow and its timings must be met and sound drivers typically busyloop. When I experimented with Z80 overclocking most games started to have garbage noises.

Usermode entry can be prevented with a game genie type device that monitors bus for MOVE instructions that access SR and modifies them to prevent exiting supervisor mode. Any games that assume A7 will be separate for interrupts will then fail however, so best solution will still be patching of games.

68(EC)020 has a bit different bus interface, it will take more effort to get things going and there will be similar concerns as with Z80, some games, such as Sonic1 and 2 will have messed up music as YM accesses get too fast and unlike overclocking, you cannot fix it with underclocking as that throws off other timings and you will still enter incompatibilites territory.

Microcode is not updateable like in PentiumII and newer CPUs on these things, and when you want to do such a thing you just overclock instead lol

[Lycanphoenix]

I mean... The eZ80 would presumably be sending instructions and data to the YM2612 at the same speed as the Z80 that it would be replacing. It doesn't run at a higher clockspeed (unless you specifically tell it to do so), nor does it have an instruction cache.

Wider ALU? Sure.
Access to faster RAM? Definitely.
More efficient at executing certain instructions? Without a doubt.

But it was specifically designed to be as compatible as possible with the original Z80 and code written for it, so I feel like it will only end up being too fast for YM2612 if it tries to send data to the chip too quickly. Really the only way to know for sure is to try it out.

— — — — — — — —

I had another thought regarding the issues with overclocking. A lot of the real instabilities that happen at higher clock frequencies tend to come from memory corruption, right? With how cheap SRAM chips have gotten, couldn’t we try replacing all the DRAM chips with SRAM? (The VRAM chips do contain a serial access cache though, which complicates things a little.)