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 minddoes a BIOS call, invoking an uart service routing , expecting to have to deal with a PC uart
DOS program, written without BIOS in minddoes a directly access to the PortIO 0×03F8, expecting to have to deal with 8250/16450/16550 chip
RiscOSdoes 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"
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.