• Please review our updated Terms and Rules here

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

It doesn't matter. It's simple enough to write a blocker/deblocker for any sector size (that's a power of 2) and fake 512 byte sectors.

Can't comment on this but if it works as is under MSDOS 6.22 then that would at least be a good start. Also if it is working under DOS 6.22 couldn't the work around for PCDOS 7 break it? I am just asking as I have no idea either way...
 
Can't comment on this but if it works as is under MSDOS 6.22 then that would at least be a good start. Also if it is working under DOS 6.22 couldn't the work around for PCDOS 7 break it? I am just asking as I have no idea either way...

I'm like 90% confident that if it doesn't work in PCDOS it won't work in MSDOS either. However I do plan to test on a variety of PC and MS DOS versions out of curiosity. Implementing the workaround would not break anything. DOS would just think the sectors are 512 and carry on
 
Remember the IBM OS/2 XDF floppies? Tracks formatted with 8K, 2K, 1K and 512 bytes per sector = 16+4+2+1 = 23 512 byte sectors. Magic done in the driver. Turned out to be something of a headache for IBM wrt compatibility with some non-IBM machines.
 
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.

Code:
mov	ax,es:[bp].DPB_SECTOR_SIZE
	cmp	ax,maxsec		; Q:is this the largest sector so far
	jbe	notmax			; N:
	mov	maxsec,ax		; Y: save it in maxsec
 
Thought I'd seen that somewhere. bios\msinit.asm it is.

So biggest sector found on boot; installable drivers aren't checked.

That figures--by the time you've booted the system up, it's too late to change the sector size.

But I wonder how many utilities have 512 byte sectors hard-wired in.
 
Probably a good deal of them. I've seen sector size defined as a constant in several source files I've browsed so far
 
Opinion time:
Should I extend the "recalibrate on init" behaviour to units 2-3 on the primary FDC, since anything AT or better won't have BIOS support for them? The primary FDC gets reset on boot by the BIOS in any case, so that's not a concern. If I leave it the way it is worst case is it recalibrates on the first error retry when it can't find the sector mark

Additionally:
Can anyone enlighten me on how DOS handles media sense for sub-caliber disks? Specifically finding documentation for:
1) bit 13 of the device characteristics field - MS defines it in the DOS source as
13 -> 1 IF THE DEVICE DETERMINES MEDIA BY EXAMINING THE FAT ID BYTE.
; THIS REQUIRES THE FIRST SECTOR OF THE FAT TO *ALWAYS* RESIDE IN
; THE SAME PLACE.
but other references call it the "IBM-compatible" bit

2) the expected values of the media type field in the get/set device parameters generic IOCTL packet

3) the DOS 5 generic IOCTL sub function 68H - SENSE_MEDIA_TYPE
 
Last edited:
That's the way I looked at it--unless it's a major performance issue, leave it alone. Floppy BIOSes for 3 and 4 units exist, but are uncommon--and it's even less common to see the additional drive capability being used. .
 
That's the way I looked at it--unless it's a major performance issue, leave it alone. Floppy BIOSes for 3 and 4 units exist, but are uncommon--and it's even less common to see the additional drive capability being used. .

Now that you mention it, I think MR BIOS had support for all 4 floppys
 
The FAT ID byte was the DOS 1.x/2.x method of determining media characteristics, but that fell apart with the advent of 3.5" floppies (as nearly as I can recall), when the same F9 media byte was used for both IBM 720K and Microsoft 720K floppies (they're not the same) and only got worse after that. That's when the DPB in the boot sector became relevant.

If you've got some old 160K/320K floppies, try reading them in Windows 9x. (no boot sector DPB). Windows 98 and later returns a "General Failure" error. AnaDisk has some code for detecting media type based on FAT ID when the boot sector is unreadable, but it's far from foolproof.
 
Yeah so it doesn't look like it was so much an issue of support being dropped as it is they've always done that silly "sector size on boot limit" thing. Even DOS 2.11 balks at a BPB from the driver with 1024 byte sectors.

Really makes me wonder if there is a viable way to hack it after boot time. Not because blocking/deblocking is hard, but because this would be cooler.

IMG_20200412_180540054.jpg
IMG_20200412_182818983.jpg
 
Yeah so it doesn't look like it was so much an issue of support being dropped as it is they've always done that silly "sector size on boot limit" thing. Even DOS 2.11 balks at a BPB from the driver with 1024 byte sectors.

Really makes me wonder if there is a viable way to hack it after boot time. Not because blocking/deblocking is hard, but because this would be cooler.

Damn you Microsoft! LOL!
 
How does the PC BIOS determine if you are using a 360kB disk in a 1.2MB drive to boot even? Does it just start at 500kHz and reduce the rate if it doesn't get a good read?
 
It's all in the BIOS. Take a look at the AT BIOS code--a READ ID is performed which tells everything. Incidental to that is that the BIOS makes the determination to double-step, not DOS.
 
Yeah so it doesn't look like it was so much an issue of support being dropped as it is they've always done that silly "sector size on boot limit" thing. Even DOS 2.11 balks at a BPB from the driver with 1024 byte sectors.

Really makes me wonder if there is a viable way to hack it after boot time. Not because blocking/deblocking is hard, but because this would be cooler.

You could hack the msinit routine to always use 1024 bytes as maxsect, but that has unfortunate consequences, such as doubling the storage required for BUFFERS, etc. I suspect that SMARTDRV would also need to double buffer size as well.
 
It's all in the BIOS. Take a look at the AT BIOS code--a READ ID is performed which tells everything. Incidental to that is that the BIOS makes the determination to double-step, not DOS.

didn't realise the AT BIOS source was available, but I found it and it does in fact cycle through the data rates in the retry function called by the main R/W/V function unless the media determined bit is set in the drive state memory variable, in which case it reports true error

after a successful operation it sets the bit
 
One way to handle 5.25" 720K floppies on the 5170 was to reset the "double step" BIOS flag (0:90h/0:91h, IIRC) using a small TSR. Some later/third party BIOSes redefined the flags, so it didn't work on all systems.
 
Finally located a double sided TM848E and it's on the way. Assuming it arrives safely I'll resume work on the DSDD 8" profile immediately
 
Back
Top