Trying to understand DMA on a 4A.

[+dhe]

I'm trying to understand DMA in the 4A world.

 

I found this on wikipedia:
The processor can be paused with the address bus tri-stated for external direct memory access (DMA). Memory accesses are always 16 bits wide, with the CPU automatically performing read-before-write operations for byte-wide accesses.

 

The only card I know that claims to do DMA is the MyARC HFDC.

 

It's documented in the manual here:
CRU OFFSET RELATIVE ADDRESS    DEFINITION           ACTIVE
          >02             >04                 DMA in Progress      High

 

Do you get DMA for free on all reads and writes, or do you have to set it up in assembly?

 

Does it really buy you any real world performance as implemented on the HFDC?

 

People looking at the MyARC FDCC said it looks like a second iteration would have been setup for DMA....

[+mizapf]

The HFDC does not do the DMA that you supposedly think of. The DMA is only done between the controller chip and the onboard RAM of the HFDC; this is a private business of the card. However, you can map the RAM into the main address space (at 5000, 5400, 5800, 5c00).

 

[matthew180]

34 minutes ago, dhe said:

I found this on wikipedia:
The processor can be paused with the address bus tri-stated for external direct memory access (DMA). Memory accesses are always 16 bits wide, with the CPU automatically performing read-before-write operations for byte-wide accesses.

 

The first sentence is fine, the second makes absolutely no sense; the CPU is out of the picture when DMA is taking place (that's the whole purpose of DMA).

 

The 9900 has support for DMA via the #HOLD input and HOLDA output, however on the 99/4A #HOLD input pin is pulled high and not externally exposed.  So actual CPU-coordinated DMA is not possible on the 99/4A.

 

[+mizapf]

The second sentence has nothing to do with DMA, as I understand it. So why does it not make sense, as you say?

[matthew180]

The OP's question was about DMA, and included an excerpt from WikiPedia about, presumably, the 9900 DMA interface.

 

In the context of DMA, stating how the CPU accesses memory is irrelevant, since the CPU is inactive, and the address bus and data bus are tri-stated as far as the CPU is concerned.  The way the CPU accesses memory has nothing to do with how a DMA device might access memory.

 

Maybe those two sentences are completely separate and make more sense in full context (I did not go read the WikiPedia page).

[Willsy]

Agree with Matthew. Once the CPU is off the bus, memory accesses can be 1, 2, 3, 8, 11, 12 whatever bits wide - it's none of the CPUs business. The read before write reference is clearly a reference to the CPUs architecture and of no relevance to DMA once the CPU is off the bus. Typical Wikipedia BS.

[Asmusr]

If you read the article it's just two sentences next to each other. Nobody claims that the second is about DMA.

[+FarmerPotato]

Geez, it was one statement about DMA mixed in with other facts about the 9900.  
 

Dan was just asking what it meant. 
 

DMA has some overhead for stopping the 9900.

 

You might  design for it if dumping a lot of data fast were a benefit. Say 256 bytes from disk. At least,  the CPU doesn’t have to copy it from the DSR to itself and back to main memory.

 

Because a CPU in the peripheral is writing to memory, for the CPU to read later. 
 

 

 

 

[+OLD CS1]

The bit about CPU reading is certainly non sequitur.  It should be elsewhere in the article.  Corollary to other discussions about Wikipedia, much of the article contains commentary versus information or fact.

[+dhe]

I appreciate everyone's feedback, the core take away's for me:

1) no hold pin, no DMA transfers.

2) the reference to DMA in the MyARC HFDC manual is 'private' DMA on the board.

3) the wikipedia article is not perfect. 😃

 

Another design decision that made the 4a poorer than it needed to be.

 

One day, when I'm smarter, I need to revisit the Culp code to do data transfers to CPU memory, avoiding the double transfer from VDP buffers to CPU RAM. While this has nothing to do with DMA, if it works, it eliminates one step that doesn't add any value.

 

 

[apersson850]

It does offer the value that you can use diskettes without having 32 k RAM expansion.

[speccery]

Somewhat off-topic and unnecessary advertising of my ET-PEB project: it does DMA transfers from SD card to CPU RAM expansion. The onboard microcontroller handles moving of data back and forth between CPU RAM and SD card, and translating to the FAT32 filesystem in between. Although personally I think it's cool, it's sort of pointless since all TI-99/4A software expects disk buffers to reside in VDP memory. Of course it's a requirement for a non-expanded system, and would be too easy otherwise. So in the end the CPU copying is still needed, and probably in many cases the first thing the application code does is to copy the buffers back to CPU memory