Copper timing

[yaqube]

Hello,

I'm trying to adapt Minimig's copper to behave like Amiga's one. The current solution written by Dennis is based on AHRM description and it's not perfect.

I've done some tests on my A4k and WinUAE 1.5.0 to figure out the actual behaviour. But by chance I've found difference in UAE's and AGA's copper operation. The attached pictures show the results of the same program run on A4k and under WinUAE 1.5.0. The difference is noticeable when using 6 bitplanes in low resolution or 3 bitplanes in high resolution (I believe the difference is also present when using 5 bitplanes but my tests don't cover this case, they should use different alligment between wait and bitplane dma fetch cycles). It seems that WAIT and SKIP require 4 FREE even cycles. I only tested WAIT's which had been already true.

Can somebody confirm this? What happens on the bus during these two additional cycles?

Also there is a question for which I don't know the answer yet: in which cycle does the actual comparision take place?

The description of copper MOVE's in WinUAE's sources are not understable by me . It's been written that these MOVE's require 3 or 4 cycles (depending if they move data to Agnus or other chip) but from my tests I can see that changing background colour (moves to Denise) takes 8 lores pixels (if all even cycles are free) and it's only 2 even color clock cycles. Where is the catch?

I hope Toni will enlighten me . I'm looking forward to see any explanation.

[Toni Wilen]

That copper taking more time -comment most likely isn't true in real hardware (old test case works now without it but i fear it breaks something else without real fix..)

Could you attach your test program (including source) and I can use my logic analyzer to solve this problem.

I have been planning to do this but I haven't got good test cases. Until now I guess

Note: program needs to be ECS compatible, it is too difficult to connect LA probes to A1200 surface mount chips

[yaqube]

The program is very dirty and bangs hardware directly. I quickly modified one of my test programs which I wrote 15 years ago. I run it from Asm-One without any system software loaded. It runs on OCS but under AGA it switches fetchmode to standard one. Thanks for help. I am really curious what happens on the bus

[Toni Wilen]

Line 64 (+part of line 65) in LogicPort project file attached. I think LogicPort software (http://www.pctestinstruments.com/) works without the device and can load project files (that include captured data)

Software only has csv export and it isn't very visual

I'll attach other lines after you have confirmed you can load attached lpf-file.

Trigger condition was vsync + 64*hsync. Note that hsync isn't same as hpos=0, real hpos happens when there is 0x3c on the bus. (few cycles earlier)

(I haven't examined the result yet, later..)

EDIT: only RGA captured, data bus would mean 16 more probes, there is enough channels left but..

[yaqube]

Big thanks for very quick answer.
I confirm I can view the captured data with downloaded software. As I expected the RGA bus is idle during additional cycles of WAIT.

Now I'm doing further copper timing research. Still don't know when actual comparision takes place. My Minimig's copper code is late in WAIT's about 8 lowres pixels. I would be interested in more captured data files if you have any and be so kind to share them (I mean not only copper but blitter would be interesting although I haven't touched it yet).

[yaqube]

@Toni
I would like to see a capture of a line where all slots are taken by bitplane dma and wait is over during that line but further copper list processing is postponed until display dma is inactive (the last case in my program). It will answer some of my questions. Thanks once again.

[Toni Wilen]

Can you list the lines that are needed?

btw, I was going to setup data bus capture but I noticed I run out of probes. (found 10, need 6 more..) It seems I have lost some of them..

Blitter is as documented in HRM (channel cycle diagrams). Nothing special, fortunately or unfortunately It can use any available DMA slot.

[yaqube]

Line $D2 would be the best.

Does it mean that blitter can use odd slots if they are not used by bitplanes, sprites, audio, disk nor refresh?

[Toni Wilen]

Originally Posted by yaqube

Line $D2 would be the best.

Ok. I can do multiple lines as long as I know which ones. I am not going to do 20+ lines

Does it mean that blitter can use odd slots if they are not used by bitplanes, sprites, audio, disk nor refresh?

Yes, it can use any slot as long as it is free. (I tested by using D=A blit without any other DMA activity and all slots except 4 refresh slots were allocated for blitter)

[Toni Wilen]

More lines attached. (note that previous file was incorrect, it was line 66..)

Line $d2 and $40 from your test program.

Other files include following tests:

"moves" = move to 180, move to 182, move to 180...
"waits" = wait line 1, wait line 1, wait line 1 etc.. (skip,skip,skip was 100% identical)
"jumps" = coplc2 points to move to copjmp2. (copjmp2, copjmp2, copjmp2..)

Still need to know which "free" cycles are really free or used but null word in rga.. (Is there signal that shows when "Agnus" bus is active?)

[yaqube]

I noticed that the previously captured data was not from line $40 and assumed that it was from line $42 or $44 (those lines are probably indistinguishable).

In the meantime I discovered another undocumented feature: after write to COPJMP2 there are two additional cycles before first instruction from new location is fetched. I have also made tests with A4000 and WinUAE and found another difference considering this issue (I know that WinUAE takes these cycles into consideration). See atached pictures and source code.

The code jumps to new location after performing 4 MOVE's. It is done in 5 bitplane display mode so there are 3 free even cycles and one taken by plane 5 dma. In four lines the same sequence repeats with different start position. Could you capture line $42, $44, $46 and $48? I'm interested in the first cycle after COPJMP2 is written.

It seems that the first cycle after write to COPJMPx is just one even cycle (free or not, in your captured file there is a read to COPINS) and the second one must be a free cycle (with RGA NULL).

As far as I know there is no way to determine if a given cycle is a real free dma cycle or not, such a logic is deeply burried inside Agnus.

[BippyM]

/me is confused, or should I say..

/me doesn't understand

[Toni Wilen]

As far as I know there is no way to determine if a given cycle is a real free dma cycle or not, such a logic is deeply burried inside Agnus.

I think there must be some signal that "allocates" chip RAM bus (and keeps CPU from the bus), data bus is shared with chip ram and custom chips so even "internal" copper write to custom registers still needs to allocate the bus.

Latch chips between CPU and Agnus data bus is probably the best place.. or some signal that prevents CPU's memory accesses.

btw, I can't do more tests until saturday or sunday.

/me is confused, or should I say..

/me doesn't understand

Quick hint: numbers in RGA line are custom register addresses. (180h = dff180 etc..)

[yaqube]

Thanks for your help. There is a signal from Agnus to Gary called /DBR, when it's high chip bus is available for CPU.

[Toni Wilen]

Same tests plus "empty line" done + "/BLIT" signal included (which appears to be "agnus wants the bus"-signal. Used Gary pin 15)

I can see /DBS in Agnus pinout but I don't see it marked on any schematics.. I also tried /REGEN (which should be "RGA in use" but it was totally quiet..)

This test confirms that writing to COPJMP does need extra memory cycle which is not used for anything.. (copper_jumps.lpf)

COPJMP cycle usage seems to be:

1:fetch copper instruction (normal move cycle 1)
2:write to copjmpx (normal move cycle 2)
3:fetch next instruction(write to copins. I really need to see data in data bus..)
4:use another cycle for nothing (copy internal pointer?)
5:continue normally

More tests soon..

[yaqube]

"/BLIT" is another name for "/DBR". In all functional descriptions in Technical Reference and Service Manuals for A500/A2000 the name "/DBR" is used but in schematics it's named "/BLIT". It prevents CPU from getting bus access in current cycle.

"/REGEN" is an output from CPU address decoder. It's only active when CPU wants to access custom registers.

COPJMP cycle usage seems to be:

1:fetch copper instruction (normal move cycle 1)
2:write to copjmpx (normal move cycle 2)
3:fetch next instruction(write to copins. I really need to see data in data bus..)
4:use another cycle for nothing (copy internal pointer?)
5:continue normally

According to my tests:

As for 3: it apears that this cycle doesn't have to be a write to copins. It can also be a bitplane dma fetch.

As for 4: it apears that this cycle must be a free bus cycle. If it's taken by bitplane dma another cycle is required.

[Toni Wilen]

Originally Posted by yaqube

"/BLIT" is another name for "/DBR". In all functional descriptions in Technical Reference and Service Manuals for A500/A2000 the name "/DBR" is used but in schematics it's named "/BLIT". It prevents CPU from getting bus access in current cycle.

"/REGEN" is an output from CPU address decoder. It's only active when CPU wants to access custom registers.

Ah, that explains it

According to my tests:

As for 3: it apears that this cycle doesn't have to be a write to copins. It can also be a bitplane dma fetch.

As for 4: it apears that this cycle must be a free bus cycle. If it's taken by bitplane dma another cycle is required.

Ok, I'll test if other DMA channels can also use that cycle.

[Toni Wilen]

Originally Posted by yaqube

As for 3: it apears that this cycle doesn't have to be a write to copins. It can also be a bitplane dma fetch.

As for 4: it apears that this cycle must be a free bus cycle. If it's taken by bitplane dma another cycle is required.

This is getting weird..

Bitplane dma can use "cycle 3". BUT blitter CAN'T use it.. (it becomes "8C" cycle again)

Test case 1:

No bitplane dma. Continuous COPJMP2's. D=A blit (and nasty bit set).
-> 08C 000 08A 074 08C 000 1FE 074 (and repeats)

Test case 2:

3 planes + hires. Continuous COPJMP2's. D=A blit (and nasty bit set)
-> 112 114 110 xxx (and repeats) where xxx =
8C 8A 1FE 8C 8A 1FE (blitter didn't get any cycles)

It seems Agnus DMA scheduler is weird

[yaqube]

Bitplane dma can use "cycle 3". BUT blitter CAN'T use it.. (it becomes "8C" cycle again)

I think it's because the blitter has lower priority than the copper and the bitplane dma has the highest. That's why the copper can steal this cycle from the blitter.

The "blitter-nasty" mode keeps only the CPU off the bus, not the copper.

[Toni Wilen]

Originally Posted by yaqube

I think it's because the blitter has lower priority than the copper and the bitplane dma has the highest. That's why the copper can steal this cycle from the blitter.

The "blitter-nasty" mode keeps only the CPU off the bus, not the copper.

Yes but the point is that copper does not need that cycle for anything but it still "steals" it if it is available. But you are right, it most likely depends on dma priority levels.