firstname.lastname@example.org wrote: > Hallo Andre, > > About the 65816: yes, I did use a board to connect the 65816 to the 8032 > but I had to rewire it a little bit. In fact it is the card I used for the > VIC20. I'll give you the details later. That would be nice. Somewhere in my head is the idea of building a 65816 board for my CS/A65, with 512k on-board fast RAM, using all the I/O on the (slower) bus. But that's at least a year ahead... :-( > I want to react on your "Network page": > > > The asynchrounous communication will be derived from the RS232 > > specification, in that normal UART 16550 or ACIA 6551 chips can be used. > > Very nice. (I always used the 8250 and 16450 with 65xx-systems) The answer to the other mail: Yes, there are things like inverted IRQ and Reset lines, and /WR & /RD instead of /CS and R/-W. For schematics how to use a 16550 with a 6502 see my homepage (The Gecko computer as well as the CS/A65 has one, and I have a 16550 interface for the C64 as well - much better than this 6551 stuff) > > The physical layer could be derived from the RS485 specifications. > > The original RS485 specification uses a terminated bus, and allows > > one master to send at any time only. Otherwise drivers could be damaged. > > Can you give me in a few lines some more specifications, please? How many > lines does it use? Why can the drivers be damaged? What ICs does it use? I was/am still looking for drivers. The problem is that pure RS485 does not allow any two or more drivers to be active at the same time. > > > With tokens, the bus itself has a kind of global "state", which is > > represented by the token. > > What exactly is a token in this case, a byte to be sent around, a level of > the line(s)? It is a logical state, represented by a certain type of packet(?). Only the node with the token is allowed to send on the bus. If it sends the token (special control packet) to the next node, then the next node is the only one that is allowed to send. Prohibits bus collision (which is forbidden in RS485 anyway, so this is one way to consider). Originally from IBM (competitor to Ethernet), and originally a real (i.e. electrically) ring. Imagine what happens if a node fails.... Now there are protocols that have a bus and still use token-passing. But again, there have to be provisions for if a node fails and if you switch on or off a device. For example scanning the bus for new devices to link into the ring takes time and then they must be somehow addressed on the bus (if it is not a physical ring) which means you have to preset device numbers, which I wanted to avoid. > You mean "power off"? Can be coverd by simply using the right hardware. Not always when you use token ring. > > Collision detection can be done in several ways: > > > > Have a hardware that compares the signal level from the receiver > > with the one as it should be from the sender. > > Could be done by EXORing the signal before and after the linebuffer. Maybe > you have to include a small filter to get rid of spikes caused by internal > delays. That's actually the idea I had already. Have the line sender something like open-collector and always receive from the _same_ wire. Compare with xor and set a latch when differing, switching off the sending data by hardware, as well as setting RTS (or CTS, which one is the input again?) Only pulsing with CTS (or RTS, well, the output) resets that latch and enables transmitting again. I even thought - for better software handling - to set a timer (i.e. an RC thing or whatever) that starts at every 0-bit (startbit, every 0-data bit) and ends after a short (two-byte?) sending time. The output is fed to DCD, and the software can send if DCD is not set (or make it the other way round whatever, you get the point) Somewhere I might even still have the early schematics of that.... > > > Receive the bytes just sent be the sender and compare them to the > > bytes sent. If they differ, abort. Yes, see above > The only thing is I have no idea of is which hardware-driver to use to drive > the bus. That's why I asked more info about the RS485. My idea is to use > something like the 7406 but capable of driving a long bus (> 100m?) and at > higher frequencies. I never had a good look at a networkcard but if someone > can figure out what it uses to drive the bus, we have our solution. Yes, that's exactly the point where I'm stuck too. I haven't found any appropriate driver. RS485 cannot allow collisions, and simple open collector might be not reliable enough. Any other ideas? Then I'm with you (errr, when time permits, most probably after my PhD...) > > Addressing is done dynamically. On startup of the network services > > each node sends a kind of request message which all active nodes answer > > in return. The requesting node then selects a free node number. > > Probably that doesn't work that simple, but it shouldn't be to difficult > > to figure something like that out. > > In this way you still don't know which node is which computer. This only > can be known if the computer identifies himself in one or another way. So > why not use the identification itself? This is the reason networkcards > heave a unique built-in address. But this involves extra hardware. Why not The protocol I was thinking of is actually something to determine a kind of MAC (Ethernet hardware-) address dynamically, without extra hardware. A layer on top a query packet can be sent to determine the host name for example, or other properties. [Note added later: This doesn't work with token ring on a bus. Because with multi-send you can just send a broadcast and wait for the replies to come in. No need to negotiate which (new) node is first to send etc. On Token-Ring you have to specifically address a new node with a token to make it able to send. This might work with a special token to startup new devices, but there must be a timeout for no new node, and what happens if there are two new nodes - that are not allowed to send at the same time!... You see it's not that easy] > pass the node-address as a parameter to the PRG taking care of the > communication? In this way you even can take care of the fact that each > USER using the computer can have its own identification. A layer above. Thanks for the comments Andre -- Email address may be invalid. Use "fachat AT physik DOT tu-chemnitz DOT de" ------Fight SPAM - join CAUCE http://www.cauce.org------Thanks, spammers... Andre Fachat, Institute of physics, Technische Universität Chemnitz, FRG http://www.tu-chemnitz.de/~fachat
Archive generated by hypermail 2.1.1.