I had an idea today for a simple RS-485 based network with auto-configuration and hot-swap, and I thought I'd share it to gather feedback. The network is a half-duplex, single-master, multi-slave network in a daisy-chain topology. See attached PDF for a diagram. I don't have a name for it yet, but just so we have something succinct to refer to it by I shall tentatively christen it "SCN-485" (for Self-Configuring Network, rs-485).

Whilst not specific to 6502-based systems, I envisage the simple networks this would create could work well for such systems. A single SC28L91 UART provides all the necessary I/O - the only additional components required (ignoring miscellanious Rs & Cs) is an RS-485 transceiver, a buffer and a 100k resistor. The interconnect between devices requires 4 wires, or 5 if the master provides power to the slaves.

I won't got into detail about the on-wire protocol for the main RS-485 bus, principally because I haven't finished writing it all out, but it doesn't really matter exactly how it works provided that:
1. The slaves only "speak" when instructed to do so by the master.
2. The master addresses slaves by assigned addresses.
3. The master can send a packet containing a new address assignment without addressing a specific slave (e.g. a reserved address for "broadcast").
4. The ability for the master to ping a slave to solicit a response.

When a slave is added to the network, either by connection or being powered-up, it does not know what address is should respond to and will idle on the bus until it gets an address assigned to it by the master.

As you can see from the diagram, its a fairly standard RS-485 network, aside from the addition of the ARQ signal, which stands for "Address Request". A slave that is without an address for any reason will assert its ARQ_OUT signal, regardless of anything else. If any upstream slaves receive an ARQ on their ARQ_IN signal, they will assert their ARQ_OUT in turn - in this way any slave requesting an ARQ will propagate to the master's ARQ_IN. Note that multiple slaves can require an ARQ at the same time without conflict.

When the master receives an ARQ, it sends a special Address Assignment packet out to the bus, and any slave looking to receive an address will be listening for this special packet. However, only the requesting slave whose ARQ_IN is not asserted (or floating - I'll come back to this) will actually save the address. That slave will deassert their ARQ_OUT, and will now respond to that address. (This has the effect that the farthest downstream slave that still needs an address is the one that actually receives it.) If other slaves still need an address, they keep their ARQ_OUT asserted and, after a short timeout to allow for propagation through the slaves, if the master still sees an ARQ it will send out another Address Assignment. This process repeats until all slaves have an address and the master's ARQ_IN is no longer asserted.

Note that the timeout period between Address Assignments can still be used to communicate with any slaves that already have an assigned address. The amount of time between Address Assignments is flexible and could be configured based on user needs.

Once a slave has been assigned an address, the master can then interrogate it directly to learn more about what kind of device it is and load the appropriate software.

The ARQ_FSP signal is used to determine if the ARQ_IN signal is being driven, or is floating (and thus not connected to anything). This is done by setting ARQ_FSP to either a HIGH or LOW, measuring ARQ_IN, inverting ARQ_FSP and measuring ARQ_IN again. If the read values for ARQ_IN paralled ARQ_FSP then the input is floating and not connected to a downstream slave; if ARQ_IN maintained a single value regardless of ARQ_FSP then it is being actively driven by a downstream slave.

On the master, being able to determine that the ARQ_IN is floating allows the master to know there are no slaves connected to the port, and it can put the port into a low-power state (if supported).

On slaves, if they detect that the ARQ_IN is floating, then they should enable their internal bus termination network using the TE signal. This means that correct termination for the bus is also auto-configured, in addition to addresses.

Finally, the master should track which slave addresses are in use. If the master hasn't required a response from a slave within a certain timeout, it should send a noop/ping packet to that slave to solicit a response. If the master does not receive a response from a slave it has assigned an address to, it can surmise the slave has been removed from the network and free the address for future assignment. This part is flexible: the timeouts and number of retries could be configured based on user needs.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

The 28L91 is only given as an example of a suitable UART that doesn't require a seperate I/O chip to drive the additional signals that SCN-485 needs. Most UARTs would suffice and, if they lacked sufficient built in I/O, you could use a VIA for the additional signals.

I am aware of the need for termination, and this has been addressed in both the PDF and the text of the first post. That being said the scheme as it is wouldn't put the auto-termination right at the end, there would be a small stub in the final slave between the transceiver and the unused input connector. I am unsure how much effect such a stub would have in practice - we're probably talking an inch or less. I wouldn't envision using this network over vast distances, but it would be nice if it could be that robust. If the stub would be a problem, it could be resolved by not relying on the transceiver's in-built termination provision - mainly I was just trying to keep the part count down.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Econet, as used on the BBC Micro in the early 80's is worth a look at - there are still folks today maintaining Econet networks on their BBC Micros, Acorn ARCs, etc. There was even a Linux driver for it at one time. (Still is in older Kernels)

In essence, it was a multi-drop bus with synchronous data and clock. RS-422. There were bridges and file servers.

There was a network file server as well as processor to processor communications. Lots of schools were fitted out with it back then. The diskless workstation was a thing.

I used it extensively in some factory automation projects I was working on/studying at the time. Speed was essentially determined by the length (and often quality) of the wiring, but 250Kb/sec wasn't uncommon.

See here for more details: https://en.wikipedia.org/wiki/Econet

But sadly, like many old things, the Motorola MC68B54 IC used to control it is now hard to find unless you manage to get a lab-full of BBC Micros with them already fitted. The BBC Micro motherboard had space for them and you could either buy the Beebs with it fitted or not.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/