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

[Bliss]

@Toastie,

Since the FT232H seems to do the job and has even a FT245 mode, I decided to pursue my test with the FT245 while I'm waiting for the FT232H delivery later this week (Amazon).

So I tested the FT245 in its native mode (Serial Com port) which sends Bytes directly to its Datalines D0-D7 and reads bytes from the same datalines (Shared).

Since the datalines are shared, we need some TTL chips ...

I juste tested the Outputs D0-D5 for now with the 74HC174 that was lying around...  (74HC573 would also do the job).
The CLK of this 74HC174 is wired to the FT245 RXF and RD pins but for the RD pin I needed a small RC circuit (1K res + 10nF Cap) to make a pulse...  Easy.

It is working flawlessly with a Terminal utility like Hercules sending Bytes one at a time (Hex).
AND IT IS WORKING with TCLOGO_S.com as well in DOSBox-X !

No arduino at all, just the FT245 (Should be soon the FT232H) and 74HC174 and RC circuit (1K Res + 10nF cap ) (And LEDS :-) )

Now for the Inputs (6, 7) There is more to add...
I guess that TCLogo_s read continuously when it is not writing ? (DOS shares the same IO Adress right?)

 

Edited Sunday at 09:50 PM by Bliss

[evank]

25 minutes ago, Bliss said:

No arduino at all, just the FT245 (Should be soon the FT232H) and 74HC174 and RC circuit (1K Res + 10nF cap ) (And LEDS :-) )

Now you have my attention. ;)

Were all of these components readily available in the 1980s?

[Bliss]

@evank

Now that's the tricky part...

USB I believe did not exist in 1980s I think...

And in today's computer, no more parallel port and no more ISA bus and no more serial port...

But we can still get seiral comm with the use of USB to serial adapters...

Suppose you accept the USB-Serial adapter and start your rules from the serial RX / TX pin and GND...   
The FT245 / FT232H does more, as it allows to transform Serial comm from the USB port (Still seen as COM port in the OS) to parallel data lines (D0 to D7) directly...
FT245 is called a USB to parallel FIFO interface...  (Still using COM port on the PC, but no TX RX at the other end, it is directly parallel lines).  (FT232H can do the same but is more universal as it can also do basic USB to serial with RX TX etc).

So it depends if you accept the FT245/232H like you would maybe accept a USB-Serial adapter...

For the TTL part, I'm pretty sure everyting was available back then but was 74LSxxx, not the more efficient 74HCxxx.  (Gemini said all the 74LS174, 244, 573 were avail at the end of 1970s) 

Edited Sunday at 10:36 PM by Bliss

[evank]

3 hours ago, Bliss said:

USB I believe did not exist in 1980s I think...

And in today's computer, no more parallel port and no more ISA bus and no more serial port...

But we can still get seiral comm with the use of USB to serial adapters...

Suppose you accept the USB-Serial adapter and start your rules from the serial RX / TX pin and GND...   
The FT245 / FT232H does more, as it allows to transform Serial comm from the USB port (Still seen as COM port in the OS) to parallel data lines (D0 to D7) directly...
FT245 is called a USB to parallel FIFO interface...  (Still using COM port on the PC, but no TX RX at the other end, it is directly parallel lines).  (FT232H can do the same but is more universal as it can also do basic USB to serial with RX TX etc).

So it depends if you accept the FT245/232H like you would maybe accept a USB-Serial adapter...

For the TTL part, I'm pretty sure everyting was available back then but was 74LSxxx, not the more efficient 74HCxxx.  (Gemini said all the 74LS174, 244, 573 were avail at the end of 1970s) 

USB is definitely out of the question for the 1980s.

However, a USB-to-serial adapter is fine for modern use an period authenticity.

Regarding your comment, "it depends if you accept the FT245/232H" -- I don't know enough about this. @Toastie what's your opinion ... Also you seem to understand, in our private messages, how best to explain such things to me!

[Toastie]

7 hours ago, evank said:

However, a USB-to-serial adapter is fine for modern use an period authenticity.

@evank @Bliss,

Well I guess this is the core of the matter - along with possible application scenarios: Define period authenticity - for individual scenarios!

"Modern use" means to me: Using a modern computer for controlling vintage hardware. As we all know modern computers (manufactured after let's say 2020), and particularly laptops, don't have built-in serial ports anymore, and the parallel port is gone since long. What we are stuck with is essentially USB, which uses a "modern" serial protocol, which is quite complex.

LEGO hardware equipped for "simple" RS232 serial communication (Interface B, RCX etc.) is readily reachable from USB using USB2Serial adapters and thus from modern computers. If this is defined as period authentic, then I believe, the FT245/232 approach is as well, see my reasoning below.

The old LEGO Mindstorms IR communication tower - still available cheaply - was just transforming what came in over a serial TX line - i.e., bytes, which were 8 bits one after another, wrapped by a start and stop bit, and a parity bit. Usually the way of wrapping is dictated by the receiving device; for the RCX it was 1 start bit, odd parity (bit), 1 stop bit - arriving at a rate of 2400 bits/s (Baud). There is a piece of hardware in each serial device (UART) that does this wrapping on the sending side (8 bit parallel to 8 bit serial + wrapping) and on the receiving side (unwrapping + 8 bit serial to 8 bit parallel).

On a controlling computer, this 1:1 matching is straight forward using a (USB) virtual COM port. The moment you stick in the USB2Serial adapter, the operating system creates such a port for you. At that point, any programming environment having access to such virtual COM ports can now interact with the other side after configuring the COM port appropriately.

Things do change quite substantially, when (8-bit) parallel port access is required. And this is the case solely for Interface A, which a core component in our vintage electronics world though. For one there is no Baud rate, just parallel 8 bit changes at whatever rate. Vintage LEGO programs and hardware were not superfast, so that any 8 bit serial to parallel conversion, let's say at the Baud rate LEGO Blockly is using (115200 bits/s) is technically a joke. This can be done in many ways, e.g., by our beloved Arduinos or any other modern microcontroller. 

This is what I have done with my bare-bone Arduino approach: Whatever byte comes in on the serial receiving line of the Arduino is translated to 8 bit parallel out. And vice versa.

Scenario: Win11 laptop running QBasic within DOSBox-X (DX). The DX software can channel emulated serial data to one of the many virtual USB ports of the laptop. On one of them is a USB2Serial adapter and this one sends 8 bit serial data

• wrapped with 1 start, no parity, 1 stop bit at a rate of 115200 Baud.
• The Arduino's UART settings are also 115200 Baud, 1 start, no parity, 1 stop bit. 
• What I get after serial transmission is clean (parallel) 8 bits, for further programming usage. 

This works from QBasic or the patched TCLogo version TCLogo_s, where Alex rerouted the parallel port operation to the DOS serial port COM1.

HOWEVER  in your challenge you explicitly said: NO ARDUINOS allowed! Period.

So, in the above FT245/232 discussion, we specifically look for a means to "constructing" a device, that translates serial USB data "directly" to 8 bit parallel data, using a virtual COM port (because then we can use DX and run old LEGO of other software on it) without using an Arduino or the like. It is just a hardware translation thingy, no programming "in-between", and thus not allowing dirty tricks . There are such adapters available out there, however, they are a) expensive and b) usually do require sending a command preceding the actual data byte/word/long, so that the adapter knows what to do. TCLogo never sends any commands though. Just pure data byte reflecting the outputs of Interface A.  

Conclusion: As far as I am concerned, @Bliss FT245/232 solution really IS period authentic: No programming, on one side USB, then translation hardware, on the other side true vintage TTLs.

When it comes to LEGO Blockly, Arduinos are the best choice for the protocol translation, as Blockly is nothing near vintage, but high-powered, top-notch software allowing access to numerous LEGO vintage devices. It was Interface A that made it more complex, as this is the only device with parallel access.

This is just my limited view/interpretation of things - I taught all that electronics stuff myself. So there may be garbage up there - I said it before: I am just a chemist!  

Best
Thorsten

[Toastie]

13 hours ago, Bliss said:

AND IT IS WORKING with TCLOGO_S.com as well in DOSBox-X !

Oh yessssss!!! 

13 hours ago, Bliss said:

Now for the Inputs (6, 7) There is more to add...
I guess that TCLogo_s read continuously when it is not writing ? (DOS shares the same IO Adress right?)

Well not exactly. Yes, DOS uses the same I/O address for serial r/w.

But what TCLogo (all variants) does, is this classic speeding-up-things trick (mostly for games ^^):

• Upon startup, it manipulates the DOS interrupt table with pointers to TCLogo code 
• then changes the PIT settings to fire every ms (1 kHz). Doing it that way, TCLogo runs with the exact same timing on different machines (XTs, ATs, or within DOSBox-X, as they correctly emulate the PIT).
• It also counts how many times it has cycled through the new interrupt routine and then adjust the timer tick accordingly, otherwise the time would run really fast, when TCLogo runs 
• So what happens in TCLogo runs is: Every ms it cranks out one byte to the 9771 parallel card, regardless of any changes on the outputs, as it does generate 125 Hz PWM (6 channels) this way. So when using power different settings for the outputs, they are constantly turned on/off at 125 Hz. Fine for motors and incandescent lamps.
• It also reads the status of the 74LS373 latch which has its Q outputs connected to the data bus of the computer. D lines 6 and 7 of this latch are connected to the sensor outputs of Interface A, so that you get an 1 ms constant update of the input status.
• That is the reason I am sending back the output status of the 8 GPIO pins of the Arduino in my serial2parallel conversion program immediately fater TCLogo was writing new data: this mimiks, what TCLogo does anyway: Send data, read data, wait for 1 ms.

I did write this up in this post - it's a long read, though, meant to be some sort of documentation (you need to click the upper link dated May 19)

Best wishes
Thorsten

 

Edited Monday at 11:10 AM by Toastie

[evank]

1 hour ago, Toastie said:

HOWEVER  in your challenge you explicitly said: NO ARDUINOS allowed! Period.

No.

I said no modern microcontrollers for adapting period computers that weren't supported by Lego. For example the ones you hacked to work with 9750 -- TI, Atari, Sinclair. My logic is simple: if you're going to make a 1980s computer work for 9750, other than the ones Lego endorsed using, then do it with period technology.

Use whatever you like for adapting a modern computer to 9750. What difference would the microcontroller make, since the whole computer to which it's attached is modern anyhow?

That being said, I do appreciate that you and @Bliss figured out how to make Blockly/9750 interact in an authentic-ish, period-ish manner. :)

Granted, I may have confused my own point :) in my question to Bliss yesterday.

Edited Monday at 11:55 AM by evank

[Toastie]

1 minute ago, evank said:

Use whatever you like for adapting a modern computer to 9750. What difference would the microcontroller make, since the whole computer to which it's attached is modern anyhow?

Ahhh - now we are talking!!! That makes total sense!

I thought its was more the "programming" in-between issue that worried you as one can do so many additional things other than data protocol translation on modern microcontrollers.

So modern computers + Arduinos (or the like) as protocol translators are OK, the strict rules only apply to vintage computers needing period correct, vintage type translators, right?

Furthermore: If @Bliss gets the FT245/233 talk to one or two TTLs, we move the vintage side of things even closer to the modern computer hardware. It will have to stop at the ultimate vintage barrier: USB2TTL or serial translation and then FIFO. But no microcontroller.

Nicely and clearly defined, indeed!

1. Vintage computers: period correct translation hardware (TTL, CMOS etc.) required
2. Modern computers a) using newly developed or other modern software: Microcontroller translation allowed
3. Modern computers b) using vintage software in emulators: The FIFO/bit-bang approach, if successful.

Does this make any sense? It applies to Interface A only, of course.

Best
Thorsten

  

[evank]

26 minutes ago, Toastie said:

Ahhh - now we are talking!!! That makes total sense!

I thought its was more the "programming" in-between issue that worried you as one can do so many additional things other than data protocol translation on modern microcontrollers.

So modern computers + Arduinos (or the like) as protocol translators are OK, the strict rules only apply to vintage computers needing period correct, vintage type translators, right?

Correct. Again, I apologize for being unclear.

26 minutes ago, Toastie said:

1. Vintage computers: period correct translation hardware (TTL, CMOS etc.) required
2. Modern computers a) using newly developed or other modern software: Microcontroller translation allowed
3. Modern computers b) using vintage software in emulators: The FIFO/bit-bang approach, if successful.

Does this make any sense? It applies to Interface A only, of course.

Points 2 and 3 tend to overlap. (It's like what you were telling me and @alexGS in a private message the other day ... the hardware/software line blurs, when trying to organize on-topic posts.)

For my under-development Interface A table (http://www.brickhacks.com/table.htm), I need to start adding some rows about connecting modern computers. I am feeling newly energized to do so, because I KNOW ABOUT SOMETHING THAT YOU ALL DON'T KNOW ;) which will soon be revealed. < evil grin >

Edited Monday at 12:42 PM by evank

[Toastie]

8 minutes ago, evank said:

will soon be revealed

In two weeks? 

Now that is really exciting!!! Any hints? Hardware, software, both ... or is it more "personal"?

Can't wait to hear about it.

Best wishes
Thorsten 

[evank]

Big secret :)

I'm just being a weenie by teasing about it now.

Edited Monday at 12:57 PM by evank

[Bliss]

2 hours ago, Toastie said:

So what happens in TCLogo runs is: Every ms it cranks out one byte to the 9771 parallel card, regardless of any changes on the outputs, as it does generate 125 Hz PWM (6 channels) this way. So when using power different settings for the outputs, they are constantly turned on/off at 125 Hz. Fine for motors and incandescent lamps.

I read your long experiment in the INT A thread but diagonnaly so I missed some key elements...

I tried the setpower in TCLOGO_S and the Leds I wired for the outputs of the FT245 were blinking fast :-)

So about this FT245/232H thing, It might work in its native configuration (Standard OS driver) after some good effort (Still struggling for the inputs) natively but it needs a bunch of circuitry (TTL, Res, Cap)...
The Bit Bang Mode, which involve loosing the Serial COM port, so purely USB, is more interesting for me as there are NO external component needed, only wire the pins directly to INT.A...
That was my primary goal, find a solution that almost works out of the box with no microcontroller to deal with.  (Still have to wire the pins of FT to INT.A somehow and change the Driver with Zadig).
It works with Modern software, but not with original TCLOGO/LINES...

But using FT in its native mode, Serial COM and shared FIFO input/Output requires some DIY circuitry which for me, render the whole project less appealing...

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, 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.

Edited Monday at 01:43 PM by Bliss

[Toastie]

12 minutes ago, Bliss said:

The Bit Bang Mode, which involve loosing the Serial COM port, so purely USB, is more interesting for me as there are NO external component needed, only wire the pins directly to INT.A...
That was my primary goal, find a solution that almost works out of the box with no microcontroller to deal with.

And that is perfect, as you connect with Blockly to such an interface, correct? That would be indeed the most elegant solution for this scenario.

For the vintage software scenario, the Ardunio/COM port approach is fine, as far as I am concerned. Again, it works out of the box, can even be run via BT and all is good. All that is needed is the Arduino program I came up with and it works. I shall ask the developers of DOSBox-X whether they can maybe emulate a more powerful chip UART chip than the 8250 - that one doesn't like baud rates > 9600. Or after zapping it 19200. The 16550 UART is much better ... we shall see.  

Best
Thorsten

[Wapata]

On 6/24/2026 at 7:29 PM, Bliss said:

finally found a Lego Dimensions Starter Pack (Batman) for Wii.

And it is the very same for all the consoles except Xboxes (it's written on the sticker on the back).

I discovered Lego Dimensions 3 weeks ago and nobody around me know it exists neither ! Whatever they are gamer or Lego fan... A 10 years ago stuff.

... And the game look cool !

[Toastie]

@Bliss

I got my Dimensions Toypad out, but LEGO Blocky does not find it. I am using the latest LEGO Blockly version (2026-07-11-0820). It says "No compatible device found."

If I remember correctly, my pad is also for a Wii, but as @Wapata said, they all behave the same except the XBox version, I research that before I got mine several years ago .

I also digged-up a rather old zip file on my laptop with a basic ToyPad control program. It still works! You can copy it here, if you wish:

https://bricksafe.com/files/Toastie/this-and-that/NFCBaseColorChanger_v1.zip 

It runs in its own directory, just unzip it. When the program comes up (click on exe file), I first press "Scan USB". This produces a good number of HID devices (?) in the drop-down list of which I select the "241 LegoDimensionsPortal". Then I press "Activate" and it replies with "Device 1 interface 0 connected". When I go to the tab "USB descriptors" this shows up:

When I expand the LegoDimensionsPortal entry, this shows up:

 

The rest of that entry reads:

There is more under "Setting 0", but I guess this is all uninteresting, isn't it?

I can then run the Demo, which lights up some LEDs.

Do you have any idea what I am doing wrong with Blockly?

Thank you very much!
Thorsten

Edited Monday at 06:34 PM by Toastie

[Bliss]

1 hour ago, Toastie said:

Do you have any idea what I am doing wrong with Blockly?

I don't see why right now because my code filters for the same vendor and product ID shown in your images.

      const devices = await navigator.hid.requestDevice({
        filters: [{
          vendorId: 0x0E6F,
          productId: 0x0241
        }]
      });

On my side, I tried Blockly and your NFC color changer and both works.

Make sure you have the latest version of Chrome in case.

Check the Chrome Console (F12) for any error message.

Make sure you do not try to connect while your pad is already connected to your NFC Color Changer program.

What OS are you working with?

Did you tried on different USB port?

Also, the NFC Color changer software, use libusb.dll which is not the same as the Chrome's WebHID...

If your using windows 10, make sure the permission are enabled in chrome for USB devices.  Type the following in chrome:

chrome://settings/content/usbDevices

 

Edited Monday at 07:35 PM by Bliss

[Toastie]

27 minutes ago, Bliss said:

On my side, I tried Blockly and your NFC color changer and both works.

Make sure you have the latest version of Chrome in case.

Check the Chrome Console (F12) for any error message.

Make sure you do not try to connect while your pad is already connected to your NFC Color Changer program.

What OS are you working with?

Latest version of Chrome - check.

Phew - it tells me a lot, but I don't see any errors ...

Pad was not connected, rebooted, same thing.

I am using Windows 11 Pro, Version 23H2, Build 22631.6199, as per "winver" (hmm is that a bit outdated? I have automatic updates turned on, and another window tells me I am upto date?)

Best
Thorsten

Updates should be up

[Bliss]

@Toastie,

Did you check the permissions in chrome?
Type the following in the address bar:

chrome://settings/content/usbDevices

You already used USB to serial adapter with your setup, so It cannot be the permissions...

 

When you plug your toypad, does it appear in the Windows Device Manager in the "Device Manager → Human Interface Devices"  (HID-compliant device)?
(Mad Catz, Harmonix, LEGO, Unknown device, Vendor HID driver, HID-compliant vendor device, all those are bad)
Here, it shows many generic HID devices but I can see that one more HID is adding up when I plug the toypad...
If you have the wrong driver, in dev manager, uninstall device and check the "Delete the driver software for this device"... unplug toypad and reboot.

 

Can you try on another PC?

Edited Monday at 08:06 PM by Bliss

[Toastie]

32 minutes ago, Bliss said:

When you plug your toypad, does it appear in the Windows Device Manager in the HID devices (HID-compliant device)?

I believe no, in device manager it shows up as a "libusbK USB device" (main entry) and then as LEGO READER V2.10 and there it says: All good.

When I unplug the pad, this entry is gone, when I plug it in, it shows up again and Windows does the friendly "USB device plugged in" sound.

I believe here is where it derails?

Best
Thorsten

Edited Monday at 08:13 PM by Toastie

[Bliss]

8 minutes ago, Toastie said:

I believe here is where it derails?

The WebHID api in chrome works only for HID-compliant device in the "Device Manager → Human Interface Devices".
Delete any other drivers that appears when you plug the Toypad... (Check the box for delete its software as well)...  Reboot

[Toastie]

OK, I shall do that tomorrow night! 

Oh BTW, I do have another PC: An IBM XT. It lacks USB ports though - but has 9771, serial, and parallel cards in the slots 

THANK you very much for looking into my troubles - I bet this will resolve the issue.

Best
Thorsten

[Toastie]

11 hours ago, Bliss said:

Here, it shows many generic HID devices but I can see that one more HID is adding up when I plug the toypad...
If you have the wrong driver, in dev manager, uninstall device and check the "Delete the driver software for this device"... unplug toypad and reboot.

@Bliss

THIS did the trick - I just watched all the HID entries and in fact one was added, when I plugged in the pad after deinstallation (well I actually removed the libusbK.sys driver and the libusb0 and libusbK dlls). 

After reboot, when trying to connect to the pad, Blockly said "unknown device" followed by a cryptic hex number of the format "ABCD:EFGH". At first I thought "merde" and was clueless. But then I just clicked on that unknown device, Bockly encouraged me then to press "connect" and - WORKS!

For the first time in my life, I composed a one-block line of code to switch on some LED's on the pad!

THANK YOU VERY MUCH!!!

Need to rush to work now ...

All the best
Thorsten

[Bliss]

37 minutes ago, Toastie said:

Blockly said "unknown device"

I also get this once in a while, but when I disconnect the toypad from USB and reconnect it to USB, then the Lego Blockly connect dialog show "LEGO READER V2.10"...

[Toastie]

10 hours ago, Bliss said:

"LEGO READER V2.10"...

@Bliss

That is what it does now all the time :)

And now I am playing with tags (I have about 10 and one is Gandalf) and LEDs ... and ran into this little challenge:

Regardless what I do, the LEDs never change their color, it always stays blue; with or without Gandalf on the center reader ...

I checked Gandalf's ID a couple of times (the long hex numbers ...) and typed it into the "set Gandalf to" line as the hex code the display function gave me: 0x... and then the hex number. Upon pressing return the correct decimal number is shown. I also copied the number set Gandalf to and pasted it into the Windows calculator set to prgrammers mode: It shows the correct hex number, without leading zero of course.

Could it be my hex/dec translation, that screws this up? Or the leading zero in the hex number?

I am planning on using the tags as switches for LEGO models :D

Best regards
Thorsten 

[Bliss]

2 hours ago, Toastie said:

Could it be my hex/dec translation, that screws this up? Or the leading zero in the hex number?

Set your variables using TEXT values (found in the Text toolbox).

No conversion needed...  The Tag Hex Region returns Hex IDs as Text (String) not numbers.

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

 

Edited Tuesday at 09:05 PM by Bliss