Serial Communication, I need a ComDebug for the handshake lines - Page 1
Forum section: electronics / general

author: legacy
author_rank: Super Contributor
timestamp: June 01, 2015, 08:47:41 pm
content: hi guysis there any useful application (for linux, if possible) that shows the handshake lines ?I mean something likethisApp, unfortunately I am not able to download.also, I'd better use a HEX terminal, with the possibility to save as raw filesI have to debug an old (and super crappy) Serial Equipment

author: westfw
author_rank: Super Contributor
timestamp: June 01, 2015, 11:18:27 pm
content: 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.

author: enz
author_rank: Regular Contributor
timestamp: June 02, 2015, 08:05:48 am
content: 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.

author: legacy
author_rank: Super Contributor
timestamp: June 02, 2015, 08:56:36 am
content: 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

author: legacy
author_rank: Super Contributor
timestamp: June 02, 2015, 09:01:09 am
content: thank you guysI 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 writtenherea few lines about.I have the same DOS program running in two machinesA: a genuine 486 PC Olivetti LaptopB: a RiscPC with x86Cardthis 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_spaceIO_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 minddoes a BIOS call, invoking an uart service routing , expecting to have to deal with a PC uartDOS program, written without BIOS in minddoes a directly access to the PortIO 0×03F8, expecting to have to deal with 8250/16450/16550 chipRiscOSdoes 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:DOS-APP ---> BIOS (or directly access) ---> PC UART(1) ---> Gemini ---> 82C710 ---> physical serial line ---> EVS boardQuote from: westfw on June 01, 2015, 11:18:27 pmI 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 translations8250/16450/16550 <------> 82C710Quote from: westfw on June 01, 2015, 11:18:27 pm9600bps(1) PC UART8250first 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.8250Afaster than the 8250 on the bus side. Looks exactly the same to software than 16450.8250Bsimilar to that of the 8250 UART.16450used in AT’s (Improved bus speed over 8250’s). Operates comfortably at 38.4KBPS. Still quite common today.16550first generation of buffered UART. It has a 16 byte buffer, however it doesn’t work and is replaced with the 16550A.16550AIs 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.16650recent breed of UART. Contains a 32 byte FIFO, Programmable X-On / X-Off characters and supports power management.16750produced by Texas Instruments. Contains a 64 byte FIFO.

author: legacy
author_rank: Super Contributor
timestamp: June 02, 2015, 09:09:47 am
content: RiscPc serial parallel schematic

author: westfw
author_rank: Super Contributor
timestamp: June 02, 2015, 09:26:35 am
content: 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.)QuoteApparently, it's not... :-)

author: legacy
author_rank: Super Contributor
timestamp: June 02, 2015, 10:40:19 am
content: Quote from: westfw on June 02, 2015, 09:26:35 amthe 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 fromComShow.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 mysteriesSo I am going to write a simple DOS program. In the afternoon I will try to attach a LA.

author: legacy
author_rank: Super Contributor
timestamp: June 02, 2015, 11:54:14 am
content: 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.

author: westfw
author_rank: Super Contributor
timestamp: June 02, 2015, 03:57:03 pm
content: You're welcome tohttp://www.oocities.org/westfw/ibmftp.bas.txtI 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...

author: Monitor
author_rank: Newbie
timestamp: June 03, 2015, 09:16:01 am
content: What was the problem downloading ComDebug? I can send you the link if you still want to download it.

author: legacy
author_rank: Super Contributor
timestamp: June 03, 2015, 09:40:54 am
content: 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 controlunder MSDOS v6.22 it works fineI 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.

author: Karel
author_rank: Super Contributor
timestamp: June 03, 2015, 10:55:08 am
content: Have you tried this one?http://www.teuniz.net/serial-com-tester/Works perfect for me.

author: legacy
author_rank: Super Contributor
timestamp: June 03, 2015, 11:12:39 am
content: thank you, the serial-com-tester App is marvelous