 Greetings, retro friends. Today I'm going to be talking about the S100 bus. Yeah, I don't think so. So the S100 bus was the backplane for the Altair computer back in 1975. The idea was that the signals for the 8080 microprocessor would be brought out onto a bus and each pin on the slots had the same signal. Then other cards could be added to the bus like memory, display, disk and printer cards and so on. Other companies could make cards for the Altair because of the standardized bus and other companies could even replace the CPU and so it wasn't an Altair anymore and the bus became known simply as S100 because it had 100 pins. Like the 8080, the S100 bus had 16 address lines and eight data lines but eventually in 1979 the bus standard was updated for 24 address lines and 16 data lines and finally the bus became an IEEE standard, 696-1983. At the time though there was a competing standard and that was the IBM XT bus and as we know by looking around today the winner was the IBM bus which morphed through time into ISA, PCI and then today's PCI Express. S100 held on through the 1990s and was pretty much dead by 1994 when the IEEE standard was withdrawn. Today of course the S100 bus is still used for retro computing projects and that's what we're all about. Okay let's look at the bus signals. There are address and data lines of course and there's a bus clock. There are some status lines which tell what the bus is doing such as memory accesses, a read, an opcode fetch. There are also control lines which the master card that is controlling the bus generates to control the other cards on the bus known as slaves. There's only one permanent master on the bus but another slave card can become a temporary master if the permanent master lets it. Anyway let's take a look at how a read by the master from some other card such as a memory card takes place. There are basically three bus cycles. During the first one the sync control line is asserted to indicate the first bus cycle. Also the address and status lines are set to their values for a read. Then the status valid control line is asserted then the status valid control line goes low causing the slave card to examine the status lines and address lines. All that takes place during the first cycle. During the second bus cycle the data bus in control line is asserted which starts the read. During the third cycle the data bus in control line is de-asserted which means the master has read the data from the data lines. A write cycle is similar except both address and data lines are set by the master. Instead of strobing the data bus in control line the write control line is strobed which tells the slave card to store or do something with the data. Most of the bus signals have minimum times relative to other bus signals. For example the sync line has to be asserted no sooner than 10 nanoseconds after the rising edge of the bus clock. Some signals also have maximum times so for example the sync line has to be asserted no later than 40% of the way through the bus cycle. Speaking of bus cycles the bus clock has a minimum and maximum cycle time or frequency. The minimum frequency is 500 kilohertz for a 200 nanosecond cycle time while the maximum frequency is 6 megahertz for a 166 nanosecond cycle time. There are other signals like the ones that request temporary control of the bus but let's move on to the TMS 9900 signals to see how we can generate the bus signals we need. Here's the clock timing for the 9900. Recall that there are four clock phases staggered evenly and not overlapping. The cycle time of the overall clock is between 300 and 500 nanoseconds which places it within the 166 to 2000 nanosecond range required by the S100 bus. For argument's sake let's suppose that the overall clock is going as fast as possible which means a 300 nanosecond overall clock cycle. However the cycle time between phases is 70 to 80 nanoseconds which is too fast for a bus clock so it's likely that we can use the overall clock as the bus clock. Also note that the phase pulse itself is at least 40 nanoseconds usually 45 nanoseconds long. Now for a read the 9900's address and control lines are set a bit after the rising edge of phase two in fact 20 to 40 nanoseconds afterwards. So basically we don't know that we're in bus cycle one until 20 to 40 nanoseconds after the rising edge of phase two. Recall that the sync pulse on the S100 bus has to rise anywhere from 10 nanoseconds to 40 percent of 300 nanoseconds or 120 nanoseconds. So it is perfectly viable to start the sync pulse when this memory enable line is asserted. On the S100 bus we need to place a negative edge on the status valid signal to indicate that the address and status lines are stable. According to the standard this must happen at least 70 nanoseconds after stability is reached. But since stability is reached at most 40 nanoseconds after the rising edge of phase two the minimum time for the status valid signal edge is 40 nanoseconds plus 70 nanoseconds is 110 nanoseconds. We need to find some more delay. Since we know that the rising edge of phase three occurs at least 70 nanoseconds after the rising edge of phase two and that the phase pulse lasts at least 40 nanoseconds we can use the falling edge of phase three to drive the falling edge of the status valid signal. We can continue this way until we've decided when each S100 bus line is triggered relative to the 9900 signals. Now in terms of the three bus cycles we can clearly see two bus cycles in this read cycle timing diagram. It kind of looks like there is a third cycle where the processor is sort of digesting the results of the read. This can be our third bus cycle. So I've hooked up one bit of the circuit. So here is the CPU. Here is my oscillator. It's 12 megahertz which means that the cycle time is going to be or rather the cycle frequency is going to be 3 megahertz or a 333 nanosecond cycle time. This is the clock generator chip that goes along with the CPU. It generates the four non-overlapping clock phases and I've fed the outputs of that chip to an inverter just in case I need the inverted clock outputs and I've also taken the memory enable signal and put it through the inverter as well. Now I've hooked up this circuit over here just to generate the bus clock and the sync signal. So the bus clock is fairly straightforward. I wanted to go high when phase two goes high and I wanted to go low when phase four goes low. That's the phase right over there so I wanted to go high on phase two and I wanted to go low on phase four. High on phase two, low on phase four. That gives me the 50% duty cycle that I need. And here is the memory enable signal. Now from the CPU it's actually a negative signal so this is through the inverter. And then finally I have generated the p-sync signal out of the memory enable signal and the phase one clock. So this is a 74-74 flip flop. I've also used that flip flop for the bus clock generator. This is a nice versatile chip because it's a D flip flop so it's synchronous but it also has asynchronous reset and asynchronous preset which means that I can set the output to zero or one whenever I want regardless of the clock. It also has regular and inverted outputs so basically with this you can build whatever sort of flip flop you want. So for the p-sync signal what I wanted to do is I wanted to go high when memory enable goes high but I wanted to go low on the next phase one clock. So that means that it should go phase two, phase three and phase four. It should be high and then phase one it should be low. Recall that the minimum time for sync to be high is 70% of the entire cycle. Well phase two, three and four together comprise 75% of the full cycle so I should be safe. So that's the idea here. So that's what I built. Here's the inverter. Here's the flip flop and I've hooked up my logic analyzer so let's take a look at what that looks like right now. Okay so here's the output of the logic analyzer so let's zoom in. All right so here's the first signal. This is my bus clock. It looks pretty straightforward. It is going at about 330 nanoseconds per cycle or 3 megahertz so that makes sense. Here is the the memory enable output as it comes from the CPU. Remember it's a negative signal and this is my generated sync pulse. So it looks okay because it does go high and then go low within the same bus cycle which is what I wanted. It does seem to have a delay from the beginning of the bus cycle to the beginning of the sync cycle. The sync signal which is correct. The minimum specification is 10 nanoseconds and I am actually at 10 nanoseconds right here. Actually now I'm at 20 nanoseconds. Let's go and take a look at another signal here. That's 20 nanoseconds. Let's take a look at another signal 20 nanoseconds. Okay so I'm well within the spec here. Also the sync signal has to be at least 70% of the bus cycle which is 333 microseconds. Now 70% of that is what something like 220, 230 nanoseconds. It looks like I'm at 240 nanoseconds. Let's take a look at another one. 230. How about another one? 230. So that seems pretty good. Now I don't have anything more precise than 10 nanoseconds because this logic analyzer only goes up to 100 mega samples per second. So this seems to work pretty well. Now one thing that I'd like you to notice though is that the beginning of the phase, the beginning of the bus cycle to the dropping of the memory enable signal is actually 10 nanoseconds which is quite odd because remember that from the timing diagram of the 9900 there is supposed to be 20 to 40 nanoseconds of delay. So what's going on? So here's what I think is happening. This is a timing diagram for the clock generator chip. Now remember that the purpose of the clock generator chip is to generate the four non-overlapping phases at 12 volts for the CPU but it also outputs TTL versions and inverted versions of the clock as well. So if you look at this it looks like there is actually a delay from one clock phase that's fed to the CPU and the same clock phase that's output on the TTL outputs. So what is that delay? So if we look at the timing of that on the data sheet we're looking at delay time phase n high to phase n TTL low negative 20 to negative 13 nanoseconds, well typically negative 13 nanoseconds and maximum zero nanoseconds. So in fact what that means is that the TTL phase is actually over here. It occurs before clocking the CPU. So to find out what happened I hooked up the logic analyzer to both the 12 volt and the TTL output of the clock generator which I can do because the Sallier is 12 volt tolerant, at least the pro version is. And sure enough I see that the TTL output precedes the 12 volt output here by 10 nanoseconds. So that negative 10 nanoseconds is definitely within the negative 20 to 0 nanoseconds called out by the data sheet. And here we can see that the falling edge, that the rising edge also precedes the falling edge of the 12 volt signal. Here on the other hand there is a zero nanosecond delay. Here's another zero nanosecond delay just choosing at random zero nanoseconds, zero nanoseconds. Of course that's not necessarily zero nanoseconds because again my sampling interval is 10 nanoseconds. So this could be let's call it plus or minus 10 nanoseconds. So now let's add the memory enable signal and change this to phase two to see when the memory enable signal occurs relative to the phase two clock. All right so let's take a look. Now the memory enable signal we want to see when it goes low. And we can see that it indeed goes low. Well here it's 10 nanoseconds after the phase two clock. Let's take a look at some other signals, some other instances, 10 nanoseconds, 10 nanoseconds, 10 nanoseconds, and let's say somewhere in the beginning. So we're also seeing 10 nanoseconds. That delay is supposed to be 20 to 40 nanoseconds. Now if we take a closer look at the 9900 data sheet we can see that the propagation delay time which is the delay between the phase two clock and memory enable it actually doesn't have a minimum. So I was wrong when I said that the that the minimum would be 20 nanoseconds. That's actually typical. It could be as low as negative infinity nanoseconds but realistically zero plus nanoseconds because it really is clocked based on phase two so it has to occur at or after phase two. So 10 nanoseconds is not unreasonable. But that's okay. It looks like our sync signal worked anyway. On the next episode of building a retro computer. An S100 bus system. Insanely overpriced vector boards fully discharged. It's always a good thing. We're just going to unscrew this and always replace them. We're not going to have a crazy huge power supply. I've heard that they basically they don't do anything. Okay I'm going to use something a little beefier.