4

I am currently prototyping an Intel 8088 system (Maximum Mode) on a breadboard. Later I want to move to custom designed PCB. To get some input and output, I wanted to use the 8251A chip. I have two new-old-stock chips from Intel and AMD. However, I have trouble using either of them.

Both generate garbage output on the TxD line as shown below. The top channel shows the TxD output, which is supposed to be at 3600 baud. However, as you can see I get framing errors or 0x80 as an output. The channel below shows the TxClock, which runs at at 57.6 kHz with some slight deviations, which I think are well within the error tolerance (e.g., 57.55 or 57.65 kHz, generated from a 4-pin crystal oscillator IC). The channel afterwards shows the TxRDY pin and at the very bottom the TxEMPTY pin.

Logic Analyzer view of the UART

This is the code used to talk to the UART. First I send the worst-case initialization sequence (e.g., 3 times 0 followed by a reset command). Afterwards I configure it to use 8N1 communication with a 16x multiplier (57.6/16 = 3600 baud). The C/D pin is directly connected to address line 0. I verified the memory mapping by probing the chip enable signals. Also writes and reads reach the UART just fine. I verified this by probing the data bus and checking the transferred data.

xor ax, ax
out 0x1,al
nop
out 0x1,al
nop
out 0x1,al
nop
mov al, 0x40
out 0x1,al
nop
mov al, 0x4E ; 8 data, 1 stop, x16
out 0x1, al
nop
mov al, 0x37 ; RTS, DTR, Enable RX,TX
out 0x1, al
nop
xor bx, bx
mov bl, 65 ; output letters A-Z
test1:    
in al, 0x1
test al, 0x1
jz test1 ; check if TxRDY
mov al, bl
out 0x0, al
add bl, 1
cmp bl, 91 ; simple inefficient modulo operation stay within 65-91 range
jne test1
mov bl, 65
jmp test1

The code is not the most efficient one. It, for example, includes NOPs because I thought maybe it is a timing issue. The UART itself is connected to the CLK of the 8088 (2.6 MHz), but I also tried to connect it to the PCLK (1.33 MHz) as the CLK input of the UART doesn't seem to be used for input synchronization as I understand the datasheet. The CTS line is tied low. The RxD line is tied high. The UART is connected to the global reset signal. I verified the bus connection (e.g., no data bits are mixed up). I furthermore, measured the WRITE pulse length and it is in spec. As a last ditch attempt, I tried to analyze the output signal with lower baudrates, but they do not match the data I expect.

As the UART actually outputs data, and the write and read signals indicate that the CPU is actually waiting for the TxRDY bit (test1 loop in the code), I simply do not understand what else might be going on.

Does somebody maybe have a hint or recognizes what may be going on?

5
  • 2
    Would you mind to add the circuit drawings? Likewise annotation about the measurements shown (timing, relation, Names) - it seems hard to believe that TxD runs faster than TxClock.
    – Raffzahn
    Commented Jan 12 at 23:56
  • 4
    What are the time periods in the logic analyzer for one TXD bit or from start bit to start bit? I.e. what is the actual bit rate instead of 3600? How many clocks per bit there is then, if it is not 16? Which crystal oscillator frequency you are using? Your analyzer expects a different baud rate and I believe there are perfectly valid frames transmitted.
    – Justme
    Commented Jan 13 at 8:03
  • 1
    @Raffzahn TxClock is the gray band. It is running that fast that it doesn't get resolved at all. TxD is not faster than that. Commented Jan 13 at 10:27
  • I don't see any problems in the code, it should initialize to 16x async mode, yet the baud rate is 4x too slow or 900 bps so the chip is in 64x mode or something else in the hardware is wrong.
    – Justme
    Commented Jan 13 at 11:19
  • Hi @Justme I just resolved the issue after checking the 900 bps data. There was indeed a nasty wiring error.
    – x95
    Commented Jan 13 at 12:43

1 Answer 1

2

Sorry for wasting your time. As Justme said, it seems it was running in 64x mode, and I got some data without frame errors with 900 baud but it was still not the ASCII letters I was sending. So while creating the schematic for Raffzahn I doubled checked all data sheets of my design and found that the data lines I am connecting to the UART are not in the order I assumed.

In particular, I connected the I/O lines of my AT28C64B ROM (which are also connected to my SRAM, which in term is connected to the CPU bus) to the UART and I/O0-3 were reversed from my notation. This went unnoticed as the RAM I am using has the same pinout as the ROM, so as long as I connected the same pins of my RAM and ROM module together I never had to look up the actual data pin order (except of course when I hooked them up to the CPU, which was some time ago).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .