Hi Neil, According to the IEEE-696 specs there is only one board in the bus that is the actual bus master. A distinguishing feature of the bus master is that it ALWAYS comes up or power on (or system reset). That is why I have POC, Reset etc. on all the boards – so they could be bus masters. It is also the responsibility of the bus master to decide if and when a slave can have control of the bus. The specs outline an up to 15 slave priority system as to who has priority via TMA 0,1,2,3. As best I can tell nobody implemented this facility when the S100 bus was in use. Instead they just transferred control over to another board (temporally). In fact I have never seen a system (before ours) where there was more than one slave in the bus. This includes, Cromemco, Godbout, Intersystems etc. Some actually cheated and put two CPU’s on one card so both kind of acted as masters or at least could call a DMA controller. Who gets the bus is totally determined amongst the slaves by your priority designation of each boards TMA line. In practical terms it doubtful you would have more than 4 slaves in the bus. This simplifies things because then each slave just looks at one TMA line. If it goes low, and it’s that’s board watch line, it acknowledges back to the master its ready to transfer control to it. The other slaves not seeing their TMA line go low, do nothing. So all you need is some software and hardware to pull one of the TMA lines low. For testing you can just do it with a wire connection to ground. On and off should flip the master slave back and forth. Our V2 SMB allows you the control all four TMA lines (i.e. 1 in 16 combinations). Currently I use TMA0 for the 8086/Intel family, TMA1 for the 68K, and TMA2 for the 6502. Perhaps with later slave CPU boards, I will fully decode the top two TMA lines allowing 4 combinations! The complication you get into is if the slave when in command wants to drop down a level and call another CPU/DMA controller. According to the IEEE you give that controller a higher priority TMA number. So the master would take control back from your slave, transfer control over the then new CPU which would then control the bus. Later things would unwind back up to the original slave. I have never seen this implemented. The approach I used is simply add circuitry on the slave CPU’s using two unassigned S100 lines so that the slave kind of acts as a master to a new “sub-slave”. Same handshaking etc. The original master never knows this is going on. The advantage is that the software and hardware is now quite simple. The other thing the IEEE specs had was that the bus master supplied the bus clock and all boards worked from this clock (Phi). That put a severe limitation on the slaves, most of which could run at clock speeds faster than a Z80 (at the time). Again I have not seen anybody utilize that approach. In all cases companies had the slave supplied the bus clock while it was running the bus. Hope this helps. John From: n8vem...@googlegroups.com [mailto:n8vem...@googlegroups.com] On Behalf Of nbreeden I know the CPU boards are designed to work with "Bus Mastering"; I've realized I'm not 100% what "Bus Mastering" means or how it works. My take on it and please correct me if I'm wrong.
Assuming I have this somewhat correct then I have a couple questions:
-Neil -- |