Adapted games: what makes them incompatible at >16 MHz?

[mikro]

Today I got a great idea which was buried after 10 minutes of despair.

As you certainly know, there are many great game adaptations to run on the Falcon (and TT etc). One of them is Lotus III. Both versions (D-Bug and Petari) work fine on a standard Falcon.

So I was thinking: hey, it works on 030, so no cache troubles or whatever. It's 100% CPU only game (no DSP of course...), it runs purely in ST RAM (not even fastload flag enabled) so why it wouldn't work on the CT2 where the only difference is 030@50 MHz?

And indeed, why it doesn't? The only thing I could think of is that the adaption code tries to be too smart and doing some magic with checking hardware but that's a very weak hypothesis. CT2 even has a pure "CPU only" mode, where everything is as is (i.e. clean TOS 4.04 in ROM, no TT RAM etc) except the CPU speed and nope, doesn't work there either.

Can anybody think of a reason? Imagine Lotus @ 50 MHz, that must something.

[KyleB]

These games were written expecting an STFM, so the programmer made assumptions. Takes X nanoseconds to complete this loop, at which point the hardware will need me to fart the output to address Y...

Make the computer 12 times faster and those assumptions are no longer true. Hard drive patches can only compensate for so much. Many of the patched games I've tried "run" at 16Mhz but have odd behaviors already.

[mikro]

I know what you mean but I find it strange that it works on 16 Mhz (i.e. twice as fast + caches) but doesn't on 50.

[KrisW]

It could be that the ST is fundamentally a 8/16MHz system, and 50 isn't a nice multiple of that.

Also, I assume that at 50MHz, you're using faster RAM too. The 680x0 family was quite flexible about RAM speed, which allowed very slow RAM even on a nominally fast master clock speed... Just because the Falcon is clocked at 16MHz, it doesn't mean it is necessarily reading RAM twice as fast as ST.

[arf]

so why it wouldn't work on the CT2 where the only difference is 030@50 MHz?

What exactly are you getting when you run it? 'Doesn’t run' isn’t really the most information-overloaded error description A black screen? Garbled graphics? Unplayable controls? A message saying "too many MHz, will stop responding now"?

[mikro]

What exactly are you getting when you run it? 'Doesn’t run' isn’t really the most information-overloaded error description A black screen? Garbled graphics? Unplayable controls? A message saying "too many MHz, will stop responding now"?

Haha, good point. In this case it's quite fitting actually - I skip the intro (D-bug version has a real intro, Petari's version has a text screen + game box scan in hires) which works in both versions and then I get 'out of scan range' on VGA (where it should work too) and totally messed up sync on RGB. But fair enough, I could understand if the game played (sounds, some moving image) but nope, it's dead in the water.

[Petari]

I don't think that only difference is CPU clock. In CT60, CT2 68060 CPU is used, if I'm not wrong (could not find exact descript. of CT2 right now) .
And that CPU is not 100% compatible with 68030. For instance instruction movep is removed. And that's used in many games. The result is almost certain crash.
Higher speed can cause crash too, as KyleB pointed. Or just making game unplayable fast. That problem is present on TT too, pretty often. I added in many special slowdown code for TT .
Most of games is coded with work on ST only on mind. Even worse - many to work on specific TOS versions only - just because they were not able to test it on future TOS versions, and Atari DOCs were not clear and enough detailed how to make proper code in that aspect. But that part is solvable pretty well with launchers. CPU incompatibility is harder thing, and needs changes in code self. Sometimes on many places (Infestation) .
Speed problem may be even harder to fix. Klapauzius started with making CT60 compatible game adaptations, but that did not last long.
Quote from Klaz: "About 30 individual changes to the code had to be applied to make it work properly on the 68060 CPU. " - now imagine how much time it needs to trace down all those code parts and find good replacement code.
Basically, I think that CTxx is not intended for gaming. May be good for some special coded for it, or at least coded to be compatible with. Like some Doom for Falcon. Older games are just not done with running on such beast in mind.

[exxos]

The only thing found relating to the clock speed is sync code used in demos or games. Rasters screw up, its well known. Higher speeds don't normally add anything worse to that problem.

TOS is also next problem, again well known issues with some games etc.

Also (like Peter said with instruction issues) like the 020 isn't 100% compatible with 68K code. I am not sure, but assume 060 isn't 100% 68K compatible either. Possible some 68K instructions could even be missing in the 060. Internal FPU isn't complete for example.

[mikro]

Guys, no arguments from me there - 100% agreed. But if a game works flawlessly on 68030@16 MHz and the only change is 68030@50 MHz (that is what the CT2 uses) without any TT RAM or modified TOS, there must be something else going on.

The first screen after the intro is the word protection (cracked of course) and even that doesn't show up. System is totally dead. So I'm wondering what kind of code that could be that it relies so heavily on 16 MHz clock?

[Petari]

Micro, can you give some %-age of games not working with CT2 at 50 MHz ? Should try my later adaptations, those after 2013 . 1 game is really not enough to make some reliable conclusions.
There is always code which can fail at higher CPU clock. It is not much present. Maybe 5-10% of games will crash, freeze because that. There are more problems with screen sync, too fast gameplay. In those cases adding some delays on proper place usually solves problem.