Game compatibility with later Amigas

[Radertified]

One for anyone that knows their stuff when it comes to game compatibility.

When I think of Amiga game compatibility, I generally consider Kick 1.3, OCS, 512kb chip + 512kb fast the gold standard.

What is the most common cause of game incompatibility, if anything at all?

Kickstart 2.0+ hurts things, but does OCS/ECS/AGA break compatibility with older games? Does having more chip RAM break anything?

An Amiga 500+ has 1mb chip with an ECS chipset, and Kickstart 2.04. If I replaced the Kickstart with 1.3, would game compatibility be as good as the gold standard I listed above?

Anyone know of any real world examples where more chip RAM or ECS breaks a game?

[StingRay]

What is the most common cause of game incompatibility, if anything at all?

Self-modifying code, direct ROM access, missing blitter waits, wrong access to hardware registers, 24-bit problems etc. etc. etc. The list is actually almost endless.

[Radertified]

Those are mainly software issues.

Would that imply ECS with 1mb (or more) chip is just as compatible as OCS with 512kb chip?

[StingRay]

Originally Posted by Radertified

Those are mainly software issues.

Erm, yeah...

Originally Posted by Radertified

Would that imply ECS with 1mb (or more) chip is just as compatible as OCS with 512kb chip?

No!

[musashi5150]

If you've got a 1MB chipram but don't have 512K trapdoor RAM at $C00000, this is sometimes a kicker too

But again, another software issue.

[roondar]

How much compatibility there is between Amiga models all depends on how you look at it:

• From the perspective of the custom chipset itself (i.e. what registers do what, what registers are at what address) the compatibility is pretty high. Not exactly 100%, but really rather close - most programs that fail on higher specced Amiga's do not fail because of chipset differences
• From the perspective of the memory map, there are some clear incompatibilities between the various models. Not every Amiga has RAM in the same locations, though they all at least have the first 512KB of chip memory mapped to the same location (but note, the A1000 initially only had 256KB). Some have fast memory, some do not. Many programs that fail end up failing because of this: they either expect there to not be any fast memory or they expect memory at specific addresses
• From the perspective of the CPU type, the compatibility is a bit more of an issue. Each member of the MC68K series is slightly different and it's pretty much possible to write code that will only work correctly on a specific model. Many incompatibilities in Amiga programs stem from this issue. There's so many things that can go wrong here that I'm not going even try to list them
• Lastly, from the perspective of the OS the compatibility is good, but not perfect. It's certainly possible to write code that only runs on a specific Kickstart/Workbench revision

All these things combine to create potential problems for code that assume a 68000/no fast ram or only slow ram/KS1.3.

[Minuous]

Originally Posted by roondar

From the perspective of the custom chipset itself (i.e. what registers do what, what registers are at what address) the compatibility is pretty high. Not exactly 100%, but really rather close - most programs that fail on higher specced Amiga's do not fail because of chipset differences

Apart from the infamous modulo issue which can give garbled display of OCS modes on AGA machines; I had countless games affected by that one :-(

[roondar]

Originally Posted by Minuous

Apart from the infamous modulo issue which can give garbled display of OCS modes on AGA machines; I had countless games affected by that one :-(

I'm not aware of any modulo issues for OCS modes on AGA machines? Never needed to do anything different for it to work in my code.

So now I'm interested , do you know what it is exactly?

[Galahad/FLT]

Originally Posted by Radertified

One for anyone that knows their stuff when it comes to game compatibility.

When I think of Amiga game compatibility, I generally consider Kick 1.3, OCS, 512kb chip + 512kb fast the gold standard.

What is the most common cause of game incompatibility, if anything at all?

Kickstart 2.0+ hurts things, but does OCS/ECS/AGA break compatibility with older games? Does having more chip RAM break anything?

An Amiga 500+ has 1mb chip with an ECS chipset, and Kickstart 2.04. If I replaced the Kickstart with 1.3, would game compatibility be as good as the gold standard I listed above?

Anyone know of any real world examples where more chip RAM or ECS breaks a game?

Stingray said it all, but to expand upon what he said.

1). Different Kickstarts rarely cause problems unless the games programmer has done something quite stupid as in directly calling routines in the Kickstart ROM or making assumptions that certain values will be in a set position in the Kickstart ROM.

Most of this type of problem was in the early days of Amiga where the programmers didn't really understand that there was a specific, virtually 100% error free way of getting the results they needed no matter what ROM was present.

2). Plenty of poorly coded memory detection routines caused problems where they couldn't accurately detect memory at $80000 or only assumed extra memory at $c00000

3). Lack of blitter waits. Some programmers wanting to get the best out of the A500 68000 would not use blitter waits, because it meant that whilst the game was using the blitter, their code would be doing other things before using the blitter again and on 68000 A500's, the blitter being considerably faster meant that it had already completed the job before being called on to do another blit.

68020 and the code is now running significantly faster where the missing blit waits are a problem, now the processor is whipping through the code so quickly, that before the blitter has finished with its blitter operation, its already being given parameters for the next blit operation, cue lots of graphic crap on screen as nothing gets blitted properly.

4). Self modifying code, especially in a lot of vector routines,causes problems because of the cache features of the 68020.

5). Incorrect stack frame, or assuming its a certain type. There is a play routine used by Teque for Ben Daglishs music that does this, farting around with the stack, which causes the music not to play because they've assumed its a certain type.

6). CPU timed stepper routines. This is one of the biggest. Back in the day when I did a lot of AGA fixes outside of WHDLoad, this was quite a big problem on a lot of games. Processor delays would be put in place to give the drive time to step to the next track, the problem was that on 68020 the processor would process that delay much quicker, which meant that the drive wasn't given enough time inbetween steps, and the loader would fail.

7). 24bit accesses on addresses was also quite a big one. In an effort to disguise code for copy protection purposes, or to utilise memory better, sometimes the very upper byte of an address would be used for something different, on 68000 that upper byte would be ignored when accessing as an address, but obviously on a 68020, it would access the full 32bit of the "address" and interpret the upper byte as part of the address, as it should do, pretty sure Xenon 2 had this problem where certain pickups did nothing because of this programming method, in the case of Double Dragon 2, the entire game just wouldn't work because every single custom hardware access was obscured like this.

8). Crap programming. Most of this stuff was in the infancy of the Amiga, but there really was some shocking programming at times which was entirely the cause of the game failing on anything other than 68000.

Routines that use the wrong instruction to move information into the custom registers (i.e. copying a colour palette using longwords instead of words), moving values into registers that haven't even been implemented yet, hard coding bootblocks to load information too low in memory, trying to setup supervisor mode in weird ways that operate correctly on 68000 but will work differently on 68020.

[Minuous]

@roondar:

No, but I remember it affects AMOS 1.34 and earlier and any game compiled with it, also Ultima 6, etc.

[robinsonb5]

Originally Posted by roondar

I'm not aware of any modulo issues for OCS modes on AGA machines? Never needed to do anything different for it to work in my code.

So now I'm interested , do you know what it is exactly?

It's just that in higher AGA fetch modes the modulo and alignment requirements are different, which can trip up OCS/ECS software that hits the hardware when run from Workbench, because that software doesn't know that it needs to cancel the higher fetch mode.

There's no issue if you're booting straight into your code, or if you do a LoadView(NULL); WaitTOF(); WaitTOF(); before hitting the hardware, or manually set the fetch mode appropriately.

There are various wrapper/launcher programs which will do the LoadView(NULL); thing before launching a program, to solve this.

[roondar]

Originally Posted by robinsonb5

It's just that in higher AGA fetch modes the modulo and alignment requirements are different, which can trip up OCS/ECS software that hits the hardware when run from Workbench, because that software doesn't know that it needs to cancel the higher fetch mode.

There's no issue if you're booting straight into your code, or if you do a LoadView(NULL); WaitTOF(); WaitTOF(); before hitting the hardware, or manually set the fetch mode appropriately.

There are various wrapper/launcher programs which will do the LoadView(NULL); thing before launching a program, to solve this.

Gotcha, that makes perfect sense. Thanks for the info.

[Torti-the-Smurf]

WHDLoad to the Rescue !

Thanks goes to all those awesome guys that do theres WHDloads

[Radertified]

I think I need to rephrase my original question because I was talking more of the hardware side of things rather than software. I know about the myriad of things that can go wrong due to programming trickery, timing, etc.

I guess the easiest example is an Amiga 500+. Is it just as compatible as an Amiga 500? If not, why? RAM? Kickstart? Chipset?

Another example. If I created an imaginary 68000 ECS Amiga and 256gb chip RAM. If a game was designed for a 68000 OCS Amiga with 512kb chip RAM, could that imaginary Amiga run it, hopefully without issues? After all, it's got the 68000, and assuming ECS is completely compatible with OCS and having a stupid amount of RAM does not matter, the game should run if it doesn't do something stupid.

So, does ECS mean OCS + more? Does AGA mean ECS + OCS + more?
Does 2mb chip mean the same memory mapping as 512kb chip?
etc.

It's a little hard to explain but I hope you guys get what I mean.

From what I'm reading above, memory mapping would be the main cause for incompatibility between Amiga's.

[roondar]

Well, the core issue is that it's the software that causes incompatibilities and not the chipset. For example, the A500 and A500+ are virtually identical apart from one having more memory and a ECS revisions of the Denise and Agnus chips.

This means that on paper any 512KB A500 game should just work. If it doesn't then the code does things it never was supposed to do in the first place (such as assume things about what the OS does where in memory or write to illegal custom chipset registers).

The same goes for OCS vs ECS vs AGA: on paper these chipsets will not cause any issues as all the old registers are still there and accept the exact same set of values. In fact, the ECS and AGA chipset default to OCS compatible values for the new registers (if applicable). If problems arise, it's due to software doing stuff it never was supposed to do in the first place (such as taking over the OS and doing so badly to boot).

[robinsonb5]

Originally Posted by Radertified

...the game should run if it doesn't do something stupid.

You've pretty much summed up the entire subject, right there!

[jotd]

we discover new stupid stuff every time we try to fix another game.

[Radertified]

I guess the answer is essentially the hardware is largely backwards compatible. It's only when software gets involved that compatibility issues arise.

That's what I wanted to know. Thanks for the responses everyone!

[jotd]

hardware was designed with backwards compatibility in mind. And the OS was supposed to fill the gaps. But most games don't use the OS, or only partly, or use code that depends on the CPU speed...

With a little work, all software created 35-25 years ago can run on modern machines.

[Minuous]

Originally Posted by jotd

With a little work, all software created 35-25 years ago can run on modern machines.

If only these problems were restricted to old software. Unfortunately there are still new brain-dead programs that make these kind of erroneous assumptions being written in 2020 :-( Like this one: http://eab.abime.net/showthread.php?t=102380