3Com EtherLink II 3C503

28Aug/240

3Com EtherLink II 3C503 – Boot ROMs

The XT-IDE Universal BIOS is a very cool project, enabling older hardware to support much newer storage devices. The safest way to use it is with a dedicted 8-bit ISA controller card, but there are other ways to get started. If you have an Ethernet card with a spare ROM slot on it, you can program an EPROM with their BIOS and boot from there! Or so I thought... enter the 3Com 3C503.

Willem EPROM Burning: 101

I've discussed using the Willem Programmer before and, since working out the caveats, it's relatively straight-forward. Firstly, make sure you have a known-working version of the burning software installed on a known-working machine with a known-working parallel port. Next, check that you have the EPROM-specific dip switches correct, the power at a suitably-high (with enough current!) level and TOTALLY erased EPROMS. I usually leave my EPROMs to cook for around 20 minutes in my super-dodgy Ultra-Viole(n)t eraser.

Another good note is to make sure that you write them more-than-once when programming. Press the program button on the programming software again and again... so that the EPROM is written and verified multiple times. The software will write a byte and check it, and I've had it where the second programming run will fail. The usual reason is that the EPROM wasn't erased well enough, and that the initial write tinkered with residual data/current in the chip's cells, which then settled. The second write will write/read/check and fail as that cell has changed to another value. Erasing and programming again might work, else that chip needs to go in the bin.

Preparing an XT-IDE Boot EPROM

The default ROM can be downloaded from here. Choose the folder whose name begins with an 'r' and has the highest number. This'll be the most-recent release of the software and should be bug-free on all supported hardware. There's a miriad of flavours of the software, so you'll need to choose the one that's right for your hardware.

Burn it to an EPROM. I chose a 27C256 as I had a spare truckload.

Testing it in known hardware

This is paramount. Don't just slap this in marginal hardware and expect things to work. I found a boring Realtek PCI 8139 NIC and slapped the freshly-minted EPROM in.

It was installed in my PIII-500 workhorse and worked first time!

Just for fun, I inspected the area of system memory where it mentioned the ROM was hosted:

Microsoft(R) Windows 98
   (C)Copyright Microsoft Corp 1981-1999.

C:\WIN98JP\DESKTOP>debug
-d d000:0000
D000:0000  55 AA 10 E9 B5 03 58 55-42 32 31 30 2D 3D 58 54   U.....XUB210-=XT
D000:0010  49 44 45 20 55 6E 69 76-65 72 73 61 6C 20 42 49   IDE Universal BI
D000:0020  4F 53 20 28 41 54 29 3D-2D 00 00 00 72 36 32 39   OS (AT)=-...r629
D000:0030  20 0A 28 32 30 32 34 2D-30 37 2D 32 30 29 00 00    .(2024-07-20)..
D000:0040  61 FC 00 00 04 00 00 00-02 80 00 01 00 00 F0 01   a...............
D000:0050  F0 03 00 0E 1D 00 00 00-00 00 1D 00 00 00 00 00   ................
D000:0060  70 01 70 03 00 0F 1D 00-00 00 00 00 1D 00 00 00   p.p.............
D000:0070  00 00 E8 01 E8 03 00 00-1D 00 00 00 00 00 1D 00   ................
-d d197:0000
D197:0000  89 55 12 89 5D 14 31 C9-89 4D 16 C7 45 18 00 02   .U..].1..M..E...
D197:0010  2D 01 40 81 DA EC 00 19-CB 73 04 80 4D 02 02 26   -.@......s..M..&
D197:0020  8A 54 0A 30 F6 89 55 08-89 4D 0A 26 8A 54 0B 89   .T.0..U..M.&.T..
D197:0030  55 0C 89 4D 0E 26 8B 54-0C 89 55 04 89 4D 06 91   U..M.&.T..U..M..
D197:0040  E9 4F FB 81 7E 18 AA 55-75 14 C6 46 1F 21 F7 56   .O..~..Uu..F.!.V
D197:0050  18 E8 0D 00 89 4E 1C 80-66 24 FE E9 3A FB E9 CD   .....N..f$..:...
D197:0060  FA B9 01 00 80 7D 14 04-73 03 80 C9 04 C3 FF FF   .....}..s.......
D197:0070  FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF   ................

Nice, there it is. I dumped it (great tutorial on dumping over here at MESS) for safe-keeping, so I could use it for any comparison in the future:

-n pci-d000.bin
-r bx
BX 0000
:0000
-r cx
CX 0000
:2000
-m d000:0 2000 0100
-w 0100
02000 BYTES WRITTEN
-q

Note that you need to hit enter at the end of any line starting with "-". 0x2000 is 8kb (aka 8192) in HEX. Debug also only cares for 8.3 filenames, so don't give it anything longer.

The actual card to test was this 'trusty' 100yen purchase from a Hard Off in Japan. The 3Com 3C503 was detected and installed under Win98 and worked fine. I then put in the EPROM and nothing happened during a restart!

This card has one thing going for it: configurable jumpers. The ROM location can be easily specified and I'd put it at 0xCC00.

I have no idea if this was a good location, but I went for it. A reboot saw absolutely nothing get executed! To test if it had actually been loaded into memory, I used debug once more:

Microsoft(R) Windows 98
   (C)Copyright Microsoft Corp 1981-1999.

