The names Interface A, Interface B, and Interface C suggest a simple sequence. They sound like three versions of one idea, each replacing the one before it. That interpretation is understandable, but it hides the more interesting engineering story. These systems were created for different purposes, in different technical eras, and with different assumptions about what a controller should do. Interface A and Interface B are primarily general-purpose input/output interfaces connected to computers. Interface C is a modern motor-speed controller designed around LEGO Power Functions. The shared word “interface” describes a family resemblance, not a continuous product lineage.

• For Interface A, the central question is whether a computer interface built around an obsolete expansion bus can still be used today.
• For Interface B, the question is whether several old control systems can be brought into one modern software environment.
• For Interface C, the question is what a familiar speed controller should become when the motor system, manufacturing methods, and user expectations have all changed.

Looking at the three together reveals three different forms of modernization: preservation, interoperability, and redesign.

Three Interfaces, Three Different Jobs

The original Interface A system is associated with the LEGO 9750 and the 9771 PC interface card. Its control model is digital and general purpose. The 9750 provides six outputs and two inputs, while the 9771 card connects the interface to a computer expansion bus. Software running on the computer reads and writes hardware ports, and those operations ultimately change the state of the external interface. There is very little abstraction between the program and the electronics. The computer must know which address to use, when to latch an output, and how to interpret an input.

That direct relationship is efficient in its original environment, but it creates a serious problem when the environment disappears. Modern computers do not have the same expansion bus. Even when a compatible physical adapter exists, the original software may still attempt to access an address that no longer exists. Replacing a cable is therefore not enough. The entire path between software, operating system, bus, and external hardware has to be reconstructed.

Interface B has a different architecture. It uses serial communication rather than a parallel bus interface, and it provides a larger set of general-purpose connections: eight outputs and eight inputs. A serial link is not automatically easier to use, but it changes the problem. Instead of asking a PC to manipulate a set of hardware registers directly, a program sends commands over a communication channel. The controller or an intermediate device interprets those commands and changes the outputs. Inputs return through a similar path.

This architecture makes Interface B interesting as more than a vintage device. It can become a node in a larger system. A computer, microcontroller, or browser can address it through a serial port, and software can wrap the low-level protocol in functions, objects, or visual programming blocks. The device still behaves like the original hardware, but the user no longer has to think about every byte on the wire.

Interface C begins from a different premise. It is not designed as a general-purpose input/output interface. Its primary target is LEGO Power Functions motors, and its most important job is to drive one motor channel with repeatable speed and direction control. The design includes a rotary dial, an OLED display, Wi-Fi and browser-based control, a desktop utility, USB-C flashing and diagnostics, and an open enclosure design. Later firmware adds motor-status reporting and a serial command for setting motor speed.

The initial Interface C design does not provide the broad sensor and output array of Interface A or Interface B. It is closer to a smart motor controller than to a general control interface. A Christmas train layout, a Technic mechanism, a Great Ball Contraption, and a custom motorized model all need reliable motor control, but they do not all need the same number of digital inputs and outputs.

Interface A: Reviving a Computer Interface

The Hardware Dependency

The Interface A story begins with a hardware dependency. The original system expects a computer with a compatible expansion card and an operating environment that allows direct access to hardware ports. The external interface is comparatively simple, but the computer side is tied to a specific generation of hardware and software. Once those machines become difficult to maintain, the interface may still work while the system around it no longer does.

Serial Bridges and Software Compatibility

The most practical modernization strategy is to replace the old bus connection with a serial or parallel bridge. A microcontroller can receive a serial command, convert it into the correct combination of output states, and present those states to the Interface A connector. Inputs travel in the opposite direction. The first working versions of this idea were deliberately modest: a small microcontroller, a serial adapter, a handful of wires, and LED kits that made the state of each line visible. The value of the LEDs should not be underestimated. They turn an invisible protocol into a testable electrical condition and make troubleshooting far easier.

