DMA - no!

[sirmorris]

It feels like It's never going to work. My huge plan to revolutionise the zx81 storage arena. In tatters

Bear with me on this one, it might be a little technical - and there will be questions

A while ago I did a little playing with a microcontroller hooked up to the zx81's rear port with the intention of performing some DMA. Direct Memory Access - forcing the z80 off the bus so an external controller can write to the RAM directly. The 1st stage worked - I could take the z80 off the bus by signalling it on one of its control lines - 'BUSRQ' and have it return to normal business when required.

Unfortunately I had to stop playing at that point and I've only just got back into the playground. Here's the new controller board hooked up to the zeddy and ready for action. Type LOAD"" (simply a way of putting the machine in a FAST-mode loop without writing any code - It's got nothing to do with the DMA) and hit the button...

DMACONTROLLER.JPG

(102.48 KiB) Downloaded 6500 times

CRASH!

Pretty much every time I've examined the bus activity during the DMA cycle and this is what I get:

a.JPG

(70.59 KiB) Downloaded 6504 times

starting from the top - with /busrq - we see it get asserted. The signals here are all active when low.
/busak follows. This is the z80 confirming that it's sleeping. There is a period of silence in the trace and then you see little blips where the /wr line is asserted. This should poke values into RAM. In the time between blips things like address line setup happens. After 8 bytes have been sent /busrq is de-asserted, or released. /busak follows and the z80 continues its business. For once. Mostly it crashes :*(

One thing I wasn't expecting to see is blips on the /rd line. _I'm_ not doing that, and the timings of the signal are too close to the write pulses and too even in width to be coincidence. Either I have a short circuit somewhere or the ULA is interfering... Anyone know what the ULA does when /busq is asserted?? Could /rd be floating? I'd expect to see a delay if it was capacitive coupling. Should a DMA controller pull /rd low? Anything else?

It looks like I'll need to actively drive /mreq too - I have a 'wilf' barebones 32k mod and that requires /mreq to be asserted in order to enable the decoder. I've just thought of that as I've been typing.

All-in-all this is turning out to be quite a lot more hassle than I thought

Fun though.

[Mike]

Bear with me here, I'm a little rusty on these things...

Correct me if I'm wrong, but the BUSRQ and BUSAK lines are not connected to the ULA.

My guess is that when the Z80 releases the bus, you're not asserting all the relevant signals and the ULA thinks something is going on that isn't... Without the Z80 controling things wouldn't you have to control at least MREQ, IOREQ, WR & RD ? Maybe even the M1 line too, since that is connected to the ULA.

Mike

[Mike]

I was pondering this at work today, while fighting with yet another exchange server that had fallen over...

Are you using Static or Dynamic RAM? If Dynamic, how is the memory getting refreshed?

Mike

[siggi]

Perhaps you could describe your hardware a little bit more (which lines are driven by your hardware during DMA)?

Wilf's DMA solution seemed to work:

http://www.user.dccnet.com/wrigter/index_files/HS4.htm

HTH Siggi

[sirmorris]

Hi all, thanks for the contributions!

Presently I'm only driving the control lines I need for ensuring that my internal RAM expansion is enabled at the right time - /MREQ.

Having looked at Wilf's solution - thanks Siggi - I can see you're right Mike. I'll need to control /M1, /IORQ, /MREQ, /RD and /WR ... I suppose when the Z80 tristates these will float. However the fact that the ULA isn't taking /BUSRQ still worries me. Wilf's solution seems to use some neat control logic - perhaps I need to implement something like this.

Another option I'm considering is to have the microcontroller hold the zx81 in reset whilst transferring data. The ROM startup doesn't touch RAM at 8K so stuffing that should survive a warm start. I wonder if the same issues of control line state would occur though?

C

[siggi]

'll need to control /M1, /IORQ, /MREQ, /RD and /WR ... I suppose when the Z80 tristates these will float.

Yes, you have to drive ALL Z80 outputs, which are not fixed to a specific level using pullup- or pulldown resitors (e. g. also /HALT and /RFSH).

DMA state is the only legal mode, where you could do this. During RESET the Z80 does nothing, but it's outputs are AFAIK still driving the bus.

Siggi

[sirmorris]

Aah ok.

@Mike - This will be an add-on for static ram only. It will have on-board 32k chip with the option to disable this for pre-expanded machines. I won't be supporting 16k ram-packs.

@Siggi - okeydokey - /BUSRQ it is I'll hack against the board tonight and see if I can get things going. I started a redesign with EPROM on board but it's turning into an address-bus nightmare

[siggi]

I started a redesign with EPROM on board but it's turning into an address-bus nightmare

?
You don't need to fetch the address lines of the ROM to use an external EPROM for rom patches: use the normal address lines at the edge connector and enable the external EPROM only during /RD cycles (not during /RFSH). Then the character generator of the ROM is still used during display (and cannot be replaced by external EPROM), but the code can be read from external EPROM.

Again see at Wilf's pages ..

Siggi

[sirmorris]

Siggi - I sent you an email last night to you at the zx81 dot de address. Do you check this one still?

It shows the address decoding for external ROM. The decoder is enabled with /rfsh so the memory isn't used for character generation.

I have a decoder for RAM too and that's where my knowledge fails me - I want to combine the internal rom inhibit signals but don't know how

That might be irrelevant if I can get the DMA working though.

[siggi]

Siggi - I sent you an email last night to you at the zx81 dot de address. Do you check this one still?

Yes, but nothing arrived. I have to check the spam filters ...

It shows the address decoding for external ROM. The decoder is enabled with /rfsh so the memory isn't used for character generation.

I have a decoder for RAM too and that's where my knowledge fails me - I want to combine the internal rom inhibit signals but don't know how

I use an address decoder for my EEPROM similar to the 64KINTRAM.gif (64K-ram with rom-patch) here:

viewtopic.php?t=244#p1729

When the jumper between /RD and HC251/pin4 is closed, the EEPROM is enabled at 0K (only during read cycles, not during refresh) and the internal ROM disabled (/ROMCS is pulled high). Works fine ...

Siggi