Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!mo
From: mo@seismo.CSS.GOV (Mike O'Dell)
Newsgroups: net.arch
Subject: Timing sensitive devices
Message-ID: <1475@seismo.CSS.GOV>
Date: Sat, 22-Feb-86 11:16:11 EST
Article-I.D.: seismo.1475
Posted: Sat Feb 22 11:16:11 1986
Date-Received: Mon, 24-Feb-86 06:57:11 EST
Organization: Center for Seismic Studies, Arlington, VA
Lines: 28

Sorry to break the news, folks, but almost every Unibus device
ever attached to a PDP-11 or a VAX has timing sensitivites which
must be considered when stroking the hardware from fast machines.
(The 780 Unibus adaptor itself is certainly in this group!!)
Such things, while a pox on the programmers, are in fact the way
the world really works.  I didn't say I like it, or that it's the
way it should be, but that's the way it is.  One valid criticism is
that much of the microprocessor-derived hardware was designed when
a 4 MHz Z80 was considered fast, and a "bus" was a handful of 8080
signals all running down the board together (crosstalking all the way!),
and correspondingly exhibit these problems more visibly than
discrete implementations designed for other environments.

There is a simple hack which solved the problem more gracefully than
arguing over it.  Keep in mind the point is to wait AT LEAST long
enough, not to time things precisely. Therefore, you find preprocessor
symbols like CPUDELAY which you simply count down to zero, and the
constant is tuned per the CPU speed.  The usual hack is CPUDELAY
represents about 10-100 Microseconds, depending on the delay
intervals which must be burned, and whether you want to multiply
to get the right number.  A slight variant is to make CPUDELAY
a global cell containing the right number, so binary programs can
get the right number without recompiling.  

Again, it ain't wonderful, but it works fine, and you can get on
with other more productive things.

	-Mike O'Dell