Toastie

Hello @maehw, WHAT A FIND!!! Wow. Daniel has so many "things" - it is incredible - and in the right "hands". I love his channel, his attitude, the things he brings across ... just wonderful. With regard to 5 1/4 floppies: My IBM XT has two of those - happy to be at service. Yeah, TLG and copyrights (of software on a medium, 99.X% of all inhabitants of Earth never heard about ... they'll make a fortune off the copyrights, I am sure, they are so smart) - forget it. As said ... Hey, welcome to the club. Just turn "the world" into ... 10 people. It always makes the difference for me. The world ... let them do their thing. I am all 10 people do care world. Or maybe 5. 5 really happy people on this planet make the difference, as they not only freak out for a second or minute, but their enthusiam and appreciation simply persists for a very(!) long time. Yes. Interface A is a (dumb) parallel port device responding to changes on its input lines. It is the LEGO #9771 parallel interface card taking care of things. The #9750 box is a 6 "lines" output "driver" and provides 2 input "lines". You have to read or listen to the 8 bit port (6 bit out latched/mirrored to the 8 bit data bus, and 2 bit as momentary status of the 2 sensors (on or off)). You can always asynchronosly read from and write to #9771 => #9750. I am using QBasic and it does seamlessly work with interface A using that approach. #9750 does not send out any data. It provides a "status" (along with #9771). Nothing overflows, as you are the one asking the port for its status. This is completely different for #9751 (interface B) - here you have to swallow with what the 19 byte data frames are telling you. #9750/#9771 are not responding; they change the 8 bit port signals, and you have to interrogate. The "writing before reading" approach synchronizes the two programs (in my case, DOS/QBasic <-> Arduino), i.e., they are "bolted together": Writing to the Arduino calls for an immediate reply, which I then read in turn into my QBasic program. This way, any programming overhead is essentially eliminated. QBasic is a bit on the slow side. Should the Arduino crank out data with lets say 1ms resolution, then indeed input buffer overflow will happen, as the program does other things as well ;) Well, I am not sure, what you are asking for ... What is happening on a DOS machine running, e.g., TC Logo is: The DOS ISR routines are manipulated such that the timer tick is 1 ms and at that frequency (1kHz) all 6 outputs are continuously (turned on/off) via ISR routines, depending on the software power setting. Thus, outputs do PWM at 125 Hz. Yes. What you need to do is supply +5V to pins 1 and/or 3 of the interface A port. This will then make a transistor inside happy to enable the opto couplers driving the 6 #9750 input data lines. Please feel free to ask more - I am one of the 5 people on this planet interested ... All the best, Thorsten P.S.: My interface A DOS/QBasic control program "Q9771_3" is here: https://bricksafe.com/pages/Toastie/qbasic-programs There is also a brief program description (PDF) as well as the .BAS and .EXE file. The QPWM_5.BAS program just illustrates, how the PWM is done within TCLogo.

System rocks Best, Thorsten

Hi @Bliss, oh wait! Now, this is nice information: I did not read about that anywhere! In other words, the non-zero condition of byte #1 in the 19 byte frame could be used for emergency like behavior, e.g., stop all outputs, right? And byte #2 of the frame is then identical to what they did on interface A: You always have the status of the outputs available. NICE!!! Now interface B is then really a modernized version of interface A: Both have a STOP button (physically stopping of all outputs of interface A and software information delivered in case of interface B - the interface still sends the full frame set of data back at the same speed, regardless of the blinking - I was wondering about that! Thank you for that information!) Both have inputs and outputs accepting different sensors (interface A touch and light/rotation and interface B touch, light, temp, rotation) Both have a permanently activated output for testing (4V on interface A and 9V on interface B) Interface B has of course more inputs and outputs than interface A, but the operational philosophy is essentially the same. With the exception that you always have to ask interface A for its sensor and output status, interface B delievers that information every so many ms. Plus, PWM signals have to be generated by the attached computer using interface A, whereas interface B is providing that on board. I thus changed my COM ISR code accordingly to: - SNIP - IF LOC(1) < 19 THEN RETURN 'record not complete; 2x18 (etc.) works as well IF ASC(INPUT$(1, #1)) <> 0 THEN 'red STOP button pressed once (LED blinks) flag.stop% = 1 'Turn off all outputs ELSE flag.stop% = 0 'resume normal output operation END IF OStatus% = ASC(INPUT$(1, #1)) 'bit encoded HGFEDCBA; 0=off, 1=on - SNIP - Works perfectly well! Again, thank you very much!!! Your post really clarified a lot of things. All the best, Thorsten

Hi @Bliss, very nice description of your work! Thank you very much! I am looking forward to seeing further progress on your side - I love ESPs as well. And they are very good for stand-alone automation tasks! Now, currently I do something similar (interface interface B :D with my rather modern laptop) but I try to make it such that the resulting "code" can run on an IBM XT or Win 98 (and below ;) machines. So my approach is using MS QBasic (1.1) or MS QuickBasic (4.5), the latter just to compile my program to COM/EXE files, the XT loves so much. Basic runs within DOSBox-X (not DOSBox though as a) the former is actively developed and b) runs rock solid as a "simple" Windows(64) app plus provides full and stable access to USB ports which then interface well with interface B). What I found through some multiple hour long stress tests is that there was (so far) no glitch at all regarding the serial link. I thus simply strip the two leading bytes and the last byte of the 19 byte frame. My interface B is also happy with receiving a "stay alive" character (any, as others have said) every three seconds. I just have two "interrupt" handlers: One is ON COM and the other ON TIMER; this then works like a charm for hours. I need to make the handler as fast as possible, as XT's are a bit on the slow side :D, thus it looks a bit weird, I guess. The main DO/LOOP runs "on its own" and just watches the IDproc array to decide what to do. IDproc content changes only when there is something new ... '---------------------------------------------------------------------------- 'Interrupt handlers '---------------------------------------------------------------------------- ComHandler: 'input# raw byte# raw byte pair# ' 1 15+16 7 ' 2 11+12 5 ' 3 7+ 8 3 ' 4 3+ 4 1 ' 5 17+18 8 ' 6 13+14 6 ' 7 9+10 4 ' 8 5+ 6 2 'Resolution of inputs = 10 bit for A/D; rotation sensor is different 'First byte = high 8 bit, bit 7+6 of second byte = low 2 bit IF LOC(1) < 19 THEN RETURN 'record not complete; 2x18 (etc.) work as well r$ = INPUT$(2, #1) 'dump first 2 zeros FOR x% = 1 TO 8 'read 8x2 data bytes and process them IF IStype(x%) = 5 THEN 'rot sensor data treatment 'IDraw(IDindex(%)) = XYZ ELSE 'all other sensor data treatment 'data are read from the head of COM buffer (new%), and stored in the 'respective sensor array data location 1-8, but only if there is a change new% = ASC(INPUT$(1, #1)) * 4 + ASC(INPUT$(1, #1)) / 64 IF new% <> IDraw(IDindex(x%)) THEN 'new<>old flag.new% = 1 ix% = IDindex(x%) 'save interpreter reading time IDraw(ix%) = new% 'store new data (as old) SELECT CASE IStype(x%) 'process data and store in IDproc CASE 1 'A/D - save data as is for display/programming IDproc(ix%) = IDraw(ix%) CASE 2 'TOUCH IF IDraw(ix%) < 1023 THEN IDproc(ix%) = 1 ELSE IDproc(ix%) = 0 END IF CASE 3 'LIGHT currently do nothing CASE 4 'TEMP currently do nothing END SELECT END IF END IF NEXT x% 'checksum check goes here r$ = INPUT$(1, #1) r$ = "" 'Dump checksum or check goes here RETURN KeepAlive: 'Send some char every 2s (official time) 'official value to be sent is &H2(?); any value works; CHR$() not required PRINT #1, 0; RETURN This is all very preliminary, but so far I will use this code to create a small text based "UI" and then come up with some programs for "robotics" or the like. Best, Thorsten

I believe this is the perfect place to post your very nice find (and fix)!!! There is essentially no other forum that fits any better, I believe. Would you know whether these motors also work within the enclosure of 4.5 "Technic" motors? These sell really cheap on EB, but I always lean towards fixing a suffering motor rather than dumping the entire assembly, just because it makes noises. Thank you very much and all the best, Thorsten

Well ... there is no hate, I guess. It is more - train fans are not ... that many. And (not many) x (possible highest train set price ever accepted) does not match their (F1 set price always accepted) x (so many). It is not hate nor rubbing. It is revenue. TLG has departed since long from any "fan" oriented ... which is, in a shark tank, a reasonable strategy for surviving. And making tons of money, of course. The fan oriented love thing only works, when there is no competition ... Best, Thorsten @Lyichir Seconds before my reply, I entirely agree with your assessment.

Aww, come on, flowers are beautiful! May I cite from one of my favorite movies? "Oddball : Why don't you knock it off with them negative waves? Why don't you dig how beautiful it is out here? Why don't you say something righteous and hopeful for a change?" Flowers also sell so much better ... TLG simply surfs the botanical revenue wave - you guys are the motor heads, come on, you like dirt, don't you? You will accept a lill' azure here and there, won't you? And blue pins? Color is ... beautiful. Oh my. Well, I am so happy that now there are >true alternative< companies out there, should TLG go down the toilet someday in the (near) future. I have my act together: Used, old school bricklinked or eBayed parts will more than suffice for me. "Like a true nature's child, we were born, born to be wild We can climb so high, I never wanna die" Rock on, Thorsten

wait, this should be added to the program: ThisReply% = (no-brainer AND LEGO) AND (Ducati AND fans) 'AND = logical and Best, Thorsten

Well - it all went well Just as a summary: Tom's C# exe (LEGOInterfaceB.exe) - runs flawlessly on Win11/64; needs a freshly powered CLI and freshly started LEGOInterfaceB.exe. On a second attempt connecting to the CLI, it says "wrong reply". Power down the CLI and restarting LEGOInterfaceB.exe does the trick. Anders Isaksson's Delphi exe (BrickLab.exe) runs flawlessly on Win11/64. TLG's Control Lab DOS software runs flawlessly within DOSBox-X. My absolute preference What to say, serial ports, particularly RS232, rule. BTW, the CLI has a PCB trace from pin 6 of the 9-pin DSub socket (DSR, data set ready) into the innards of the thing; this is not even mentioned in the corresponding CLI documents. Here, only pins 2, 3 (RX/TX), and 5 (GND) are referenced, as confirmed by many in this thread. I guess TLG wanted to make sure that as many as possible computers recognize that the CLI is always "ready", some hardware may check DSR. The RCX serial IR tower cable + RS232 1:1 gender changer (male/male) work fine. This cable is essentially a null modem cable. GND of the RS232 terminal and GND of the CLI power supply (9V, unregulated DC) are not connected, i.e., there is a complete electrical isolation of computer (RX/TX/GND/DSR) and CLI, as done in Interface A as well. A bit of an overkill, but who knows what teachers such as @JopieK come up with. Or me ... AND YES, I AM JOKING Next up: Testing on my Toshiba 4090 laptop and the IBM XT, the latter will most probably fail: 256 kByte of memory ... ctrlab.exe has become a memory monster - DOS making windows ... in 1993 ... All the best, Thorsten

Thank you very much for writing this up. It was (and still is) a great pleasure to read some passages of your text over again. I sure hope many people have read, are or will be reading your post. I did earlier this morning, then walked the dog, then had three coffees - and still think about your thoughts. I shall write more - I very much appreciate when people share personal deep thoughts on matters of this kind. There may be a "wider perspective" though - or maybe it is only a different view ... I need to assemble all my thoughts on this. By the way, this alone, making me think about complex matters, is something that makes me very happy. So thank you very much again! You wrote you started your "LEGO assembling career" (I bluntly call it that because you also wrote you never "moced", except in Stud.io) in late 2016. And now you are about to donate most of your collection. That is a time span of about 8 years - within a period, TLG makes ever-increasing tons of money by selling 18+ sets, along with these 1 piece per step instructions, resulting in boring cartoon-books rather than instructions; they are made for relaxing rather than thinking. I recently dragged out some older (< 1990) instructions and - well - I had to figure out where to put the 20+ pieces of one step. Which is so much more fun than attaching a "color coded" 2x2 plate to a highlighted place in Step 42 of 666. This alone may render a disassembled set, stashed away in some closet, a pile of plastic bricks. And many of such sets a burden in many regards. I am totally with you. From that perspective, essentially with everything! But let us widen the view of the camera a bit. I turn 63 early next year. I got my first LEGO set for Christmas in 1965. My parents never had the money to buy any larger sets, nor many. When my first LEGO world came to an end, I was 15 years old. At that time, my "collection" of bricks and plates (not sets, these were all atomized - in LEGO world only of course, where the H-atom analogue at that time was a 1x1 round plate) found space in a medium-sized plastic container. And for these 12 years I was "mocing". The necessity to come up with a dedicated word for "building on your own" - or "creating" - is a bit disturbing. But so is "googling", whatever. Languages develop over time. I missed out on Technic. I missed out on early LEGO electronics. Completely. Then, in 1998, shortly after our second daughter was born, I saw the LEGO light again: The RCX programmable brick - along with Technic ... Today, I am "immersed" in brick-built stuff in my home office. I am very lucky to have a wonderful family, an attic for me alone, I am writing this literally surrounded by plastic. Do I feel bad about plastic? Yes and no. Here are many of my own creations as well as display models - the latter mostly not from TLG, other companies can do much better, when it comes to display models. The thing though is: "Creating", "imagination", "construction", "vision", "trying and failing" (there is only one way to "learn": You need to fail and then succeed), "learning" ... this was, was LEGO was about back in the days. This has been said so many times here and elsewhere ... My last purchase of a LEGO set costing >$10 is years ago. MK, BB, Pantasy do get my money for (display) sets - and even this faded away. Today, I buy pieces only. Mainly old LEGO electronics and >old< Technic, the bricks and plates with holes in them . This is my view on the plastic around me. A bit of nostalgia, good memories, and endless hours of thinking and creating. With old LEGO stuff. All the best and make these children happy!!! Thorsten @Mylenium and @MAB: Gentlemen, I just read your posts; I am so thankful of beeing a memeber of this forum. It simply feels good reading such replies.

Heehee - me too! I am seriously colorblind, so all I see in your photograph are three different colors: There seems to be green (top right), gray (right) - and well - some shade of yellow I gave up on identifying any colors other than the "real" black, blue, green, red, yellow, light gray, light bluish gray, dark gray, dark bluish gray, and taataaa "white". The latter comes in a broad variety of "yellowed" states - which simply means: Could be white. I also decided that this makes my life much easier: There are apparently some issues TLG and other companies have with producing stuff with the same color in the same color. I don't believe in these rumors Best, Thorsten

@evank this is going to be >very< exciting! On another thought: Do you have an RS232 (serial) card on your Apple? I guess so - this would mean you can operate the CLI from that machine using Apple BASIC; maybe you have already done so. I am reserving some time between Christmas and New Years for a little coding using QBASIC for my IBM XT operating the CLI ... Best wishes, Thorsten

Hello @maehw, I believe this may be not that successful, but who knows. @evank did the scanning of the book, which, if I recall correctly, was sent to him by Helmut Albrecht, one of the authors. Back then, Helmut was high school teacher and later became Professor at the University of Education, Schwaebisch Gmuend. I have been in contact with Helmut last year and this year, a very nice individual. He tried to find stuff related to TC Controller and LEGO Technic Control in general - to no avail. They had issues with water damage to their building/s etc. Helmut also contacted Herbert Hödl - but again, all TC stuff they had (and that was a lot) seems to be lost. Herbert has retired since long, Helmut retired recently and has a long list of non-LEGO related activities. I then contacted LEGO dacta customer service and told them the entire story with reference to EB etc. They actually replied and told me to be patient, as they wanted to inquire at LEGO Archives in Denmark. Evan and I were particularly interested in the TC Controller software as well as PASCAL code implementation, as discussed in the reference book. TC Controller provides, as the LEGO Interface in combination with #9771 and TC Logo, PWM control. Well, what should I say: TLG decided that it is not possible to release any further information or even software from their archives due to patent and NDA regulations. Wow. That software is from <1990 ... about 35 years ago. And at that point, we "gave up" - if you have more success, please report here! All the best, Thorsten

If anyone, chances are @evank may know ... Best, Thorsten

I completely agree on this. I am in the same boat and used ESP32's and even Vroom boards for far less demanding tasks than yours - programmed using the Arduino IDE or the VS Code IDE with the platformio plugin. This is simply brilliant, @LabManager! Best wishes, Thorsten

Heehee - me too - this very morning! For €80 from a BL seller located in Northern Germany ... we'll see "what" actually arrives He camouflaged the interface as "electric programmable" - never ever expected it there, I mean, it is electric, but not programmable - only to realize that the "Code Pilot Bar Code Sheet, laminated, 2 sided (paper size A3)" is listed in that category as well. I guess I am too narrow-minded Well, I don't like to play with smart devices that much - born a couple of years before the ARPANET was invented, I like to play with 8- or 16-bit machines running QBASIC programs, I love CP/M and MS-DOS <4.0. Well, the programming is much more comfortable on a modern laptop with DOS emulation, but then I copy the programs to the real machines. So if all goes well, I shall code a QBASIC/QuickBASIC program for that beautiful machine ... and then run it on my IBM XT. As that one has no HD installed, the program length is a bit limited, but then 100kByte of compiled QuickBASIC code represents a sheer endless litany of code lines and subroutines This is going to be fun! All the best, Thorsten

Wow, how cool is this!!! Thank you very much for sharing and walking through the installation process, @BatteryPoweredBricks. Also, very nice video! And congratulations to @diegobaca - simply incredible work. I don't have an Interface B - these are for sure excellent pieces of LEGO engineering. Too bad, they forgot how to make such fantastic electronic devices All the best, Thorsten

Welcome to the club @maehw! Your diagram is marvelous - I can't find anything wrong. Thank you for your effort!!! Just recently I though trying the "modern computer link to 9750" with a Bluetooth-2-USB adapter, these HC-05 (or HC-06) thingies. Works like a charm. All you need in addition is an Arduino - this time I used a Pro Mini, which essentially is a Nano without USB port, as the HC-05 does that. I made an ugly socket to connect both - this way I can use them for other things as well. The Pro Mini gets nicely conditioned 9V from #9750; I just soldered two wires +9V and GND to unused pins 2 and 4 of the 20 pin socket of the Interface A - the Pro Mini has a 5V regulator on board and supplies that to the HC-05. The nice thing is: Wherever you place the #9750 box with the BT extension, you can access it from your computer, as the HC-05 just becomes another COM port visible in device manager BT after pairing. Then edit the DOSBox-X config file in the serial section, it all works: More here: https://bricksafe.com/pages/Toastie Will post that in the next weeks along with an updated QBASIC program. All the best and have fun! Thorsten

Lawsuits, the final frontier ... Well, I hope, truly hope, that The LEGO Company, or The LEGO Group, or LEGO, The One and Only, actually rolls out better sets than the competition does. That is all there is. Don't tell me about ethics and costs. Just get - dammit - better. And simply cut the cost saving crap arguments. Should these apply, well then, goodbye. TLG is not a religion, it is a for-profit, totally for profit oriented company. As any company is, in a for profit-oriented world. What a surprise. In this world, lawsuits >sometimes< work. Generally, simply being better, even if otherwise "unlawful" copying is happening, assures success. Just be better. And don't wine so much. Rock on, Thorsten

I know We collaborate with some of the folks making them. This dissolution is nevertheless a somewhat matter of (currently little) concern, as the stuff added dissolves within the battery to presumably - and in my world hopefully - something not causing any harm some years down the road. Or as they call it - in the long run . Well, we'll see ... so far, resurrection of apparently dead LiPos is of central concern in this discussion. Good night and all the best, Thorsten

That is all cool and nice, but this is for "many years storage". Not "6 months not used". However, 6 months without charging it from time to time and having a circuit that is constantly sucking current, well, will drain the LiPo on that timescale. It always depends on the circuit of course. Some need more than others. No idea what the BW sucks, when turned "off". Partial charging (well, better close to full, but not fully full ;) is one good thing to do when storing a LiPo. But the most important thing though is getting it off from any circuitry. In reasonably well-designed devices, actually "inside" reasonably well-designed LiPos, there is always a protection circuit preventing deep discharging, overloading etc. I just arbitrarily visited GitHub for some info: https://github.com/xlfe/conservative-lipo-protection. That's also (very small) electronics usually hidden under some wrapping foil around the otherwise ugly LiPo cells, but once the thing tripped due to deep discharging, you need to know how to resurrect it - and @Zerobricks is at it, I guess Best, Thorsten

Nice that it worked! However, there is no "killing". There is chemistry going on inside a LiPo. Or in any battery/rechargeable. A true one-way battery delivers voltage and thus current as long as chemical redox reactions inside that thing find a way to get to a lower state of energy/entropy. When that chemistry is finally happy, i.e., it is at thermodynamic equilibrium, the battery is usually considered "dead". Which is nonsense - such a battery has found chemical peace. Rechargeables are essentially the same thing, but the chemistry inside is reversible. "Charging" means driving the chemistry to one equilibrium, i.e., the charged state. Draining it means driving the chemistry to - well - the "drained" equilibrium. Batteries don't allow you to reverse the redox reaction system, which is, from a chemistry cost standpoint, cheap: Trash them. Chemicals used inside rechargeables are comparably "expensive"; but need some attention It appears as if your storage state was something in between the two extremes of equilibrium: "Allowed fully loaded" and "allowed empty", which is >not< zero Volts, but something well above zero. Deciding on "allowed" versus "not" is the task of "electronics" ... when that electronics was designed as: "X Volt is bad", the "thing" will just play dead, and not allowing charging the LiPo. But the LiPo is certainly not "dead", it is out of (self-defined) safety specs. Best regards, Thorsten

Hey! Don't get me started :D - I am happily using Windows since Win 3.0 was introduced. And before that, I jumped on board with DOS 3.0. And yes, I have no clue, what I am doing right. It crashed back in the days now and then, but later, it simply worked - I may have used it without my men-in-black-sunglasses My last blue screen is win-millennia away ... Whatever (believe me, I have 500% Mac, 200% Linux, and 400% C++ totally convinced absolute freaks (i.e., very nice individuals I have very much fun with) in my research group). They also happen to reinstall this and that from time to time - I never reinstalled Win - I fixed it - somehow). Maybe being a chemist helps - we ... try out things, and claim of course it worked, when it worked. And don't talk about it, when not. Now, what is going on here: It would be very helpful to learn about the different scenarios. One is: LiPo charged half-megablocks, put away for months, attempting to recharge then and . No way to resurrect it. What else? LiPo fully charged, put away for months - ??? It would be helpful to know exactly when your charging/resurrection of the BW did not work anymore. Are there any phantom currents, when the BW is turned off? No. There are real currents! It has to recognize the "on" button, when the charger is applied, all that. So the thing listens, what's happening on its in/outputs - and that needs some current to flow. After months, the LiPo is totally drained, should there be no totally drained protection, as virtually every LiPo circuity should have. LiPos don't like to be drained to zero - or better below a certain level. Should these BW folks forgot about that: Screw them. Which does not help at all. But: Totally drowned LiPos can be resurrected; you need to disconnect them from the BW circuitry though and then treat them nicely. Here is one link, don't blame me, if that does not work: https://www.instructables.com/Restoring-over-discharged-LiPo-Lithium-Polymer-bat/ This is all pure speculation - I don't have a BW. But I have devices discharging below the critical level, if unattended. Should BW folks talk about this issue: For sure! But don't simply trash otherwise nicely designed systems, as I will never abandon MS Folks, here is to feeling good: Best, Thorsten

Welcome to EB! No, you did not. Well, sort of not. Hmm, who really cares about strictly "not", I certainly don't. Not in this forum, I believe. Someone may notice the blurred studs in your photographs This is a nice motor you are using! Are there any issues with the friction of the gear when using different makes and models of switch points? Or do you manipulate these as well, as I do? All the best, and thanks for sharing, Thorsten

And I bet, you will be not only granted entry to the heavens, but surely be complimented in ... and then maybe asked how to fix the burnt motors of His train layout, who knows ... Have fun and all the best, Thorsten