LEGO Technic Control (TC, 1986) meets LEGO PoweredUp (PUp, 2019): Bridging a 30+ years LEGO Technic electronics “gap”.

[Toastie]

Technic Control (TC) from 1986 is - at the very least - absolutely fascinating (to me). It was when TLG wondered into (electronic) robotics ...

Evan Koblentz (@evank on EB), his website is http://brickhacks.com/, has assembled the most comprehensive resource available regarding TC - and it still grows ... a wonderful place to be.

Thus nothing better to begin this thread with a spoiler …

Spoiler

This is (again) about vintage computing and LEGO – however also about using modern machines for running vintage LEGO Technic Control hardware. It is thus about my very personal (and perpetual) LEGO “issue”: LEGO ABS bricks last forever, but in recent decades LEGO electronics changes every 5 years or so - to the extent, that most high level users are screwed every 5 years: TLG makes new hardware, makes it (deliberately …) incompatible, and … still does … line followers. As they did in 1986. Oh sure: No wires anymore, everything is toothed blue, and runs – well – less smoothly: In the current PUp app, one tacho motor – still – after 3+ years, does not work correctly using the “set speed” icon – this simply crashes the app (well after an arbitrarily long time, it stops and then does weird things). In TC world of 1986, motors equipped with rotation sensors built from scratch (using a disk with b/w markings, a light sensor, a 4.5V motor) never failed. And still don’t. Sigh.

 

The project idea

Building an “autonomously” operating, programmable “robot arm” constructed with original Technic Control (TC) LEGO elements (bricks, plates, 4.5V lamps and motors, interface A, all from 1986 – 1988) and PoweredUp (PUp) LEGO elements (hub, motor; from 2019). Most importantly: TC “interacts” with PUp in a way that TC tells PUp when to move the trolley “left/right” to pre-programmed locations consecutively , while operating “up/down/turn L/R, and grab/release” of the arm by itself. This thus requires 4 motors and TC cannot do that without help, as the interface A has only 3 reversible polarity motor outputs. See below for hardware/software details.

What does this combo do? The robot arm [building instructions provided by @alexGS; shown here in a video on his YouTube channel (https://www.youtube.com/watch?v=xLENEktsZdQ)] “quasi-autonomously” exchanges the storage locations of two “parcels”, using three pedestals on a stand and a trolley:

(Left) Lord Darth Vader checking on PUp stuff; (right) Captain James T. Kirk checking on TC stuff; (bottom) MK stand + some TC and other LEGO bricks + 4.5/12 rails + 3 pedestals. Trolley: pulled with a “run-around” chain by a PUp medium linear motor on the left (color/distance sensor not used); (back) PUp Technic hub, powered by the permanent ≈ 4.0 V output of interface A using a small DC/DC converter in the hub’s battery box, see below; (top left) interface A powering the three 4.5V motors of the robot arm and the three 4.5V lamps in the base; (top right) ESP32 Dev kit + opto-coupler board connecting to output A of interface A, Arduino serial to parallel converter, RS232 cable to Win11 laptop (not shown); (center) robot arm, design by @AlexGS). Further to the right is the XT (not shown).

 

“Quasi-autonomously” because instead of a LEGO PUp hub or PBrick of any kind, an IBM XT running PCDOS 3.3 and QuickBasic 4.5 is the brain behind the TC hardware – and I simply failed to get the XT moving on the trolley as well :D

Why such a weird project? a) I wanted to show that TC can interact with PUp with only modest and cheap 3rd party elements used; b) wanted to use original LEGO TC ABS elements mingled with modern LEGO ABS elements plus some MK ABS elements; c) love to bring together vintage and modern electronics, particularly from TLG as they >never< show(ed) us how to accomplish this, and d) because I am simply running out of space up here in my attic and can’t do much more other than rotating something rather small by 180 degrees on the spot :D

Did some remodeling up here lately to accommodate an original IBM XT (this one from 1985) – and these monsters do consume some room. Even worse, in the setup shown in the above figure, for a full 180 degree turn of the arm, it needs to be a) in the upper position, otherwise it crashes into a shelf; and b) the arm also needs to be moved laterally when turning, otherwise it crashes into a pedestal :D Space … the final frontier …

Here is a short (and very boring video) of what the robot arm does – it was way more fun to bringing those two LEGO programming worlds together than taking that video. More on that below.

(Video does for some reason not load - it does on YouTube: Just click here: https://www.youtube.com/watch?v=-6WI4i-TcYs)

 

LEGO Hardware used

One version of the robot arm (grab/release, up/down, turn left/right) is depicted in one of the LEGO Dacta booklets coming with set #1092; however a >much improved< version was provided by @alexGS. I would not have been able (zill!) to build the robot arm without a ton of help from Alex. The turn table’s (the arm is mounted on) instructions are available as building card in Dacta set #1092. The simple trolley I made is pulled back and forth using the small LEGO chain elements and is operated by the LEGO Technic hub and a PUp tacho motor (see below). The trolley runs on dark gray LEGO plastic train rails. And oh boy – the rails are affixed to the base of a stand for the MK Flying Dutchman … for fun I added three LEGO 4.5V lights to the stand’s base – just for show, nothing else. Well, not exactly: It shows that the outputs of #9750 can drive much more than one 4.5V motor each …

Up/down, rotation left/right, and grab/release of the arm is done with three #6216 4.5V motors, #9750 interface A, the XT (+ LEGO #9771 ISA bus card) running PCDOS 3.3 and a compiled MS QuickBasic 4.5 (1988) program I wrote for that purpose. So in essence most of the stuff used to build and operate the arm is about 35 years old; the stuff to pull it back and forth is from 2019 onwards. The Technic hub is powered from the permanent 4V DC output of interface A with an additional DC/DC converter:

 

As said, the lateral motion of the robot arm is done with a trolley moving on 4.5/12V type LEGO rails, operated by the linear medium PUp M motor (#88008), hooked up to a 4-port PUp Technic hub #88012. An ESP32 Dev kit board running Legoino is used for controlling the PUp devices; there is also the PUp remote (#88010) for manual trolley operation and PUp program control. I cannot (and don’t want to) get used to the LEGO PoweredUp app. After all, this stupid app >always< crashes, when operating TLG’s very own #88008 motor in tacho (PID) mode – even after TLGs 4+ years of app development …

 

Other electronic hardware employed
It turned out that using the ESP32 Dev kit/Legoino hard/software combo was (again) a fortunate approach as I was too dumb to use the LEGO PUp color and distance sensor (#88007) to simply sense light on/off.

Spoiler

It just occurred to me how "isolated" PUp devices are from the rest of the LEGO electronic world … no simple dark/medium/bright light sensor, no touch sensor, no – nothing to connect …

“Though I've flown one hundred thousand miles
I'm feeling very still
And before too long I know it's time to go”
Space Oddity – David Bowie

The TC and PUp brains are thus synchronized via an opto-coupler (4N28, already referenced in this book from 1983, we have to keep it straight on the vintage front ;) http://www.bitsavers.org/components/motorola/_dataBooks/1983_Motorola_Optoelectronics_Device_Data.pdf) hooked up to the ESP32 board, in accord with the interface A electronic layout philosophy, which also uses opto-couplers (2x LTV 487 M; 4 couplers in each chip) for separating the circuitry of the control computer/interface card from the power lines of the interface A.

In my setup, one of the 3 motor outputs of the interface A is wired via a bridge rectifier (because forward and reverse need to be sensed) and a 470 Ohm resistor to the photo diode of the 4N28. The photo transistor goes low when the diode is turned on; thus the corresponding ESP32 input is tied to VCC(+3.3V) via a 1kOhm resistor. This little PANT board (I made that PANT thing up of course, Arduino’s have SHIELDS, Pi’s have HATs …) is riding directly on the pins of the ESP board:

Total cost here, including the ESP board, is about $15. I used 4.5V wires (#766c96) with 2prong connectors, took off one connector and soldered Dupont connectors to the bare wires, which attach to the corresponding pins on the PANT board (interface A <=> ESP32 connection). See below for some programming hints on that; essentially, the ESP notices even the shortest low-level pulses on its inputs; I simply very briefly turns on/off the corresponding interface A output, so that neither a motor nor a 4.5 light bulb (visibly) notice that at all, but the ESP does. Well the ESP is more than 30 years younger than the other old farts :D

The computer running QuickBasic 4.5 (or QBasic 1.1) or TC Logo controls the LEGO interface A. The interface in turn “controls” the LEGO PoweredUp Technic hub. Well, not exactly true: It signals the state of one of its outputs to the ESP32, which runs Cornelius Munz’ simply wonderful Legoino (https://github.com/corneliusmunz/legoino) software, which then provides bidirectional access to PUp devices, i.e., the Technic hub and the PUp remote. The PUp remote is only used for moving the trolley into its starting position and then telling the hub to listen to what the ESP is telling it to do. It can also be used to simulate light events etc. A note on the PUp environment: The tacho motor has a very high rotational resolution on the built-in encoders – way more than the TC encoders, but the principle is exactly the same: With the TC elements, you actually learn how that works; with PUp it is an icon in the app – or some code in Legoino. Nevertheless, the high precision, along with the built-in ramping routine, the speed is going up/down in a very controlled fashion, and results in absolute smooth trolley motion.

Software

Computer hardware controlling the interface A may be a modern Win11 machine, a semi-vintage machine running Win98 or the like, or a true vintage machine, e.g., an IBM XT, I am using frequently for such experiments. This >35 years range of computers smoothly operating the interface A became possible after Alex paved the road by partly disassembling the original TC Logo software from 1986-89 for PC’s running DOS and creating two new versions: One that does I/O via the parallel port LPT1 (TCLogo_p) and one that does I/O via the serial port COM1 (TCLogo_s). Both DOS executables are provided on his Bricksafe pages (https://bricksafe.com/pages/alexGSofNZ/interface-a-tc-logo). The original TC Logo for IBM PCs running DOS uses a LEGO parallel interface ISA card (#9771) with its own address for I/O. In this EB thread, there is a little documentation on the efforts of Alex and me regarding running TCLogo on modern computers:

 

Why all these efforts?

Simply because people like Alex and Evan and most probably many others like to run original vintage LEGO electronic hardware with the original LEGO vintage software. That’s all there is. Running the software alone on a modern computer is not an issue; there are many (DOS) emulators out there, some tailored towards playing original vintage games, others to actually mimic the functionality of a vintage computer. However, modern PCs/laptops don’t have any “true” serial (RS232) or parallel ports anymore – they do almost everything via USB. Nor do they have any means of providing 8-bit ISA bus functionality – at least not at an affordable price – if at all.

Spoiler

The LEGO interface A though is essentially an 8-bit parallel device: It has 6 input lines (for operating up-to 6 lamps and/or motors) and 2 output lines providing the logical state of the 2 sensor ports of the interface (TC touch and opto sensors). The original LEGO ISA card #9771 for PC’s is basically a very cheap version of a parallel card for digital I/O and the like. There is a corresponding card for Apple II computers as well and there are corresponding LEGO cables for C64/128, BBC Micros, and many more; the latter either provide a parallel port type output or access to the data/address bus of the computer. There is also an extremely nicely done and comprehensive documentation to be found on Evan’s webpage “Brickhacks” (http://www.brickhacks.com/).

I am focused on the IBM XT though, as this was my dream computer back in the days – and still is. To this end, if you want to use TC Logo to operate the LEGO interface A, you had to use a vintage PC featuring ISA slots, an Apple II, a BBC Micro, or a C64/128, or other cool 8-bit machines. Then Evan figured out how to operate the Interface A from a parallel port using custom software. Also, Tom has done that. Alex mastered it. And I am sure there are others as well. Still, you need a semi-vintage computer with a parallel port for that purpose.

It is pointed out that the original TC Logo software Alex and Evan are preferring for very good reasons, features fully fledged PWM control of the 6 output lines. The PWM base clock is 1 kHz – this is how fast the 6 outputs are switched on/off (in parallel) via the IN/OUT processor instructions. The actual full PWM duty cycle on each output is 8x1 ms = 125 Hz. Alex’ TC Logo_p flawlessly runs PWM on a computer with a parallel port. Alex’ TC Logo's almost runs PWM flawlessly within DOSBox-X on a Win 11 machine; there is a little glitch (barely noticeable) in the PWM timing, cf. (updated irregularly):

 

I am pursuing another route: I want to run QuickBasic 4.5 / QBasic 1.1 in an emulator environment, and write my own BASIC code on a Win11 machine. Then transfer the program to the XT and run the robot arm from that computer. The DOSBox-X emulator is perfectly suited for this task, as it also provides access to COM ports on the host computer (laptop) as per configuration file:

serial1 = directserial realport:COM1

COM ports are “created” using e.g. an USB2Serial or USB2TTL adapter; they are showing up as such in device manager. Why not using the XT directly for program development? For one, an XT with 256 kByte memory cannot run QuickBasic 4.5 but surely compiled QuickBasic com/exe files. QBasic 1.1 in turn runs on a 256kByte XT, but cannot compile files; it runs them directly. Furthermore, a laptop is mobile, an XT is not. A modern laptop is quite fast – an XT is not. A modern laptop has a flicker free display, an XT has not … yeah, we got “softer” over the years … and older for sure …

The last thing required to operate interface A is a fast enough serial to parallel “converter” to operate interface A through an USB channel into DOSBox-X and further into QuickBasic. This is a very simple task for any Arduino device; even an Arduino Nano can do that. I made such an “interface”: Serial to 8bit parallel, 6 output, 2 input lines, as shown again here:

And finally the program codes, most probably full of bugs, but they run smoothly so far; my Bricksafe page is here: https://bricksafe.com/pages/Toastie; direct download links:

• QuickBasic 4.5/QBasic 1.1 program (9750 control/robot arm program): https://bricksafe.com/files/Toastie/lego-interface-a---9750---9771---tclogo/tc-meets-pup/Q9750_9.BAS
• Legoino (C++) source code for the trolley (Technic hub + tacho motor + PUp remote): https://bricksafe.com/files/Toastie/lego-interface-a---9750---9771---tclogo/tc-meets-pup/DactaArm_V2.ino
• Arduino Nano serial to parallel code (C++): https://bricksafe.com/files/Toastie/lego-interface-a---9750---9771---tclogo/program-files-/9750_Parallel2Serial_Interface.ino

I am very happy to provide more info on the programs, but I guess I am the only one doing this weird stuff in BASIC … and I just keep it here for future reference. Updates will also go here.

All the best,

Thorsten

Edited May 24, 2023 by Toastie

[BatteryPoweredBricks]

A new video from Thorsten in my YT subscription box?  What a treat!  Sadly I'm on my way out for work so I haven't had time to read through the details.  I'm sure you know I am a huge fan of combining new and old Lego electronics, although I tend to draw the line at the DACTA 9v serial interface.  Looking forward to diving into the details!

Note: I wouldn't worry about setting the video "for kids", in case anyone who does come across the video wants to comment

[Toastie]

Hi Brian,

oh yes, I know that you are a huge fan of combining new and old LEGO - I am following very closely what you are posting - of course. And I love it. Well, you know that as well

7 hours ago, BatteryPoweredBricks said:

I wouldn't worry about setting the video "for kids"

Just changed that back - I was sort of scared when YT (also via other channels) said - was it years ago? - something to the effect of "you will perish in hell, when you don't change your content to 'for kids' ". At least this is what I understood ... well nothing like that happened when I changed it back ... so thank you very much for that tip!

And many thanks for your kind words, as always!

All the best,
Thorsten 

[BatteryPoweredBricks]

Awesome stuff!  I love the idea of using a bridge rectifier on the interface A output to control an opto-coupler.  I was wondering where this mysterious 4th output was coming from .  The hardware I can follow pretty well, where you guys go way over my head, is in the software department.  Still, a fascinating read!  Maybe one day I'll get back around to playing with my Interface A's, for now it's all trains all the time... for the time being

2 hours ago, Toastie said:

Just changed that back - I was sort of scared when YT (also via other channels) said - was it years ago? - something to the effect of "you will perish in hell, when you don't change your content to 'for kids' ". At least this is what I understood ... well nothing like that happened when I changed it back ... so thank you very much for that tip!

Most Lego channels I interact with have not been setting their channels / videos as made for kids.  I think there was a lot of over-reacting by all parties a few years ago.  Including YouTube themselves.  I guess it could still be an issue for some larger creators depending on their style of content but I wouldn't worry about it in your case.  If for some reason it does become a major issue again, rest assured your subscription box will be full of videos like "It's all over (again)!  I'm going into hiding before they find me!"

[evank]

Here's the latest video of my giant V8 engine, controlled by guess which computer system. :)

https://youtu.be/F-x7YFMWnBQ

 

[Toastie]

3 hours ago, evank said:

controlled by guess which computer system

Wait, wait ... "is it a star?" (Ghostbusters - of course )

Now, there are two interface A boxes - I assume there are two "9767" cards in that Apple clone, is this correct? Or are you using some custom solution?

BTW, I found 3 Atari STFM 1024 in the "basement" - one is in very good condition and is about getting a fitting Gotek drive. Played with the Hatari Atari emulator - there is no reason, not having a real Atari controlling any kind of "robot" with interface A attached to the parallel port ...

I simply love your project. For one, it is the engine itself; then there is all that functionality, most importantly for me though is the real life implementation of so many things happening in a real combustion engine of that make. And of course, the real deal computer brain ... simply perfect!

All the best,
Thorsten   

[evank]

It's a Laser 128. It has one card slot, with a replica doubler card from A2heaven.com. There is one real 9767 card and a homemade replica card by Jonathan Chapman a.k.a. "Glitch" in the retrocomputing hobby. I programmed it in Applesoft BASIC. 

[vergogneless]

I strongly salute the project, even though it completely surpasses me !

[MangaNOID]

4 hours ago, vergogneless said:

I strongly salute the project, even though it completely surpasses me !

I was trying to find some words and yours sums it up for me too 😅