Image Map Image Map
Page 1 of 5 12345 LastLast
Results 1 to 10 of 45

Thread: How does a DOS SYS driver enable a file system / drive?

  1. #1

    Default How does a DOS SYS driver enable a file system / drive?

    I'm thinking of all those .SYS type drivers that create a new drive letter. I know that is a wide range, everything from a network requester, to a CD-ROM driver, to some sort of parallel port type drive.

    My questions are

    #1 - Does DOS still handle the file system, or can it, if it is presented with a block device?
    #2 - Or does the request get passed to the device and it is expected to be the device system?
    #3 - Or could there be both methods?
    #4 - Is there documentation for how to implement a SYS file to do this?

  2. #2
    Join Date
    Mar 2016
    Location
    Georgia, USA
    Posts
    650

    Default

    Quote Originally Posted by alank2 View Post
    I'm thinking of all those .SYS type drivers that create a new drive letter. I know that is a wide range, everything from a network requester, to a CD-ROM driver, to some sort of parallel port type drive.

    My questions are

    #1 - Does DOS still handle the file system, or can it, if it is presented with a block device?
    #2 - Or does the request get passed to the device and it is expected to be the device system?
    #3 - Or could there be both methods?
    #4 - Is there documentation for how to implement a SYS file to do this?
    I don't know about .sys files, but you might look at

    https://sourceforge.net/p/etherdfs/code/HEAD/tree/

    EtherDFS adds a drive letter via a .com file.

  3. #3
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    34,931
    Blog Entries
    18

    Default

    CD-ROMs and Network drives use the "network redirector" mechanism in DOS. This essentially bypasses most of DOS's block device file system logic and is handled by a series of INT 2FH AX=11xxh calls (see Ralf Brown's list for details). This is actually quite useful, since the interface is abstracted to a great extent. So a CD-ROM is a completely foreign file system, so MSCDEX makes it accessible via a network redirector.

    A standard block device driver essentially provides a basic interface to DOS's file system block device drivers at a more-or-less physical level (e.g. define media characteristics, read sectors, write sectors, format, etc. A block device driver knows nothing of FAT, directories or file names. It provides an "interrupt" and a "strategy" entry point a la Xenix. As DOS isn't multi-talking by nature, the "strategy" entry point just remembers the request block that's passed to the "interrupt" routines.

  4. #4

    Default

    I guess where I am going with this is that I like the idea that someone came up with here of writing a parallel port to microSD driver, but he bit banged the entire thing which I think made it pretty slow. I've used FATFS on an AVR a number of times and I wonder how much performance you could get through a parallel port if the AVR handled the communications to the microSD.

    As far as the parallel port, I would want it to work with even the very first ones that aren't bidirectional although it could be possible something like this could support multiple modes. I've looked at the laplink type cable and it looks like they wire 5 bits in each direction by using the status bits. I'm assuming they send a nibble at a time and use the 5th bit as a strobe in each direction? Does anyone know what type of performance you can get with that in terms of KB/s?

    Then there is the question of block device driver vs. redirection driver. With a block driver I am assuming that MS-DOS is doing the filesystem work and you are forced to use a certain (or at least BPB provided to DOS) size filesystem. This would mean FAT-16 and a size that that particular DOS version could handle. With a redirector driver would you have the AVR use FATFS to do the filesystem work then? So you could theoretically even use a FAT32 filesystem on the microSD and DOS wouldn't be privy to it?

    Then I thought, why reinvent the wheel at all in terms of making a DOS side driver, I've seen many different drivers and networks mentioned like INTERLNK that already do it if someone knows the protocol it uses you could just make a device that pretends to be the INTERSVR side of things. Does anyone know the protocol for INTERLNK/INTERSVR? I tried searching but couldn't find anything.

  5. #5
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    34,931
    Blog Entries
    18

    Default

    Given the size of modern SDHC cards and the limitations of DOS block device drivers and the FAT16 filesystem of pre-Win95 software, it would seem that a network redirector is about your only pathway. I've posted code here in years past that illustrate how a redirector is implemented and I've also posted code that shows how, for example, the Microsolutions Backpack drives communicate by nibbling over the parallel port. So it's not rocket science and certainly within the capabilities of even an AVR Mega-8. I do recommend that you implement your design using SDIO rather than the slower SPI interface. DMA helps considerably, if you're trying to read ahead/write behind while transferring over the parallel interface (allows for overlapped I/O). You just have to implement your own transport protocol--do include error-checking.

    FTDI used to offer a module that gave file access via serial interface (TTL level RS232) to USB drives. I noted it, but don't know if anyone ever followed up on it.

    As far as speeds, 50KB/sec isn't unusual.

    As far as INTERSRVR protocol, you're on your own. It's probably out there somewhere.

  6. #6

    Default

    Is SDIO the 4 bit interface? I'm not sure any AVR's have that, so SPI running at clk/2 is probably still faster than bit banging SDIO. I *think* I could run a SPI fast enough to not be a bottleneck compared to the parallel. If you recall the names or something that would easily find your redirector post/code and/or nibbling parallel port post/code, that would be awesome and give me something to look at. I've done AVR FATFS before so that part isn't an unknown to me, but pretty much everything on the PC side is.

  7. Default

    INTERLNK itself likely used the lower-level block device interface, as I recall INTERSVR didn't run properly on FAT32 partitions. Another clue was that using DIR on the client system would sometimes eat up a lot of time transferring data just to show the amount of free space. 50KB/sec is precisely what I would get out of it, on all but the slowest machines (8088 would get somewhat less).

    Some info about DOS drivers here https://www.drdobbs.com/writing-ms-d...vers/184402277

  8. #8
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    34,931
    Blog Entries
    18

    Default

    Yup, the 4 bit one. I'm pretty much an STM32 guy nowadays and those often include high-speed SDIO interfaces.

    The pddos file shows how a non-standard file system driver is implemented via a network redirector. Note that since the redirector interface doesn't support formatting, a separate utility is used. I've also included code from DDJ that shows how redirection is done. All of this was back in 1997, so I'm a little fuzzy on details, such as which version of PDOS (TMS9900 or 68K) is supported; maybe both..

    pddos.zip

    ddjredir.zip

    I'll look around for the backpack code--I know that I've uploaded it before.

  9. #9
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    34,931
    Blog Entries
    18

    Default

    Here's a little program that communicates interactively with a backpack floppy drive. Shows how communication is done. The Backpack drive is little more than an 8051, some external SRAM and a NS PC8473 FDC, so you can see how the thing operates.
    Attached Files Attached Files

  10. #10

    Default

    Thank you - I appreciate it!

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •