Agranlunds TF534 Build

[terriblefire]

- i plan on implementing the necessary Monster ram size register on the TF so that emutos can autodetect the TF as monster and install the altram.

What is this? if i know about it i'll add it to stock firmware with ATARI parameter on.

[exxos]

ah I see TF has updated 3 months ago on git. So he must have uploaded the later firmware which I was also testing out.

[agranlund]

What is this? if i know about it i'll add it to stock firmware with ATARI parameter on.

MonSTer ram size register appears to be at 0xfffffe00 and EmuTOS reads from here to detect it.
Unfortunatelly EmuTOS is then hardcoded to change the setting to 8MB (or 6MB for STE) :/

Locally, I will just rebuild EmuTOS to use the value it reads, but it makes it somewhat tricky to include MonSTer pretend in an official firmware due to this behavior? Except for on TF boards with >=8MB of course.

Having the MonSTer register(s) on the TF would also mean that we would be able to use the MonSTer alt-ram driver instead of writing our own.

The Monster Alt-RAM driver with source can be found here: http://www.fairlite.co.uk/AtariKit/monster/monster.html
It appears there are some other registers as well but since I am at work I haven't had time to see if we actually need to include any more of them.



Here's a rough copy-paste from the EmuTOS sources:

#define MONSTER_REG 0xfffffe00UL
has_monster = check_read_byte(MONSTER_REG);

/* Add MonSTer Alt-RAM detected in machine.c */
if (has_monster)
{
/* Dummy read from MonSTer register to initiate write sequence. */
unsigned short monster_reg = *(volatile unsigned short *)MONSTER_REG;

/* Only enable 6Mb when on a Mega STE due to address conflict with
VME bus. Todo: This should be made configurable. */
if (cookie_mch == MCH_MSTE)
monster_reg = 6;
else
monster_reg = 8;

/* Register write sequence: read - write - write */
*(volatile unsigned short *)MONSTER_REG = monster_reg;
*(volatile unsigned short *)MONSTER_REG = monster_reg;
KDEBUG(("xmaddalt()\n"));
xmaddalt((UBYTE *)0x400000L, monster_reg*0x100000L);
}



/* ==== check_read_byte =====================================================
*
* check_read_byte - Verify access to the memory pointed to by the ptr
*
* C call: int check_read_byte(long);
* returns 0 if reading the address caused a bus error
*/
_check_read_byte:

[agranlund]

Haha I just spent way too much time troubleshooting why accessing the onboard RAM only gave me bus errors, including re-soldering the ram and cplds... and now I feel like a complete idiot
The firmware I am using was apparently mapping the onboard RAM to 0x40000000, not 0x00400000 like the MonSTer as I assumed. So basically... never assume

As I was about to remap the onboard RAM to 0x00400000, it got me thinking though.

Isn't it instead better if the TF cards, with Atari specific firmware, maps the onboard ram as TT RAM instead of "alt-ram"?

After all, that's how Atari introduced FastRam, and it would also mean that we could, just the TT, support much more RAM.
(I guess it's not relevant for the TF534, but very interesting for the TF536)

TT RAM lives in the 32bit memory space and starts at 0x01000000:
$01000000-$013FFFFF|TT Fast Ram
$01400000-$FDFFFFFF|Reserved

(Since TT's can have 128MB RAM expansions, I assume that ram just keeps going into the Reserved space? Or does anyone know for sure? I never had a TT)

Another big benefit would be that EmuTOS should be able to auto-detect and install it, and perhaps even Atari TOS (unless it's depending on some other registers before starting TT RAM detection, or if perhaps only TOS 3.0 and higher does it?)
Nevertheless, if the OS cannot auto-detect it we would be no worse off anyway, and would have to install it in a similar fashion to how the MonSTer application does it.

The only drawback I can think of is perhaps compatibility with a theoretical badly written application, that assumes 24bit addressing and leaves garbage in the upper 8 bits - but that would have been a problem on a TT as well - and I suppose Atari already tried to solve this issue with PRG fastram load/alloc flags.

I'm just thinking out load really. I will remap the RAM as TT ram on my card and give it a go.
But if that works well then that would be my suggestion for the official firmware.

[Cyprian]

TT RAM lives in the 32bit memory space and starts at 0x01000000:
$01000000-$013FFFFF|TT Fast Ram
$01400000-$FDFFFFFF|Reserved

(Since TT's can have 128MB RAM expansions, I assume that ram just keeps going into the Reserved space? Or does anyone know for sure? I never had a TT)

Storm supports up to 256MB TT-RAM
http://wiki.newtosworld.de/index.php?ti ... sh_Version

[agranlund]

Yeah ok, I'm now convinced that the onboard ram should be mapped to TT-Ram space

It basically makes it just work out of the box with EmuTOS.
Atari TOS 2.06 does not detect TT RAM, probably need Tos 3.01 or newer for that, so I'm going to write a simple "driver" to enable it under 2.06 also.

DSC_3078.JPG (33.05 KiB) Viewed 4347 times

DSC_3081.JPG (84.5 KiB) Viewed 4347 times

Nice speed boost when running the application from FastRam.
I used the TT application FLAGSETTT.PRG to flag Gembench to both load into and allocate from FastRAM.
EmuTOS itself is not running from FastRAM here, but it can be compiled to be RAM-Loadable from any location so that's on the todo list.

DSC_3079.JPG (34.5 KiB) Viewed 4347 times

TT version of Yaart just works of course.

[PhilC]

Looking good

[Cyprian]

nice figures Agranlund.

Can you do please NemBench v2.1 test?
http://www.atari-forum.com/viewtopic.php?t=17970

[agranlund]

Can you do please NemBench v2.1 test?

Sure! And thanks for bringing that benchmark program to my attention, I didn't know about it.

Sadly no FPU results as I don't have an FPU - I do plan on ordering one from the Exxos store though.

Also, the readme advices to use Mono mode but I only have a homemade vga cable for colour display so I ran it in medium resolution.
"Use ST-high resolution monochrome (640x400x2) when running the tests, as this reduces the detrimental impact the video hardware can have on the bus when trying to display lots of pixels and colours."

If I understood it correctly, these numbers are in comparison to a stock 16Mhz Falcon.

DSC_3082.JPG (76.81 KiB) Viewed 4325 times

[8 Bit Dreams]

will this FW be uploaded somewhere? Would like to test it..