Originally Posted by Photon
Fastmem didn't (and largely doesn't) really help games much. Here's why: You could put all the code and mapdata in it, but that would likely only use 150k for a big game. You couldn't have graphics, sounds, or misc. buffers for such in it. The point is that loading from disk was and is a replacement for loading the whole game in memory. And this is why loading from disk is an advantage to 'just write huge binary, who cares if people have memory for it'. (And yes, the reason it's trackloaded from disk and not file-loaded is that a 10yo could copy it in 5 minutes then.)
Loading a big part of the game into memory was an advantage for those games which used in worlds (parts of) the same graphics over and over again. For this reason many track formats even had a rudimentary custom file structure on them. These parts could then be copied to expansion memory and loaded from there. I made once a version of Projectyle for me which loaded the half of the disk which contained the arenas, score boards etc. multimedia data in a 512 k expansion memory, and it showed the goal faces with 2 instead of 30 seconds delay. (A pity that the original company hadnt done this).
Otherwise, the used memory detection routines were mostly broken, until the fact that Pang detected the Amiga-XT-Brigdeboard-Card-State-Transfer area as ram, crashing the Game, because the XT-Side modified the data. The ONLY correct way to detect a ram area is to allocate it with the OS, eg allocate from $80000-$d0000 in chipmem with AllocAbs and later assume that that are 512 k. Same for Non-Chip-Ram: Allocate the largest free "Fastram" block, make sure it is larger than 256 k (to exclude these small expansions), and clip its boundary to a 512 k border; in the case of old customized handmade hd installs you may also leave the odd start if the game runs with it and it is large enough.