DMA on the Electron

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
paulb
Posts: 784
Joined: Mon Jan 20, 2014 9:02 pm

DMA on the Electron

Postby paulb » Thu Dec 18, 2014 10:38 pm

Since there have been a few posts touching upon interfacing projects of late, I thought it might be a good time to ask a naive question about direct memory access and the Electron.

Reading around on the 6502 (looking at the Synertek manuals, for instance) and looking at various guides on 6502.org, mentions are made of the RDY line for the purpose of performing DMA, but searching a bit on these forums, I only really found indications that most interfaces for the Electron signalled a non-maskable interrupt (NMI) and made the CPU transfer data itself.

Does anyone know whether the NMI approach was the only approach taken, or did various interfaces actually use the RDY line on the Electron? I can imagine that things like video digitisers might have needed DMA to update memory in reasonable periods of time, but I'm not aware of any such peripherals for the Electron, only the BBC Micro.

I imagine that contention with the ULA might have been dissuasive when it came to designing hardware, but given that the 6502 manuals give DMA an explicit mention, I thought it might be worth asking around on here about it.

User avatar
daveejhitchins
Posts: 3691
Joined: Wed Jun 13, 2012 5:23 pm
Location: Newton Aycliffe, County Durham

Re: DMA on the Electron

Postby daveejhitchins » Sat Dec 20, 2014 10:36 pm

Paul, sorry . . . Not heard of DMA 'ever' been used on the Elk! - This is where someone pops-up to say . . . .

Dave H :D
Parts: UM6502CE, GAL22V10D, GAL16V8D, AS6C62256A, TC514400AZ, WD1772, R6522, TMS27C512, AT28C256
Products: ARA II, ABR, ATI, AP6, MGC, AP5 . . .
For a price list, contact me at: Retro Hardware AT dave ej hitchins DOT plus DOT com

paulb
Posts: 784
Joined: Mon Jan 20, 2014 9:02 pm

Re: DMA on the Electron

Postby paulb » Sat Dec 20, 2014 10:53 pm

Some useful references while we're waiting. :wink:


(Not particularly related, but still mildly interesting, was another document I stumbled upon just now: Bitmapped video interface, which is some "old school" video signal generation using discrete logic ICs.)

poink
Posts: 963
Joined: Tue Mar 01, 2011 10:27 am

Re: DMA on the Electron

Postby poink » Sat Dec 20, 2014 11:24 pm

daveejhitchins wrote:Paul, sorry . . . Not heard of DMA 'ever' been used on the Elk

Nor can I.

Acorn never seemed very keen on DMA. Arguably, they used DMA (of a sort) to allow the video display to share memory but, as I recall, the first production machine that was sold as having DMA was the Risc PC; and even then they'd cut the SCSI controller and gone with an IDE controller in non-DMA mode; so there's no fitted hardware that uses a DMA channel on a stock RiscPC (as there are no podules fitted).

From the co-processor thread it seems the 80186 2nd processor internally used DMA, but was there even anything for the Beeb that used DMA to the Beeb's memory? I suspect that the tightly coupled nature of the Beeb (either the 6502 executing code or video output/memory refresh always seems to be happening) tends to preclude DMA.

