On 24 Aug 2012 at 18:39, allison wrote:
Simple, Most of the systems ran without interrupts and
did zero
timekeeping so
while the ap was running it was in control, when the ap returned
control CPM was not keeping time either. In essence there was no
"idle time" as that concept is only known to multitasking or forground
background systems that used blocked IO and task lists to manage what
the CPU was doing( rather than spinning in loops).
Easy, move the heads when a close is issued. Yes, I know that many
programs didn't bother with open or close calls, as CP/M cared only
that the FCB described something, whatever it was. Move the heads
when the system is sitting at a command prompt. Moving one cylinder
is trivial in terms of timing compared to the average rotational
latency of a disk.
Not even MP/'M or CP/M 3.0 that actually had timekeeping would do
this. MS-DOS had timekeeping and didn't do that.
When disk got larger Deblocking was common and that
results in caching
of at least one physical sector but since ram was considered a scarce
commodity a whole track cache was rarely done. The later systems with
banked ram and running interrupts would include time outs and other
features sorely needed and often omitted in early BIOSes.
What does a whole track cache have to do with this?
Turns out that 95% of the directory kills were either
power up or
down, was due to disk in place and door closed. The rest were if the
system was flaky and would crash during write or randomly.
Yes, so why not position over a junk track when the system isn't
actively doing disk access? Apple OS writes a duplicate directory at
the end of the disk, but it's usually far out of sync with the main
one.
FYI the directory was the first accessible blocks on
the disk, and
literally that meant after the system tracks.
Well yes and no--I can show you some CP/M layouts where that's not
true--the National Semi BLC 86/12 system puts the directory on track
39 with data blocks allocated alternately first on cylinders below
the directory, going toward cylinder 0 and the system boot tracks,
then cylinders after the directory, going toward cylinder 79. There
are other similar CP/M implementations. And not all CP/M
implementations start the directory on a track boundary (the Allen-
Bradley Advisor+ and the BU-60 aircraft test set, for example--or the
Coleco Adam).
The point is that losing system boot tracks isn't a big deal--files
can still be read from the disk--and with a utility, the boot tracks
can be restored. Killing both file name and allocation information
is a catastrophe.
...so if the CPU/floppy box lost power first it wrote
a lot of zeros
on the current track of all the drives.
Not zeroes, but a genuine DC erase--if the CPU lost power before the
disk unit, WRITE GATE would be pulled low and the entire track wiped
with a DC level. I'm looking at a Z37-written floppy where that's
happened. I can be somewhat successful in recovering file data with
some guessing, but there's no way to recover file names.
--Chuck