Mike Chambers
Veteran Member
- Joined
- Sep 2, 2006
- Messages
- 2,621
Would anyone else find a piece of software like this useful? I've been experimenting with the idea of an int 13h network disk driver layer via UDP and am wondering if I'm the only one who would find it useful? I have more old PC's than I have hard drive controllers, plus there are old laptops that only have floppy drives but can take a parallel port Ethernet adapter like a Xircom.
Like, the concept I have is this:
1. Boot a DOS disk that contains the loader, a packet driver, and a small driver payload written in asm.
2. Reserve a little RAM at the very top of conventional memory.
3. Load the packet driver and payload into the top of RAM.
4. Update BIOS data area with new amount of available memory.
5. Transfer CPU control to driver payload.
6. Driver destroys DOS by overwriting int 21h vector, containing just enough emulated functionality to make your typical packet driver work.
7. Runs packet driver and registers a packet receive callback with it.
8. Hook int 13h and handle calls with DL=80h (drive select hard drive 1), passing calls meant for other drive numbers to the original int 13h handler.
9. Driver bootstraps remote hard disk image by reading the boot sector into 0000:7C00 and transferring CPU control there.
10. Disk image loads whatever OS is on it!
At this point, the payload's int 21h emulation isn't needed anymore so the remotely booted DOS can safely overwrite that vector again.
Then it can talk with a Windows/Linux/whatever server hosting a hard disk image file via a simple UDP protocol.
I've got this working already in preliminary form under DOSBox-X, and it's able to boot MS-DOS over the network and run software/games. No sector write support yet, but easy enough to do. I haven't done any testing beyond that yet. Need to add more features, make the code prettier and do a lot more testing.
Can anybody think of any possible pitfalls? I'm sure there are many. For example, it seems to me like having interrupts enabled during sector reads may not be a great idea, but I need it to receive packets and for timing packet resends lol. Is that a problem? So far it seems happy enough. I'm not sure what other int 13h drivers do regarding that.
But the nice thing about this is that it's at the int 13h level! Theoretically, the only software that wouldn't work with this type of driver would be specialized utilities that want to talk directly to a specific kind of hard disk controller or programs that truly need a full 640 KB of RAM.
This could also be made to be an add-in card with a ROM version of it, though you'd also need to include a little SRAM if you don't want to steal a bit of conventional memory. Or it could be loaded from a floppy disk into VGA memory at segment A000 and it would work, keeping 640 KB conventional available... as long as you don't run any software that actually uses VGA.
Like, the concept I have is this:
1. Boot a DOS disk that contains the loader, a packet driver, and a small driver payload written in asm.
2. Reserve a little RAM at the very top of conventional memory.
3. Load the packet driver and payload into the top of RAM.
4. Update BIOS data area with new amount of available memory.
5. Transfer CPU control to driver payload.
6. Driver destroys DOS by overwriting int 21h vector, containing just enough emulated functionality to make your typical packet driver work.
7. Runs packet driver and registers a packet receive callback with it.
8. Hook int 13h and handle calls with DL=80h (drive select hard drive 1), passing calls meant for other drive numbers to the original int 13h handler.
9. Driver bootstraps remote hard disk image by reading the boot sector into 0000:7C00 and transferring CPU control there.
10. Disk image loads whatever OS is on it!
At this point, the payload's int 21h emulation isn't needed anymore so the remotely booted DOS can safely overwrite that vector again.
Then it can talk with a Windows/Linux/whatever server hosting a hard disk image file via a simple UDP protocol.
I've got this working already in preliminary form under DOSBox-X, and it's able to boot MS-DOS over the network and run software/games. No sector write support yet, but easy enough to do. I haven't done any testing beyond that yet. Need to add more features, make the code prettier and do a lot more testing.
Can anybody think of any possible pitfalls? I'm sure there are many. For example, it seems to me like having interrupts enabled during sector reads may not be a great idea, but I need it to receive packets and for timing packet resends lol. Is that a problem? So far it seems happy enough. I'm not sure what other int 13h drivers do regarding that.
But the nice thing about this is that it's at the int 13h level! Theoretically, the only software that wouldn't work with this type of driver would be specialized utilities that want to talk directly to a specific kind of hard disk controller or programs that truly need a full 640 KB of RAM.
This could also be made to be an add-in card with a ROM version of it, though you'd also need to include a little SRAM if you don't want to steal a bit of conventional memory. Or it could be loaded from a floppy disk into VGA memory at segment A000 and it would work, keeping 640 KB conventional available... as long as you don't run any software that actually uses VGA.
Last edited: