maehw

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.