Project: Programs to allow interactions between old Lego Control Interfaces (RCX, Lego Interface B, others?)

[Toastie]

1 hour ago, Bliss said:

There is a tooltip if you leave your mouse on the block for a moment.

I need to be more patient, focused, sorry for just posting without thinking. 

I believe all my rushing is caused by ... realizing what has been enabled by LEGO Blockly.

It seems to be related to this Queen song: "I want it all, (...), and I want it now"

Thank you again!

Best
Thorsten 

 

[Bliss]

On 7/13/2026 at 9:42 AM, Bliss said:

However, thinking about it, we could maybe think of a software gateway, I remember this com0com null modem serial com port emulator...
Between TCLOGO_S/DOSBOX-X and the FT245/232H/232RL, there would be a gateway software to catch the TCLOGO serial traffic (com0com comes handy here) and convert it to USB Direct IO to FT in bigbang mode and then to the Int.A...
Just to keep things somehow compatible with old software...  Anyway, I might evaluate this route eventually.

@Toastie and others...

I finally tested this route with a VERY cheap FT232RL breakout board.  (NOT THE FT232H which is another project ;-) )

Please see the following post for the details of the pinout and pictures of this RED board and also how to set it up in big bang mode (Use Zadig to replace the OS driver by a generic usb driver)
Don't forget to set the jumper to 5v.

 

I asked Gemini to make a program to act as a software gateway between Serial traffic from TCLOGO_S and the FT232 board which utilise USB comm Bit Bang mode (Not serial COM).
He first suggest a Node.JS code but I also asked for a python program as I already familiar with Python and the famous Thonny IDE.

I STRONGLY SUGGEST to use THONNY to try it out as it is so easy for beginners like me.
Thonny is available here: https://thonny.org/

 

Here are the easy steps:

1. - Get com0com virtual com emulator: use the version 2.2.2.0 64 bit signed as the 3.0.0.0 does not work for me and for many people. (Windows 11).
   https://sourceforge.net/projects/com0com/files/com0com/2.2.2.0/com0com-2.2.2.0-x64-fre-signed.zip/download
   After installation completed, Lauch the setup for com0com and type over the proposed virtual port pair port names.
   While you type a port name, if the port is not avail, the text becomes red.  I have choosen the port name COM12, COM13.
   Click Apply.
   
   
   You should have the following in the Device Manage:
   
    
2. Modify you Dosbox-x.conf file:

   serial1       = directserial realport:COM12

3. Download the LegoGwy_FT232.py : https://github.com/BlissCA/lego-blockly/blob/dev/Misc/LegoGwy_FT232.py

4. Open this python file in Thonny.

5. Make sure Thonny has the pyserial and pyusb library.  Go to Tool menu, Manage Plug-ins, in the search box enter pyserial and install if not already and do the same for pyusb.

6. In the code window of thonny, search for "GATEWAY_PORT = " and change COM13 for the second port you configured in the pair in com0com earlier...

7. Now in Thonny, you are ready to press the Green "Play" button ("Run Current Script").

8. If everything is setup correctly, it will print:

   >>> %Run LegoGwy_FT232.py
   FTDI Chip successfully locked into raw Bit-Bang Mode via Python!
   Gateway listening for DOSBox-X traffic on virtual COM13...

   Some outputs initialize to ON when we connect the FT232 to USB...  Make sure you interface A is not powered on until the gwy is running properly and found the FT232. 
   Running the python program succesfully resets the output to OFF...

9. Now you can start Dosbox-x, Mount the Folder that has TCLOGO_S.COM from @alexGS: https://bricksafe.com/files/alexGSofNZ/interface-a-tc-logo/TCLOGO_S.COM

10. Execute TCLOGO_S, and try it out...  It is very fast, at least with LEDS ;-)  I tried the Inputs 6, 7 too with a logo command WAITUNTIL [SENSOR?] ONFOR 20...  (I previously ran the command TTO [0, 2, 4] and LTO 7...)

11. I guess this will work with Legacy Lego Lines for DOS too...  But this Lego Lines would also have to be patched to use COM port IO Address rather than Parallel/ISA IO Address...

12. ALSO NOTE that this configuration DOES NOT allow the use of a BT adapteur (HC-05)...

 

Edited Wednesday at 11:14 AM by Bliss

[Toastie]

5 hours ago, Bliss said:

I finally tested this route with a VERY cheap FT232RL breakout board.

I ordered two of those and they should arrive any time soon!!!

Best
Thorsten

[Wapata]

Sorry, what will be the goal with this board ? 

[Toastie]

46 minutes ago, Wapata said:

Sorry, what will be the goal with this board ?

@Bliss will certainly reply ...

... it is a serial to (fully bidirectional) parallel converter, that allows any program having access to a Windows COM port, for example DOSBox-X, control Interface directly. No microcontroller in-between, just software and this board, that cost less than $/€ 5.

Thus, in DOSBox-X, you can run programs such as TCLOGO_P with full control over Interface A.

Or you can program stuff yourself in, e.g., QuickBasic. Or TurboPascal, and so on.

It is more or less a fun project!

Best
Thorsten 

[Bliss]

1 hour ago, Toastie said:

... it is a serial to (fully bidirectional) parallel converter, that allows any program having access to a Windows COM port, for example DOSBox-X, control Interface directly. No microcontroller in-between, just software and this board, that cost less than $/€ 5.

Thus, in DOSBox-X, you can run programs such as TCLOGO_P with full control over Interface A.

Actually, FT232RL breakout red board is a USB-TO-SERIAL TTL adapter in its standard configuration, used with Windows native driver.

To use it in a parallel lines configuration to attach an Interface A directly to the board , you need to change the native Virtual COM port OS driver with a more generic one (Zadig utility allows us to achieve that)...

NOT TCLOGO_P but TCLOGO_S which is a patched version that uses serial communication.

Original TCLOGO.COM (ISA Board) or the patched TCLOGO_P.COM (Parallel IO Address) will not work.  Because we cannot easily redirect any IO Ports address used in DOS...

EDIT:
For now, it is more a fun project as I do not intend to implement into Lego Blockly, the "Continuous BYTE WRITE/READ" protocol TCLOGO uses.
It is a 1ms continous Write/read that allows to do some kind of software PWM which I doubt a WEB APP could achieve as it is not fast and deterministic enough.

Edited Wednesday at 10:39 AM by Bliss

[Toastie]

Just now, Bliss said:

NOT TCLOGO_P but TCLOGO_S

Sorry, of course TCLOGO_S!!! This is the version, Alex has patched for us to run within DOSBox-X or a PC w/o 9771 or parallel port ...

This is why "we" (@alexGS ??? ) would have to patch LEGO Lines for DOS as well, if we want to use this approach. A LEGO Line_S version would do the trick ... 

Best
Thorsten

[Bliss]

I improved I think the Gateway program for the FT232RL for better support of TCLOGO_S AND also other than TCLOGO_S software...
Like maybe Lego Lines if a patched version ever happens...
https://github.com/BlissCA/lego-blockly/blob/dev/Misc/LegoGwy_FT232.py

Because the first version of the gateway was only sending back sensor status if it received an Output write from TCLogo...
It was fine for TC LOGO because it writes continuously every 1 ms to achieve PWM...

But I doubt Lego lines does that...  So the new version alway send input status with or without the write of outputs...

 

[Toastie]

7 hours ago, Bliss said:

But I doubt Lego lines does that...  So the new version alway send input status with or without the write of outputs...

That is true. I believe there is some message in this or the 9750/9771 thread that says LEGO Lines does not do PWM, and thus the ms interrupt seems to be unnecessary ...

How often does the new version send the input status? Or is it upon request? 

I am desperately waiting for the FT232RL to arrive ... 

Best
Thorsten

[Bliss]

5 hours ago, Toastie said:

How often does the new version send the input status? Or is it upon request? 

It should send Input status ON CHANGE only OR after an Output Write.  (The read byte is always the In 6/7 status AND the Out 0-5 last write state)

If the inputs change their state quickly i.e. faster than the end user software can take it, It is not supposed to overflow , nor fill the com RD/WR buffers etc... 
So the input status read of the gateway should adapt to the end user software input scan time...

But I only tested with TCLOGO_S to make sure it was still working with instant response of the input changes...

And I tested with Hercules terminal utility connected to COM12 (Same COM port configured for TCLOGO_S)...
With Hercules, even if no output write sent, it reads a byte only when input changes.  (Input 6/7 state with last outputs 0-5 state as well)
When it writes a byte to output, it reads a byte back which will be the input and new output state.
 

Maybe it would work with your QBasic program as well in Dosbox-x...

Edited Thursday at 12:56 PM by Bliss

[Toastie]

1 hour ago, Bliss said:

It should send Input status ON CHANGE only OR after an Output Write.  (The read byte is always the In 6/7 status AND the Out 0-5 last write state)

Ahh, I see. 

1 hour ago, Bliss said:

So the input status read of the gateway should adapt to the end user software input scan time...

And this is due to potential "danger" of input buffer overflow, correct? TC LOGO_S will not run into such a situation, because it takes one byte every 1 ms, correct? I.e., after one second 1000 bytes would have been flushed from the input buffer?

LEGO Lines may not have such a feature at all, it may only ask for the input status, when arriving at an "input Line", asks once and then continues with other Lines. We should check the LEGO Lines manual, if there are any counters/timers, which would need a multiple read in between two explicit read Lines?

For my QBasic programs having the change = send byte feature of your code is of course perfect. What I do so far is cycling the keyboard read routine as fast as possible, then do an output (even when if there was no change), read the value back = update on changes of the Interface A inputs.  If these are captured by the software you wrote, then I just need to read the input buffer until it is empty, and continue with something else.

Is that how it would work?

Best
Thorsten

[Bliss]

15 minutes ago, Toastie said:

Is that how it would work?

The best will be to test it :-)

[Toastie]

34 minutes ago, Bliss said:

The best will be to test it :-)

 Agreed. The damned postal service is between me and the testing :D

Best
Thorsten

[Bliss]

I added in https://github.com/BlissCA/lego-blockly/tree/main/Misc a diagram that explains this software gateway project for using legacy DOS Lego software for Interface A in a modern computer using a cheap FT232RL in GPIO mode...

EDIT: Please, note that all serial com happens at 9600, 8, N, 1...

 

This was just to demonstrate another way of interfacing with Lego 9750 without using an arduino.  The arduino way still remains the best way according to me (Fairly cheap and flexible)...

There are other direct HW solutions (Serial to GPIO) using FT245/232H board that i'm evaluating, which appears to work WITHOUT any software gateway, (NO com0com, NO python) just plain TCLOGO_S running in dosbox-x communicating through serial/USB to FT245/232H then using FT GPIOs wired somehow to Interface A connector...
BUT FT245 is discontinuated, FT232H is more expensive and it requires a fair amount of TTL and Passive components to be added...  I might give schematic eventually...

 

EDIT:  I tried this FT232RL Gateway with @maehw brick_lines.py and it works.
However, when I run a lines program like BTEST.txt sample that wait for input 6 at one point, it works great but when the lines program finishes and return to dos, the dos window hangs for 1 min and CPU fan runs fast...
But besides that it works.

 

Edited Thursday at 10:33 PM by Bliss

[Bliss]

I'm having fun experimenting new ways to connect to the Old Lego Interface A with Legacy DOS software using Serial communication even If I don't have an interface A haha...

So after playing with the FT245/232H and recently with FT232RL in bit bang mode using a software gateway which works really great but no wireless BT solution can be used, I decided to go back to the microcontrollers but not with an arduino.

I did a test with an ESP-WROOM-32 devkit that is a very popular WIFI/BT etc relatively cheap board.
I used BT NOT BLE (The newer ESP32-S3, C6, C3, etc can only do BLE) to have serial com port at the PC Side like an HC-05.
BT is fast and can do sub msec communication as required by legacy TCLOGO_S.COM...
We can use the Arduino IDE to program the ESP32...
The ESP32 GPIO are 3.3v so we have to use a cheap bidirectional voltage Level shifter like the "TXS0108E"...

I uploaded a simple BT to GPIO program in the ESP32 that does the same byte protocol as my previous FT232RL Gateway program and it appears to work very reliably with TCLOGO_S via dosbox-x ...
This solution requires NO software Gateway nor com0com null modem emulator... it is direct Serial COM to BT.
And it makes the Lego Int.A wireless (Well at least for communication, still need power supply...)

Is it better than a Arduino with a HC-05 BT to Serial adapter...?  I don't know but we eliminate the Serial code with the ESP32 because BT is managed internally...  
Arduino UNO/NANO:  PC End-User program <-> PC Virtual Serial COM port from HC-05 pairing <-> PC BT Dongle <<->> HC-05 BT <-> HC-05 SERIAL Pins <-> Arduino SERIAL Pins <->Using Serial instructions in arduino Code so Baud rate in Arduino code must fit baud rate in end-user programs...
ESP32: PC End-User program <-> PC Virtual Serial COM port from ESP32 pairing <-> PC BT Dongle <<->> ESP32 Builtin BT<-> Using BT instruction in arduino code.

 

The ultimate goal though is to make a solution that would work with both Legacy protocol and a specialized Blockly protocol...
So i'm going to look after making a arduino code that can be used for both legacy protocol AND blockly protocol...

 

I put the arduino IDE sketch for the ESP32 BT (Lego Legacy Protocol only, no blockly yet) in the following folder if some of you want to give a try:
https://github.com/BlissCA/lego-blockly/tree/dev/SketchArduino

In the board manager in Arduino IDE, you must use version 2.17 of ESP32 package.  latest version seems to have a bug for standard BT...
GPIO pins used: 12, 13, 14, 25, 26, 27 for Int.A Output 0 to 5,  32, 33 for Int.A Input 6, 7. 

Edited Friday at 02:47 PM by Bliss

[Toastie]

35 minutes ago, Bliss said:

The ultimate goal though is to make a solution that would work with both Legacy protocol and a specialized Blockly protocol...
So i'm going to look after making a arduino code that can be used for both legacy protocol AND blockly protocol...

That would really be the ultimate burner!!! Because then I would not have to keep track what software is running on which ESP (or Arduino).

Again: VERY exciting news!!!

Thanks a million,
Thorsten

[Toastie]

@Bliss

Downloaded Thonny (never used Python before), Zadig (never heard before, but highly interesting!!!), and com0com (also never heard before and again highly interesting!!! 

This will be an installation/learning frenzy for me - and sounds like total fun.

Your diagram is really nice! Absolutely clear with regard to the work flow. OK data flow 

Thank you very much!

Best
Thorsten

P.S.: The postal service went by today - again! DAM-ned  Well, it will happen - if nothing works in EU I will select Chinese companies. When they tell you "in three weeks with free shipping" for a $10 package, it will be here in two weeks, with free shipping. Like in the olden days, when the German railroad was on time pretty much always. Today it is more like: 30 km? No thanks, I'll take the bike.

Edited Friday at 07:25 PM by Toastie

[Wapata]

(do you really find Lego NXT and Lego Mindstorm by dozen ? Here in France it look like the price is linked to gold price 😭)

[Toastie]

54 minutes ago, Wapata said:

Lego Mindstorm

Do you mean the RCX PBrick or other Mindstorms items?

If it is the RCX then I find them on BrickLink for about €15. Price indeed has gone up - maybe due to this thread 

Best
Thorsten 

[Bliss]

I finished a first version of an ESP32 code (Arduino sketch) for Lego Interface A (and PF IR) support.

Advantage over the Arduino UNO/NANO:

• No HW serial, only use Internal ESP32 Bluetooth.  So it is Wireless natively!
• Dual Protocol support (automatic detection).
  Supports Blockly protocol AND Legacy DOS Lego Software like TCLOGO_S.COM

Requirements:

• ESP-WROOM-32, 30 or 38 pin version  Do not use newer ESP32-C3, C6, S3 etc as they only support BLE.
• In Arduino IDE, Menu Tools, Board, Board Manager, you must use ESP32 Package 2.0.17.   Do not use the latest 3.x.x package.
• Since ESP32 GPIO's are 3.3v voltage level, you need to use a 8 channel Logic Level Converter like DFR0844 or TXS0108E between GPIO and Lego Int.A connector pins...
• It is BLUETOOTH so you must have BT on your PC...  I bought myself a cheap TP-LINK BT/BLE dongle...

 

Once the ESP32 is paired in windows, it creates 2 virtual com port.  Only one will work, the one flagged Outbound...
In windows Bluetooth device page, there is a section for associated parameters and then More Bluetooth parameters...  This will give you more information about the com ports created...

 

I tested only with LEDs connected to GPIOs using 3.3v, NO Logic level converter.
THIS HAS TO BE TESTED/VALIDATED with a real Interface A using Logic level converter before we can decide to make this solution the recommended one.

 

I successfully tested (with leds) the following:

• Legacy mode TCLOGO_S.COM
• Legacy Mode using a terminal software that can send and receive raw bytes like Hercules and Termites.
• Blockly mode Input and Output (PWM) blocks.
• Blockly mode Infrared Power Function.

Note that in legacy TCLOGO_S.com, when I "setpower" to anything less than Max (7), the output leds are blinking fast (PWM) and the blinking looks inconsistent.
I don't know if it is normal, I also observed this with FT232RL tests...

 

Get the ESP32 sketch Lego9750_PF_ESP32_V2 here:  https://github.com/BlissCA/lego-blockly/tree/dev/SketchArduino

Edited 15 hours ago by Bliss

[Toastie]

14 hours ago, Bliss said:

Since ESP32 GPIO's are 3.3v voltage level, you need to use a 8 channel Logic Level Converter like DFR0844 or TXS0108E between GPIO and Lego Int.A connector pins...

@Bliss, @evank:

I just found out experimentally that the Interface A is fully 3.3V compliant :

3.3 V (e.g., from an Arduino Uno board) wired to pin 1 or 3 of Interface A's 20 pin socket are sufficient to drive the 557 transistor (= enabling the 8 opto couplers). 1.5 V from an alkaline battery are not sufficient to drive that transistor, as expected.

However, even 1.5 V (alkaline battery) are sufficient to turn any output of Interface A on, when they are enabled with 3.3 V. I believe this is accomplished by the ULN2003 Darlington driver array (7 channels) in the Interface A. The ULN2003's inputs are directly wired to pins 6,8,10,12,14,16 of the 20 pin socket.

So, no level shifters required, an ESP32 works out of the box! 3.3V as output enabler, and then any ESP GPIO pin for the outputs. The sensor outputs of Interface A (pins 18,20) are internally pulled up with a 2.2kOhm resistor to 5V (when TTL level operated) but only to 3.3V when ESP operated and the 3.3V from the board are used to enable the outputs. So again, all is safe and no level shifter is required.

Best
Thorsten      

Edited 34 minutes ago by Toastie