<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>
Date   : Wed, 02 May 1984 07:54:05-PDT (Wed)
From   : ihnp4!houxm!hogpc!houti!ariel!vax135!floyd!cmcl2!philabs!aecom!glen@Ucb-Vax.ARPA
Subject: Re: Neophyte CP/M 2.2 Question (BIOS disk flush)

In reply to:  Mark Becker <CENT.MBECK%MIT-OZ@MIT-MC.ARPA>

Welcome, Mark, to hacker's paradise - BIOSland.  The disk flush 
you saw in the BIOS CONIN call is very common, especially on 
systems implementing disk sector sizes of over 128 bytes.  The 
reason is simple: CP/M deals with record sizes of 128 bytes, so 
the BIOS must buffer all disk operations if the sector size is 
larger in order to accommodate the smaller read/writes.

The flush in your BIOS is simply a safety feature.  Since writes 
are also buffered, what would happen if you changed disks while 
the system still had the buffer in memory?  Simply, chaos.  You'd 
lose the ending sectors of your file and maybe the file entry 
from the directory itself (especially if the BIOS buffers the 
directory).  Therefore, the BIOS dumps the buffer at the point 
when most (system-friendly) users change disks - at console 
input.  

Some BIOSes even dump the buffer on console output for a case
where the system churns for a while on disk and then starts 
outputting pages of stuff to the screen or printer.  If the user 
got frustrated, he might just reset the system and therefore lose 
the buffer contents.  

This is one bit of foresight you can thank your manufacturer for!

                         - E N J O Y ! -
                                               Glen
- - - - - -
>From the core dump of:

Glen Marianko
ConIX Software Division,         |   Microcomputer Division,
Computer Helper Industries Inc.  |   AECOMputing Center

{philabs,pegasus,rocky2,ihnp4}!aecom!glen
<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>