I think older video digitisers either worked by grabbing the entire frame into an (expensive) external framebuffer or by assuming that the video display is static (eg., a paused VCR) and then repeatedly sampling it at different time offsets, thus building up the complete picture over time. (I've got an older digital storage oscilloscope which uses this technique.)

paulb
Posts: 784
Joined: Mon Jan 20, 2014 9:02 pm

Re: DMA on the Electron

Postby paulb » Sun Dec 21, 2014 12:06 am

Nice answer, poink!

I suppose the ULA is doing DMA and doesn't itself like being interrupted when active, either. Having read warnings in the documentation about snow on the screen (especially in MODEs 0-3) when disk or network interfaces are active, although those things could have been doing DMA in theory, in practice they were probably using NMIs and getting the CPU to read from some memory-mapped buffers, as I understand it at least. Such CPU-managed transfers would lock out the ULA, and thus cause snow, but it obviously wouldn't be direct memory access for the peripherals.

I started to consider how one might attempt DMA in a way that doesn't affect the ULA so that one might transfer data into screen memory. That would involve some delicate timing, but the expansion connector (and even cartridge connector) should expose the necessary signals. Hence my query about video digitisers, although I'm thinking of much more mundane stuff than that. And my electronics skills are not adequate for any tinkering just yet, anyway. :lol:

johnkenyon
Posts: 108
Joined: Wed Jul 20, 2011 2:21 pm
Location: Coventry

Re: DMA on the Electron

Postby johnkenyon » Sun Dec 21, 2014 12:13 pm

poink wrote:
daveejhitchins wrote:Paul, sorry . . . Not heard of DMA 'ever' been used on the Elk

Nor can I.

Acorn never seemed very keen on DMA. Arguably, they used DMA (of a sort) to allow the video display to share memory but, as I recall, the first production machine that was sold as having DMA was the Risc PC; and even then they'd cut the SCSI controller and gone with an IDE controller in non-DMA mode; so there's no fitted hardware that uses a DMA channel on a stock RiscPC (as there are no podules fitted).


The only DMA required in the BBC was for the screen display.
IO was at such a relatively low speed, all you had to do was write a tightly coded loop to transfer data.

Given that the 6502 RAM is only accessed by the CPU 50% of the time, all you had to do was have an address bus multiplexer driven by the CPU clock and you could have RAM shared permanently on a 50/50 basis between CPU and "something else". The only downside for this is that you have to have RAM rated for 4MHz accesses rather than 2MHz.

The something else in the Beeb being screen and as convenient byproduct, DRAM refresh.

Compare the uncontended BBC method with the ZX Spectrum method - if you tried to access the lower 16k of RAM on a Speccy at the same time as the ULA was outputting anything other than the display border, the CPU clock was held during the contention time, and CPU cycles got extended while the screen data was being read.

/John

paulb
Posts: 784
Joined: Mon Jan 20, 2014 9:02 pm

Re: DMA on the Electron

Postby paulb » Sun Dec 21, 2014 1:43 pm

johnkenyon wrote:Compare the uncontended BBC method with the ZX Spectrum method - if you tried to access the lower 16k of RAM on a Speccy at the same time as the ULA was outputting anything other than the display border, the CPU clock was held during the contention time, and CPU cycles got extended while the screen data was being read.


Yes, this sounds like the Electron and its ULA. I guess that Acorn decided that the way to compete with Sinclair was to also use cheaper, slower RAM and some extra logic to mediate between the CPU and video refresh task. (Although this caused problems for Acorn, I suppose that reducing the chip count in this way arguably makes for more predictable hardware - you get to define the circuitry precisely - at the cost of having a proprietary IC that then has to be produced in sufficient volume.)

User avatar
1024MAK
Posts: 6791
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...

Re: DMA on the Electron

Postby 1024MAK » Sun Dec 21, 2014 3:37 pm

Typically there are three different "modes" of DMA.
  • Bulk - CPU stopped, DMA transfer using all memory access cycles until all data moved/copied.
  • Burst - CPU stopped, DMA transfer using all memory access cycles for a portion of the data, DMA then pauses to allow the CPU access for a time. Then DMA cycle continues. This sequence continues until all data moved/copied. The amount of data moved per DMA cycle can be defined as the number of bytes to be moved per DMA cycle, often including just one or two bytes.
  • Background - DMA transfer only uses memory access cycles that the CPU does not need or which it cannot make use of. This mode does not slow down the CPU, but transfers are a lot slower.

As the NMOS 6502 does not have the required bus release and control signals, it cannot make all of it's control signals hi-Z (tri-state) and it uses dynamic memory for it's registers, the DMA modes where the CPU is stopped for a while all memory access is used for a fast transfer are not easy to do and retro fitting DMA is not practical.

But as the 6502 uses a very predictable memory access cycle, the Background DMA mode is easy, and it is this that is used in the Beeb. The Election uses a variation of this, which is a mix of Background and Bust DMA modes. The ULA holds the CPU clock so that the screen data can be read for display.

The ZX Spectrum was designed to be as low cost as possible, so the ULA was designed to read the screen data in DRAM page mode (the ULA always reads two bytes) from slow cheap DRAM. Couple this with the complex Z80 CPU bus access and it was not possible in the timescale available to have non-contended RAM access.

The Russian ZX Spectrum clones however do manage to have all Z80 memory access without contention, demonstrating that it is possible and practical.

And of course, the Z80 CPU has all the correct signals for DMA and a DMA chip was available for it.

There are expansion devices that have a DMA chip, and because the DMA chip uses the CPU clock, this does work well with the 48k machine as the ULA controls the clock. So the ULA will pause a DMA transfer (any mode) by holding the clock, while it reads screen data, with the poor old CPU kept waiting in last place :lol:

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

paulb
Posts: 784
Joined: Mon Jan 20, 2014 9:02 pm

Re: DMA on the Electron

Postby paulb » Sun Dec 21, 2014 4:25 pm

An informative answer, thanks!

1024MAK wrote:Typically there are three different "modes" of DMA.
  • Bulk - CPU stopped, DMA transfer using all memory access cycles until all data moved/copied.
  • Burst - CPU stopped, DMA transfer using all memory access cycles for a portion of the data, DMA then pauses to allow the CPU access for a time. Then DMA cycle continues. This sequence continues until all data moved/copied. The amount of data moved per DMA cycle can be defined as the number of bytes to be moved per DMA cycle, often including just one or two bytes.
  • Background - DMA transfer only uses memory access cycles that the CPU does not need or which it cannot make use of. This mode does not slow down the CPU, but transfers are a lot slower.


I guess that we're looking at a range of different DMA approaches, where the transfers may be sliced into finer chunks right up to the point that they can alternate with the CPU, as seen with the Electron in MODEs 4-6.

1024MAK wrote:As the NMOS 6502 does not have the required bus release and control signals, it cannot make all of it's control signals hi-Z (tri-state) and it uses dynamic memory for it's registers, the DMA modes where the CPU is stopped for a while all memory access is used for a fast transfer are not easy to do and retro fitting DMA is not practical.


This is useful to know, but do you have any comments about the Synertek manual with regard to DMA? On P112 onwards, it describes how DMA might be achieved on the 6502 and other processors in the family.

There's a mention of how dynamic RAM (with specific reference to "4096-bit dynamic RAMs") needs regular refreshes: "Refreshing the entire chip requires 32 Read operations which can be performed all at once every 2 milliseconds, or 1 approximately every 64 microseconds."

I found another remark about DMA with regard to memory on P108, section "2.3.4 The Application of RDY to Controlling the Memory Interface": "The processor can be stopped for any number of clock cycles, from one cycle for interfacing with slow memories to many cycles for DMA applications and for single cycle execution."

It seems to me that the ULA just stops the CPU clock while accessing RAM and keeping it refreshed. The challenge would be to achieve the same thing by using RDY instead of playing with the clock, and to uphold any RAM refresh requirements.

1024MAK wrote:But as the 6502 uses a very predictable memory access cycle, the Background DMA mode is easy, and it is this that is used in the Beeb. The Election uses a variation of this, which is a mix of Background and Bust DMA modes. The ULA holds the CPU clock so that the screen data can be read for display.


I suppose that Beeb's 6502 is, however, unaware of the background DMA, though, given the increased bus speed.

1024MAK wrote:The ZX Spectrum was designed to be as low cost as possible, so the ULA was designed to read the screen data in DRAM page mode (the ULA always reads two bytes) from slow cheap DRAM. Couple this with the complex Z80 CPU bus access and it was not possible in the timescale available to have non-contended RAM access.


So, it is effectively like the Electron in MODEs 0-3, then, at least when considering the effect?

1024MAK wrote:The Russian ZX Spectrum clones however do manage to have all Z80 memory access without contention, demonstrating that it is possible and practical.

And of course, the Z80 CPU has all the correct signals for DMA and a DMA chip was available for it.

There are expansion devices that have a DMA chip, and because the DMA chip uses the CPU clock, this does work well with the 48k machine as the ULA controls the clock. So the ULA will pause a DMA transfer (any mode) by holding the clock, while it reads screen data, with the poor old CPU kept waiting in last place :lol:


This is certainly an interesting approach. :)

