13 Jun
2014
13 Jun
'14
6:36 a.m.
I'm told that some vendors shipped CP/M systems that would auto-detect
between several disk formats, e.g., 8-inch single density vs double
density, but I've never used one. Obviously the BIOS would change the
values in the disk parameter block. At what point is it safe for the BIOS
to do that? Obviously you wouldn't want to do format detection every time
the BIOS SELDSK function is called, but is it reasonable to do it whenever
READ or WRITER are called after a SELDSK of a changed drive number? Or is
there a way the BIOS can figure out specifically when the BDOS is trying to
log in a new disk?
13 Jun
13 Jun
2:52 p.m.
Yes, you want to do it when the disk is first logged in. You can determine
this by checking the low order bit of register E when SELDSK is invoked.
If the bit is clear, the disk is being logged in and id is
safe/appropriate to modify the corresponding DPB as needed.
--Wayne
On Thu, Jun 12, 2014 at 11:36 PM, Eric Smith <spacewar at gmail.com> wrote:
I'm told that some vendors shipped CP/M systems
that would auto-detect
between several disk formats, e.g., 8-inch single density vs double
density, but I've never used one. Obviously the BIOS would change the
values in the disk parameter block. At what point is it safe for the BIOS
to do that? Obviously you wouldn't want to do format detection every time
the BIOS SELDSK function is called, but is it reasonable to do it whenever
READ or WRITER are called after a SELDSK of a changed drive number? Or is
there a way the BIOS can figure out specifically when the BDOS is trying to
log in a new disk?
8:21 p.m.
More mostly irrelevant anecdotes, without technical content:
Many computers had code to select between a few different formats.
Howard Fullmer (Morrow Designs) told me that he intended to implement
massive automatic format recognition, with MANY formats. He was going to
come by my office to get data for many formats, and borrow sample disks
for testing. But, we fell out of touch. Eventually, I heard that he had
died. Then Morrow Designs died. Then George Morrow died.
In XenoCopy, I implemented some partial semi-automatic format recognition.
IFF the user turned that on, the program would do a few specific reads,
and gray-out choices in the format selection menu that were obviously not
compatible, such as bytes per sector, sectors per track, sided, and track
density.
I did NOT implement the next step, which would have been further
eliminations based on content of sectors ("That sector CAN NOT be a CP/M
directory sector, therefore, gray-out all formats that would be using that
sector in the DIRectory.")
I kept user over-rides available, since there were many things that could
go wrong, such as an 8 sector per track format that was recorded
(successfully) on a disk formated for 9 sectors per track, or the high
incidence of single sided formats that were re-recorded on disks that had
previously been used for double sided with completely different format
("Front side looks like Dec Rainbow, but the back side of the disk looks
like the back side of IBM 360K" (MOST Rainbow disks were factory
formatted, but there were SOME third party formatting programs available))
Watch out, that track 0 was often a different format than the rest of the
disk, and occasionally, when a disk gets re-used, the system trracks don't
always get reformatted and "corrected" for the new format that it is being
used for, much like the second side issue for SS formats.
--
Grumpy Ol' Fred cisin at xenosoft.com
3853
days inactive
3853
days old
4 comments
3 participants
participants (3)
-
cisin＠xenosoft.com -
spacewar＠gmail.com -
wwarthen＠gmail.com