• Please review our updated Terms and Rules here

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

Depends on the platform, but the most straighforward way, IMOHO, is to hook Interrupt 1ch This is a dummy routine called by the INT 8 servicer and normally contains only an IRET instruction.

Why do this rather than 08h? Because there are some utilities and games that run the 8254 with a shorter interval to get better granularity. The usual way is to get the 8254 to interrupt, say, 4X more often, then program in a divide by 4 routine in the INT 8 servicer before passing the interrupt on to the regular time-of-day routines. 1Ch occurs down the chain, so no matter what you're running, the tick rate should be constant.

Besides, this is why interrupt 1Ch is part of the BIOS. :)
 
pcdosretro said:
You would really need a device driver which accessed the secondary floppy controller (370h-377h) for DOS to see the drives since PC BIOSes only access the primary controller for INT 13h access which is what the DOS builtin disk driver uses. Even then DOS may not recognize the disks since they aren't in a standard floppy format (160KB, 180KB, 320KB, 360KB, 720KB, 1.2MB, 1.44MB, 2.88MB). I don't recall a specific media descriptor byte code for 8" floppy drives though there were two old unused codes (FAh and FBh).

Would it be possible to use a null modem serial cable to transfer over whatever data you have from whatever computer used the 8" floppy drives to a PC ? Seems like that would be easier than trying to get an anachronistic device from the 70s to work with a PC from the 80s.
Click to expand...

I remembered my first "Personal Computer", the S-100 bus Morrow Designs Decision I, had a floppy controller that supported 4 diskette drives and provided both a 34-pin 5.25" FD header and, IIRC a 50-pin 8" FD header. I never thought about the differences at the time, but all 3 diskette drives (I had by that time installed the 5.25" FH 5MB HD in place of one 5.25" FD) worked in perfect co-operation. The 5.25" diskettes were 10spt, hard-sectored, but that's a minor issue in retrospect. I remembered the 8" (Tandon TM800?) drives were capable of 800KB double-sided , maximum.

Media Descriptors:
http://stanislavs.org/helppc/media_descriptor_byte.html

HTTH,
Tim
 
Last edited:
I hope to have the motor off timer implemented this weekend. The roadmap after that is:
1) correct crashing in the error handler
2) get formatting working
3) make build with DSDD 8" parameters
4) abstract driver to allow choosing between drive types with command line switch at loading

Got a set of 10 NIB DSDD 8" disks for testing on ebay for $15 shipped, so that's nice :D
 
I was able to get the driver to read and write to SCP 8" SSSD DOS disks. Both 86-DOS 1.00 and MS-DOS 1.25 :cool:

Figuring out why the driver crashes on any error (only when using the secondary controller) is still vexing me. :(
 
been trying to get DD SCP floppies working, but when I set the logical sector size to 1024B in the BPB DOS actually generates a "sector size too large" error when I try to load the driver

I thought DOS supported 1024 byte sectors? Is there some other parameter I need to change to trick it into allowing that? (media byte, DOS drive type - I'm using '4') ?
 
Japanese NEC PC98 MS-DOS supports 8x1024 byte tracks, but that's a different matter--you can't run NEC MS-DOS on a standard PC (hardware and BIOS incompatible). 512 byte sectors are pretty firmly embedded in stock MS-DOS. I can't recall if a DOS patch was needed for the DOS 3 dodges to get around the 16-bit maximum sector number for hard drives, or if it was simply handled with a special driver. I suppose you could try hacking the table pointed to by interrupt 0x1E

When I wrote drivers for the Apricot and PC98 disks, I used blocking/deblocking routines to provide a 512-byte sector interface. Simple enough and doesn't require any particular version of DOS or patches.

Windows NT... handles 1024 byte sectors just fine.
 
Chuck(G) said:
When I wrote drivers for the Apricot and PC98 disks, I used blocking/deblocking routines to provide a 512-byte sector interface. Simple enough and doesn't require any particular version of DOS or patches.
Click to expand...
I suspected this would be the approach I would need to take. Just thought it was strange though as I have seen multiple sources saying DOS supports 1024B sectors, including a post from pcdosretro in this very thread.
 
Progress is being made.

1) correct crashing in the error handler
2) get formatting working
3) make build with DSDD 8" parameters
4) abstract driver to allow choosing between drive types with command line switch at loading

Also the secondary motor timer is done. Got to get that crashing fixed on disk errors. Then to implement a blocking/deblocking routine for the 1024 byte sectors

As of right now the driver is totally functional, if bugged with all standard drive types and 8" SSSD disks, on either the primary or secondary FDC.

Going to implement a command line switch to choose the original 86-DOS parameters for the 8" disks vs the DOS 1.25/2.0 ones as well. The only difference is the size of the root directory, and the 86-D SSSD disk has 2 reserved tracks.
 
86-DOS 8" mode is done

I've got to say, having direct access to an 86-DOS 1.00 8" disk in Windows 3.11 and over the network via FTP puts a goofy grin on my face.
 
There is a bug where the request packet or the pointer to it occasionally gets corrupted, resulting in the driver doing random things (including occasionally clobbering track0).
Once that's fixed I'll do a release
 
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.
 

Attachments

  • DOSFDRV.zip
    4.7 KB · Views: 38
maxtherabbit said:
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...

Excellent. Thanks for the release. A few questions:

