search

hoglet67 / PiTubeDirect

Bare-metal Raspberry Pi project that attaches to the Acorn TUBE interface and emulates many BBC Micro Co Processors
GNU General Public License v3.0
187 stars 23 forks source link

Consider safe operation when not connected as a Tube #69

Open BigEd opened 4 years ago

BigEd commented 4 years ago

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 commented 4 years ago

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:

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

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 commented 4 years ago

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?