poink
Posts: 963
Joined: Tue Mar 01, 2011 10:27 am

Re: DMA on the Electron

Postby poink » Mon Dec 22, 2014 1:19 am

paulb wrote:I found another remark about DMA with regard to memory on P108, section "2.3.4 The Application of RDY to Controlling the Memory Interface": "The processor can be stopped for any number of clock cycles, from one cycle for interfacing with slow memories to many cycles for DMA applications and for single cycle execution."

I vaguely recall that this isn't possible on all 6502 processors. It's certainly possible on a static variant (The CMOS 65C02 is IIRC) but I think on the early ones they tend to forget what they were doing. I'm not sure what the situation is with the 6502 they used in the Elk.

paulb wrote:I started to consider how one might attempt DMA in a way that doesn't affect the ULA so that one might transfer data into screen memory.

In principle, if one could force a write on the (4-bit) memory bus, rather than a read, then one could get background DMA to screen memory at the speed of scanout. The ULA simply sees (and thus displays) what we're writing to the RAM, instead of what was stored in RAM.

I suspect one can't pull that off from the expansion connector though. (It might require ULA support, and thus be the rare thing of an improvement that could have been made to the Elk design without blowing the budget.)

paulb
Posts: 784
Joined: Mon Jan 20, 2014 9:02 pm

