IBM DACU

[Art Berggreen]

This probably doesn't belong in unix-wizards, but the original note was,
and I can't think of another newsgroup except maybe tcp-ip.  Also it may
be of interest to someone running one the IBM unix ports.

> 
>      You need the following hardware:
> 
> 	IBM Device Access Control Unit (DACU), which provides DEC UNIBUS
> 	slots and connects to an IBM block multiplexer channel.
> 
> 	IBM PC w/128Kb and 1 floppy, which is the brains of the DACU
> 
> 	1 Interlan UNIBUS dumb Ethernet card, plus cables, tranceivers, etc.
> 
>      Incidentally, the IBM mainframe does all the protocol processing;
> the DACU and Interlan cards are unintelligent and the PC is just there
> to get the DACU started; the packets don't pass through the PC.
>      Supposedly this all works OK, but I haven't used it.  Contact your IBM 
> rep for further info.  If you get the product announcment info for the program,
> all the basic questions are answered there.

Having had some experience getting one of our boards running on a DACU, I
thought that I'd add my observations.

The DACU is essentially an IBM PC with two special I/O devices, an interface
to IBM 370 channels and a UNIBUS interface.  The channel interface emulates
a graphics controller on the IBM channel and the UNIBUS interface emulates
the CPU end of a UNIBUS.  Both controllers are DMA into the PC's memory.
The PC is responsible for initiating I/O transfers through both controllers
and handling interrupts from both.

While the DACU does look like more or less like a real UNIBUS it does have some
strange "features".  When the PC wants to access UNIBUS device registers
it must turn off the logic which grants UNIBUS devices NPR (DMA) control of
the UNIBUS, suspending DMA activity while device registers are manipulated.
Device register access itself is indirect.  When the PC wants to access a
device register, the address and data are placed in DACU registers and the
PC waits for the controller to perform the device register access on the
UNIBUS.  Therefore DMA latency on the UNIBUS is affected by the code in the PC
which controls the UNIBUS device and whether that code can be interrupted
with DMA disabled.  Another strange thing was that interrupt requests were
granted to the UNIBUS device and then when the interrupt vector was asserted
on the UNIBUS an interrupt request to the PC is made.  This  holds the UNIBUS
interrupt transaction in mid cycle until the PC gets around to processing
the interrupt and reading the vector at which time the UNIBUS interrupt
transaction is allowed to terminate.  This has two effects, DMA cannot occur
because the UNIBUS is held in a transaction and devices which may timeout
the interrupt vector transaction could get upset.

For a stream of small packets, the PC is definitely could be a bottleneck,
depending on the packet handling overhead in the PC.  Also, any DMA
latency requirements of the device should be looked at acrefully.

Finally, if the use is to tie TCP/IP in IBM machines to Ethernet, make sure,
that there is ARP code in the mainframe or in the PC.

Needless to say, we are taking a different approach to the problem.

    				"Art Berggreen"<Art at ACC.ARPA>

------