🚀 go-pugleaf

In article <8162@chinet.chi.il.us> jkingdon@chinet.chi.il.us (Jim Kingdon) writes:
>jhallen@wpi.wpi.edu (Joseph H Allen) writes:
>>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.
>
>No, give each slot its one line.  And its own address space.  Cuts down
>on the number of pins on the connector and eliminates conflicts between
>cards.  Like the
>Apple II or NuBus.  If each board is also required to have a ROM (I'm 
>unsure about whether this is a good idea) the whole can operate without
>any configuration at all, the system just knows what all that boards
>are.  Even without a ROM you only have to say "slot 6."  Help stamp
>out DIP switches within our lifetime! 

The only prolem I have with this is that each board may have more than one
interrupt/dma device.  If you are also willing to have requests between
multiple devices on each board resolved on board (a la Z80 perhaps) then I
agree.  If you do this then you probably also want to have vectored interrupts
so that the board can indicate which device actually gave the interrupt. 

Another possibility is to have a single interrup line and have software do the
dispatching.  This might not effect speed so badly since extremely fast
devices would use DMA and the search order in the dispatch poll routine could
further indicate device priority.

Address space:  perhaps we want two buses, a multiple processor/memory bus and
a peripheral bus.  I don't like the idea of ROM on board since then the boards
are forced to work with only one processor type.

Oh, minor update:  replace BYTE0* and BYTE1* with BYTE0 and BYTE1 (I.E.
non-inverting so that they can go into a NAND gate with clock and chip select
signals). 

Also, I nominate Apple-II bus as "best" commonly available bus yet devised. 
After all, on what other computer have you seen disk controllers which only use
5 TTL chips? (of course, there is Wozniak's power supply problem...).