<If you're an S-100 user, particularly if you have experience in bringing =
<up a system from totally dead to totally alive, I'd certainly like to =
<see what your impression of your needs from such a device might be.
I've brought up several IMSAIs, Altairs, NS*, Netronics explorer 8085,
several mongruls and my multi-CPU s100 crate.
Front pannel systems were rich enough to accomplish the task one the FP
was known working or nearly so. Often the problems were dirty switches,
broken wires, failed oneshots or maybe a bad LED. Other problems were the
older boards that didn't like Bus pins 20 and 70 (protect/unprotect).
Must haves:
ability to display memory
ability to write to memory
Start, stop and single step the CPU
Most front pannel systems (alatir, Imsai, Ithica intersystems, PDA-80 have
the basic resources. A scope may be needed if there are timing issues
or one shots that are drifted off.
The non front pannel systems required a FP that could be plugged in. the
easiest way was a a minimal CPU (Computime SBC880) that can drive the bus
but is otherwise self contained. That and a terminal is as good as a front
pannel (better).
The multi-cpu system needed more as the CPUs were not commercial units
IE: they never worked before so they had to be debugged first and that
required a bus logic analyser (capture bus state 1024 cycles deep) that
could trigger on specified conditions. This was needed to look at the
interaction of the many cpus and DMA devices. Once the system could run
code predictably (could still crash but reset to rom monitor was reliable)
The bus analyser was almost by un-needed.
A simple logic proble was the single common tool besides a frontpannel or
its analogue. A multi trace scope was handy for altairs (too dam many
oneshots!) and other system where the problem was logic that was damaged
>from lightining (my old NS* system).
Allison
Hi!
When I said the device had to work at high speed, I was referring to the
crosspoint switch which is used to distribute and collect the bus signals,
and by means of which one can assign an arbitrary destination for any of the
source signals, viewing them as channels rather than as individual bits.
The reason for this is to facilitate wiggling bus hanshake signal lines at
something approaching real-life speeds. If you've got 96 such channels and
want to update them all at a 2 MHz rate without skew between the various
changes, you've got to multiply that number of bits by the rate, which
quickly yields 192 MHz, which is the rate at which the circuit translates
the bits. The good (and saving) thing that I'd quickly point out, is that
it's seldom necessary to change all the signals. There's a way to shorten
the delay between bus updates by skipping the updates of unchanged
registers. That will help, hopefully with this bandwidth demand.
It's easy to reduce the signals changed in a transaction on the bus by a
couple of dozen by paying attention only to the signals relevant to a given
transaction. This means that the board should have no difficulty whatever
generating the typical data transfer handshake ant a normal speed, and
wouldn't strain too much to perform block fills and block transfers, and,
more interestingly, reasonably thorough memory verification, since that
actually involves only a couple of dozen or so signals.
I was/am contemplating a programmable state machine with which to perform
bus transactions at real-world rates in lieu of a "full-blown" crosspoint
switch because that way I could proceed to program macro-operations locally
as opposed to doing everything in the PC and suffering the performance loss.
What the crosspoint switch does for me is it allows me to group the inputs
and outputs in any combination I like, thereby making really fast bus
transactions possible since the delay form update at the PC interface to the
S-100 is a function of how long it takes me to load the registers I need to
load in order to do what I need. If only two or three registers need to be
changed, then loading them will be all that has to be done before generating
an update of the S-100. In any case, I'm considering an alternative design
which will operate at a much higher rate because of parallelism. In a
couple of weeks I'll know whether I can exploit that higher rate with
PC-resident software.
Keep in mind, that this thing has to work from the parallel port, else it's
too big a hassle. I don't want to build a kit to go in the PC along with
one to go in the S-100. What's more, I don't want to fiddle with USB, since
it's WAY too slow, and SCSI is a bit too complex for me to fiddle with for
this application. (I don't like having to buy documents on standards like
ASPI). What's more, I want this to be useable from a notebook. That's how
I intend to drive it.
As far as the graphical interface, I've considered how I'm going to sneak up
on this. I'm not a WINDOWS programmer, nor do wish to become one. I
thought what I'd do is write the code in 'C' using Borland's stuff, then
move to their WINDOWS-compatible software set or maybe SYMANTEC's, which is
also in house. Ultimately, I was hopeful I could generate the top level GUI
stuff, e.g. the front panel buttons, in Visual Basic. I've got a physical
front panel built with switches that look a bit like the buttons VB creates
quite easily, and, since each one has a little round LED in it, the VB
handler can emulate that as well. I expect that this will be a substantial
education for me, but I also expect that the fundamental software tools to
make this board a useful tool will be no trouble at all. I don't HAVE to
run it under Windows in order to use some display graphics, you see.
I think that I can cook up a library of routines (macros) which the user can
select from a popup menu or drop-down list, or some such. That way he
simply generates a block of data, be it a byte, word, or whatever, with
nearly no limits, and tells the system what to do by means of macro
commands, like fill memory from-to-with . . . maybe even some I/O
operations.
What's needed is a bit of outside input.
Dick
-----Original Message-----
From: Dwight Elvey <elvey(a)hal.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Wednesday, October 06, 1999 7:14 PM
Subject: Re: S-100 Bus
>"Richard Erlacher" <edick(a)idcomm.com> wrote:
>>
>> If you're an S-100 user, particularly if you have experience in bringing
up a
>> system from totally dead to totally alive, I'd certainly like to see what
your
>> impression of your needs from such a device might be.
>>
>> Dick
>
>
>Hi Dick
> I've only brought one IMSAI up from the dead. I only needed
>a dual trace oscilloscope but I realize that isn't always
>the best option. Way back when, I worked for Intel and
>was responsible for test of the UPP product. This had a 4040
>on it. I built a cable and interface that allowed
>one to replace the 4040 with a Series II development system.
>It was not a full logic analyzer, it just did normal read/write
>to ROM, RAM and I/O. This combined with an oscilloscope made
>a good trouble shooting tool. There isn't really a need to
>do 100 MHz operations to make a useful tool. One can make
>variable delays to adjust read and write timing to look
>for timing issues. The code that ran on the Series II
>was done in Forth. This way, one could quickly write a particular
>test routine for the particular problem one was trouble shooting,
>like one would do on a Sun with open boot. This would be quite
>hard to do in a GUI without some kind of command line
>macro ability ( the problem with GUI's is that, although a
>picture is worth a thousand words, they are often not the
>thousand words that you currently need ). Trouble shooting
>requires flexibility in test conditions that are much more
>varied than what would be used to simply go-nogo test.
>Dwight
>
In a message dated 10/6/99 9:45:16 PM US Eastern Standard Time, red(a)bears.org
writes:
> The very first EISA machines were brand new in June of 1989, and were
> powered by 25 MHz 80386 CPUs. I used to have a copy of the Byte in
> question, which also featured MCA clones. I wish I knew where it got to.
MCA clones? interesting! remember anything about the article? Ive an NCR 3300
that is similar to a PS/2 model 77.
There's a copy of the IEEE Std 696 in my lap. I've been searching for this document in "the pile" for quite some time and it's held up my work on a bus probe for the S-100. I intend to run the S-100 from my PC and have completed circuitry to enable transfer of data from the PC to the probe at a maximum of about 2 MHz. Now, this is entirely fast enough to run the bus, with the exception that it probably can't run it continuously at that rate, hence I've contemplated inserting a state machine to operate the bus automatically in a series of operations while sampling the activity on the bus at the same resolution as that at which it is being driven, e.g. 8 MHz for a 2 MHz processor clock, and more or less at that same proportion otherwise.
Unfortunately, I'm not convinced that it's necessary for me to have a really long sample memory (has adverse effects on price and circuit complexity). What's more, though I've considered including a large crosspoint switch for both writing and reading signals from the S-100, at real time, I'm not sure it will be of sufficient value to the user public. Its purpose is to allow compaction of the data transfers during a simulated bus transaction in real time. What's more, in order to get 2 MHz throughput, even in bursts, it requires I operate the device at around 100 MHz internally, which will be both costly and difficult.
Originally I intended this thing strictly as a diagnostic tool. When I noted that IMSAI is bringing back its front panel board and the box to accomodate it, I figured it might be useful to provide a fairly automated method for testing and debugging the thing, including tests for shorts, crosstalk, I figured that the notion of putting a Pentium-class machine in an IMSAI box might not satisfy everyone's debugging an testing needs, particularly if they wanted to run REAL '70's era hardware.
My intention is to allow the PC to function as the front-panel, and, to small extent, as a combined pattern generator/logic analyzer, for numerous purposes ranging from backplane troubleshooting to peripheral testing. The plan is to provide functional support for things like block transfers, I/O-to-memory and memory-to-I/O as well as memory-to memory-transfers. Memory testing, at least superficially will be supported as well. I'm contemplating a graphical interface for purposes of stimulating the bus, though, again, I've yet to see whether that's useful enough to warrant the effort.
This is YOUR big chance to have input into the design of this device, assuming you have some idea of how YOU'd use it. I've got to break the functional sections up enough that the device can be sold as a "kit" not requiring FCC approval, so much of the cost will be in things like adapter sockets for the FPGA's and CPLD's, which often outcost the IC's by 10x. Since FCC approval will goose up the cost by 100x, I'm trying to avoid that.
If you're an S-100 user, particularly if you have experience in bringing up a system from totally dead to totally alive, I'd certainly like to see what your impression of your needs from such a device might be.
Dick
--- Tom Owad <owad(a)applefritter.com> wrote:
> >Has anyone out there heard of a Multi-Mac Apple ][ Clone, model MT-600?
> That one's new to me. Is it in a similar form factor to the Apple II, or
> something more original?
It's a cheap knockoff of the Apple ][ style, down to the wedge-shaped
cable cutouts on the back. They did change the lid a little. It doesn't
have the same fastener as an original, nor does the bottom slope up in the
front. Other than that... they are vey similar.
> I run a site that documents Apple clones. May I quote you on
> <http://www.applefritter.com/appleclones/other.html>?
Yes.
-ethan
=====
Infinet has been sold. The domain is going away in February.
Please send all replies to
erd(a)iname.com
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com
>>>> Joe <rigdonj(a)intellistar.net> 10/06 4:52 PM >>>
>>
>>and are sometimes referred to as
>>HP200 9800 series.
>
> What??? The 9800 series is the series of HP desktop
>compluter/calculators that includes the 9805, 9810, 9820, 9830, 9815, 9825,
>9835, 9845, 9816, 9826, etc. A few of them use the 98200 tape but that's
>the only thing they have in common.
>
> Joe
>
I know it sounds strange but I have a tape that I received with the 85 labeled
"HP200 Series 9800" made by Hewlett Packard. It is identical to the other
98200A tapes I have. I will post a scan of the label if anyone's interested.
Wayne
!
!
!
I am looking for a source of new, or nearly new, HP 85 tapes.
These are HP no. 98200A, and are sometimes referred to as
HP200 9800 series. Any help would be appreciated. Thanks.
These are large phototypesetting machines of the first or second generation.
Autologic designed most of their own boards but sometimes OEMed CPUs. It
would be wise to check the CPU cabinet. Also check to see if the paper tape
reader is a punch also.
If it is working it could be a museum piece. I bet there are few left.
Paxton
Hi, sorry it's already been called for.
Todd
-----Original Message-----
From: John Ott [mailto:jott@ee.nd.edu]
Sent: Wednesday, October 06, 1999 4:24 PM
To: Discussion re-collecting of classic computers
Subject: Re: Giving stuff away....
Hello -
I am interested in the scsi controller if you still have it. What will
the shipping be?
john
***********************************************************************
* John Ott * Email: jott(a)saturn.ee.nd.edu *
* Dept. Electrical Engineering * *
* 275 Fitzpatrick Hall * *
* University of Notre Dame * Phone: (219) 631-7752 *
* Notre Dame, IN 46556 USA * *
***********************************************************************
On Mon, 4 Oct 1999, Todd Jaspers wrote:
>
> Hi Everyone, my roommate and I are moving to a larger apartment and
> we have tons of computer junk and my girlfriend won't let me keep it at
her
> house! I really have no use for it but I don't want it to go to waste if
> someone has a use for it.
>
>
> 1) MGA Matrox PCI graphics card. 1mb ram. pretty slow.
>
> 2) RampAT 16 bit card. Adds 4 SIMM slots to any computer with a 16 bit ISA
> card slow. Manual and instructions included.
>
> 3) various CGA and Monochrome 8-bit graphics cards.
>
> 4) various old 286 and AT mother boards IBM.
>
> 5) A whole bunch of old computer manuals. Please take the whole lot.
>
> 6) E-ISA Scsi controller 32-bit
>
> Everything is free, just pay for the shipping.
>
> Thanks!!
>
> Todd
>
