One for 680x0 experts - move16 issues...

there’s a bug in some early versions of the 68040 chip (including some shipped Quadras) that requires you to use a Nop instruction before any set of Move16 instructions. The problem is that if you have a pending write to an address subsequently referenced by a Move16 instruction that executes before the pending write completes you’ll get bogus data. The Nop instruction flushes the instruction pipeline (including the pending write) and eliminates the possibility that the bug will show up. Strictly speaking, I don’t think I need the Nop given the instructions that execute in my code before the first Move16 but I left it in there for instructional purposes and because it might be needed for some other rare set of circumstances on certain batches of 040’s.

from here

Dunno if this is of any use?

[Karlos]

@all

If you have an 040 / 060, you can test this yourself (note you still need an RTG system for this particular test)

There is a version of pixeltest here that tests some of these operations on VRAM and asks if you see any glitches in the pixels.

Note that there is one test, just before the 'shufflecopy' test that times a byteswap accelerated with move16. The output pixels will naturally look screwy after byteswapping - appearing as a strange patchwork pattern. This is not a glitch.

The glitches are the occasional flickering short spans of duff pixels you might see as some of the copy and set tests are performed.

Does anybody else see them, or is it just my one system (it works fine on another 040 here).

[Framiga]

none here . . . i have CMQ060Move16 installed.

Do you want the output?

CVPPC 1024x768 16bit CGX 4.3 68060

[patrik]

@Framiga:

Just post it here so we all can see :=).


/Patrik

[Framiga]

10/0.AmigaOS:> "Ram Disk:pixeltest"
Surface width: 640, height: 480, modulus: 0

Surface hwWidth: 640, hwHeight: 480
Test data pixel format

Bytes   : 2, endian native
Bits    : A[  0] R[  5] G[  6] B[  5]
Offsets : A[  0] R[ 11] G[  5] B[  0]
Maxima  : A[  0] R[ 31] G[ 63] B[ 31]

Window pixel format

Bytes   : 2, endian native
Bits    : A[  0] R[  5] G[  6] B[  5]
Offsets : A[  0] R[ 11] G[  5] B[  0]
Maxima  : A[  0] R[ 31] G[ 63] B[ 31]

Results (negative value indicates glitches were observed

Read RAM      : 58624.13 K/sec
Write RAM     : 45418.33 K/sec
Write RAM(C)  : 33136.09 K/sec
Write RAM(16) : 36941.41 K/sec
RAM->RAM      : 27755.91 K/sec
RAM->RAM(C)   : 15264.19 K/sec
RAM->RAM(OS)  : 33201.58 K/sec
RAM->RAM(16)  : 32738.10 K/sec

-------------------------------

Read VRAM     : 6094.18 K/sec
Write VRAM    : 23460.41 K/sec
Write VRAM(C) : 5813.95 K/sec
Write VRAM(16): 16617.21 K/sec
RAM->VRAM     : 16568.05 K/sec
RAM->VRAM(C)  : 5273.44 K/sec
RAM->VRAM(OS) : 15774.65 K/sec
RAM->VRAM(16) : 16000.00 K/sec
RAM->VRAM(SC0): 12903.23 K/sec
RAM->VRAM(SC2): 11952.15 K/sec
RAM->VRAM(SC4): 12928.42 K/sec
RAM->VRAM(SC6): 11834.20 K/sec
RAM->VRAM(SC8): 12877.88 K/sec
RAM->VRAM(swp): 11583.01 K/sec

-------------------------------

VRAM->RAM     : 5157.59 K/sec
VRAM->RAM(16) : 5853.66 K/sec

-------------------------------

Conversion    : 16617.21 K/sec [output bandwidth]
Conversion    : 8508011.87 pix/sec

Conversion attained  100.30% copy speed

[Karlos]

@framiga

Only the OS copy test should be affected by your CMQ060 patch.

So you didn't see any glitched pixels during the various write/copy tests I take it.

@patrik

That looks like another system that prefers not to use move16 to VRAM, eh?

-edit-

Read RAM : 58624.13 K/sec
Write RAM : 45418.33 K/sec
Write RAM(C) : 33136.09 K/sec
Write RAM(16) : 36941.41 K/sec

That's interesting. The version you are running us using the last version of the asm I posted. I guess resetting the cache line with the four move.l is killing it. Or something :lol:

[Karlos]

@Piru

Hmm.

Maybe it is a hardware bug after all. I tried again with Forbid() just now and still observed glitching in some copy tests.

I also allocated enough space so that there would be at least one cache line before and after my test area. Same weirdness.

[itix]

@mdma

Found this from the article:

there’s a bug in some early versions of the 68040 chip (including some shipped Quadras) that requires you to use a Nop instruction before any set of Move16 instructions. The problem is that if you have a pending write to an address subsequently referenced by a Move16 instruction that executes before the pending write completes you’ll get bogus data.

[itix]

Heh. After reading that article I feel MacOS classic is piece of {bleep} :-D

itix wrote:
Heh. After reading that article I feel MacOS classic is piece of {bleep} :-D

Hehe, some might say MacOS X is too! ;-)

[Karlos]

@mdma

I have to use OS X and OSX Server at work on a daily basis. I can quite assure anybody reading, both are way overhyped. That is not to say they are bad but once you get past the eyecandy, they really are nothing exceptional.

[Karlos]

@all with 040/060 + RTG

Could you please test this version of pixeltest?

This version reinstates my origial move16 code (the 4x unrolled one) and the timing measurement should also be a fair bit more accurate. It also supports a new CLI argument, 'lock' which will hold off task switching during iterations.

