Consider safe operation when not connected as a Tube

[BigEd]

In the case where a Pi is running PiTubeDirect but not connected to a host, but to something else, it might be an advantage not to set any pins as outputs.

A suggestion: watch the databus for activity, in a small tight loop, and only exit when enough activity has occurred to be convincing. Possibly, also look for one or two 6502 opcodes, if it's certain that all MOS versions will contain them. (But one day PiTubeDirect might be attached to a Z80 or 6809 and the details will differ.) Likewise, look for activity on the address pins and the clock.

There are perhaps some hundreds of clock cycles before PiTubeDirect must respond as a Tube chip.

In any alternative situation, such as where the Pi is installed in a Spectrum Next, it may be that at least one of the inputs being monitored will be inactive, and the main Tube emulation loop will never start, and so none of the Pi's pins will be driven. That avoids trouble if both the Pi and the host are driving the same pin.

[hoglet67]

Thinking this through a bit more....

Snooping on the data bus for 6502 opcodes would only work on the Model B, not the Master.

The only outputs are D0..7, and these are only driven when:

• Phi (GPIO7) = 1 and NTUBE (GPIO17) = 0 and RnW (GPIO18) = 1

On the Spec Next, those lines are used as follows:

• GPIO 7 - SPI CE1 (Next output, when SPI enabled)
• GPIO 17 - unused (probably undriven)
• GPIO 18 - I2S Audio PCM_CLK (Next output, when I2C master enabled, Next input, when I2C slive enabled)

So, in PiTubeDirect if we were to enable a weak pullup on NTUBE, we might probably be OK.

However, if there were any activity on NTUBE, it's possible the GPU code would get stuck in the Phi=1 state (waiting the falling edge of Phi) and in this state it would be driving the data bus forever.

There are two more mitigating factors....

D7..0 use GPIO 25/24/23/22/11/10/9/8.

Of these, the only overlap with Spec Next use is with the SPI port:

The current Spec Next Accelerator code doesn't use the SPI port.

If it is enabled, the Spex Next core acts as an SPI Master only, and uses the signals as follows:
GPIO 7 - CE1 (Next output)
GPIO 8 - CE0 (Next output)
GPIO 9 - MISO (Next input)
GPIO 10 - MOSI (Next output)
GPIO 11 - SCLK (Next output)

So a conflct is possible, if the SPI function is ever enabled.

Finally, in the .ucf file of the Spec Next core, the DRIVE on all the Pi signals is set to 2mA.. This value is approximate (i.e. -50%/+100%) but still, that's quite a low value. So even if a conflict occurss on all 8 data signals, a max of say 32mA will flow. This is unlikely to cause any damage to the Xilinx or the Pi.

Dave

[BigEd]

It's good that there are tactics which will (probably) be safe with the present pin assignments on the Next.

Even so! And good point about the Master's unconnected databus.

Can we for example watch for a few tens of transitions on the clock and the RnW? And at the same time, verify that there are no transitions on nTube, which should stay high?

[BigEd]

Are there any updated observations on the SpecNext situation, now that there are two versions of Next with different FPGAs, and there are both Next and QL cores which might run on the Next?

[hoglet67]

Yes, it probably is worth reviewing the current situation.

There are two scenarios to consider:

1. Beeb FPGA <===> Spec Next Pi

During startup BeebFPGA probes for PiTubeDirect by reading the Tube Data Bus with nTUBE de-selected. In this scenatio, weak pullups in PiTubeDirect place the value 0x55 on the data bus. If the Spec Next Pi firmware is running, this value will not be seen, and BeebFPGA disables the external tube (all tube outputs become high impedance)

I'm pretty happy with this solution, as it doesn't need a custom build of PiTubeDirect.

2. SpecNext FPGA <===> PiTubeDirect

As stated earlier in the thread:

The only outputs are from PiTubeDirect are Tube D0..7, and these are only driven when:

Phi (GPIO7) = 1 and NTUBE (GPIO17) = 0 and RnW (GPIO18) = 1

On the Spec Next, those lines are used as follows:

GPIO 7 - SPI CE1 (Next output, when SPI enabled)
GPIO 17 - unused (probably undriven)
GPIO 18 - I2S Audio PCM_CLK (Next output, when I2C master enabled, Next input, when I2C slive enabled)

PiTubeDirect enables a weak pullup on nTUBE (GPIO17) which should prevent it ever driving the data bus,

It's definitely worth reviewing the current use of these signals by the SpecNext core, esp. GPIO17

[Xalior]

GPIO17 is currently left undriven, at boottime by the ZXNext core - with no plans to change this default at this time.
GPIO18 is undriven by default, at boottime by the ZXNext core - used as I2S CLK sink (Next input) during TZX loading.

Neither of these pins can be prevented, of course, by user apps on the Next changing the modes -- but without user interactions / at default boot these pins should remain safe as per current configuration.

Hope that helps, Dave :)

-Dx