24 Aug
2012
24 Aug
'12
6:15 p.m.
On 24 Aug 2012 at 20:48, Dave McGuire wrote:
But even more problematic than that,
"F_CLOSE" is a BDOS call, not a
BIOS call, and the BIOS doesn't know when a file is being closed.
(IIRC)
So one wouldn't be able to do this in the BIOS, it would require a
modification to the BDOS.
...and that's just my point. I suppose that the BIOS could "hook"
the BDOS interface, since it (the BIOS) is responsible for plugging
location 5 with the BDOS entry point. If it weren't for some
programs using the address of the jump in location 5 for the base of
the BDOS, it might even work.
But heck, the BDOS already communicates to the BIOS in read/write
sector calls what *kind* of read or write is happening (used by
block/deblock BIOS code). There's no reason that the BDOS couldn't
call the BIOS to inform it that it should secure the drive heads.
One could do this with an idle timer in the BIOS
keyed on console
I/O.
Similarly, the BDOS could inform the BIOS of any open files; i.e.,
when it's safe to change disks. I have a BIOS that can detect disk
changes (it polls the write-protect sensor on 5.25" drives), but I
can't do anything with the information. On DX85M, we flashed a
message on the screen and waited for the user to replace the disk if
there were files open for write/modify access.
That awful "BDOS ERR: R/O" really threw users for a loop.
While CP/M 1.4 was adequate for simple MDS systems, I didn't see that
much progress in accommodating newer hardware and bullet-proofing in
later versions.
I thought it was remarkable that DRI never bothered to move the
location of the second default FCB after the introduction of the Z80.
It made life interesting if your system used the Z80 TRAP interrupt
for anything.
My list is very long...
--Chuck
P.S. Were there any x80 systems that attempted to implement paged
virtual memory?