TF536 on the ST

[terriblefire]

I've tried Frontier. The game runs but there are some issues and breakage.

You have to remember that there are two flags, data in fast ram and program in fast ram. The former allows the program to allocate memory and the former tells the OS where to put the program code.

(This is on a TT)

I'd start with program in fast ram and data in st-ram. It may be that the game needs patched to make it alloc anything DMA'able to ST-RAM and the rest to Fast ram. The basic game should cope with this because the Amiga version does.

[agranlund]

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)

[terriblefire]

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.

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

Will try them out. thanks.

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)

Isnt this what WHDLoad is for Amiga? I think the GameX system does something similar if not as complete (i honestly don't know, im speculating). But actually it might be reasonable to port WHDLoad.. its clever but not overly OS dependant.

[agranlund]

Will try them out. thanks.

It will throw TOS206 into FastRAM as well and make the desktop a whole lot faster

Isnt this what WHDLoad is for Amiga? I think the GameX system does something similar if not as complete (i honestly don't know, im speculating). But actually it might be reasonable to port WHDLoad.. its clever but not overly OS dependant.

I honestly don't know, never thought much about it until now. But with having the MMU available, and the fact that it's trivial to replace any TOS system call with own code should open some doors I would think.
Might be a good idea to take a look at what WHDLoad is doing, and GameX as well for that matter

[exxos]

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)

Could you write a FRB cookie installer ? This is driving all of us nuts as nobody knows how to set it up.

[agranlund]

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)

Could you write a FRB cookie installer ? This is driving all of us nuts as nobody knows how to set it up.

maprom.prg does all the required things (and the sourcecode is included on my Github)
It tries to read from 0x01000000 onward until it hits a bus error and then it tells TOS about how much new memory it found.
64Kb ST-RAM is allocated for the FRB and the _FRB cookie is set accordingly.
It also sets up the MMU table the same way as is done for Falcon and TT.
Then it proceeds to copy TOS from ROM into FastRAM and puts the correct entries in the MMU table to transparently redirect rom access to the fastram copy.
(It redirects some TOS system variables as well but this doesn't really do a dramatic difference. But I kind of went nuts with it when I was reaching for >1000% average score in Gamebench )

Or do you mean split some of that into separate programs? Or just the cookie stuff?
That could be done if you want to.

[exxos]

Or do you mean split some of that into separate programs? Or just the cookie stuff?
That could be done if you want to.

Its just we need a example how to install the FRB cookie on its own, of course needs to allocate the 64K buffer as well. The ASM code and compiled would be really useful as there isn't any universal cookie installer for alt-ram boards. Setting up the alt-ram is simple enough.. Will look at your program as well, but I'm not a ASM programmer guy

EDIT: Wheres your github page ?

[agranlund]

This is what to look forward to with the TF accelerator
This is the 534 in my ST. It's running a custom build of EmuTOS, and NVDI is installed, so your milage may vary but it's one heck of a snappy machine..

[agranlund]

Or do you mean split some of that into separate programs? Or just the cookie stuff?
That could be done if you want to.

Its just we need a example how to install the FRB cookie on its own, of course needs to allocate the 64K buffer as well. The ASM code and compiled would be really useful as there isn't any universal cookie installer for alt-ram boards. Setting up the alt-ram is simple enough.. Will look at your program as well, but I'm not a ASM programmer guy
EDIT: Wheres your github page ?

It's here: https://github.com/agranlund/tftools
The source is asm and builds with Devpac3, you are of course free to use it for whatever you want
(But I think it would probably be quicker and easier to make a small C program for just doing the cookie and it's memory)

[exxos]

It's here: https://github.com/agranlund/tftools
The source is asm and builds with Devpac3, you are of course free to use it for whatever you want
(But I think it would probably be quicker and easier to make a small C program for just doing the cookie and it's memory)

Thanks, I never used C either, some other guys may have

Think your up to 060 speeds there ! BTW - you can just press "A" for all tests, @terriblefire Uses the menu as well, to much effort