Possible PUTR bug?

[Chuck Guzis]

On 5/11/19 11:40 AM, Fred Cisin via cctalk wrote:
> On Sat, 11 May 2019, Chuck Guzis via cctalk wrote:
>> In the case of RX50 on the PC, it doesn't matter.  The format is 10
>> sectors of 512 bytes, which isn't supported by the PC BIOS in any
>> regular sense (9 sectors is the norm).  So most packages that deal with
>> FILES-11 RX50 floppies on a PC use direct hardware (chip) access and
>> bypass the BIOS completely.  PUTR is one such package.
> 
> If the only problem is that there are 10 sectors per track, that can
> still be done WITH THE BIOS, using Int1Eh in conjunction with Int13h,
> except for the potential problems with 765 index "flash blindness".  For
> formatting tracks, you can use Int1Eh to alter the sector gaps.

But that isn't the only issue, even assuming that you have a
well-behaved BIOS. Many are not.

The other gotcha is that if you want to run a 5.25" HD drive declared as
a "1.2M" in the BIOS, the assumption made by the BIOS is that you want
to double-step.  That's a harder one to defeat, although it can be done
by tinkering with the flags in 0490h and 0491h, but due to BIOS
implementation differences, this is not perfectly reliable.

Of course, you can, as mentioned, modify a 1.2M drive to run at 300 RPM
and tell the BIOS that it's a 720K unit, but you won't be able to handle
48 tpi disks without a device driver to do the double-stepping for you.
Telling potential customers how to modify a drive that you've never seen
is even more entertaining, particularly in the pre-web world. So you're
back in the same boat.

All in all, using the BIOS to do RX50 work was a support nightmare for
me--there was always *someone* out there with a no-name PC using a
strange BIOS that wouldn't work.

I found that doing direct access was far more reliable in the long run.
(see SIMTEL20 RAINDOS for my implementation of a DOS device driver for
Rainbow 100 floppies, circa 1990).

--Chuck