maxtherabbit wrote on 2023-12-13, 20:39:

Yes, I know. Just pointing out the switch because you didn't mention it and the guy who was struggling with the issue doesn't seem to know about it

You probably mean me. 😜 But I understand the issue quite clearly. I only made a feature request (that would probably mean not to use a device driver) and tried to workaround it by loading it from the command line with some external utilities. But that unfortunately doesn't work the way I want it to work (getting a drive letter after the CD drive).

On a side note I did test NetDrive extensively today and made a backup with it of one of my retro pc's which contains around 1Gb of data consisting of 1000s of files. Performance was quite good and no problems were encountered. I reformatted the image file first btw so I can use it with 7zip etc.

Mu0n wrote on 2023-12-13, 12:42:

if it could straight up mount a .iso file as a drive, it would save a step but I'm happy as is to edit my .dsk files (it's quite straightforward with WinImage).

I'm glad to hear it worked well.

Mounting an ISO directly isn't going to be easy; DOS is fairly particular about what it can read, and that means FAT12, FAT16, or FAT16B. CD-ROM filesystems can be mapped, but they are not directly one of those FAT variants.

One could write a utility to take an ISO file and basically convert it into a hard drive; basically creating a new blank HD image and doing an XCOPY operation. But the filesystem on the CD-ROM (ISO9660 presumably) files would have to obey DOS naming rules for that to work. And that's a pretty brute-force approach.

Yoghoo wrote on 2023-12-13, 18:52:

mbbrutman wrote on 2023-12-13, 15:44:

It's not enjoy, it just doesn't have boot code in the first sector. It will mount using DOS and Linux and there will be no files or volume label on it.

True, but if a more compatible boot code was used during the creation of the image file with NetDrive it would be more compatible with external (Windows) tools. You can't open an image file created by NetDrive with 7-zip or PowerISO for example. If you reformat that image file (after mounting it with OSFMount or so) you can use those tools to open and manipulate those images. It also still works with NetDrive. Not necessary of course as there is a workaround but would be a nice feature request.

I wrote the minimum required boot sector to avoid complications. So while I could have gone all fancy and written an extended BIOS Parameter Block with the unique drive identifier and other tidbits, for the most part that information is not used and adding it increases the chance of bugs or other things. Linux, DOS, and WinImage recognize and mount the images just fine, probably because they are not requiring something that is optional.

Feel free to use whatever tools work for you; I wrote the create tool so that people would have something they could use out of the box. It's not my intent to re-invent the wheel and make another disk image manipulation tool.

(And 7Zip can worth with raw images? Neat!)

Yoghoo wrote on 2023-12-13, 21:28:

On a side note I did test NetDrive extensively today and made a backup with it of one of my retro pc's which contains around 1Gb of data consisting of 1000s of files. Performance was quite good and no problems were encountered. I reformatted the image file first btw so I can use it with 7zip etc.

That's good feedback - thank you!

For those of you who are adventurous and want to try out the device driver without setting up your own server, or who want to test the "across the Internet" feature, I have something for you ...

For a limited time I'm hosting some public disk images for people to play with. If you connect to brutman.com:2002 the following disk images are available:

(Note: all names are case sensitive as the server is running Linux.)

Hard drive images:

• fat12.dsk: 32MB, FAT12, suitable for all systems running DOS 2.0 or better. Utilities and RLE files.
• bigdisk.dsk: 200MB, FAT16 with DOS utilities, shareware games, etc.
• hugedisk.dsk: 2GB FAT16 disk, mostly empty.

bigdisk.dsk is probably the most interesting, as it has a collection of my favorite utilities, some reasonably good shareware games, RLE graphics, and other things to play with. fat12.dsk has the utilities and RLE graphics, but not much else due to the size. hugedisk.dsk is empty; it’s just there so that you can test mounting a 2GB disk image.

Floppy disk images:

• ibm_dos_11.dsk: IBM DOS 1.1 on the original 160KB diskette
• buick_1.dsk and buick_2.dsk: Demo disks from the late 1980s
• pcmag_march_1988.dsk: PC Magazine shareware/utility disk from March 1988

ibm_dos_11.dsk is mildly interesting because it is a 160K format without a BIOS Parameter Block, and that gives disk imagers like WinImage a hard time. (NetDrive has some special code to handle these.) The BASIC programs will run but the rest of the programs should not be run because they’ll crash a modern DOS system. The Buick demos will start but some of the code assumes you are using a floppy drive and asks you to switch diskettes, so you might not get far. The PC Magazine diskette is a small time capsule of utilities; it’s hard to believe that people distributed software that way now.

All of these images will appear writable to you, so you can play games and update high-score files, run benchmarks (including write speed testing), or just mess around. Your changes will only last for the duration of the session; when you disconnect the changes are lost. (The server has the “session scoped writes” feature described above turned on.) To keep the server from running out of space there is a maximum number of writes allowed per session, a maximum session length, and a timeout timer.

Yoghoo wrote on 2023-12-13, 21:28:

maxtherabbit wrote on 2023-12-13, 20:39:

