So I figured out how to create FAT16 images compatible with DOS 3.30...
DON'T use this:
netdrive create hd 31 FAT16 test31m.dsk
Instead, do the following:
1$ dd if=/dev/zero of=test31m.dsk bs=1048576 count=31 231+0 records in 331+0 records out 432505856 bytes (33 MB) copied, 0.0146831 s, 2.2 GB/s 5 6$ mkfs.fat -v test31m.dsk 7mkfs.fat 3.0.20 (12 Jun 2013) 8test31m.dsk has 64 heads and 32 sectors per track, 9logical sector size is 512, 10using 0xf8 media descriptor, with 63488 sectors; 11filesystem has 2 16-bit FATs and 4 sectors per cluster. 12FAT size is 64 sectors, and provides 15831 clusters. 13There is 1 reserved sector. 14Root directory contains 512 slots and uses 32 sectors. 15Volume ID is 1865e2ba, no volume label.
You can also "mount -o loop -t msdos" it, and copy something to it.
Default is 4 sectors per cluster - works fine:
The attachment 4spc.png is no longer available
Now, let's reformat it to 2 sectors per cluster:
1$ mkfs.fat -v -s 2 test31m.dsk 2mkfs.fat 3.0.20 (12 Jun 2013) 3test31m.dsk has 64 heads and 32 sectors per track, 4logical sector size is 512, 5using 0xf8 media descriptor, with 63488 sectors; 6filesystem has 2 16-bit FATs and 2 sectors per cluster. 7FAT size is 124 sectors, and provides 31603 clusters. 8There is 1 reserved sector. 9Root directory contains 512 slots and uses 32 sectors. 10Volume ID is 5b8a7888, no volume label.
Still kinda works, but CHKDSK hangs:
The attachment 2spc.png is no longer available
Finally, 1 sector per cluster:
1$ mkfs.fat -v -s 1 test31m.dsk 2mkfs.fat 3.0.20 (12 Jun 2013) 3test31m.dsk has 64 heads and 32 sectors per track, 4logical sector size is 512, 5using 0xf8 media descriptor, with 63488 sectors; 6filesystem has 2 16-bit FATs and 1 sector per cluster. 7FAT size is 246 sectors, and provides 62963 clusters. 8There is 1 reserved sector. 9Root directory contains 512 slots and uses 32 sectors. 10Volume ID is 91d7a08c, no volume label.
...which results in DATA CORRUPTION!!!:
The attachment 1spc.png is no longer available
Conclusion:
- 16-bit cluster numbers don't work with DOS 3.30
- 15-bit cluster numbers work with DOS 3.30 kernel, but not CHKDSK
- 14-bit cluster numbers fully work with DOS 3.30
- it seems that FORMAT command in DOS 3.30 never exceeds the 14-bit limit
- "netdrive create hd FAT16" needs improved for compatibility with DOS 3.30
Kiełbasa smakuje najlepiej, gdy przysmażysz ją laserem!
(As far as I know, Vfeature Deluxe was among one of the utilities that made DOS 3.x handle larger HDDs back in the day.
Speaking under correction, though. I merely read about it in Microsoft KB Article 80387.)
"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel
- "netdrive create hd FAT16" needs improved for compatibility with DOS 3.30
As stated above, I'll add an option to set the number of sectors per cluster to the HD create util. And probably a warning message about the older versions of DOS and their limitations.
Thanks for doing this testing - it is another interesting rabbit hole.
As stated above, I'll add an option to set the number of sectors per cluster to the HD create util. And probably a warning message about the older versions of DOS and their limitations.
OK, but note that there's something more to it than just sectors per cluster...
Also, when the "FAT16" parameter is used, it probably should create an image compatible with DOS 3.00-3.30 *by default*.
There's not much point to use "FAT16" with later DOS versions, is it?
Kiełbasa smakuje najlepiej, gdy przysmażysz ją laserem!
As far as the created images are concerned, both have identical BPBs except the NetDrive created image has 256 sectors per FAT while the mkfs.fat version has 248 sectors per FAT. mkfs.fat fills in some more fields in the BPB that are used by later versions of DOS, but they are not needed.
As far as how to create an image goes, 4 sectors per cluster might be a reasonable default for FAT16 but I still want to provide an option to override that.
As far as how to create an image goes, 4 sectors per cluster might be a reasonable default for FAT16 but I still want to provide an option to override that.
Sure, you decide.
But I don't expect "netdrive create" to fully replace "mkfs.fat".
Quite contrary, I expect it to be as simple as possible - quickly create an image that just works, that's all.
Kiełbasa smakuje najlepiej, gdy przysmażysz ją laserem!
So I started to dig into why I I needed 256 FAT sectors for the the 31MB FAT16 image while Linux only needed 246. It turns out I hard-coded the number of sectors per FAT so that it was safe on any size hard disk, but that can be wasteful depending on the sectors per cluster and the disk size. And on FAT12 my calculation was totally wrong, so it was wasting a lot of sectors for unused areas of the FAT.
The next version will clean those bugs up. It won't perfectly match what mkfs.fat is doing, but it will be within a sector or two. (I could make it perfect, but it's not worth the effort.)
I like to imagine how rich I would have had to been in 1988 to be hitting some of these limits.
To my knowledge, 5 and 10 MB MFM/RLL drives were already out of production by that time.
A 20 MB HDD was ca. 1986 standard and already "small" by 1988.
Amstrad/Schneider PC1512/1640 from 1986 had an 20MB HDD option (and also 10MB, which was less popular).
By 1988, 40MB and up were common, reaching the limits of DOS 3.
Back then in the press, DR-DOS 3.3x had been advertised to solve the 32 MB HDD problem.
For example, it's mentioned in the old news (March '89) about Deltagold Computer and DG-DOS 3.33 (DR-DOS OEM) that I've read just recently.
Of course, our good old Europe here was different. Users were chronically short on money (but only for computers).
Some still used music tapes, records or phonograph cylinders for storage, not sure.
The C64 fans probably just saved up enough money to buy a factory broken 1541 drive and "upgrade" from datasette.
But seriouly, we have to remember that computer technology evolved very fast.
In the 90s, a PC was "officially" considered obsolete after 6 months (no kidding).
In the 80s it wasn't that fast yet, maybe, but one or two years made a difference too.
Edit: Here in cheap old Germany, we also had low-end computers such as Atari PC-1/Commodore PC-1 in ca. 1985-1990.
These were cheap slow XTs (8-Bit 4,77 MJhz 8088) with little RAM, no HDD.
The biggest no-no was the use of only one floppy drive (second one was external/optional).
That was very unprofessional, because you need two floppy drives for serious working on DOS if you have no HDD.
You need one diskette for DOS, one for the user application.
Or one custom working disk with DOS/application and one disk for user data.
Edit: The only usecase for such a limited PC that comes to mind is playing an inferior port of Frogger (booter disk).
And that's not even meant in a sarcastic way.
The only rational explanation for users buying such a PC I can imagine would have been the ability to run GW-BASIC and Turbo Pascal 3.
Turbo Pascal 4/5 or QuickBasic 4.x wouldn't have fit on a single 360KB diskette shared with MS-DOS 3.2.
"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel
The original FAT16 is limited to 65535 sectors, therefore 32 MB.
Modern 4Kn drives aside, I've never seen a HDD that wasn't 512 Bytes/sector...
- IDE drives are factory-formatted with 512 B/s
- MFM/RLL drives don't care about sector size, it's up to the controller card - again, the PC standard is 512 B/s
I believe there were some exceptions, but nevermind it for now...
Important thing is: between the hardware with 512-Byte physical sectors, and the DOS, there's always BIOS and/or some driver...
and that's where it's possible to pretend that the sectors are bigger.
This document - https://raw.githubusercontent.com/AR1972/DOS3 … 7568700c/AG.DOC - lists certain MS-DOS 3.30 limits:
- max sector size: 32 KB, must be a multiple of 64 byte, BUT - nothing that it must be a power of 2 !!!
- max number of sectors: 64K (I believe 65535)
- max cluster size: 128 sectors, but <64 KB
- max number of clusters: 32766
The following are obviously possible:
- 32766 clusters * 1 sector/cluster * 32 KB/sector = 1 GB
- 32766 clusters * 2 sectors/cluster * 16 KB/sector = 1 GB
...and that's what Vfeature Deluxe claims - "a Gigabyte".
SpeedStor only allows for 512 MB.
If non-power-of-2 sector sizes are really possible, we can push it even higher:
- 32766 clusters * 2 sectors/cluster * 32704 B/sector = 2 GB
And another thing - that document also claims:
1 ------------------------------------------------------------ 2 | | 3 | Note | 4 | | 5 | However, some MS-DOS utilities (such as Chkdsk and | 6 | Recover) restrict the total FAT size to 32K entries, | 7 | hence the MS-DOS 3.x limit of 32,766 clusters and not | 8 | 65,525 (216-11). | 9 | | 10 |__________________________________________________________|
...but it seems wrong!
CHKDSK already hangs with 31603 clusters - tested with both PC DOS 3.30 and the slightly newer MS-DOS 3.30.
Vfeature Deluxe comes with its own CHKDSK - hopefully improved.
But the 32766 clusters limit has nothing to do with CHKDSK - it must be in the DOS kernel.
Kiełbasa smakuje najlepiej, gdy przysmażysz ją laserem!
Was these workarounds(those available in that era) the way,early servers worked?
I guess,the early ARPAnet servers could be in this era...if it had servers & not only P2P,but @ least research labs of the era had terminal servers or early coaxial LAN,but maybe none of them run DOS?
There was no Linux yet,but probably some early Unix yes...
What was the 1st server using DOS & was it using these workaround,or they just used disk fields built from 20MB HDDs?
Or was it just a sci-fi,I had seen in old movies terminal servers & terminals troughout a research facility of the era?
Was these workarounds(those available in that era) the way,early servers worked?
Sometimes.
DOS-based network operating systems did exist, and could use such workarounds.
The more advanced systems, however, used their own filesystems.
See eg. Novell NetWare - the server software was installed on a normal DOS partition, with all its limitations.
But there was also separate NWFS partition for the files being served, free of any DOS FAT limits.
Unix systems also use their own filesystems.
I guess,the early ARPAnet servers could be in this era
ARPANET was established in 1969, long before the IBM PC and DOS.
Kiełbasa smakuje najlepiej, gdy przysmażysz ją laserem!
I'm actually (well, was actually) certified to administer that shit!
Yes, the server starts from DOS but completely takes over, sorta like early linux used lilo and loadlin to start.
NWFS in later versions was certainly not FAT, and had quite a few oddball features, like 'block suballocation'. If a cluster was not fully used, a suballocation inode would be added to the tree, so that a small file could use the remainder of the cluster.
Some more observations after a few days of living with DOS 3.30 (1987) on a 486DX2-66 (1993)...
Such a combo can't be great, of course.
But this is pretty bearable.
There are severe limitations - primarily the 32 MB of partition size.
Also, no way to load stuff above the 640 KB.
It's possible to alleviate such problems using third-party utilities, but that's not quite elegant.
Still, I consider the 3.30 as one of the most successful versions ever.
It's still simple and compact, but already mature - that's where the DOS API got pretty much complete, and it's hard to find an application that refuses to run.
Don't use it on a 486.
But if you still have an XT in stock configuration - typically 640 KB RAM and 20 MB HDD - the 3.30 is definitely the #1 choice!
Pre-3.30 versions, however... well, they belong in the deep 80s:
The attachment win31.png is no longer available
The attachment vc405.png is no longer available
The attachment msnc30.png is no longer available
Kiełbasa smakuje najlepiej, gdy przysmażysz ją laserem!
Still, I consider the 3.30 as one of the most successful versions ever.
It's still simple and compact, but already mature - that's where the DOS API got pretty much complete, and it's hard to find an application that refuses to run.
I agree! ^^
It’s also a bit faster than previous versions, I think.
Especially noticeable on 4,77 MHz 8088 systems, were every bit counts.
(DR DOS 3.3x had been said to have fast HDD routines btw.)
The only other version that still matters might be DOS 2.11, because it had been the last "hurray" to MS-DOS compatibles.
It’s really the bottom of the barrel, but still better than MS-DOS 1.25 which MS-DOS compatibles had initially been shipped with.
Such as Sanyo MBC-550/MBC-555 computers, which at least saw v2.11 torwards the end.
Some Tandy 1000s had it in ROM, too. The Atari Portfolio's DIP DOS was v2.11 compatible, too.
MS-DOS 2.11 was like a dead end, in some ways.
It was meant to gravtiate torwards Unix and allows certain Unix things, such as switching / and \.
It also was small (but not fast) and had ansi.sys built-in.
Some early DOS compatibles OSes tried to feature MS-DOS 2.11 API/ABI, such as DOS Plus 1.2, which is CP/M-86 with "PC-MODE" DOS emulator.
It was being bundled with Amstrad PC1512 and BBC Master 512 in mid-80s.
Anyway, just saying. I'm not saying that 2.11 was great or something, I just found the relationship interesting.
Many programs available in 1985 can still run on DOS 2.11 but later programs from, say, 1989 do already request DOS 3.1-3.3.
Personally, I think that MS-DOS 2.11 and DOS Plus 1.2 can still be useful to PCs with 256KB of RAM, CGA and two 360KB floppy drives.
To re-experience PC usage of the early 80s, when the x86 PC was more like a home computer still.
For anything fixed-disk related, I'd go with a later version, though.
"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel
It was... a very odd beast. Some small part of me wants to try to get my hands on one again, but it's not worth the prices and shipping. (Special CRT!!)
An ISA slot top cover (similar to RACORE Rapport Drive II, but instead of just adding 256k of DRAM, and a second diskette in the top, Max out to 640k, and add integrated JrIDE, with 8 ISA slots.) would be a very amusing thing to try to make for it, but meh. Not worth it.
Did it run MS-DOS 2.11 or PC DOS 2.1? Most Jrs would have been running PC-DOS 2.1, then possibly later versions of PC DOS. Those handled the built-in ROM BASIC and the cartridge correctly. The screen is just CGA with a different pinout.
I'm going to have a PCjr at an event in two weeks that is going to be basically period correct - 512K of RAM, single disk drive, and a parallel port. But it's going to have an Ethernet adapter on the parallel port and I'm going to boot it to PC-DOS 5.02, then use NetDrive do connect 48GB of storage to it over the network. (24 drive letters, 2GB each.) Running chkdsk across all of those is going to take an hour or two. ;-0
