Serial Communication, I need a ComDebug for the handshake lines

[legacy]

hi guys
is there any useful application (for linux, if possible) that shows the handshake lines ?
I mean something like this App, unfortunately I am not able to download.

also, I'd better use a HEX terminal, with the possibility to save as raw files



I have to debug an old (and super crappy) Serial Equipment 

[westfw]

Bray's Terminal (windows) is usually highly recommended.

Do you need real-time display of the handshake lines compared to data, or just "somewhat dynamic" displays of what is going on?  The former may not be possible without external hardware (twisted and different device driver paths.)
What speed?  How much would you spend?  I've also seen "digiview" recommended (starting at about $300), and I think several other logic analyzers have some async serial analysis support.

[enz]

There's also HTerm:
http://www.der-hammer.info/terminal/
The website is german only, but the program is in english.

I use it quite offen.

[legacy]

I could ask a friend to have a LA made by ZeroPower, I do not know if it accept RS232 level or not, in case … I will put a RS232-TTL adapter in the middle, MAX232, or similar

[legacy]

thank you guys

I have two similar troubles to be solved, the first is for my job, the second is for my hobby. I want to talk about the last one as I have already written here a few lines about.

I have the same DOS program running in two machines

• A: a genuine 486 PC Olivetti Laptop
• B: a RiscPC with x86Card

this DOS program uses the serial line to control an EVS board, it uses handshakes, the behavior is quite similar, but … B: seems to have something wrong so the DOS program hangs up.

I'd like to understand what is wrong:
- is it in the BIOS ? B: uses to "pass" a bios to the x86Card, so it may be it has a bug somewhere
- is it in the OS serial block ?
- is it hardware ?

who knows ?

from the DOS Application's point of view the PC Serial port is an device attached to the IO_space
IO_COM1_Base, x86.IO_space 0x03F8, PC UART(1)
IO_COM2_Base, x86.IO_space 0x02F8, PC UART(1)

Every DOS program is expecting to have to deal with a PC UART(1)'s chip (8250/16450/16550 chip, see the list below), while the RPC machine does have a pretty 82C710 chip.

From the assembly point of view everything does “OUTBX” does directly access the PORT_IO 0x03F8, so I wonder how the Guest-486-Card’s hw is able to remap everything coming to the PORT_IO’a address of the PC’com1 (0×03F8) to the 82C710 chip in the RPC machine.

DOS program, written with BIOS in mind
does a BIOS call, invoking an uart service routing , expecting to have to deal with a PC uart

DOS program, written without BIOS in mind
does a directly access to the PortIO 0×03F8, expecting to have to deal with 8250/16450/16550 chip

RiscOS
does an access to 82C710-chip’s output register (is this chip memory mapped ? Probably yes)

What is it in the middle ? In the middle there is an ASIC chip that adapts things, and this ASIC chip is called "Gemini"

Code: [Select]

DOS-APP ---> BIOS (or directly access) ---> PC UART(1) ---> Gemini ---> 82C710 ---> physical serial line ---> EVS board


Do you need real-time display of the handshake lines compared to data, or just "somewhat dynamic" displays of what is going on?  The former may not be possible without external hardware (twisted and different device driver paths.)

I know the DOS program does its connect phase using handshake, and then it uses the full Serial signals to get synchronized to the EVS. Sometimes B: has success, too often it fails, it means there is certainly a bug somewhere between the BIOS and the RiscOS layer.

In short, i do not know what I need, and I do not know if this is the right approach to solve the problem. It's a bit complex, what i know is I want to check if the problem is caused by a few missing lines in the PC's BIOS about the handshake. This, if the DOS application is using the BIOS to access the serial line. It could do directly access, and in this case … things go more complex because I have to check what the Gemini chip does about its translations

8250/16450/16550  <------> 82C710

What speed?

9600bps




(1) PC UART

8250 first UART in this series. It contains no scratch register. The 8250A was an improved version of the 8250 which operates faster on the bus side.
8250A faster than the 8250 on the bus side. Looks exactly the same to software than 16450.
8250B similar to that of the 8250 UART.
16450 used in AT’s (Improved bus speed over 8250’s). Operates comfortably at 38.4KBPS. Still quite common today.
16550 first generation of buffered UART. It has a 16 byte buffer, however it doesn’t work and is replaced with the 16550A.
16550A Is the most common UART use for high speed communications eg 14.4K & 28.8K Modems. They made sure the FIFO buffers worked on this UART.
16650 recent breed of UART. Contains a 32 byte FIFO, Programmable X-On / X-Off characters and supports power management.
16750 produced by Texas Instruments. Contains a 64 byte FIFO.

[legacy]

RiscPc serial parallel schematic

[westfw]

You can probably forget about the application using the BIOS to communicate with the serial port.  The PC BIOS Serial Port support was pretty useless (initialize, send char, receive char (no interrupts), port status.  That's all.)   (BASICA, OTOH, had remarkably good support for the serial ports.)

I wonder how the Guest-486-Card’s hw is able to remap everything

Apparently, it's not...  :-)

[legacy]

Apparently, it's not...  :-)

the Gemini chip is memory mapped on the ARM ram space, ARM does not have any IO space like x86 CPUs, but it's not a trouble, I wonder how different goes the 8250/16450/16550 family from the 82C710 chip.

Focusing only to the debug com, I have reversed the EVS board into a little schematic. I have discovered the circuit is simpler than what I have imagined , the debug processor routes its DTRout to {CTS, DSR} signals on the db9 connector. It does not use any other signals.

I got strange behavior from ComShow.exe ( I could attach if someone wants to try/needs it), it's a DOS program that aims to be a simple handshake monitor, I does not work at all in the RiscPC PCx86 box, but it also does not work under Windows XP too, while it works quite perfectly under MSDOS-v6.22 on a PC laptop.

Strange computer's mysteries 

So I am going to write a simple DOS program. In the afternoon I will try to attach a LA.

[legacy]

It may be that this topic in eevblog is overcomplicating matters, but it may be not.  Either the PC Card serial port looks -quite- like a normal port to the PC world there are cer, or it doesn't.  It should be interesting to know how -quite- like, so do  think there are things I need to do on the PC side. This is the reason of the topic here instead on the ROOL forum.

Within DOS, a good serial terminal is Procomm.exe, it works pretty good with NULL-modem equipment, I can't say a world about handshake.
Within RISC OS, a good serial terminal is "!Connector", it works pretty good with NULL-modem equipment, I can't say a world about handshake.

[westfw]

You're welcome to http://www.oocities.org/westfw/ibmftp.bas.txt
I can dig up heath.x and it's source code as well, though I don't think the assembler is available any more.
I was almost a competitor for CrossTalk v1...

[Monitor]

What was the problem downloading ComDebug? I can send you the link if you still want to download it.

[legacy]

ComShow.exe ?

under Windows XP is reading things that are not existing, I mean, It gets thousand bytes from the COM1 while there is nothing attached.
under !PC/Pro it has the same behavior, completely out of control
under MSDOS v6.22 it works fine

I have checked the IRQ4, and the address 0x03F8 of COM1, and they are correctly set, so … I do not understand what happens.
However, I am developing a piece of C software, in order to have the full control.


p.s.
It seems the EVS board is sending a "break", and it seems the Gemini chip does not like it.

[Karel]

Have you tried this one?

http://www.teuniz.net/serial-com-tester/

Works perfect for me.

[legacy]

thank you, the serial-com-tester App is marvelous