Does the CPU ever access Chip RAM without being aligned to the DMA access windows?

[TommoH]

On a plain OCS Amiga each DMA time slot is two processor cycles long. When the CPU wants to access Chip RAM it may have to wait for an unoccupied slot.

Question then: if the CPU isn't currently aligned to the two-cycle DMA windows*, and wants to access Chip RAM halfway through an empty DMA slot which is followed by another empty slot, is it penalised a cycle or does the access happen immediately?

Apologies for the slightly academic question.

* I notice that DTACK is exposed on the Zorro bus, so that's one way it appears that the CPU can end up out of phase with the DMA windows.

[roondar]

The CPU can access any DMA slot, it just can't access two in a row. So it can access both the 'even' and the 'odd' slots, just not one after the other. Due to how DMA is allocated, the CPU usually gets 'pushed' back into alignment sooner or later, but if a non-aligned slot is open and the CPU needs it, it'll get it without any cycle penalties.

[TommoH]

Originally Posted by roondar

The CPU can access any DMA slot, it just can't access two in a row. So it can access both the 'even' and the 'odd' slots, just not one after the other. Due to how DMA is allocated, the CPU usually gets 'pushed' back into alignment sooner or later, but if a non-aligned slot is open and the CPU needs it, it'll get it without any cycle penalties.

To clarify, because I'm a simple fellow...

The situation I'm asking about is this:

|-        DMA slot         -|-        DMA slot         -|
|- CPU cycle -|- CPU cycle -|- CPU cycle -|- CPU cycle -|

                     ^            ^
                     |            |
                     --------------
                            |

            CPU would access here if permitted

Will the CPU have to wait one cycle for the next full DMA slot, or can it straddle two with a single access as depicted if both slots are unoccupied?

Should I take from your answer that it can't, because that would be using two slots in a row? Or were you more commenting on the 68000's usual access patterns?

The whole thing feels like a bit of an edge case with likely minimal impact that would need the DMA scheduler to have an extra bit of lookahead, so I wouldn't be surprised if the answer is that alignment occurs.

[Kalms]

Think of it like this:

The 68000 CPU's logic for performing a memory access takes 4 cycles to complete. The first two cycles are spent preparing, signaling the address of interest, whether it's a read or a write; the last two are used for the actual data transfer.

The Amiga chipset decouples the CPU from other hardware to some extent. The part that cannot be decoupled is the latter half where the data transfer takes place. Where it seems in some Amiga manuals like an access only takes two CPU cycles, it is the data transfer portion that takes two CPU cycles; and where it seems like the CPU needs to 'wait' two CPU cycles between consecutive memory accesses, it is that the CPU is busy signalling the second address and read/write and therefore not able to perform the second data transfer immediately.

