System and Video RAM DMA - Revision history

PJW: /* Proper Sequencing */

2021-01-19T21:12:46Z

‎Proper Sequencing

PJW at 21:11, 19 January 2021

2021-01-19T21:11:18Z

PJW: Created page with "NOTE: this section to be fleshed out later. Okay, this is important message for anybody who has been using the SDMA -> VDMA transfer. For some reasons, the problem comes up o..."

2021-01-18T21:42:56Z

Created page with "NOTE: this section to be fleshed out later. Okay, this is important message for anybody who has been using the SDMA -> VDMA transfer. For some reasons, the problem comes up o..."

New page

NOTE: this section to be fleshed out later.

Okay, this is important message for anybody who has been using the SDMA -> VDMA transfer. For some reasons, the problem comes up on the U but never did on the FMX. Anyway, the deal is when you are doing a SDMA to VDMA, because the CPU takes 100% of the bandwidth, when the transfer takes place, the CPU is halted. The SDMA goes and fetch the data and then when all the data is fetched, the CPU is released. This part works fine, the part that I have been having issues on the U, is the fact that when the SDMA part is done, it doesn't necessarily means that the VDMA part is done. Since they are very much asynchronous and the fact that remainder of the DATA in the FIFO might linger on till the time is right to go write that Data and that can take a little of time before it happens.
So, bottom line, that means that before you can begin a new transfer, you need to make sure the old one is done. So, either you poll the Status Register bit 7 of the VDMA or you wait for an Interrupt to happen to let you know that it is finished.
Like I said, I am talking about this now because I never really had any issues like this before... So, for the concept of having a Kosher way of doing things and also for the sake of compatibility with the U in the future. Always make sure that when you are doing a SDMA to VDMA that the Flag is reseted before beginning a new one. Cheers!

Below and example of how it should be done:
<nowiki>
; Begin Transfer
; Start the VDMA Controller First
LDA VDMA_CONTROL_REG
ORA #VDMA_CTRL_Start_TRF
STA @l VDMA_CONTROL_REG

; Then, Start the SDMA Controller

LDA SDMA_CTRL_REG0
ORA #SDMA_CTRL0_Start_TRF
STA @l SDMA_CTRL_REG0
NOP ; When the transfer is started the CPU will be put on Hold (RDYn)...
NOP ; Before it actually gets to stop it will execute a couple more instructions
NOP ; From that point on, the CPU is halted (keep that in mind) No IRQ will be processed either during that time
NOP
NOP
NOP
NOP
NOP

LDA #$00
STA @l SDMA_CTRL_REG0

NOTFINISHED:
LDA @l VDMA_STATUS_REG
AND #$80
CMP #$80
BEQ NOTFINISHED
LDA #$00
STA @l VDMA_CONTROL_REG</nowiki>

@@ Line 7: / Line 7: @@
 There are a couple of details to keep in mind with sequencing these sorts of DMA transfers.
-First, although VDMA will not stop the processor, SDMA will. You therefor cannot trigger the VDMA after the SDMA has been triggered, because you will not be able to trigger the VDMA before the SDMA block stops the CPU.
+First, although VDMA will not stop the processor, SDMA will. You therefore cannot trigger the VDMA after the SDMA has been triggered, because you will not be able to trigger the VDMA before the SDMA block stops the CPU.
 Second, when transferring from system RAM to video RAM, the VDMA is not necessarily finished when the SDMA is done. Writes can still be pending. This is important to keep in mind because you cannot access video RAM while a VDMA is going on, and you cannot start another VDMA operation while another is still going. So it is recommended that you make sure your VDMA is finished before continuing with your program.

@@ Line 1: / Line 1: @@
 NOTE: this section to be fleshed out later.
-Okay, this is important message for anybody who has been using the SDMA -> VDMA transfer. For some reasons, the problem comes up on the U but never did on the FMX. Anyway, the deal is when you are doing a SDMA to VDMA, because the CPU takes 100% of the bandwidth, when the transfer takes place, the CPU is halted. The SDMA goes and fetch the data and then when all the data is fetched, the CPU is released. This part works fine, the part that I have been having issues on the U, is the fact that when the SDMA part is done, it doesn't necessarily means that the VDMA part is done. Since they are very much asynchronous and the fact that remainder of the DATA in the FIFO might linger on till the time is right to go write that Data and that can take a little of time before it happens.
+When using DMA to transfer data between system and video RAM, both the [[System DMA Block]] and the [[Video DMA Block]] have to be configured and used together. For example, if a program needs to copy data from system RAM into video RAM (e.g. bitmap data) it needs to configure the system DMA block to grab the needed block of system RAM as the source, and it needs to configure the video DMA block to store that block in the correct area of video RAM. The two DMA blocks will cooperate to do the actual transfer.
-So, bottom line, that means that before you can begin a new transfer, you need to make sure the old one is done. So, either you poll the Status Register bit 7 of the VDMA or you wait for an Interrupt to happen to let you know that it is finished.
-Like I said, I am talking about this now because I never really had any issues like this before... So, for the concept of having a Kosher way of doing things and also for the sake of compatibility with the U in the future. Always make sure that when you are doing a SDMA to VDMA that the Flag is reseted before beginning a new one. Cheers!
+= Proper Sequencing =
   <nowiki>
 ; Begin Transfer