Toastie

I am totally lost And this is due to my lack of knowing anything about Python (well sort of, I guess, I get the Python idea, have it installed, but whatever I try, it tells me I am dumb) but certainly because I simply can't follow the libraries, includes, and whatnot required for getting this up and running. Rock on dudes, I revert to QBasic/DOS3.3/DOSBox-X. Have fun and make it happen! All the best Thorsten

Yes, this is what I thought. You need to come up with a program on the CL monitoring three inputs “simultaneously”. When you press the buttons on the CC the CL monitoring routines will notice that, and then you need to record these key presses = sensor input changes along with the time they were pressed on the CL. And then you can play them back on the CL. Best Thorsten

@amine It works! I just tested it with a simple voltage divider (2 resistors) and a 12V power supply. You can use the 3 outputs of CCI/II to "program" CL, once you know how capturing of A/D values on the CL software works. My QBasic program does decode these data, as it reads out the raw A/D values provided by the CL interface (the CL protocol provides raw 6 bits = 0 to 1023). I have no clue how to get the LEGO CL >software< (I am running Control Lab for DOS) recognizing any such raw A/D values; my understanding is, that either touch sensors and/or temp sensors can be used on the yellow = passive sensor inputs and these data are converted internally by the CL software to "ON/OFF" or "°C/°F". You may well convert °C/°F data back into raw data (0 ... 1023), of course. Maybe there is another way in CL software to tell it: Use the plain A/D data. What happens with this simple setup is: When pressing any "fwd" key (upper red button or yellow disc N/E), a reading <600 is recorded by CL, when pressing any "rev" keys (lower red button, S/W), the emitted data are somewhere between 800 and 900, and when no key is pressed it is 1023. These numbers are all raw sensor data, as provided by the CL interface. If you want more details, I am happy to provide them, here or via personal messaging. For this approach you need a) a cheap, but stabilized 12V DC power supply, b) 3x1kOhm + 3x330 Ohm resistors (covering all three CCI/II outputs), and c) a bit of soldering or a solderless mini breadboard. All the best Thorsten

That is >really< cool!!! Now, I personally (it is just me!) would like to get this into the clear. Your IDE, as a main goal, is designed to >control< the various LEGO PBricks and interfaces from, well, the IDE, right? Or do you also want to universally program the PBricks and interfaces? Interfaces would be A and B, right? PBricks would be CodePilot, MicroScout, Cybermaster, RCX, Scout, correct? NXT and EV3, as well as Spike/PUp are more or less up to date or do you want to include these as well? The interfaces are essentially stationary and act as remotely controlled devices, in addition delivering input data, whereas the PBricks are designed to operate autonomously = run programs to respond to sensor data on their own. In other words: Your IDE is designed to do two principal things: a) run programs on the interface controlling device and b) provide means of downloading programs to the different PBrick targets. Is this the goal? Very interesting project!!! All the best Thorsten

Hmm - that seems to be a bug? When I use either TCLogo within the DOSBox-X emulator or directly on my IBM XT with 9771 card, I don't get that error. At least not, when I type "tto 1" then "on" and then "tto 0" and "on" in direct mode. Does this lead to the error you mentioned in your post? Best Thorsten

How on Earth could that happen ... Thanks for noticing and - all the best Thorsten

All good here as well.

So there are at least two of us! I do see and do it the exact same way you are choosing: Either I get the (as "Unobtanium categorized") items, such as 9771 for very low money + S&H of course, or I will take the "trail and error, error, error ... success!" route. OK, success may not be the final result, but for sure the learning curve took steep inclines! And that is all what counts. AI may be of help - or maybe not. I recently got so much nonsense regarding "reset button for a C64" from Google's AI - it was telling. Old and swiftly emerging stuff (back in the days, as the C64, Apple II, and other systems - heck, that was the >fun<!) seems not to be the realm of AI. I prefer the human brain guided search when it comes to old stuff. You know the arbitrary diversions, deep dives, just for fun searches. And yes, the "what I have at hand approach" is another rewarding experience. 3D printing? Sure. But maybe there is a scrap part somewhere? Buying the perfect fit part for some task? Sure. But maybe a used part, having the functionality, will do? With some mod, or apparently less nice look? Sure. However, it depends on perspective: Used parts generally look good to me ... Just keep posting what you are either struggling with or you have accomplished. Or you are searching for. I am in. All the best Thorsten

Hi Michael, that is a perfect write-up!!! Maybe one tiny little thing to add: Thermistors, as they are “stressed” chemical compounds (they need to chemically conduct current in contrast to metal wires, they simply push electrons through and thus may burn out, as nobody tells them hey, could be too much ;) - naturally “age”. First with time, second with stress. As do rechargeable batteries, for the same reason but due to a totally different chemistry. Thank you very much and all the best Thorsten

