A device with direct memory access?

[dfzx]

Apropos of nothing, I found myself wondering if it's possible for a device plugged into a Spectrum to change the Spectrum's memory directly?

Assuming the 48K for simplicity, would it be possible for a device plugged into the edge connector to, at a moment of its choosing, stop the Z80, change the contents of RAM, then release the Z80, without the Z80 really knowing anything about it?

I've no idea what I'd do with such a feature, I just wondered if it was possible.

[Ast A. Moore]

Not sure exactly what you mean by “without the Z80 really knowing anything about it,” but, sure, all the address and data lines, as well as the RFSH, HALT, WR, MREQ and other signals are available on the edge connector.

[djnzx48]

Don't the DivIDE/DivMMC use this sort of technique? And I'm not sure if it's necessary to stop the CPU either, as long as they don't try to access memory at the same time.

[1024MAK]

Yes, it is possible to request that the Z80 CPU release all the address bus, most of the control lines and all of the data bus.
If the BUSRQ (Bus Request) control line is taken low, once the Z80 CPU completes it’s current instruction, it will release the address bus, the control lines and the data bus and take it’s BUSAK (Bus Acknowledge) line low to signal this.

At this point, external hardware can then freely use the busses to read or write to any memory location.

However, keep in mind that none of the above makes any difference to the ULA, so it will continue to read the screen data from the ‘lower’ RAM, and continue to stop the CPU clock. So any external hardware either has to avoid the ‘lower’ RAM or take notice of the ULA controlling the CPU clock. You also have to take account of the DRAM refresh if stopping the Z80 CPU for too long or provide alternative DRAM refresh cycles (if needed, it very much depends on which memory and how much you are accessing).

Zilog do actually make a DMA controller, and there is a hardware design that uses it.

The DivIDE and DivMMC don’t use DMA, they use the CPU as normal to carry out data transfers.

Mark

[Firefox]

I've always wondered how that gizmo Matthew Smith made himself worked.

In an interview he said he spent the first week of Manic Miner development building an interface for the Spectrum on Veroboard that allowed him to fill the top 32kB of the Spectrum's RAM in a couple of seconds via a cable connected to his TRS-80's parallel port, and then kick the program off. You can even see it in one of the photos of him at work, but sadly not very clearly.

If you grab the Z80 bus via BUSRQ for several seconds will the upper RAM start to lose data due to the lack of refresh?

Does anybody know anything more about it...?

[1024MAK]

As I said, it depends on what you are doing whether you need to perform refresh.

The older 128 cycle / 7 bit refresh DRAM officially needs refreshing every 2ms. [The next generation of DRAM is 256 cycle / 8 bit refresh and only needs refreshing every 4ms].

But if you are constantly reading or writing consecutive memory locations (counting up or down) for at least 128 bytes, then no additional refresh is needed, as every read or write forces the DRAM chips to refresh the addressed row (in the chip) anyway.

However, if you take control of the Z80 busses but don’t access memory, or only a limited number of addresses (less than 128 bytes or non-consecutive memory locations) for more than 2ms, you risk corruption of the data in the upper 32k bytes of RAM.

Note that there are other ways to copy data to/from RAM. Switching in a another ROM and getting the Z80 CPU to run code from this other ROM can achieve the same thing if there is a suitable I/O port for the data transfer.

Mark

[dfzx]

At this point, external hardware can then freely use the busses to read or write to any memory location.

If a bit of hardware took control of the busses, how quickly could it write into memory? Suppose I wanted such a device to write a 32K image into the top 32K of memory. Would it need to write byte by byte at the same sort of speed as the Z80 would, or could it write the data into the RAM in a few, I dunno, nanoseconds or something?

[PROSM]

At this point, external hardware can then freely use the busses to read or write to any memory location.

If a bit of hardware took control of the busses, how quickly could it write into memory? Suppose I wanted such a device to write a 32K image into the top 32K of memory. Would it need to write byte by byte at the same sort of speed as the Z80 would, or could it write the data into the RAM in a few, I dunno, nanoseconds or something?

The access time of the upper RAM chips in a 48K Spectrum is about 150ns. Dividing 2ms by this figure gives a ballpark estimate for how much data could be transferred before the refresh becomes a problem. I know hardly anything about how these RAM chips actually interface with the system (apart from the fact that they use columns and rows), but doing the estimate above gives:

(2*10^-6) / (150*10-9) = 13333.33 bytes per 2ms.

