Adapted games: what makes them incompatible at >16 MHz?
Moderator: troed
Adapted games: what makes them incompatible at >16 MHz?
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.

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.
Re: Adapted games: what makes them incompatible at >16 MHz?
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.
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.
Re: Adapted games: what makes them incompatible at >16 MHz?
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.
Re: Adapted games: what makes them incompatible at >16 MHz?
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.
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.
Re: Adapted games: what makes them incompatible at >16 MHz?
What exactly are you getting when you run it? 'Doesn’t run' isn’t really the most information-overloaded error description


--
Against signature spam!
Against signature spam!
Re: Adapted games: what makes them incompatible at >16 MHz?
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.
Re: Adapted games: what makes them incompatible at >16 MHz?
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.
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.
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.
Re: Adapted games: what makes them incompatible at >16 MHz?
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.
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.
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter
https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.
https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.
Re: Adapted games: what makes them incompatible at >16 MHz?
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?
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?
Re: Adapted games: what makes them incompatible at >16 MHz?
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.
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.
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.