English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 09 December 2021, 16:58   #1
TommoH
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.
TommoH is offline  
Old 09 December 2021, 18:26   #2
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,152
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.
roondar is offline  
Old 09 December 2021, 19:37   #3
TommoH
Registered User

 
Join Date: Jul 2021
Location: New York
Posts: 12
Quote:
Originally Posted by roondar View Post
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:

Code:
|-        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.
TommoH is offline  
Old 09 December 2021, 20:47   #4
Kalms
Registered User
 
Join Date: Nov 2006
Location: Stockholm, Sweden
Posts: 233
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.
Kalms is offline  
Old 09 December 2021, 20:53   #5
TommoH
Registered User

 
Join Date: Jul 2021
Location: New York
Posts: 12
Quote:
Originally Posted by Kalms View Post
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

Last edited by TommoH; 09 December 2021 at 21:02.
TommoH is offline  
Old 09 December 2021, 21:00   #6
Kalms
Registered User
 
Join Date: Nov 2006
Location: Stockholm, Sweden
Posts: 233
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.
Kalms is offline  
Old 09 December 2021, 21:21   #7
TommoH
Registered User

 
Join Date: Jul 2021
Location: New York
Posts: 12
Quote:
Originally Posted by Kalms View Post
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.
TommoH is offline  
Old 09 December 2021, 22:44   #8
NorthWay
Registered User
 
Join Date: May 2013
Location: Grimstad / Norway
Posts: 743
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...
NorthWay is offline  
Old 10 December 2021, 01:01   #9
TommoH
Registered User

 
Join Date: Jul 2021
Location: New York
Posts: 12
Quote:
Originally Posted by NorthWay View Post
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.
TommoH is offline  
Old 11 December 2021, 00:17   #10
NorthWay
Registered User
 
Join Date: May 2013
Location: Grimstad / Norway
Posts: 743
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.
NorthWay is offline  
Old 11 December 2021, 14:21   #11
Niklas
Registered User

 
Join Date: Apr 2018
Location: Stockholm / Sweden
Posts: 98
Quote:
Originally Posted by TommoH View Post
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.
Niklas is offline  
Old 13 December 2021, 22:34   #12
Photon
Moderator

Photon's Avatar
 
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,174
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?

Photon is offline  
Old 14 December 2021, 04:18   #13
mc6809e
Registered User
 
Join Date: Jan 2012
Location: USA
Posts: 351
Quote:
Originally Posted by Kalms View Post
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.
mc6809e is offline  
Old 14 December 2021, 13:23   #14
Photon
Moderator

Photon's Avatar
 
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,174
Quote:
Originally Posted by mc6809e View Post
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.
Photon is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
A tiny Little Ms Access application to view .info on Windows masteripper Amiga scene 3 17 May 2021 18:26
A1200 CPU memory access speed (with DMA) roondar Coders. Asm / Hardware 38 23 July 2019 09:49
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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 14:27.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, vBulletin Solutions Inc.
Page generated in 0.09212 seconds with 13 queries