Original control programs were written to talk to the old card, not to a serial port in software side.

Both approaches require a detailed understanding of the original program and the timing of the hardware. A connection that works for a simple output test may fail when inputs are polled, when several outputs change at once, or when a program expects a response within a narrow time window.

That is why successful projects tend to combine three layers.

1. The first layer is electrical: correct voltage levels, grounds, pin mapping, and protection.
2. The second is protocol: command formats, handshaking, timing, and error handling.
3. The third is software: patching the original program, creating a new driver, or providing a modern application that emulates the behavior the old program expects.

A project is not truly complete when the first motor moves. It is complete when repeatable programs can read inputs, drive outputs, recover from errors, and run on a machine that can still be maintained.

Results and Platform Portability

The results are substantial. Serial-to-parallel adapters have allowed original control software to operate Interface A without the old expansion card. Modified programs have run through serial and printer ports, and DOS-based software has been used in modern emulated environments. The work has also expanded beyond a single computer platform. Technical experiments have considered vintage systems such as IBM PCs, MSX computers, Commodore machines, Apple systems, BBC Micro computers, and several European school computers. Each platform brings a different port, timing model, and programming environment, so the interface becomes a lesson in portability rather than a single fixed solution.

One ambitious concept considered using sixteen legacy controller cards together, which would theoretically expose 96 motor outputs and 32 sensor inputs. That figure is not a normal product specification. It is a demonstration of what a general-purpose I/O architecture can become when the host software and communication layer are designed for expansion. The important engineering lesson is that the original hardware may be limited, but the system around it need not remain limited.

Preserving Software and Documentation

Interface A also raises a preservation question that cannot be answered by electronics alone. Old manuals, disk images, programming examples, language versions, and teaching materials are part of the system. A working adapter that cannot run the original educational software preserves only part of the experience. The strongest modernization work therefore recovers both the electrical behavior and the software culture that gave the hardware meaning.

Interface B: From a Serial I/O Box to a Programmable Device Node

From Bus Recovery to Software Abstraction

Interface B shifts the focus from bus recovery to interoperability. Its serial architecture makes it easier to connect to a modern computer, but the greater opportunity is software abstraction. A serial protocol can be wrapped in a library, a service, or a visual programming environment. Once that happens, the user can think in terms of inputs, outputs, timers, loops, and motor commands instead of raw bytes.

Interface B and the RCX

Early work in this direction used scripting languages and serial adapters to communicate with Interface B and other legacy controllers. The comparison with the RCX is especially useful. In the documented testing, Interface B could respond in roughly 25 milliseconds, while remote RCX commands involved a delay closer to 100 milliseconds. Both values are small in everyday use, but the difference matters in automation. A mechanism that needs to stop near a position, react to a sensor, or coordinate several actions will behave differently when the control loop is four times slower. The lesson is that “supported” and “suitable for the task” are not the same claim.

One Programming Model for Multiple Devices

The next step was to bring multiple devices into one programming model. The RCX can run autonomous programs, while Interface B can provide faster and more direct I/O. Instead of treating them as competitors, a software layer can let each do what it does best. A sensor event on one device can trigger an action on another. A computer can monitor both, log activity, or coordinate a larger sequence. Communication becomes a form of translation rather than a simple cable connection.

Browser-Based Block Programming

This is where browser-based block programming becomes relevant. A visual editor can expose device functions as blocks for reading an input, setting an output, waiting for a condition, repeating a sequence, or changing motor behavior. Under the surface, the editor still has to manage serial ports, device names, command timing, errors, and reconnection. The visual simplicity is real, but it depends on a substantial amount of hidden engineering. When several interfaces are connected, the software must distinguish them, preserve their assignments, handle a disconnected device without breaking the entire program, and make the state of each device visible to the user.

Hardware Adapters and Sensor Behavior

The hardware layer is equally varied. USB-to-serial adapters, microcontroller gateways, Bluetooth-to-serial adapters, shift registers, and ESP32-based devices have all appeared in this technical space. Each choice changes the failure modes. A USB adapter may be sensitive to driver quality or operating-system power management. A microcontroller can add autonomy but may also become the place where all hardware-specific logic is hidden. A browser can remove the need for a desktop installation, but browser support, permissions, and serial-port access vary by platform. The more convenient the top layer becomes, the more important it is to understand the layers below it.

Sensors add another practical difficulty. Touch sensors are not ideal binary switches. Their internal resistance can vary, and aging can change the threshold at which a controller interprets a press. Reliable designs therefore need calibration, filtering, or at least a clear way to inspect raw values. The same principle applies to motor outputs. A command that appears correct in a short test may produce different results under load, at a different voltage, or after the driver circuit has warmed up.

Authenticity and the Programmable Node

Around authenticity is also significant. Some users want an old computer and the original software experience. Others want to keep the old mechanical hardware but replace the computer with a modern microcontroller. A third group wants a browser-based programming environment that hides nearly all hardware details. None of these goals answer different questions about preservation and use. A useful design makes the boundary explicit: which parts are original, which parts are emulated, and which parts have been replaced by modern technology.

The Interface B device stops being only a box with eight outputs and eight inputs. It becomes a programmable node that can participate in a larger system. That shift is more significant than adding another adapter, because it changes how users describe and combine their hardware. The old interface remains valuable not because it can imitate a modern device, but because a well-designed software layer can expose its strengths without requiring the user to reproduce the entire computer environment of the past.

Interface C: Modern Motor Control

Interface C is built around a different control chain. The user provides an input through a rotary dial, a web interface, or a serial command. Firmware processes that input. A power stage drives a MOC PF motor. Feedback appears on an OLED display, in status messages, or through software. It combines several engineering domains: embedded software, motor drive electronics, networking, human-interface design, and long-term firmware maintenance.

Repeatable Discrete Speed Settings

The rotary dial offers six speed settings in forward and reverse. Six discrete steps may appear less flexible than continuous control, but discrete settings have an important advantage: they are repeatable. A holiday train can return to the same low speed. A mechanism can be tested at a known operating point. A Great Ball Contraption can run for long periods at a setting that has been verified under load. A display and a physical reference point also reduce ambiguity. The user can see the selected state instead of guessing where an analog control has been left.

Display, Feedback, and Firmware

The display and browser interface close part of the control loop. The user changes a setting, the controller processes it, the motor responds, and the display confirms the result. Firmware version 1.0.2 added motor-status broadcasting and a serial command for setting motor speed from -6 to +6. Those features do not change the basic job of driving a motor, but they make the controller easier to integrate into automated tests, custom software, and diagnostic workflows. The inclusion of performance improvements and bug fixes is equally important. A modern controller is not a finished electrical circuit; it is a small computing system with a software life cycle.

Software Dependencies and Complexity

That distinction separates Interface C from a classic speed regulator. A traditional controller may be understandable without any software. A modern controller offers remote operation, configuration, status reporting, and updates, but it also creates dependencies on firmware, utilities, network behavior, and compatible power supplies. The benefit is flexibility. The cost is complexity, and that cost must be managed deliberately.

Engineering Boundaries and Trade-Offs

Interface C does not restore an old bus or unify several legacy protocols. It asks what a familiar control function should look like when the user expects a display, network access, firmware updates, and a customizable enclosure.

Three Paths Compared

The three systems can be compared most clearly by their primary engineering objective.

A simple hardware comparison would miss the point. Interface A is difficult because its software assumes a particular bus. Interface B is difficult because it must coordinate devices that do not share one native protocol. Interface C is difficult because a modern product has to balance power, usability, updates, and future expansion. Each system demonstrates a different layer of compatibility.

Compatibility Is More Than a Connector

A connector can make two devices fit together, but it cannot guarantee that they will work correctly. Compatibility includes voltage, current, ground reference, signal polarity, timing, protocol, buffering, and the behavior of the software that sends or receives data. An adapter may pass a simple test and still fail when the controller changes several outputs at once, reads an input during a precise interval, or operates for several hours under load.

Openness, Repair, and the Life Cycle of a Controller

Education, Hobby Use, and the Meaning of Modernization

Interface A and Interface B belong to an era when LEGO control was closely connected to classroom programming. Logo, BASIC, and structured control exercises taught students how to translate a sequence of instructions into physical behavior. A motor turning was not the whole lesson. The lesson included planning, testing, debugging, and understanding why a mechanism behaved differently from the program's assumptions.

Modern hobby use is broader. A train AFOLs may care about smooth low-speed operation and precise station stops. A Technic builder may care about rapid direction changes. A Great Ball Contraption builder may care about continuous operation and repeatability. A custom model may combine all of these requirements. Interface C speaks to this environment by concentrating on motor control, local feedback, and remote operation rather than on a large general-purpose I/O array.

“Modernization” can mean several different things. It can mean running old software on a new computer. It can mean replacing an obsolete bus with a serial adapter. It can mean hiding a legacy protocol behind a modern programming interface. It can also mean designing a new controller that does not use the old electrical system at all.

They preserve the parts that matter to the user, replace the parts that have become impractical, and explain the boundary between the two.

• A patched program that still behaves like the original has preserved more than a new program that merely produces similar motor movement.
• A modern graphical environment that exposes the same inputs and outputs has preserved the logic of the hardware while changing the programming experience.
• A redesigned controller has preserved the familiar role of a speed regulator while changing everything else.

FAQs: What Comes Next

Q: What technical limitations still affect Interface A and Interface B?

Both can be extended to more computers and devices, but each additional platform introduces timing and portability problems. Better software abstractions can make them easier to use, provided they remain honest about latency, errors, and unsupported behavior. A graphical interface only helps when it gives the user enough information to understand what the hardware is doing.

Q: What practical questions remain for Interface C?

Sensor inputs need more than connectors: protection, configuration, and firmware logic are also required. Powered Up support would require a digital protocol layer and careful power management. USB-C Power Delivery could simplify the power supply but complicate the separation between data and power. A less expensive Mini version could broaden access, but only by changing the balance among motor capacity, usability, and expansion.

Q: How much of the original behavior should be preserved, and how much should be replaced?

There is no universal answer. A Lego collector may value the original computer and software. A builder may value a modern interface that makes a mechanism easier to operate. An educator may value a system that teaches the same control concepts without obsolete hardware. A repair-focused user may value open documentation more than any particular feature.

Q: What measurable requirements should be used to evaluate these choices?

Consider the available voltage, required current, number of motors operating at once, acceptable heat, required response time, sensors that must be read, and behavior after a power interruption or communication error. The device should also be evaluated for repair, update, and replacement.

Conclusion: Three Questions, Not Three Generations

• Interface A asks whether an old computer-controlled system can survive after its original bus has disappeared.
• Interface B asks whether several generations of hardware can be brought into one programmable environment.
• Interface C asks what a familiar motor-control function should become when modern electronics, networking, and software maintenance are available.

Those questions do not form a straight line. Interface A is an exercise in preservation and reverse engineering. Interface B is an exercise in interoperability and abstraction. Interface C is an exercise in product redesign and trade-off management. Together, they show that the history of LEGO control is not simply a story of replacing old products with newer ones.

The more interesting story is about the layers that make control possible: the electrical connection, the communication protocol, the software model, the user interface, and the knowledge required to maintain the system. A controller can be modern in one layer and outdated in another. It can preserve the past while changing almost everything around it. The real value of Interface A, Interface B, and Interface C is that each one exposes a different part of that relationship.

The names may suggest a sequence, but the engineering suggests a conversation. Interface A keeps the past connected. Interface B makes different systems speak to one another. Interface C reimagines control for a new generation of motors and users.