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.
On Sat, 11 May 2019, Chuck Guzis via cctalk wrote:
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).
Oh, SO TRUE!
It is FUNNY (not "ha-ha") that although the stated purpose of having the
BIOS separate from the file system and command processor was to cover over
incompatabilities ("DOS est omnis divisa in partes tres"), the hardware
was sometimes more compatible than the "compatability layer" made up of
the BIOS!
I always advised everybody not to use a 96tpi drive for wwriting to 48tpi
disks. Too many people refused to understand that you had to format a
virgin (or bulk-erased) disk in the 96tpi as the only way to avoid the
failure to completely RE-write the full width of the track on disks that
would later go through attempts to read on a 48tpi.
I always tested everything thoroughly on real IBM hardware. Not that I
could comfortably afford that premium, but it let me make the
sanctimonious statement "It works on REAL IBM. If it doesn't work on YOUR
after-market machine, that means that it is not TRULY compatible. That's
not necessarily BAD, if they wanted to do things in a BETTER WAY, but we
can't guarantee that all "compatible" machines are "compatible ENOUGH".
Please provide us as much detail as you can of any problems, and we will
make a good faith effort to make changes to be able to include your
systems."
PC-WORLD once used Xeno-Copy as "the acid test of compatability"! They
failed to mention that they used a much earlier version than what was
being sold, and that the current version at the time that they used the
early version for testing would work on every one of the machines that
they said could not run it.
I considered [and started] writing a PC TEST program called "XenoProbe :
The Acid Test" that would seek out and identify differences between
machines, starting with exploiting side effects to identify the
processor, etc.
The reason for the early incompatability, as many of you have figured out,
was that what little assembly/machine language that I know, I learned
working on XenoCopy. I do not expect to live long enough to ever catch up
with the knowledge and abilities of many on this list. (Chuck and ARD are
not the only ones)
In fact, the FIRST version (as used by PC-World) was written in BASIC, and
compiled with BASCOM, using Int1Eh and a call to Int13h. As suggested by
Brett Salter, I passed the return value back through the Floating Point
Accumulator! THAT was what made it incapable of running on anything other
than REAL IBM 5150. The title screen SAID that it would not work on
anything other than IBM.
I also had a trivial piece of self-modifying code,
and that is how I found out about the change in the pre-fetch buffer size
from 8088 to 80286.
I rewrote version 2.00 in DeSmet C, with cleaned up calls from high level
to machine language functions, saving and restoring screens, etc.
Although I enjoyed DeSmet C, I used Microsoft C for all subsequent high
level language progams that I wrote. For example, I wrote the screen
capture TSR of "XenoFont" in MASM, and the printing program in Microsoft
C; I wrote "Sales tax Genie" (TSR) in MASM, but then later renamed the
.COM file to .EXE to use it as the "stub" program of a Microsoft C
Windoze program, to have a single file that could load the TSR in DOS, AND
be able to run as a Windoze program. I never got around to redoing the
TSR formats to be able to ALSO load them as device drivers (lets you get
them into lower memory!); I intended to eventually create a single
executable file format that could be loaded by CONFIG.SYS, CMD.COM, AND
Windows.
--
Grumpy Ol' Fred [email protected]
