Help needed with mTCP and the Xircom PE3-10BT adapter

[hyperfrog]

Got my Xircom PE3-10BT Ethernet adapter the other day. Read Mike's DOS networking pages. Found the packet driver for the PE3-10BT (PE3PD.COM). Set up Internet Connection Sharing on my Windows XP box (which has two network adapters) in order to have a DHCP server running on the unused adapter. Connected the PCjr to that Windows XP box using a crossover cable. Loaded the packet driver, which recognized my Xircom adapter on LPT1. Fired Mike's DHCP client. And it worked... a few times.

More often than not, the DHCP client aborts with a "Failure to get DHCP address" message, but it does work from time to time, in a random manner. When it works, I can also use the FTP client, but after a few moments, the connection becomes slower, and the FTP client ultimately stops working. I never experienced dropped packets. Sometimes the DHCP client fails, saying it did receive some packets, which I deem strange.

I just can't tell what the problem is. I tried different settings with the packet driver (non-bidirectional, different software interrupt), but no luck. I never got it to work with my router's DHCP server (i.e. connecting the PCJr to the router with a normal cable), but it could be a matter of chance.

Could somebody help me? This is getting a bit frustrating!

Thanks,

Christian

[Brutman]

What command line arguments are you using with PE3PD.COM? I disable the interrupt feature which causes it to hook the timer interrupt and poll the adapter instead. (Both of my parallel port sidecars would be using the same hardware interrupt, which could be nasty.) Use int=0 to disable interrupts on it. Otherwise, if you have something else on a parallel port and it causes an interrupt things will get very messy. (See my script below.)

There are two other issues that I know of. The first is that Jrconfig uses a software interrupt, so on my system 0x60 is taken already. I tell PE3PD.COM to use 0x61 instead. I don't know what happens if you let PE3PD clobber the interrupt Jrconfig is using. (If you are not using jrconfig you might not have this problem.)

The second issue is that there is a weirdness about the PCjr BIOS that I don't think that most people are aware of. The software interrupt range reserved for user applications is 0x60 - 0x80. In memory they start at 0000:0180 and take up a double word (4 bytes) each. If I look at my machine after it boots to Cartridge BASIC it has the following memory addresses in those interrupt slots: F000:F815. (If you use DEBUG to examine 0000:0180 you will see this, but remember this is a little endian machine so the bytes are reversed. In the interrupt vector slots the segment offset is the first two bytes followed by the segment in the next two bytes.)

Anyway, this points at some code in the BIOS. I have no idea what the code does, but I'm quite sure that on an original IBM PC there would be zeros in those interrupt slots to signify that they are not in use.

In ancient memory I think that PE3PD would refuse to load or die if the F000:F815 value was in the software interrupt slot you told it to use, but maybe my memory sucks. Just to be on the safe side, I wipe out the four bytes at 0000:0184 (where software interrupt 0x61 is stored). I use this script to do it:

Code: Select all

echo Fixing interrupt vectors
debug < intscr.dat
echo Loading packet driver
pe3pd sint=61 int=0

And in intscr.dat are the following commands that debug will run:

Code: Select all

e 0:0184
00 00 00 00
q

In summary, that wipes out the bogus value from software interrupt 0x61 so that PE3PD can load and use it.


A few other questions/comments:

