Serial COM1 problems on an IBM AT

[Hugo Holden]

It may not relate to you problems here, but, perhaps deserves some consideration. On async/serial cards, the input chips especially are vulnerable to damage.

There are a few reasons, one is that the serial device being connected may be to a non earthed chassis device, where the common (0v) power rails are not connected to the chassis and the connector shell. If the computer async card is hot plugged onto such a "floating" peripheral device, there can be a significant charge injection into the input of the line receiver IC's (typically 75154) on the cards at the moment of connection , destroying them.

If that doesn't destroy the chips, even plugging in a very long cable with significant electrostatic charge can do it.

So what I'm saying is that while it is likely you have a software issue, it could be a hardware one. Also some faults in serial interfaces can be due to borderline voltage levels, this is where the scope comes in handy. In other words a damaged IC on the card could easily cause it to work in one computer, and not another with borderline levels.

I wrote about one type of aync card issue in my IBM5155, and had me chasing my tail a little until I figured out what had gone wrong:

www.worldphaco.com/uploads/LOST_IN_SPACE_REPAIR.pdf

 

[SteveG]

I have 1 new serial card which has 2 serial and one parallel ports. Photo 1

I have two other working original IBM async serial cards. Photo 2

Once this AT has warmed up it performs reliably but is always tedious to power up because it can require several resets.

I just need a mouse to demonstrate Windows on it. NB, I have a series of IBM PC’s 5150, 5160, 5170 (This AT) PS1, PS2, Think Pad and Compaqu DS20 all showing their different versions of windows.

All the other museum members behave. I plan to get Ethernet working on all but the 5150 so I can move files around using MTCP.

 

[modem7]

I have 1 new serial card which has 2 serial and one parallel ports. Photo 1

Which in future posts, you should refer to as the {Serial & Parallel Port Adapter Rev 1.0}. In that way people will know exactly which card you are referring to.

I have two other working original IBM async serial cards. Photo 2

Best not to refer to that card like that, because people will think that you are referring to an IBM made product. Refer to it as a GW451C.

If the AT is 'iffy' - how do you expect it to work properly with any cards you are plugging in there I ask myself... It may not be the BIOS that is faulty - but the CPU, RAM, etc. etc. etc.

Exactly.

 

[docangle]

I have several(3) of these GW451C cards I got from Computer Reset, and it is almost always a bad tantalum that causes these cards not to work. I went and actively replaced all of them including the ceramic ones(Usually the one that is above the QC Sticker in your photo, that one was bad on all three cards, 1 of them was dead short the other two were not quite there so it would not pop, but cause issues with the cards), since they often are the ones that go pop on these cards(but only if you have a powerful enough power supply), unlike the IBM Motherboards which are the opposite. If you are having problems sometimes at startup, you might want to check your 12v and -12v lines, Most old serial cards require these voltages.

The new card, I have no idea, but if these cards work in other machines, I would be looking at voltage issues as the main suspect, I had a -12V problem on a Tandy 1000EX that caused an add-on 3-in-1 Serial to fail loopback testing. On Classic Macs -12V is used for Audio Chip Amplification.

 

[SteveG]

Thanks

I guess the AT power supply may be the issue so will check the voltages

But It’s strange that only the serial interfaces cause a problem due to low voltage.

 

[docangle]

Thanks

I guess the AT power supply may be the issue so will check the voltages

But It’s strange that only the serial interfaces cause a problem due to low voltage.

Not a lot of devices use -12 Volts, mostly just serial ports. -5V was used mostly for Sound Card Amplifier circuits, and on the original IBM 5150 Boards the memory required -5V. Also, What are you connecting? Are you using a 9 to 25-pin adapter? I recently had an issue where my 9 Pin to 25 Pin adapter went bad on me, one of the wires shorted out internally.

Check B7 and B9 on the Bus, they are your -12v and 12 Volt pins, check them with the serial card installed and not installed and see if the voltage levels drop.

modem7 probably has some other stuff for you to try, but I would start with the basics.

ISA Connector

ISA connector pinout, as used in the IBM PC

www.nullmodem.com

 

[modem7]

If you are having problems sometimes at startup, you might want to check your 12v and -12v lines, Most old serial cards require these voltages.

The symptom at start-up relating to the serial cards has been determined to be an inability of the POST in the 5170 to detect the UART on the cards.
For serial cards that require +/-12V, improper +/-12V is not expected to cause the 'UART not found' symptom.
The circuitry between the UART and the ISA connector only requires +5V.
+/-12V will be for the level converter circuitry.

But It’s strange that only the serial interfaces cause a problem due to low voltage.

Of course, your 5170 may have multiple problems.

The 'Unstable 5170' symptom and '5170 POST not detecting UARTs' symptom could be completely unrelated. For example, maybe one (or more) of the ISA slots in the 5170 are not fully functional.

But if I had a 'known sick puppy', I would be getting that puppy well before I questioned any abnormal behaviour.

 

[modem7]

Once this AT has warmed up it performs reliably but is always tedious to power up because it can require several resets.

Lots of possible causes. Even interference from a floppy drive.

For example, does the 'instability' disappear in only a {PSU+motherboard+keyboard} configuration?
If so, then add back bits one at a time until the instability returns.
If not, is it the PSU or motherboard?

 

[SteveG]

Modem 7 Thanks for your advice.

It makes sense to identify the cause of the poor startup issue before tackling anything else.

My guess may be the floppy interface because it occasionally decides the 5 1/2 drive is the wrong format and requests that I run Setup to correct this.

 

[SteveG]

I have just been testing the AT.

Booted first time from Floppy with no errors.

Booted first time from Hard Drive with no errors.

Ran CHECKIT tests.

It passes memory video and other tests but FAILS EVERY TIME ON THE CPU Protcted Mode (80286 and above) test.

It just locks the AT and the <ESC> key is ignored and only a power reset will unlock it.

ANY IDEAS

 

[daver2]

I was on an Intel 286 training course with a load of IBM engineers.

When we got to the protected mode part of the course - in particular how you switch from real mode to protected mode, the IBM engineers went into a "holy huddle" and realised that the AT had been designed wrong, and would never support a protected mode operating system without a hardware modification.

I wonder if you have a very early AT without the modification?

Either that or the CPU could possibly be faulty.

Dave

 

[modem7]

When we got to the protected mode part of the course - in particular how you switch from real mode to protected mode, the IBM engineers went into a "holy huddle" and realised that the AT had been designed wrong, and would never support a protected mode operating system without a hardware modification.

I wonder if you have a very early AT without the modification?

That must have been when the IBM AT was in prototype stage. All of the documentation in the first public release shows support for protected mode operation, including use of the motherboard's keyboard controller (and other chips) in the overall process of returning to real mode from protected mode.

It passes memory video and other tests but FAILS EVERY TIME ON THE CPU Protected Mode (80286 and above) test.
It just locks the AT and the <ESC> key is ignored and only a power reset will unlock it.

I imagine that the test is like the equivalent test in some other diagnostics:
Step 1: Switch CPU to protected mode.
Step 2: Verify that CPU is in protected mode.
Step 3: Switch back to real mode.
Step 4: Continue testing.

Re steps 1 and 2:

The CPU. A reseat of the CPU would be a good first step. Easy (relatively speaking) to do.

Re step 3:

a) Puts a 'reason for returning to real mode' byte into a particular RAM address within the CMOS SETUP/RTC chip. See 'shutdown status byte' at [here].
b) Then resets the CPU by sending a particular command to the motherboard's keyboard controller. Diagram at [here].
c) How the POST responds depends on the byte used in a).

A few chips involved in that process.

Re the shutdown status byte in the CMOS SETUP/RTC chip, the MC146818 chip. If there was a problem with that, your 5170 would not be booting to disk, because the 'Verify shutdown byte in 146818 RTC chip' test in the POST would fail and the POST then halt. See [here].

 

[modem7]

Re the shutdown status byte in the CMOS SETUP/RTC chip, the MC146818 chip. If there was a problem with that, your 5170 would not be booting to disk, because the 'Verify shutdown byte in 146818 RTC chip' test in the POST would fail and the POST then halt. See [here].

At that page, see codes 19 (hex) to 20 (hex). You got to DOS. So, the 5170's POST (IBM) at some point, went into protected mode then returned to real mode. CheckIt must be testing some 'protected mode' functionality that the POST does not use. It really does suggest a CPU related problem.

 

