Toastie

Very nice! Congratulations and have fun! All the best Thorsten

Hi there, IR tower indicator LED goes on upon sending data to the tower? All three RCX' lost their firmware? If so: You can establish a connection to an RCX w/o firmware, but the "icon" does not work/show up without firmware present, as virtually all other things don't. This is more or less what the RCX can do: Wait for a firmware to arrive ... and run the 5 built it test programs, so you know it is alive. Best Thorsten

Well thank you very much @maehw for this excellent summary of 22 forum pages!!! This is exactly what I am missing from time to time: Good summaries. I believe what you are speculating at the end of your summary is a really nice proposal - it really may work! All the best Thorsten

Well ... maybe when using the accompanying LEGO software ... But when you want to control Interface B using BASIC, quite some "code" optimization is needed to get that going on a vintage machine. It took me a while to figure even out the data stream logic. And programming that thing for some autonomous action requires seriously more lines of code ... With Interface A it does not get simpler: PEEK/POKE (IN/OUT) one address (after one more POKE for port direction initialization) The one thing I still have not implemented is PWM control for Interface A. But as we have figured out how that works in 8086 assembly, even that seems to be within reach. Here is to the wimps Best Thorsten

So you do the initialization by sending the appropriate bytes, right? And then you send a motor command, the brick replies by flashing its LED 3 times, correct? I just got put my CMs + RF tower: Using BricxCC, upon pressing "find brick", the Tower LED flashes briefly, then again, then for maybe a second, then 3 times briefly. The CM bricks replies 2 times with 5 flashes each. Now, I am believing to recall that whenever the tower sends out certain commands, a reply is expected. The incoming reply is indicated by the second flash of the tower LED and by the 5 flashes on the CM brick. So what I believe is happening upon establishing a connection is sending a byte code, get the reply, send the unlocking string, get a reply. Furthermore, I can't confirm the necessity of sending repeated "keep alive" messages on short time scales (that was the case with Interface B): In BricxCC I set the power down time of the CM brick to 15 min. Then sent a motor A on command, then unplugged the RF tower from the USB2Ser adapter, waited for a couple of minutes, plugged it in again, sent the motor A sop command - works. The power down time is reset to 15 min upon receiving a new command. Regards Thorsten

I believe the card @Gunners TekZone posted above (on the left) can do that. Two 6522's = 4 freely programmable 8 bit I/O ports: https://en.wikipedia.org/wiki/MOS_Technology_6522 The 6522 have more on board that you don't need at all for your purpose. All these features seem to be exposed on the multiple pins on top as well, I believe. Any chance that there are more of such cards floating around? I can't figure out the address decoding - and I have no clue how an Apple II addresses cards sitting on these bus sockets. On the IBM XT cards are freely addressable (with exception to ISA socket 8) but I don't know how that works on the Apple II. I have the feeling there is some socket dependent addressing (see card on the left, which is "socket selective"), but again, pure speculation here. Other know for sure better! Best wishes Thorsten

Does it play sounds? Does it activate the third output? CMs are known to have bad motors - the disc magnets inside regularly went bad. Do your wheels spin freely (or with the resistance of a good geared down motor? I have 5 CM bricks of which 1 + 1/2 is working motorwise. Everything else is fine (communication, memory=programming, 3rd output). Best Thorsten

What does that mean? Flashing as it turns its LED on and off (but that is it), or actually executing a command? Best Thorsten

Would a zip file do? If so, here's a link to my universities cloud server - the file is the exe Jo referenced, stored as zip file: https://uni-wuppertal.sciebo.de/s/ebemboGYrrimRWk Best Thorsten

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