Category: S-100 Bus

I stumbled on a SMB PCB (V3) for sale on ebay.  This PCB is for a modern design using many old ideas.  It provides address and data bus displays, status LEDs, single stepper, breakpoints, and some other facilities and debug features. To be honest, i thought the blinken lights might add a little visible interest to the 8085/86 system!

I built it up using the info here:

http://www.s100computers.com/My System Pages/SMB Board/S100 Bus SMB.htm

The board was designed by S-100 legend John Monahan.

The frequency display seemed a bit unnecessary, so i skipped that part.

The S-100 bus is quite a loose/adaptable standard, and i’ve found that a card may work well in a particular context but not so well in another. I found this one neede some customisation for my set-up. I’m not super experienced with S-100 so my notes should be taken with a grain of salt and certainly not as a criticism of the original designer. Sometimes too, i am guilty of not RTFM!

I found the breakpoints were unreliable.  I think this was due to the address bus not being stable when the address was captured (a decoded output driving a preset on a flip-flop).  I modified it to use the pstab signal which seemed to settle it down.

When i came back to this a couple of months later, I found that at break the displayed address was always one more than I had requested.  This led to quite an adventure in trying to understand how breakpoints work.  I also noticed that it often broke at random addresses.

When I looked, I found that the breakpoint does not take into account whether the cycles are read or write, or if it was a data or instruction fetch or I/O cycle.

I further learnt that the displays are only accurate when reading.  That’s because they are transparent when the pDBIN signal is asserted.  If the card breaks on a memory write, then the display isn’t meaningful.

The address is latched locally using pSYNC AND pSTVAL.  This seems to be an approach adopted for V3 of the board.  Previously, the lines were just buffered.  The earliest that these can be grabbed is when pSTVAL is asserted.  As far as I can see, this makes it very hard to get a RDY signal asserted before the rising edge of PHI in state BS2, particularly given the standard says that pSTVAL may not be asserted until that clock edge.  Fortunately, the CPU card asserts it much earlier (about 80ns) so there was hope.  Unfortunately, the address registers are triggered when pSTVAL is negated which is too late to guarantee that the XRDY signal will be asserted in time to take effect on the current cycle.  Consequently, it moves on to the next cycle and then stops.  This explains the address being one too late.

I have made some changes to try to salvage some useful operation.  The first was to use the leading edge of the pSTVAL pulse to trigger the address latches, so the address is available locally much sooner.  Getting through the registers, comparators, gates, and flip-flop chews through a lot of the available time.

The V3 design uses PHI_L in place of pSTVAL (apparently this was not uncommon on older boards, but I’m not sure why it was done here).  Given that RDY is negated by an asynchronous set, it is important that the Address comparison is stable before it is gated through to the flip flop.  That’s difficult to organise because that logic is responding to the local address change initiated by pSTVAL being asserted.  I think the only robust way to do this would be to accurately delay pSTVAL beyond the propagation time through the address comparison logic.  Very ugly.

I tried this to some extent by inverting pSTVAL twice but this is not nearly long enough.  Even with an RC network I found it was not perfect – particularly once I attempted to filter out writes using sMEMR.  Spurious pulses were generated as the addresses settled. Using typicals for the comparator network, suggests a delay of at least 50ns is required, and this is hard given the two delay gates only give about 10-15ns and the pSTVAL pulse is less than 100ns. I did find the spurious pulse from the address detection could be suppressed with a 560pF capacitor. This resulted in predictable operation in my system.   

When I added sMEMR I found that a spurious pulse was always generated on the cycle after the write cycle that matched the break address (attempting to suppress with capacitance does not help here).  I have not resolved this, so I have removed the sMEMR signal. This means that breaks will be triggered by writes.

The V1 design, which had buffers for addresses rather than registers, would have been better for my system because the addresses would be available to the comparator logic 70ns earlier – plenty of time to be sorted before pSTVAL arrived and enough time to get XRDY negated (at least with my CPU board).  The standard does not allow any time between pSTVAL being asserted and the critical STVAL edge in BS2, so that would have been really tough.

Looking at the timing diagram in the standard, it dawned on me that pSTVAL may be asserted twice by some cards.  The timing diagram seems to make that a possibility, but not a guarantee.  This would be consistent with a comment on the card site that says that early cards used the inverted PHI as the equivalent of STVAL. So, perhaps the V3 SMB card assumes that PSTVAL is asserted twice.  The Compupro card does not do this.

With two pulses, there is an additional edge available to clock the address registers well in advance of the second mandatory pSTVAL pulse.  I think this must be what the designer had in mind.  The second PSTVAL pulse (or, as in the design, the matching PHI low) is identified by being in association with pSYNC.  I attempted to substitute pSTVAL* with PHI* but I could not get the timing right. 

I reverted to my original solution above (italics) which relies on a capacitor to suppress spurious outputs (very dodgy).

• 560pF capacitor at U22-12
• U3-5 connected to U10-11
• U10-11 pin bent out of socket
• U10-11 socket pin connected to U10-13

So I think the upshot is that the card assumes a two pulse pSTVAL and the Compupro does not provide it.  It’s possible that I have other cards that do – so I’ll need to bear that in mind if I use it with other processor cards.

Moving on … This board has a daughterboard, for the displays, LEDs, and control switches.  In hindsight, I may have been able to mount it directly on the card, but I didn’t.  Instead, I used ribbon cables.  I made it a little harder by mounting the connecters iaw with the silkscreen, rather than putting them underneath.

The mechanical exercise of doing the front panel was quite time-consuming.  I replaced the existing front panel with 3mm aluminium and 3mm clear perspex. That allows me to put card in between – a graphics design problem in search of someone with some flair. The display is mounted on the aluminium panel. The original panel front panel has been stored.

There are a lot of jumpers on this board: