Contended memory with the Z80 in reset

[dfzx]

If I assert the Z80's /RESET pin (via a device on the Spectrum's edge connector) am I guaranteed that memory contention will never happen and the ULA will never slow the clock from 3.5MHz?

[1024MAK]

Contention occurs only when the ULA (or gate array) detects a memory address on the address bus that is in the 'lower' RAM range OR an I/O operation that accesses or which may access the ULA (or gate array).

Once the Z80 has reset, the address on the address bus will be 0x0000 which points to ROM. And hence is not contended. Before that, it is possible for the address bus to have another value, as before the Z80 has completed a normal reset, the state of the address bus is undefined.

It takes a number of clock cycles for the Z80 to complete a normal reset. See also Z80 special reset.

Mark

[dfzx]

Thanks Mark. Unfortunately, in my attempt at brevity, I didn't quite ask the question I wanted to, which was this:

If I assert the Z80's /RESET pin (via a device on the Spectrum's edge connector), and hold that /RESET pin asserted, am I guaranteed that memory contention will never happen and the ULA will never slow the clock from 3.5MHz?

Or putting it a different way, contention can only happen when the Z80 is running, right?

I'm pretty sure I know the answer, and your post seems to confirm it, but I've got a piece of test hardware which is behaving oddly while the Z80 is held in reset and I was after confirmation that it couldn't possibly be contention that's interfering.

[AndyC]

If you hold RESET, won't you face issues with RAM failing to be refreshed?

[berarma]

Thanks Mark. Unfortunately, in my attempt at brevity, I didn't quite ask the question I wanted to, which was this:

If I assert the Z80's /RESET pin (via a device on the Spectrum's edge connector), and hold that /RESET pin asserted, am I guaranteed that memory contention will never happen and the ULA will never slow the clock from 3.5MHz?

Or putting it a different way, contention can only happen when the Z80 is running, right?

I'm pretty sure I know the answer, and your post seems to confirm it, but I've got a piece of test hardware which is behaving oddly while the Z80 is held in reset and I was after confirmation that it couldn't possibly be contention that's interfering.

Contention happens only when the CPU is accessing the lower RAM. If the Z80 is held in a reset state then it won't access RAM and there would be no contention.

[AndyC]

Contention happens only when the CPU is accessing the lower RAM. If the Z80 is held in a reset state then it won't access RAM and there would be no contention.

If another device puts an address on the bus in order to access lower RAM, that surely will cause contention (although said device will need to be paying attention to the signals from the ULA that it is accessing the bus or you'll just get snow on screen and garbage reads) right? It's not the Z80 that cares, it's the ULA, you can't just remove the issue by bypassing the Z80.

Although, as I said, I'd have thought the failure to refresh RAM, which will cause values in memory to degrade, might be a bigger problem if that's what you're trying to do.

[1024MAK]

Yes, a Z80 held in reset will not refresh the DRAM. This does not matter for the 'lower' DRAM, as only the ULA refreshes this. But would affect the 'upper' DRAM.

And yes, if an external device puts an address on the address bus within the address range of the 'lower' DRAM, there will be a an address bus and maybe a data bus clash as the ULA stops the Z80 clock, but (depending on the design) may not be able to control the external device.

Of course, if you do want to take control of the system, you ate better off using the /BUSREQ control pin rather than the /RESET pin.

Mark

[berarma]

If another device puts an address on the bus in order to access lower RAM, that surely will cause contention (although said device will need to be paying attention to the signals from the ULA that it is accessing the bus or you'll just get snow on screen and garbage reads) right? It's not the Z80 that cares, it's the ULA, you can't just remove the issue by bypassing the Z80.

Although, as I said, I'd have thought the failure to refresh RAM, which will cause values in memory to degrade, might be a bigger problem if that's what you're trying to do.

The ULA causes contention on the Z80 by holding its clock. OP didn't give more details about what is connected to the computer. If there's something else acting like a CPU and using the same clock, yes, contention might happen. If something unknown is connected to the bus then everything is possible.

The failure to refresh the RAM would be for the upper RAM only. And again, if something is connected to the bus that replaces the Z80 in all its functions, it might still be refreshed.

Without knowing more details about what OP is doing I don't think my answer is incorrect.

[dfzx]

Many thanks for all the help.

I'm using an RP2040 attached to the edge connector to sample signals and understand what's going on with the CLK line. Nothing is taking over the machine, and the Spectrum isn't expected to be doing anything useful while I conduct these experiments. I was seeing odd values for the CLK frequency when I was holding /RESET, which made me wonder if I was misunderstanding contention any maybe it was getting in the way.

I'd been puzzling over this since the beginning of December, and it occurred to me what was going on about an hour after asking for help here. It turned out to be a bug in my RP2040 PIO code.

[RST#08]

Page 22 here (and elsewhere) may also be of value if you're experimenting with the edge connector:
https://archive.org/details/bitsavers_z ... /mode/2up

[zx64]

When CPU is in reset, it's not driving address lines, so they are floating. Floating inputs change between 0 and 1 randomly.

Try to pull A15 up with 10K resistor

[1024MAK]

When CPU is in reset, it's not driving address lines, so they are floating. Floating inputs change between 0 and 1 randomly.

Actually, when the address bus is not being actively driven, depending on what is connected to the address bus (board issue, type of chips fitted, any expansions fitted), the address lines may float towards either 0V/GND or (if 74 or 74LS series logic is in use) towards +5V/VCC. But this will only be a weak effect, so it will take significantly longer than a clock cycle if indeed the voltage actually makes it to a defined logic level. In the meantime, stray capacitance will tend to "hold" the last value.

Mark

[zx64]

On the other hand, there is EMI from nearby traces, which will drive floating lines as well.

[1024MAK]

Don't know if these videos helps...





Mark

[dfzx]

That's really interesting, I've never heard of a CPU NOP tester...