Decoding a Legacy serial bitstream.

[SparkyOne]

Agreed Bob.....I'm just not that far along yet.    Right now, I'm just trying to read and capture the data....so I can compare it against the programming manual.....and make sense of that "ser1.txt" file.   It's just 1 test of 9....but I'm using it as a base starting point because it continually loops data, and doesn't require a response back to the Apple ][ controller. 

Eventually, I should be able to do exactly what you're describing.

I did figure-out one issue in the meantime....   I had to drop-off the manual flow control buttons "DTR Write" and RTS Write", for now.   It was sending the test program into a locked state after the first execution.

[Henrik_Volkers]

If you have a good documentation of your DUT, isn't there noted how to communicate with it?

There is a clear structure in the data. Counter jumps from FF to 80 so looks like 7 bit

What are you looking for?

Again: What are you testing?

[arteitle · Accepted solution]

---

@Bob_Schor wrote:

I may be wrong, but I think you are confusing RS-232 communication protocols with how your device encodes data.  If you are transmitting data via a serial stream with 8 data bits and Even Parity, that really means that you have only 7 bits of data (as the eighth bit is effectively the XOR of the other 7 bits in order to force the Parity to be even).  The Start and Stop bits are stripped out by the UART and never make it past the VISA Read.

 The parity bit is also stripped out by the UART, and isn't part of the 8 data bits, so in this case each RS-232 frame will contain one 8-bit byte, and that's what a VISA Read will produce. The only way to explicitly read the parity bit would be to set Data Bits to 9 and Parity to None, which some hardware is capable of but VISA isn't.

[SparkyOne]

It does not appear that I need to explicitly read the Start, Stop, or Parity BITs.....so we can put that to bed.    🙂

The unit being tested is an old plasma display.   Essentially, a user-configurable/programmable display from the 80's.   It has a ton of built-in features, so the current Apple ][ test is designed to exercise all of them.   I'm just trying to make sure that I do not invalidate the test methods, when I create a LabVIEW replacement.

Right now, all I'm looking to do is properly frame & recreate the serial data in LabVIEW....but I need to be able to decode the commands that are being sent-out.   So for example, the other repeating test just keeps sending-out the HEX bytes 07 84 80 , and the display is checked to ensure that no characters, lines, or symbols are written to the display.   The Test which uses the "ser1.txt" file illuminates each individual pixel on the display Right-to-Left, then when the display is fully illuminated, it turns-off each pixel in the same manner.   That's how we test the displays for Dead or Stuck pixels.    All of the other tests are MUCH more complex, and require responses from the unit, back to the controller.

I have not even tackled the flow control lines yet.  CTS/RTS   DSR/DTR

[Henrik_Volkers]

Uups, skipped some posts...

can you post the communication part of the manual?

(or a link)

SInce DTR and DSR are used you should try hardware handshake (flow control -> DTR/DSR)

[Henrik_Volkers]

AND rescue the good old Apple ][   , it's an collectors item now 😄

[SparkyOne]

I'll see if I can find a link to the manual.....but that's really on me...not you guys.     Everything appears to be in this "triplet" format....so each individual bit can and does change what the whole "triplet" command means to the display.   ASCII strings have a special 01Dh terminator, but are still transmitted in that format, after a special command is sent.

What I'll eventually need help with recreating these commands, and tackling the flow control......but my initial question about the Start/Stop/ and Parity bits has been answered.  

We actually have 4 "working" Apples (all part of the same program), and one that's a parts donor.

[SparkyOne]

Thanks everyone!   I think I'm over the hump on this one, thanks for talking through the VISA masking structure with me.    .....nothing was making any sense, because I was either counting too many bits, or not enough.  

I successfully decoded both tests (image below)....and now I have ideas on how to approach porting at least these two tests.   May have some more questions once I start implementing the Flow Control structures...but I appear to be on the correct path for now.  🙂

[arteitle]

Note that the hex code doesn't match the bit pattern for the second byte of the Electrical Characteristics Test; the hex says 84, but the bit pattern would be 82.

[SparkyOne]

I never went back to correct that one command.....oops.     It's so simple, I'm just sending that HEX string.    The first code 02 84 80 is decoded correct.

The Buffer Test was a little more challenging, so I set-up Excel with the "Decoder Ring" for commands.   I can just type in the HEX code (line 23 for example), and the formulas on the spreadsheet do the rest.