• Please review our updated Terms and Rules here

DOS File Level access to Secondary (370H) FDC - Driver

So to satisfy my curiosity, I tried brute forcing the max sector size to 1024b by grabbing a pointer to the SYSVARS table and just editing the value. It "works" in the sense that DOS will load the driver, but basically all the built in commands choke on any attempt to access the drive. Oh well, guess 512b sectors are just in too deep with modern versions of DOS.
 
That's been my suspicion. I can check some of my PC98-formatted 1K sector images, but I don't recall seeing later DOS versions on them.

Virtualizing sectors to 512 bytes (i.e. blocking/deblocking) is probably the only reasonable way to handle things in DOS. NT is a different matter, however.
 
Shadow Lord said:
Have you tried testing the driver under Microsoft dos 6.22? IBM may have removed the support much earlier.
Click to expand...

I've tested the driver under MSDOS 6.22, and it will not load (and generates an error message to that effect) if any 8" drive type (3 or 4) is specified. This driver works fine for any 5.25" or 3.5" drive type connected to a secondary controller.
 
hmb said:
I've tested the driver under MSDOS 6.22, and it will not load (and generates an error message to that effect) if any 8" drive type (3 or 4) is specified. This driver works fine for any 5.25" or 3.5" drive type connected to a secondary controller.
Click to expand...

Interesting, I use it daily on PC-DOS 7 with Type 3. Type 4 is disabled in the release

I'll spin up a MSDOS boot disk and see if I can duplicate your issue, what is the exact error you receive when trying to select type 3?
 
Last edited:
maxtherabbit said:
.... what is the exact error you receive when trying to select type 3?
Click to expand...

Encouraged by your comment that it does work with PC-DOS 7, I gave it another try. I must have tried many combinations of things over the course of the day today which didn't work, but when I edited the DEVICE line just now to add /D:3 in an attempt to reproduce the wording of the error message - it works !

There were two issues that did slow me down:
- the command line parameters must be provided in the precise order provided in your instructions. Out-of-order parameters will create an error message - which might have been the cause of my problem.
- in retrospect it's obvious that the "physical unit number" is with reference to the controller, and not the computer. It took me a few tries to figure out what the driver was looking for.

Thanks!
 
hmb said:
- the command line parameters must be provided in the precise order provided in your instructions. Out-of-order parameters will create an error message - which might have been the cause of my problem.
Click to expand...
that's not how it's written, it will parse them in any order
 
maxtherabbit said:
that's not how it's written, it will parse them in any order
Click to expand...

...and of course, you are absolutely right. I tested it again, and this time I had no problem with the driver loading irrespective of the order of the parameters.

Now that all works, I've got to test it out reading my 8" disk copy of SCP 86-DOS that I've had laying around for many years.
 
So, a couple of months ago now I mentioned in the sergey FDC thread I would be updating this driver to support copying between multiple FDDs controlled by the secondary FDC. I knew both then and now the source of the problem - the tick routine I hooked into the user timer interrupt to turn off the motors on the secondary FDC is being loaded twice (once for each instance of the driver) and when doing a more lengthy operation, the tick routines (since they are not mutually aware) will occasionally turn off the motor of the active drive in the midst of a sector transfer.

I was faced with a decision - either check for an existing instance of the driver in memory at init time and don't load the tick routine twice, or rewrite the driver front end to support multiple units since the underlying disk IO library supports them. Since the former would require some really hacky stuff to hook instance 2 of the driver into the countdown timer and DOR image from the first instance, I chose the latter. Not to mention saving 6kB of memory for each extra drive at the cost of a few more bytes one time.

Work stalled due to various real life factors but I still intend to complete it. I could use some input on how to format the command line arguments for multiple units. Right now you can specify physical unit number, drive format, port (for secondary), and "SC" for the 86-DOS variation of SSSD 8" disks, in any order. This will need to be overhauled to allow for a more matrix-like input where you can specify these parameters for each different unit managed by the driver. I'm not sure the best way to go about that, for UX purposes. Thoughts?
 
maxtherabbit said:
OK I've squashed the bug, it was stack corruption. Release attached to the post. To the best of my knowledge this version is working, but PLEASE do not use this driver to try to read irreplaceable disks without write-protecting them. If you do you are bad and should feel bad.

DEVICE=DOSFDRV.SYS /U:unit [/D:type] [/P:port] [/SC]

Where "unit" is a physical unit number (0-3) and "type" is a DOS floppy type. If no type is specified, the profile defined at build time will be used. In this build, that is a standard 40 track DSDD 5.25" disk, but it is there to give me the ability to easily make custom builds for odd disks. Type 3 refers to a MSDOS formatted SSSD 8" disk. Type 4 is 8" DSDD but is disabled until I get blocking/deblocking implemented. With type 3/4, an optional "/SC" may be added to have the driver use the original SCP 86-DOS format. "/P:port" is optional and specifies the hex address of the controller to be used.

