maehw

As this seems to be referring to the serial/parallel converter: I had slightly modified Toastie's code and pushed it to this git repo on GitHub: https://github.com/maehw/BrickLines/blob/main/hardware/serial2parallel_converter/arduino_sketch/arduino_sketch.ino Have a nice weekend, folks.

You're right. But this is basically only a static website. So you should totally be able to run this locally if I currently don't miss anything. But the idea here was to have a tool working in a web browser - so that it's OS independent aka cross-platform. A driver behind this was curiosity for the "new" technology behind it (WebSerial, Web Assembly/ASM and theoretically WebUSB). But: this technology also has its drawbacks because its requires a browser supporting these technologies and for WebSerial this seems to be limited to Chromium-based web browsers. And Chrome is some Google foo. Code is FOSS on GitHub - see feel free to download, modify, etc. -- https://github.com/maehw/WebPBrick (might move or be mirrored to Codeberg some day). And yeah, there's a version hosted by myself which runs under the domain webpbrick.com -- and there's no guarantee for that service to exist forever. Afair there's another user trying to build a universal pbrick tool in Python but I haven't looked at it yet.

Hi @Bliss, thanks for your reply! There's not a broad user basis... so I haven't gotten too much feedback so far. Thanks for letting me know. About `until`: Yes, there's the block `repeat while/until <condition>`: You say "And I do not find a matching block for until. I had to use repeat until which is not the same... " - in my understanding, it is. You simply leave the loop's body empty. But yeah, we could add another block that does not provide a loop body... so that you cannot plug something in here (you don't have to, though). Also, from the NQC documentation: NQC also defines the until macro which provides a convenient alternative to the while loop. The actual definition of until is: #define until(c) while(!(c)) In other words, until will continue looping until the condition becomes true. It is most often used in conjunction with an empty body statement: until(SENSOR_1 == 1); // wait for sensor to be pressed It seems that my BlockNQC generator does not make use of that macro. Out of curiosity, I've thrown both versions into WebNQC: task main() { while (!(Message() == 11)) { } } task main() { until (Message() == 11) { } } They both compile to the same byte code (which totally makes sense as a macro will be replaced by the preprocessor already): ↪️ nqc version 3.2 r2 (built Jul 5 2024, 02:23:32) ↪️ Copyright (C) 2005 John Hansen. All Rights Reserved. 🕵🏻‍ Compiled NQC code successfully using WebNQC. 🕵🏻‍ Binary output length: 41 🕵🏻‍ Binary output as HEX: 0x52 0x43 0x58 0x49 0x02 0x01 0x01 0x00 0x01 0x00 0x03 0x00 0x00 0x00 0x0E 0x00 0x13 0x07 0x02 0x07 0xE1 0x87 0x95 0x82 0x0F 0x0B 0x00 0x00 0xFA 0xFF 0x00 0x00 0x00 0x00 0x05 0x00 0x6D 0x61 0x69 0x6E 0x00 🕵🏻‍ Compiled NQC code successfully using WebNQC. 🕵🏻‍ Binary output length: 41 🕵🏻‍ Binary output as HEX: 0x52 0x43 0x58 0x49 0x02 0x01 0x01 0x00 0x01 0x00 0x03 0x00 0x00 0x00 0x0E 0x00 0x13 0x07 0x02 0x07 0xE1 0x87 0x95 0x82 0x0F 0x0B 0x00 0x00 0xFA 0xFF 0x00 0x00 0x00 0x00 0x05 0x00 0x6D 0x61 0x69 0x6E 0x00 There's at least one other user - a teacher from Brazil - who's trying to get the serial communication working. They've been trying to build the DiyIrTower. I guess you're using the original LEGO IR Serial tower + the adapter, right? Two things you can do: - Try https://test.webpbrick.com/ide/index.html and see if it behaves differently - Go to browser tools > web developer tools and inspect the console log. Those provide very detailed communication logs, i.e. every transmitted/received messages with all their bytes. This may help... however also consume a significant amount of time to narrow this down. It may be a problem with the USB/serial adapter picking up some noise... leading to UART framing or parity errors. But it could also be something else (UART timing?). The firmware download currently isn't very stable, unfortunately. I think the same retry mechanism as the one of Bricxcc should be used as it seems to work very reliably. Thanks for trying out this project! :)

I wasonly entering those commands directly into the lower part. On the 'TURTLE' page if that is relevant — but actually without explicitly executing procedures from that page.

Hi everyone! I've got a question about LEGO TC logo. There's the `talkto` (short `tto`) command to select the output port(s) to be operated on (switched on/off, flash, etc.). The reference manual states: "There are nine outlet ports (A, B, C, 0, 1, 2, 3, 4, 5)". In my understanding A/B/C can be used bi-polar, e.g. to attach motors whose direction can be changed (`rd`, `setodd`, `seteven`) -- i.e. enabling to turn them CW and CCW. And ports 0-5 can be used in a uni-polar fashion, e.g. switching motors only on and off. When I use the LEGO TC logo Apple //e emulator, I get the error message "Can't use adjacent ports" for `tto 0` and `tto 1` (or `tto "0` and `tto "1`) while the other outlet port names work fine. Is that a bug or is there a reasonable explanation for that? Cheers Mäh

Perfect, thanks! Alt + U/D does the trick on the MacBook I am currently working on. Cheers! Have a nice weekend everyone

Hi everyone, thanks for providing more code and explanations. I've now taken a look into LEGO TC logo. Also thanks @evank for the reference guides for both Interface A and B! Can someone please guide me how to use the emulator on https://archive.org/details/LEGO_TC_Logo? How can I navigate a page (e.g. "TURTLE")? It seems that the cursor only moves in the lower part (the "command center" as it's called IIRC.. maybe mixing it up with the name of the input field in ControlLab though). Cheers Mäh

That's great! Are you willing to share the code and explain? Is it like controlling the direction by key presses?

I stumbled across this dead cheap Interface A listing on eBay from a seller in the US: ~21 $, unknown state, no power supply https://www.ebay.de/itm/336353044675 If I wouldn't already own one, I'd consider buying it. Probably not too attractive for Europeans though as shipping is expensive and customs these days probably, too. Cheers, Mäh

Thanks everyone for sharing their knowledge and fun projects! This is what the web-based program currently looks like (I am really bad at CSS, so this is pretty much hacked together): You can control outputs (switch them on and off and set their polarity). No slider for output power yet, but that should be pretty easy to add. You can also read sensor inputs -- as boolean and as raw values. It's just that the UI becomes more and more confusing when not properly designed. I've currently decimated the output rate by a factor of 10 (configurable in software of course) -- which still gives a nice responsiveness, but does not provide enough data when you really want to dive into the details when working with the rotation sensor. If you want, you can uncomment several `console.log()` calls to see more details such as every decoded received frame. This is really fun! @AJB2K3 nice blog posts, Adam. It seems that you do not check the checksum byte in the frame. This may work when you always read the 19 bytes when always perfectly in sync and no byte is ever dropped. -- Python is a very good choice to be platform-agnostic. I'd do the same, if I wasn't experimenting with the web tools... -- also don't want to bother the user to install a Python environment. Still, my solution "only" requires a web browser that supports WebSerial.. which Firefox for example unfortunately does not. So this is also a limitation for the usable environments. Besides that, no installation/configuration should be required. Those of you who are more familiar with the ecosystem -- some official TLG software uses or generates LOGO code, right? Is this the same "dialect" as used with Interface A? So far only "worked" with LEGO Lines... ;) IMO it'd be fun to get a LOGO programming language interpreter working in the browser and running it in interaction with the Interface B.

Hi all! I've been playing around with the WebSerial POC every couple of days. And it looks nice so far. "Only" a WebSerial-capable browser is needed to control an Interface B with a "modern system", no RPi in the middle (IMHO -- I may still run into performance issues though). Dear @Toastie, I am not 100% sure if this was the latest diagram posted by you. Concerning the pressed stop button in the first byte (you call it byte #1): for me the indicating bit is bit 4, i.e. I read 0x10 when the button is pressed and 0x00 when the button is released. I am not sure if this is a typo/error in your diagram or there are really different revisions of the ROM code out there. Cheers, Mäh PS: In case anyone is interested in this kind of technology, let me know and I'll upload my code some day. I think I'll open source this anways, but always motivated by others to do it rather sooner than later. And happy for feedback and improvements. ;) ____ Edit: If anyone of you who is reading this is located in the EU and willing to sell me a compatible temperature sensor, please get in touch with me!

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.