You too!

Oh my, sorry! I totally wrongly assumed, @amine is PEEKing and POKEing around in BASIC 1.0 because there was no LEGO software for it ... Your website is so unbelievably helpful in referencing and identifying all the various 8-bit systems a) endorsed by TLG and b) all the systems you summoned in reply to your challenge. a) being much more important to me, as I find this really fascinating: What countries chose what route to get into school computing, and at what effort, cost, and - "success". All the best Thorsten

Maybe some people are worried that without the thermistor, a motor may burn out upon operating too long under too much stress. This is what they are there for in the first place. I have taken out all the thermistors in my 9V motors, as they always caused trouble. All my non-PUp locomotives have 9V motors, two are RCX controlled, most other with PF and some with PUp gear. All these controllers use PWM for setting the "speed". On my RCX trains I have even programmed a PID control loop for controlling speed - the stuff that is now built into PUp hubs, should you use the appropriate PUp motors that have rotation encoders on board. The PUp train motor has of course not ^^. Upon RCX PID control and using 9V motors along with the blue Mindstorms rotation sensors, the RCX PWM outputs go "crazy" when either ramping up speed or trying to keep speed constant. Nothing happened so far to the motors. Here is a 15 years old post along with a video showing that (yes, video sucks, but you can hear the pitch of the changing PWM output clearly): https://www.eurobricks.com/forum/forums/topic/45440-lego-train-control-using-rcx10-pbricks/ I don't do any shows though - things may change under full stress ... All the best, Thorsten

That would be super nice. 6809 machine code ... And there is even an emulator for the MO5: https://www.roug.org/retrocomputing/emulators/mo5 I have some BASIC code for simulating (very) slow "PWM" as done in the TCLogo machine code. It works, but as said, it is way too slow. Well, in DOSBox-X, I can crank up the speed of QBasic considerably ;) All the best Thorsten

That is quite a nice machine, I never heard of! And it runs MS BASIC 1.0 - I love the PEEKs and POKEs! This is really very interesting - so in France they also had a dedicated "school computer" as they had in Sweden - The Compis (and most probably elsewhere, but in Germany, if I am not mistaken). And @evank has to update his website Thank you very much for sharing! All the best Thorsten

Was that any custom PWM device or using TLG's RCX, PF, or PUp? They never failed on me (so far, 10+ motors). Did you remove the thermistor in the 9V motor, or was it still in place? Best Thorsten

I see. Well, I am running DOS3.3 or 6.2 (within DOSBox-X on Win11/64bit) and using QBasic 1.1 or QuickBasic 4.5 as well as VisualBasic6.0 on Win11/64bit, the baud rate settings as applied in software never change. Maybe it is the stone old stuff ... Best Thorsten Heehee - the gold old hardware for the good old software Congratulations and welcome to the Vintage People! Best and have fun, Thorsten

Well, at about €18, there would be about €20ish for S&H + tax. I got my third recently from the US, and it was for €40 on BrickOwl. Total was €65 incl. S&H+tax, which I thought was a very good deal. It was in tested and perfect condition. As I have three of these now, I also don't consider buying it. As these are virtually unbreakable and even if, they fully made with nicely "desolderable" and replaceable parts. If I were looking for one, I would definitely go for it. Thank you very much for sharing!!! All the best Thorsten

Hello @maehw, it was the last diagram, and it is of course wrong in that place as 0x10 is not 0000 0010 sorry for that, will clear that up when I find the damned diagram. In my QBasic program to speed up things a lill bit, I don't even check for any value other than 0, as I never found any other information in that byte. I shall correct that! Thanks again for noticing! All the best Thorsten

Wait - I believe the Baud rate >needs to be< 2400? And everything else does not work? I was under the impression that the software used to communicate with the CM brick does set the Baud rate to 2400? It does not matter what is in the driver section, as the software you use takes care of that? Best Thorsten

Congratulations! And this is also owing to @BrickTronic! I looked up one's and two's complement on the webs - it still is sooo confusing to me. All websites I found talk about signed bytes/integers. There is even a one's complement calculator website ^^, which works perfectly well, but only in the range 0 to 127 - and of course -128 to 0. There is no -128 on the RCX ...well it depends of course on the universe. On the RCX it is 0-255. In the signed world, where such complements make total sense, it is the same range, but expressed as -128 to 127 ... On the RCX it is simply 255 - x. Which flips all bits. In the signed world, 128 is impossible. But the RCX lives in the unsigned world ... Well. Just cool you got it to work!!!! All the best Thorsten

Not exactly: The one's (here is to @BrickTronic) complement of your checksum is wrong: 0xFF-0x5B=0xA4, if I am not mistaken. Best Thorsten

