TF536 - Atari firmware - Rev2 TF536

[exxos]

what about 6880 ? That game runs very very smooth now.. although the rasters are going nuts!

Child off a few scan lines off the top of the screen and get even higher

Hmmn.. maybe it's not considered cheating by @exxos if it could also make those Castle Master sharks swim even faster

You really need to try castle master on a stock machine once you get inside the castle its even worse.

[agranlund]

Child off a few scan lines off the top of the screen and get even higher

I think this is far as I can push it without even more help from the cpld, and I am really running out of space (and brainpower) to do so.

You really need to try castle master on a stock machine once you get inside the castle its even worse.

Hehe, I remember being quite impressed by Total Eclipse on a stock machine as a kid. Same with 3D Construction Kit.
The framerate was probably rubbish by todays standards though

[Steve]

@agranlund Can I run some of these special versions on my TT, think it'd get some awesome results? Are they available to download.

[agranlund]

@agranlund Can I run some of these special versions on my TT, think it'd get some awesome results? Are they available to download.

I think those special Frontbench builds may be slower than the normal one on a TT.
They have a quite large overhead of additional work (in fastram space), which is worth it to avoid 8Mhz writes, but probably not on a TT with 16mhz st-bus.

(@Badwolf may correct me if I’m wrong, I believe he ran it on a Falcon - but i can send you those builds when i get home)

The crazy speeds above 6000 are from the standard Frontbench program, but it’s boosted by experimental firmware features in combination with a software running in the background.
This only works on the TF536 in my machine at the moment.

I can’t really see ”gofast.prg” being useful for much other than Frontier, but it’s fun so I still want to develop it a bit further and improve compatibility
It makes a huge difference when playing Frontier proper!

[Cyprian]

I think those special Frontbench builds may be slower than the normal one on a TT.
They have a quite large overhead of additional work (in fastram space), which is worth it to avoid 8Mhz writes, but probably not on a TT with 16mhz st-bus.

the ST-RAM in the TT has the same memory access scheme for the CPU as in the ST - 500ns for every memory slot.
The only difference is 32bit width vs 16bit.

[agranlund]

the ST-RAM in the TT has the same memory access scheme for the CPU as in the ST - 500ns for every memory slot.
The only difference is 32bit width vs 16bit.

Aha, so 16bit writes and (cache-miss) 16bit reads are as slow as on the ST (<4MB/s)?
The others at around twice the performance just like on Falcon?

@Steve I sent over "fbcmplu.prg" and "frontblt.prg" I hope badwolf doesn't mind.
Would be interesting to see the result.
As mentioned, they trade a huge instruction and extra (fastram) memory access in order to avoid a smaller number of ST-RAM accesses.
An exercise in seeing to what extent one can/should go to avoid ST-RAM, and at what speed differences it makes things good or bad

[alexh]

Slightly on topic. Over at EAB (English Amiga Board) one member has been writing reallocation tables to move CPU code from CHIP-RAM to FASTRAM. ChipRAM has very similar characteristics to ST-RAM (7.09MHz, 16-bit, limited access cycles).

They recently patched Castle Master and I showed them your video, they seemed impressed.

http://eab.abime.net/showthread.php?t=1 ... ter&page=5

The programmer seems to imply that (at least on the Amiga) that Freescape was relatively easy to relocated execution code to FastRAM

[Cyprian]

the ST-RAM in the TT has the same memory access scheme for the CPU as in the ST - 500ns for every memory slot.
The only difference is 32bit width vs 16bit.

Aha, so 16bit writes and (cache-miss) 16bit reads are as slow as on the ST (<4MB/s)?
The others at around twice the performance just like on Falcon?

exactly,

in case of 16bit access, Falcon has an advantage that the ST-RAM bus is clocked twice faster than in the TT/ST

[agranlund]

With stability fixes etc, 6509 frames. Feels very smooth indeed.
(Same setup without gofast.prg: 4110 frames)

That "gofast.prg" utility program program relies on the ability to toggle L2 write-through in the firmware so it is currently relevant for this thread.
But now that I've been toying with this for a bit I believe it should be possible to achieve close to the same bump without having that feature.
That would be nice since the r2 board is already low on space in the cpld and I believe the r5 even more so.

This is just too good not to share:

[DoG]

Yikes, that is smooth.