• Are you on a bi-directional parallel port or an unmodified parallel port? Either one should work.
• I would go back to a direct cable connection to the router. Get Windows out of the picture. The DHCP client works fine against Linux, my Linksys router, my Motorola cable modem, and the DHCP servers I have at IBM. Windows is probably OK, but that just complicates the setup.
• If you plug into a router or hub first, can you tell from the LEDs if it is autosensing the connection correctly? The Xircom is a 10Mb/s device.
• Do you have the keyboard cable connected, or are you using batteries on your keyboard? (Yes, I'm serious ...)
• What DOS are you using? What other device drivers/software do you have running?

At worse case I can give you a diskette image with DOS 5, my PE3PD and known working copies of everything. My setup is rock solid. I want yours to be too.

[hyperfrog]

Still not working.

Hardware:

IBM PCjr computer w/ V20 CPU
512K RAM (64+64+384)
PCjr keyboard (wired)
Racore Drive Two Enhancement Package
Xircom PE3-10BT Ethernet adapter
Straight through Ethernet cable
2Wire ADSL+ modem/router

Software:

MS-DOS 6.22
JRCONFIG 2.14
DOSKEY
PE3PD 3.08
mTCP tools, April 26, 2009 version

There are no other TSR or device driver loaded in memory.

The only parallel port in this setup is the one provided by the Drive Two sidecar. MSD says it uses port 0378h and IRQ 7. I modified this parallel port to be bidirectional. I am confident that my mod is OK, though it is not yet fully tested. Actually, I thought using the PE3-10BT would a good way to test it... INTERLNK still works fine with the modified port, though I think it only uses nibble-mode transfers by design. PE3PD reports that the adapter will be using the bidirectional mode (unless I use the NON switch).

The status LED turns green when I connect the PE3-10BT to one particular adapter installed in my XP machine using a crossover cable. When connected to any other adapter, hub or router that I own, using a straight through cable, it remains orange most of the time, but it blinks green maybe twice a second. This is strange; I thought this LED should turn and remain green whenever a link is established. When connected to a hub, a LED on the hub indicates that a 10Mbps connection is established.

I tried software interrupts 0x60, 0x61, and 0x70, with and without a hardware interrupt. I also tried to force non-bidirectional mode. I used the script that wipes out the four bytes at 0000:0184. No luck. The packet driver never displays any error messages, except when I forget to plug the adapter in.

I also tried the adapter and mTCP with a modern PC (Pentium III). This machine has Windows 98 SE installed, but I booted it into DOS mode (i.e. DOS 7.1). I tried software interrupt 0x61, with and without a hardware interrupt. No luck. So it seems that the problem is not related to the PCjr, its parallel port, or JRCONFIG. I think that leaves four possibilities: the adapter, the DHCP server, DOS (I only used 6.22 and 7.1), or mTCP (I only used the April 26, 2009 version).

Using either the PCjr or the PC, I noticed I can "see" the DHCP client send its first packet: one of the adapter's two LEDs blinks when I hit the ENTER key. However, the adapter or the software doesn't seem to receive any incoming packets, and it times out after a few seconds. By the way, I only used the modem/router in this series of tests, and it *never* worked, not a single time.

Maybe the adapter is defective. I'd like to rule out this possibility. How could I test it using something else than mTCP? Something small and simple. Any ideas?

I think I will conduct further testing on the modern PC, because it is much simpler for me to do so.

Thanks a lot,

Christian

[Brutman]

There are some debug flags you can set in mTCP to help figure out what is going on.

Before you run the DHCP server I want you to set two environment variables:

SET DEBUGGING=255
SET LOGFILE=tcplog.txt

If those are set the mTCP apps will do a nice packet level trace to the named text file. Send that to me, and maybe I can see something tragically wrong.

Mike

[Brutman]

Christian,

Here is a boot disk that contains PC DOS 5.02, JrConfig, PE3PD, DHCP and FTP. It is self contained - you should be able to boot it and run it with no other files. ( http://www.brutman.com/mtcpboot.dsk ) You can use dskimage or your favorite diskette archiving program to write it back to a floppy.

My Xircom is on LPT2 which is different than yours. PE3PD should be able to find it either way.

Now, onto your setup ...

You are running a Drive II and I am running a straight Jr. We both have the V20. I don't have a lot of experience with the Drive II parallel port, but I can't imagine that they screwed that up. Do you have the switch on the back in Jr or PC mode? (It should not make a difference.)

My machine runs DOS 5.02 and a newer version of JrConfig than yours. Our PE3PD is the same, as is our mTCP.

My Xircom is connected to a hub, and the LED on the Xircom is green. According to the docs, orange or red constantly is a cabling fault, while flashing red is a collision on the wire. Flashing would be ok - that's the nature of Ethernet when used with hubs. Steady red is not. (This is the LED closest to the orange band that you use to screw the Xircom to the port with.) The other LED is for activity and will flash green when something is going on.

My script for the Jr wipes out four bytes at 0000:0184 which corresponds to software interrupt 0x61. If you use a different interrupt wipe out the correct bytes. (Multiple your hex interrupt number by four to get the starting byte.) With this boot disk do not use 0x60 as that is in use by JrConfig.

The Xircom distribution disk has a diagnostics program - have you used it yet?

There are other TCP/IP programs out there. The WATTCP ones are very similar to mine, and can be used as a sanity check. If you have an adapter problem those will be fubar too. Another possibility is to use static addressing - just set the parameters in the mTCP configuration file to something sane for your network, then use FTP directly without running the DHCP client. If you have a DHCP server problem this will get you around it. If you still have problems communicating, then we are down to hardware or my code. We all know my code is perfect so .... (just kidding - weird crap happens all of the time. But I think the code is stable.)

Also, don't forget to use the environment variables from the previous post to get me a trace ..

Mike

[NTEPB]

Hi Christian. Thank goodness you received the adapter in the mail. I was starting to wonder about that...

Before I sent you the adapter, I tested it on 3 of my systems, and all of them worked fine with the Xircom. I'm curious about something...are you using a wall-wart AC-to-DC adapter to plug into the Xircom? If so, could you let us know what DC output voltage/amperage you're using? If you're not using a wall-wart adapter, this could very well be the problem.

When I tested the adapter, I used both a wall-wart adapter (with my PCjrs) and the Xircom mouse-port pass-through cable (on my P3 laptop). I think most parallel ports don't shoot out enough voltage/amperage to kick on the Xircom. On another note - with my dad's PCjr, I've sometimes had to run the built-in diagnostics (Ctrl-Alt-Ins) and conduct the LPT test with the adapter plugged in, which then kicked it on for some reason...even with a wall wart. Go figure!

Crossing fingers!

Jon

[Brutman]

Jon,

That's a very good point - I was going to post another message about making sure external power is being provided to the Xircom. It can not run off the parallel port alone - that is not even an option with it. Are you using the Xircom provided wall-wart or a generic one? The official Xircom wall-wart says 12V DC output at 300mA. The manual says it is 12V DC at 500ma, which seems to be very high. The center post is positive, the outer shell is negative.

The keyboard cord is another issue - if you are not using a keyboard cord then you should be. The POST on the machine does a self diagnostic on the infra-red port that can leave the Intel timer chip in a semi-bad state. If the keyboard cable is detected then the diagnostic is not done and the port is left alone.

The bad state on the timer chip affected the operation of my parallel-port to SCSI adapter. I doubt the Xircom is affected the same way, but it's so easy to try it and be safe.


Mike

[NTEPB]

Hi Mike.

I have one original Xircom power brick, as well as 3 Xircom mouse port power adapters. For a generic wall wart, I use a 3-12VDC 1A power brick (it's a big one!). All 10 of my adapters work without any power issues.

With my dad's PCjr, I'm thinking that there's something with PC-DOS 3.30, where it doesn't initialize the LPT port properly compared to other DOS versions...which is why sometimes I have to use the Ctrl-Alt-Ins diagnostics and run the LPT port test. After that, running the Xircom works perfectly. Both he and I use corded keyboards (he uses the original "replacement" keyboard, I use the PCE 101-key keyboard).

Jon

[Brutman]

Doesn't initialize the port, or doesn't find it?

I have a Jr here with a modified sidecar and sometimes it doesn't find the sidecar. If the POST routines find the sidecar they fill in the addresses in the BIOS RAM areas starting at 0000:0400. Patching in the address or rebooting usually clears the fault up. Maybe that is what diagnostics is doing for you.

There is very little to do to initialize an LPT port, especially if it is just a standard port (non EPP or ECP). I'd be surprised if DOS does anything to it at all.

'All 10 of my adapters' - stocking up?

Mike

[hyperfrog]

Hi dudes,

Let me start with a few precisions about my setup. First, my keyboard is wired. Second, the switch on my Drive Two is in the "jr" position. Third, to power the Xircom adapter, I use a universal wall wart rated for 1A, which I set to 12VDC, positive center. When the adapter is powered, its status LED lights up, and PE3PD can find the adapter on LPT1, so I don't think there is a power issue. I also checked the output voltage with a voltmeter to make sure it is ok.

I am now convinced that the problem is with the adapter itself. It works for the first few minutes, and then it slowly dies (I witnessed this behaviour again last night). I guess the FTP client performs a few retries when it doesn't receive the data it is expecting, so the death of the connection does not appear to be sudden. I'm pretty sure there's something inside the adapter that doesn't like heat. Well, having nothing to lose at this point, I decided to open my adapter. (If you ever intend to do this, be aware that the shell is glued. I didn't break mine, but it was close.) Visually, everything seemed fine, but there's one QFP chip you really wish is not where the problem lies. I put an ice cube in a small plastic bag, and installed that HSCD (Highly Sophisticated Cooling Device) on the QFP chip... (I guess I'm being pessimistic.) Now, guess what. Yes, it resurrected the adapter... for as long as it takes for an ice cube to melt. By the way, this chip doesn't run hot, just warm, so I think – well, I hope – it’s “just” a bad solder joint. But it could be that the chip, or the PCB, is defective. Well, even if it’s “just” a solder joint, such a chip is hard to deal with, and I don’t know if I will be able to permanently fix the problem. I only own a soldering iron with a not-so-fine tip. Mind you, those ICs are normally picked and placed with a machine, and then the board is put in an oven to solder the components.

No, I wasn't aware of the PE3TEST.EXE program existence. I didn't notice this file in the archive. I read the README file, but it wasn't mentioned. Well the program says my adapter is ok, whether it be "cold" or not, which puzzles me. However, I don’t think this program tests receiving data from an external device, and I'm pretty sure that's what the problem is all about. I can “see” my Windows box send packets to the PCjr, but the PCjr doesn't seem to receive anything. By the way, I got the ice-cooled Xircom adapter to work with the modem/router too.

Mike, I will try your boot disk (thank you!), and I will also send you the trace you asked me to generate, but at this point, I don’t think you will find anything wrong with your software.

Jon, I believe you when you say you tested the adapter. If you used PE3TEST, it doesn’t report any problem here either. Otherwise, if you actually performed a real-life test, it could be that you have air conditioning in your home. I guess most people do in Arizona. Well, I don’t, because it isn’t really essential to my comfort here in Québec City. These days, the temperature is about 75-85 °F, but if you keep your home at, say, 70°F, I guess it can make a difference.

Christian