Yes, I know. Just pointing out the switch because you didn't mention it and the guy who was struggling with the issue doesn't seem to know about it

You probably mean me. 😜 But I understand the issue quite clearly. I only made a feature request (that would probably mean not to use a device driver) and tried to workaround it by loading it from the command line with some external utilities. But that unfortunately doesn't work the way I want it to work (getting a drive letter after the CD drive).

On a side note I did test NetDrive extensively today and made a backup with it of one of my retro pc's which contains around 1Gb of data consisting of 1000s of files. Performance was quite good and no problems were encountered. I reformatted the image file first btw so I can use it with 7zip etc.

But it could work the way you want it. If you load MSCDEX and manually specify a higher drive letter then you could still later load the block device driver with CTLOAD or whatever you're using and it would pick up the lower one and all would be well, that's my point

I just gave a thought to the 7 CD Phantasmagoria, which needs some severe disk swapping during gameplay. Due to the 2gb limit, my first thought is that it'd be impossible to go beyond 3 mounted CDs at a time roughly using a netdrive.

Then I tried the following:
-(from modern PC) Put CD1 iso into a .dsk, serve it
-(from vintage PC) connect to the netdrive, mount the iso, install the game, run the game
-(from vintage PC) deliberately go to a later chapter that requires another mounted CD, wait for the disc swap prompt
-(from modern PC) kill the serve session, modify the .dsk and use the exact same .iso name (despite it being really another disc iso), same .dsk name, re-serve it
-(from vintage PC) hit enter to finalize the disc swap

Unfortunately, it won't let me do this hot swap and I get a "DOS Error, Enter to retry, ESC to wait".

Is there another method to attempt this?

Have you checked to see if there's overlap between the disc contents? The entire game from GoG is only 2.13GB when installed.

jmarsh wrote on 2023-12-14, 13:51:

Have you checked to see if there's overlap between the disc contents? The entire game from GoG is only 2.13GB when installed.

There is an overlap. Those files are what get installed into a regular hard disk partition. However, CD-based games are strict in various ways, and here is no exception. The game requires a "disc" to be inserted and present in the CD-ROM drive. It will not accept a dumping of all files into a regular disk drive, but even if it did, I can't fit 2.13 GB into the maximum 2GB partition size of MS-DOS 6.22.

There's no strict 2GB partition limit in MS-DOS 5/6, it technically can support around 3GB no problem.

However, this requires patching of a few DOS files. It's also not very efficient with FAT16B and a lot of small files.

But if only a handful of large files are being stored, it might be useful.

Edit: More information here.

Good to know in a time of need, but the reality is that somehow, I need to do the equivalent of mounting/unmounting .ISO files with SHSUCDX - if there was a custom TSR tool to let you do it without breaking the game's runtime...

I'm just a layman, a tinkerer, so I don't know for sure.

However, I'm confident that MSCDEX and similar device drivers can overcome the limitation in principle.

As fas as I know, MSCDEX uses the network redirector interface. Those NTFS read-only file system drivers for DOS do use it, too, I believe.

So the absolute limit must be related to register sizes/adress ranges used in the application code of some sort, rather.
Or within the limits of what the API allows.

Again, I'm just a layman here. Things are sometimes not like they seem.

An example: CP/M doesn't know about sub directories, for example. So the DOS compatibility layer in DOS Plus has to work with "virtual" sub directories.
That has a positive side effect; it doesn't have the same limitation when it comes to the depth of sub directories as DOS has.

Mu0n wrote on 2023-12-14, 11:08:

I just gave a thought to the 7 CD Phantasmagoria, which needs some severe disk swapping during gameplay. Due to the 2gb limit, m […]
Show full quote

I just gave a thought to the 7 CD Phantasmagoria, which needs some severe disk swapping during gameplay. Due to the 2gb limit, my first thought is that it'd be impossible to go beyond 3 mounted CDs at a time roughly using a netdrive.

Then I tried the following:
-(from modern PC) Put CD1 iso into a .dsk, serve it
-(from vintage PC) connect to the netdrive, mount the iso, install the game, run the game
-(from vintage PC) deliberately go to a later chapter that requires another mounted CD, wait for the disc swap prompt
-(from modern PC) kill the serve session, modify the .dsk and use the exact same .iso name (despite it being really another disc iso), same .dsk name, re-serve it
-(from vintage PC) hit enter to finalize the disc swap

Unfortunately, it won't let me do this hot swap and I get a "DOS Error, Enter to retry, ESC to wait".

Is there another method to attempt this?

mTCP NetDrive is "session" based; when you connect you get a unique session number from the server. Killing the server , swapping the file, and restarting it fails because DOS tries the next operation with the old session number. The reason for doing this is you don't want a DOS machine which possible has stale buffers trying to write to an image file. That can cause corruption.

I don't see any sort of "change media" support like this coming soon; it's just too risky for the data.

Jo22 wrote on 2023-12-14, 20:46:

There's no strict 2GB partition limit in MS-DOS 5/6, it technically can support around 3GB no problem. […]
Show full quote

There's no strict 2GB partition limit in MS-DOS 5/6, it technically can support around 3GB no problem.

