It's a secondary drive. Likely you have a device driver loaded to support it.

This sounds like a limit in int13 support, when parsing the partition table.

I VAGUELY recall reading the revision history / readme for Ontrack Disk Manager, that it originally came as a loadable .sys device driver, and needed to start from a small dos volume.

Maybe something like that here?

If it's just a tweak to the dos kernel, then something similar could be done with a small assembly stub that prods the right bits in ram, along with a proper int13 supplier, like xtide?

So how U did that?
---
& other thing,I wish to investigate:I am sure,I have read in more than 1 articles(about 3 to 4 years ago) about file system limits,that original "FAT16" counted some values only in 14bit numbers.
Was the authors of those articles same bad in math as me?
---
& I wish to add an another limit,I was reading about(& I did not risked to test it):
Windows 3.x causes data corruption on exit,when it is on a partition larger than 2GB(it can happen,if Win.3.x is installed on a FAT32-aware DOS,for example MS-DOS 7.1+ or FreeDOS),what do U know about this limit?

wierd_w wrote on 2025-03-04, 19:01:

It's a secondary drive. Likely you have a device driver loaded to support it. […]
Show full quote

It's a secondary drive. Likely you have a device driver loaded to support it.

This sounds like a limit in int13 support, when parsing the partition table.

I VAGUELY recall reading the revision history / readme for Ontrack Disk Manager, that it originally came as a loadable .sys device driver, and needed to start from a small dos volume.

Maybe something like that here?

If it's just a tweak to the dos kernel, then something similar could be done with a small assembly stub that prods the right bits in ram, along with a proper int13 supplier, like xtide?

Or...there is also an another occassion of a >32MB volume:
I have CD-ROM in 2 of my DOS 3.30 systems,driver VIDECDD.sys is working with both 286(pure 16bit) & DOS 3.30 & the limit does not apply for CDs,I can read full 700MB CD on DOS 3.30.

wierd_w wrote on 2025-03-04, 19:01:

I VAGUELY recall reading the revision history / readme for Ontrack Disk Manager, that it originally came as a loadable .sys device driver, and needed to start from a small dos volume.

Good enough!
Actually, I used SpeedStor:

Note that the 65535 sectors limit is still there.
SpeedStor bypasses this limitation by combining several physical sectors into one "logical sector" - in my scenario it's 4 KB:

And yes, it's handled by SSTOR.SYS loaded from CONFIG.SYS.
DOS itself, of course, doesn't recognize the SSTOR partition:

Sabina_16bit. wrote on 2025-03-04, 19:25:

Or...there is also an another occassion of a >32MB volume:
I have CD-ROM in 2 of my DOS 3.30 systems,driver VIDECDD.sys is working with both 286(pure 16bit) & DOS 3.30 & the limit does not apply for CDs,I can read full 700MB CD on DOS 3.30.

Indeed, it's also possible to bypass FAT limitations by using a completely different filesystem - eg. ISO9660 supported by MSCDEX.

Microsoft Network Client supports SMB:

But of course, such solutions occupy more memory than using the FAT driver, which is already loaded as a part of the DOS kernel.

Sabina_16bit. wrote on 2025-03-04, 19:17:

& I wish to add an another limit,I was reading about(& I did not risked to test it):
Windows 3.x causes data corruption on exit,when it is on a partition larger than 2GB(it can happen,if Win.3.x is installed on a FAT32-aware DOS,for example MS-DOS 7.1+ or FreeDOS),what do U know about this limit?

You mean the following?

1 Sometimes you may get an error message  when  exiting  Windows  3.x  like
2 "File allocation table bad" for some drive. Don't panic, this isn't true.
3 As a workaround, make sure that you  start  Windows  3.x  from  the  root
4 directory of drive C:, e.g.:
5 
6 C:
7 CD\
8 C:\WIN311\WIN.COM
9 
10 If you use WIN311.BAT as described above, modify it accordingly.

Anyway, create a new thread if you want to focus on DOS 7.

Sabina_16bit. wrote on 2025-03-04, 19:17:

& other thing,I wish to investigate:I am sure,I have read in more than 1 articles(about 3 to 4 years ago) about file system limits,that original "FAT16" counted some values only in 14bit numbers.
Was the authors of those articles same bad in math as me?

I'm currently investigating it, and inclined to believe it's true...

The original FAT16 supports up to 65535 SECTORS.
But I can't get DOS 3.30 to work with this many CLUSTERS...

DOS 3.30 formats its 32 MB partitions with 4 sectors/cluster - so there's less than 16384 clusters.

In my DOS 3.30 + SpeedStor setup, there's 4 logical sectors/cluster - again, less than 16384 clusters.

According to the mTCP User Documentation:

FAT16 (also known as original FAT16): [...] ◦ Maximum number of files: Just under 64K ◦ Max format: 64K clusters at 1 sector per […]
Show full quote

FAT16 (also known as original FAT16):
[...]
◦ Maximum number of files: Just under 64K
◦ Max format: 64K clusters at 1 sector per cluster

NetDrive creates FAT16 images with 1 sector/cluster, and 60000+ clusters:

1$ ./netdrive_linux_amd64 create hd 31 FAT16 test31m.dsk
2mTCP NetDrive by M Brutman (mbbrutman@gmail.com) (C)opyright 2023-2025, Version: Jan 10 2025
3
4Specified MB: 31, Filesystem: FAT16
5Bytes per sector: 512, Sectors: 63488, Data sectors: 62943, Cluster size: 1 sectors
6Reserved sectors: 1, FAT copies: 2, Sectors per FAT: 256
7Root directory entries: 512, Sectors for root directory: 32
8test31m.dsk disk image created.

DOS 3.30, however, can't cope with such images - when accessing them, I get garbage, or total hangs.

To be continued...

So it is that, because FAT16 was introduced in MS-DOS 3.0, at that point a 2GB partition was theoretically possible, except they kept some limits relative to practical disk sizes of the time? When the need arose, in MS-DOS 3.31, they relaxed those limits, but not really to intentionally breach the BIOS limits of the time of 1024 cynlinders and 16 heads (512MB). That didn't happen until MS-DOS 4.0. By that time, if larger hard drives landed, they didn't care about having accurate cylinder-heads-sectors numbers of a hard drive. It just needed to calculate to a size, and disk controllers knew how to map everything to the actual location on disk, and partitioning tools & BIOS eventually got the required updates.

Third party software can override those limits, though unsure I'd be unsure how compatible software would have been in the MS-DOS 3.0-3.3 days for very large partitions... It seems this driver is supplying some patching? Have you tried a late disk utility to see if you can access the whole drive?

It is a property of Windows 3.x,not of DOS 7,it is regardless on what FAT32-aware DOS version it runs.
VIDECDD.sys eats up about 40KB of memory,if I remember well,less than mouse driver or Norton Commander.
On a 286 with 1MB RAM(640KB usable) I cannot have permanently loaded mouse driver & I have to leave NC to load Keen 4/5,but I can have permanently loaded this CD driver.
& also NC5 itself can access larger volumes...by a laplink cable I can access larger volumes of another PC...using for backing up...
& also standard solution has some RAM consumption,each drive letter eats up some memory...So,can U,please do an another test?:
When U have DOS 3.30 on a 256MB HDD with partitions up to J,do U have still enough memory to run Commander Keen 5/6?
Or also now as U have it with that additional SW for the "large" partition,can U run Commander Keen 4/5 now?
But of course if U do this not on a 286,but on something newer & U loaded Himem.sys & EMM386.exe ,U get HMA,then U do not have to be so cautious about memory.
Most interesting is Wolfenstein,it has its own memory driver & it is the only game capable to access UMB without HMA,the only application @ all,which on a 286 with 1MB of RAM & DOS 3.30 only able to c 640KB RAM,Wolfenstein is able to use the whole 1MB of RAM & runs surprisingly well on 286 with DOS 3.30.
BTW try it on DOS 3.0.
Wolfenstein is thus the most backwards compatible game.
Much simpler BioMenace or Monster Bash has no chance to run on a 16MHz 286 PC with 1MB RAM,while Wolfenstein 3D runs perfectly on this set...with CD driver loaded...as I run it of the CD...
It also has another improvement over older games thats allows it to run on so tiny memory:while other Id/Apogee games always wants to load a whole level into memory,& if U do not have enough free RAM,these just tell U "Not enough memory to load level", Wolfenstein can load levels partially,it does not insist to fit whole level into memory,it loads a part of it & when U move near the end of the loaded part,it loads another part of the level,so with a tiny RAM,U just must wait for some door to open,while what is behind the door is loading,Id Software should get a medal for backwards compatibility,not my favorite game,but I am playing it often on this 286,because it is amazing,it runs on 286.

the3dfxdude wrote on 2025-03-04, 21:34:

So it is that, because FAT16 was introduced in MS-DOS 3.0, at that point a 2GB partition was theoretically possible, except they kept some limits relative to practical disk sizes of the time? When the need arose, in MS-DOS 3.31, they relaxed those limits, but not really to intentionally breach the BIOS limits of the time of 1024 cynlinders and 16 heads (512MB). That didn't happen until MS-DOS 4.0. By that time, if larger hard drives landed, they didn't care about having accurate cylinder-heads-sectors numbers of a hard drive. It just needed to calculate to a size, and disk controllers knew how to map everything to the actual location on disk, and partitioning tools & BIOS eventually got the required updates.

Third party software can override those limits, though unsure I'd be unsure how compatible software would have been in the MS-DOS 3.0-3.3 days for very large partitions... It seems this driver is supplying some patching? Have you tried a late disk utility to see if you can access the whole drive?

The early BIOS limit was 504MB.

Back to the 60000+ clusters in the original FAT16 filesystem...

DOS 6.22 works fine:

DOS 4.00 - not so fine, but still works:

DOS 3.30 - total failure:

Looks like the original FAT16 implementation - in DOS 3.x - is indeed limited to 14-bit cluster numbers.

Later DOS versions, however, use full 16-bit cluster numbers - even with <32 MB filesystems, therefore not BIGDOS.

Sabina_16bit. wrote on 2025-03-04, 21:58:

The early BIOS limit was 504MB.

Yes. That is a BIOS limit.

I was talking about FAT16 partitions in DOS 3.31: 512MB max, even though it could support more, they had limits still in place. It's likely simply a practical limit for whatever machines they had in mind. It could have been BIOS related why they didn't support larger, so I mentioned it in passing. Who knows why they picked that value though.

There is a document in the leaked DOS 3.3 source code that says that even though the number of clusters is in a 16 bit quantity, the code only supports up to 15 bits of precision:

https://github.com/AR1972/DOS3.3/blob/50868cd … 00c/AG.DOC#L867

That's the bug ... I can include a warning or additional parameters on the create command to allow setting the sectors per cluster.

mbbrutman wrote on 2025-03-04, 22:40:

There is a document in the leaked DOS 3.3 source code that says that even though the number of clusters is in a 16 bit quantity, the code only supports up to 15 bits of precision:

So I tried the following:

1$ ./netdrive_linux_amd64 create hd 15 FAT16 test15m.dsk
2mTCP NetDrive by M Brutman (mbbrutman@gmail.com) (C)opyright 2023-2025, Version: Jan 10 2025
3
4Specified MB: 15, Filesystem: FAT16
5Bytes per sector: 512, Sectors: 30720, Data sectors: 30175, Cluster size: 1 sectors
6Reserved sectors: 1, FAT copies: 2, Sectors per FAT: 256
7Root directory entries: 512, Sectors for root directory: 32
8test15m.dsk disk image created.

The number of clusters should already fit in 15 bits, right?

But I still get garbage:

15 bits is not working for me either ...

At this point it's a DOS 3.3 limitation or bug. And it's not well documented anywhere, except possibly now in this thread.

Well...

1$ ./netdrive_linux_amd64 create hd 7 FAT16 test7m.dsk
2mTCP NetDrive by M Brutman (mbbrutman@gmail.com) (C)opyright 2023-2025, Version: Jan 10 2025
3
4Specified MB: 7, Filesystem: FAT16
5Bytes per sector: 512, Sectors: 14336, Data sectors: 13791, Cluster size: 1 sectors
6Reserved sectors: 1, FAT copies: 2, Sectors per FAT: 256
7Root directory entries: 512, Sectors for root directory: 32
8test7m.dsk disk image created.

Now it fits in 14 bits - but still same garbage in DOS 3.30 !

Must be some other problem...

the3dfxdude wrote on 2025-03-04, 22:34:

Sabina_16bit. wrote on 2025-03-04, 21:58:

The early BIOS limit was 504MB.

Yes. That is a BIOS limit.

I was talking about FAT16 partitions in DOS 3.31: 512MB max, even though it could support more, they had limits still in place. It's likely simply a practical limit for whatever machines they had in mind. It could have been BIOS related why they didn't support larger, so I mentioned it in passing. Who knows why they picked that value though.

I was reacting to Your theory,that they tried to align the partition limit(DOS 4; 512MB) with BIOS limit of those days,I pointed to the fact,it did not matched each other,8MB difference left.

All the garbage in my earlier posts was after I did "mount -o loop -t msdos ...", and written a file there.

Now, fresh after "netdrive create ...":

mbbrutman wrote on 2025-03-04, 22:40:

There is a document in the leaked DOS 3.3 source code that says that even though the number of clusters is in a 16 bit quantity, the code only supports up to 15 bits of precision:

https://github.com/AR1972/DOS3.3/blob/50868cd … 00c/AG.DOC#L867

That's the bug ... I can include a warning or additional parameters on the create command to allow setting the sectors per cluster.

DOS 3.30's source code did not leaked,it was officially unclassified by Microsoft,which rendered it freeware,which helped the FreeDOS project,as they started from decopyrighted DOS 3.30's source code.
But of course if U think a leak earlier,then it was declassified,than then it really was a leak,depends on time.
Interesting is this another version with 15 bits,I had read before,that they utilized only 14 bits for cluster numbers,as they did not felt need for more those days,when HDDs had 10 to 20MB.
But maybe they just tried to cover the bug by statements like this,history is being so often overwritten,that if it would be archived on a flash media,we would not have history @ all...