Serial port access on XT vs AT/Pentium

[hard_fault]

I seem to be stuck on trying to open a serial port on AT or higher PC's..

In the test software Checkit 3 for DOS, there is a serial test that outputs some ASCII text to the COM port. Is there any reason why this serial port test in Checkit 3 would seem to work fine 2 of the XT class PCs I have, but none of the AT class PCs? The Checkit 3 recognizes the serial ports, but no bytes come out of the port during the test on any the AT machines. I'm wondering if it is because they are AT+ class, Checkit's serial port test outputs no bytes on the wire.

This comes up as I'm trying to get a serial port api for DOS up and running, and can't seem to open a serial port on the AT class machines, but no issue on the XT class ones.

// Tested OK
Tandy 1000 SL (XT) - Checkit serial port test OK
Tandy 1000 TL (XT) - Checkit serial port test OK
// Tested No Bytes on Wire
Tandy 4020SX (AT) - Checkit serial port test no bytes out
Tandy 2100 (AT) - Checkit serial port test no bytes out
Pentium Pro 180 on Intel 440FX board (AT) - Checkit serial port test no bytes out
Also not working on my 486DX4-100, but not sure what the motherboard is without opening it..

Thanks.

 

[modem7]

Checkit 3 recognizes the serial ports, ...

I expect that, per [here], the motherboard's POST is what is detecting the ports and recording them in the BIOS data area (BDA), and CheckIt is simply showing what got recorded in the BDA.

... but no bytes come out of the port during the test on any the AT machines.

Background: See [here] for internal loopback and external loopback.

When you get CheckIt 3 to do a test on a serial port, it asks, "Is an external loopback connector attached ...".
If the answer is in the affirmative, CheckIt 3 will do external loopback testing.
Are you saying that you are not seeing data on the data out pin during an external loopback test ?

 

[hard_fault]

Thanks for your reply, modem7.

Test Method
The test method I am using to determine which PC setup work and which ones do not, is use of a null modem adapter between the target PC and a modern PC running either Tera Term or Realterm.
Forgot to mention before that I am booting up each PC with the same bare-bones MSDOS 6.22 boot disk with no drivers loaded, to do the Checkit 3 serial port test.

I would connect everything then run the Checkit 3 serial port test, choosing "No" for the loopback option.
Then Checkit 3 transmits a few "abc123" test strings at various baud rates.

Test Results
From the XT PCs, the Checkit 3's serial port test strings are visible on the receiving terminal running Teraterm or Realterm, OK.
From all 4 of the AT+ PCs, although the serial ports are recognized, nothing is output on any COM port tested.. test failure.
However, the AT serial ports do seem to actually work, with the right software anyway.. CTMOUSE and serial mice work just fine on all the ATs, but the Checkit 3 serial port test does not.
---

What led me here..
We can get as technical as we like.. I'm supposed to have lots of embedded experience and this should be a piece of cake for me.. yet I am defeated here. Well I can't argue with my post history here of not being very smart.. .

Reason I have ended up here was trying, unsuccessfully, to open a serial port in C, on those AT machines.. whereas the code works OK on the XT machines. That's what led me to the Checkit 3 serial port test, and the realization that hey this too doesn't work on the ATs..
I know some chips have "unlock sequences" to access things like chip DMA registers, so I'm wondering if there is the same kind of thing going on with 80386 or higher CPUs regarding unlocking I/O port access. Probably not, but that's where my mind is at now.

 

[modem7]

...
I would connect everything then run the Checkit 3 serial port test, choosing "No" for the loopback option.
Then Checkit 3 transmits a few "abc123" test strings at various baud rates.

So CheckIt 3 will be setting the UART into loopback mode, per the 'for illustration purposes' diagram at [here].

If the particular model of UART is doing exactly what is shown in the diagram, then bytes that CheckIt gets the UART to transmit are not going to make it to the TxD pin on the connector.
But maybe some models of UART do the internal loopback whilst still keeping the output pins connected.



