Yes. This is another reason for using the CONFIG signal.

Remember that even GPIB addressed this issue by using secondary addresses too!

The way I see it, when in CONFIG mode, a device responds to the configuration command set. This means:

* It responds to commands to query the kind of device it is, and its capabilities. This includes the number of secondary addresses.

* It responds to commands to select a specific secondary address for "normal" I/O operations.

* It responds to interrupt management and query commands.

* If the device is a switch or an expander, it must also respond to commands for asserting and negating the child bus' CONFIG signal too. This allows the host system to probe nested buses too, albeit at a slight performance loss.

Hmm...perhaps a better name for the CONFIG signal is ADMIN, for "administration" mode, since it's clear its function extends beyond that of simple auto-detection and configuration.



Hey, now, I'd like this to remain open, so us hobbiests can continue to enjoy its benefits too! I would prefer some standard to be set forth by a consortium that one doesn't need to pay a cent to be a member of, unlike PCI. (Or, payment is just enough to cover operating expenses. $1000 per year or more for places like PCI-SIG and USB-SIG are OUTRAGEOUS.)



I predict a minimum of two ICs: a 3-state buffer for gating the upstream bus pins onto the sub-bus ports, and a MCU to handle the upstream ADMIN commands.



GOOD POINT, I hadn't thought of that.

_________________
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?

_________________
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?

Sorry -- I haven't had time to draw up my idea in schematic form since today was my last day working for my (now former) employer. I should have more time to draw up some schematics to make things a tad bit clearer.





This sounds reasonable. I never thought of using the switch idea to replace the ADMIN line. The overhead is that now EVERY packet has to have that prefix command/address byte, but that would have happened anyway at some level. And, it's a lot faster than having to command the admin phase to change sub-addresses, then switch over to the normal device (1 byte overhead replaces, minimum, 2 or 3, plus the time taken to assert and negate the ADMIN line).



I LIKE this. Again, I never thought of this, but it makes perfect sense. This isn't too far from GPIB's overheads either, where every transaction on the bus was prefaced with ATN asserted and the appropriate TALK/LISTEN commands. In some senses, it's actually faster than GPIB.



I'm assuming pin 1 is at the top of the list (e.g., pin 2 is CS1\)? Also, I'm assuming CS1 is the actual device select line?



Yeah, well, I'm also talking about the 80-pin IDE cables, not the 40-pins. I haven't pulled any 80-pin IDE IDCs apart to see how the interleaved grounds work. I think it might be necessary to do this before making this decision, to see how it'll all piece together.

Also, it looks like the characteristic impedance for such a cable is close to 260 ohms (if used balanced) or 130 ohms unbalanced.



Yeah, this seems reasonable. If changes need to be made, though, it's probably better to use a different connector or bus protocol completely anyway. I mean, 20 pins is already an awful lot!

Garth, check out this site:

http://www.interfacebus.com/Design_Connector_IDE.html

This lists the various IDE cables and bus speeds achieved on them. Even the 40-pin cable is able to transfer data at 33MBps, which in terms of serial translates to 16Mbps throughput (remember that IDE is a parallel 16-bit bus). Since you'll be bit-banging, even a low-quality ribbon cable would work well.

Also, and in opposition to the Amphenol website I found on these cables, it claims that bus impedance is close to 90 ohms unbalanced. So, a 100-ohm termination wouldn't create too much SWR on the lines, and that means less emissions in the form of reflections.

_________________
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?

At this point, I'm looking at average costs for 20-pin IDC connectors, and they appear to range from $5 to $7 in singles. This means that it'll cost $10 to $15 or so minimum investment, just for the connectors.

Are there any cheaper that you're aware of? I looked at both DigiKey and Mouser.

Also, will the signalling be 3.3V?

WAIT...

If there is no ADMIN pin, then that necessarily means that all peripherals will require a switch uC up front. Otherwise, the connection of a raw SPI chip to the bus may produce abnormal behavior when attempting to probe it. Thus, all devices attached to the bus must have some amount of local intelligence.

_________________
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?

So, in other words, your system would contain a configuration file that basically says, "Probe around these devices listed herein, as I already know they are too ignorant to respond correctly." I hadn't thought of that either.

As the Kestrel's boot device will itself appear on the bus, and can appear anywhere on it, the Kestrel will require all peripherals to have at least an auto-configuration MCU on it. At maybe a buck a pop, I don't think this is a terrible burden for me.

_________________
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?

You asked for comments, ... :-)

I think it seems to fit your requirements, and that is good, as it seems you are the first to use/build it.

I like the addition of a regulated +5V line, so I could use simple devices without an own regulator. If I would implement the bus, I would probably go with a single original select line and define the first "hub" on the controller board, so that the cable still has all your select lines.

For my requirements (remember, mostly peer-to-peer and half-duplex between say a C64 and a PET) I think I will make another connector, with additional handshake, maybe something like a cross-over cable or so. I'll have to see when I get to it - which can be a while from now...

Thanks for the discussion and your comments anyway
André

It is going to be tough enough for me to provide +12V. It absolutely is not possible for me to provide -12V as well. The power supply I am planning on powering it with is a Cobalt RAQ 2 power supply, which only provides +5V, +12V, and ground.

_________________
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?

Correct. The DCE on each side could be an Ethernet interface, for example. I'm also interested in freespace optical networking as an alternative to wifi too.



Well, as you recall, that's precisely what we were trying to engineer via the SS-22 interface. I tried taking your SS-22 idea and implementing it as a serial loop or as a bi-directional bus architecture. It would have worked, but its resource demands would have been relatively high (you MUST have 2 VIAs to implement it, for example, and unless you were willing to bit-bang, you could only use VIAs to interface to it).

Peer-to-peer means that each side is both a client and a server, in terms of the roles it provides to other nodes on the link. It strictly speaking isn't topology dependent (e.g., the Internet is architecturally a star network; yet, P2P networks exist all over the place on it). However, peer to peer got its start back in the LANtastic days over 10-base-2 Ethernet, which most definitely is a bus architecture.



I'm not very experienced in this area, so I have very mixed feelings. But, to me, I think it's a bad idea for two reasons.

1) To keep costs of the controller down, I think it would be wise to not stipulate that you must have +12, -12, +5, and -5V on the bus, regulated or otherwise. Power supplies can be had commercially that can supply these, but from what I've seen, at significant cost. It also adds mass to the circuit as a whole, which means it's not nearly as portable. It also consumes more power to provide these voltage rails.

2) I fear that taking true grounds away in place of supply rails will reduce its ability to function correctly. Ripple will be introduced which regulators may not be able to compensate fully for. In every circuit I've seen where this may be a problem, a clear distinction between types of grounds are provided (e.g., analog grounds versus digital).

3) If Kestrel provides a true ground on pins you decide to use -12V or -5V on, what happens if I try to insert one of your peripherals into my bus implementation? Or, vice versa? Will damage come to the peripheral or to the bus?

Basically something like that. My requirement is that I have a single shift register on each end only, so I can not require the device (and controller) to send and receive at the same time. Rather the controller would signal the direction and both, controller and device would use this line to determine their direction.

Note to the SS22-interface: I would use an electronic switch for the 6522 so I could use the same single shift register for sending and receiving.



Yes, and that is what I wanted to avoid. But as I said - you don't have the multi-controller requirement. I basically have, and that is the reason that for this peer-to-peer connection I want to stick to peer-to-peer and not a bus. Arbitrating between two controllers is easier than between multiple controllers.



You're years ahead anyway, so just stick with it! i don't want to keep you from it until I got my stuff sorted out, which may take a while just as well :-)

André