jss@sjuvax.UUCP (Jonathan Shapiro) (11/30/84)
[Aren't you hungry...?] Is there any general concensus about the best way to handle IO to slow devices? I have been thinking about building a board whose disk interface has a sort of staging area of 4K or so and then tells the processor its there and come get it... This would allow, for example, hard disk backup which happened in bursts at memory to memory speed rather than memory to disk speed. My plan is to put a separate processor and bus on the disk interfac and connect these to the main bus through an IO port. Any thoughts/suggestions? Jon Shapiro P.S. if this is a repost, I'm sorry. Forgot to sign my name to the first one, but I cancelled it before it left the local site, so hopefully it won't go out.....?????
dmt@ahuta.UUCP (d.tutelman) (12/02/84)
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