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 ucbvax.BERKELEY.EDU
Path: utzoo!decvax!bellcore!ulysses!ucbvax!NGP.UTEXAS.EDU!mknox
From: mknox@NGP.UTEXAS.EDU (mknox)
Newsgroups: mod.computers.68k
Subject: Re: Questions! (disk track buffering)
Message-ID: <8606050133.AA08224@ngp.UTEXAS.EDU>
Date: Wed, 4-Jun-86 21:33:42 EDT
Article-I.D.: ngp.8606050133.AA08224
Posted: Wed Jun  4 21:33:42 1986
Date-Received: Thu, 5-Jun-86 10:01:45 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 26
Approved: info-68k@ucbvax.berkeley.edu


Mike,

   "My cp/m-80 system did track bufferring.  They solved the problem
	of disk changes by caching(sic) door open interrupts..."

Yeah, that works fine.  The problem is that most 8" (and most 5 1/4)
drives do not produce door-open interrupts. [Of course, then there are 
the "pushy" ones that latch the door and will not LET you take the disk;
and the Persci's that have no door, but will not give you BACK the disk
unless you ask 'pretty please'.]

The other way to detect disk changes is to check for disk-not-ready.
(which is, I suspect, how yours detected the door being closed again)
The trouble with using this for detecting changes is that it normally
needs to be polled, and that means most systems can be fooled during
compute-bound jobs.  The exception is those using NEC 765A (or INTEL
8257(?)) disk controllers.  There the controller chip does the polling
constantly.

If you have this capability, then there is no problem adding caching
to CP/M-68K.  It has the usual hooks (for blocking/de-blocking) which
enable write-through and read-through, as well as the standard 
caching options.  [Now, if only I had a 765A or a door-open interrupt.]

					mknox