• Please review our updated Terms and Rules here

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

A

alank2

Veteran Member
Joined
Aug 3, 2016
Messages
2,264
Location
USA
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?
 
alank2 said:
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?
Click to expand...

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.
 
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.
 
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.
 
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.
 
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.
 
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-dos-device-drivers/184402277
 
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..

View attachment pddos.zip

View attachment ddjredir.zip

I'll look around for the backpack code--I know that I've uploaded it before.
 
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.
 

Attachments

  • scanbp.zip
    11.3 KB · Views: 3
I don't know if it'd be helpful at all, but on the AVR end maybe there might be some value in looking at the code for the "plipbox", an Arduino-based dingus that interfaces with a parallel port to emulate a network device.

https://lallafa.de/blog/amiga-projects/plipbox/

I saw the code for etherdfs was mentioned above; EtherDFS runs over a network but it uses a really simple layer2 protocol, it might not take that much to strip out the packet driver code and bolt on a simple parallel port driver, and the server-side code might give you a lot of clues how to implement the AVR end if your plan is to have it do the FAT filesystem handling itself instead of doing a block device.
 
I picked up a laplink cable and I noticed that in addition to the 5 bits going in each direction (d0/d1/d2/d3/d4 connected to error/selin/oopaper/ack/busy), it also has strobe/linefd/reset/selprt directly connected. Can these 4 pins (strobe/linefd/reset/selprt) be used for 4 more data bits to send more than 1 nibble at a time? I found a page talking about how they are open collector so either side can release or drive them low. I was able to get around 82+ KB/s between my Compaq 486 desktop and a P3 Compaq notebook using Norton Commander link, but I am assuming it just uses 4 bits at a time. Between the P3 notebook and my 5170 AT, around 27 KB/s.
 
Take a close look at the PC XT printer adapter in the IBM techref. There are 5 lines that can be used as input. No matter what your own reference says, all output lines are driven with totem-pole drivers, but for the status lines--which are the same 5 ones used for input. The idea is that the printer adapter can self-test.

Clones and later systems can have much reduced circuitry. A common hack is to modify the adapter so that bit 5 in the control register (LS174) controls the OE/ pin on the 374, so that 8 bit bidirectional function can be realized. I wrote about it in the 1980s and actually had it mentioned in Nuts'n'Volts when I used it to hack a cheap clone printer adapter to function as a GPIB interface.
 
I did a search for the IBM techref, but didn't see much I could make sense of. I'm really asking about the 4 lines (strobe/linefd/reset/selprt) that say they are bidirectional/open collector. The page I was looking at suggested that if you write "xxxx0100" to the control port that this causes the 4 lowest bits to allow these 4 lines to be released/hiz/high. Then the other side could control them by either leaving them hiz or driving them low. These 4 lines are directly connected in the laplink cable I bought - is it safe for either side to drive them? I'm assuming it is since they are connected. Thanks for your help!!
 
Yes, they're open collector, at least on the IBM gear (usually driven by 7405 inverters). But what would be the point of using them in output mode, aside from implementing some sort of multi-drop network? If you want to try it, remember to use some pullups on the lines.

You've already got 8+strobe output lines.
 
Unless my thinking is off (and it could be), my thought was I could use them for another 4 bits in addition to the 5 bits in one direction and 5 bits in the other direction of the laplink cable. I have to think that that is the reason they implemented them in the cable, so you could do either 4 bit transfer, or 8 bit transfers.
 
Okay, so I made up a test program and sure enough the 4 bits (3selprinter, 2initprinter, 1autolf, 0strobe) in the control port can also be used to send data to the other side. One of them is inverted compared to the other 3, but xoring with 0x04 can easily correct that where I can write "0000" to one of them and "0000" to the other and reading will result in "0000". If any side has a bit set, it will read set on both sides (OR operation between them). So, I could use these bits to double the transfer speed by one nibble at a time to one byte at a time even using old spp type ports. I tested this between a P3/700 compaq notebook and a 5170.
 
SO essentially I have 5 lines in each direction plus 4 shared lines. Does it matter what bit I use for the strobe? Especially given that I am not going to use any interrupt features, can I bit any bit of the 5 in each direction? I plan on doing something like this:

set 4 shared bits to high nibble
set 4 non shared bits to low nibble + 1 bit as strobe "high"
other side will see the strobe high and sample the 8 bits to reconstruct a byte.
it will take its strobe high to tell the other side it has received the byte.
then the original side could send another byte, except this time taking strobe "low".

This would require bytes to be sent in pairs to leave the strobe low at the end.

If the master side wants to receive a byte, it wouldn't drive the 4 shared bits, but instead sample them along with the dedicated 4 bits to receive a byte.
 
SO essentially I have 5 lines in each direction plus 4 shared lines.
Click to expand...

No, essentially, you have 5 lines in each direction.

Here's what some code that I wrote 30 years ago as part of a larger product. I don't expect that you'll copy this verbatim, so I've left out the "include" files. It should give you a good idea of how this workd. Made to work on anything from an 8088 to whatever with parallel port. Timing and checking are essential to reliable operation. Block-oriented protocol using a LL parallel cable.
 

Attachments

  • pport.zip
    6.7 KB · Views: 2
Chuck(G) said:
No, essentially, you have 5 lines in each direction.
Click to expand...

I must be missing something. I've got:

D0-D4 going to error/selin/oopaper/ack/busy IN BOTH DIRECTIONS (full duplex).

Then I've additionally got:

3selprinter, 2initprinter, 1autolf, 0strobe that are essentially half duplex.

My thinking was use the 5 as a 4+1(strobe) and the additional 4 to make 8. You can't do full duplex 8 bits in each direction, but you can do half duplex 8 bits in one direction or the other.
 
You must log in or register to reply here.
Back
Top