09 December 2021, 16:58 | #1 |
Registered User
Join Date: Jul 2021
Location: New York
Posts: 12
|
Does the CPU ever access Chip RAM without being aligned to the DMA access windows?
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. |
09 December 2021, 18:26 | #2 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,444
|
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.
|
09 December 2021, 19:37 | #3 | |
Registered User
Join Date: Jul 2021
Location: New York
Posts: 12
|
Quote:
The situation I'm asking about is this: Code:
|- DMA slot -|- DMA slot -| |- CPU cycle -|- CPU cycle -|- CPU cycle -|- CPU cycle -| ^ ^ | | -------------- | CPU would access here if permitted 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. |
|
09 December 2021, 20:47 | #4 |
Registered User
Join Date: Nov 2006
Location: Stockholm, Sweden
Posts: 237
|
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. |
09 December 2021, 20:53 | #5 | |
Registered User
Join Date: Jul 2021
Location: New York
Posts: 12
|
Quote:
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 Last edited by TommoH; 09 December 2021 at 21:02. |
|
09 December 2021, 21:00 | #6 |
Registered User
Join Date: Nov 2006
Location: Stockholm, Sweden
Posts: 237
|
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. |
09 December 2021, 21:21 | #7 | |
Registered User
Join Date: Jul 2021
Location: New York
Posts: 12
|
Quote:
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. |
|
09 December 2021, 22:44 | #8 |
Registered User
Join Date: May 2013
Location: Grimstad / Norway
Posts: 855
|
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... |
10 December 2021, 01:01 | #9 | |
Registered User
Join Date: Jul 2021
Location: New York
Posts: 12
|
Quote:
|
|
11 December 2021, 00:17 | #10 |
Registered User
Join Date: May 2013
Location: Grimstad / Norway
Posts: 855
|
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. |
11 December 2021, 14:21 | #11 | |
Registered User
Join Date: Apr 2018
Location: Stockholm / Sweden
Posts: 129
|
Quote:
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. |
|
13 December 2021, 22:34 | #12 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,730
|
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,
|
14 December 2021, 04:18 | #13 |
Registered User
Join Date: Jan 2012
Location: USA
Posts: 373
|
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.
|
14 December 2021, 13:23 | #14 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,730
|
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
A1200 CPU memory access speed (with DMA) | roondar | Coders. Asm / Hardware | 43 | 17 February 2023 16:21 |
A tiny Little Ms Access application to view .info on Windows | masteripper | Amiga scene | 3 | 17 May 2021 18:26 |
Access Windows share over network from A2000? | LuigiThirty | New to Emulation or Amiga scene | 10 | 10 January 2017 13:17 |
Using PC Windows to let Amiga access Wireless Internet | tygre | support.Other | 16 | 24 May 2012 04:43 |
Can't access HD | ruffian | support.Hardware | 5 | 13 November 2009 12:59 |
|
|