Now what about alignment? Well, if the CPU reaches the point where it wants to do a data transfer (so cycle #3 in the 4-cycle process) yet there is no DMA slot ready, then the CPU will wait, cycle after cycle, until it is granted a DMA slot. Then it immediately proceeds with the data transfer.

See the '68000 Bus Cycle Timing' section at https://www.bigmessowires.com/2011/0...roller-design/ for some more elaboration.

[TommoH]

Originally Posted by Kalms

Think of it like this:

The 68000 CPU's logic for performing a memory access takes 4 cycles to complete. The first two cycles are spent preparing, signaling the address of interest, whether it's a read or a write; the last two are used for the actual data transfer.

The Amiga chipset decouples the CPU from other hardware to some extent. The part that cannot be decoupled is the latter half where the data transfer takes place. Where it seems in some Amiga manuals like an access only takes two CPU cycles, it is the data transfer portion that takes two CPU cycles; and where it seems like the CPU needs to 'wait' two CPU cycles between consecutive memory accesses, it is that the CPU is busy signalling the second address and read/write and therefore not able to perform the second data transfer immediately.

Now what about alignment? Well, if the CPU reaches the point where it wants to do a data transfer (so cycle #3 in the 4-cycle process) yet there is no DMA slot ready, then the CPU will wait, cycle after cycle, until it is granted a DMA slot. Then it immediately proceeds with the data transfer.

See the '68000 Bus Cycle Timing' section at https://www.bigmessowires.com/2011/0...roller-design/ for some more elaboration.

I have no problem with any of that; the question is: if cycle #3 of a 4-cycle Chip memory access falls halfway through an unoccupied DMA slot, and the next DMA slot is also unoccupied, does cycle #3 start right then, or does it start one cycle later? Do those two CPU cycles have to be aligned to a DMA slot, or can they occupy the second half of one slot and the first half of the next?

There's no physical limitation clearly — it's the same access time for the RAM, and nobody else needs to access it. But is the scheduler able to schedule on the half-slot for such an access?

EDIT: I don't see how this is any clearer than the diagram above, but e.g. in 68000 clock cycles (and all events rounded off to that precision) is the following possible:

1. first cycle of a DMA slot
2. dtack acknowledged, data strobe goes active
3. first cycle of a second DMA slot
4. data strobe goes inactive, 68000 is done
5. first cycle of a third DMA slot

Or, must it be:

1. first cycle of a DMA slot
2. [nothing; CPU penalised a cycle]
3. first cycle of a second DMA slot, dtack acknowledged, data strobe goes active
4. [nothing; middle of RAM access]
5. first cycle of a third DMA slot, data strobe goes inactive, 68000 is done

[Kalms]

Aha. That I do not know, sorry, and never looked into because:

The 68000 CPU instruction set is designed so there never are any instructions that take an odd number of cycles, or start a memory access at an odd number of cycles.

I believe that a 68000 memory access that gets delayed by the Amiga chipset always gets delayed by an even number of cycles (I.e. to the beginning of the Nth following DMA slot).

Because of the above, I believe there is no way for the CPU to become desynchronized in the way that you outline above. Except, if you manipulate DTACK via homemade hardware then -- hmm, no, sorry, no idea what would happen then.

[TommoH]

Originally Posted by Kalms

Aha. That I do not know, sorry, and never looked into because:

The 68000 CPU instruction set is designed so there never are any instructions that take an odd number of cycles, or start a memory access at an odd number of cycles.

I believe that a 68000 memory access that gets delayed by the Amiga chipset always gets delayed by an even number of cycles (I.e. to the beginning of the Nth following DMA slot).

Because of the above, I believe there is no way for the CPU to become desynchronized in the way that you outline above. Except, if you manipulate DTACK via homemade hardware then -- hmm, no, sorry, no idea what would happen then.

Yeah, it's probably completely academic — I was thinking of hypothetical cases of e.g. a Zorro device with one-wait-state memory on it, or one that did something other than VPA for interfacing a lower-speed component.

I can think of no way that the 68000 could get out of phase in a stock Amiga, as all exceptions seem to fire at two-cycle boundaries, all instructions (including TAS and variable-length multiply and divide) are multiples of two cycles in length, and all peripheral chip accesses retain alignment.

[NorthWay]

As far as I understand:
Our ugly sibling the ST has a locked down lock-step access between the cpu and the graphics chip - they get every other each. That results in some cycle stretching; I believe it affects opcodes not a multiple of 4 cycles, but it depends on how much of the opcode is internal processing and how much is bus access. It's complicated and you need an ST guy to pop in and correct me here.
That will of course have to behave the same on the Amiga under the same circumstances, but - to the best of my knowledge - it can be avoided when there is an unused chipset cycle.

If that was any closer to an anwer...

[TommoH]

Originally Posted by NorthWay

As far as I understand:
Our ugly sibling the ST has a locked down lock-step access between the cpu and the graphics chip - they get every other each. That results in some cycle stretching; I believe it affects opcodes not a multiple of 4 cycles, but it depends on how much of the opcode is internal processing and how much is bus access. It's complicated and you need an ST guy to pop in and correct me here.
That will of course have to behave the same on the Amiga under the same circumstances, but - to the best of my knowledge - it can be avoided when there is an unused chipset cycle.

If that was any closer to an anwer...

The ST is what made me curious; it does indeed have a fixed two-cycles-for-you-then-two-for-me memory access pattern, and it also has a one-cycle penalty on AY accesses, so the CPU can get out of phase. But the fixed slot division means that there’s never an opportunity for slot straddling by the 68000 so the answer there is fairly clear.

[NorthWay]

For what it's worth, I really wanted to write a big lump of looping unrolled code (which should be possible with just a few lines of source) that ran the worst possible non-4 cycle opcodes for the ST, turned off Amiga DMA and do the timings for both an ST and an A500, and send to Retro Gamer who at one point pissed me off with their no-exceptions "ST is 10% faster" (10 should be more like 13 then) gospel.
Alas, they are mostly parroting their "20 years" rule now and have grabbed 3D consoles with both hands and run with it.

[Niklas]

Originally Posted by TommoH

1. first cycle of a DMA slot
2. dtack acknowledged, data strobe goes active
3. first cycle of a second DMA slot
4. data strobe goes inactive, 68000 is done
5. first cycle of a third DMA slot

Or, must it be:

1. first cycle of a DMA slot
2. [nothing; CPU penalised a cycle]
3. first cycle of a second DMA slot, dtack acknowledged, data strobe goes active
4. [nothing; middle of RAM access]
5. first cycle of a third DMA slot, data strobe goes inactive, 68000 is done

Agnus is arbitrating the use of DMA slots. By the start of the DMA slot Agnus decides if the CPU will use the slot or not, if the slot is not already allocated to some DMA channel of course.

One way to see why this must be the case, is that in the middle of the first CPU cycle (one quarter of the way through the DMA slot), Agnus is driving the row address on the DRAM address lines, and asserting row address strobe (RAS). So by that time Agnus must already have decided what chip memory word to access in that slot.

On page 14 and 15 of this document, AGNUS.pdf, are nice timing diagrams that show how the CPU communicates with Agnus, and how Agnus communicates with the DRAM.

[Photon]

If I understand you correctly, for hardware programming (i.e. running hardware-banging code question), it should be relatively simple and quick to find out how the hardware actually behaves:

With no competing DMA,

1. Wait for a HPOS
2. Spam COLOR00
3. Wait for same HPOS on next line+Perform "odd"-timing instruction
4. Spam COLOR00
5. Next run:Move HPOS, test pattern again. Did it align?

[mc6809e]

Originally Posted by Kalms

Because of the above, I believe there is no way for the CPU to become desynchronized in the way that you outline above. Except, if you manipulate DTACK via homemade hardware then -- hmm, no, sorry, no idea what would happen then.

I wouldn't be surprised if some early fast ram memory expansion boards inserted an extra wait state so that they could use cheap DRAM.

[Photon]

Originally Posted by mc6809e

I wouldn't be surprised if some early fast ram memory expansion boards inserted an extra wait state so that they could use cheap DRAM.

The question is about Chip RAM, though.