That kind of difference is not something that I have ever investigated (had no need). Is is a realistic possibility. I don't know.

If I am going to test a serial port (UART + UART supporting circuitry + level converters) on one of my vintage computers, then I will be hooking up a suitable loopback plug to the serial port connector, then doing external loopback testing using DOS software that does external loopback tests. I will most likely use the software that I wrote, which is SERTEST. But I would not use SERTEST (or any other form of hardware testing software) in a DOS box within Windows.

And I would keep in mind that SERTEST was not tested on 'fast' machines ('fast' being relative). I think a 386 was the fastest I tried it on. As the years passed, I remember at one point having to adjust the code to cater for some faster computers. And that raises the question of suitability of CheckIt 3 on certain 'fast' machines. I seem to remember at some point, in SERTEST, catering for a different UART model by flushing a buffer.

 

[modem7]

This comes up as I'm trying to get a serial port api for DOS up and running, and can't seem to open a serial port on the AT class machines, but no issue on the XT class ones.

SERTEST communicates directly with the UART via I/O ports. SERTEST was written in Turbo Pascal. I will PM to you the source code. That may help you.

 

[hard_fault]

Thanks again for the reply. Looking forward to checking out the SERTEST source.

I believe you're right about the suitability of Checkit 3 against fast machines or various models of UART..

Apparently there are 2 types of UART one may find in these old computers.. the older 8250A and newer 16550A that has a FIFO.
Both of my XT Tandy 1000's have a 8250A-like serial port contained in their PSSJ ASICs according to the docs. So I installed a 16C550 based UART in the Tandy 1000 SL as COM2. What I've discovered is that Checkit 3 does not work with a 16550 based UART (as on Sergey's FDC/Serial card). The port works with CTMOUSE okay. I was inspecting solder joints thinking I had a bad card..

It would appear that both Checkit 3 and the DOS serial library I'm trying to use can't run the 16550 UART properly. I think this is probably the solution to this mystery.

I haven't seen your SERTEST source yet, but I find the detection method that had to be used in the past from examples found online is.. silly.. As seems to be the norm in those days.

 

[hard_fault]

Ahem.. in addition to the 8250A vs 16550A thing I encountered using Checkit 3.. I had mentioned I was trying to use some serial port code found online. I traced some weirdness happening to the COM port value being passed down a stack of nested init functions in the driver code I'm using (DOS-Serial-Library on Github).. This is a whole 'nother kind of problem I'll have to hit the compiler manuals up for. I don't want to drag this discussion into this thread, but I do want to add this to the list of problems contributing to my initial post.

 

[Chuck(G)]

Don't know about the self-test in the UART chip (again no need for it), but I've run my own serial port software under DOS clear up to a P4 and had no problems, no matter if the UART was a discrete chip or submerged in a multifunction device.

 

[modem7]

Apparently there are 2 types of UART one may find in these old computers.. the older 8250A and newer 16550A that has a FIFO.

You left out the 16450, which in the IBM PC family, was introduced with the IBM AT.

I see a decent comparison/description in section 1.6.1 of [here]. And section 1.7 is an interesting read.

What I've discovered is that Checkit 3 does not work with a 16550 based UART (as on Sergey's FDC/Serial card). The port works with CTMOUSE okay. I was inspecting solder joints thinking I had a bad card..

It would appear that both Checkit 3 and the DOS serial library I'm trying to use can't run the 16550 UART properly. I think this is probably the solution to this mystery.

I will have a 16550 based serial card in my card collection. I will see if I can confirm the incompatibility with CheckIt 3. And see what SERTEST makes of it.

 

[Eudimorphodon]

I will have a 16550 based serial card in my card collection. I will see if I can confirm the incompatibility with CheckIt 3. And see what SERTEST makes of it.

Huh. So… in my homemade Tandy 1000EX/HX Plus card expansions I’m using a chip called the 16552, which is two 16550s in one package, and my recollection is it passes the Checkit3 internal loopback check with no problems… and, maybe this is relevant, but I used to have a serial printer hooked up to that port, and while it’s possible I just never happened to have it turned on when running the loopback test my expectation would be it would have gone ape if the loopback test bytes were also being sent out the external pins.

In short this may just be a difference in behavior between the 8250 and the newer UARTs when loopback is enabled.

 

[modem7]

It would appear that both Checkit 3 and the DOS serial library I'm trying to use can't run the 16550 UART properly. I think this is probably the solution to this mystery.

I will have a 16550 based serial card in my card collection. I will see if I can confirm the incompatibility with CheckIt 3. And see what SERTEST makes of it.

I found the card, which I picture at [here]. Set as: 3F8, IRQ4.

I added it (as the only serial port) to one of my IBM 5170 motherboards (an 8 MHz one).
Via [this] adapter, I hooked up an external loopback plug to the connector, a loopback plug that is compatible with both CheckIt 3 and SERTEST.
On the IBM 5170, I booted to DOS 3.3

All tests in SERTEST passed, and SERTEST reported that IRQ4 responded when SERTEST executed code that got the UART to generate an IRQ.

I ran the serial port test in CheckIt 3, answering in the affirmative when asked about an external loopback plug. That serial port test passed.

Rhetorical: So, what is going on in your configuration ?

I haven't seen your SERTEST source yet, but I find the detection method that had to be used in the past from examples found online is.. silly.. As seems to be the norm in those days.

In the case of the IBM PC family:
If I add a non-serial card whose I/O address range includes 3FA, and a read to that address results in certain bits appearing as zero, then the POST is going to believe that a serial port exists at base I/O of 3F8.
IBM would say something along the lines of, "That is an invalid configuration. The I/O range of 3F8 to 3FF is reserved only for the use of a serial port."

 

[Eudimorphodon]

Rhetorical: So, what is going on in your configuration ?

My interpretation of his post is he's running the checkit test *without* telling it there's and external loop back, ie, instructing the test to run with the UART's internal loop back enabled, but expecting to be able to see the test running on another host connected via a null modem cable.

And if that's the case, we'll, maybe it's an expected difference in behavior between the older and newer UARTs... or it could be a quirk specific to the ASICs in the Tandy 1000 TL/SL.

 

[modem7]

... but I've run my own serial port software under DOS clear up to a P4 and had no problems, no matter if the UART was a discrete chip or submerged in a multifunction device.

Out of curiosity about SERTEST, I brought out the most convenient-to-access Pentium motherboard that I have (a GA-586VX). The Pentium runs at 166 MHz. I booted to IBM DOS 3.3, and found that SERTEST checks out the motherboard's serial ports just fine.

 

[hard_fault]

My interpretation of his post is he's running the checkit test *without* telling it there's and external loop back, ie, instructing the test to run with the UART's internal loop back enabled, but expecting to be able to see the test running on another host connected via a null modem cable.

And if that's the case, we'll, maybe it's an expected difference in behavior between the older and newer UARTs... or it could be a quirk specific to the ASICs in the Tandy 1000 TL/SL.

Your interpretation of my jumbled, rambling, mess of glyphs, is indeed correct. This is just how I'm used to testing serial ports. I'll do it either this way, or buck those RX/TX down to 5V and use the logic analyzer. It probably sounds like I'm doing things the "hard way," but I usually have all this stuff already set up/ready to go, from my other embedded projects. I'd have to buy myself a loopback tester or fashion one out of two breakout connectors.

Here are the facts I know so far:
- Tandy 1000 SL/TL technical reference manual both mention a 8250A-like interface being present as part of their PSSJ chips.
- Using Tandy 1000 SL/TL on-board serial port, the Checkit 3 serial test puts bytes on the wire just fine.
- I then installed the Sergey FDC/Serial card as COM2 in the Tandy 1000 SL (16550-based UART). Checkit 3 will NOT put bytes on the wire, using this card.
- Confirmed that the Sergey FDC/Serial card's serial port does actually work in the Tandy 1000 SL/TL, because CTMOUSE detects mouse on COM2 and works OK. CTMOUSE works, whereas Checkit 3 serial port test does not.

