Copper timing

[Toni Wilen]

If you still want timing tests, please list all required lines and which test program to use. (I think I already have all the info I need to fix UAE copper)

btw, copper start (hpos=0,vpos=0) seems to need one extra cycle before first instruction fetch. (probably same as step 4 in copjmp-test?)

[yaqube]

I would like to see lines $42, $44, $46 and $48 from my copjmp from the post #11.

Thanks for the info about copper start, in my current implementation I have used two cycle delay but will change it to one as you suggest.

I have already implemented discovered "features" in the copper in my Minimig. The results of test programs are identical to those run on my A4k. I hope to see them working the same under UAE

[Toni Wilen]

Originally Posted by yaqube

I would like to see lines $42, $44, $46 and $48 from my copjmp from the post #11.

Attached

Thanks for the info about copper start, in my current implementation I have used two cycle delay but will change it to one as you suggest.

I think it may be two cycles after all. If first refresh slot (STRHOR slot) is cycle 1, not 0. (it seems to be 1 but I am more software than hardware guy )

I have already implemented discovered "features" in the copper in my Minimig. The results of test programs are identical to those run on my A4k. I hope to see them working the same under UAE

Your first copper test (EDIT: and copjmp too) program works now correctly but for some reason copper c2p zoomer in B2 by Lazy Bones still looks exact same.. (=wrong)

[Toni Wilen]

EDIT: I think I found the problem, it is ancient ancient problem that makes copper's "bitplane dma in use" check two cycles too early..


B2 partial copper list, nothing special really:

 00066bf0: 4ad3 fffe            ; Wait for vpos >= 0x4a and hpos >= 0xd2. (works if 0xd0 instead of 0xd2)
                                ; VP 4a, VE 7f; HP d2, HE fe; BFD 1
 00066bf4: 0182 0988            ; COLOR01 := 0x0988
 00066bf8: 0184 0652            ; COLOR02 := 0x0652
 00066bfc: 0186 0862            ; COLOR03 := 0x0862
 00066c00: 0188 0c96            ; COLOR04 := 0x0c96
 00066c04: 018a 0971            ; COLOR05 := 0x0971
 00066c08: 018c 0684            ; COLOR06 := 0x0684
 00066c0c: 018e 0574            ; COLOR07 := 0x0574
 00066c10: 0190 06a5            ; COLOR08 := 0x06a5
 00066c14: 0192 0597            ; COLOR09 := 0x0597
 00066c18: 0194 0898            ; COLOR10 := 0x0898
 00066c1c: 0196 0788            ; COLOR11 := 0x0788
 00066c20: 0198 013e            ; COLOR12 := 0x013e
 00066c24: 019a 0444            ; COLOR13 := 0x0444
 00066c28: 019c 013e            ; COLOR14 := 0x013e
 00066c2c: 019e 013e            ; COLOR15 := 0x013e
 00066c30: 01a2 013e            ; COLOR17 := 0x013e
 00066c34: 01a4 013e            ; COLOR18 := 0x013e
 00066c38: 01a6 013e            ; COLOR19 := 0x013e
 00066c3c: 01aa 013e            ; COLOR21 := 0x013e
 00066c40: 01ac 013e            ; COLOR22 := 0x013e
 00066c44: 01ae 013e            ; COLOR23 := 0x013e
 00066c48: 01b2 0369            ; COLOR25 := 0x0369
 00066c4c: 01b4 0abf            ; COLOR26 := 0x0abf
 00066c50: 01b6 013e            ; COLOR27 := 0x013e
 00066c54: 01ba 013e            ; COLOR29 := 0x013e
 00066c58: 01bc 013e            ; COLOR30 := 0x013e
 00066c5c: 01be 013e            ; COLOR31 := 0x013e
 00066c60: 0180 0873            ; COLOR00 := 0x0873
 00066c64: 0180 0862            ; COLOR00 := 0x0862
 00066c68: 0180 0b94            ; COLOR00 := 0x0b94
 00066c6c: 0180 0971            ; COLOR00 := 0x0971
 00066c70: 0180 0992            ; COLOR00 := 0x0992
 00066c74: 0180 0574            ; COLOR00 := 0x0574
 00066c78: 0180 0585            ; COLOR00 := 0x0585
 00066c7c: 0180 0597            ; COLOR00 := 0x0597
 00066c80: 0180 0786            ; COLOR00 := 0x0786
 00066c84: 0180 0788            ; COLOR00 := 0x0788
 00066c88: 0180 013e            ; COLOR00 := 0x013e
 00066c8c: 0180 0444            ; COLOR00 := 0x0444
 00066c90: 0180 0698            ; COLOR00 := 0x0698
 00066c94: 0180 013e            ; COLOR00 := 0x013e
 00066c98: 0180 0655            ; COLOR00 := 0x0655
 00066c9c: 0180 013e            ; COLOR00 := 0x013e
 00066ca0: 0180 013e            ; COLOR00 := 0x013e
 00066ca4: 0180 013e            ; COLOR00 := 0x013e
 00066ca8: 0180 013e            ; COLOR00 := 0x013e
 00066cac: 0180 013e            ; COLOR00 := 0x013e
 00066cb0: 0180 002a            ; COLOR00 := 0x002a
 00066cb4: 0180 077f            ; COLOR00 := 0x077f
 00066cb8: 0180 013e            ; COLOR00 := 0x013e
 00066cbc: 0180 013e            ; COLOR00 := 0x013e
 00066cc0: 0180 013e            ; COLOR00 := 0x013e
 00066cc4: 0180 013e            ; COLOR00 := 0x013e
 00066cc8: 0180 0000            ; COLOR00 := 0x0000
 00066ccc: 4be1 fffe            ; Wait for vpos >= 0x4b and hpos >= 0xe0.
                                ; VP 4b, VE 7f; HP e0, HE fe; BFD 1
 00066cd0: 0086 6cd4            ; COP2LCL := 0x6cd4
 
 00066cd4: 4c5b 80fe            ; Wait for  hpos >= 0x5a.
                                ; VP 4c, VE 00; HP 5a, HE fe; BFD 1
 00066cd8: 0180 0873            ; COLOR00 := 0x0873
 00066cdc: 0180 0862            ; COLOR00 := 0x0862
 00066ce0: 0180 0b94            ; COLOR00 := 0x0b94
 00066ce4: 0180 0971            ; COLOR00 := 0x0971
 00066ce8: 0180 0992            ; COLOR00 := 0x0992
 00066cec: 0180 0574            ; COLOR00 := 0x0574
 00066cf0: 0180 0585            ; COLOR00 := 0x0585
 00066cf4: 0180 0597            ; COLOR00 := 0x0597
 00066cf8: 0180 0786            ; COLOR00 := 0x0786
 00066cfc: 0180 0788            ; COLOR00 := 0x0788
 00066d00: 0180 013e            ; COLOR00 := 0x013e
 00066d04: 0180 0444            ; COLOR00 := 0x0444
 00066d08: 0180 0698            ; COLOR00 := 0x0698
 00066d0c: 0180 013e            ; COLOR00 := 0x013e
 00066d10: 0180 0655            ; COLOR00 := 0x0655
 00066d14: 0180 013e            ; COLOR00 := 0x013e
 00066d18: 0180 013e            ; COLOR00 := 0x013e
 00066d1c: 0180 013e            ; COLOR00 := 0x013e
 00066d20: 0180 013e            ; COLOR00 := 0x013e
 00066d24: 0180 013e            ; COLOR00 := 0x013e
 00066d28: 0180 002a            ; COLOR00 := 0x002a
 00066d2c: 0180 077f            ; COLOR00 := 0x077f
 00066d30: 0180 013e            ; COLOR00 := 0x013e
 00066d34: 0180 013e            ; COLOR00 := 0x013e
 00066d38: 0180 013e            ; COLOR00 := 0x013e
 00066d3c: 0180 013e            ; COLOR00 := 0x013e
 00066d40: 0180 0000            ; COLOR00 := 0x0000
 00066d44: 4ce1 80fe            ; Wait for  hpos >= 0xe0.
                                ; VP 4c, VE 00; HP e0, HE fe; BFD 1
 00066d48: 4e01 ffff            ; Skip if vpos >= 0x4e and hpos >= 0x00.
                                ; VP 4e, VE 7f; HP 00, HE fe; BFD 1
 00066d4c: 008a 4359            ; COPJMP2 := 0x4359
 
 00066d50: 4e5b fffe            ; Wait for vpos >= 0x4e and hpos >= 0x5a.
                                ; VP 4e, VE 7f; HP 5a, HE fe; BFD 1

(either commented "fix" fixes the problem, not both) I guess this must have something to do with skip or copjmp..

[Toni Wilen]

I am getting really confused now..

Attached is two images, 000-024 shows lines from 0 (and before) to 24. (ddfstrt=0x18,4 plane hires). First write to 0x116 "should" be cycle 24 but that makes refresh 0x3c cycle "-1" = 226.

This does not make sense because very first line after reset shows all 4 refresh slots (trigger = when reset line goes inactive) = first refresh slot can't be 226..

