Toastie

I saw exactly the same behavior: No unlocking, no communication (LEDs blinking or not is not any sign of logical communication. The tower LED blinks regardless which bytes are fed to it. Sometimes the CM brick's LED flashes, but no true communication. My test for a known good CM brick: I use BricxCC to unlock the CM brick (this way, you get a visual confirmation in the IDE that "the link" is established, then end BricxCC, then use a terminal program on the same port, and then manually send commands for some time. I believe sending a command also resets the time-out counter on the CM brick. Equally important: When sending, e.g., "beep" repeatedly, you need to flip the toggle bit each time. Or, just send another command; the next beep can then be identical to the first beep. If that works, then I know that tower+CM brick are actually working. Regards, Thorsten

I believe, Evan was/is in touch with him, I can try as well - but let us wait for Evan's reply! This will be such a nice read, thank you again so much, @amine for letting the past shine - brilliantly! This IS such a nice read. I have all the US/ENG cards and manuals, but there is a subtle difference. And I am really impressed how this difference in addressing - in this case German teachers - makes such a big difference! This is of course about PCs and compatibles and LEGO Lines. TLG really was something different in the past, at least this is my impression, over and over again. All the best Thorsten P.S.: I believe we are seriously derailing this thread, as this is about Interface A, LEGO Lines etc. rather than about Control Lab. No idea how to fix that other than ... just go on?

That is a nice read! GW Basic, QuickBasic, Turbo Pascal, ... all on my Laptop And the unobtainable LEGO TC Controller software is mentioned as well!!! We tried so hard, but to no avail. And here is where you could order all that stuff: "LEGO GmbH, Schulbereich, Postfach 1263, 2354 Hohenwestedt", which was 20 km away from where I grew up in Northern Germany - and never ever heard about it back then - OK, I was in my dark ages ... So enjoyable! All the best Thorsten

Wow! That IS cool. This was for the IBM PC/XT right? What BASIC, Pascal, and Comal versions are they recommending/using on what OS? I shall then feed my Gotek on my IBM appropriately! All the best Thorsten

Ahh, I see, as I said, I got a bit lost. I am also aware that Windows is not loved much (with at least one exception: Me ), but all LEGO software runs either directly within Win11 (including BricxCC = access to RCX, Scout, Spybot, Cybermaster, NXT - I have them all, and they connect fine using the serial IR or RF tower, or BT/USB) with any USB2Ser adapater I have, even a USB2BT transceiver pairs work) or within DOSBox-X, which in turn runs perfectly well in Win11. Except for Interface A, every other LEGO PBrick or device runs on some sort of serial protocol - and since USB will be around a bit, all various adapters including USB/serial-to-parallel (with a little help from an Arduino Nano or Pico). VLL requires an even simpler adapter, which in turn runs perfectly well using Win11 or DOSBox-X. So what would the Raspberry pie do differently other than running LINUX, or is that the main point? All the best Thorsten

I believe I have lost it a bit - sorry. What are you actually aiming for? Are these pies or arduinos (or ESPs) envisioned for doing any protocol translation, e.g., from serial to parallel, or are these proposed to run an entire IDE for scratch like programming? Best Thorsten Me too!!! Well, as said, I have lost track. What is the goal of all this in one sentence? There are so many things already out there ... Best Thorsten

This thing runs on an ESP32 Vroom board in a LEGO case. It can't do CM (yet), but that is a matter of a bit of additional programming Time ... All the best Thorsten

What is that? RCX 1.0, 1.5, 2.0 are all running the exact same communication protocol. The only differences are 1) power feed and 2) firmware. There was no change on the com protocol. This is a bit confusing: Cybermaster has not much to do with Scout; the Scout follows exactly the RCX protocol. There are some additional op codes, but that is very well documented in the NQC software, which bundles with the current BricxCC framework. And also in the LEGO SDKs documents for all the original Mindstorms platforms. The CM came before the RCX, but shares a lot of the programming infrastructure. As discussed extensively in another thread here, you can connect to a CM using the RF tower with a simple terminal program - after initialization. Again NQC/BricxCC documentation has all the opcodes. Hope that helps + all the best Thorsten Wow! That is a nice one! When wanting to integrate the Interface A into your suite, you'll need 8-bit parallel outputs (2 input 6 output). It appears as if the 40 pin GPIO port can do that with no hassle. This is different for all other interfaces and PBricks; they run on serial hardware. But I believe you know all that. Cool project! All the best Thorsten