1. So what does this driver exactly do? I.e. if a BIOS does not support a drive type (say 2.88MB) does this driver allow support for that drive type as long as the controller chip does so? This would be applicable in many EISA/VLB systems where the system BIOS provides the SW end of drive access but the FDC is on an add in card many times w/o a built in BIOS. So the FDC can do 2.88MB drives but the motherboard BIOS only allows for 1.44MB disks.
2. How does this compare to the config.sys option DRIVEPARM or the DOS device driver DRIVER.SYS? Is it complimentary, a replacement, or something completely different?
3. Any plans to implement the SS DOS formats (160KB/180KB) or the 320KB format? or 720KB in 1.2MB drives?
4. I have a 2.88MB drive and disks connected to a CCIV. What kind of testing would you need?

Great work!
 
1) yes the purpose of it essentially is to transcend BIOS limits. If the hardware can support the drive type it will work
2) it is meant to be a more-fully featured replacement for DRIVER.SYS - with support for secondary FDC and 8" drives that DRIVER.SYS lacks
3) not at this time, since it is easy enough to use them in drives driven by the BIOS - I could easily define a custom profile for one of those situations if you really need it. Making it "just work" would be a bit more work than I'm interested in just now
4) just run it and let me know if you can access files and such, if it works it works
 
maxtherabbit said:
I thought DOS supported 1024 byte sectors? Is there some other parameter I need to change to trick it into allowing that? (media byte, DOS drive type - I'm using '4') ?
Click to expand...

According to Microsoft, DOS does for 1.2MB DSDD 8" Disks

Code: 
Standard Floppy Disk Formats Supported by MS-DOS

3.5 Inch - Formatted Capacity 

			720K      1.44 MB   2.88 MB
# of Heads (Sides)         2         	2         2
# of Cyls (Tracks)        80           80        80
# of Sectors/Track         9           18        36
Total # of Sectors      1440         2880      5760
# of Free Sectors       1426         2847      5726
# Sectors/Cluster          2            1         2
Total # of Clusters      713         2847      2863
# Sectors/FAT              3            9         9
# of FAT Copies            2     	2         2
# of Root Dir Sectors      7           14        15
# Reserved Sectors         1            1         1
# of Hidden Sectors        0    	0         0
# of Bytes/Sector        512          512       512
# of Bytes/Cluster      1024          512      1024
# Root Dir Entries       112          224       240
Media Descriptor          F9           F0        F0
Recorded Density      Double         High      High
MS-DOS Version Began    3.20         3.30      5.00
DRIVER.SYS Switch       /F:2         /F:7      /F:9
FORMAT.EXE Switch     /F:720      /F:1.44   /F:2.88
Change-Line Support      YES          YES       YES

5.25 Inch - Formatted Capacity 

			160K     180K	     320K 	360K      1.2 MB
# of Heads (Sides)         1        1       	2           2           2
# of Cyls (Tracks)        40       40          40          40          80
# of Sectors/Track         8        9           8           9          15
Total # of Sectors       320      360         640         720        2400
# of Free Sectors        313      351         630         708        2371
# Sectors/Cluster          1        1           2           2           1
Total # of Clusters      313      351         315         354        2371
# of Sectors/FAT           1        2           1           2           7
# of FAT Copies            2        2           2           2           2
# of Root Dir Sectors      4        4           7           7          14
# Reserved Sectors         1        1           1           1           1
# of Hidden Sectors        0        0           0           0           0
# of Bytes/Sector        512      512         512         512         512
# of Bytes/Cluster       512      512        1024        1024         512
# Root Dir Entries        64       64         112         112         224
Media Descriptor          FE       FC          FF          FD          F9
Recorded Density      Double   Double      Double      Double        High
MS-DOS Version Began    1.00     2.00        1.10        2.00        3.00
DRIVER.SYS Switch       /F:0     /F:0        /F:0        /F:0        /F:1
FORMAT.EXE Switch     /F:160   /F:180      /F:320      /F:360      /F:1.2
Change-Line Support       NO       NO          NO          NO         YES

8-Inch - Formatted Capacity

			250K     500K     1.2 MB
# of Heads (Sides)         1        2          2
# of Cyls (Tracks)        77       77         77
# of Sectors/Track        26       26          8
Total # of Sectors      2002     4004       1232
# of Bytes/Sector        128      128       1024
# of Bytes/Cluster       512      512       1024
# Sectors/Cluster          4        4          1
Total # of Clusters      497      997       1227
# Reserved Sectors         1        4          1
# of Hidden Sectors        3        0          0
# Sectors/FAT              6        6          2
# of FAT Copies            2        2          2
# Root Dir Entries        68       68        192
Media Descriptor          FE       FD         FE
Recorded Density      Single   Single     Double
MS-DOS Version Began    1.00     2.00       2.00
Change-Line Support       NO       NO         NO

This is according to "Standard Floppy Disk Formats Supported by MS-DOS" MS Article ID: Q75131
 
I implemented those parameters exactly as specified in the article into my BPB. When I passed the BPB to DOS, it said "sector size too large" and kicked the driver. Somewhere along the way, MS must have pulled support for 1024 byte sectors. I'm testing on PC-DOS 7
 
The information may be a bit dated; it's true that MS-DOS for the NEC systems does support the 8*1024 track size (Windows NT does also), but the later stock domestic versions seems to have 512 byte sectors hardwired in. Years ago, there was some discussion about this and it was ventured that if MSDOS boots from 1024 byte/sector media (as specified by the DIPT pointed to by the interrupt 1eh vector) , then the large sector support is enabled. One can verify this by checking the MSDOS 6.0 source available on the web.

My guess is that this support went the way of the "set switch character" DOS API call.
 
Well the article is last updated in 2003. However, it does clearly say it only applies to DOS 1.0 to 6.22. Have you tried testing the driver under Microsoft dos 6.22? IBM may have removed the support much earlier.
 
You must log in or register to reply here.
Back
Top