The other valid types are:
0 360kB DSDD 5.25"
1 1.2MB DSHD 5.25"
2 720kB DSDD 3.5"
7 1.44MB DSHD 3.5"
9 2.88MB DSED 3.5" (untested, I don't have any drives or media)

If you make an error in the switches, the driver will not load and will pause the system, beep at you and remind you the correct syntax. If you specify a drive on a secondary FDC, the driver will reset said FDC and attempt to seek the unit specified to track 0 at initialization. If this fails, (due to incorrect unit number, drive not attached, etc.) the driver will not load and will pause the system with an error message. Formatting IS implemented, but may be buggy. Needless to say, IBM-compatible MSDOS FORMAT.COM is not going to write out boot sectors compatible with SCP S-100 machines. The disks will be accessible for R/W operations on original hardware, just not bootable.

One more thing - there is no support implemented in this release for using disks smaller than the profile associated with the device type. I.e 720kB disk in HD 3.5" drive, 360kb disk in 1.2MB HD drive, or 160kb/180kB/320kB disks in anything.
Click to expand...


Hi maxtherabbit! I am new on vcf, have highschool time experience with trs-80 and c64, favourite was assembler. Now I plan to read/write floppies in single density format on PC in order to create media for the old machines. So I bought an adaptec aha-1542b and try to use it (only FDC) in a 440bx pc without any success.

The fdc part of the 1542b is not visible to w95/98 nor to dos, tried several bios settings, dc2.sys and sdrive.sys with no result. Your driver was the first with which the floppy connected to the 1542b gave some sign of life: motor spinned and led lighted, however no head moving or such unfortunately.

Do you have any idea what bios settings or config.sys content would help? Maybe the 440bx is not compatible with the card? I checked several sites/forums, and many users complained about the same issue.

Thanks for any advice in advance, all the best, zolarp
 
zolarp said:
Hi maxtherabbit! I am new on vcf, have highschool time experience with trs-80 and c64, favourite was assembler. Now I plan to read/write floppies in single density format on PC in order to create media for the old machines. So I bought an adaptec aha-1542b and try to use it (only FDC) in a 440bx pc without any success.

The fdc part of the 1542b is not visible to w95/98 nor to dos, tried several bios settings, dc2.sys and sdrive.sys with no result. Your driver was the first with which the floppy connected to the 1542b gave some sign of life: motor spinned and led lighted, however no head moving or such unfortunately.

Do you have any idea what bios settings or config.sys content would help? Maybe the 440bx is not compatible with the card? I checked several sites/forums, and many users complained about the same issue.

Thanks for any advice in advance, all the best, zolarp
Click to expand...

I have successfully used my driver with an 1542B card. Make sure the card is set to secondary port for the FDC (J7 pin pair 1 ON) and make sure the FDC IRQ is set to 6 and DMA is set to 2 (J8 pin pairs 1,2,4,6 ON - all others OFF).

Consult the adaptec manual for more detail on the jumpers. http://download.adaptec.com/pdfs/user_guides/aha1540b_um.pdf Please note that the secondary FDC port address listed in the manual is an error - the correct port setting for the driver is /P:370

If after verifying all these settings and you still can't get the drive to transfer sectors, it is probably because your onboard FDC on the motherboard does not properly handle the register bit to disable IRQ/DMA. If that is the case you can either use a different motherboard or try to disable your motherboard FDC outright. Barring that your only other option would be to use software which supports an alternate IRQ/DMA for the secondary FDC such as Chuck's 22disk
 
Thanks a lot for the driver! It worked perfectly with my Thinkpad Dock I and Adaptec AHA-1542CF controller to drive a 5.25" FDD.
 
Shadow Lord said:
Huh? What happened?

More importantly has he moved the project to its own site or GitHub or something similiar?
Click to expand...

I'm back. No github, the project is closed source at the request of Chuck who was kind enough to share the disk I/O library with me upon which it's built
 
Thanks for the welcome frens :)

A refactor of the device driver is planned to allow one driver instance to support 2 or more drives. The library from Sydex is capable of it and I want to make use of that. It will also eliminate the bug where you can't copy files directly from drives managed by two instances.
 
I can report that Max's driver is working on a Adaptec 1542CF which does not have jumpers for IRQ/DMA. like the 1542B. Only thing to do is set the FDC base port to 0x370h in the Option ROM setup.
 
You must log in or register to reply here.
Back
Top