I am just curious to see if the original move16 code I wrote will outperform the move.l based write as the previous one did not (not too surprising considering it kept re-updating the cache line in a vain attempt to beat the glitch).

[Framiga]

8/0.AmigaOS:> "Ram Disk:pixeltest/pixeltest" lock
Surface width: 640, height: 480, modulus: 0

Surface hwWidth: 640, hwHeight: 480
Test data pixel format

Bytes   : 2, endian native
Bits    : A[  0] R[  5] G[  6] B[  5]
Offsets : A[  0] R[ 11] G[  5] B[  0]
Maxima  : A[  0] R[ 31] G[ 63] B[ 31]

Window pixel format

Bytes   : 2, endian native
Bits    : A[  0] R[  5] G[  6] B[  5]
Offsets : A[  0] R[ 11] G[  5] B[  0]
Maxima  : A[  0] R[ 31] G[ 63] B[ 31]


Locking enabled. No task switches or interrupts during iterations.

68040/060 detected. MOVE16 based tests will be performed.
Results (negative value indicates glitches were observed

Read RAM      : 57380.75 K/sec
Write RAM     : 45855.11 K/sec
Write RAM(C)  : 33108.27 K/sec
Write RAM(16) : 52591.97 K/sec
RAM->RAM      : 27757.65 K/sec
RAM->RAM(C)   : 15544.19 K/sec
RAM->RAM(OS)  : 32728.97 K/sec
RAM->RAM(16)  : 32656.29 K/sec

-------------------------------

Read VRAM     : 6408.90 K/sec
Write VRAM    : 23131.52 K/sec
Write VRAM(C) : 6307.71 K/sec
Write VRAM(16): 19469.71 K/sec
RAM->VRAM     : 16668.71 K/sec
RAM->VRAM(C)  : 6022.64 K/sec
RAM->VRAM(OS) : 15999.47 K/sec
RAM->VRAM(16) : 15976.67 K/sec
RAM->VRAM(SC0): 12945.05 K/sec
RAM->VRAM(SC2): 11964.15 K/sec
RAM->VRAM(SC4): 12944.53 K/sec
RAM->VRAM(SC6): 11968.74 K/sec
RAM->VRAM(SC8): 12936.73 K/sec

-------------------------------

VRAM->RAM     : 5970.79 K/sec
VRAM->RAM(16) : 6512.34 K/sec

-------------------------------

Conversion    : 16668.29 K/sec [output bandwidth]
Conversion    : 8534163.20 pix/sec

Conversion attained  100.00% copy speed

[Karlos]

So can anybody shed any light on why the BPPC/BVision seems to support burst access to VRAM but the CSPPC/CVision does not?

I am inferring this only from the fact that my system (and one or two others) are faster when writing to VRAM with move16, but all the CSPPCs seem slower.

[patrik]

CyberStormPPC(060@50MHz) + CyberVisionPPC:
Surface width: 640, height: 480, modulus: 0

Surface hwWidth: 640, hwHeight: 480
Test data pixel format

Bytes   : 2, endian native
Bits    : A[  0] R[  5] G[  6] B[  5]
Offsets : A[  0] R[ 11] G[  5] B[  0]
Maxima  : A[  0] R[ 31] G[ 63] B[ 31]

Window pixel format

Bytes   : 2, endian native
Bits    : A[  0] R[  5] G[  6] B[  5]
Offsets : A[  0] R[ 11] G[  5] B[  0]
Maxima  : A[  0] R[ 31] G[ 63] B[ 31]


Locking enabled. No task switches or interrupts during iterations.

68040/060 detected. MOVE16 based tests will be performed.
Results (negative value indicates glitches were observed

Read RAM      : 47892.42 K/sec
Write RAM     : 38258.97 K/sec
Write RAM(C)  : 27613.75 K/sec
Write RAM(16) : 43855.58 K/sec
RAM->RAM      : 23149.21 K/sec
RAM->RAM(C)   : 12955.79 K/sec
RAM->RAM(OS)  : 21271.21 K/sec
RAM->RAM(16)  : 27232.07 K/sec

-------------------------------

Read VRAM     : 6197.98 K/sec
Write VRAM    : 19459.75 K/sec
Write VRAM(C) : 5740.48 K/sec
Write VRAM(16): 16227.62 K/sec
RAM->VRAM     : 13894.56 K/sec
RAM->VRAM(C)  : 6426.90 K/sec
RAM->VRAM(OS) : 13680.40 K/sec
RAM->VRAM(16) : 13320.74 K/sec
RAM->VRAM(SC0): 10787.77 K/sec
RAM->VRAM(SC2): 9974.31 K/sec
RAM->VRAM(SC4): 10787.71 K/sec
RAM->VRAM(SC6): 9976.13 K/sec
RAM->VRAM(SC8): 10782.86 K/sec

-------------------------------

VRAM->RAM     : 6448.74 K/sec
VRAM->RAM(16) : 6507.22 K/sec

-------------------------------

Conversion    : 13894.99 K/sec [output bandwidth]
Conversion    : 7114236.87 pix/sec

Conversion attained  100.00% copy speed


/Patrik

[Framiga]

forgot to mention . . .mine is a

68060 @ 60 Mhz (ram settings>60ns)

CVPPC @ 92 Mhz (Permedia active cooled)

My CSPPC its a very early 604e 150 Mhz OC at 200 Mhz. (the model with NO RAM Precharge settings enabled)

EDIT- and remember that there are 2 different models of CVPPC, that uses different VRAM chips.