On 5/11/19 8:22 AM, Douglas Taylor via cctalk wrote: I have to admit that I don't follow this one. Although I'll admit the possibility that some odd chipset doesn't support the 300Kbps data rate needed to use normal "360K" floppies in a 5.25" HD drive spinning at 360 RPM, I've yet to run across one. Finding a modern PC with legacy floppy support is a different issue. Either using a 5.25" DD-only drive (such as a Teac FD55F) or jumpering a 5.25" HD drive to use 300 RPM are both options. From the standpoint of the hardware, there's no difference between a "720K" 3.5" drive and a 5.25" one so configured. 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. The real issue is that the need for *writing* RX50 FILES-11 format diskettes is virtually non-existent. With the exception of PUTR, the packages that I've seen (dating from 1984) are all for *reading* them. Heck, I've written a couple myself, including one for CP/M-80. --Chuck

On 5/11/19 11:40 AM, Fred Cisin 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). --Chuck

On 5/11/19 2:00 PM, Fred Cisin via cctalk wrote: My first FILES-11 RX01 read-conversion tool was written in PL/M and ran on an MDS800. My second FILES-11 RX01 reading/conversion utility was written largely in FORTRAN. System was an 8080 S100 box with a WD1771 controller. C on an 8080/85 system seems like a horrible waste of hardware, owing to the need for procedure-local variables. Stack-based addressing isn't pretty. Basically to load a 16-bit stack-based integer into BC you have to do something like this: LXI H,offset DAD SP MOV C,M INX H MOV B,M Add to that, that really good "C" compilers for the x80/x86 took some time to mature. My first C on an 8086 was Lattice; compiled on a floppy-based system. But then Microsoft MASM 1.0 was terrible in its own right as well--the list of errata was quite long. I remember mumbling to myself "that's not what I wrote!". --Chuck

On Sat, 11 May 2019, Douglas Taylor via cctalk wrote: {Written in a hurry; making a list of all of the errors is left as an exercise for the reader] You can fool the computer in software. Most of those problems are with DOS/Windoze. There is little or no problem with the FDC (other than as detailed in #3 below). The main change that you are referring to was that some companies cut corners and stopped supporting a 300K bits per second data transfer rate that had been needed to use "360K" floppies in SOME early "1.2M" drives. Don't use THOSE "1.2M" drives on THOSE computers for reading 5.25" 96TPI "720K"/"800K" floppies. 1) the computer can't tell the difference between a "720K" 3.5" drive and a "720K" 5.25" drive, such as Tandon TM100-4, Teac 55F, Mitsubishi 4853, or Shugart/Panasonic/Matsushita 465. My favorite was the 465, since it didn't have the "NEED for index" mentioned in #3 below. The methods of being able to figure out which kind of drive it REALLY is are hardly never implemented in PCs. (cf. undocumented algorithms to identify which processor is present) If you are concerned about the menus in the CMOS SETUP or the choices in the DOS FORMAT program, LIE TO IT! (Tell it that the tax increase is TEMPORARY, that the check is in the mail, that the current software release is completely bug-free) When 3.5" drives and disks came out (also 3" and 3.25"), they were usable in ALL of the 5150s, 5160s, and 5170s. With 5170s, you just had to LIE to the CMOS SETUP and tell the BIOS that your "720K" 3.5" drive was a "360K" 5.25" drive. FDC and BIOS couldn't tell the difference. But, now, you need to lie in the other directions. DOS support of "720K" was finally included in certain OEM versions of MS-DOS 2.11; and then got full support in MS/PC-DOS 3.20. For use of the DOS formats of those drives, you were instructed to use DRIVER.SYS, or the partially undocumented DRIVPARM (present, but not documented in PC-DOS, because it did not work with some "real" IBM BIOS'es and would give an "UNRECOGNIZED" error, although the same boot disk would work with after-market BIOS!) 2) There did exist briefly, some "1.2M" 5.25" drives that could only run at 360 RPM, and required a 300K bits per second data transfer rate for handling "360K" and "720K" floppies in the "1.2M" drive. Support for that data transfer rate might not be present in cut-corner "modern" PCs. On those machines, you need to either use a "720K" 5.25" drive, or, if you need to use a "1.2M" drive, it needs to be one that can run at 300 RPM. Check the jumper settings. 3) However, SOME "400K" and "800K" floppies do still have a problem. WD style disk controllers, such as the 179x series and some other custom disk controllers are capable of writing closer to the index pulse than the NEC 765 style FDCs can handle. The NEC style needs a little time after the index pulse before it can read. Some compare that to "flash blindness", where a human can not see anything immediately after a photo flash. There are numerous kludges to get around that. On most drives (NOT including most TEAC 55), you can successfully read those diskettes by physically blocking the index hole of the floppy, using a SOLIDLY applied write-protect tab. (Do I really need to tell you to make sure that it won't fall off in the drive?) OR, by fashioning a floppy drive data cable with a SWITCH in series with the INDEX signal. Both of those approaches have a very minor problem that many unrelated disk errors will be mis-reported as being "DRIVE NOT READY" (error code 80h), since the FDC doesn't see an index pulse. Some people have had some success by slightly reducing the motor speed (nominally 300 RPM) of the drive! If you still have access to the machine whose disks you want to read, you can FORMAT a disk with an adequate index gap (using software on your PC), take THAT disk back to the alien machine, copy the files onto it, and then bring it back to the PC to read. That also works for a few other minor incompatabilities, such as formats that use an incorrect value in any of the sector header fields. -- Grumpy Ol' Fred cisin at xenosoft.com XenoSoft http://www.xenosoft.com

I wish that I were to have met you 40 years ago! Learning that stuff by error, error, error, trial, and error was inefficient. -- Grumpy Ol' Fred cisin at xenosoft.com On Sat, 11 May 2019, allison via cctech wrote: