maehw

You're right. It's in the ROM code. Seems to be used for checking the firmware image – which resides in RAM after having been successfully transferred via the infrared serial interface. So it also needs to be contained in every firmware image as this check is executed during the "unlock firmware" command.

Hacker voice: "I'm in." (I got a response from my Interface B via serial.)

Yesterday and the day before I was finally able to read the whole thread. My biased summary that no-one asked for: No official schematics of Interface B PCB have been seen in the wild so far. Though, several photos of the PCB exist. A lot of official software and DACTA documentation (or Control Lab books) has been made available via archive.org! (Thanks to everyobody involved! Special thanks to @evank, I guess.) The serial protocol is understood and documented. The Interface B periodically spits out 19 byte long status messages (including a checksum byte). However, it needs to be unlocked with a magic spell first as typical for TLG PBricks (~"Do you byte, when I knock?"). It's important to note that the first two bytes can't assumed to be always 0x00 0x00 (thanks to @Bliss). These bytes encode the statuses of the red stop button as well as ACKnowledgement of turning the outputs on. @Toastie did a deep dive into sensor characteristics and sensor data encoding here - thanks for the nice graphical overview. Again about the serial protocol: baud rate is 9600, configuration 8N1 (8 data bits, no parity bit, 1 stop bit -- very common). It uses RS232 voltage levels and not just TTL — so you need to choose a compatible USB/ serial converter. It also seems that LEGO made its very own special cable so that others needs a NULL modem cable + a gender changer. (That's where I am stuck right now.) RX, TX, GND is enough, no hardware handshake lines are used. Commands to control the outputs so have a different message format. Also, the "PC" needs to send keep-alive message to the Interface B every now and then (seen 0x02 sent every 2 seconds; may work with all op codes with the high nibble being 0x0; read that Toastie has been sending something every 3 seconds only). @Toastie also did a comparison of input port behaviour to both the Interface A and the RCX. Can anyone share their user programs (running in Control Lab or ROBOLAB or LEGO Engineering or any other very popular 3rd party software like TechnoLogica) along with a screenshot and short description? I'd be curious if someone also has reverse engineered the file formats. What are the typical file endings for the programs? Were the files for one application compatible across platforms (e.g. Macintosh and something else)? @evank some day in the past you wrote that you tracked down some of the Lego engineer(s)(?) who helped build the interface and that you had a phone interview with someone who may have led the development of Robolab -- is there something publicly available about these people and your conversation(s)? A lot of DIY software and retro-computing enthusiasm seen here! Nice! Thanks everybody who has contributed to this thread! It was a nice (and long!) read. This also sparked some interest on my side.. if I shouldn't do some more of the make-it-work-in-a-modern-webbrowser stuff as I did with the RCX ("WebPBrick" thingie mentioned above). It's also a serial interface... and I could again use WebSerial in a Chrome-based webbrowser. And a lot of knowledge and source code has been collected and/or linked here. So it should be doable... I don't see the need to plug some Raspberry Pi inbetween the Interface B and a web browser -- except for realtime behaviour, maybe. But the status message rate of 50 Hz might still be doable in a webbrowser these days. Who knows. (Side note about LEGO Lines and the IBM PC: Daniel is from Austria... which is close to Germany but not Germany. I am still in touch and have offered him some RCX hardware in exchange of data from the old disks. However, I didn't find time and stuff to send him (yet) and I don't know if he's open to making the data publicly available.)

True. RCX: WebPBrick: webbrowser-based cross-platform IDE of an RCX in NQC and upload RCX firmware without the hassle to set something up on your own PC, especially no Windows VM; only works with the IR Serial tower so far, the IR USB tower is still not working yet Details in https://github.com/maehw/WebPBrick (its README) WebPBrick's BlockNQC: A web-based visual programming editor called BlockNQC can be used to generate NQC code. — Can be used in the IDE above. Build your own DIY IR tower? Sure: https://github.com/maehw/DiyIrTower (it's the DIY miniature version of a IR Serial tower) (Edit: requires no 9V battery power supply and no D-Sub 9 serial converter cable in the times of USB connectors) Interface A: https://github.com/maehw/BrickLines — run your LEGO Lines program from a Python environment (USB serial/parallel DIY adapter required); supports old file formats (@Toastie: I guess you pinged me about this one some days ago, but I didn't receive an email notification; also I wasn't aware of this thread) Control Lab: Isn't that what this thread (new to me) is actually about? :)) I got one several months ago but didn't find the time and motivation to play around with it. No clue how it works under the hood but I guess that there's a serial protocol. Could be made part of WebPBrick thanks to WebSerial technology. (Edit: my stuff is typically using old TLG hardware peripherals with more modern computers + software; not so much retro... because I am lacking the space, money and knowledge/skill for the old equipment)

Great news I am reading here. However, I'll need more time to really read and answer things here carefully. Especially excited about LEGO Lines for IBM PC. About the RCX: a quick reminder that I've done this thing called WebPBrick (.com + GitHub). Also with a visual IDE (Scratch-alike, i.e. Blockly based) to generate NQC code. And the compiler running in your browser and download the programs via WebSerial and maybe some day also WebUSB. Cheers

On the bottom right corner it reads "verkauft" — German for "sold". I didn't have the budget at that time. That has been sold to Daniel.

Hi all and merry Christmas! Could you please reference the exact post? If it is the ebay one, we'd have to ask Daniel Schmatz because I didn't obtain those newsletters in printed form and the image above very much looks like a photo and not a screenshot. Still in touch with Daniel about the software BTW, so we might get a German version of Lego Lines some day.

Whaaaaat? Finally a LEGO Lines edition for the IBM PC? 🫠 The unobtanium in reach... 👏

Hi @Gunners TekZone, that was indeed also not very clear to me in the beginning, but I found some convincing hints around the interwebs: websites, a book and finally the auction with the mentioned unobtanium @Toastiementioned above. 😅

Yes, unfortunately not really any progress. I've been in touch with Daniel recently. He's expecting some kind of expense allowance to compensate the invested time to save the data from the disks. So maybe we could start throwing together a pile of money. What do yous think?

Hi Thorsten, no worries. I've just re-read the code and slightly modified it: https://github.com/maehw/BrickLines/blob/main/hardware/serial2parallel_converter/arduino_sketch/arduino_sketch.ino Should work the same - just added another bitmask for the status bits. However, I haven't tried this version yet.. so if it turns out not to work as you'd expect, please let me know. The previous version worked fine for me™. And thanks for your original code contribution. Mine is just heavily based on yours, I only remember to have cleaned it up a bit. I do not have an IBM XT here, so I cannot test that but I haven't touched baud rate settings from your code, IIRC. Still having a visit at the Deutsche Nationalbibliothek in my mind to acquire the data from that book diskette... even if it will not give us the LEGO Lines code for IBM PC. I'll ask Daniel if he was successful with the precious disks from LEGO.

Hi everyone. I don't think that any variant of LEGO Lines offers power levels. The UI also only allows zeros and ones (and "don't care" for inputs). So only binary — on or off. Also, I don't think there was a hidden option — for Block Lines I reverse engineered the file formats and the encoding also would not support that.

Hi Evan (and all), I read about your post in my e-mails and got interested so I was planning to help this morning (before seeing your edit). I stumbled across this tool: https://github.com/monkeyman79/dfsimage - and was able to extract the files, too. Actually I was quite surprised that you were expecting BASIC source code files... I'd have expected binary (compiled) executables instead. But that may not be how the BBC Micro worked. Maybe you can enlighten us (me?) here. Honestly, I haven't done any research on my own here but it might be interesting to hear from someone directly who's familiar with systems from back then. Looking at LINES, the file doesn't seem to contain only printable characters (from an UTF-8 perspective) - so I guess there's a bunch of control characters in every line. Looking at TITLE.. at least the very end looks like assembler mnemonics. Again surprised, because why would you ship them in this encoding? Was runtime compilation of assembly a thing?

Thanks for elaborating on the details! Is this actually you(r blog)? https://lukazi.blogspot.com/2014/07/lego-legos-first-programmable-product.html?m=1 — If so, I didn't get it until now. Thanks for sharing the instructions! I am most excited about the robot arm 1090 E), the crane (1092 E) and the plotter (1092 A) models. Thanks for sharing the zip/pdf files. Unfortunately 1092 E seems incomplete. It's really interesting how LEGO had multiple plotter models — interface A, Technic Control Center and also interface B I guess? I had played around with Technic Control Center's plotter model and used it with the RCX earlier this year. Cheers Edit: also thanks to everyone for having good hints about fixing the wobbly cable connections! PS: Thanks for pointing me to the C64 and Apple ][ disk files. I knew about them and had extracted the save files and uploaded them as examples in the git repo. They do work with BRICK Lines out of the box.

