LEGO Control Center II: Remote control and program download

[Toastie]

Dear All,

still making headlines all across the country, LEGO’s Technic Control set #9771 (ISA card for IBM XT along with a 20 ribbon cable, from 1986) is at it again – this time at the famous dance club “The Rose” … no – wait ... (Who you gonna call?)

Executive summary:

1. Added external computer control for accessing LEGO Technic Control Center II set #8485, without compromising its built-in keyboard functionality, button motor control and manual programming.
2. Programs can be uploaded to LEGO Control Center II using BASIC or any other programming language on 8-bit (or the like) computers of the 1980’s (external program storage) – and on any emulator on modern machines with an interface providing 6(8) bit parallel output port.
3. Only vintage hardware is used (1980’s), fully compatible with LEGO’s DACTA Technic Control 4.5V robotics line from 1986 (PC ISA card #9771 or equivalents)

Figure 1: LEGO Control Center II (left) and LEGO Train Speed Regulator (right), the latter only used as enclosure for my little hardware addition, see below

After that stupid intro, allow me to start over: One of my favorite LEGO Technic sets is Technic Control Center II, #8485, from 1995. The dinosaur simply blew my mind – it is both a brilliant Technic set as well as a wonderful display model. I took it apart about 10 years ago, as most of the flex cables had become brittle and simply snapped where they were exposed to light over the years. Around 1999, I hauled the box from Germany to the US (as my XMas "present"), where we lived for some years; Southern California’s sun was apparently too tough for the flex cables, I guess. Yes, you can replace these, but I did not know then. The actual Control Center II controller (I call it LCC II from now on, and believe this is part #2840c02?) itself is a follow-up of Control Center I, part #2840c01(?) – the only noticeable difference being an additional AC/DC plug for the former (yes, it says 9 – 12V AC, but - naturally - it works with up-to 15V DC without any harm; it lies in the nature of bridge rectifiers and classic voltage regulators). And the 9V electrical outputs are differently color coded; on LCC I it is blue-yellow-red, on LCC II it is red-yellow-yellow, from left to right.

Spoiler

 

Over the past two years, I really got into vintage LEGO electronics. It is all Evan’s (@evanks) fault, so don’t blame me, when I keep opening these weird threads … I like challenges, particularly when old digital electronics is involved. In the 1980s, I deep-dived into the 8-bit world of computers, the cheap ones, that is. Along with that came another deep-dive on TTL logic. And now, about 40 years later, it starts all over again. Well, the reason is that there were some events that recently happened coincidentally: I found a myriad of 1980s TTL and computer chips in a “storage room” of my research group along with some vintage computers (IBM XT, Atari ST’s, C64); I still have my ZX81 and ZX Spectrum from back then, and got recently hold of an Amstrad PCW 9512 “Joyce” (on which I wrote my diploma thesis back in 1987), and so forth, I have posted this stuff here on EB too many times, I guess. For all these machines, I made custom interfaces for the LEGO Interface A, #9750, from 1986, in reply to Evan’s challenge. There you go. I call these interfaces “#9771 equivalents”, as they behave in the exact same way: 6 parallel output, and 2 input ports. Access from e.g. BASIC is via the OUT command – which writes 6 bits into TTL latches connected to LEGO Interface A, and the IN(P) function, which reads all 8 (latched) bits from #9771. The LEGO Interface A drives up-to six 4.5V devices, such as motors and lamps, in an on-off fashion, or up-to 3 motors with forward/reverse control. Lastly, I also made an Arduino Nano based interface, which allows me to mimic 8-bit parallel access to #9750 via a USB port of any modern computer. This in turn opens up the world of emulators for running tons of ancient software, such as QBASIC (DOS, PC), GFA-BASIC (TOS, Atari), and so on and so forth … When I'm done with rather comfortable programming on my Win11 Laptop using such an emulator, I transfer the programs to the old machines (Gotek’s and the like are your friends …) and play with them. OK, enough bragging … I have earned bragging rights though, see here: https://www.brickhacks.com/2.php

 

Manual programming of LEGO Control Center II (as it comes out of the box)

What I found out is maybe not entirely documented, at least I could not find such detailed information on the behavior of LCC II regarding its programming. So the following is probably very well known to many of you guys. I apologize for not referencing that information, just let me know, and I will edit this post accordingly!

The LCC II keyboard consists of 12 keys: N, S, W, E, A, and B, corresponding to motor A forward (AF), motor A reverse (AR), motor B forward (BF), motor B reverse (BR), motor C forward (CF), motor C reverse (CR), in addition to the following combinations: NE (AF + BF), SE (AR + BF), SW (AR + BR), and NW (AF + BR). Then there are the keys STOP (ST), PAUSE (PA), PLAY, ON-OFF, PROGRAM 1/2, RECORD.

Programming LCC II is done – what a surprise – using its buttons = keyboard. In programming mode, LCC II records individual button actions (or “events”). An LCC II event is represented by

1. a change of any motor status (from off to on, and from on to off);
2. tapping the PAUSE button (off-on-off);
3. tapping the STOP button (off-on-off);

Upon throwing an event, LCC II records the nature of the change as well as a corresponding timestamp.

There is one exception: When all motors are off, and then one motor is turned on for some time, then turned off and after a delay turned on again, the delay timestamps are not recorded; the motor spins continuously for the added times without stopping inbetween. If one wants to record “all motors off” delays, the PAUSE function has to be used.

The PAUSE function is operating in two different ways:

1. Record a defined delay when all motors are off. This is done by tapping the PAUSE button once (timestamp recorded upon off-on change of PAUSE button, PAUSE LED turns on) and then tapping again, when the delay is over (PAUSE LED goes off). When you then don’t press any button for some (delay) time, this is not recorded; only another event, e.g., turning on a motor, will create another timestamp.
2. Automatically record all timestamps for all events occurring, even when all motors are off. This function is invoked by a) tapping the PAUSE button anytime during programming, e.g., right at the beginning, as first event (in this case, the PAUSE LED turns on and stays on until any other event occurs), or b) when one or several motors are on. In this case the PAUSE LED remains off as long as any of the motors are on, but the PAUSE function is activated.
   When all motors are off, the PAUSE LED automatically comes on, and all timestamps are properly recorded. This function is turned off again by tapping the PAUSE button a second time during the programming cycle.

(I prefer using the latter function, as all my “delays” during programming, regardless whether motors are on or off, are usually placed intentionally. But: It is up to you!)

What bothered me back then (as it did recently, when I broke out my LCC II for the hundredths or so time – and desperately tried to figure out what the hell to do with it – with no dino around anymore …), was that the LCC II is a “closed” system. Which is exactly what TLG designed it to be: A beautiful, programmable, “self-contained” controller box for three 9V motors. No computer required, two programs can be stored - with a total of 51 programming steps/events (41 max. in one program slot). That is perfectly fine (!) - but not with me. About three weeks ago, I began seriously searching the web for a circuit diagram for LCC II – to no avail. I did find a thread in the (German) “microcontroller.net” forum (https://www.mikrocontroller.net/topic/461564), which deals with an - unfortunately unsuccessful - attempt to fix a broken LCC I, with a focus on the microcontroller. This controller is apparently of the type “mask programmable Motorola 680X microcontroller”. Whatever that line is, I did not find out. In that thread, user “hinz” posted a pinout of this chip, which was very helpful for my interrogation of the PCB of my LCC II, but I still had no diagram ...

Without any diagram available - I had to make one, simple as that (I bet there is such a diagram out there; I am an expert in reinventing the wheel). Or better: a diagram of the “keyboard” layout. Which means: Grabbed my multimeter, put it on beep-beep mode and traced the tiny tracks.

Figure 2: The PCB of LEGO Control Center II; my button numbers (blue sharpie marks) are entirely arbitrary, and just for me. Note the rotten 9V cables ...

And now what? Da plan:

Solder wires in parallel to programming relevant keys, route them to the outside world and use external, computer controlled switches to program/control LCC II.

The LCC II buttons are of the usual “conducting rubber mat” type used anywhere in el-cheapo world: There are two separated but close sections of blobs of conducting material (the black surfaces in Figure 2) for each key on the PCB, which are “closed” by the conducting material applied to the rubber mat representing a button. Now, what if I can solder tiny wires to each of the two button contacts on the PCB, route them to the outside world and close them with relays or the like? Well relays are not exactly 1980’s, they are more 1900’s – but analog CMOS switches, like CD4066 are! Sounded good to me, but when I looked at these tiny “feet” of the MC680X microcontroller, I almost gave up. On that scale, my 0.5 mm soldering iron tip looked like a device for roof repair, rather than for soldering wires to an SMD type microcontroller:

But wait: There is more (there always is): It appears as if each of the LCC II buttons has at least two tiny “test points”, sort of arbitrarily distributed on the PCB’s traces, each represented by a tiny blob of solder. And BINGO! Each “button test point” is traceable to the micro controller’s little feet, and even better, each trace goes to an I/O port, should the pinout of the above referenced MC680X be correct, which I do believe. I copied that pinout into the picture below:

 

Figure 3: Traced lines from buttons to microcontroller

That looked pretty confusing, so I tried the usual stuff, when it comes to multiple button operation: The button contacts are often arranged in “rows and columns” and the microcontroller simply parses these: Raise a column/row to one logic level and see, which row/column responds with the same logic level = key identified. Go on with the next column/row and so on. I arbitrarily assigned the first 5 shared contacts on the MC680X to “columns”, and the 3 other shared contacts to “rows”. This results in the following key matrix:

Figure 4: Traced lines rearranged to columns (C) and rows (R). The numbers correspond to the pin numbers of the microcontroller as shown in Figure 3.

Next step: soldering (tiny) wires to the corresponding (tiny) test points and route them to the outside world.

 

Figure 5: Wires soldered to corresponding button test points. And yes, hot glue is not my thing, but the wires needed to be fixed in place - somehow. Note that the original 9V output wires TLG used, which were also rotting away of course in a closed case, are replaced; compare to Figure 2.

Figure 6: C3PO tapping into the keyboard of LCC II - the 8 ribbon cable connects to the little interface discussed below. White dot = pin 1.

With that, the hard work was done. Now on to making external switches. As mentioned, I tried CD4066 (4 x CMOS analog switches), but that totally failed: It worked for some time, then motors attached to the LCC II outputs began to turn erratically, and then they worked again. I have fought with these ICs for decades now, just to fail again ... CMOS seems to be above my head, lower league TTL is my league. That left me with mechanical relays … and … good old 1980’s opto couplers! These have a “direction”, though, as the internal “switches” are transistors. Well, column/row testing has that direction as well, either H or L is to be sniffed. With my arbitrarily assigned columns/rows it worked, when columns are tied to the collector of the opto coupler transistor, and rows to the emitter (but not the other way around). This resulted in the following schematic:

Figure 7: Circuit diagram of the #9771 to LEGO Control Center II interface. ILQ74 (quadruple optocoupler IC) can be replaced by any single or double optocouplers such as ILD74 or whatever you have at hand. 

Applying 5V to the photo diodes of the corresponding opto coupler via a 1kOhm resistor closes the LCC II button, and leads to the expected response.

Next challenge: There are now 6 "remote" buttons available for motor control: AF, AR, BF, BR, CF, CR. Outputs A and B (the two yellow 9V terminals) are either forward or reverse; both cannot be (mechanically) turned on. Regarding output C (the red 9V terminal) it is different: When button A is pressed and held and then in addition button B and then both are released, motor C remains “on forever” (forward) – until button A or B is pressed again. The same holds true the other way around: Press and hold button B, then in addition A, release both and motor C is “on forever” (reverse). I initially thought that this feature should be kept functional with external control. Well, not required; a computer holds any line up, as long as you want ... Outputs A and B don’t have that feature, which enables two more key actions: If both outputs are externally turned on (N + S or W + E), this case is decoded by a TTL chip, which in turn activates the switches “PAUSE” or “STOP”. So with only 6 “exclusive” button cases in manual control, 8 “program buttons” can be controlled. And that is sufficient to comfortably program LCC II, see below.

Here is how it works:

• The external control interface is a #9771 card or equivalent circuit, providing 6 TTL outputs. Its 2 TTL inputs are tied to ground, so it does no flip out upon collecting electrical noise.
• Bits 4 and 5 are directly routed via 1kOhm resistors to the photodiodes of the opto couplers controlling buttons A and B of the LCC II (= motor C). When bit 4 or 5 is H, the photo transistor in the corresponding ILD 74 opto coupler becomes conductive (“switch closed = button pressed”).
• Bits 0 and 1, as well as 2 and 3 are routed to the A and B inputs of the two 2-to-4 decoders of 74LS139. Their outputs Qn are permanently activated since their inverted enable gates (“/FE”) are tied to ground. The inverted outputs Q1 and Q2 (H=off, L=on) are routed to the opto couplers mimicking the buttons N+S and W+E (motors A+B), respectively. When the inputs A and B of the decoders = H (that would be N+S or W+S=on, which is impossible using the big yellow button on LCC II), then the outputs Q3 are activated, which in turn are used to drive the opto couplers mimicking the buttons “PAUSE” and “STOP”. These are very useful when programming the LCC II, again, see below.

This setup assures, that

• all LCC II buttons remain manually operable (if they are not “closed” externally), so when this little circuit is not powered, LCC II is entirely on its own and works as coming out of the box
• LCC II is electrically completely isolated from the outside world. The power for the little interface comes from #9771 or equivalent, as done in Technic Control world as well.

The other buttons (ON/OFF, RECORD, PROGRAM 1/2, PLAY) could also be controlled by further opto couplers, but #9771 and equivalents only have 6 TTL outputs. I really want to use this original LEGO robotics approach from 1986 for LCC II control. Note that the ON/OFF switch is not part of the keyboard matrix, it connects directly to the reset input of the (speculated) MC680X chip.

Computer controlled programming of LCC II

How to upload a program stored on an computer into the LCC II? Well, connect that computer equipped with #9771 or equivalent to the little interface board (with a 20 ribbon cable), and connect the 8 opto coupler outputs to the “extended” keyboard matrix of LCC II. Turn everything on. The PROGRAM 1 LED of LCC II blinks, indicating “ready for programming” – provided there is no program already stored in that slot. If you want slot 2 for programming, press PROGRAM 1/2 and PROGRAM 2 LED blinks, same as above. If you want to overwrite an existing program stored on LCC II, press and hold the RECORD button until the LED, which is steadily on begins to blink, indicating “recording”. And then run a program on the computer (e.g., written in BASIC) that emits the corresponding “button states” to #9771 and then into the little interface. The last command should be STOP. You can use precisely adjusted PAUSEs, as this key is also remotely controlled, see above. Here is an example written in QBASIC, that builds on my QBASIC code for operating #9750 - and now also #8485! And yes, the sub routines (e.g., LLC.OUT "XY") are somewhat elaborate ...

  LCC.PAUSEF.ON      'turn on PAUSE function - all program delays
                     'are recorded/timestamped
  LCC.OUT "AF"       'A on forward, button A pressed and held down,
                     'timestamped
  Delay 1            '1 sec delay
  LCC.OUT "BF"       'B on forward (A remains on), timestamp recorded
  Delay 1            '
  LCC.OUT "CF"       'C on forward (A+B remain on), timestamp recorded
  Delay 1            '
  LCC.OUT "ASBSCS"   'all outputs off, timestamp recorded
  Delay 2            'with LCC.PAUSEF.ON, this 2 sec delay is
                     'recorded (equivalent to no buttons pressed)
                     'PAUSE LED is on
  LCC.PAUSEF.OFF     'from now on, delays to be recorded must
                     'use LCC.PAUSE, as all motors are off. This is
                     'exactly the same in manual control
  LCC.OUT "AR"       'A on reverse, stimestamped
  Delay 1            '
  LCC.OUT "AS"       'A off, timestamped
  LCC.PAUSE 2        'PAUSE is recorded, although all motors are
                     'off
  LCC.OUT "BF"       'B on forward
  Delay 1            '
  LCC.STOP           'end program download; this also stops all
                     'motors without recording the motor stop
                     'event

Example of a "user program" that runs within my 9750/8485 QBASIC control program. "User program" is just a fancy phrase for a subroutine containing subroutines ^^. Note that the dots are in no way any modern object stuff - QBASIC just does not accept underscores or the like ... but dots ... in a subroutine or variable name. XYZ_NM does not work, but XYZ.NM does. Calling a subroutine in QBASIC is also a bit weird: You need to use "CALL XYZ", when sub XYZ has its arguments placed in brackets: CALL XYZ(PARAM), but you can omit CALL when deleting the brackets: XYZ PARAM.  

I am happy to share any further QBASIC (or whatever BASIC dialect you speak) programs I come up with. Just give me a note.

Note, that when AC/DC power is removed (= hells bells ringing) from LCC II with no batteries inserted, programs 1/2 are immediately lost. Well, from now on, this is no problem at all, as you can upload these programs from any suitable computer

Lastly, I needed to make a case for the little interface board, as usual, that somehow “blends in” with the appearance of LCC II. But all these slopes and angles … so difficult. But wait: There is more, there always is: There is #4548, the “9V train speed regulator” (which does not regulate train speed, but the voltage supplied to the tracks ^^). The outer shape of the enclosures of LCC II and #4548 perfectly match, as if they were designed to marry. I happen to have a couple of the latter, so one got an “upgrade” - there is ample of space inside! Well sort of, my clumsy perfboard layout needs a lot of space as well, it really should have been much smaller. So, the rather big 2000 uF capacitor had to be relocated (these bastards hot-glued it to the PCB, for whatever reason, dang-it!), and about 3 mm of aluminum had to be removed from the heat sink; should not cause any problems, as I will run only one 9V Technic motor from that regulator. It now features two new ports: One for the 20 ribbon cable from #9771 and one 8 line port connecting to LCC II. And yes, on both LCC II and #4548 the 9V cables had to be replaced ... but this procedure is so well documented by Brian, it worked very well.@BatteryPoweredBricks

Figure 8: Lots of space! The 9V train speed regulator enclosure ...

This is the backyard:

Figure 9: Left: #9771 equivalent (Arduino Nano USB to 8 bit parallel converter; center: #4548 as enclosure for my little interface, it does not pay any rent for using #4548's electronics; right: new LCC II port for accessing the buttons used for downloading programs. 

Is this monster enclosure approach reasonable? No, not at all, not for such a tiny board, but it looks good … to me. If the board was made on an actual PCB and the chippies were not socketed, it would easily fit directly into LCC II. But: It would look far less impressive … after all, I have something, I can brag about …

All the best,

Thorsten

Edited September 8 by Toastie

[evank]

>> It is all Evan’s (@evank) fault, so don’t blame, me when I keep opening these weird threads

You're welcome! 

>> I  am happy to share any further QBASIC  (or whatever BASIC dialect you speak ) programs I come up with . Just give me a note

How may we PEEK and POKE it from good old, line-numbered BASIC?

[BatteryPoweredBricks]

Incredible work @Toastie 

You won't see this anywhere else!

[Toastie]

5 hours ago, evank said:

How may we PEEK and POKE it from good old, line-numbered BASIC?

Well, bare metal BASIC, or GOSUBs OK?

Let me guess: Applesoft BASIC?

Best,
Thorsten

[Toastie]

Dear All,

I'll update any of my Microsoft (MS) QBASIC programs related to operating Technic Control (TC) stuff, or any other vintage LEGO interfaces, or anything interesting (to me) in this BrickSafe folder:

https://bricksafe.com/pages/Toastie/qbasic-programs

MS QBASIC programs are 100% compatible to MS QuickBASIC programs, as QBASIC 1.1 (released in 1991) is actually a downgraded version of QuickBASIC 4.5. (final release 1988). QBASIC is solely interpreting BASIC code; QuickBASIC had in addition a compiler with all the bells and whistles and could generate COM/EXE files.

So far, there are only two files:

1. Q9750_10.BAS: Control program for #9750 as well as #8485 using either the UI (user interface) or user programs.
2. QPWM_5.BAS: This is my QBASIC code mimicking the TC PWM (pulse width modulation) approach used in TCLogo.COM in 8086/88 machine code.

Best,
Thorsten

Edited September 5 by Toastie

[evank]

19 hours ago, Toastie said:

Well, bare metal BASIC, or GOSUBs OK?

Let me guess: Applesoft BASIC?

Best,
Thorsten

Applesoft is my favorite, as you know :) but I'm also happy to code on a Commodore 64 or with IBM PC-BASIC.

[BrickTronic]

Hello Thorsten,

Again a great project from you. I like them. Please keep continuing.

But in your Matrix-Picture the "ON" Button should be the "B" Button and Cols C18 to C27 seems mirrored to C27 to C18

The only 680x uC in PLCC28 I could find was the MC6805P2FN (Motorola) or EF6805P2FN (SGS later ST)

For the H-Bridge marked NOD-1001 I could not find a Datasheet.
But this driver seems to be used also in RS232 Interface "B"

Jo

[Toastie]

@BrickTronic

Hello Jo,

thank you very much!!! You are absolutely right - I sketched two versions of this matrix in my scratch book; one with the columns in reverse order ^^ Upon transforming the columns into ascending order in the PowerPoint document - what could possibly go wrong?

I hope I fixed the main post properly - as I said before, I am an expert in screwing such things up. I also replaced figure 3, as "PG" = Program 1/2 was not labeled properly.

And wow, that datasheet of the Motorola MCU - that is a nice chip! Thank you for the link, just downloaded it. Cool.

And I really appreciate your kind words and particularly your deep dive on the content!

All the best,
Thorsten

Edited September 8 by Toastie