- The 75159 is notionally still 'in production' with TI, but if you actually buy some you find that they are old stock. It seems likely that no more will ever be made and they will eventually become unavailable (as has already happened, ironically to the equivalent part used on later Acorn products, 26LS30).
- The parts are somewhat expensive
- PCB area consumed is not small.
- A regulated 5V power rail is needed, often not already present on modern designs (even if USB powered, USB Vbus may be as low as 4.4V f plugged into a passive hub).
My objectives are:
- 100% compatibility with classic Econet
- 3.3V power supply
- Cheap and easily-available parts, particularly with respect to JLCPCB availability/pricing
- Given the modern requirement for primarily 'table top' ad-hoc networks, providing on-board clock/terminators is desirable.
- Reasonably low power.
Line drivers/receivers
This is the easy part. Econet voltage levels have always been RS-422, just with a higher input impedance to permit a larger number of stations than RS-422's 32. There's lots of RS-422 transceiver chips around; older ones will have the 32-station limit, but there are plenty available that are "1/4 load" or "1/8 load" compared to traditional RS-422 and so support up to 256 stations. And there are 3V3 powered versions: they use FET output stages to achieve equivalent voltage levels to traditional 5V parts with bipolar output stages.
Lots of parts to choose from, though some are expensive. I've settled on the 65HVD75: these are reasonably cheap (about 50p for the genuine TI parts, or even less for the Chinese knock-offs with the same part number). They are a "3/20 load", so not quite as good as the "1/8 load" parts you can get, but that still allows up to 200 stations per network which I consider sufficient.
I have tested these and they work well, giving output levels indistinguishable from classic parts.
Each device gives one driver and one receiver, so two needed in total and that gives you a driver for a clock output "for free". They have separate pins for Tx/Rx, but on this particular design I'm using an RP2040 so a single pin on there can be either a PWM output to drive the clock or an input if this station isn't the clock source - and the Rx logic can read the pin state either way. So I have the two linked together for CLK_IO, where other designs might want to split them into CLK_IN and CLK_OUT.
Collision detection
Unfortunately, the standard chips don't give you CD. Some people believe CD isn't needed, in which case the two 65HVD75 chips are all you need for the complete interface. However, I believe CD is somewhat important - though it's less necessary to be 100% equivalent to the original since the original wasn't always fitted and (I suspect) wasn't always completely successful in detecting collisions. Something that works well in typical conditions is acceptable, even if it diverges from the original (maybe better, maybe worse) in extreme conditions. This opens up the option for something that works in a different way.
The traditional circuit is voltage-based - a collision is detected if the voltage on the line is smaller than the expected level due to two drivers driving in opposite directions. This circuit is current-based - a collision is detected if the line driver draws more current due to 'fighting' with another line driver rather than the expected current driving into the termination. As a historical note, Lawrence Hardwick tells me that the original 'drawn on a napkin over dinner' Econet suggestion from Andy Hopper was current based, but when he (Lawrence) came to implement it the voltage approach turned out to be easier/cheaper to get to work.
In principle the voltage-based circuit gives you more information - when not transmitting you can tell if the line is driven actively to the idle state or not; this was unsuccessfully used in Econet V2, but all current Econet (since 1982) only uses the CD when transmitting and so this is not a problem with the current-based approach.
I have prototyped an earlier version of this and the principle is sound, but there are some snags. You would think naively that a line driver driving into a constant termination would draw a constant current (perhaps with some spikes at the bit boundaries), and driving into a collision would be much higher than that, so you could smooth off the spikes and use a fixed threshold value: above the threshold is collision, below is normal. Or just look for ripple: during a collision, the current will be unusually low when both stations are driving the same bit value and unusually high when driving opposite values.
Unfortunately, it's not that simple: the normal value varies significantly between '1' and '0' bits due to the asymmetric termination, and the absolute value will vary depending on the exact type of termination (classic Acorn, SJ, other modern designs), how many terminators there are, and cable type/length. A single threshold value would probably work a bit - you'd have to make it fairly high to avoid false triggering on a short network with 100R terminations, and it would then fail on a long network with SJ terminators or a short network with only one terminator (BTW, I doubt that the classic circuit reliably detects collisions between distant stations on a long network).
So, the circuit here is straightforward with a sense resistor in the line driver power (1R is acceptably small against the 50R expected load on the output of two cables at 100R impedance, each terminated 100R). That's then amplified to give a voltage inversely proportional to the current, and I've hedged my bets on thresholding it. I have a simple comparator, but the reference is a voltage derived from a PWM output on the micro, and the raw value is also fed to an ADC input. So the software can simply set a fixed threshold value, or software can do calibration at startup (or on suspicious results) and set a variable threshold value, or software can read the ADC continuously during Tx of the scout packet and apply more complex algorithms.
More testing/software work is needed here, but I am fairly confident this will ultimately yield good results.
I've cheated somewhat to save cost: originally I had a nice current sense amp chip here (INA381, providing both the current sense and the threshold comparator), but instead I've gone for a super-cheap opamp (~10p for 4 channels) which only works because I happen to have a nominal 5V rail to power it from. However, it just needs a bit of headroom above 3V3 so should still be OK if that '5V' is actually a Vbus at 4.4V. This is partly driven by wanting some opamps for my, arguably overdesigned, termination circuit; maybe for the plain station circuit the extra cost of the INA381 is worth it.
Clock and terminator
BITD, I was strongly against on-board clock/terminator arrangements, especially that of the FileStore with it's "automagic" configuration that inevitably resulted in it turning on when you didn't want it and stuffing up the network. But that was in the era of multi-room, permanently installed networks where the extra cost of dedicated clock and terminator was trivial and the convenience of knowing that there was always precisely one clock, permanently powered, was invaluable. Nowadays, table-top networks with ad-hoc combinations of stations predominate, and it seems sensible to have a clock/terminator in every station - just make sure they are clearly and explicitly enabled so you can tell what is going on!
Here, I've gone for software enable/disable, with LEDs to indicate the state and avoid FileStore-style swearing. I'm still not sure whether that's actually better than doing it with DIP switches. There always needs to be a software configuration for the clock speed/mark-space ratio, and the software needs to know that it's enabled if saving a pin by making the clock pin bidirectional (originally on this design the enable pins were on an I/O expander and so the saving of one precious RP2040 GPIO pin was still realised even though it takes an extra pin for the enable; as it happens, that's no longer true on this particular board). So the DIP-switch isn't that much of a saving, and especially so if you want to make it just one switch rather than several.
Providing the offset clock needed to drive SJ-style phantom-powered terminators is difficult, especially using the driver that 'comes for free' in the clock receiver, and I consider that this design is strictly intended to clock/terminate tabletop networks. If you have a network large enough to have remote, standalone, terminators then you should use a dedicated clock too (and Beebmaster will happily sell you one); conversely, if it's a tabletop network then you can clock and terminate in the same station if necessary.
The clock part of this is obvious - just enable the driver and set up a PWM in the micro to generate the appropriate waveform.
For termination, what you are aiming to achieve is a 100R AC impedance across the lines for both clock and data, plus a DC voltage offset between the two data lines of about 0.4V. All the existing circuits have some drawbacks:
- The very original Acorn design used germanium diodes to create the offset voltage, and capacitors to provide short-circuit that at AC, with the 100R then being provided by a pair of 47R series resistors. This has the disadvantage that the capacitors (if not infinitely large) can get charged up by a long string of zero bits in a packet and take time to settle back to the right voltage at the end of the packet. Also, germanium diodes are not ideal in a modern design.
- The SJ terminator design (copied in later Acorn terminators) uses a network of resistors and assumes that the power supply is zero impedance (supplemented in the actual phantom-powered terminators by a capacitor). This suffers less from the 'reverse charging' problem, but it actually provides too high a terminating impedance (I can't remember why that was chosen, but I suspect there simply isn't enough power available from the clock to drive the correct impedance). While this evidently worked in practice, I don't like implementing something that's 'wrong' in a new design.
- A version similar to the SJ circuit but locally powered and with the resistor values scaled to give the right impedance (100R) should be satisfactory (I believe some of Ken Lowe's designs do this). However, that consumes quite a lot of power: 3.3V and a 470R-120R-470R string gives about the right impedance and voltage, but consumes 3mA whether in use or not.
That's straightforward enough, but then it needs turning on and off - needing to apply no load even if the applied clock/data has an offset to it (eg. from an SJ clock. I used an analogue switch chip on an earlier design which worked OK, but is only legitimate if the pin voltages are within the power rails - which they might not be, particularly with an SJ clock (typically 5.5V if terminated, could be as much as 7V unloaded). So I've gone for simple FETs. Trouble then is that the gate voltage to turn them on needs to be threshold above the highest possible applied voltage, so 3.3V is not nearly enough; even doubling that for 6V is still not enough even with expensive low-threshold FETs. Final option is cheap 2N7002 FETs and a diode tripler to generate the (very low current) 9V to turn them on. The tripler is driven by the same PWM that sets the CD threshold level - could have used any source of pulses here, such as the econet clock itself.
I'm sure this will all work, and is in fact pretty cheap, but looking at it again after a year I'm not sure I can justify the complexity.
so that can wait till the weekend.