Of course, on the real hardware, the figure is going to be nowhere near that large, since the next address would have to be latched each time, and of course the hardware sending the data would have to be able to match the speed of the transfer. It's much easier and more reliable to just let the Z80 handle the data transfer through an I/O port.

[1024MAK]

If a bit of hardware took control of the busses, how quickly could it write into memory? Suppose I wanted such a device to write a 32K image into the top 32K of memory. Would it need to write byte by byte at the same sort of speed as the Z80 would, or could it write the data into the RAM in a few, I dunno, nanoseconds or something?

Maximum speed of transfer is at the memory bus speed. This is normally controlled by the same clock that the Z80 CPU uses.

The advantage of DMA is there is no need to keep re-reading an instruction every cycle like the Z80 CPU has to do. Instead the parameters are set up in the DMA device/chip by the CPU, then a start instruction is given by the CPU. The DMA device/chip then does a block transfer at the memory bus speed until the end of the operation. So it can be twice as fast as the CPU doing the transfer. At the end, the DMA device/chip returns control back to the CPU.

Mark

[1024MAK]

Links to Zilog documents:
Z84C10 General Description

Z80 CPU Peripherals User Manual

Mark

[Alcoholics Anonymous]

The z80 dma's bus transaction lengths are programmable at 2, 3 or 4 cycles. 3 is "standard timing" which corresponds to typical z80 memory read/write cycles (but not instruction fetch cycles). However using 2 cycle timing is perfectly fine if the external memory and/or io device is fast enough. In 2 cycle timing, the address is stable for something less than 2 cycles and the rd/wr signal is asserted for about 1.5 cycles. Spectrum memory can handle this no problem.

So what does 2-cycle timing mean? One byte can be read and one byte written in 4 cycles, which is four times faster than an LDI instruction or an INI instruction.

The problem with refresh is another thing as mentioned but depending on how the computer's memory is wired up, the act of generating sequential addresses by the dma could also act as refresh. But I don't know if this works in the spectrum. I do know that it's common for datagear and mb02 programs using their dma chips to transfer a display file at least uninterrupted which amounts to 6k and those programs seem to work stably on a spectrum. I don't know if they are depending on likely decay time of the drams being > 2ms (they say 2ms but I know there's a reputation for it being much larger in practice). The mb03 is another interface that is getting a dma and it will have the refresh issue too. The zx next is all sram so its dma can blast away without problems.

Anyway, matthew smith would not have been using a dma for transferring his programs. It's just too complicated - the other end (the trs80 that did the transferring) would not be synchronized with the z80 bus to supply bytes when the dma demanded it. For one thing, the trs80 is too slow.

It would have a been a much simpler io port interface that the spectrum's z80 read with a regular 16T INI instruction. Keep in mind the trs80 was half as fast and you probably need some margin for synchronizing so maybe a transfer every 48T or so. That amounts to sending 32k in 32768*48/70000 = 22.5 frames or about 4-5 seconds.

[Firefox]

I was having a geek out over the "what did Matthew Smith make?" problem on Sunday.
After poring over the Tandy Model III and Spectrum schematics for a while I came to the conclusion that it could probably be done with a couple of daisy-chained counter ICs and some octal tri-state buffers (trying to use components that Matthew could've got from the Maplin catalogue). It wouldn't even really need much in the way of glue logic.
Annoyingly the Model III's printer port doesn't implement any of the nice flag signals in the printer-wards direction like linefeed, so there's no simple way to be able to kick off the transfer directly from the Model III. A sort of "arm" button would be needed to get ready for the transfer, and you'd probably want to reset the Spectrum before that so it's not running out of upper RAM and so you can type "RAND USR 32768" or whatever after the transfer's complete.

*sigh* Now I'm going to have to build one to see if it would work...

Of course, this is just a complete guess. Maybe he had access to an EPROM programmer and just stuck an EPROM and a Z80-PIO on his Veroboard?

[1024MAK]

For transfers in one direction only, from another computer with a parallel printer port to a ZX Spectrum with a Sinclair Interface 2 joystick interface, or any of the Kempston (or compatible) joystick interfaces where the common pin on the joystick port is the ZX Spectrum 0V (GND) you only need a custom cable. Other joystick interfaces may also be suitable. The criteria being that the common pin on the joystick port is the ZX Spectrum 0V (GND). That includes the +2 grey, but not the +2A, the +2B, the +3 or the +3B machines.

On the Spectrum you will need a short bootstrap loader, and on the other computer you will need a custom program to send the data as 4 bit nibbles.

Mark