[SteveG]

I have reseated the cpu but I get the same error.

I noticed a missing plastic insulator leg in the CPU socket (see photo):-

I have a HYPER 386SX upgrade cpu which I am going to try next.

 

[daver2]

Ah...

It is not the missing insulator that is the problem - but the associated two (2) pins either not making good contact between the IC and the pads - or the two pins shorting out.

Dave

 

[rodney]

I noticed a missing plastic insulator leg in the CPU socket (see photo):-

Hi SteveG,

That is unfortunate to be missing that piece of socket plastic.
The pins in question are the READY and VCC pins.
Do be careful that the READY pin doesn't make contact with VCC or anything else, which could surely damage your 82284 controller chip. The READY pin is essential because it also determines your I/O and memory access timing since the READY signal serves to terminate the 286 command cycle in the PC/AT. The command cycle is when the CPU is actually performing the data read or write action it set out to do in that CPU state sequence.
If the READY pin is not connected with the 286 CPU, or shorted to something, your CPU will not do anything anymore, which is important to know.

I read this thread of yours today and I have a few more things to add, besides all other things already mentioned.

I have built a 286 system similar to the 5170 and I have tested a few similar "chipset-less" mainboards from several manufacturers.

What I can tell you from my own experience is that the COM port support is very poor with various BIOS types I have tested so far in these types of systems.

The AT BIOS tests for the COM port being present, and saves the detection in the CMOS RAM, as mentioned. Based on this "present" or "not present" status that the BIOS detected and saved in the CMOS RAM previously, you may or may not have a working COM port generally in DOS. And this detection process is not a perfect thing as I have seen in my tests.

The 16 bit AT is substantially different from the XT in that the timing is much more delicate and sensitive.
The reason for this is that the AT contains a backward compatibility mechanism with 8 bit hardware, invented by IBM. Which is exactly the situation with your COM port because it only uses 8 data bits. In an XT we connect directly with these 8 bits, however the XT can also have trouble with COM ports, but I won't get into that now since that's not the issue. In general, I have experienced various issues with a COM port both in 8 and 16 bit systems.

Added to this fact is one other thing, your 5170 is one of the most early systems of its type which, even though it is in my opinion an amazing design and concept which deserves appreciation, since it's a first system of this type, it is also at the same time not a "perfect" machine yet. In my testing experience I have seen many situations where the CMOS RAM got corrupted, resulting in all sorts of strange behaviour. So if you see anything funny, it would be good to clear the CMOS information. What I am doing lately is to use a DOS CMOS backup program to store a known good CMOS content in a backup file, and if the CMOS RAM is acting up, I simply read back the known good copy. This solves a lot of issues that I have experienced, and enabled me to have less trouble during all of my test work.

When your mainboard left the IBM factory built into a system, it had been assembled in a known good configuration of all the components on the PCBs and it had been quality tested etc.
The problem for example may be that after leaving the factory, the mainboard may have been repaired and certain ICs may have been replaced. And if a repair was done for example by a person not working for IBM at the time, and a certain IC was replaced with one that does not exactly match the logic type and timing specs of the replaced IC, this can potentially introduce timing changes which may mess up the perfectly working mainboard timing as verified by IBM. So in such a situation, the mainboard may no longer be functioning exactly the same way as when it left the factory. If you see evidence of repairs on the bottom of the mainboard, I would look at the IC in question very carefully and try to find a photo of your mainboard version to see if you can find a mostly identical photo to your mainboard where you can see mostly the same ICs in various places, to know:
- brand
- logic type
- year/month of manufacturing
of the replaced IC.
If your mainboard is 100% factory that would be the best situation really.

All these things could matter in certain sensitive circuit areas if the IC is too far off compared to what IBM put in at the assembly line. I am not saying it's the case here, however you may benefit from keeping this point in mind at some time when doing a repair or test and seeing unexpected results for which you can't find an explanation since there appears nothing faulty anywhere.

Okay, back to the COM port problem. If the BIOS doesn't detect the COM port, it may still be perfectly functional (!). So don't get too much distracted by the fact that the port is not working, it may be the AT BIOS which is the actual problem causing this issue. Especially since you verified the serial port card to be working in another system. So the ICs on the card are all fine.