Hi Jo, I am aware of that - however, a good number of references out there describe it as just that for the RCX: As two's complement. A few years ago, it took me literally days to figure out, how this two's complement should ever work on an RCX. I did not. I figured out though (by intercepting reply messages from the RCX) that 0xFF - 0xYZ does. I did not want to run into trouble and thought "so be it". You are absolutely right, of course! All the best, and so good to have you around!!! Thorsten

Not exactly ... but close: The two's complement is what follows each message byte = opcode and databyte(s). The preamble is always 0x55, 0xFF, 0x00. For the PlaySound opcode (59) the two's complement is 0xFF-0x59=0xA6. Then you send the data byte, let's say for sound 1, and its two's complement 0xFF-0x01=0xFE. Next is the checksum and its two's complement. Checksum for 0x59+0x01=0x5A (only the lower 8 bits are sent, in this case not necessary to strip any high bits), the two's complement is 0xFF-0x5A=0xA5 The entire message for "PlaySound 1" should thus be 0x55, 0xFF, 0x00, 0x59, 0xA6, 0x01, 0xFE, 0x5A, 0xA5 Now, when you want to send "PlaySound 1" again right after the previous "PlaySound 1" or even repeatedly, you have to "toggle" bit #4 (0x08) in the opcode: 0x59-0x08=0x51 and vice versa. This of course also changes the complement of the opcode as well as the checksum and should be: 0x55, 0xFF, 0x00, 0x51, 0xAE, 0x01, 0xFE, 0x52, 0xAD. When you send another command after the first "PlaySound 1" message, you don't need to change the toggle bit. Here is how I assemble my RCX messages (I am using a pure SetMessage protocol for my RCX equipped trains, which is simply train ID + action = 2x consecutive SetMessages), so the first 5 bytes in each message are always the same (preamble + opcode SetMessage + two's complement = 0x55, 0xFF, 0x00, 0xF7, 0x08) then I simply append the message byte. Note that SetMessage (opcode 0xF7) does not need to change the toggle bit, when sending it twice or multiple times: const uint8_t RCXMessageHeader[5] = {0x55,0xFF,0x00,0xF7,0x08}; if (Flag_ComMode == ManualMode){ // Build full RCX message from ID and databyte manually entered for (int i=0; i<5; i++) ZXBytes[i] = RCXMessageHeader[i]; // Preamble + command message //ZXBytes[5] = ID; // From ManualInput. ZXBytes[6] = 0xFF-ZXBytes[5]; // RCX' two's complement ZXBytes[7] = lowByte(0xF7+ZXBytes[5]); // checksum of "real" data bytes in msg ZXBytes[8] = 0xFF-ZXBytes[7]; // RCX' two's complement for (int i=9; i<14; i++) ZXBytes[i] = RCXMessageHeader[i-9]; // Preamble + command message //ZXBytes[14] = databyte; // From ManualInput. ZXBytes[15] = 0xFF-ZXBytes[14]; // RCX' two's complement ZXBytes[16] = lowByte(0xF7+ZXBytes[14]); // checksum of "real" data bytes in msg ZXBytes[17] = 0xFF-ZXBytes[16]; // RCX' two's complement } Forgive me my horrible C++ coding - I am a BASIC person, so I code C++ as if it were BASIC Let me know whether this works (the PlaySound messages) - I started all this more than 25 years ago using MS QBASIC. I still have these programs on my laptop (Win11/64bit - using DOSBox-X) and my IBM XT (PCDOS 3.2) ; they run well on both machines. If not, I shall break out my test RCX, the IR tower and check. Could be that I screwed up the hex numbers above ... Best Thorsten

Sure Firstly, your "command" is not complete. The mralligator page you are using lists "just" bare opcodes. Each of these, including any data byte(s), e.g., "0x01" for sound one, have to be followed by their two's complements (RCX uses: 0xFF - 8-bit opcode or 8-bit data byte as two's complement tc). Then the checksum needs to be appended, which are just the 8 low bits of the sum of all payload bytes (opcode + data bytes), excluding all two's complements, and lastly the two's complement of the checksum. Once you have coded the synthesizing of the entire data packet, it is all smooth and easy: preamble (0x55, 0xFF, 0x00), opcode, tc of opcode, data byte, tc of data byte, ..., checksum, tc of checksum. That is one full RCX command. Don't forget to flip the toggle bit of the opcode, when resending the command. When you scroll down on this post to the "Protocol bit/byte streams encoding" of old LEGO protocols, you'll find details for the RCX in section 4: Best Thorsten

@AJB2K3 This is the place! I think maybe also this link provides some structured info about the Interface B protocol - it was put together some time ago with the help of many people her on EB: There is more further down as well, a bit on A/D conversion and so on. Best Thorsten