• Please review our updated Terms and Rules here

8-bit ISA Bootable Ethernet Adapter with ATAoE

Mike, thanks for posting this - it's phenominal to see this idea comming alive so quickly :D

Great to hear that the packet driver model looks do-able. So building our own NIC seems somewhat needless, given the progress you're making and especially if the whole thing will fit into just 8K anyway.
 
That is good progress.

So the plan is to adapt the open source Crynwr drivers to run from ROM, and then have the INT13 BIOS use them directly? Are you fixing the API so that you can just do a far call to the code to send packets instead of invoking a software interrupt? How are you planning on handling the server configuration - is it going to be a parameter "burned" in with ROM image or are you going to do something like DHCP to obtain an IP address and get the server IP address?


Mike
 
No, what I do is hook int 21h and have my own handler support a tiny subset of the DOS functions. Just enough of it that the packet driver is able to run and set itself up. All of the packet drivers (including even the proprietary Xircom PE3 driver) I've seen so far only use a small handful of DOS functions, and then once they're installed and go TSR they never do any other int 21h calls again. :)

The complete list:
Code:
Int 21/AH=02h - DOS 1+ - WRITE CHARACTER TO STANDARD OUTPUT
Int 21/AH=09h - DOS 1+ - WRITE STRING TO STANDARD OUTPUT
Int 21/AH=25h - DOS 1+ - SET INTERRUPT VECTOR
Int 21/AH=31h - DOS 2+ - TERMINATE AND STAY RESIDENT
Int 21/AH=35h - DOS 2+ - GET INTERRUPT VECTOR
Int 21/AH=40h - DOS 2+ - WRITE - WRITE TO FILE OR DEVICE
Int 21/AH=49h - DOS 2+ - FREE MEMORY
Int 21/AH=4Ch - DOS 2+ - EXIT - TERMINATE WITH RETURN CODE

For server config, I'm actually just using my own ethertype in the packets which isn't used by anything else. It's just to keep things simple. When it's all working, I was considering using the UDP code from that asm TCP stack I wrote a while back. It would also need the ARP and IP code too though, and would eat up another 4 KB or so. I don't know if it's really necessary though, because I doubt anybody would be trying to use it outside of a LAN anyway. It's going to have it's own simple discovery protocol that just broadcasts a packet that any machine running the server software recognizes and sends a packet with info about itself to the client machine. A nice, clean, and simple way to do it.

Once it's working I'll probably just tinker with adding UDP to it. Maybe it will use less RAM than I'm thinking.
 
Last edited:
Nice!

ATAoE can handle the configuration automatically for us on the server side, by simply using a MAC address binding. So for example using Ubuntu and vblade we could create a blank 250MB disk image and then define an export based on the target machine thus:

dd if=/dev/zero of=5160-System-Disk.img bs=1M count=250
vbladed -m 00:01:2e:bd:2e:ac 1 1 eth0 5160-System-Disk.img


AoE itself is using three fields only - MAC addresses, 'shelf' and 'slot' in vblade terminology (major and minor in the spec, see wikipedia for frame format or the spec itself), but the discover option uses wildcards (FFFh, FFh) in those fields hence the only targets appearing will be those with a MAC address matching the request:

2.5. Major, Minor

Each AoE server possesses a major and minor address. Before
processing the header Command the server must validate its major and
minor address with the Major and Minor fields in the header. A
server will accept a command message for processing if the following
two tests are true:

The Major field in the header is the server major address or all
ones (0xffff).

The Minor field in the header is the server minor address or all
ones (0xff).

Any command messages failing either of these two tests must be
ignored by the server.

The server must supply its major and minor address in every response,
even if the corresponding request had all-ones values.


In that context, an AoE server is per disk image, so multiple "1 1" images can be shared (by MAC address) from a single vbladed host.

So no need to include any layer-3 code at all :D My suggestion would be to always use shelf/slot 1 1 for the first (boot) volume or something like that, so that multiple images could (in future perhaps) be supported too. But TBH, I think one disk image support would be absolutely fine.
 
Last edited:
No, what I do is hook int 21h and have my own handler support a tiny subset of the DOS functions. Just enough of it that the packet driver is able to run and set itself up. All of the packet drivers (including even the proprietary Xircom PE3 driver) I've seen so far only use a small handful of DOS functions, and then once they're installed and go TSR they never do any other int 21h calls again. :)

