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 12 hours ago 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 3 hours ago by Bliss