• Please review our updated Terms and Rules here

8-bit ISA Bootable Ethernet Adapter with ATAoE

P

pearce_jj

Veteran Member
Joined
May 14, 2010
Messages
2,808
Location
UK
XT/IDE is great but what about if the HDD was actually an image file on a network server?

The technology for this already exists - ATA over Ethernet (ATAoE): a layer-2 protocol - there's no TCP or IP and the protocol itself is very simple, only about 10 pages. It's nothing like iSCSI (which is horrid). The server side is available on any Linux distro (for example apt-get install vblade on Ubuntu).

Because ATAoE is so simple and since we already have a comprehensive IDE BIOS (the awesome XT/IDE Universal BIOS) that has been specifically coded to allow the use of different physical layers (VL-Bus, 16-bit, 8-bit, JRIDE etc), my gut feel is that we should be able to pull together the functionality of XT/IDE but running via ATAoE and get a usable solution for XT class hardware.

So there are two possibilities:

1. To create a software solution, i.e. a boot ROM that can drive some readily available 8-bit NICs. The problem is that we'd need to embed the packet drivers into the ROM and therefore also emulate a bunch of DOS handlers to make that work; basically create a PXE in ROM. Also I'm not sure how well this could perform.

2. To build our own ISA card using a single-chip Ethernet controller like the SMSC LAN91C96. It seems that this will offload most of the work involved so should perform better, and also we can program for it directly. Of course there's a downside... it's a TQFP-100 package and expensive at nearly £20. But the chip has a reasonable buffer, will work directly with the 8-bit bus, and is 5V.

Hence, looking to open this up to the community!
 
Last edited:
Option 3 use a commodity MCU with built-in Ethernet or 802.11 and a bridge interface to the PC.

Though option 1 is the best bet by far. Could build different packet drivers into different ROM images. I'd start with NE2K and expand as demand dictates.
 
Thanks. That approach also opens up the possibility of using parallel port adapters, for example with a laptop or luggable.
 
In the private conversations I had prior to this thread we discussed some of these options.

Taking other people's packet driver code and making it ROMable is not my idea of fun. For the older cards the code is open source and is available. The Xircom PE3 packet drivers are a notable exception - no source code is available, although it is supposed to be. But even with source code, it is a lot of work.

It also doesn't make sense to keep the packet driver interface. The packet driver interface was designed to allow any arbitrary application to use the Ethernet hardware. In this case if the Ethernet hardware is in use for something low level like INT 13, it is probably not going to be shared.

I think the best solution is to embed the Ethernet on the card and keep it private to the card. Then the BIOS knows exactly what it is talking to, and can do it in the most efficient way. (ie: No software interrupts just to send a packet.) It also cuts down on the testing and programming effort; trying to support multiple Ethernet chipsets would take a lot of effort.
 
I'd start with scratching out a rough BOM and figure out what the cost per unit's going to be; then find someone willing to program and debug the thing.

Personally, I think that those two items will probably be fatal to the project. But I'm happy to be proven wrong. :)
 
ENC28J60 are pretty slow - especially if you have to bit-bang the SPI. But it does potentially allow a completely 5V PTH design.

PIC18F97J60 is a pretty good choice for option 3 since it has an integrated PHY and external bus interface for a FIFO interfacing approach to the ISA bus.

I'm still not sure why option 1 isn't the best choice. I understand Mike's concerns, however with any other option you will need to build an actual board. If you just target the most common chip - NE2000 - and design an Int 13h ATA ROM that work specifically with it, people can pickup any cheap NE2000 off eBay, program a ROM, and be running quickly.
 
My concern? I'm lazy. All good programmers are ...

I'm working under the following assumptions:

  • We need a new board. Sharing an existing Ethernet card means that two slots are required, two sets of I/O and address jumpers are required, and every INT13 op will result in at least 2x the bus traffic that it should. (You might only need one board if your existing NIC has an EPROM socket on it.)
  • We have to hide the Ethernet controller. Somebody trying to run a badly behaved application that touches the Ethernet hardware will crater their system.
  • Having only one Ethernet target to program for is immensely easier.
  • There are a wide variety of Ethernet boards out there. NE1000 was common, but I find many more 3C503 and old WD/SMC 8003 boards in the wild. Even Intel 8/16 boards are pretty common. And for the oddball machines the Xircom is the way to go, except that those @#$@ never open sourced their code after stealing the Crynwr open source framework.


If we are not talking about a new board then just the BIOS extension to use an existing card is fine. But you still have to program for each card; the packet driver source code can help there but you can't use the packet driver directly. And performance will be back down in the original XT-IDE range because of the extra bus traffic.


Mike
 
Perhaps the option of a custom board will be ruled out by a show of hands from those who would seriously consider buying such a board. For example, is a custom board worth the effort/cost for say, 5 people?
 