Hey folks, when the RCX protocol works, so will SCOUT and Spybots. I have to dig up my MulPI and CM stuff - man, time goes by ... Best Thorsten THAT sounds really cool!!! My IBM XT has a German keyboard - and the CGA card of course refuses to do any codepage or related stuff. Would be nice to see when Ä Ü ß ö ä ü need to be pressed (OK, I do have the GER <-> US keyboard layout conversion on a laminated print out of course) to get into action Best Thorsten

I never thought that this is even debatable? Of course, they do their very best, being openly fully exposed to the "public". Everything they create which makes it into a product is exposed to the WORLD, including the myriads of YT channels believing they know it, all social media outlets, catalogs, websites ... "they" are not named, but "they" see these responses, for sure. When "they" decide to do so. The "constraints" ... let's speculate: Are these ... minimizing the cost for TLG to realize a set? Or creating a set that satisfies the tastes of - experts, knowing it better anyway, as they have no constraints? Or anything in between? Or is it just that: Assessment of buying habits of world-wide cohorts, analysis of regionally resolved buying power, balancing invest to revenue, always monitoring the world-wide market? I sincerely do believe so. In other words: Being a LEGO designer sounds like a dream. Maybe unless reality (= money) checks in. Maybe not; it could be fun for some creating a set at minimal cost rather than ... making it through EB's quality control. Which in addition sells well. I have no clue. But calling out the set designers within TLG world - no. It is TLG. Just my very personal view. All the best Thorsten

You are very welcome! These SDS sheets always imply that the end is near ;) BTW: Large LD50 numbers mean that the poor mice had to swallow >a lot< before they died. Butanone, as well as acetone, are really sort of safe "household" solvents. When it comes to flammability, gasoline, that we put into our cars every so often, is in the same ballpark. With regard to toxicity, gasoline is much worse than MEK and actually is a carcinogenic formulation (mixture). It is always the same: Things we are used to, and we learned to handle, can be as bad as imaginable, but we are fine. Just a three-letter abbreviation as MEK does ring so many alarm bells, because that stuff is mostly "unknown". Folks in a chemical lab are really happy when MEK does the job as solvent, because it is so "friendly". There are so many way worse solvents ... (yes, I am a chemist) In conclusion: It is really safe and smart using MEK as a means to permanently attach LEGO bricks. Just make sure there is sufficient ventilation to prevent for fires. And don't inhale or drink too much of it. All the best Thorsten

Methly ethyl ketone or butanone is hazardous, but not because it is causing cancer. Here is what Wikipedia says: https://en.wikipedia.org/wiki/Butanone. There is also a link to the safety data sheet (SDS). The last SDS revision in the EU is from December 2025. Even the LD50 numbers are rather high. However, it is >highly< flammable. So what people try to do with "venting" is diluting any MEK vapors to the extent that a) the explosive region is not reached, b) preventing any sparks to fire up the air (does not always need an explosion to cause damage), c) people who are working with it don't irritate their eyes etc., it is also toxic upon inhalation, however, virtually all chemical compounds with such a high vapor pressure as that of MEK are. Here is an interesting "article" of a US chemicals supplier (Alliance Chemical) talking about how to "glue" LEGO bricks together and why it works: https://alliancechemical.com/blogs/articles/beyond-the-basics-using-mek-as-a-lego-glue-for-permanent-structures? There is also a short version of the SDS for MEK attached at the end. Best Thorsten