Hi all, I am happy to tell you that BRICK Lines works now... also for reading the inputs. I've committed the @Toastie's slightly modified code to the git repo and added the pinout details here: https://github.com/maehw/BrickLines/tree/main/hardware/serial2parallel_converter I've also fixed the always-serial-write-then-serial-read mechanism in BRICK Lines. I can still observe that the first character sent to the Arduino is not properly "echoed". (Actually ASCII capital letters A, B, C, ... make up for a good binary testing patterns as A = 0x41 which is masked to 0x01, B to 0x02 etc). I am not 100% sure if this is due to sending the first character very soon after the serial connection is opened... or this is a platform-specific problem on my macOS machine. However, not a big deal as I've implemented a workaround for this. Thanks for pointing out that the input can be shorted and nothing will light up in magic smoke. This made it easy for me to test the inputs and make a special cable which I can plug in to simulate a touch sensor. This allowed me to load and execute LEGO Lines program BTEST: ┌ IN ───┬ OUT ──────────────────┐ BRICK Lines ├───┬───┼───┬───┬───┬───┬───┬───┤ │ 7 │ 6 │ 5 │ 4 │ 3 │ 2 │ 1 │ 0 │ ┌─ # ──┬─ LABEL ──────┼───┼───┼───┼───┼───┼───┼───┼───┼───────┐ │ 1 │ light │▒▒▒│▒▒▒│ 0 │ 1 │ 0 │ 0 │ 0 │ 0 │ │ │ 2 │ REPEAT │▒▒▒│▒▒▒│ │ │ │ 3 │ UNTIL │▒▒▒│ 1 │ │ │ │ 4 │ open │▒▒▒│▒▒▒│ 0 │ 0 │ 0 │ 0 │ 0 │ 1 │ 2 │ │ 5 │ close │▒▒▒│▒▒▒│ 0 │ 0 │ 0 │ 0 │ 1 │ 0 │ 2 │ └──────┴──────────────┴───┴───┴───┴───┴───┴───┴───┴───┴───────┘ BTW: I also thought about embedding a LEGO Lines program to BASIC code and/or TClogo code converter into BRICK Lines. Let me know if you'd find this useful. :) I think the cable-motor or cable-lamp connections do not work very reliably. It seems that for some cables (or light bricks?) I need to wobble to get a connection. Especially for motors... the vibrations can loosen existing connections. Any helpful hints if this is normal wear-out, has always been like this or something else? Next logical step would be to re-create models for LINES and play around with them. Do you know which instruction manual I'd have to look at (and check if I have those bricks available here)? Can you tell if the instructions for LINES and TClogo used the same models or different ones? PS: I'd be happy to join a call but I'll be at 38C3 congress in Hamburg during the last week of this year.

Thanks for the motivating words, @Toastie! Sounds good, let's give Daniel some more time until February until we start asking how the floppies are doing. That seems to be a good attitude. I am happy to tell that today, I've been able to use my Interface A for the very first time. I've got a DC power supply which does the trick, I've also got an Arduino Nano which still works and some wires. Thanks to your Arduino software and my preparations in BRICK Lines, this was quite a quick starter. (I haven't tried the TC Logo version modified for the serial interface yet. Also no DOSBox-X experiments so far.. I am running BRICK Lines on native Windows, Linux and macOS.) You can find the BRICK Lines software on GitHub: https://github.com/maehw/BrickLines - it's free and open... (MIT license). (It comes with a README.md!) This is where I'd also like to add the Arduino code snippet which does the serial/parallel conversion. As the code is originally yours, I ask you kindly to license it under MIT as well, so that I can add it along with some pinout/hardware wiring info which I added. I also think that the software still has a small bug where I can see issues when applying outputs for the first time. This might not be visible when outputs are set using TC Logo at a rate of 1 kHz but it is in (BRICK) Lines where outputs are only set when specific instructions are executed (all that are not equal to LEGO Lines keywords). I'll try to narrow this down and report with more details. There may also still be a bug in my code and/or wrong assumptions. It already seemed suspicious to me when I tried to talk with the Arduino with a serial terminal and it replied with different characters when I typed in the same character several times... As you may have guessed, I only do have the Interface A (70455, i.e. the later 1987 version) without any cables or interface cards -- only the Arduino Nano as USB-to-parallel-adapter. Sorry, I think I did not make my point clear... or should have rephrased my question. Your code does a `Serial.write()` for every `Serial.read()`. This implies that code running in the machine is always writing outputs before it can read the inputs - because serial is async. This brought up the following questions/assumptions: Does TC Logo write the outputs before it does read the inputs? Always? LEGO BRICK Lines can have instruction that only depend on the inputs (conditions such as `IF` or `UNTIL` or the `COUNT` statement). There's no need in setting the outputs before. Of course, to make this compatible with BRICK Lines, it could adapt the behaviour working with TC Logo and just re-transmit the last-known outputs it has set before to be able to receive the current input levels. (Note: Oops, that's actually what I should have added in the Python code here: https://github.com/maehw/BrickLines/blob/8ba5b78e233419ed867500548f6be82b21c972c7/brick_lines.py#L456 - it seems that I have tested outputs-only programs so far! Probably because I do not have received any sensors so far (neither touch nor opto)! Expected behaviour until I modify the code: the program should get stuck because it's waiting for a receive byte which never comes... and it's a blocking serial receive function.) As this "need to write outputs in order to know the inputs" dependency may be problematic/unintended (see 2), I asked myself if it would also work when the Arduino Nano polled the inputs regularly (or implemented edge detection on the two pins) and sent the data periodically (at the polling rate; or event-based when an edge = level change has been detected). But: this could result in many many bytes being sent from the Arduino to the PC without being read from there... and could overflow a receive buffer until `receive()` is called. But this might not be a problem for "old serial" interfaces which just overwrote a single byte buffer and it was the application's responsibility to read the received input data just fast enough before it got overwritten by more recent data. Not clear if this description let's you get my point... I'd be happy if some of you would like to try BRICK Lines. But it requires the Arduino Nano serial/parallel device as a hack... and so far I am only aware that Toastie has this and somebody else attempted to build another one for themself. So maybe this is a 2 people world only so far.

Hi all, a short update from my side! I had contacted both authors Helmut Albrecht and Herbert Hödl. I've gotten a reply from Helmut who seemed very nice and helpful - however, no software files in the end. And Helmut also mentioned that he was in touch with you Thorsten and Evan. Regarding the book and its floppy, I must confess that I had made some wrong assumptions: I was thinking that it contained the MS DOS/IBM PC version of LEGO Lines. But nope, of course not. You had to have LEGO's master flopy along with the license to make copies. So the book's floppy "only" contains programs I guess - still very valuable and I'd like to get access. I found out that the German national library in Frankfurt actually does have the book. It seems that due to legal reasons, they don't want you to copy the floppy contents - or at least you should not get caught when doing so. Well, maybe some day... I haven't contacted TLG about LEGO Lines - as you've written that this likely is a dead end. But: Some weeks ago, I found the precious LEGO Lines floppy for DOS on ebay by a German seller. As at the time I didn't have the equipment to read old 5.25" floppies, I got in touch with Daniel Schmatz (the guy from eitle kinderkram/YouTube mentioned above). Also: it comes with a pile of paper for use in schools (DACTA 950026), so I think Daniel is the best fit with his "museum" near Vienna. In the meantime I do have a 5.25" floppy drive and a Greaseweazle and cabling. I am missing a power supply and some more time, though. Daniel got the floppy and may read it some day using his old equipment - he might be willing to read and archive it by himself or lend it for archiving, we will see. In the meantime, I got myself an Interface A including a ribbon cable, two motors and IIRC opto-sensors and lights should be on their way. I haven't unpacked everything yet even though I am every excited to try things out soon! And I still need an AC or DC power supply - though I probably have one that already fits. Also: I have started to re-create LEGO Lines using Python and am willing to share it - probably another software I've written which the world has _not_ been looking for. It will be able to import Commodore and Apple ][ LEGO lines files and run them (I tried to understand the save file formats and fortunately, they are not that complex). The following screenshot shows my remake "BRICK Lines" on the left and the LEGO Lines software for Commodore (C64, C128, ...) on the right. Interestingly, the Commodore and the Apple ][ versions look completely different and also have different sets of functionalities! Still curious about the DOS version... I might even add functionality to edit your own programs if I or anybody else is willing to use this. I am aiming to use this with a USB/serial converter - so this could run under Windows, Linux and Mac OS! I will base it on @Toastie's Arduino project. But this finally leads me to some questions concerning the serial interface: * The project assumes that before the input ports are read, they are always written. Is this how TC Logo works? Has this been confirmed to be working with other LEGO Interface A software? * How do the emulated serial ports work? Would it also be an option that the Arduino detects edges on the inputs and sends them? Or polls the pins every millisecond and just sends an update? Or would the serial buffer in the emulated DOS machine "overflow" because the software does not read them? Or would it just.. work? * Would the old parallel ports be able to detect edges on the input pins or were they polled (e.g. every millisecond as this is the frequency which as been observed with PWM)? * A general Interface A question: did I get this right that the PC must feed a 5V voltage back into interface A to power LEDs or something or am I mixing things up here?

Thanks. Yeah, I anyway contacted Evan. Actually, there's a German book called "Steuern und Regeln mit LEGO Lines und dem LEGO TC Controller" (1989/1990). It's also avaliable on the archive.org website IIRC. I am currently trying to reach out to the authors from back then. It mentions an IBM compatible disk but also that LEGO Lines had only been available for two types of machines — but does not mention which ones (edit: from the details in the chapter: it is Commodore C64 resp. the IBM PC running DOS). This would not match with the info from above. But it's still possible that the software has been posted to other machines. Who knows.

Hey all, I am asking myself if anyone has access to LEGO Lines for the IBM PC/DOS? http://lukazi.blogspot.com/2014/07/lego-legos-first-programmable-product.html mentions it with number 9537 as "the IBM-PC version" -- so it must have existed https://archive.org/details/vintagelegorobotics currently lists versions for the BBC Micro, the Apple II, the C64.. but not the IBM PC https://lgauge.com/technic/LEGOInterfaceA/9750(1093).htm is "very much interested in the IBM (DOS) software, if anyone has it for download or even the original diskettes" Is this piece of software really lost? Or maybe only slumbering on floppy disks in attics? Has it really not found its way to the interwebs? I'd really like to see this piece of software running in DOSBox-X as well.

This is not a sponsored ad — I just thought that this might interest some of you: >Do you like Lego? Do you like the Apple IIe/IIgs? > >Blocko is an interface card that allows you to control Lego Technics machines with the LOGO programming language, just like we did in elementary school! > >Available in November 2024 > >https://blocko.net

Wow, what a nice thread! Thanks everyone for sharing their knowledge, insights, experiments and so on! While reading through the thread and before stumbling across @Toastie's diagrams, I've started to create my own one to get an overview of the hardware+software from that era... as I am more a "visual learning type": This may be wrong (please help me fix it) - and for sure is incomplete. Also special thanks to @evank for publishing videos! Do you have an update on the Philips P2000? And: are you still wanting to sell a hardware bundle? If I find time - and a 9750 - I'd like to use @Toastie's approach with a USB/serial converter + an Arduino acting as serial/parallel converter + DOSBox-X + @alexGS' modified TC Logo version for the serial port (on either Mac OS, Linux or Windows - preferably one of the first two)... and also see if there's other software we can run (or bring it to the browser such as I tried with WebPBrick). Cheers!

Thanks @Toastie! It seems that I don't have forum post notifications active. Hey @mar11, thanks for trying! Great that you made an attempt and tried WebPBrick! Have you tried to cover the infrared connection (e.g. by a sheet of paper)? I guess that you are in a "noisy" environment regarding light emissions. You can also play around with distance and angles. The mechanism is not very robust at the moment - however there should be a retry mechanism implemented. But maybe that one is not robust enough and should allow for even more retries. Hope to hear from you again. Cheers! Edit: PS: I had little progress with the USB IR tower. IIRC, you can checkout the git repository and try https://github.com/maehw/WebPBrick/blob/main/src/communication/webusb.htm. It seems that I am losing some data here. I need someone to team up with me as it gets pretty tedious and frustrating working alone on it.

Hi all, yeah this thread is pretty old - but why not try to dig out some really old things? I've gotten me a 8094 set and I've built the pen plotter model. It also works with the Mindstorms RCX yellow programmable brick (see my Mastodon/Fediverse account: https://chaos.social/@maehw/112588710501097292). However, I'd also like to lift and lower then pen with a third motor. Unfortunately, the OP's link is broken and the YouTube video in the third post does not really allow me to copy the mechanics. I am more the electronics/ embedded software guy and could need some help with the mechanics. Cheers, Mäh

Hi all, my last post may have been very technical - maybe too technical? I am happy to announce that I've just released version 0.1.0 of the web-based IDE which I called WebPBrick. I'd be happy to see people explore the IDE here: https://webpbrick.com/ide/ As the project is open source, you can also find the source code on GitHub: https://github.com/maehw/WebPBrick README? Try this one: https://github.com/maehw/WebPBrick/blob/main/CHANGELOG.md CHANGELOG? Try this one: https://github.com/maehw/WebPBrick/blob/main/README.md The LEGO Serial IR Tower should work out of the box - unfortunately, I am still having difficulties with the LEGO USB IR Tower. It would be cool if you could help me spread the news about WebPBrick! Cheers

Hi all, I never had an RCX when I was young back then when the first Mindstorms generation was release (1998), but these days I have got me some hardware to play with. I have this idea of reviving the yellow LEGO Mindstorms RCX brick. I've researched the web and found that most people will either set up a Windows Virtual Machine with an old version and run the original LEGO RIS RCX Code IDE or use a Windows Machine and use Bricx Command Center (BricxCC) and program in NQC. However, there seem to be issues with Windows 64-bit drivers for the LEGO USB IR tower. ("That beautiful communication hub for all RCX1.0, 1.5, 2.0, Scout, Spybotics, MicroScout, CodePilot bricks one is truly dead since 64 bit operating systems have taken over." - @Toastie, 2018) People have been using the LEGO serial IR tower instead or done something on their own (e.g. tinkering with hardware and Arduino code to get their own DIY IR tower working). Tired of setting up those Windows machines? Not all people have the knowledge to hack around with things... or try alternatives like running an NQC compiler from Linux or Mac OS. So.. I came up with the idea of... Programming the 1st generation LEGO Mindstorms RIS (yellow RCX brick) from the webbrowser What follows is a technical block diagram of the toolchain to accomplish this. The idea is to compile NQC code in your webbrowser and to download your compiled code to the RCX where it is executed - without any installation. We may even think out of the box and imagine block based programming with Blockly (you know Scratch? you're familiar with Blockly) and generating NQC code... Of course, there are some technical shenanigans required here, but I have proof that the basic concept is feasible: NQC compiler can be compiled as Web Assembly (WASM). See also: https://github.com/maehw/WebNQC (this should run in every modern browser) The actual relevant bytecode chunks from LEGO's proprietary .rcx file format can be extracted. (thanks to NQC's RCX library; also thanks to LEGO for documenting the opcodes) The bytecode chunks (tasks/subroutines, etc) can be downloaded to the RCX brick using a IR serial tower (infrared serial link). This can be accessed with JavaScript in webbrowsers like Chrome, Edge and Opera (unfortunately not Firefox) using the Web Serial API. (thanks for everybody working on that before, especially also BricxCC which allowed me to sniff on the communication; and also LEGO for documenting the protocol) The WebUSB API is a thing, so we may also get this wokring with the LEGO USB IR tower. I've also worked on a low-cost DIY IR serial tower that consists of a an IR LED, an IR receiver, an 8-bit microcontroller, some current-limiting resistors and two LEDs (power, activity), wires + a breadboard (of course, this could be a tiny PCB) + a USB/TTL UART converter (cable) for around 10 € (see thread on Mastodon, continued there): (No 9V battery required, it can be powered by 5V VCC (and probably alternatively also 3.3V) from the USB/serial converter. And only the default driver for the USB/serial converter. You can probably also use this "hardware frontend" part with your Arduino, Raspberry Pi or other embedded hardware... as it simply connects to a TTL serial/UART) I've so far been able to: Program the firmware (.lgo files in Motorola S-record file format (SREC)) using my DIY IR serial tower with the command line utility firmdl3 (disclaimer: all transfers only work reliably using 2400 baud) Program the firmware using my DIY IR serial tower from the webbrowser (Web Serial API) Remote control the RCX from the the webbrowser (using Web Serial API), like playing sounds, reading ROM/firmware versions, ... - everything is possible Run the NQC compiler in the webbrowser - to compile NQC code (.nqc) into RCX image binary files (.rcx) Download programs using my DIY IR serial tower from the webbrowser (again Web Serial API) This should work platform-dependently... on Windows, Linux, Mac OS.. probably also Android (haven't tried to plug the DIY IR tower via an USB OTG cable). If I see interest in any of this, I might keep working on it - and maybe set up a demo website so that you don't have to compile these things locally and run them on a local webserver (which I guess is the current barrier to entry). This looks very technical and ugly, but could get a nice UI. (Take another peak here, here and here.) Feel free to ask, if you'd like to get more insights. You have hacked around with the LEGO RCX in those last 25 years? I'd be keen to know! If you have any cool RCX projects (.rcx files or .nqc files lying around, model build instructions, sensor reverse engineering, ...) that I should try, let me know! (I also have ideas about "decompiling" old .rcx files into NQC code... and optionally Blockly in turn.) You have other ideas? Sure, share them with me!