I assume that ATA over Ethernet would make whatever is on the other end of the Ethernet cable look like a local hard drive to DOS. What would be on the other end? Network Attached Storage, a shared folder/drive? What about DOS's partitioning schemes like FAT16 & FAT32? What kind of read/write performance can be expected? If you use a 10Mbit card, the performance may not be too impressive compared to real ATA interface & drive.
 
An ATAoE server would be on the other end; this exists in the Linux kernel for several years at least. Any Linux box can do the job. Yes the disk would appear like a local hard disk on the XT and everything that could be done with an XT/IDE attached disk could be done with it.

Performance wise, this is unknown. The original XT/IDE did about 60KB/s, later improved to about 200KB/s. RAM copies in the PC/XT are only about 380KB/s. With the single-chip MCU type approach, I guess we could pick up data quite rapidly. Presumably real 8-bit NICs have only a single-packet buffer so things might be more difficult, although 1500 bytes is still enough for 2 sectors.
 
modem7 said:
Perhaps the option of a custom board will be ruled out by a show of hands from those who would seriously consider buying such a board. For example, is a custom board worth the effort/cost for say, 5 people?
Click to expand...

And therein lies the problem with many of these derivative projects - the need is reduced because of the previous projects, and thus the demand is reduced as well.

I was really happy with the first generation XT-IDE. I even grafted one onto a PCjr and hacked the BIOS to make it work. Alan (EEGuru) came along and made it a real PCjr specific adapter, getting it into a sidecar form factor where I was thinking of some mega-hack/kludge expansion unit.

But after that ... well, XT-IDE worked so well. Revision 2 was faster, but for machines that had *nothing* Revision 1 was a quantum leap. And so the derivatives are doomed to starve because their predecessors were so good ...

I like this project because it combines my two great interests - hard drives and networking. I'm willing to throw code into it to make it work. But I need to heed the lesson of the still as of yet unfinished XT-FDC project - I'm over extended and good intentions + cash can't overcome a lack of time. And really, if this is a niche project due to lack of demand then I think that will decide the question of new hardware or not.
 
Continuing ...

On the other hand, having a hard drive interface that uses a virtual hard drive on a backend server is one of the ultimate geek projects - imagine the bragging rights!

I can get 70 to 100KB/sec through a PC XT with an Ethernet adapter using TCP/IP, which is a pretty heavy protocol. And that is on a slow 10Mb/sec Ethernet segment. Also, that is using the packet driver interface which has some inefficiencies in it. Using a lighter weight protocol and owning the hardware directly you can do quite a bit better. Performance would not be an issue. For people who didn't want the Linux box it would be very easy to write a server in Java than can run under Windows and use UDP.

The ability to have an unlimited supply of virtual hard drives to choose from at the end of your Ethernet cable is pretty appealing. And your nerd-cred would be stellar.
 
Glad your on-board!

Is there any reason we can't do both; I mean, start development against a common (any common) NIC, just keep the code nicely in layers so a direct media interface can be dropped in at some future point? I'm happy to prototype an ISA card of course, but there are others here much better equipped to do so than me.

On the subject of cards, the 10 XT-CF-Lite boards I had made all sold within a week. So either the fine-pitched SMT or the need to program the CPLD seemed to put off buyers of the XT-CFv2 board (or maybe a combination).
 
Right now, on my XT clone, which has an XT-IDE and external CF fitted (photo here), I can get multiple boot environments by using multiple CF cards.

From my viewpoint, this 'network boot for vintage computers' proposal is definitely 'a solution seeking demand' rather than 'demand seeking a solution' kind of scenario. But that's okay - this is not a commercial venture. Do it for the enjoyment/satisfaction (and brag rights). In fact, phase 2 could be the additional option of booting from a dedicated server on the Internet (just for the 'wow' factor).

As long as contributors are aware that their efforts may be only be for a few.
 
This would be a very awesome thing to see get made. I've been talking with pearce_jj about it a bit already. I don't have the kind of hardware expertise needed to help design the actual circuitry, but there are a lot of folks here who would be up to the task. I want to get involved on the software side of things, though. (ROM code, etc)

The idea has already gotten me interested enough that I've started writing some assembly code for remote ethernet booting already. I'm just writing it to work with a regular packet driver on any existing NICs for now, but once everything is working it should be fairly easy to adapt it to ROM for a custom adapter like this. It's coming along really well, and I think I should have a basic proof-of-concept all functional in the next 2 or 3 days. It doesn't use DOS to load itself up, I wrote a custom floppy boot sector that loads up my code and the packet driver into the top of conventional memory and reserves it so that booting DOS won't interfere and break things.

Getting packet drivers that are designed to run under DOS working without DOS required a bit of trickery, but was pretty easy. I'll give more details about all of this when I've got it the remote boot totally working and am ready to share. All that's left at this point is handling the actual int 13h calls, which really should be very easy. The memory footprint will be pretty small, the code compiles to about 6 KB right now and I'd be surprised if the whole thing ends up needed more than 8 KB when finished. So, that and the size of the packet drivers (crynwr ones are VERY small) will be all it needs. :evilgrin1:
 
You must log in or register to reply here.
Back
Top