That was clever, and it gets you around the requirement for the original source code.

(I'm still of the opinion that if the source code is available, use it. The packet driver interface requires a software interrupt for sending every packet two far calls to receive; it's a bit of a pig. But what you have takes care of the Xircom problem, and a lot of the later packet drivers too.)
 
pearce_jj: i think the ATAoE stuff looks like it would work pretty well for this. i'm going to go with what I described first, just to verify everything works nicely then then I will definitely look into switching the protocol.
 
That was clever, and it gets you around the requirement for the original source code.

(I'm still of the opinion that if the source code is available, use it. The packet driver interface requires a software interrupt for sending every packet two far calls to receive; it's a bit of a pig. But what you have takes care of the Xircom problem, and a lot of the later packet drivers too.)

In most cases, you're right source code is the best to work with but I think there are many pros for just using the existing packet drivers as-is. It makes it easy for anybody to make any card work right out of the box. I don't think there's really a meaningful performance penalty from it is there? In any case, all of my code for this will be open-source. We can always tinker with it and see what we can do in the future.

I'm hoping to have something up for download before I go to bed tonight, or sometime tomorrow.
 
I haven't had as much time to work on it as I wanted, but now I've got the basics working and it can use a remote disk image as if were BIOS drive 80h. It doesn't do writes yet, only reads but I'm working on that right now. Here it is doing a boot, and it works fine on real hardware too. It worked the same on my XT. Should have something ready for people to download and play wiith pretty soon. :)

netdrive.png


It's 100% hard-written assembly, and you can see there after reserving the RAM it needs there is still 624 KB free and that's with a packet driver that uses 8 KB.
 
Last edited:
Just wanted to show some proof that it works on real metal too. Here's my IBM 5160. :twisted:

netdrive-xt.jpg


I ran some games (Jetpack, Paku Paku, Ultima 6) on it and they all worked perfectly.
 
Just want to say I've got the write functionality working too. I will try to upload something tonight, I want to add a boot menu and polish up some rough edges first.
 
Your 'workshop' looks as well organised as mine :D Seriously though, this is GREAT.
 
So, in approximately two weeks since pearce_jj came out with the idea of ATAoE Mike already has a working solution? Now that is impressive! And I really like the concept of booting/using a remote 'virtual' disk, liked the idea from the start. I just didn't think it would happen so fast.

-Tor
 
I didn't quite follow the entire thread, as it was very technical. Does this allow the ethernet card to be shared with other software?

Very nice work either way.
 
Hatta,

It allows you to take a well behaved DOS packet driver for the Ethernet card you have and create and burn a boot ROM image that will emulate a hard drive (C:) by reading and writing an image file over the network from a modern server. Initially you would not be able to use the network card for providing anything other than just the virtual drive C: (eg. you could not then run a Doom net game with your friends without a second NIC). However I suspect some sort of driver sharing could be worked out in the future even if it means encapsulating the payload of a second DOS loaded tunneling packet driver over the emulation protocol.

The other caveat is it is a frame based protocol only. Thus it isn't routable at an IP level. Both the server and vintage PC must be on the same Ethernet segment.
 
Yeah, I did it so fast because this is something I've been meaning to create for years anyway! :)

If you guys go to the vintage programming subforum, I just created a new thread in there calling for NetDrive testers! And yes, eeguru network card sharing has been one of my goals from the beginning. It doesn't do it yet, but it will soon. Sharing the packet driver with other software tranparently should be straight-forward enough to do.
 
Hey Mike,
This looks AMAZING! I'll be testing it later today! Is there any way to make this work with a Boot Rom on a NIC so that the floppy would not be needed?
 
Cool, let me know how it works when you get a chance! :)

I was thinking about using a ROM a little bit. It would still require reserving a bit of conventional memory, but yes that would be way more convenient. Problem is that the only EEPROM burning capability I have here at home is with some 8 KB chips. I don't even have a "proper" EEPROM writer. I do it full hobo-style. I took an old LBA BIOS extension card made by DTC, took it's ROM off since I didn't use it for anything, soldered a few connections on the bottom to connect the write enable pin on the ROM socket. :p

I would need a way to work with larger ones. My resident driver is 6 KB on it's own, so it wouldn't leave nearly enough room for a packet driver to fit on there with it. Maybe somebody else out there in vintage computerland would be willing to mod it for ROM use. We should probably move further discussion over to my thread in the programming section.
 
Back
Top