Possible PUTR bug?

[Fred Cisin]

>>> 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     		cisin at xenosoft.com