exxos's Atari, Amiga & retro forum

:lolbig: :bravo:

Very interesting thread and very nice work.

Interesting solution to ST-RAM speed with an interesting problem to solve with ST-RAM write capable masters...

Out of curiosity what write capable masters are there? The FDC and HDC(ACSI) were mentioned. Blitter? Do you intercept blitter detection? Make the SW to use CPU routines? (which will be much faster) or are you using an ST without a blitter? (Excuse me if this is a well answered question)

Are there no co-processors that are able to write to ST-RAM? MFP?

alexh wrote: 28 Jul 2022 09:07 Out of curiosity what write capable masters are there? The FDC and HDC(ACSI) were mentioned. Blitter? Do you intercept blitter detection? Make the SW to use CPU routines? (which will be much faster) or are you using an ST without a blitter? (Excuse me if this is a well answered question)
Are there no co-processors that are able to write to ST-RAM? MFP?

To my knowledge it's only FDC/HDC + Blitter?

I haven't bothered with Blitter for this purpose yet though.
Blitter in TT-RAM enabled systems is a broken and non-functioning setup in itself and the easiest solution would be to just have the accelerator or MMU tricks hide the blitter hardware completely.
(Alternatively, make it mandatory to either remove the blitter from the machine, use EmuTOS, TOS3, or NVDI for TOS1/2/4 to prevent TOS from blitting - like all other accelerators)

But.. I have one in my 520ST and I do care about the blitter, so blitfix.prg(*) was born to allow me to run the 5 or so things that supports or requires Blitter on non-STE machines :lol:
I thought I'd perhaps look at making blitfix.prg aware of the L2 situation, alternatively build blitfix into maprom itself?


(*) blitfix.prg

There are three cases to consider:
1) TOS, and programs that use TOS for all things blitter
2) Programs that ask TOS if the Blitter is there, and then use the hardware directly
3) Programs that ask the hardware directly, and then use the hardware directly

Blitfix acts slightly different depending on which TOS is running:

EmuTOS:
1) Blitfix does nothing here (EmuTOS already disabled HW blits for itself and TOS clean programs when TT-RAM exists)
2) If the caller is running in ST-RAM then EmuTOS is forced to say "yes" here, if not then it it returns whatever EmuTOS wants.
3) Nothing is done here, so programs using the blitter directly will do so

TOS206:
1) Blit parameters are checked and the blit will be either HW or SW depending on what is possible
2) Same as for EmuTOS
3) Same as for EmuTOS

Blitfix is nowhere near perfect though.. apart from the new L2 incompatibility it also never coped with a theoretical scenario of having mapped a different TOS compared to what is on the real ROM - in that case it would blit "rubbish".
It could really do with an update to better cope with all this.

I guess it should probably just "disable" the blitter when you are running with the L2 option enabled.
Some additional logic to the code that deals with 1+2, and the cpld to cover case 3.. or something like that.. I haven't given it very much thought.
It's been working ok-ish for the 5 or so things that use Blitter on non-STE machines.

alexh wrote: 28 Jul 2022 09:07 Out of curiosity what write capable masters are there? The FDC and HDC(ACSI) were mentioned. Blitter?
...
Are there no co-processors that are able to write to ST-RAM? MFP?

The only "true" ST-RAM DMA master is the DMA chip that serves FDC and ACSI. Or, if you want, you can say DMA/GLUE/MMU combined, because the DMA operation is really a cooperative work between the 3 chips.

Blitter is a generic 68K bus master that uses the "official" Motorola 68K bus acquisition interface. It can access main ram, but not only. In theory third party add-ons could use the same mechanism.

The main difference that is relevant here, is that a "normal" DMA bus cycle is (relatively) easy to snoop because all the buses and control signals are properly driven. "DMA chip" DMA doesn't drive the address bus and addressing is handled internally by MMU. This makes snooping the DMA transaction much more difficult.

Badwolf wrote: 26 Jul 2022 19:18 I've implemented a quick hack (more overhead than the above, but was quick to do at lunchtime) and sent it to Anders. Will be fun to find the results!

This thread is a bit all over the place, I love it :)
Perhaps this is more about programming techniques and fastram vs. st-ram in general but it's also a little bit related to the L2 cache so I think it's fine?

I found these experiments super interesting, thank you @Badwolf for sharing my curiosity and making these special builds :)

Here are the results:

The programs:
frntbnch.prg - Normal Frontbench, the game draws directly to ST-RAM
frontblt.prg - Game draws to Fastram, then blits entire screen to ST-RAM
fb_cmplu.prg - Game draws to Fastram, compares against previous frame in Fastram and writes only changes to ST-RAM
Even with the large overhead of comparing, fb_cmplu.prg ends up faster in both the L2 and non-L2 scenario.
I don't think this would be the case on TT or Falcon with their faster ST bus.
And of course, Elite has huge areas of the screen which is the same between frames so the results would vary for different games.

There is a TF536 relevancy for these experiments too..
The L2 currently has to be write-through for the sake of the Shifter but the results above show that it could be interesting and worthwhile to experiment with some fun alternatives :)
If the CPLD was to write-through only on changes, then I think the standard Frontbench could end up somewhere faster than the 4550 of fb_cmplu.prg..

agranlund wrote: 28 Jul 2022 20:54 The programs:
fb_cmplu.prg - Game draws to Fastram, compares against previous frame in Fastram and writes only changes to ST-RAM

Code: Select all

When you have L2 (very fast ST-RAM reads, very slow ST-RAM writes)
 fb_cmplu.prg	4550

W00t!

We have a winner! First Frontier* result over 4200?

BW



* Not strictly Frontbench as it's not comparing like with like software-wise, but still probably the highest frame count seen?

Badwolf wrote: 28 Jul 2022 21:00 We have a winner! First Frontier* result over 4200?
* Not strictly Frontbench as it's not comparing like with like software-wise, but still probably the highest frame count seen?

It does bring quite a bit of motivation to implement automatic ST-RAM write avoidance.
So the same score or higher could be achieved in the normal one (and any other thing that writes to ST-RAM -- which I guess is pretty much everything with graphics :lol: )

so... is this considered cheating? :hide: :)
Perhaps it is, it's not quite general purpose yet. Also not quite stable :lol:

But, 6068 frames on standard Frontbench!



(gofast.prg disables write-through for the L2 on the TF536, then makes sure the Shifter is being fed by refreshing L2 -> ST-RAM as needed)

agranlund wrote: 29 Jul 2022 21:20 so... is this considered cheating? :hide: :)

exxos says.. Probably yes :lol: But it also demonstrates what a marvel piece of software engineering can accomplish!
:bravo:

agranlund wrote: 29 Jul 2022 21:20 Also not quite stable :lol:

Matches most of the people on this forum as well I think :lol: :hide:

exxos wrote: 29 Jul 2022 22:32

agranlund wrote: 29 Jul 2022 21:20 so... is this considered cheating? :hide: :)

exxos says.. Probably yes :lol: But it also demonstrates what a marvel piece of software engineering can accomplish!

what about 6880 ? That game runs very very smooth now.. although the rasters (or some other palette related stuff) are going nuts!


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

agranlund wrote: 29 Jul 2022 21:20 Also not quite stable :lol:

Matches most of the people on this forum as well I think :lol: :hide:

:lol: