Disappearing Key Assignments

[twoweims]

I am seeing strange behavior on my 41CL and the PowerCL (Angel Martin) PWRX Module.

After executing the ROMLST function, all of my Shifted Key Assignments disappear and I get a bunch of new assignments where "ABS" has been assigned to various shifted keys.

It looks like maybe ROMLST is using the "e" Register for something and not restoring it when finished? This could be operator error since I am a novice on the 41CL and I might have configured something improperly.

[attachment=7969]

Thanks in advance for any assistance.

[Ángel Martin]

Your diagnostic is correct: such sympthom is indeed a sign for register "e" overwrite.
I suspect the issue is a version mismatch between the PWRX and 4LIB ROMS. Pls. make sure you have the latest installed.

ÁM

[twoweims]

Angel, Thank you for responding!

I got my 41CL board back in November and have not updated any ROM images since.
I can't get the serial port to work...

I am using the ROM Images that came with my board.
How do I check for the Version numbers?

Thanks!

[Ángel Martin]

I can't help with the serial port, but the latest ROM versions can be downloaded from Monte's web site at this URL

click on the item on the upper right:
"The current set of .rom files for the 41CL is: rom_files_191203.zip"

[twoweims]

Is there a way that I can check to see which versions that i currently have installed?

[Sylvain Cote]

(12-30-2019 05:29 PM)twoweims Wrote:  I can't get the serial port to work...

(12-30-2019 05:37 PM)Ángel Martin Wrote:  I can't help with the serial port, ...

I can surely try, can you describe your problem.
Sylvain

[twoweims]

I am pretty sure that I destroyed the cable while re-assembling the calculator. It moved and I pinched it pretty bad between the case halves. I also need to verify the pinouts on the serial cable that I have.

I am using your clupdate software on macOS 10.15.2.
The software seems to be installed correctly but I just get timeouts when trying to connect to the calculator.

Could be damaged cable as noted above, bad serial cable, incompatible USB-Serial Converter, etc.
If I had access to a windows computer with a real serial port (if such a thing even exists anymore) I could eliminate a couple of variables.

I am afraid to disassemble the calculator again because the posts were marginal to begin with and I may have some extensive work to do to get it running again.

[Sylvain Cote]

Here is a small test program written in Python that will test your serial ports on the computer side.

Software needed:

• Python v3.7.5
• pyserial v3.4
• clupdate v1.1.0
• cl-protocol-test program
  

Hardware needed:

• USB-to-DB9M Serial Converter (main)
• USB-to-DB9M Serial Converter (test)
• DB9F-to-DB9F Null Modem Cable (test)
  

My hardware setup (see picture)

• MacBook Pro 15" (May 2019) running macOS Catalina (10.15.2)
• USB-to-DB9M Serial Converter (main) [/dev/tty.usbserial-1412430] (Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC)
• USB-to-DB9M Serial Converter (test) [/dev/tty.usbserial-FTGTM9TN] (Prolific Technology, Inc. PL2303 Serial Port)
• DB9F-to-DB9M RS-232 Null Modem Dongle
• DB9F-to-DB9F Gender Changer Dongle
• DB9F-to-DB9M RS-232 LED Tester
  

Terminal #1 - clupdate program (need to be started first)

Code:

java -jar clupdate-1.1.0.jar --update rom_files_191203.zip /dev/tty.usbserial-1412430 4800

Terminal #1 - program output

Code:

14:29:20 --update   [fileName: rom_files_191203.zip] [portName: /dev/tty.usbserial-1412430] [baudRate: 4800]
14:29:20 File       rom_files_191203.zip loading ... done
14:29:22 Serial     /dev/tty.usbserial-1412430 opened at 4800 baud.
14:29:22 Waiting    for 41CL commands ...
14:29:56 Received   OPEN_CHANNEL_REQUEST(0x41)
14:29:56 Sent       OPEN_CHANNEL_RESPONSE(0x42)
14:30:01 Received   CLOSE_CHANNEL_REQUEST(0x57)
14:30:01 Sent       CLOSE_CHANNEL_RESPONSE(0x58)
14:30:05 Serial     /dev/tty.usbserial-1412430 closed.

Terminal #2 - 41CL protocol test program

Code:

python3 cl-protocol-test.py

Terminal #2 - program output

Code:

opening serial port
serial port opened:  /dev/tty.usbserial-FTGTM9TN
sending communication channel open request
waiting for reply (timeout set to 5 seconds)
received communication channel open reply
sleeping for 5 seconds
sending communication channel close request
waiting for reply (timeout set to 5 seconds)
received communication channel close reply
serial port closed

Python test program (cl-protocol-test.py)

Code:

#!/usr/bin/env python3
import time
import serial

print("opening serial port")
serial_port = '/dev/tty.usbserial-FTGTM9TN' # change this entry to your device name
ser = serial.Serial(serial_port, 4800, timeout=5)
if ser.is_open == True:
    print("serial port opened: ",ser.name)
    print("sending communication channel open request")
    ser.write(b'A')
    print("waiting for reply (timeout set to 5 seconds)")
    si = ser.read(1)
    if si == b'B':
        print("received communication channel open reply")
        print("sleeping for 5 seconds")
        time.sleep(5)
        print("sending communication channel close request")
        ser.write(b'W')
        print("waiting for reply (timeout set to 5 seconds)")
        si = ser.read(1)
        if si == b'X':
            print("received communication channel close reply")
        else:
            print("received unexpected reply")
    else:
        print("received unexpected reply")
    ser.close()
    print("serial port closed")
else:
    print("failed to open serial port")

Sylvain

[twoweims]

Thank you for this information. I have all of the hardware bits here at work with the exception of the LED tester. I have one ordered now. I'll give it a shot over the next weekend.

[Sylvain Cote]

(12-30-2019 08:32 PM)twoweims Wrote:  Thank you for this information. I have all of the hardware bits here at work with the exception of the LED tester. I have one ordered now. I'll give it a shot over the next weekend.

LED tester is nice but not needed for the test.
Let me know your test results.
Sylvain

[twoweims]

Success... so far.

Here at work I have verified functioning clupdate and two good usb-serial cables.
My 41CL Serial Cable is at home. I will bring the cable in tomorrow and attempt to update my 41CL.

Thanks again for your help.

[attachment=7970]

[twoweims]

Well, I think my initial fear has been verified.
I double checked the pinouts on my CableClub BC20213-6 Serial Cable. It is the correct cable.

clupdate starts and waits for 41CL Commands but CMOPEN on the CL results in COMM and then TIMEOUT.

I am in Turbo 50 mode.
I have executed SERINI and set the baud rate to 4800.

I will contact Monte about getting a new cable...

[cdmackay]

(12-30-2019 07:56 PM)Sylvain Cote Wrote:  [*]DB9F-to-DB9M RS-232 LED Tester

please forgive me going off-topic a little, but can you explain what the two sets of 8 LEDs denote, on the tester?

Is the left set of 8 looking in one direction, the right set in the other?

[ijabbott]

(01-02-2020 03:55 PM)cdmackay Wrote:  

(12-30-2019 07:56 PM)Sylvain Cote Wrote:  [*]DB9F-to-DB9M RS-232 LED Tester

please forgive me going off-topic a little, but can you explain what the two sets of 8 LEDs denote, on the tester?

Is the left set of 8 looking in one direction, the right set in the other?

Each pair of LEDs should indicate the state of the corresponding signal with respect to signal ground. One LED should light when the signal is positive (logic 0) and the other should light when the signal is negative (logic 1). Some testers replace the pair of LEDs with a 2-pin, bi-colour LED. The pair of LEDs is connected in parallel with opposite polarity, so at most one of them should light up.

[Sylvain Cote]

(01-02-2020 03:55 PM)cdmackay Wrote:  please forgive me going off-topic a little, but can you explain what the two sets of 8 LEDs denote, on the tester?
Is the left set of 8 looking in one direction, the right set in the other?

Yeah, I asked myself the same question when I received the tester, I am used to only have one set of LEDs.

After some experiments, I discovered that the lights were used as follow:

Code:

LEDS   Description   LEDS
0  1  1:DCD | 6:DSR  0  1
0  1  2:RXD | 7:RTS  0  1
0  1  3:TXD | 8:CTS  0  1
0  1  4:DTR | 9:RI   0  1

In my test, when both cables are plugged but no software is running the tester show this:

Code:

0  1   Description   0  1
X  -  1:DCD | 6:DSR  X  -
X  -  2:RXD | 7:RTS  X  - 
X  -  3:TXD | 8:CTS  X  -
X  -  4:DTR | 9:RI   -  -

note: X means LED is lighted on and - means LED is not lighted

When I start clupdate, then the tester show this:

Code:

0  1   Description   0  1
X  -  1:DCD | 6:DSR  X  -
X  -  2:RXD | 7:RTS  -  X
X  -  3:TXD | 8:CTS  X  -
-  X  4:DTR | 9:RI   -  -

Then I start the python test program, after the port is open I see:

Code:

0  1   Description   0  1
-  X  1:DCD | 6:DSR  -  X
X  -  2:RXD | 7:RTS  -  X
X  -  3:TXD | 8:CTS  -  X
-  X  4:DTR | 9:RI   -  -

Then the LEDs on RXD & TXD are moving back and forth from 0 to 1 when there is transmission going on.

Hope it clarify things a bit.

Sylvain

PS: Ian beat me to it

[cdmackay]

thanks Ian, Sylvain!

I have one too, but only used it once, and couldn't make sense of it, partly I think because I used it on something that wasn't working properly, so couldn't calibrate my head to it

So neither lights means 0V, i.e. not connected/not in use?

My other confusion was whether the left bank of 8 lights was 4 pairs of [0,1] for signals 1–4, or the 0 indicators for all 8 signals. Sounds like it's the former.

I'll get mine out and try it again. Thanks!

[Sylvain Cote]

(01-02-2020 05:58 PM)cdmackay Wrote:  So neither lights means 0V, i.e. not connected/not in use?

Not connected or not driven.

RS-232C signal levels are:

Code:

Logical 1 = −15V to  −3V
Invalid   =  −3V to  +3V
Logical 0 =  +3V to +15V

(01-02-2020 05:58 PM)cdmackay Wrote:  My other confusion was whether the left bank of 8 lights was 4 pairs of [0,1] for signals 1–4, or the 0 indicators for all 8 signals. Sounds like it's the former.

Yep! that's it!

[ijabbott]

(01-02-2020 04:56 PM)Sylvain Cote Wrote:  

(01-02-2020 03:55 PM)cdmackay Wrote:  please forgive me going off-topic a little, but can you explain what the two sets of 8 LEDs denote, on the tester?
Is the left set of 8 looking in one direction, the right set in the other?

Yeah, I asked myself the same question when I received the tester, I am used to only have one set of LEDs.

After some experiments, I discovered that the lights were used as follow:

Code:

LEDS   Description   LEDS
0  1  1:DCD | 6:DSR  0  1
0  1  2:RXD | 7:RTS  0  1
0  1  3:TXD | 8:CTS  0  1
0  1  4:DTR | 9:RI   0  1

In my test, when both cables are plugged but no software is running the tester show this:

Code:

0  1   Description   0  1
X  -  1:DCD | 6:DSR  X  -
X  -  2:RXD | 7:RTS  X  - 
X  -  3:TXD | 8:CTS  X  -
X  -  4:DTR | 9:RI   -  -

note: X means LED is lighted on and - means LED is not lighted

When I start clupdate, then the tester show this:

Code:

0  1   Description   0  1
X  -  1:DCD | 6:DSR  X  -
X  -  2:RXD | 7:RTS  -  X
X  -  3:TXD | 8:CTS  X  -
-  X  4:DTR | 9:RI   -  -

Then I start the python test program, after the port is open I see:

Code:

0  1   Description   0  1
-  X  1:DCD | 6:DSR  -  X
X  -  2:RXD | 7:RTS  -  X
X  -  3:TXD | 8:CTS  -  X
-  X  4:DTR | 9:RI   -  -

Then the LEDs on RXD & TXD are moving back and forth from 0 to 1 when there is transmission going on.

Hope it clarify things a bit.

The 0s and 1s seem to be transposed, but apart from that it looks OK. Logic 0 is "asserted" (space) in RS-232, and logic 1 is "deasserted" (mark). The quiescent state of RXD and TXD (when no characters are being sent) is logic 1.

From the set-up you posted earlier, the Prolific adapter (controlled by clupdate) is acting as the DTE (data terminal equipment), and the FTDI adapter via the Null Modem dongle (controlled by the Python test program) is acting as the DCE (data circuit-terminating equipment). The Null Modem dongle will cross over RXD & TXD, CTS & RTS, DSR & DTR, and wire DCD to DSR at each end. So on the tester:

• DCD shows the state of DTR output by the FTDI before the Null Modem
• RXD shows the state of TXD output by the FTDI before the Null Modem
• TXD shows the state of TXD output by the Prolific
• DTR shows the state of DTR output by the Prolific
• DSR shows the state of DTR output by the FTDI before the Null Modem
• RTS shows the state of RTS output by the Prolific
• CTS shows the state of RTS output by the FTDI before the Null Modem
• RI is not passed through the tester (it would normally be output by a real modem)
  

[Sylvain Cote]

(01-02-2020 07:03 PM)ijabbott Wrote:  The 0s and 1s seem to be transposed, but apart from that it looks OK. Logic 0 is "asserted" (space) in RS-232, and logic 1 is "deasserted" (mark). The quiescent state of RXD and TXD (when no characters are being sent) is logic 1.

RS-232C use inverted logic vs voltage level, a logic zero is declared when the voltage goes over +3V and a logic 1 is declared when the voltage goes under -3V.

(01-02-2020 07:03 PM)ijabbott Wrote:  From the set-up you posted earlier, the Prolific adapter (controlled by clupdate) is acting as the DTE (data terminal equipment), and the FTDI adapter via the Null Modem dongle (controlled by the Python test program) is acting as the DCE (data circuit-terminating equipment). The Null Modem dongle will cross over RXD & TXD, CTS & RTS, DSR & DTR, and wire DCD to DSR at each end. So on the tester:

• DCD shows the state of DTR output by the FTDI before the Null Modem
• RXD shows the state of TXD output by the FTDI before the Null Modem
• TXD shows the state of TXD output by the Prolific
• DTR shows the state of DTR output by the Prolific
• DSR shows the state of DTR output by the FTDI before the Null Modem
• RTS shows the state of RTS output by the Prolific
• CTS shows the state of RTS output by the FTDI before the Null Modem
• RI is not passed through the tester (it would normally be output by a real modem)
  

Yep, you are right. RI line is wired but not driven, that is why no LED is lighten up.

Lots of peoples have a hard time understanding RS-232C DTE & DCE roles and communications direction that goes with it.
It was designed in the 1960's and reflect the reality of the equipments back then.

Data Terminal Equipments (DTE): Teletype, Terminal, Computer, etc
Data Communication Equipments (DCE): Modem, Printer, Plotter, etc.

As an example, when using a DB9 connector ...
a) the transmit data (TXD, pin 3) on the DTE side is an output line but on the DCE side it is an input line
b) the received data (RXD, pin 2) on the DTE side is an input line but on the DCE side it is an output line

It is why when using our USB-to-RS-232C DTE dongles we need a NULL MODEM dongle that switches wires to create a DCE device on the other side.
Direct DTE-to-DTE or DCE-to-DCE communication is not possible without a NULL MODEM adapter, the interface was designed at the hardware level to only works when a DTE device is connected to a DCE device.

Sylvain

[ijabbott]

(01-02-2020 07:36 PM)Sylvain Cote Wrote:  

(01-02-2020 07:03 PM)ijabbott Wrote:  The 0s and 1s seem to be transposed, but apart from that it looks OK. Logic 0 is "asserted" (space) in RS-232, and logic 1 is "deasserted" (mark). The quiescent state of RXD and TXD (when no characters are being sent) is logic 1.

RS-232C use inverted logic vs voltage level, a logic zero is declared when the voltage goes over +3V and a logic 1 is declared when the voltage goes under -3V.

Yes, it's like a "double inversion". It is inverted with respect to voltage level and also inverted with respect to assertion:

• Negative = logic 1 = mark = deasserted
• Positive = logic 0 = space = asserted