I could not agree more. However, the good design judgment of the individual listening to the parts speaking, is governed by the individual's willingness or capability to let imagination, transfer thoughts, extrapolation, memory (...) run freely, without limits. Best Thorsten

Mine as well! Nothing to hide, in contrast. Best Thorsten

Thank you very much @Gunners TekZone! It will take some time for me plowing through the (to me) unknown Apple hardware - but what is time! I love these chips. And others may be way more educated to come up with ideas, proposals, solutions. For sure: You can make it way less sophisticated, as said. On the other hand: You absolutely don't need an Apple or IBM PC/XT to control 9750. A ZX81 - the totally el cheapo Zeddy - is well suited to do so, with a little help from (again) dead cheap ancient TTL chips. Not the point: This thread is not about saving here and there, it is about making it work. If someone figures out how to connect a Cray X-MP to 9570: It is >totally< relevant to this thread! And most probably, I will faint. It is just fantasizing about what >could< possibly work, regardless of the approach. @evank will judge and approve or not, just for locking anything appropriate into his (wonderful!) website. How cool is that. But here on EB: Just go nuts. All the best Thorsten

BUT This IS a totally relevant post to this thread!!! Sure you can use them for much more sophisticated stuff, but, also for talking/listening to Interface A! This thread is not about what can be done cheaper or less demanding, it is about what devices can interface to 9750! Your cards can do much more, but hey, I am absolutely sure that the chippies on these cards would be so happy when running 4.5V Technic machines. Is there a chance that you repost the card pictures? I have no idea how the Apple works on its inside, but I saw (but did not take screenshots, when I was preparing for a nice, 3 beers night diving into Apple ][ hardware) the photographs, all the chippies, I am familiar with ... of course these cards will do, I thought, but then - gone ... Man, I am using the I/O port of an Atari 1040 to talk to 9570. Believe it or not, I can hear some sort of "snickering", when it does. A friendly sound, though. This thread is about just doing or envisioning it. Best Thorsten

Huh? I am confused. If you want to know the dimensions of a LEGO thing in studs - isn't the diameter of a "stud" more or less irrelevant, but the center distance of two such studs (or the stud pitch) is? I thought this is the LEGO universe universal constant: 8 mm ideal stud center distance. Which of course implies that the diameter of such a stud needs to be less than that. The brick, precisely the 1xX bricks, are (ideally) 8 mm wide (which they really aren't, as reality needs tiny space to separate them again). And a stud is a stud, isn't it? In studless world, there are no studs, otherwise it would be studful. In studful world, we pop the holes - some call anti studs ^^ onto these (ideally) 5 mm (but in reality about 4.8 mm) diameter studs, don't we? The only real constant here seems to be the studful LEGO stud pitch - which should be more or less exactly 8 mm. So is the studless Technic hole pitch. Best Thorsten

Oh nice!!! I love rectification of this kind! Thank you very much, Evan! All the best Thorsten

I completely agree with you - with everything you wrote! Yes, let us continue to voice our enthusiasm and appreciation for what has been accomplished by TLG in the past. And show what (still) can be done with these fantastic educational materials. All the best and have a very nice day! Thorsten

