ST536 STE EDITION

[exxos]

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

Get odd results..

H4 with BLITTER.

IMG_4023.JPG (289.93 KiB) Viewed 219 times

STE with blitter.

IMG_4024.JPG (344.71 KiB) Viewed 219 times

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

ST RAM access is 2% slower , maybe thats a clue 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

[exxos]

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.

IMG_4026.JPG (278.64 KiB) Viewed 211 times

[exxos]

Current state with my test firmware.

IMG_4028.JPG (344.72 KiB) Viewed 197 times

IMG_4027.JPG (294.99 KiB) Viewed 197 times

[coonsgm]

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

[exxos]

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

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

[Badwolf]

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

[exxos]

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

[Badwolf]

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

Woah, that's weird.

BW

[agranlund]

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?

[exxos]

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