Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.PCS 1/10/84; site ahuta.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!whuxlm!whuxl!houxm!ahuta!dmt
From: dmt@ahuta.UUCP (d.tutelman)
Newsgroups: net.micro,net.arch,net.dcom
Subject: Re: I/O consensus
Message-ID: <136@ahuta.UUCP>
Date: Sun, 2-Dec-84 09:32:34 EST
Article-I.D.: ahuta.136
Posted: Sun Dec  2 09:32:34 1984
Date-Received: Tue, 4-Dec-84 05:37:42 EST
References: <695@sjuvax.UUCP>
Organization: AT&T Information Systems Labs, Holmdel NJ
Lines: 36

REFERENCES:  <695@sjuvax.UUCP>

Yes, there are boards to buffer slow I/O devices, specifically disks
and printers. Here are a few of the design considerations for such
an animal, dictated by the nature of the OSs used by most micros:

	Since the common I/O for micros (MS-DOS and CP/M) are not
	concurrent, there isn't much advantage to going to "burst
	mode" I/O. Instead, you've got to suck up the whole request
	and execute it. This dictates a lot of buffer memory. For
	instance, most practical printer buffers have at least 64K.
	The most common floppy disk buffer is RAM-disk (generic, not
	tradename), which typically starts at 256K and goes up from there.

	Since the common OSs don't use device-independent I/O, the OS
	thinks it knows how to control each kind of device.
	(Oversimplification; I'll explain below.) This means that the
	board has to EMULATE the controller chip for each kind of
	device to be handled. I know of three ways to cope with this:
	(1) Make a separate board customized for each type of device.
	    Historically, this is what has been done.
	(2) Make a single board with a micro on it, programmed to
	    emulate the controllers for all the devices to be buffered.
	    For a given set of devices, this requires about as much
	    program as (1), but saves a little hardware.
	(3) The OS really is "sort of" device independent; most of the
	    dependencies are built into the Basic Input-Output System
	    (BIOS) for the specific computer. The BIOS is generally in
	    ROM on MSDOS machines, and either ROM or disk-loadable
	    RAM on CP/M. By changing the BIOS, you could get a single,
	    consistent emulation on the I/O buffer board, but at the
	    expense of re-doing the BIOS. I'm not sure which I'd rather
	    do. On second thought, having done some BIOS hacking, I'd
	    take my chances doing it on the board.

				Dave Tutelman