exxos's Atari, Amiga & retro forum

Doing some more tests on @Badwolf's STE with the current ST536 firmware from the other thread..

Get odd results..

H4 with BLITTER.


STE with blitter.


The STE is faster for some reason, but TTram speed is about 50% less..

ST RAM access is 2% slower , maybe thats a clue :shrug: But also int-div is a bit slower. Maybe the CPU spending a bit less time in 50MHz.. But then why would the GEM functions be faster...

EDIT:

Crossed the streems a bit viewtopic.php?p=136535#p136535

Working good at full speed now ACCESS delay was removed !
ACCESS delay didn't slow things down before, but been many tweaks..
Main thing is it doesn't have that odd byte corruption thing going on.

Current state with my test firmware.

Looking awesome! Have you posted the firmware for us to test out?

coonsgm wrote: 13 Nov 2025 18:12 Looking awesome! Have you posted the firmware for us to test out?

Not yet. Still trying to figure out the ST536 problems.

Something's wrong with your integer division figures. 50MHz should be 1.820 seconds whether run from ST or TT ram and there's nothing interrupting or going through bus arbitration.

I don't know if that's intentional, but if not it's probably a hint as to where to look.

BW

Badwolf wrote: 14 Nov 2025 09:44 Something's wrong with your integer division figures. 50MHz should be 1.820 seconds whether run from ST or TT ram and there's nothing interrupting or going through bus arbitration.

Its normal when using BLTFIX. No idea why but its the norm. TTram speed is normally 847%.

exxos wrote: 14 Nov 2025 10:18 Its normal when using BLTFIX. No idea why but its the norm. TTram speed is normally 847%.

Woah, that's weird.

BW

Very weird. Could it be possible your timer is started a bit too early, or stopped a bit too late and so accidentially includes something not strictly related to the test itself (a window redraw slipping in there, or something else general gembench-app related)? Or is that completely out of the question?

Off the top of my head, if we're talking about the same blitfix program, trap #1 and #14 dispatcher themselves would cost a few more cycles since they get one extra layer to go through.
Some of the drawing functions could end up a few more cycles if they need to decide if a blit should be done in hardware or software.
But I'm assuming none of that is, or at least should be, happening in the tests we are talking about.

Is Nembench exhibiting the same phenomenon when you use blitfix?

agranlund wrote: 14 Nov 2025 16:30 Very weird. Could it be possible your timer is started a bit too early, or stopped a bit too late and so accidentially includes something not strictly related to the test itself (a window redraw slipping in there, or something else general gembench-app related)? Or is that completely out of the question?

The start and end and time of tests are done in assembly code. @dml actually wrote those routines. It just gets the current timer tick. It does sync to vbl as well.. But while it's normal to be 1 or 2% out on runs as the timer isn't fast enough, I've never seen a huge speed drop like when BLTfix is used.

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..

Is Nembench exhibiting the same phenomenon when you use blitfix?

I'll check when I get back home.. Have a feeling it was tested before but don't remember the outcome..

EDIT
viewtopic.php?p=128742#p128742

Your conclusion seemes to be

I've got no conclusive ideas what the issue is, only vague guesses