Your comments are interesting and probably correct, but I think you've
missed the point. What I wanted to address is the problem of deciding which
features to put into a tool and which ones to leave out.
The issue of host speed is interesting, except that it really doesn't matter
whether it can emulate the S-100 system's processor at 15 times its normal
rate or 2500 times its normal rate. The interface is bandwidth limited by
design to 2 MHz updates. I've contemplated a FIFO of some sort, but since
the S-100 can be operated in bursts or in loops at an arbitrarily high speed
anyway, I doubt there's a need for a FIFO.
What boards there were or are isn't really relevant, since the target is to
produce a useful tool. Pointing out the weaknesses, which, after all this
time are either forgotten by or known to all of us, of one tool or another,
won't help. What I'm addressing is using TODAY's technology to facilitate
testing and verification of the S-100 bus. We're free to assume that the
width of various signals can be adjusted in 10 ns increments just to
determine what might work the best, even if the CPU can't really generate
that waveform, and we're free to try solutions to the S-100's 7 equations in
4 unknowns, not only as a linear programming problem, but with discrete
attempts with each possible solution, even though our CPU doesn't play that
way, just to find out what really is wrong.
This stuff is, in some cases, over 20 years old. Digital circuit design has
evolved considerably since the '70's and, as it happens, much of what was
sold on the S-100 market really didn't work, not because it was designed
back in the '70's, but because it was designed badly. Some of it worked,
"sorta," when in combination with specific other components (boards) but
others didn't really work reliably, (e.g. survive a 1k-hour test/burn-in)
under any circumstances. Unfortunately, sometimes the very circuits we
wanted to use were in this category and wouldn't work with OUR hardware,
even though it seemed to work fine with THEIRs at the
store/trade-show-whatever, where we first saw it.
What I would do if now were then is try a board in my existing test system
to see if it caught fire or did something equally irksome. If it worked,
I'd smile and proceed, and if it didn't, I'd attempt to find out why. If
the board is claimed to be IEEE-STD-696 compliant, I'd try driving it with a
'696-compatible set of signals to see if it behaved as expected. If yes,
then I'd have CPU issues to resolve, not "new-board" ones. The tool I've
essentially proposed enables you to do that without having to buy
'696-compliant boards, since you can't readily pick up the phone and order
them. It will, however, support you in an effort to whittle at each of the
boards you want to use in order to make them work and play well with the
others you wish to use, regardless how recalcitrant.
Features I've already built in include the abilities you mentioned, examine
and deposit memory content, easily extended, by the way to ensuring that the
memory works consistently, stop the processor, single-step through execution
of a program or cycle, jam an instruction onto the bus during an instruction
fetch, etc. What's more, it can do this without a CPU in the system, or,
assuming the CPU can do this, it can float the CPU and do "correctly" what
you think the CPU is doing incorrectly just to ensure the fault is on the
board you think it is.
Anyway, people who've had the experience of bringing up a dead multi-board
system in which the various manufacturers had no convention as to defaults
or operating modes, in which it was a given that three or five boards,
though all functional could and usually did yield a system which did nothing
until the incompatibilities were ironed out, and in which there were no
guarantees that ALL the components would work together at all, would have a
really good idea of what features a generalized emulation/troubleshooting
tool like this one should have.
Resurrecting a 20-year old S-100 is VERY different from bringing up an old
PDP-8. In the latter case, the bus standards were set by DEC, who knew what
they wanted to put out there. In the S-100, boards were often designed by
people with incorrect and/or incomplete information about what had to be on
the bus in order for it to work correctly. They were virtually always
designed with incomplete information about how other mfg's boards behaved on
the bus. What's more, that behavior was likely to change, depending on how
the CPU or other bus masters behaved.
Since it's difficult to get detailed information about how a board you just
bought at the flea-market works, you have to figure that out for yourself.
This is a tool for doing that. It won't do it automatically but it will
help you.
Dick
-----Original Message-----
From: allisonp_at_world.std.com <allisonp_at_world.std.com>
To: Discussion re-collecting of classic computers
<classiccmp_at_u.washington.edu>
Date: Thursday, October 07, 1999 7:03 AM
Subject: Re: S-100 Bus
>> on the MULTIBUS-I. The only case in which I've used a front panel has
been
>> the one MULTIBUS-user-client I had once whose SW types thought it would
>> help. I doubt that it did, but it was a fun job!
>
>All the multibus bring ups were done using CPUs like intel 80/20 or
>national BLC204, even if the bus was a mess you could run with these
>as ram/rom/io on board were alive.
>
>> I agree, except that I belive that your PC-compatible would make an even
>> better FP substitute, with its nearly 1 GHz processor, 1GB of RAM and
>
>Not to say it can't. The SBC880 was a z80/serial/parallel/rom/ram on one
>card and more of less had those function isolated from the bus. This
>allowed severly crunched bus to be driven while having the luxuray of a
>real cpu and terminal interface. I used my own debug monitor in Eprom.
>The key is I still have it, and I used it from the early 80s on.
>
>For board level debug the explorer 8085 <netronics> was good as s100 was
>the 'add on bus" so if the card was not running you could
>drive/interrogate it.
>
>> several 3-doz-GB HDD's. Moreover, since it can not only load programs
and
>> monitor their execution, clock-tick-by-clock-tick, and disassemble
>> unfamiliar code in real time, generally waiting for the resident
processor
>> to catch up, it has potential not yet exploited. You can use it for
logic
>> analysis, signature analysis/failure detection, code verification,
>> profiling, etc. It's just another tool, but if it can be sold for less
than
>> IMSAI's FP, then it's not only an improved tool, but less costly, too.
>> Since you can repetitively stimulate the S-100 in a short loop, you can
>> easily address signal quality issues previous too slippery for most
folks.
>> You can look over the processor's shoulder or you can take him out of the
>> loop and run things yourself. When you've narrowed the problem you have
>> down to a small set of signals, you can poke around with your 'scope to
see
>> that all's as it should be.
>
>A s100 card with z80, io and enough ram and rom to run is a trivial board
>and was cheap even in the early 80s. Using todays parts 64k of eprom,
>64k (or more) of banked ram and other things would be not only simpler but
>cheaper too!
>
>The PC approach depends on the processor having lots of speed. What if
>all you have for this kind of task is a 486dx/33 or maybe an old P133?
>Not evey one is invested in PCs to the ears. FYI: my hottest PC is for on
>line use and not for adding cards like that and it's only a P166 with
>about 2.1gb. The only systems I have with an abundance of loose storage
>are VAXen.
>
>> I never used a front panel until I was asked to build one for a
>> multi-processor system on a VERY extended Multibus-I. That was fun and
>> profitable, but wholly unnecessary, I felt, since all the processor
boards
>> were completely self-sufficient with the exception of mass storage, and
>> since the CP/M image was in ROM, it didn't take long to boot, either.
>
>I started with PDP-8s, 10s then a CM2100 and firs micro was ALTAIR. FP
>were ok for some thing where seeing state was nice. I used it more to mod
>software that had IO that didn't match mine. It was the easiest way to
>see what addresses it was looping at.
>
>> I've normally addressed lightning damage with a call to the insurance
>> company, though they usually don't respond promptly. The procedure for
>> socketed boards is to take the parts out and test them in a tester. Most
>> prom programmers can do that.
>
>There were two proms in the entire system, 488 2102s, and lots of '367s,
>241s, and '244s. Not to mention the fried terminal and printer. In 1979 a
>logic tester for would have cost several times the system. Now, I'd toss
>the MB <PC> and start fresh.
>
>> I really don't see how a logic probe can help you until you've narrowed
the
>> problem down to a single board. What's more, it's common enough to have
>> several boards which work correctly in a system that doesn't. Sometimes
>> they just don't work and play well with others. CompuPro boards were
famous
>> for this. They often wouldn't work with other boards from CompuPro.
They
>> weren't alone in this, but their idea of interoperability was that MOST
of
>> the boards in a system which they sold would work together. Their
excellent
>> marketing and advertising made them the main force behind adoption of a
>> standard too weak to work, and too vague to provide guidance. They, more
>> than any other maker of S-100 stuff ignored whatever parts of the
standard
>> that it suited them to ignore, and they weren't alone. The problems of
this
>> sort are exactly the sort I'd seek to address with a bus probe. What's
>> more, there are few tools which will automatically allow you to find
>> inadvertent connections between signals, say, because of a mis-jumpered
>> board, or such, or to find that what one board maker uses for signal is
GND
>> to another.
>
>S100 was nice in one respect you could strip the bus and plug in pboard
>until it broke.
>
>Allison
>
>
Received on Thu Oct 07 1999 - 13:12:23 BST