Contribute to aybe/dosbox-svn-daum development by creating an account on. Case 0x01: /* serial isolation */. NTS: If some of my late 1990's laptops are any indication, this resource list can. [undoc] (0x80| line status) in case of rx timeout. Windows 95, and Windows 98, is carried out NOT by talking directly to the. The FPP software likes to take direct control of the serial port of your PC at the hardware level - and this is something that Windows in almost all it's various guises will intercept and mess up. The answer: use a genuine DOS session.
On the Modem Control Register, Bit 1 is 'Force Request to Send', Does that mean if I do the following: outportb ( MCR, ( inportb ( MCR ) 0x02 ); // setting bit 1 'HIGH' It will activate CTS to the other computer? Because the documentation I'm reading says that bit 4 on the MSR is 'Clear to Send' So I was just testing and did the following: if ( inportb ( MSR ) & 0x10 ) // True if bit 4 is 'HIGH' But it never returns true. And MSR never seems to change on the other computer, no matter I set MCR to on this computer.
Am I missing something? Request to send (RTS) is connected to Clear to send (CTS). When one side raises RTS, the other side gets a CTS and can start sending data. One thing I have learned in serial communications is that you need to have a breakout box. You can get those at a Radio Shack or pretty much any electronics place that sells connectors.
They not only have lights that tell you when a signal is on, but they have jumpers so that you can turn on a signal so you can see its results in your code. I would set up a breakout box and set up a function key to toggle the RTS line. If you see it changing, then put the breakout box at the other end of the cable and see what that shows. There are a couple of potential problems: One is that the cable is a bad cable.
That deosn't happen very often, but can drive you crazy when it does. The other thing, is that the the NULL modem cable may not cross the RTS/CTS correctly. If you have a scope, you can test the pins on the chip or look at each rs232 line. Pt breakout boxes are easir to come by and much easier to use. Hi johnws, Does this verify that my cable is wired properly? It certainly should but it may not.
As you are probably aware, a defeated modem cable would achieve the same. But its a good indicator. Essentially, since almost all the lines are crossed over on a null-modem cable you will have to get your head around the following: Raising DTR at one end will (usually) raise DSR at the other and sometimes DCD. Raising RTS at one end will raise CTS at the other.
![Dosbox direct serial rx delayed Dosbox direct serial rx delayed](/uploads/1/2/5/4/125448262/146206556.png)
Data sent on TxD at one end will arrive at the other on RxD. Paul is correct. The wires you have used in your test are: RxD, TxD and GND. That does not speak for the other wires. A breakout box will illustrate all this rather clearly. Another tool it would be good to have is Simple Term Gold. It is so much better than HyperTerminal.
You can get a eval version at. It will show the state of each control signal as well displaying the data in any form you like (hex, dec oct, bin or chr). Just seeing the control signals at the other end makes it worth it. Also take a look at: That has a lot of good info about serial.
![Serial Serial](/uploads/1/2/5/4/125448262/805641442.png)
Ask if anything does't make sense. No, you should toss it away. You see there's waaay tooooo many levels of fooling going on: (1) You're running a program in a DOS window on Windows XP. (2) Your program does a 'OUT $279,$40' let's say this is the modem control register (3) The CPU chokes on the out instruction and traps to the kernel.
(4) The kernel sees you're running in virtual 8086 mode, so it hands the CPU off to the 'bad instruction' interrupt handler. (5) The BIIH sees you're in a DOS box, so MAYBE the OUT instruction needs to be emulated. (6) It sees if there's an OUT emulation handler registered for port $279. Yep, there is.
(6) The 279 emulator recognizes this is one of its ports, the modem status register, so it tries to do the right thing. (7) It looks and sees if COM1 is implemented as a Windows XP driver, and by golly it is. (8) It does the proper IOCTL function to call the driver to twiddle that register. (9) But it turns out the XP driver has been overriden by a USB filter driver. (10) The USB filter driver notices it's been asked to change a modem control line, so it calls the USB IOCTL driver. (11) The USB IOCTL driver sends the right packet to the right USB port to change the bit. (12) The chip might or might not change the right signal line, maybe at the right time, or maybe out of step with the data.
(13) The drivers all return, the kernel returns to your program, many thousands of instructions later. Of course, if you try twiddling some of the more complicated serial register bits, like the FIFO test or control bits, things are likely to get mangled at each and every step above. USB RS232 adapters sometimes work and sometimes don't. I went through 4 different brands to find one that did as advertised.
I experienced the same issues when looking for an RS422 adapter. On all USB ports, the control lines are emulated. You will note that in the following USB pinout, there are no control lines. Pin Name Description Cable Colour 1 Vcc +5V DC Red 2 D- Data - White 3 D+ Data + Green 4 Gnd Ground Black The control signals are created via a combination of jumpers and a built-in algororithm.
Unless you are prepared to work your way through all that to achieve results, I would put forth the effort to find a real rs232 port. Then going along with what grg99 said, try to find a MSDOS boot disk.
This will give you direct control of the hardware. Just make sure the you have a fat32 partition to put your executable on. MSDOS does not recognize NTFS. Or you could just write them to a floppy. That is fat16 and recognized by all MS OSs.