In my original post, my thinking at the time was that this was an XT vs AT problem, when it actually seems to be an 8250 vs 16550 problem. I had tried to use Checkit 3 as a definitive test to solve a programming related problem, but as it turns out, I did not yet understand nor expect to run into problems related to 8250 vs 16550. I didn't even know that this was a "thing" yet.

I did finally manage to get that DOS-Serial-Library on Github to work on the Tandy 2100 (486SX/25), yesterday. That driver makes use of the 16550 FIFO, so if I want to make use of the 8250-based Tandy 1000's, I think I'll have to roll up a completely different driver for it.

 

[syzygy]

You may want to check out this 1989 Ap note...if you have not already come across it.

The seven versions currently produced are designated
INS8250, INS8250-B, INS8250A, NS16450, INS82C50A,
NS16C450, and NS16550AF. These devices are grouped
below by process type.

Of course subsequent [to the time of the App note] versions probably introduced further complications.

 

[Chuck(G)]

Wouldn't the standard for AT (5170) be 16450 (not CMOS)? At least that's what I recall. Somewhat buggy, but still worked with regular comm software.

 

[Eudimorphodon]

Your interpretation of my jumbled, rambling, mess of glyphs, is indeed correct. This is just how I'm used to testing serial ports.

It looks like you might need to think of a different way because:

You may want to check out this 1989 Ap note...if you have not already come across it.

This app note nails it, explaining that one of the differences between the 8250 and the later UARTs is the later ones disconnect the physical pins when they’re in LOOP mode, which is what Checkit’s serial test uses unless you tell it you are using the external loopback plug Modem7 describes.

To be clear about the internal loop mode, it’s basically doing the same thing as the external plug but internally, IE, it acts like a null modem cable connected to itself. If the UART passes the test in internal loop mode but doesn’t send characters in real life then the problem is probably the EIA drivers, not the UART, since that’s the thing that’s going to take the hit from a short or something. (I’ve seen one of those chips with the magic smoke brutally liberated, it happens.) If you want to know if the card works full path why not either just:

A: use one of the external loopback plugs, or:
B: if you have the null modem cable already, just use a COMM program to type at yourself between the machines?

Either of those should work to give you an accurate answer.

As for why a software library might work on the newer UARTs but not the Tandy’s, remember that it’s always a possibility this isn’t even a 8250 vs. 16x50 thing, there’s always a chance it could be a uniquely Tandy quirk. The 1000 family *always* had its peculiarities, and when you’re comparing an embedded copy of a chip to the original it’s always possible they didn’t completely duplicate every feature.

 

[Chuck(G)]

Those EIA drivers/receivers were frequent casualties in environments where static build-up on people (draw a spark from a co-worker) was an issue. I kept a tray of 1488 and 1489s for just such an occasion. Either the design improved with time, or they started spraying the carpeting with anti-static stuff, I never knew--but the ESD blowouts gradually ceased to be a problem. Never could figure out why it wasn't a problem with printer interfaces.

That's one of the reasons that the 8250 internal loopback was useless in the real world.

 

[Svenska]

Confirmed that the Sergey FDC/Serial card's serial port does actually work in the Tandy 1000 SL/TL, because CTMOUSE detects mouse on COM2 and works OK. CTMOUSE works, whereas Checkit 3 serial port test does not.

Note that CTMOUSE sometimes works when the serial port is incorrectly wired to the connector. There are two pinout variants between the 10-pin header on the mainboard and the 9-pin / 25-pin SUB-D connector on the case. I had a machine recently where the wrong adapter was used - and while CTMOUSE worked great, nothing else worked.

Check your wiring. And check the line driver inputs while at it.
Also, does the internal loopback test succeed?