Copper speed question

[FrenchShark]

Hello,

another question for Toni Wilen.
This time, it is about the copper.
According to the HRM and the TRM, the OCS/ECS copper uses the same cycles than the blitter and the 68000.
Which means, if you limit your lores bitplane to 16 colors (or hires to 4 colors), you have 113 (or 112?) cycles max for the copper (226/2, The last cycle $E2 cannot be used, right ?).(1)
One instruction is two 16-bit words, so the copper needs 4 CCKs to execute one instruction. That means we can change a color every 8 lores pixels.
Now, here comes the AGA chipset : the copper is said to be 2x faster. Does that mean that it uses all the cycles or a 16-bit double-CAS fetch mode (that is always activated ? creating incompatibilities between OCS/ECS and AGA?)

Regards,

Frederic

(1) BTW, my explanation about cycle $E2 that cannot be used by copper, blitter of 68000 is because cycle $E2 is the fourth memory refresh cycle for the Chip RAM. Cycle $E1 is not used either since display data fetch cannot happen here. I am also wondering about cycle $E0 : if it is used by the copper, with a copperlist that constantly changes background color across scanline, we should see a shift of 4 pixels between two scanlines.

[Toni Wilen]

Copper (and blitter) is the exact same in AGA.

Only bitplanes and sprites have 32/64-bit modes. (which can make copper/blitter look faster because bitplanes don't need to steal as many cycles as with 16-bit fetch mode)

[FrenchShark]

Originally Posted by Toni Wilen

Copper (and blitter) is the exact same in AGA.

Only bitplanes and sprites have 32/64-bit modes. (which can make copper/blitter look faster because bitplanes don't need to steal as many cycles as with 16-bit fetch mode)

Also, am I right about the cycles $E0 - $E2 explanation (I was editing the message and you already answered) ?

Regards,

Frederic

[Toni Wilen]

Originally Posted by FrenchShark

Also, am I right about the cycles $E0 - $E2 explanation

Yes, last cycle in horizontal line is actually first refresh/strobe cycle.

[FrenchShark]

Originally Posted by Toni Wilen

Yes, last cycle in horizontal line is actually first refresh/strobe cycle.

Is cycle $E0 used by copper or wasted to keep instruction alignment ?

[Toni Wilen]

Originally Posted by FrenchShark

Is cycle $E0 used by copper or wasted to keep instruction alignment ?

E0 is normal cycle. Only the very last one is not available for anyone

[FrenchShark]

Originally Posted by Toni Wilen

E0 is normal cycle. Only the very last one is not available for anyone

E1 seems to not be reacheable either : $D8 hardstop on DDFSTOP prevent E1 from being used by DMA bitplane. Copper, blitter and 68000 use even cycles only.
I am asking this question because I am implementing Agnus in an FPGA with a SDRAM controller. I need a fifth refresh cycle for the SDRAM.
The SDRAM needs 64000 refresh cycle per second, 4 x 15625 = 62500 (PAL) and 15734 x 4 = 62896 (NTSC). A fifth cycle on E1 seems the best solution to not break the compatibility.

What do you think ?

[Toni Wilen]

Originally Posted by FrenchShark

E1 seems to not be reacheable either : $D8 hardstop on DDFSTOP prevent E1 from being used by DMA bitplane. Copper, blitter and 68000 use even cycles only.

E1 is perfectly normal free cycle. Note that DDFSTOP hard stop is at 0xD4 so you don't normally get "too large" BPL DMA cycles except if DDFSTRT is "non-aligned". (you can even cause BPL DMA to go over 0xE2 and cause very interesting garphics errors and finally crash the system..)

I am asking this question because I am implementing Agnus in an FPGA with a SDRAM controller. I need a fifth refresh cycle for the SDRAM.
The SDRAM needs 64000 refresh cycle per second, 4 x 15625 = 62500 (PAL) and 15734 x 4 = 62896 (NTSC). A fifth cycle on E1 seems the best solution to not break the compatibility.

What do you think ?

I don't think you can't do this without breaking compatibility. For example normal D=A blits will use all cycles except 4 refresh cycles. (if only blitter DMA is enabled)

It is guranteed that even single cycle difference will break some 200+ bobs demo

[FrenchShark]

Originally Posted by Toni Wilen

E1 is perfectly normal free cycle. Note that DDFSTOP hard stop is at 0xD4 so you don't normally get "too large" BPL DMA cycles except if DDFSTRT is "non-aligned". (you can even cause BPL DMA to go over 0xE2 and cause very interesting garphics errors and finally crash the system..)



I don't think you can't do this without breaking compatibility. For example normal D=A blits will use all cycles except 4 refresh cycles. (if only blitter DMA is enabled)

It is guranteed that even single cycle difference will break some 200+ bobs demo

Does blitter use even AND odd cycles ? I thought it was even cycles only
I have got confused by the Minimig implementation : the blitter uses even cycles only but also stealing cycles from the fast ram access.
For the 200+ bobs demo, I will activate the 8-word burst of the SDRAM

[FrenchShark]

Originally Posted by Toni Wilen

E0 is normal cycle. Only the very last one is not available for anyone

What about NTSC ?
The last cycle is E2 or E3. Does the refresh move to E3 every other line ?
That means a copper with 113 or 114 useful cycles per line.

[StrategyGamer]

Nasty blitter mode uses all available cycles doesn't it?

[Toni Wilen]

Blitter can use all cycles. (depends on used channel cycle sequence).

Blitter nasty has nothing to do with this. (note that enabling blitter nasty does not guarantee that blitter steals all CPU cycles)

Short/long line toggle seems to move last (or more like first?) refresh cycle and there really seems to be 1 cycle more/less for DMA/CPU use. (I haven't really cared about NTSC too much, in emulation short/long toggle is not yet emulated, for example)

How is burst mode going to help with compatibility? Amiga hardware has very low latencies in DMA (blitter write goes to ram "instantly" and CPU can read it in next memory cycle or vice versa), I think this is going to break above case. (rare but can happen, as usual!)

[Photon]

Table 6-2 and Figure 6-9 in HRM for <your chipset> will (well, ought to...) explain it all.

From the first one you can see that some minterms use every DMA cycle whereas others have gaps that are free for the CPU, regardless of BLTPRI.

BLTPRI is set to off when you have lots of bitplanes and need to stop the CPU from being totally stopped (such as if you need some interrupt, such as in a working multitasking OS ). In off state, it gives every 4th blitter DMA cycle to the CPU (simplification).

On OCS, the copper can change colors every 8 cycles up to 4 bitplanes, then bitplane DMA starts to steal cycles.

[FrenchShark]

Originally Posted by Toni Wilen

How is burst mode going to help with compatibility? Amiga hardware has very low latencies in DMA (blitter write goes to ram "instantly" and CPU can read it in next memory cycle or vice versa), I think this is going to break above case. (rare but can happen, as usual!)

If the blitter is missing few cycles to finish the 200+ bobs update, the burst mode will help by giving up to 8 times the bandwidth
The "instantly" update of the RAM takes about 280ns, which is very slow by today standard. An SDR SDRAM can do two 8-word transfers (one for the chip and one for the fast) during this time.
The AGA chipset has limited burst transfer too and it does not break the compatibility.

By the way, how does the AGA chipset react with unaligned transfer for FMODE >= 1 ? Does it ignore the lower address bits ?
Do the lines length have to be a multiple of the fetch size ?

Regards,

Frederic

[Photon]

FMODE >=1 ? Is this some C construct?

Lines length = modulo?

Haven't done benchtests on a single AGA machine, but I doubt very much that at least address-bit 0 ever gets set during a blit in any mode. AFAIK it's stripped when registers are loaded. (But admittedly, not tested. I always make sure the blitter gets kosher values.)

Why don't you test these things yourself? Every question here is just a few lines of code Don't you have an AGA Amiga?

[alexh]

Originally Posted by Photon

FMODE >=1 ? Is this some C construct?

Eh? Surely he just means if the FMODE register is not zero?

http://www.winnicki.net/amiga/memmap/FMODE.html

But, given this bit-representation for FMODE, I dont see quite what he's talking about.

[FrenchShark]

Originally Posted by alexh

Eh? Surely he just means if the FMODE register is not zero?

http://www.winnicki.net/amiga/memmap/FMODE.html

But, given this bit-representation for FMODE, I dont see quite what he's talking about.

I was talking about the DMA bitplane part of FMODE (bits 0 and 1).
To clarify : if bits 0 and/or 1 are set, bitplanes have to be aligned on a 4 (FMODE = 1,2) or 8-byte boundary (FMODE = 3).
My guess is that if you don't do it, the lower bits are dropped. Moreover, if for example you have a 304-pixel line (19 WORDs), the BPLxPTR register will be incremented by 20 anyway (plus the modulo which has to be a multiple of 4 or 8 also).

Is it clear now ?

[Toni Wilen]

I am not sure if those bits are ignored. I haven't seen any program using "illegal" values so far and I haven't bothered to test.

Usually lack of programs doing stupid things mean there is some side-effect, at least in some situations

[Photon]

Oh, it's for AGA, FMODE should stand for fetch mode... doh. He talked about blitting in the same post and I'm unfamiliar with almost all AGA stuff...

Anyway, if FrenchShark is building something in FPGA to work as an AGA Amiga, that's very nice Toni doesn't seem to mind being asked, so I'll stop 'intervening'. Still think undocumented stuff is best tested on the original hardware tho, if he wants top compatibility.