JAVA control class for DACTA 70909

The LEGO DACTA 70909 controller has 8 outputs and 8 inputs that can be controlled from a PC via the serial port.

Image of the Dacta 70909. It's a big lego brick with 8 inputs and 8 outputs. All connectors are old 80ies style lego wire connectors.

As a part of my thesis in computer science that I did in 2006, I coded a JAVA class that can control the box. It also comes with a some example code that will enable you to control the box.

Since the box is quite old (from 1992 or something) it is practically impossible to find anything on the WWW about it and all software etc. that followed the thing seems to be lost forever. You can never have too many in and outputs when doing something in robotics, so even though old it is still a nice piece of hardware that can still be used for many purposes.

As a part of my thesis in computer science that I did in 2006, I coded a JAVA class that can control the box. It also comes with a some example code that will enable you to control the box.

Image of the JAVA controller GUI. It shows a number for each of the 8 inputs. It has ON/OFF switches for the 8 outputs, and sliders that can set the motor speed.

The pages about this project seems to be visited quite often, so I decided to keep the page even though I hardly remember anything about how this thing works.

I don't have one of these units myself so I cannot update the code, or write a newer version. The code relies on JAVA communications API, which seems to still exist, but has probably been changed a lot since 2006.

However these downloads can get you started, and you should be able to create your own.

A zip file with the JAVA source code. (The zip file includes the controller, an example and basic documentation.)

A pdf describing how the box works in detail.

I’d like to thank Anders Isaksson, who had left some well hidden notes on the internet with some information about the protocol etc. (2021-01-28: None of these exist today.)

Several people commented during the years on my old page, about how to get things working.

2011-10-05: Bob writes that the Java Communications package is nowhere to be found.
We find another project that seems to work:

2011-11-25 - Pengvado:

I have discovered a case in which the actual behavior of my 70909 box disagrees with your documentation:

The pdf says that the first two bytes of an input packet are constant zeros, and the java treats any deviation from that as a desync error.
My box uses byte #1 to acknowledge any output commands processed on the previous clock tick, as a bitmask of which output ports were affected. (Byte #0 really is zero.)
Therefore, I get a desync after each output command, and if I issue an output command on every clock tick then I never get any sensor inputs.

Interesting. There isn’t much info on the 70909 on the net, but the few places that I can find just now, agrees with the two first bytes being zero.

Perhaps your 70909 is a newer revision, and the original LEGO software just never checked the first byte? However it is also perfectly viable that my example, and the others too, simply throws away information when the 70909 returns the byte #1 like yours do, and we never noticed this, because everything worked well on the next frame received. (I assume the next frame has double zeros`?)

If you have byte #1 changing “randomly” all the time, the code in the example will have to be rewritten quite a bit. To detect when a complete block of code have been received you’ll have to look for complete 19 byte frames by checking for zero’s in byte #0 and the correct checksum in the end.

I’d love to hear more about it, also how you made Java talk to serial devices. (I assume you’re not using the old Java Communications package.)


> I assume the next frame has double zeros?

Your proposed solution sounds right. But note that fixing the header check is independent of reducing resync latency. If you don’t mind a resync taking 0.4s (like it currently does), then the checksum is already available, so you can just not look at byte #1.
I can’t test any change to resync latency, because my box never drops data, so (once I made it not look at byte #1) it would work even without any resync support at all.

> how you made Java talk to serial devices.
Your suggestions to bob worked perfectly.

Updated source tree, including my header patch, and the 1-line rxtx patch, and updated the readme to include rxtx:

2013-04-13 Darryl:
Just a quick note to say thanks for the original code. I used it as part of an application I built several years ago to control multiple controllers. Just refactored it to work on Windows 7(64-bit) and created a github repository for it. You can find it at