Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!husc6!m2c!wpi!jhallen
From: jhallen@wpi.wpi.edu (Joseph H Allen)
Newsgroups: sci.electronics
Subject: Re: FSF/AT-bus architecture
Message-ID: <1758@wpi.wpi.edu>
Date: 6 Apr 89 21:51:24 GMT
References: <5768@ux.cs.man.ac.uk> <2445@iscuva.ISCS.COM>
Reply-To: jhallen@wpi.wpi.edu (Joseph H Allen)
Organization: Worcester Polytechnic Institute, Worcester, MA. USA
Lines: 78

In article <2445@iscuva.ISCS.COM> jimc@iscuva.ISCS.COM (Jim Cathey) writes:
>The PC bus is not very good, especially when it comes to interrupts.  Who ever
>heard of a serious bus that had TTL active-high interrupts!!!  (For those who
>don't know, it means you can't have several boards share an interrupt request
>line.  This is a serious problem with PC's -- they only support 8 interrupts
>total.  For the AT, all they did was add 7 more, and they used most of these
>up internally to the box.  The damned bus is _still_ active-high TTL for
>interrupts.)

It makes me wonder if IBM's designers even understand interrupts...  I'd
even prefer if they had a single interrupts line and polled dispatching.

>PC bus is a lousy choice for the conceptual successor to the S-100.

I'm not sure about this- there are probably more PC buses out there than any
other kind.  It all depends on what you mean by "conceptual successor".  As I
remember the S-100 was pretty lousy too. 

>For my 2 cents' worth, they should put the designers of the 8259, 8250, and 
>765 (8272) chips up against the wall and shoot 'em.  Garbage, one and all.

Did you ever try to program the serial port?  You have to set-up and enable
_4_ chips.  Sure these chips are bad, but IBM is worse by actually _using_
them.

And now for my 2 cents' worth:  If I had designed the IBM PC bus.... ( :-) it
would be something like this:

GND		8 pins
+5V		8 pins
+12V		2 pins
-12V		2 pins

All on opposing corners so that you can plug boards in backwards.  (actually,
some kind of transmission line analysis should be done to do this correctly
but I'd guess that this would be acceptable for a small bus).

RESET*		Wire-or, low is active.  Maybe I'd replace one of the GND pins
		with it so that if you plug a board in backwards the system
		stays reset (and when reset is active, all output gates would
		be tri-state).
D0-D15		Data bus
R/W*		Direction
A1-A23		Address bus
BYTE0*		Lower byte transfer
BYTE1*		Upper byte transfer
E		Main clock.  Falling edge is when data is due- this way, E can
		go through a single NAND gate and connect to a rising edge
		clock device.  The timing at this edge is the most important
		decider of bus speed so it should be designed to minimize
		the number of gates E has to go through to interface it
		with things.  Outputs to the data bus should be enabled while
		E is high (I.E., E low is device disable time)
WAIT*		All boards should be designed to be synchronous by default yet
		upgradable.  The time between low E edge and high E edge
		should be checked on each board so that WAIT can be invoked in
		case the bus speed is increased beyond the speed of the board
		to stretch E.
IRQ0-7*		Interrupt requests.  No ACK cycle- device holding IRQ down
		is cleared by software.
DMARQ0-7*	DMA request lines.  Device holding DMARQ low releases when
		the transfer occures.

There, a total of 81 lines so probably an 86 pin connector should be used. 
Note that this is only meant to be a single processor bus such that the boards
need the absolute minimum of hardware to interface to the bus.  For multiple
bus masters I'd probably add these:

WHO0-2		Who owns the bus.
BREQ0-7*	Request the bus.  7 should use round-robin technique, 1 should
		have priority for the DMA controller.  Request should be
		placed right after E going low and response on WHO should
		appear at next E going high so that the owner can take over
		on the next cycle.
LOCK*		To prevent ownership change for read/modify/write sequences.

Issues to resolve:  how to expand the data bus
		    how to interrupt other than the default processor