This is absolutely true. However, I am not so sure about the last bit. Whenever we were asking TLG about historic software (apparently, the inquiries went all the way up to The Archives in Billund), in the end their reply was: Not to be found or not possible to disclose anything due to IP infringements. Well, this was about software(s) introduced 35+ years ago ... Could be that their archives suck, could be that their contracts are legal monsters. Besides the added value for the history, I also find it highly educating to study any >principle< progress that has been made over the decades. That is true for virtually everything, but I like to reflect from time to time real progress and not the change of color or communications protocols. Sure, new powerful hard- and software may do things unheard of every time they are introduced. But one has to tell them to actually do so. In the educational line of "robotics", having been limited for some decades to 2-3 sensor inputs or 3-5 actuator outputs (except for Interface B) without cascading the controlling devices, some repetitive elements are clearly observable. Line followers is only one. Furthermore, it is certainly true that schools and other institutions of education should be on top of the high-tech-game. However, the repetitive introduction of follow-up technology, being incompatible with its predecessors, seems also to be a nice way of increasing revenue at increasing pace. In addition, teaching folks need also be a) able and b) willing to teach the ever evolving advancement in technology. It is not only playing with old stuff from a historical perspective - it is purely fascinating to realize again and again, what can be accomplished with this old stuff, when used properly and with some skill. All the little hardware tricks and the software tweaks enabled many cool features - decades ago. Whether one sends data through a wire or through the air, be it IR, BT, BLE - in the end data need to be sent, and understood or interpreted at the other end and vice versa. Yes, today everything is high-res, multicolor, superfast, and totally awesome - but when you've built a LEGO model equipped with some sensors and some motors, 5GHz CPU clock rates are hardly necessary. Color sensing, fine, recognition of the user using an iris scan, fine, but your LEGO model will respond by moving something or making sounds. That sound could be a "beep" - as it was decades ago, or a super-nicely modulated sound from outer worlds as it is today; it remains a simple response, though. I am also aware of all the gurus out there, really bringing new technology introduced by TLG to the highest levels of sophistication. But we are talking education here, classroom action, performed with plastic bricks that have become more diverse, but the central idea of holding them together, as well as sensing and actuating, is 3 ... 4 decades old. I am not saying that today's students need to listen to beeps, because we did (in addition to all the limitation we had to live with ), no, I am talking about me, trying to get something across as a teacher. Getting to the heart and principle of the process by moving away all the decoration making it look good, no, look >awesome<. All the best, Thorsten

Hi Alex, in inner BASIC circles, that obscurity is also called "IP protection" . I grew up with “programming” BASIC on a Sinclair ZX81, and then (for years due to budget limitations) on a ZX Spectrum. Commands were exclusively tokens, the rubber (mat) keys represented >multiple< "commands" and graphic symbols, I was PEEKing and POKEing everywhere, moved RAMTOP around to make space for bytes some call "assembly", no line indenting, nested GOSUBs and so on and so forth. The dirtiest of dirty coding - but it sometimes worked. That will be quite the C64 experience. Others visit amusement parks, I take the C64 BASIC roller coaster - for free. I guess it is some rare variety of electro-masochism - but I'm actually looking forward to poking around on that 8-bit number cruncher. All the best Thorsten

Thank you, Alex. Appreciate your reply very much! Still did not make it into Lines, but that will happen soon. I shall also try out @maehw's GitHub code! I am also assembling all the Archive Lines images. I was asking, because I am planning to explore the C64's BASIC a bit more. Setting it up in my attic right now. Got another Interface A, as well as the C64's user port plug. Shall make the cable, and then try out "coding" (typing in BASIC lines is generally not regarded as coding, but "I don't care, I love it") an interface program, as I did for my DOS machines and the Atari 1040. Three more years, and I will be 100% on all this :D All the best Thorsten

Oh, that is a nice read! Thank you very much @amine! It works as the DOS Wasm X browser based emulator. I shall clear up my code, will also put the latest versions on Bricksafe. That may take a little time as I am rather busy these days, the winter semester comes to an end, which means !examania! As I have my C64 back to life (it was the boldly soldered in PLA ... it was a pain the a*s to get bugger out - ripped one trace off the ground and ruined a couple of vias, but works) - I have a quick question, I bet you, @evank, or @alexGS know right off the bat: I there a TC Logo version for the C64? Or is it "just" LEGO Lines? Best Thorsten

If the archive DOS emulator works as on the DOS Wasm X online emulator, it should work fine. As I said, in 9750 SIM mode nothing is sent anywhere, but the lill' virtual LEDs will go on/off as well as the direction is shown. I can certainly assemble a ZIP file containing all my latest programs (9750, 9751, 8485). I would probably need some explanations, but I can write something up as well. Best Thorsten

Yes, but using that code GitHub, you'll need to build and compile the server on a Linux machine. Best Thorsten