mbbrutman wrote on 2025-02-13, 01:51:

Sorry - it's Compaq MS DOS 3.31 that supports FAT16B .. there might be another OEM version that also supports FAT16B, but I think almost everything else is still limited to FAT16 at that version.

I've tried both Compaq and "generic" MS-DOS 3.31 - same results.

With MS-DOS 4.00, no problems when reading files written under 6.20.
With MS-DOS 3.31, however, they seem to be corrupt.

I'm going to do more experiments sometime.
3.31 still looks promising as the OS for XT machines - it obviously supports >32 MB, but in a way that's incompatible with later versions.

Grzyb wrote on 2025-02-14, 17:53:

3.31 still looks promising as the OS for XT machines - it obviously supports >32 MB, but in a way that's incompatible with later versions.

Is DOS 3.31 FAT16B support simply incompatible with later version? Or is forwards compatible and DOS 6.x FAT16B simply not backwards compatible?

I don't remember there being an issue with migration from DOS 3.31 to DOS 5 in '90. But I seem to remember there being limitations with DOS 3.31 that went away. I do believe it's possible that it had a maximum partition size limit that is less than 2GB. So the fdisk tool might have been enhanced further in DOS 4, and that created another FAT variant that isn't backwards compatible.

As a strange thought, I have a 40MB IDE drive that I grabbed out of an AT in the early 90's, and I don't remember how I partitioned it when I used it. But it could have been in my turbo XT running 3.31. Anyway I remember firing it up and seeing strange corruption, and I thought, too bad it's going bad. Well I reinitialized the disk with full format, and it checked clean. Then I put some stuff on it. I just fired it up again not too long ago, working perfectly, and everything is still there. I wonder now, if the corruption is this same problem you are seeing? Pretty sure it was set up for one partition. Because I didn't want to do two partitions like the old DOS 3.x days 😉

For the classic versions of DOS there is FAT12, FAT16 or FAT16B.

• FAT12: Up to 65535 sectors on a disk. FAT entries are 12 bits so you have a maximum of around 4,096 clusters. (Actually slightly less due to some reserved cluster numbers.)
• FAT16: Still just 65535 maximum sectors on a disk. FAT entries are 16 bits so now you can have up to 65535 clusters, allowing for smaller clusters and more efficient usage of the disk.
• FAT16B: More than 65535 clusters are allowed. The "number of sectors" field will be 0 and a new field with the true number of sectors will be used.

My numbers above are close, but not exact because some cluster numbers are reserved. But they are good enough for the discussion here. I think the FAT12 cluster maximum is actually 4078.

If you have less than 4078 or less clusters then it has to be FAT12. If you have more then it can be either FAT16 or FAT16B depending on the number of total sectors. The number of clusters is not explicitly stated in the BIOS Parameter block. It has to be computed by looking at the number of sectors per cluster, the total number of sectors, and then accounting for things like the FAT tables, reserved sectors, etc.

If something is not working under DOS then either that version of DOS doesn't understand it, or it was created in such a way that it is tricking DOS. For example, you can create a small FAT16B partition that is only 4MB in size. If you say four sectors per cluster then you only need 2048 clusters total. DOS will look at that and say "Cool - FAT12!" and try to use it as such. And that's not going to work ... So if you are having a problem look at what you created. You might have created something that is legal but confusing to DOS. But if one version of DOS recognized it correctly, then the other version probably doesn't have support for it.