C:\WIN98JP\DESKTOP>debug
-d cc00:0000
CC00:0000  FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF   ................
CC00:0010  FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF   ................
CC00:0020  FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF   ................
CC00:0030  FF FF FF FF FF 00 00 00-00 00 00 00 00 00 00 00   ................
CC00:0040  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
CC00:0050  BF 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
CC00:0060  08 00 45 00 CA 00 8F 02-60 E8 12 01 00 00 32 FF   ..E.....`.....2.
CC00:0070  8A DA 66 D1 E3 66 50 66-BA D4 03 66 B8 1F 57 66   ..f..fPf...f..Wf
-q

Ah yeah, that's not it. I tried a few other locations, landing on D800, but it seems that Windows 98 was stealing the memory back after DOS had loaded. I ended up having to F8 to DOS when booting and debug from there:

That's still not it! But at least it's blank. What am I doing wrong? Turns out this card only supports 27C64 EPROMs and I've shoved a 27C256 in it! Ok, lift the address pin that could be conflicting:

And what do we see?

We're literally a half-step closer! I spent a lot of time googlin' what the @#$ was going on, but then I looked at the card again:

DATA MODE has an option between 16 and 8. I had thought this was Twisted Pair or BNC... but I was wrong. Setting it to 8 (finally) revealed:

Ok, the 'top end' looks good... what about the rear end? The ROM is 8kb, but there's a bit of filler at the end. The ROM data is around 1D7 bytes:

Ok good, but what about the very end? The ROM is 8k, and that's 0x2000 in hex. It's based at 0xD800, so we also need to check up to 0xD9FF:

What... what is that 0x04 0x04? I only had to ask the internet, because... as I keep saying, nothing is new on the internet. Someone has almost always had an issue in the same vein as anything and everything I've ever encountered. The strange thing with this forum thread is that they say that the 3C503 returns 0x80 0x80 as the last two bytes. Above, as you can see, we're getting 0x04 0x04. How broken are we? I dumped the ROM and compared everything with HxD and we're not bad! It really just is the last two bytes.

Ok, so there are the two bad values right at the end. The card is always reporting them and we need to find a work around.

BIOS Option ROM Checksums

We know the EPROM data is being loaded into memory, but we don't know why the system BIOS isn't executing it. I had to dig a bit to find a thread on Option ROM checksums which lead me to a great howto on Etherboot ROM booting. This latter document contained a great list of dot-points that need to be met for an Option ROM to be seen and booted:

How does the main BIOS know that the code in the ROM is to be executed and why does it not execute some random code by accident? The ROM code has several conditions placed on it:

The ROM must start on a 2kB boundary in the memory space, between 0xC8000 and 0xEE000, although some main BIOSes scan outside these limits.

The first two bytes of the ROM must be 55 AA hex.

The third byte of the ROM should contain the number of bytes in the ROM code divided by 512. So if the ROM code is 16kB long, then this byte would hold 20 hex (32 decimal).

All the bytes in the ROM (specified by the length byte just mentioned) must checksum to 8 bits of binary zero. The sum is formed by 8 bit addition of all the bytes, throwing away the carry. Note that there is not a particular location designated as the "checksum byte". Normally the ROM building process alters an unused byte somewhere to fulfil the checksum condition.

From the dump above, we can confirm that we tick the first and second point. For the third point, our third byte is 0x10, meaning that we're 8192 bytes long. This means that if we add together every byte in our 2k ROM, we need to sum to a total of 0. Fortunately, we don't have to do this manually! If we use the checksum calculator over here, it'll run throught the ROM and adjust the last byte to fulfil the checksum zero-sum requirement.

I fed it the ROM dumped from memory, as loaded by the 3C503. Why bother using the correct binary on disk if that's not the way it'll show in RAM?

C:\Users\steve\Downloads>romcksum32.exe \\yadayada\....\3comd800.bin

ROM Checksum Calculator  VER: 0.2 REV: D
Copyright (C) 1998-2021 Microprogramming TECHNIQUES
Programming/PC Code: Alexandru Groza
All rights reserved.

ROM file     : 3comd800.bin
Disk size    : 8192 (8 KiB)
ROM usage    : 100.00% (8192/8192)
ROM checksum : 0x4h (8-bit)

ROM file checksum updated.

So, what's it done?

It replaced the final 0x04 with an 0x49? So it decided that, once summed, we were missing 0x45 to sum back around to zero... sure... but our card is going to whack that final 0x49 back to 0x04. We'll need to 'spread' this checksum'd difference around spare bytes, but they're all 0xFF, so let's change the third-last byte to 0x00 and use it to store the remainder. Running the checksum again after making this change saw:

So, with an 0x00 instead of 0xFF, we now have a final byte value of 0x48. So the FF was worth 0x01? Regardless, if we know the last 0x48 will become 0x04 in the physical machine, we can store the 0x44 difference in the third-last byte:

And you know what? I wrote this version of the binary to an EPROM, inserted it into the 3C503 and IT BOOTED! Of course, this was a stock-standard XT-IDE BIOS ROM. What you ACTUALLY need to do is to run the XTIDECFG.COM file from a floppy with a machine-relevant BIOS loaded and then customise it to the configuration on your machine. This default BIOS tries to load a second ATA controller and causes no end of lock-ups as the hardware isn't actually attached!

I can't believe it worked.