First post, by JAKra85
I've encountered an error and spent many hours in solving it, will post the details here for future reference.
-=Everything below is summarized with the help of AI.=-
The Symptoms:
When setting up an original IBM PC XT (5160) with a 3Com EtherLink III (3C509B) network card (running Nestor’s 8088-patched packet driver) and an original IBM 1816101 (Xebec) MFM Hard Disk Controller, the following behavior occurs:
1)
DHCP.EXE and SNTP.EXE work flawlessly.
2)
The network card configuration utility (3CCNFG.EXE) opens fine on a clean boot, and the EEPROM can be saved to a safe 8-bit IRQ (like IRQ 3 or 5) and a clean base I/O address (like 0x210).
3)
As soon as the packet driver is loaded (3C509.COM 0x60), running 3CCNFG.EXE instantly freezes the system. Furthermore, trying to download/upload data via mTCP FTPSRV.EXE causes a hard lockup in a second or a couple of light directory commands.
The Root Cause: 10-bit Address Aliasing & the Untouchable 3Com ID Port
The issue is a hardware clash caused by a combination of the IBM XT's 8-bit ISA bus limitations and the physical ASIC architecture of the 3Com 3C509.
1)
The 10-bit Address Aliasing (Ghosting) Bug
The original IBM PC XT motherboard was designed to look only at the first 10 bits of an I/O address to decode peripherals, completely ignoring the upper 6 bits.
In a 16-bit address, hexadecimal 0x110 and 0x310 are actually written like this:
0x110 in binary is: 0000 0001 0001 0000
0x310 in binary is: 0000 0011 0001 0000
On the IBM XT's 8-bit ISA bus, only address lines A0 through A9 are connected to decode standard I/O devices. This means the motherboard reads only the lowest 10 bits of the address and completely ignores the highest 6 bits (lines A10 through A15).
If we look strictly at the lowest 10 bits (counting from the right)and we strip the top 6 bits (which the XT motherboard is blind to), both addresses resolve to the exact same 10-bit footprint: 01 0001 0000.
------Ignored (6 bits) │ Decoded by XT (10 bits)
Port 0x110: 0 0 0 0 0 0 │ 0 1 0 0 0 1 0 0 0 0
Port 0x310: 0 0 0 0 0 1 │ 0 1 0 0 0 1 0 0 0 0
Because of this, any write operation sent to 0x110 by a network utility physically echoes/ghosts onto 0x310 across the ISA bus.
2)
The Hardcoded 3Com ID Port
The 3C509 is a jumperless card that utilizes a specialized "ASIC ID Port pattern match" routine to wake up from its dormant state or re-verify itself during high-traffic buffer states. This ID Port is hardcoded into the silicon chip at 0x110 and cannot be disabled or re-routed by any configuration utility.
3)
The Xebec MFM Controller Matrix
The IBM 1816101 (Xebec) MFM controller is a hardwired factory-default board locked entirely to base I/O address 0x320 (monitoring the range of 0x320 to 0x32F). Because of its early 8-bit design, its address decoding matrix listens broadly to data cycles hitting the 0x300–0x32F block.
4)
Why DHCP Works, but FTP/3CCNFG Crashes the System
- DHCP/SNTP: These are tiny, instantaneous network packets. They push data to the network card’s operational buffer (e.g., 0x240), bypassing the ID Port entirely after initialization.
- 3CCNFG.EXE Post-Driver: When the driver is loaded, the card is active. Running 3CCNFG.EXE triggers a secondary query sweep to the hardcoded ID Port (0x110). Due to the XT's 10-bit aliasing, this pattern sequence is simultaneously slammed right into the Xebec controller's 0x310 command registers. The MFM controller misinterprets these network bytes as a malformed disk command, enters an unhandled loop, and permanently locks up the ISA bus.
- FTP File Transfers: During a continuous, heavy TCP data stream, the 3Com card's internal FIFO buffer fills up or hits a network collision. The 3C509 ASIC automatically fires an internal synchronization check back through its 0x110 ID Port to check its bus state. The second it touches 0x110, it injects garbage data into the active Xebec disk writing sequence, corrupting the disk controller state and freezing the CPU.
The Permanent Solutions
Since neither the 3Com hardware ID Port (0x110) nor the stock IBM/Xebec MFM controller (0x320) can be shifted via software, you must modify the hardware configuration to isolate the address blocks.
-=AI summary over=-
I have replaced the IBM/Xebec MFM Controller with a Western Digital WD1002A-WX1 one. Made in 1985, so somewhat era-correct.
It would have been nice to leave the original Xebec controller... oh well...
I can now copy data easily from my modern Win11 PC to the IBM with XTFTPSRV.EXE and other network functions will no longer crash the system.
Retro PC Gallery:
https://docs.google.com/document/d/1ara32t4rV … nU/edit?tab=t.0
