RS-232 Data Parity Confusion

[BigBill53]

Hey,
I have an old software package that runs on MS-DOS. Needless to say it is tricky getting DOS to work on modern machines. So I had the bright idea of making a virtual machine of DOS and running it on a modern computer.

This software talks to a number of machines via RS232 (actually it is RS485, but through a RS232/485 converter). I have been having a lot of trouble getting the VM to communicate properly like the old machine does.

I have finally identified the issue, but I am confused by it. The data being sent from both the DOS and VM are both the same, except for the parity bits. When I took a sample of the data with an oscilloscope here is what I found:

Old machine (DOS):

New machine (VM):

(ST = start bit, SP = stop bit, Dx = data bit, P = parity bit)

To me it looks like there are 8 data bits, 1 stop bit and 1 parity bit (of some type). However, I can't ascertain whether it is odd, even, mark or space on either the VM or DOS.

Any ideas?

 

[danw2]

> can't ascertain

Neither can I. By my count, data bits + Parity bit, neither DOS nor VM maintain a consistent parity.

Old DOS
7+0 Odd, 4+1 Odd, 3+1 Even, 5+1 Even, 8+0 Even

New VM
7+1 Even, 4+1 Odd, 3+0 Odd, 5+0 Odd, 8+0 Even

I'm stumped. Does you Old DOS actually function OK with that data stream?

 

[VEBill]

Check the port / driver settings on both the legacy DOS PC and the new DOS VM. Different drivers might have different default settings.

 

[danw2]

>virtual machine of DOS and running it on a modern computer.

What hardware port is your modern computer originated this data on? RS-232 ? USB ?

 

[badservo]

Maybe they are trying to use the parity bit as a 9th bit to flag "This byte is the target address, all others are data". See if there is a setting in the host OS or virtualization software to forward the parity bit without corrections.

 

[BigBill53]

@badservo: I was starting to think the same thing - that this isn't a parity bit at all but some other way that the system is using to communicate with the devices (such as an address word, which indeed the first byte of data is). I will check the settings and come back to you (I am using VMware).

The old DOS machine works just fine when communicating with the hardware, the issue is that the new VM when connected to the hardware will send data but the hardware seems to not understand what the data is and doesn't respond (there are some TX and RX LED's on the circuit board that show me this).

 

[danw2]

I hadn't thought of 9 bit serial in decades until your thread came up and I recalled some discussions at work about a National Instruments project years ago. A 9 bit serial protocol certainly is a better explanation than parity.

One of the Google hits I came on mentions various UARTs and cards for 9 bit framing support (quite dated, but might have leads), in case you need to get serious about reverse engineering the protocol.
Link

 

[IRstuff]

What kind of data is it? How do you know whether the parity bits aren't actually part of a larger block ECC such as a 64/8 ECC?

TTFN (ta ta for now)
I can do absolutely anything. I'm an expert!

https://www.youtube.com/watch?v=BKorP55Aqvg

faq731-376 forum1529 Entire Forum list

http://www.eng-tips.com/forumlist.cfm

 

[JG2828]

What is the name and version of the software and what is the machine it is talking to? Maybe one of us could track down the communication specs.