Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site aecom.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!houxm!hogpc!houti!ariel!vax135!floyd!cmcl2!philabs!aecom!glen From: glen@aecom.UUCP Newsgroups: net.micro.cpm Subject: Re: Neophyte CP/M 2.2 Question (BIOS disk flush) Message-ID: <554@aecom.UUCP> Date: Wed, 2-May-84 10:54:05 EDT Article-I.D.: aecom.554 Posted: Wed May 2 10:54:05 1984 Date-Received: Fri, 4-May-84 05:11:52 EDT Organization: Albert Einstein Coll. of Med., NY Lines: 36 In reply to: Mark Becker 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