Re: DMA on the Electron

Postby paulb » Tue Jan 06, 2015 5:43 pm

poink wrote:
paulb wrote:I found another remark about DMA with regard to memory on P108, section "2.3.4 The Application of RDY to Controlling the Memory Interface": "The processor can be stopped for any number of clock cycles, from one cycle for interfacing with slow memories to many cycles for DMA applications and for single cycle execution."

I vaguely recall that this isn't possible on all 6502 processors. It's certainly possible on a static variant (The CMOS 65C02 is IIRC) but I think on the early ones they tend to forget what they were doing. I'm not sure what the situation is with the 6502 they used in the Elk.


Various resources tend to mention that only the CMOS variants lend themselves to certain activities, usually with no further explanation. However, it is stated that the Synertek NMOS variant can only be suspended during a read cycle, although a description of how such a cycle may be detected is provided in the manual. Since the CPU has to read instructions on a regular basis, it's not such a severe limitation.

poink wrote:
paulb wrote:I started to consider how one might attempt DMA in a way that doesn't affect the ULA so that one might transfer data into screen memory.

In principle, if one could force a write on the (4-bit) memory bus, rather than a read, then one could get background DMA to screen memory at the speed of scanout. The ULA simply sees (and thus displays) what we're writing to the RAM, instead of what was stored in RAM.

I suspect one can't pull that off from the expansion connector though. (It might require ULA support, and thus be the rare thing of an improvement that could have been made to the Elk design without blowing the budget.)


Since R/W# (or however you write that) is exposed on the expansion connector, the crucial issue is probably that of holding R/W# low in order to write data, just as the CPU instructs the ULA to do so when it wants to write to RAM. If that's possible - making a peripheral override the CPU signals on various lines before becoming passive again - then I can't see a reason why writing wouldn't otherwise work.

