There are other games, which load all files right after start, and no later disk access, maybe only highscore save. For instance Mercenary. So, can be singleparted relative easy.
I never thought of doing that. I would have thought that the level loader would have just allocated one buffer and load the selected level into that for half-meg simplicity. Does it malloc space for each level and if there is not enough ram overwrite a level and load it from disk?"
That would be useful, but in many games they did not take effort about such things. They were happy that it works at all
And it is not just joke - as I see, many is written by people not much familiar with ST and/or MC68000, so there is lot of inefficient code and even some bugs in (mostly) IKBD coding.
Typical, not so well coded ST game looks like: using TOS calls a lot, so for floppy access too. Not relocatible code, but with fixed start address, what is usually too low for TOS 2.06 . Not relocatible code is good, as then you can use fixed screen location, and will not happen that code will conflict with screen, which is usually right below 512K, as goal is that it work on 512K machines. But this way is not OK for higher TOS versions, which allocate more low RAM, and especially not good for hard disk users.
"I wonder if it could have been better if they had made it for one meg machines. It was dog-slow as I recall.
It would be an interesting project to disassemble it to see if something could be done to speed the code up a bit."
It was average slow/fast, I would say. There are racing games with better and worse framerate. I'm sure, that it can be made faster, but that's really lot of work. Game self is not that much good, IMHO .
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.