Other attachment shows lines 200 to 225+. (again, hires, 4 planes, ddfstop=0xc0 = last bitplane cycle should be 192+8-1 = 199) Again they don't match unless first refresh cycle is "-1".

I guess this has something to do with sentence in HRM that always confused me: "This cycle 0 appears to exclude one of the memory refresh cycles. This is not the case. Actual system hardware demands certain specific values for data fetch start and display start. Therefore this timing chart has been 'adjusted' to match those requirements".

"certain specific values"..

copper test program shows the problem, last test line, third line should be slightly longer than other 3 lines. Because of this 2 cycle error, it is the black line that becomes longer instead. (note that current winuae does not render last 2 lines due to other problem)

[yaqube]

Thanks Toni. I will take a look very soon.

I can't get B2 demo to work either on my Minimig or under WinUAE. Any specific config is required?

[Toni Wilen]

B2 shouldn't need anything special (except vector part never ends if cycle-exact is enabled in winuae..)

Attached copper test source that confuses me
(ignore the interrupt setup, it is not used in this test)

[Toni Wilen]

(too quiet here, this can't be so difficult?)

Anyway, I ordered more probes today

[Toni Wilen]

Probes arrived today.

And immediately I found interesting new undocumented feature.

I wrote test program that uses copper to "write" to DFF006 continuously (because it is read-only, you will see contents of the register in databus)

hpos counter does weird things, it increases normally but when it wraps around to next line, hpos=0 still shows previous vpos! hpos=1 shows increased vpos as expected. (this is similar to CIA TOD bug, is there some chip-design reason for this?)

CPU can also see this but it is very difficult to get proper timing.

EDIT: this also proves there is something more than just horizontal position counter (dff006) because it does not match with ddfstrt and ddfstop. Perhaps there is another hidden counter inside the chipset or something like that. Single horizontal counter does not make sense anymore.

[Toni Wilen]

(perhaps someone is still interested in reading this research..)

I think I have explanation for mismatched hpos and ddfstrt/stop positions. They aren't mismatched!

HRM is hiding some details, again..

HPOS has 5 cycle (about, perhaps it is 4, not sure yet or even 4.5) offset compared to diagrams in HRM. (0 in HRM = 5 in reality etc..)

Then there is that "mysterious" 4.5 cycle delay before bitplane data is visible on screen.

Interesting, isn't it..

I think everyone thought (me including) that the delay happens AFTER bitplane data has been fetched (for example Denise doing something internally before outputting data).

In reality delay happens BEFORE first bitplane fetch. (DDFSTRT triggers, "mysterious" delay, fetches start normally)

Previous copper timings match if this is true.

[HenryCase]

Originally Posted by Toni Wilen

(perhaps someone is still interested in reading this research..)

I'm still checking this thread frequently for updates, it is interesting to see the progress being made, though I don't pretend to understand it all.

Hope yaqube is still reading too.

Thanks for your work on this Toni and yaqube.

[BippyM]

I find all this interesting, if a little complicated!

[killergorilla]

I always end up reading this threads, although I have absolutely no clue what it's all about

No idea why

[gimbal]

I have little clue either (mostly because I have little knowledge of the inner workings of the Amiga... I thought it was done with magic. The pc is so simple in comparison), but it interests me to no end. I am perplexed by how it is all discovered. Truly inspiring.

[FrenchShark]

Originally Posted by Toni Wilen

(perhaps someone is still interested in reading this research..)

I think I have explanation for mismatched hpos and ddfstrt/stop positions. They aren't mismatched!

HRM is hiding some details, again..

HPOS has 5 cycle (about, perhaps it is 4, not sure yet or even 4.5) offset compared to diagrams in HRM. (0 in HRM = 5 in reality etc..)

Then there is that "mysterious" 4.5 cycle delay before bitplane data is visible on screen.

Interesting, isn't it..

I think everyone thought (me including) that the delay happens AFTER bitplane data has been fetched (for example Denise doing something internally before outputting data).

In reality delay happens BEFORE first bitplane fetch. (DDFSTRT triggers, "mysterious" delay, fetches start normally)

Previous copper timings match if this is true.

I think I have the explanation about the mysterious 4.5 cycles delay.
The HW needs to have all the plane data buffers loaded with valid data before outputting a new chunk of 16 pixels (this is the 4 cycle delay).
IMHO, the 0.5 cycle delay is for the NTSC output : remember the NTSC line is 227.5 cycle long but the Amiga HW alternates 227 and 228 cycle lines so a 0.5 delay has to be added in the video pipeline every other line to correct the 0.5 cycle jitter introduced by the DMA.
Does it make sense ?

I have a question concerning the even/odd cycles : since the lines are 227-cycle long or 228-cycle long, how does the odd/even numbering re-start after a 227-cycle line ?

Regards,

Frederic

[Toni Wilen]

Originally Posted by FrenchShark

I think I have the explanation about the mysterious 4.5 cycles delay.
The HW needs to have all the plane data buffers loaded with valid data before outputting a new chunk of 16 pixels (this is the 4 cycle delay).

I don't think so..

This would mean 8 cycle delay in lores or 2 cycle in superhires.. (ECS only, AGA would cause even more interesting delays..)

This "delay" is already emulated because bitplane emulation is cycle-exact, nothing can be output until all planes have been fetched (=BPLT1DAT is written to)

(and even HRM has little diagram inside cycle diagram that shows the delay, "all planes need to be fetched" + "mysterious delay")

ADDED:

This should be easy to confirm by checking any Denise digital output pin state, will test soon

[Toni Wilen]

Originally Posted by Toni Wilen

This should be easy to confirm by checking any Denise digital output pin state, will test soon

Tested and I didn't expect this..

There _IS_ delay between write to BPL1DAT and Denise output changing state but it is only ~2 cycles, not 4.. (FF55 = plane 0 bit pattern, other planes are filled with zeros. Last line is Denise Red high bit, colors selected so that any plane set = red high bit is set)

This is getting more and more confusing..

[BippyM]

I'm glad you're enjoying the joys of Amiga still Toni

[FrenchShark]

Originally Posted by Toni Wilen

Tested and I didn't expect this..

There _IS_ delay between write to BPL1DAT and Denise output changing state but it is only ~2 cycles, not 4.. (FF55 = plane 0 bit pattern, other planes are filled with zeros. Last line is Denise Red high bit, colors selected so that any plane set = red high bit is set)

This is getting more and more confusing..

Well, you are measuring the denise's video pipeline delay
It takes some time for denise to do the CLUT access and the plane/sprite priority logic.

I even bet that the denise's pipeline delay is 2 cycles for one line and 2.5 cycles for the next line when you are in NTSC.

HSYNC and VSYNC are certainly delayed by the same amount of cycles.

According to the HRM, the "magic" delay is 4.5 cycle for hi-res and 8.5 for lo-res so the 4 and 8 cycles ARE the fetch delays not denise's video pipeline delay.

It's funny, because we had the same kind of discussion in this thread:
http://eab.abime.net/showthread.php?t=33892

Regards,

Frederic

EDIT : I read this thread (again). Toni said that he is confused by the delay on HPOS : the explanation is really simple : it just takes some time to output the content of HPOS on the data bus (apparently 4 cycles), it is called latency. IMHO the copper is mainly responsible of this. It would be interesting to do the same test with the 68000, the latency might be different.
To sum up : you see the value of HPOS "4 cycles ago".

[Toni Wilen]

Originally Posted by FrenchShark

Well, you are measuring the denise's video pipeline delay
It takes some time for denise to do the CLUT access and the plane/sprite priority logic.

I even bet that the denise's pipeline delay is 2 cycles for one line and 2.5 cycles for the next line when you are in NTSC.

Yeah, of course, so there is no mysterious Denise delay after all, my theory can still work if delay is before first dma fetch starts. (mysterious delay is still documented in HRM and same delay is needed in emulation, 9 hires pixels)

According to the HRM, the "magic" delay is 4.5 cycle for hi-res and 8.5 for lo-res so the 4 and 8 cycles ARE the fetch delays not denise's video pipeline delay.

Yes but there is another delay "documented" in blitter chapter where the big cycle diagram is shown.

EDIT : I read this thread (again). Toni said that he is confused by the delay on HPOS : the explanation is really simple : it just takes some time to output the content of HPOS on the data bus (apparently 4 cycles), it is called latency. IMHO the copper is mainly responsible of this. It would be interesting to do the same test with the 68000, the latency might be different.
To sum up : you see the value of HPOS "4 cycles ago".

This can't be true, how can it buffer 4 cycles worth of data when every cycle can be used by dma? I don't think all custom chips have 4 word fifo

I already tested with CPU (didn't bother to include images) and results are identical. (same value returned relative to other dma fetch)

This is the bus data that connects agnus,denise and paula. CPU data bus connects to this bus via latches.

There must be some simple explanation (hardware is always "optimized" but optimization used can be quite weird..)

hpos counter "bug" probably explains why copper has one cycle that it can't use, it must be this exact cycle