ST536 STE EDITION

[exxos]

Oh I thought it was just Steve;s one playing up still?

Nope, different board and firmware.. Steve's ran fine all day without fastrom.

I've got my own board on test now...

[exxos]

20250521_202015.jpg

:hide:

8 then :lol:

It will probably crash when I am not watching it... A, bit like 3D printers... And that twin slit experiment where things misbehave were not observed. :lol:

[exxos]

Still going... Its on pass 18 now :hide:

Looking like it's going in for a overnight soaktest....

[exxos]

:yay: :yay: :yay:

IMG_3218.JPG

[Steve]

:yay: :yay: :yay:


IMG_3218.JPG

Woooooooooooooooooooooooooooooooooooooooyah! :D

[exxos]

Blitter now happy with fast-rom stuff...

Current scores..

EMUTOS

IMG_3237.JPG

exxos TOS206 & BLTFIX.

IMG_3236.JPG

Annoying thing is how much of a "hit" TTram takes when running BLTFIX. It wipes out about 121% :shock:

Really TOS206 needs a proper patch for this I think.. but how... now idea.

[exxos]

OK so back to @Badwolf suggestion..

I am trying to setup a register at the 90MB mark...

BUT..

IMG_3238.JPG

:WTF: ive not issued DTACK yet.... and even higher address are acting like RAM... Nothing should be at that mark... unless there some odd decoding error with the TTram logic...


EDIT

Capture.PNG

I'm just going to move it to 256MB :P

[agranlund]

Annoying thing is how much of a "hit" TTram takes when running BLTFIX. It wipes out about 121% :shock:

Strange, since there's no trickery or extra stuff that should be running. Ie; there shouldn't be a global overhead per se. mmu is not used etc.

It hooks itself into blitter related system calls, as well hooking tos's drawing routines which can use the blitter, so these calls will do some extra logic to decide between hardware or software blit -- but I assume none of that is being called during a memory speed benchmark.

The program does flush caches at load time, right before it pexit's as stay-resident, but I wouldn't think that should effect this.

Do you see the same kind of difference when benchmarking memory with nembench, or memspeed?

Really TOS206 needs a proper patch for this I think.. but how... now idea.

That would be nice, but it would do pretty much the same as blitfix, which isn't that much really;
In each of TOS's blitter-enabled gfx functions, determine if it should instead jump to the software routine based on the input parameters (source/dest address)
TOS206 has both hardware and software version of those functions already, and decides which one to use only based on the menu setting.

[exxos]

Do you see the same kind of difference when benchmarking memory with nembench, or memspeed?

WITHOUT BLTFIX

IMG_3239.JPG

WITH BLTFIX

IMG_3240.JPG

[agranlund]

Hmmn, that looks like perhaps cache is not enabling?

It was years since I looked at blitfix but a quick glance at reveals it clears the instruction and data cache on installation. Is it per chance disabling the cache there? Though I'm pretty sure bit 3 and 11 are for clearing the instruction and data caches respectively.

https://github.com/agranlund/tftools/bl ... /blitfix.s
(if that is the version you are using)

Looking through the other bits of code I can't immediately see what else would cause this to happen, but the code is all kinds of horrible and I didn't want to stare at it for too long :)

Update: Could maybe be that TOS is not setting cache on/off per your menu setting (or rather, setting in newdesk.inf) when it starts because you have a blitter - implying that there's no need to run whatever cache init code it has because if you have a blitter then surely it's not a TT anyway.. or something..
It reuses the same menu option as either blitter or cache control for the same reason, there was never a need for both at the same time.

But even so, one would think memspeed etc explicitly enables caches for the L1 test and then disables them for the L2/nocache test.. because that's the only sane approach for a benchmark program, so I really don't know :)