So what I advise you, if you have the possibility to try this, is to use the Quadtel BIOS which is suitable for the IBM 5170. The Quadtel BIOS is much improved compared to all other BIOS I have tested, in that it consistently keeps detecting the COM port correctly. So if you are able to change the BIOS, I can highly recommend, at least for testing purposes, the Quadtel BIOS from minuszerodegrees.net.

A way of testing this out, whether you have this BIOS detection issue, is by starting windows.
I am not sure, but I think at least from windows 3.0 onward, or from windows 3.1 onward, it contains its own mouse support and doesn't care whether the BIOS saw a COM port. The mouse pointer will still work in windows no matter what the BIOS is seeing or not seeing.

Also it may be possible to make mouse support "appear" on a COM port when running MSD diagnostics from DOS 6.22. I have seen the mouse working in MSD and not in DOS, for example.

So it depends on what you are able to test in your system.

Also I want to add one more thing, if one serial port card seems to be not working in your 5170, and works in another system, it may very well not matter which type of serial card you test out, they may possibly all not be working, no matter being a card with a separate UART IC, or a multi-I/O card containing a single chip which does multiple interfaces, and contains the serial port as well.

So if you can somehow verify that at least you don't have this BIOS related issue I described, I would do that first or you may be doing a lot of work to try to fix something which is structurally not working reliably.
So the best test would be the Quadtel BIOS. If using that you still are not able to get the COM port working, in that case it must be a different issue then.

I hope you can find some way to continue your work on the system, do be careful not to short the READY pin of the socket to anything else.

Another thing I want to share is when I was testing with MR BIOS, it also had trouble seeing the COM port at times. I solved this problem by powering on the system first without the COM port, then power off, and power back on with the COM port added again. These differences when power cycling may trigger a detection, at least in the case of MR BIOS.

One other thing may be the RESET input on the UART chip, if that RESETDRV line on the ISA slot is very noisy due to crosstalk in the PCB, it may prevent the COM port from working properly. This may be resolved by putting a 2.2nF capacitor between RESETDRV and GND, preferably at the most outer slot right next to the edge of the mainboard. What I also have done at one time is to disconnect the UART RESET pin from the RESETDRV and connect it directly with GND. That also solved the problems I experienced that time.

Kind regards,

Rodney

 

[modem7]

Based on this "present" or "not present" status that the BIOS detected and saved in the CMOS RAM previously ...

Saved in the BIOS data area (BDA), which is in low motherboard RAM.

A way of testing this out, whether you have this BIOS detection issue, is by starting windows ...

SERTEST can do this too. At start-up, SERTEST shows the serial ports that were saved by the POST in the BDA. Everything else done by SERTEST is done directly with the serial port hardware. So if we assume that a serial port at 3F8 exists, is functional, but the POST is not detecting it, then then the 'Run tests on a port not shown' option of SERTEST will reveal the serial port at 3F8.

 

[SteveG]

Thanks everybody for your input.

I wanted to keep this AT motherboard because in the day it was state of art upgrade to the standard IBM 7170 available from US manufacturer Western Digital with a 286-12 MHz clock speed CPU.

NB. It already uses Quadtel BIOS.

But now common sense has kicked in and I have purchased another working and tested motherboard.
I hope I can get a mouse working on this. TIME WILL TELL

 

[rodney]

SERTEST can do this too. At start-up, SERTEST shows the serial ports that were saved by the POST in the BDA. Everything else done by SERTEST is done directly with the serial port hardware. So if we assume that a serial port at 3F8 exists, is functional, but the POST is not detecting it, then then the 'Run tests on a port not shown' option of SERTEST will reveal the serial port at 3F8.

Thanks this program sounds useful, I will download and test this out in a "not detected but known to be present" status.

 

[rodney]

I wanted to keep this AT motherboard because in the day it was state of art upgrade to the standard IBM 7170 available from US manufacturer Western Digital with a 286-12 MHz clock speed CPU.

NB. It already uses Quadtel BIOS.

If it uses the same Quadtel BIOS as in my link, then it becomes much less likely that you are experiencing the issue I described.

Since you needed to power cycle the system several times to get it running, this may have been caused by the unstable READY and VCC contacts in the CPU socket.