TF536 caches - WAS - FrontBench: using Frontier as a benchmark (Discussion thread)

[agranlund]

To me it kind of makes sense that L1 was disabled for st-ram to avoid an even bigger "support nightmare" for Tos206.
(and to a degree, to avoid costly cache-misses.. I'm sure some things may be slower with it enabled but in practice it looks like an overall gain. Things like Driller which has to run from st-ram get a noticeable speed bump)

I don't have the capacity to support, test or make sure it works on all hardware and tos configurations but I can upload it "as-is" unless anyone objects.
This is for TF536r2 and it's built from the last one I did way way back. It works for me, may or may not work for everyone else.
Was there any firmware releases past that? I don't want to upload some alternative firmware if there is some proper, official, channel. In that case I'd rather pass along the change if it's interesting to the maintainer.
It will need a different maprom.prg, I believe the one on Github is tagging the st-ram regions as not cacheable.


As a big caveat, my machine doesn't have a floppy drive, and I rarely use ACSI other than for transferring files from the PC.
I don't know but my bet is that L1 for st-ram, Floppy and Tos206 is a less than ideal combination.
The Ultrasatan appears to work in Tos206 even with cache enabled but it's not impossible if that is HDDriver coming to the rescue flushing caches because Tos206 itself certainly wont.

(Frontbench in 206 and caches enabled gets me the same 3000-ish score. Much lower if I disable cache)

[exxos]

@agranlund Yours was the last release of TF536r2 for the ST. I am working on rev5 https://www.exxosforum.co.uk/atari/last/TF536/index.htm albeit slowly.

The sources were not released for the TF536 and I basically took over hardware and software development as terriblefire passed the project onto me. Though I have not been spending much time on it overall because I am a n00b at verilog and the has not been really any noticeable interest in the ST TF536.

Incidentally the r2 536 firmware is not compatible with the r5 hardware anymore. This was done deliberately because I am doing other mods to the 536 to work better on the ST. so I did not want people installing the updated firmware on "outdated" hardware, then complaining it does not work properly etc.

I am using your MAPROM, caches do have some effect, but they are disabled for everything but alt-ram. https://www.exxosforum.co.uk/forum/viewt ... 975#p80056

I tried adding cache for ST-RAM but nothing changed ( not saying my code works) but if you are saying MAPROM inhibits caching of ST-RAM then that's probably why.

TOS206 does not work " out of the box" with ultrasatan, it screws up badly because of the caches. Though oddly running your MAPROM, seems to solve the problem. So I assume you have some fixes in MAPROM for the caches somewhere ? Turning off the cache in TOS206 menu seems to also solve the problem.. But that should not really happen. I'm not really convinced CIIN is working properly or as it should do. If I use the physical CDIS jumper, it also works fine. So something is still being cached even though it should be inhibited with CIIN.

Not really sure why your score is slightly higher than mine. Though if you are running a patched MAPROM to use ST-RAM cache then it could explain the about 100 frame increase. Though this could really be down to variations in hardware such as the clocks speed tolerances etc. It's difficult to say. If you are able to run GB6 with TOS206 in medium res, then it may give some indications as to what is different.

[Steve]

Though I have not been spending much time on it overall because I am a n00b at verilog and the has not been really any noticeable interest in the ST TF536.

I always will keep on disagreeing with you on this I remember even one of the first times I even heard of the ST TF536 is when you were talking about shutting it down because of perceived lack of interest. So that's one good point right there lol (And I basically leave/breath this forum) Secondly when I did finally look into it the IDE wasn't working, so I assume most people are in the same boat as me where they *need* IDE to make investing in such a product worth-while.

I think the product would do very well personally.

[exxos]

I always will keep on disagreeing with you on this

Well, How many people in the past year have built a rev3 or rev5.. not many. Parts shortages and people not being able to build them themselves has pretty much squatted everything. The average spend in my store is generally £50-£60 I just do not see many people even buying a fully built up one when it will end up costing more like £200. Atari folks seem a rather poor lot compared to the Amiga guys. I have the same concerns with my SEC booster. The price will be comparable to a fully built ST536. It is one reason I have been working a bit with @Badwolf as a 16MHz booster with alt-ram would be a "stepping stone" low cost accelerator. It fills the gap between my V1 series boosters and a more expensive ST536. You basically get what you pay for.

I assume most people are in the same boat as me where they *need* IDE to make investing in such a product worth-while.I think the product would do very well personally.

I do see the point of IDE making it more attractive. But even if sales double, that is still only 2 people.

Have to look at it from my point as well. I probably spent 100+ hours the past couple of weeks diagnosing another odd DMA related problem (I really should be taking a break from all this still as my hands are still killing me and I started back work last week). People have to invest in its development. If people do not, then why should I ? swings and roundabouts I guess.

But we are really getting way off topic anyway

[agranlund]

I'm sorry if I'm derailing this thread, maybe this should be discussed somewhere else

@agranlund Yours was the last release of TF536r2 for the ST. I am working on rev5 https://www.exxosforum.co.uk/atari/last/TF536/index.htm albeit slowly.

Ah ok, then I suppose I could share the changed one I have in case someone finds it useful?

Incidentally the r2 536 firmware is not compatible with the r5 hardware anymore. This was done deliberately because I am doing other mods to the 536 to work better on the ST. so I did not want people installing the updated firmware on "outdated" hardware, then complaining it does not work properly etc.

That sounds like the best approach indeed

I tried adding cache for ST-RAM but nothing changed ( not saying my code works) but if you are saying MAPROM inhibits caching of ST-RAM then that's probably why.
...
I'm not really convinced CIIN is working properly or as it should do. If I use the physical CDIS jumper, it also works fine. So something is still being cached even though it should be inhibited with CIIN.

Yep exactly. Maprom on Github would be inhibiting cache for the entire ST-Ram region.
It's a bit pants, but CIIN itself can't actually completely disable caching in all situation. It needs the PMMU's help.
Some people have called it a bug, and some people call it a feature.. I don't really take sides in either argument

In a nutshell.. if I understand the documentation correctly (and the wild arguments about this issue on various Amiga forums) :

• CIIN can be used to prevent stuff from ending up in the cache when the CPU reads.

• CIIN does not effect writes from the CPU, so these can put stuff in the cache (depending on cache register settings)

And maybe the most important one:

• If something has somehow ended up in the cache, then CPU reads will get the value from the cache, regardless of what CIIN says.

The only way to completely disable caching for some region is to set up the PMMU specifically for that.
(The proper solution being to have the software cache-aware and flush when necessary, but that ship sailed many years ago for Tos206 )

Not really sure why your score is slightly higher than mine. Though if you are running a patched MAPROM to use ST-RAM cache then it could explain the about 100 frame increase. Though this could really be down to variations in hardware such as the clocks speed tolerances etc. It's difficult to say. If you are able to run GB6 with TOS206 in medium res, then it may give some indications as to what is different.

That seems like such a small difference that it could be anything? Like slight hardware variation or clock speed tolerance like you said?
I'll do some Gembench runs in the settings you suggested


The maprom I'm using right now is not relocating any of the low st-ram to fastram, but it does allow caching of the entire st-ram.
I haven't really tested if having the ram relocation active makes a difference - I figured just having L1 enabled for all st-ram would probably be good enough.
For something like TOS or programs that use a lot of TOS/GEM it's probably a gain to relocate a part of the low st-ram to fastram, but for things that aren't using much of TOS it'll just mean a slightly more expensive MMU table walk for no gain.
Generally speaking I think it's probably worth the cost in normal use. For games.. maybe not so much.
I think the Amiga folks did their low-ram remapping as a few separate tools such as "MuMapZero" and "MuMove4k" instead of how I did it by cramming everything into one thing

[exxos]

Ah ok, then I suppose I could share the changed one I have in case someone finds it useful?

Absolutely, you already had a thread for this in fact..

https://www.exxosforum.co.uk/forum/viewt ... =94&t=3442

I could give the new MAPROM a try...

@Badwolf Has been helping me a lot lately with code because I am a total noob at verlilog. I was using:

Code: Select all

assign STRAM_DECODE = A[29:24] != 6'h0 | ( A[23:20] != 4'h0 & A[23:20] != 4'h1 & A[23:20] != 4'h2 & A[23:20] != 4'h3 );

Note that the rev5 only has 29 address lines, not the normal 31. But I would imagine this would screw up on the lower ram variables, unless this is still patched out in MAPROM anyway.

Yep exactly. Maprom on Github would be inhibiting cache for the entire ST-Ram region.

That probably explains why I don't see any difference.

It's a bit pants, but CIIN itself can't actually completely disable caching in all situation. It needs the PMMU's help.
...
And maybe the most important one:

• If something has somehow ended up in the cache, then CPU reads will get the value from the cache, regardless of what CIIN says.

The only way to completely disable caching for some region is to set up the PMMU specifically for that.
(The proper solution being to have the software cache-aware and flush when necessary, but that ship sailed many years ago for Tos206 )

Indeed, but we do have the sources to fix that problem now... But currently MAPROM seems to solve the problem.

That seems like such a small difference that it could be anything? Like slight hardware variation or clock speed tolerance like you said?
I'll do some Gembench runs in the settings you suggested

If you have caches on ST-RAM then that would explain the increase.

The maprom I'm using right now is not relocating any of the low st-ram to fastram, but it does allow caching of the entire st-ram.
I haven't really tested if having the ram relocation active makes a difference - I figured just having L1 enabled for all st-ram would probably be good enough.

I did have problems with the lower RAM variables.. I did manage to compile a "E" version which turn that feature off. If I remember rightly it simply killed the floppy drive. But some people did not have any issues with it at all.

[agranlund]

I did have problems with the lower RAM variables.. I did manage to compile a "E" version which turn that feature off. If I remember rightly it simply killed the floppy drive. But some people did not have any issues with it at all.

Yeah I'm not surprised. That stuff is a bit hairy.
I tried to be careful about not relocating anything that _has_ to be in ST-RAM but you never know.. I use to have an external floppy drive that I tested with a little bit but that feature should probably be turned off in the name of compatibility.
It's hard to give up the bump in speed though

Anyhow, here's a bunch of Gembenches.
All running under plain Tos206 in medium resolution and no NVDI etc. ROM is relocated to fastram by Maprom.

First, Gembench running from TT-RAM:

ST-RAM L1 enable. Maprom low-ram relo enabled.

l1_tt_relo1.jpg (49.24 KiB) Viewed 2453 times

ST-RAM L1 enable. Maprom low-ram relo disabled.

l1_tt_relo0.jpg (49.35 KiB) Viewed 2453 times

ST-RAM L1 disable. Maprom low-ram relo enable.

tt_relo1.jpg (49.3 KiB) Viewed 2453 times

ST-RAM L1 disable. Maprom low-ram relo disabled.

tt_relo0.jpg (49.44 KiB) Viewed 2453 times

And then, Gembench running from ST-RAM:

ST-RAM L1 enable. Maprom low-ram relo enabled.

l1_st_relo1.jpg (49.29 KiB) Viewed 2453 times

ST-RAM L1 enable. Maprom low-ram relo disabled.

l1_st_relo0.jpg (49.41 KiB) Viewed 2453 times

ST-RAM L1 disable. Maprom low-ram relo enabled.

st_relo1.jpg (49.45 KiB) Viewed 2453 times

ST-RAM L1 disable. Maprom low-ram relo disabled.

st_relo0.jpg (49.49 KiB) Viewed 2453 times

Interestingly, it looks like run from alt-ram, with low-ram relocation enabled, performs slightly better in many of the VDI tests when L1 is disabled for ST-RAM so it's not a clear cut what is best in every possible scenario (unless I got confused when saving the screenshots )
It's tiny cache so its maybe suffering cache misses.

The L1 cache seems to do quite a bit for Gembench when running from ST-RAM.

Me personally, I'll run with L1 enabled for ST-RAM + low-ram relocation from Maprom.
To me that seems like the best all around setting, and the performance boost when running stuff from ST-RAM is way too good to pass up.

Frontbench, TOS206, running from TT-RAM, L1 cache enabled for ST-RAM and low-ram relocation also enabled: 3105
Exactly the same scenario but with low-ram relocation disabled: 3050
(That was with cache globally enabled with the Tos setting of course, and I realise some (most?) people will want to have the cache disabled in Tos206 due to Floppy or an ACSI device that refuse to work etc etc)

[exxos]

Me personally, I'll run with L1 enabled for ST-RAM + low-ram relocation from Maprom.
To me that seems like the best all around setting, and the performance boost when running stuff from ST-RAM is way too good to pass up.

Frontbench, TOS206, running from TT-RAM, L1 cache enabled for ST-RAM and low-ram relocation also enabled: 3105
Exactly the same scenario but with low-ram relocation disabled: 3050
(the difference is so small it's not really worth mentioning)

Nice! it looks like ST_RAM cache enabled is giving about 16% boost is isn't too shabby really. Your scores are basically the same as mine using MAPROM and alt-ram only.

Question is why remapping lower RAM variables has such a huge impact on the score ? odd is doesn't have much impact on frontbench scores though.

Is goes back to what I was saying a few weeks ago when I was confused why I ended up with like 600% scores then like 300% a couple weeks ago. I must of been running the original MAPROM in the first round of tests .

(That was with cache globally enabled with the Tos setting of course, and I realise some (most?) people will want to have the cache disabled in Tos206 due to Floppy or an ACSI device that refuse to work etc etc)

That is what I am currently fighting against with on my machine You can really crank up the speed and run at 50Mhz constant. But something screws up the -38 DMA, but works fine on the IMP DMA I thought just speeding up ST-RAM access would work fine because I assumed that accessing the IO registers too fast was to blame for the DMA issues.. but that does not seem to be the case.. Very bizarre.

[agranlund]

Hard Drivin' with ST-Ram cache:



And without:



I'm surprised how much of a difference that tiny L1 cache makes..

[exxos]

I'm surprised how much of a difference that tiny L1 cache makes..

Impressive indeed!