That said, I have no real experience with such matters myself. :?

paulb
Posts: 784
Joined: Mon Jan 20, 2014 9:02 pm

Re: DMA on the Electron

Postby paulb » Sun Feb 01, 2015 4:32 pm

Just following up on this, having seen a post today mentioning the NMOS 6502 CPU "forgetting" things again. This remark seems to appear quite a lot on the broader Internet without any further qualification, making it hard to understand the actual technical constraints, so I dredged up a few instances of it:

  • What is the real core of ATARI's 6502C CPU mentions this in this context: "When HALT is active, the CPU won't do anything because its clock would be stopped." I can only find a reference in the Synertek manual to HALT as being the approximate 6800 equivalent to the RDY input.
  • Anyone willing to trade me for a WDC65C02S? includes this: "The RDY input can be used to single-step an NMOS chip without stopping the clock but that's more nuisance than it's worth, IMO."
  • 6502 Clock issues uses terminology like "stop" in connection with RDY, but there's no distinction made between stopping the CPU's instruction processing activity and stopping its clock.

Indeed, the Synertek hardware manual mentions that, "The processor can be stopped for any number of clock cycles, from one cycle for interfacing with slow memories to many cycles for DMA applications and for single cycle execution." This implies that you would have the clock still cycling during RDY assertion, unless the text is referring to cycles that would have taken place, but that would be a bit contrived and misleading.

User avatar
BigEd
Posts: 1496
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: DMA on the Electron

Postby BigEd » Sun May 10, 2015 5:50 am

paulb wrote:... the Synertek hardware manual mentions that, "The processor can be stopped for any number of clock cycles, from one cycle for interfacing with slow memories to many cycles for DMA applications and for single cycle execution." This implies that you would have the clock still cycling during RDY assertion, unless the text is referring to cycles that would have taken place, but that would be a bit contrived and misleading.

Yes, RDY is taken low to re-do a read cycle, so the clock will still be running. (In the original NMOS 6502, RDY is ignored during write cycles. This is just enough functionality to interface with a multi-cycle memory system, at the expense of having to buffer writes, or to interface with slow ROM. It's also enough to do single-stepping, because an instruction fetch is a read. But it's not enough to do single-cycling.)

I can only find a reference in the Synertek manual to HALT as being the approximate 6800 equivalent to the RDY input

I hadn't come across HALT before... it seems the later Atari 400/800 systems used a 6502C (C for 'Custom'), later renamed Sally, which is an NMOS 6502 with tweaks to facilitate DMA. So we should take HALT as being a 'better' version of RDY, but it's possible it does stop the clock (internally) and therefore could only be used to stall for say 10 cycles - 100 kHz being probably a safe minimum speed for an NMOS 6502. (Not that anyone is likely to be building a new design with a Sally CPU, so for general purposes this is a red herring.)

See http://www.faqs.org/faqs/atari-8-bit/faq/
The Atari's second microprocessor, ANTIC, must routinely interrupt the 6502 in order to utilize the processor bus for itself for direct memory access (DMA). HALT' on the SALLY 6502 facilitates this system design. Atari's earlier implementation of the same functionality in the 400/800 with the standard 6502 requires a series of 4 additional chips that are unnecessary in computers designed for the SALLY 6502.

paulb
Posts: 784
Joined: Mon Jan 20, 2014 9:02 pm

Re: DMA on the Electron

Postby paulb » Wed Feb 22, 2017 2:40 pm

Just thinking about this again in the context of pause buttons for the Atari 2600 VCS, I sought to remind myself whether DMA would be possible. To clarify, this is DMA where the CPU is halted but the clock is not stopped (crucially, because we would actually need it), with the matter of whether a complete transfer or a partial transfer is performed being left undecided.

The Synertek hardware manual makes it pretty clear that DMA is supported using RDY#, actually describing the mechanism in section 2.3.4.2 "Direct Memory Access (DMA) Techniques":

