ROM board with a tiny DMA engine

[martin464]

hmmm, this is the kind of thing i'd like to confirm heh
his documentation said a CPC with bad internal ram might start working, that's what made me think it was replacing the internal ram

[martin464]

Edit - you were right Eto. 

Checking his doc again reveals that in full shadow mode RAMDIS is asserted for all memory reads 'disabling CPU reads from base memory completely'. But it then reveals 'the internal RAM is only used by the CRTC chip to drive the video display'.
So if even with RAMDIS on all the time, it still reads from internal. This is set in stone somehow I guess the CRTC is directly connected to the internal ram and doesn't go through the GA?
 

[eto]

This is set in stone somehow I guess the CRTC is directly connected to the internal ram and doesn't go through the GA?

To understand all of this you probably need to look at the schematics of the CPC (https://www.cpcwiki.eu/imgs/6/6d/Schaltplan_cpc_464.jpg) and how the ICs work together. Unlike most other systems the CPC does not have a video chip. The CRTC and the GateArray together are the "video chip" of the Amstrad. And they both are not directly connected to the normal address and data bus for accessing the screen RAM but to an area which is separated from the normal bus via mixers and latches.  That's why you will never be able to use external RAM for that, as there is simply no physical connection from CRTC and GateArray to the external RAM. 

It works like this (high level):
The CRTC basically is responsible for the video address generation (except for the lowest bit). The internal RAM ICs put the data that is stored at that address on its data pins and the the Gate Array reads those 8 bits of information. Then the GateArray quickly sets the lowest bit of the address (address+1) and reads another 8 bits of data from the RAM. 

[martin464]

Got it thanks Eto. The basic thought I had was if Doragasu's DMA is throttling down it's transfer rate to accommodate the internal RAM (either from not having the pins on the expansion bus or due to the GA/CRTC limitations) then the same is not true of external RAM. One could transfer via DMA at max rate with interrupts enabled if none of the RAM undergoing DMA transfer was connected to the bus?

So you'd want to disconnect blocks of RAM during DMA data transfer from the expansion bus and the device would also need to be a RAM expansion itself in order to manage which 16k blocks were flagged as 'DMA transfer' and 'visible' unless it could somehow merrily do this without causing a problem?

To clarify, say the CPC is running a game, you could load game data into external RAM while the game was still playing without any speed limitations. But external RAM only

[McArti0]

You can use nBUSRQ. Swith off CPU and write to internal RAM whatever.

[SerErris]

You actually have a windows of only 1µs of every 4µs. The problem is, that you can only write to ram when the gatearray allows it. The Addressbus is disconnecteed from the RAM via the Muxxers for most of the time. So you would be able to transfer a byte every 4µs, which is still faster than what the CPU can achieve, because it would need to read from rom and then write to RAM. That is at least two M1 cycles + 1additional for read and 2 additional for write. That does not include logic for looping or anything else in the Z80.

So from CPU point of view your transfer is much faster (at least 4x), because you can copy every single 4µs cycle.
However at the other end, it is only good for larger memory transfers, as the CPU does not do anything.

From a signal perspective you would first need to signal BUSREQ and then wait for the CPU to send BUSACK, then you can start working.
The next thing you need to do is, to send all the CPU signales (RD, RAMRQ etc), so that the GateArray does its job. If you just try to write to the memory, it will not go through. Also timing is crucial here.

[doragasu]

Got it thanks Eto. The basic thought I had was if Doragasu's DMA is throttling down it's transfer rate to accommodate the internal RAM (either from not having the pins on the expansion bus or due to the GA/CRTC limitations) then the same is not true of external RAM. One could transfer via DMA at max rate with interrupts enabled if none of the RAM undergoing DMA transfer was connected to the bus?

So you'd want to disconnect blocks of RAM during DMA data transfer from the expansion bus and the device would also need to be a RAM expansion itself in order to manage which 16k blocks were flagged as 'DMA transfer' and 'visible' unless it could somehow merrily do this without causing a problem?

To clarify, say the CPC is running a game, you could load game data into external RAM while the game was still playing without any speed limitations. But external RAM only

That could be done. But IMO the most interesting use cases for DMA in games would be to write to video RAM, that is not possible with an external peripheral, because of what @eto has explained.
My current DMA engine is able to copy 1 byte per microsecond, it basically does the following:
1. Request the CPU bus.
2. (in parallel to 1) Synchronize with the GA.
3. Once you got the bus and synchronization, use the allocated CPU slot each microsecond to copy the data.

While doing ROM to RAM DMA, it internally disconnects from the CPC bus to read the data from ROM without disturbing the machine. So if you had on-cart RAM, it could do exactly the same and copy from ROM to on-cart RAM (or from on-cart RAM to on-cart RAM) while the CPC bus is disconnected, achieving up to 4 bytes per microsecond, or even much much higher if you use an on-cart oscillator instead of using the 4 MHz clock from the CPC (although this brings other problems that would require a larger CPLD for the same design to fit).

But as I wrote earlier, what would be the point? The cool use cases I can think about (like for example creating an engine to draw hardware sprites) would require writing to video RAM, and we cannot.

[GUNHED]

Not only games..... Some of my applications really would *LOVE* the possibility of using DMA transfer from Expansion-RAM block to another. For example: Copy data from block &D4 to &D5 (in first 512 KB E-RAM). Or just to be able to do a quick copy in RAM from one address to another. That would really speed up the work with bigger files being kept im RAM (for working quick with them). 

Whenever the DMA card is completely finished, I would like to buy (at least) one them please. The first application I would like to make 'DMA ready' would be my text editor FutureTex I guess. 

[McArti0]

Forced fast Hi pulse when READY is Low can remember screen data in 373. 
Next forced READY to Low and not remeber new data in latch but read data from 373. 
Grab data and WR to Lo. 

DMA from SCREEN RAM to other place RAM.