EmuTOS should load Frontier into Fastram by default.
TOS 206 does not initialize fastram unless it identifies the machine as a TT so it needs a bit of help.
There's more to it than just letting TOS know about the ram. It needs to set up the st->fastram temp buffer else DMA will not work and so on..
The MMU also needs to be set up in a state that is at least like the Falcon or TT.
If you have a blitter installed it get's even worse if anyone including TOS tries to use it - Atari never had a machine with both FastRAM and Blitter so this case is not covered by it..
Put maprom.prg (and blitfix.prg since you have a blitter) in the AUTO folder, and in that order, and you should be golden.
It will even patch the blitter code inside TOS206 to allow it to use the blitter as long as both SRC and DST is in ST-RAM (and fall back to cpu-copy when this is not the case)
https://github.com/agranlund/tftools
Now that TOS knows about the fastram it will load applications into it unless the application forbids it in its header (there are separate flags in the header to control if it can load into fastram and if it should malloc from it).
Frontier runs fine here, loading into fastram and allocating memory from it :)
You will still find that most games will not run or at least not display anything when running from FastRAM.
If they're made before the TT they wont have a clue about such ram and will think that all ram is accessible by all hardware in the system.
If they set their own screen pointer they are pretty much screwed for graphics when loaded in fastram if their screen buffer is in the .bss section...
Slightly better if they malloc() their buffer because then you can at least let it load into fastram but force it to malloc from stram.
If they know about fastram they will make sure to Mxalloc the screen buffer from ST-RAM and malloc the rest. I assume very few games do this though..
Some games may just reuse the screen that TOS already allocated and in that case at least that one is ok, but if they double buffer it's a problem again.
Many older games assume 512Kb ram and load themselves into an absolute address. Sometimes at a very low address, overwriting the parts of TOS it's not going to be using anway.
At least disk access is usually not an issue since TOS automatically detect if the destination is fastram, in which case it will DMA to a temporary buffer in ST-RAM first and then cpu-copy the data to the requested destination in fastram (this is what the _FRB cookie is for, it tells the system where in memory this temp buffer is located)
It becomes an issue if the application does not use TOS, or if TOS does not know that the destination is in fastram - could happen in a theoretical loader that remaps a large chunk of ST-RAM to FastRAM.
I think it would be hard to make a single generic loader that can make any old game run from fastram.
It would likely be possible for a few cases where the game is using TOS for disk access and settings the screen pointer using TOS system calls (which could be intercepted and replaced with a buffer in ST-RAM, with the appropriate entires in the MMU table to trick the application everything is fine)