NetDrive doesn't know or care ... it's just serving 512 byte blocks of data to DOS. It's up to DOS to determine if it is FAT12, FAT16, or FAT16B. If my tools let you create something that is incorrect or misleading I want to fix that. but the device driver itself can't be the problem here. (FAT32 should also work, but I've not tried it.)

the3dfxdude wrote on 2025-02-14, 18:49:

Is DOS 3.31 FAT16B support simply incompatible with later version? Or is forwards compatible and DOS 6.x FAT16B simply not backwards compatible?

All I did so far was:
- create 450 MB and 2 GB disk images using NetDrive - I didn't use any other tools to format them
- fill them with RAR files under MS-DOS 6.20
- test the RAR files under MS-DOS 4.00 - all OK
- test the RAR files under MS-DOS 3.31 - massive corruption

I've never tried to migrate from FAT16B created/written under 3.31 to any of the later versions.

mbbrutman wrote on 2025-02-14, 17:44:

How much memory is the SMB client using?

1Modules using memory below 1 MB:
2
3  Name           Total       =   Conventional   +   Upper Memory
4  --------  ----------------   ----------------   ----------------
5  MSDOS       14,941   (15K)     14,941   (15K)          0    (0K)
6  HIMEM        1,120    (1K)      1,120    (1K)          0    (0K)
7  SETVER         592    (1K)        592    (1K)          0    (0K)
8  IFSHLP       3,968    (4K)      3,968    (4K)          0    (0K)
9  COMMAND      2,928    (3K)      2,928    (3K)          0    (0K)
10  SMARTDRV    29,024   (28K)     29,024   (28K)          0    (0K)
11  PROTMAN        400    (0K)        400    (0K)          0    (0K)
12  ELNK3        9,328    (9K)      9,328    (9K)          0    (0K)
13  TCPDRV       1,328    (1K)      1,328    (1K)          0    (0K)
14  NEMM           672    (1K)        672    (1K)          0    (0K)
15  TCPTSR      76,784   (75K)     76,784   (75K)          0    (0K)
16  TINYRFC     18,224   (18K)     18,224   (18K)          0    (0K)
17  NMTSR        6,160    (6K)      6,160    (6K)          0    (0K)
18  BASIC       13,760   (13K)     13,760   (13K)          0    (0K)
19  Free       475,936  (465K)    475,936  (465K)          0    (0K)
20
21Memory Summary:
22
23  Type of Memory       Total   =    Used    +    Free
24  ----------------  ----------   ----------   ----------
25  Conventional         655,360      179,424      475,936
26  Upper                      0            0            0
27  Reserved             393,216      393,216            0
28  Extended (XMS)    15,728,640    2,162,688   13,565,952
29  ----------------  ----------   ----------   ----------
30  Total memory      16,777,216    2,735,328   14,041,888
31
32  Total under 1 MB     655,360      179,424      475,936
33
34  Largest executable program size        475,408   (464K)
35  Largest free upper memory block              0     (0K)
36  MS-DOS is resident in the high memory area.

Do you have access to the "L" disk cache? (L stood for "Lightening". It was a small executable named l.com and it was pretty good. Probably far more effective than bumping BUFFERS.)

No, but I tried SMARTDRV...
Before, I loaded SMARTDRV in AUTOEXEC.BAT, before NETDRIVE CONNECT + SHSUCDHD + SHSUCDX.
Now, I loaded SMARTDRV after NETDRIVE CONNECT + SHSUCDHD + SHSUCDX, and it did help a bit:

NetDrive + SHSUCDHD + SHSUCDX: 2 hours 24 minutes

but still far from perfect...

Grzyb wrote on 2025-02-14, 20:13:

All I did so far was: - create 450 MB and 2 GB disk images using NetDrive - I didn't use any other tools to format them - fill t […]
Show full quote

All I did so far was:
- create 450 MB and 2 GB disk images using NetDrive - I didn't use any other tools to format them
- fill them with RAR files under MS-DOS 6.20
- test the RAR files under MS-DOS 4.00 - all OK
- test the RAR files under MS-DOS 3.31 - massive corruption

What cluster size is being used for the images?

mbbrutman wrote on 2025-02-14, 20:00:

[*]FAT16B: More than 65535 clusters are allowed.

You mean SECTORS, not CLUSTERS, right?

jmarsh wrote on 2025-02-14, 20:32:

What cluster size is being used for the images?

No surprises here:
- 8 KB for the 450 MB image
- 32 KB for the 2 GB image

Two different threads going on here ...

[1] NetDrive performance is the same as SMB performance with far less memory used. Adding SHSUCD shouldn't make a big difference so I don't understand what is wrong, but there are too many variables being presented here including caching. It's interesting but somebody else can pick this up ... detailed traces are available on the NetDrive server side so figuring out what the read pattern is and determining why SHSUCD is so much worse is possible.

[2] Compaq DOS 3.31 should work with FAT16B and it does - I gave it a 100MB disk to work with, and it partitioned it and formatted it just fine. A also recreated the corruption problem in NetDrive. This might be a problem with the way this version of DOS calls the device driver that other versions of DOS do not have. It should work as is so I want to understand what is going wrong and fix it.

I'm an idiot ...

The source code has a comment in it to add support for Compaq MS DOS 3.31 ... I just did and it works. If you want to test it send me an email.

mbbrutman wrote on 2025-02-14, 21:10:

Two different threads going on here ...

[1] NetDrive performance is the same as SMB performance with far less memory used. Adding SHSUCD shouldn't make a big difference so I don't understand what is wrong, but there are too many variables being presented here including caching. It's interesting but somebody else can pick this up ... detailed traces are available on the NetDrive server side so figuring out what the read pattern is and determining why SHSUCD is so much worse is possible.

[2] Compaq DOS 3.31 should work with FAT16B and it does - I gave it a 100MB disk to work with, and it partitioned it and formatted it just fine. A also recreated the corruption problem in NetDrive. This might be a problem with the way this version of DOS calls the device driver that other versions of DOS do not have. It should work as is so I want to understand what is going wrong and fix it.

[3] Compatibility with the ODI driver so IPX multiplayer games can be run when mounting ISO’s via NetDrive

[3] Compatibility with the ODI driver so IPX multiplayer games can be run when mounting ISO’s via NetDrive

That's a long way off, if it is even possible. I know of some changes I can make to mTCP to make it less "grabby" on Ethernet traffic, allowing it to co-exist with other traffic. But I don't know enough about how ODI works to be able to tell you if my changes to mTCP would be enough. It might just simply not be possible.

Come to think of it, there may be some other way around...

- NetDrive already allows other PD software to access the net...
- there is some PD->IPX shim - https://www.shikadi.net/network/

What if you stick them together?

The ODI way seemed obvious to me, as there's clear separation of various frame types in ODI - an elegant way for various protocols to co-exist.
But again - other ways are also worth exploring...

If ODI can be configured to send IP and ARP frames to the ODI to PKT shim, sure. Then it can keep IPX for itself. I just don't know enough about it, and my focus is on making thing works first.

On your benchmarks - do you have EtherDFS setup? I wonder if it has the same behavior as SMB or NetDrive, or something in between ...

mbbrutman wrote on 2025-02-14, 22:18:

On your benchmarks - do you have EtherDFS setup?

No, I only use FTP and SMB.
Even NetDrive is a brand new rabbit hole to me.
Not likely to touch EtherDFS anytime soon.

mbbrutman wrote on 2025-02-14, 21:45:

That's a long way off, if it is even possible. I know of some changes I can make to mTCP to make it less "grabby" on Ethernet traffic, allowing it to co-exist with other traffic. But I don't know enough about how ODI works to be able to tell you if my changes to mTCP would be enough. It might just simply not be possible.

Oh well, hopefully something in the future can be done. I’m going to have to try get my CDROM drives to work more reliably 🤣

Grzyb wrote on 2025-02-14, 22:11:

Come to think of it, there may be some other way around... […]
Show full quote

Come to think of it, there may be some other way around...

- NetDrive already allows other PD software to access the net...
- there is some PD->IPX shim - https://www.shikadi.net/network/

What if you stick them together?

The ODI way seemed obvious to me, as there's clear separation of various frame types in ODI - an elegant way for various protocols to co-exist.
But again - other ways are also worth exploring...

I’ll have a look into it

Grzyb wrote on 2025-02-14, 22:27:

No, I only use FTP and SMB. Even NetDrive is a brand new rabbit hole to me. Not likely to touch EtherDFS anytime soon. […]
Show full quote

mbbrutman wrote on 2025-02-14, 22:18:

On your benchmarks - do you have EtherDFS setup?

No, I only use FTP and SMB.
Even NetDrive is a brand new rabbit hole to me.
Not likely to touch EtherDFS anytime soon.

Are you running Netdrive server on a Windows host? Could be something like antivirus trying to scan the ISO while it’s been accessed and causing some weird slow down.

zuldan wrote on 2025-02-14, 22:37:

Are you running Netdrive server on a Windows host? Could be something like antivirus trying to scan the ISO while it’s been accessed and causing some weird slow down.

No, the server runs Linux.
Reading the ISO file via pure NetDrive is fast.
Adding the SHSUCD and reading the files inside the ISO is abnormally slow.

Grzyb wrote on 2025-02-14, 22:44:

No, the server runs Linux. Reading the ISO file via pure NetDrive is fast. Adding the SHSUCD and reading the files inside the IS […]
Show full quote

zuldan wrote on 2025-02-14, 22:37:

Are you running Netdrive server on a Windows host? Could be something like antivirus trying to scan the ISO while it’s been accessed and causing some weird slow down.

No, the server runs Linux.
Reading the ISO file via pure NetDrive is fast.
Adding the SHSUCD and reading the files inside the ISO is abnormally slow.

Maybe a workaround is to extract the ISO on the Netdrive disk image then use 0CD.COM to mount the files as a CDROM?