Provision for stopping the processor is available on the MCS6501, MCS6502 and MCS6505. This is accomplished by pulling the RDY line on the processor to GND (< 0.4V). The processor will stop in the first non-write cycle with the data bus in the high-impedance state. After the processor has stopped, the DMA controller must provide the address and data for the memory and must control R/W if data is being transferred into memory.

Providing addresses for the memories can be accomplished by gating addresses from either the DMA controller or the microprocessor into the memories. This can be accomplished very easily with a Quad 2-input data selector. During the DMA operation, the addresses fed to the memories are those generated by the DMA controller. After the DMA operation is complete, the input select signal to the data selector is inverted and the addresses generated by the processor once again determine which memory word is being accessed. The R/W line to the memories can be controlled in the same way as the address lines.


Sorry if I quoted this before. What I had become uncertain of was whether the address lines were relinquished by the CPU upon assertion of RDY#. The manual makes it pretty clear that all necessary lines are relinquished: RDY# is not merely a tool to allow slow reads, which would be the case if the addresses asserted by the CPU remained on the bus, for instance.

One annoying thing is that the Plus 1 doesn't expose A14 and A15 to cartridges, meaning that cartridges will not be able to perform DMA in general. The RDY# and RnW (R/W) lines are available, but Acorn presumably regarded RDY# as a tool to perform slow reads, which is what the Advanced User Guide seems to indicate. Thus, attempts to assert addresses and independently access the RAM will probably fail due to A14 and A15 being unasserted.

User avatar
1024MAK
Posts: 6791
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...

Re: DMA on the Electron

Postby 1024MAK » Mon Dec 04, 2017 8:04 am

Reading in between the lines, I would say that the bus drivers for the address bus in NMOS 6502 CPUs do not go to a tri-state hi-impedance mode when RDY is active. Otherwise why would the manufacturers of the more advance CMOS versions add an extra control pin (BE) for bus control.

WDC65C02 datasheet wrote:3.2 Bus Enable (BE)
The Bus Enable (BE) input signal provides external control of the Address, Data and the RWB buffers. When Bus Enable is high, the Address, Data and RWB buffers are active. When BE is low, these buffers are set to the high impedance status. Bus Enable is an asynchronous signal.


The datasheet for this version also expands on the RDY pin (but note that on this CPU, further functionality has been added).
WDC65C02 datasheet wrote:3.10 Ready (RDY)
A low input logic level on the Ready (RDY) will halt the microprocessor in its current state. Returning RDY to the high state allows the microprocessor to continue operation following the next PHI2 negative transition. This bi-directional signal allows the user to single-cycle the microprocessor on all cycles including write cycles. A negative transition to the low state prior to the falling edge of PHI2 will halt the microprocessor with the output address lines reflecting the current address being fetched. This assumes the processor setup time is met. This condition will remain through a subsequent PHI2 in which the ready signal is low. This feature allows microprocessor interfacing with low-speed memory as well as direct memory access (DMA). The WAI instruction pulls RDY low signaling the WAit-for-Interrupt condition, thus RDY is a bi-directional pin. On the W65C02 hard core there is a WAIT output signal that can be used in ASIC's thus removing the bi-directional signal and RDY becomes only the input. In such a situation the WAI instruction will pull WAIT low and must be used external of the core to pull RDY low or the processor will continue as if the WAI never happened. The microprocessor will be released when RDY is high and a falling edge of PHI2 occurs. This again assumes the processor control setup time is met. The RDY pin no longer has an active pull up. It is suggested that a pull up resistor be used on this pin when not being used. The RDY pin can still be wire ORed.


http://www.cpu-world.com/info/6502/65xx ... ences.html

On the older NMOS and CMOS 6502s, to use DMA an external line driver/buffer with tri-state outputs is required on the address lines and for the R/W line.

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...


Return to “hardware”

Who is online

Users browsing this forum: Bing [Bot], Kazzie and 10 guests