Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site hoptoad.uucp
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!sun!hoptoad!gnu
From: gnu@hoptoad.uucp (John Gilmore)
Newsgroups: net.arch
Subject: Re: All the Chips that (Don't) Fit
Message-ID: <615@hoptoad.uucp>
Date: Sat, 15-Mar-86 23:44:07 EST
Article-I.D.: hoptoad.615
Posted: Sat Mar 15 23:44:07 1986
Date-Received: Mon, 17-Mar-86 03:49:38 EST
References: <5100022@ccvaxa>
Organization: Nebula Consultants in San Francisco
Lines: 74

In article <5100022@ccvaxa>, aglew@ccvaxa.UUCP writes:
> I've just gotten my hands on "All the Chips that Fit"...
>    I find it hard to understand why they would consider the UART setting of
>    8 data bits _and_ 1 parity bit useless (in the Z8530). Not everybody uses
>    7 bit ASCII, I don't care what's in the eigth bit so I'm gonna mask it
>    off.  Not even all UNIX systems. (What I would give for a true meta key
>    in my EMACS).

The problem was that the chip is configurable to: 1 start bit, 8 data
bits, 1 parity bit (whose value is ignored) and 1 stop bit.  Nobody, I
mean nobody, sends data that way; they send 1 start, 8 data, 1 stop.
(One of the data bits might be a parity bit, if desired.)

The chip setting only happened to work because the chip would read the
stop bit as the parity bit and then, unless another character
immediately followed, there was a second stop bit.  (Stop bits are sent
continuously until the start bit of the next character.)  If you sent
two chars back-to-back, it would garble them.

>                           ...a good device designer should make his system
>    extensible, so that new features can be added in the future (*). But you
>    don't want to have to go and redesign all the boards that use the chip...
>                            ...in hardware you can't blithely increase the
>    number of control registers assigned to a device, because boards have
>    been laid out with the devices crammed as close together as possible, and
>    it costs money to change them.

Maybe this is true for some systems, but not the ones I've seen.
Typically it's just as convenient, or more convenient, to decode high
order address bits rather than low order; this puts a lot of space
between the devices.  This is often true because you can use a single
decoder to decode up to 8 devices, each of which will vary in size --
so you pick a nice large size bigger than all of them, and decode that
much space.  In systems with an MMU, each device should at least have
its own page, so it can be mapped separately from each other device.

It's also true that very few improved chips are "drop-in" replacements
in existing circuit boards.  None of the various 8080 series were
(8080, Z80, 8085); the 68010 was close to the 68000 but required much
tighter control of the BERR* input, making it not drop in to Suns at
least.  The 9513A was a drop-in for the 9513, but it didn't have
any extra registers either.  Have any examples?

>    Of course, there are trade-offs here. You could take multiplexed
>    registers to the logical conclusion, and have only two control locations,
>    register number (written as data), and register value (to be
>    read/written).

This would be almost OK.  An OK chip would have the ability to read the
"register number" register, so there is no hidden state, and you can use
the same device from a mainline and an interrupt routine, or from two 
interrupt routines.  (One application of this was for an NMI routine
to access one timer in a 5-timer chip, the 9513, while other interrupt
routines used the other 4 timers.  Didn't work without major kludgery.
You can't lock out NMI's, and once in a while the NMI would happen
just after the register number was written but before the register
value was written.)

>                                                                    ...I balk
>    at having to keep track of phase if there is only one register to be used
>    both for addresses and read/write values.

This is unfortunately what most such chips do, and is what the authors
were complaining about.

>                                                        (shall I put this 64
>    byte multiport card here?  - no, that conflicts with the disk driver;
>    here? - no, it bumps into the Ethernet card; here...)

This is mostly a problem because of an 8-bit I/O adress space.  That 64
byte card takes 1/4 of the whole address space.  That's bad I/O
subsystem design, not bad I/O chip or I/O card design.
-- 
John Gilmore  {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu   jgilmore@lll-crg.arpa