Toastie

Oh yes, congratulations! But what did I miss? There was this wrongly soldered tripod thingy - did you replace that? What actually made the Interface B come back to life? The Arduino soldered directly to the B's microcontroller? I am just curious. Best wishes, Thorsten

Have been rather busy the last month(s) - our annual mass spectrometry conference has closed its doors on Friday - was rushing back from Leipzig to make it for a birthday party - getting things into the clear, and now !focus! @Bliss I just read this thread from where I lost it - the moment I found "just go to this website" you had me. Learned a bit about "blockly" lost it again, but updated Chrome (I am a Firefox user as long as Firefox exists), installed the essential add-ons (Adblock, etc. pp) and shall try connecting my Interface B (which connects via HC-05 + TTL2SER to my Win11 laptop). I have the feeling that this will be pure fun! I can do all that with DOSBox-X + QBasic, but when it comes to "programming" Interface B in QBasic, a lot of care has to be taken as I need to capture the serial port data along with keeping program control clean - in - well - one Basic program. I am not interested in controlling multiple B's, as I haven't envisioned any stationary >programmable< robotics device having 8 inputs + outputs. Turning things on/off in response to pressing buttons is one thing (and I do that differently in my LEGO world, using RCX driven "electro-mechanical" devices for example). After all, Interface B is a sensor data reporter and light/motor driver, which is principally the same thing Interface A does. The software on the computer does it all, in contrast to the PBricks, which are meant to run autonomously after programming. And here is, where your approach really excels. I know: LOGO is under the hood of the LEGO software, but I am struggling with LOGO a lot. Particularly when mixed with visual controls as in the LEGO software for Interface B. I got somewhat familiar with the (visual) LEGO software for the NXT brick (using all sorts of 3rd party sensors/extension, some were my own), but when I wrote (ok, "wired") more "complex" programs, it became difficult there as well, as the IDE was maybe not expecting such "long" programs. I am really excited - I believe your approach is the way to go, "Interface B software-wise". All the best Thorsten

That's the thing, isn't it? I don't favor the plain average approach though. There should be a "time elapsed from first exposure" (temporally resolved) related study, as you like a paper coming out ;) Best Thorsten

Ha! Time to brag :D I have 11 1.0's Of which are 8 in service: 3 serve 18 switch points on my train layout (using mechanical multiplexers), 2 manage some lights, 1 operates a bridge (otherwise I can't get into a storage room up here) and 2 operate - well - 2 trains (these are post-PUp PID (or PPP) speed controlled trains ;) There is also 1 Scout operating 6 MicroScouts (via optical fibers) operating 6 additional switch points and another Scout operating 3 MicroScouts (again via optical fibers) operating 3 more switch points. It takes about half an hour to switch all these PBricks on :D They are all equipped with NiMH batteries and pickup power from the 9V track, which is permanently powered with a 15V DC laptop power supply. Which in turn means that I don't have to replace batteries every so many months Control is via Laptop/VB6 (yes, VB6 ) and MulPI, which among other things uses the plain vanilla RCX messaging protocol to send out - well messages to the Scouts and RCX' using simple 433 MHz OOK transceivers I made. MulPI also uses the PowerFunctions and PoweredUp communication channels (it has an ESP32 Vroom board under the hood - these are simply >crazy<. And already soo old ;) And just for fun, I can also control the lights up here as they are controlled by InterTechno 433 MHz wireless switches, which were hip after WW2 - no - it was after Y2k. Trans-blue = Spybots, old-grey = Cybermasters - they are all very handsome and readily programmable with NQC or more comfortably with BricxCC, which uses NQC. I also have a couple of those beauties. And you can get them for cheap - I guess, because documentation back then was no so enlightening ;) and they are sort of limited in general usage due to their built-in motors. Autonomous robots were meant to be powered by them. But: I will find duties for these as well. I just need more time. Less than 3 years and I'll be on permanent vacation Y'all have fun! Best Thorsten

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