Rebirth of IMSAI - test-drb@ccmp.vtda.org

29 Mar 1999

Please see comments imbedded below.

regards,

Dick

-----Original Message-----
From: Tony Duell &lt;ard(a)p850ug1.demon.co.uk&gt;
To: Discussion re-collecting of classic computers
&lt;classiccmp(a)u.washington.edu&gt;
Date: Monday, March 29, 1999 5:36 PM
Subject: Re: Rebirth of IMSAI

...
 >
> Thanks for posting this information.  It might be useful, in addition, at
> least to me, to have to correspondence with the S-100 bus pins so they can
...
   be
cross-referenced to the '696 standard signal names.  I do hve the 8080
 data in house, but nothing tying it to the S-100 bus pinout or timing. 
Isn't this already on-line somewhere? If not, I could type in the pin
descriptions for the Altair 8800b bus that I happen to have here. I have
a very useful book called 'The S100 Handbook' that contains things like
the S100 pinout, schematics for a dozen common cards (including Altair
and Imsai CPU/frontpanel/memory), etc. But I'd rather not duplicate the
work if I don't have to.

>
> Actually, it might be as correct to say that 8088 signal names are more or
...
 > less like "all the other" microcomputers
in the non-Motorola camp.  with the
...
   8085 and z-80,
it became obvious that the large number of strange signals
 generated by the 8080 didn't even help the Intel folks with the task of
 interfacing the processor to memory and peripheral devices.  The simple 
One of the problems with the S100 bus is that it is _very_ dependant on
the 8080 signals. Even using a Z80 is a bit of work - things like PINTE
(which indicates if interrupts are enabled) and SSTACK (address lines
contain the value of the stack pointer) don't exist as external signals
on the Z80. 

What's more, those signals are really of little use.  They could be, but it
was too much trouble to use them when they were available, so the fact they
aren't is of no concern.

...
 > a transfer of data to or from the processor. 
Additionally, it's nice to
> know whether the read or write is between the processor and memory or I/O.
...
 > With the MOT class of processor, you have an
address strobe to tell you a
> cycle's begun, and you have to decode the address to determine whether
it's
...

Actually, I prefer the Motorola / PDP11 idea of having memory and I/O in
the same address space. It means you can use the same instructions and
addressing modes to access either. 
...

If the total address space is large enough, you don't need all of it for
memory, so you can assign (say) 1/256th of the entire address space for
I/O. So you use something like an 8-input NAND to decode the top 8
address lines. One TTL chip. Not a lot of work IMHO. 

Yes, this was a common approach, and one which we used with bus-based memory
mapped I/O on the 6502 and 6809, etc.  With a small address space, though,
is was common to have the PROM live above the I/O page because the reset
vector lived there anyway.  With the I/O mapped processors, where the ROM
was expected to live at the bottom of addressable memory, tricks had to be
used to make the rom at the bottom go away and be replaced with I/O handlers
at the top.  Intel finally figured that out with the 8086 family, but with
IBM's implementation, it became a pain.  There it might have been more
practical to put all the ROM at the bottom, with each adapter having a
pointer at its beginning to indicate where it ended.

...
 [Incidentally, can people please trim the messages they
are replying to.
It's not necessary IMHO to include a complete copy at the end of your reply]
...

-tony 