However, this requires patching of a few DOS files. It's also not very efficient with FAT16B and a lot of small files.

But if only a handful of large files are being stored, it might be useful.

Edit: More information here.

I assume the patch is to change DOS to change sectors per cluster to be an unsigned byte instead of a signed byte? Where can I find this patch?

The official 2GB limit comes from 65536 clusters at 64 sectors per cluster and 512 bytes per sector. That works out to 2GB. But the original definition limited the sectors per cluster to 64, as it was using a signed byte value. If you treat the signed values as unsigned values, then you can get to 4GB on a DOS partition.

The tool I provided assumes nobody has patched DOS in any way. If you create a larger FAT16B image with another tool and your DOS has been patched to support it, NetDrive should be fine with it but I've not tested that.

mbbrutman wrote on 2023-12-15, 00:58:

I assume the patch is to change DOS to change sectors per cluster to be an unsigned byte instead of a signed byte? Where can I find this patch?

Hi, the patch is in the gt1024.zip file attached to the old posting in the link.
I'm afraid I'm not competent enough to deliver a proper explanation how it works in detail.
Its author can do that way better, I believe. He wrote a few text files with some information.

Long story short, it uses 12-Bit sector numbers rather than 10-Bit ones (via normal int13h, not just the extended one).
Older AT BIOSes allowed this approach more likely than the newer ones. Virtual PC 2004/2007 had a compatible BIOS, too, however.

Edit: I forgot. The changes described were made with MS-DOS 5 (English) in mind, but there's 5.0 and 5.0a..
Anyway, just saying. It might be that other DOSes have the code that needs to altered in a slightly different spot.

mbbrutman wrote on 2023-12-15, 00:51:

I don't see any sort of "change media" support like this coming soon; it's just too risky for the data.

I'm also wondering if there's any obscure "switcher" TSR that exists out there, kind of like there was in the Macintosh pre-System 7 days when precursor multitasking (and ultimately bugging for several apps) tools were popping out.
The case of mounted CD rom images avoids the problem of data corruption since it's read only. The only goal is to let a conditional flag return true for the .iso to show that it's mounted for the game at specific times. The prompt even lets the user confirm exactly when to check that the cd is "inserted".

maxtherabbit wrote on 2023-12-14, 03:36:

But it could work the way you want it. If you load MSCDEX and manually specify a higher drive letter then you could still later load the block device driver with CTLOAD or whatever you're using and it would pick up the lower one and all would be well, that's my point

Yeah, for quite a while I've told both modern Windows versions and MSCDEX to assign Z: to my CD/DVD drives, which has worked pretty well to keep drive letters relatively stable except in DOSBox since it reserves that drive letter 😁

mbbrutman wrote on 2023-12-15, 00:51:

I don't see any sort of "change media" support like this coming soon; it's just too risky for the data.

General question directed at anyone who knows: does DOS even support changing media for block filesystems? I think for example Zip disks were treated as removable media, but I presume they always went through an ASPI layer (or was that only for the SCSI models?), so I presume they weren't treated the same as this NETDRIVE.SYS?

A somewhat related thought which isn't of much value as I don't have time to investigate it: I've wondered in the past how hard it would be to implement ASPI over IP/Ethernet and whether that would be a nice way to enable both FAT and ISO filesystems to be made available over a network. I imagine it would be a bit more memory hungry because it'd require ASPI disk and/or CD drivers to also be installed.

doshea wrote on 2023-12-17, 00:21:

General question directed at anyone who knows: does DOS even support changing media for block filesystems?

I guess it does - how else could it support floppy disks?

changing media, yes. changing media *type* no. AFAIK you cannot change the DPB you pass to DOS at the time the block device is loaded after the fact

doshea wrote on 2023-12-17, 00:21:

General question directed at anyone who knows: does DOS even support changing media for block filesystems? I think for example Zip disks were treated as removable media, but I presume they always went through an ASPI layer (or was that only for the SCSI models?), so I presume they weren't treated the same as this NETDRIVE.SYS?

A somewhat related thought which isn't of much value as I don't have time to investigate it: I've wondered in the past how hard it would be to implement ASPI over IP/Ethernet and whether that would be a nice way to enable both FAT and ISO filesystems to be made available over a network. I imagine it would be a bit more memory hungry because it'd require ASPI disk and/or CD drivers to also be installed.

DOS supports changing the media type when the media changes. It also allows the driver to provide a new BIOS Parameter Block, which in turn changes the Drive Parameter Block. (The DPB is derived from the BPB.)

NetDrive.Sys literally does all of this; when it first loads it uses one media type and one BPB to describe the tiny RAM disk it uses to signal that it is not connected. When you connect to a remote image it changes the media type byte and constructs an entirely new BPB, which forces DOS to make a corresponding DPB. When you disconnect it happens again. The BPB and resulting DPB are completely arbitrary and depend on what remote image you are mounting. And no special trickery is required; I did not use any undocumented DOS features.

An ASPI driver that uses Ethernet under the covers would be possible. As long as it presents the same API to the next layer above.

-Mike