ST536 STE EDITION

[agranlund]

I know we talked about this a few months back. Running BLTfix from TTram helps..even so, it's very odd it changes int-div test speed. Like you say, either the start or end time is changed somehow or the int-div test is interrupted somehow which I don't thinks possible.. So no idea..

Very odd.
Couldn't see anything super obvious by looking at that very old code here.
https://github.com/agranlund/tftools/bl ... /blitfix.s

Trap1, Trap14 and the Blit related calls would get a bit extra overhead
And TOS itself may or may not be doing cache-invalidate after hardware blit operations (?)

But I wouldn't think any of the above should be stuff that runs during a cpu/mem benchmark.
So perhaps then, I probably missed something when looking at the blitfix code.

[exxos]

But I wouldn't think any of the above should be stuff that runs during a cpu/mem benchmark.
So perhaps then, I probably missed something when looking at the blitfix code.

No clue.. Could be some cache issue but would assume it wouldn't effect intdiv test anyway.. But looking before at the results something does upset ram speed at some point.

I suppose I could look at the clock during int div test to see if it down clocks back to 8mhz but not even sure that's possible.

Oddly it doesn't have the slowdown when first used without blitter enabled. When blitter is enabled the scores drop.. But IIRC turning the blitter off again doesn't make the scores back up to the inital run.

[agranlund]

Oddly it doesn't have the slowdown when first used without blitter enabled. When blitter is enabled the scores drop.. But IIRC turning the blitter off again doesn't make the scores back up to the inital run.

This is a mystery so interesting it's hard to resist trying to think of what it could be

Lucky me I don't have hardware to reproduce it, else that would have been my weekend gone for sure
(or at least not set up. I'm half-guessing I would perhaps see the same result on my ST with blitter then)

[exxos]

This is a mystery so interesting it's hard to resist trying to think of what it could be

I don't think there is any way to slow int-div down. I mean the CPU is onlt internal running that test. Is the MMU involved with BLTFIX ?

TOS and BLTFIX are running in TTRAM , its not like it has to slow down to access STram in the middle of int-div tests.

Lucky me I don't have hardware to reproduce it, else that would have been my weekend gone for sure
(or at least not set up. I'm half-guessing I would perhaps see the same result on my ST with blitter then)

Not sure I tried BLTFIX on a stock machine.. maybe someone can see if they can replicate over the weekend on a STE or ST with blitter..

I assume the issue would only show up when BLTFIX kicks in when something needs to blit in TTram range..

Does BLTFIX install something *only* when the blitter is on and first access for a blit ? Its like something installs, but doesn't "uninstall" when the blitter is disabled.

[agranlund]

I don't think there is any way to slow int-div down. I mean the CPU is onlt internal running that test. Is the MMU involved with BLTFIX ?
TOS and BLTFIX are running in TTRAM , its not like it has to slow down to access STram in the middle of int-div tests.

Nope, there is no mmu involved.

It intercepts a couple of traps so they would be a couple of instructions longer.

Since TOS 2.x supports both with or without blitter it already has an internal jumptable for the blitter-related functions.
Blitfix remapes this jumptable so that the hardware version can dynamically decide if a blit is possible (depending on source/dest address). If either of those addresses are TT-RAM then it'll jump to the software version instead.

And that should be about it.

(what TOS2 code does differently inside its hardware versions compared to its software dito, I do not know)

Not sure I tried BLTFIX on a stock machine.. maybe someone can see if they can replicate over the weekend on a STE or ST with blitter..

I never tried the program on a stock machine as the program only really makes sense on a machine with TT-RAM, to fix issues related to those setups.
Only on my ST with Blitter expansion + TF536.

[Badwolf]

This is a mystery so interesting it's hard to resist trying to think of what it could be

I'm completely at a loss. the 1.820 seconds for a 50MHz 030 on Integer Division is so hard-wired into my brain from DFB1 and STE536 that any departure from it sounds alarm bells to me.

Of all the jiggery pokery I've done with firmwares, motherboards and software (including OSs) it's always been 1.820 seconds. What's a TSR doing that changing the OS between 2.06, EmuTOS and 4.04 isn't?

BW

[exxos]

@Badwolf you would have to try the falcon in 8MHz mode with TTram for a closer comparison to the ST.

[exxos]

Looks like a cache issue as intdiv shows no difference with BLTFIX or not when caches are off. Seems like a smoking gun to me.

20251124_185348.jpg (264.66 KiB) Viewed 118 times

20251124_190816.jpg (241.25 KiB) Viewed 112 times

Someone with something like a TT with TOS306 would need to try..

[agranlund]

Does BLTFIX install something *only* when the blitter is on and first access for a blit ? Its like something installs, but doesn't "uninstall" when the blitter is disabled.

Not really, the trap overrides are installed right away.
The program doesn't do all that much complicated stuff:
Unless I'm missing something obvious, it just installs the new blitfuncs jumptable, and the trap overrides.

Trap14:BlitMode()

TOS2.x
* with positive value, for setting blitmode, jumps to original TOS function without modification.
* with negative value, for getting blitmode, jumps to original TOS function without modification,
(except when being asked by NVDI or WARP9 during autofolder execution. For these two we reply that there is no blitter)

EmuTOS
* with positive value, for setting blitmode, ignores command as if blitter not present
* with negative value, for getting blitmode:
-if calling program is in ROM, TT-RAM, or in ST-RAM lower than the TSR itself, we report no blitter present
-if calling program is in ST-RAM, higher than the TSR, report the truth if blitter exists or not
(as opposed to lying and always reporting no-blitter, which is what EmuTOS does when you have TT-RAM)

Trap14:Setscreen()

(all TOS's)
* update TOS's hw blitfunc jumptable depending on if new logical screen is in ST or TT ram
* then jump to original TOS Setscreen()


I assume you're building TOS206 with the P68030 patch? If so, TOS clears the cache after each hardware blit operation.
But then, I wouldn't expect that to make a difference on a benchmark program, unless there's a bug and it disables the cache instead of clearing it. or something like that.
Do you get expected benchmark result if you run with blitter enabled, but without using blitfix?

Could it be related to TOS2's shared menu entry and variable for cache/blitter, or the related code which applies it from newdesk.inf?
I recall you patched TOS to have both at the same time, is it possible there can be some issue lurking there which shuts off the cache when you (or newdesk.inf) enable blitter?
Could also give xcontrol and general.cpx a go and see if using that instead of the desktop menu makes a difference.
That cpx allows you to set cache and blitter individually.

[exxos]

@agranlund

This is without BLTFIX.. Odd since some scores now seem a bit higher.. But point being intdiv is still low without BLTFIX running..

I am using the 030 CPU as the target CPU. Mostly just adds the cache stuff AFAIK..

GB6 sets the caches ON when it boots up. So whatever the newdesk. inf has wouldn't matter anyway.

So it could well be a bug in TOS cache control somewhere. It's why I mentioned the TT as it would use TOS306.. but I don't even know if the TT has a blitter...

My only thought is to check TOS to see if there's a bug.. Or patch GB6 to report cache state in realtime. Probably be simpler if I run SI. CPX as I assume it reports cache status when opended. And run each GB6 test one by one and check the cache in the cpx after each test.

My thought is the cache is turned off during a blit and never turned back on again.. I guess BLTFIX is of the hook now

20251125_001410.jpg (231.5 KiB) Viewed 76 times

EDIT:

I quickly looked though the source code for TOS and only see it changing bit 3 and 11.......

Capture.PNG (215.91 KiB) Viewed 51 times