Please see comments imbedded below.
regards,
Dick
-----Original Message-----
From: Tony Duell <ard_at_p850ug1.demon.co.uk>
To: Discussion re-collecting of classic computers
<classiccmp_at_u.washington.edu>
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
Received on Mon Mar 29 1999 - 20:20:44 BST