Toastie

I believe "lacquer thinners" are meant, right? The cellulose part is addressing the paint to be dissolved, not the thinner. Oh, I would be >very< careful with these, as these are formulations and you never know what is actually in there. Should the company comply with current regulations (EU/US) then Wikipedia is right: https://en.wikipedia.org/wiki/Lacquer_thinner ; such approved thinners contain mostly acetone and some aromatic solvents (low VOC). Well, acetone falls into category D:Severe Effect in the list you cited ... in fact, acetone is very well suited to "glue" LEGO bricks together. Not as permanently as superglue, but it comes close. With acetone, you can actually wipe off entire ABS layers and strongly compromise the shiny surface. With the chance of permanently adding residue from the unsuited cloth you were using. Or remains of the sticker residue ... Here is one example (available in the UK): https://www.rawlinspaints.com/home/accessories/solvents-thinners/5142-rustins-cellulose-thinners.html Srcoll down to "Product Specifications". The list that opens says "Ketones" as major component; acetone is such a ketone ... Light petroleum/light petrol (German: Reinigungsbenzin) based stain removers may also work, I suggest first use a crappy LEGO brick - chances are, it will not damage it. Best wishes, Thorsten

Yeah, sure, if these are the reasons for qualifying to appear on an otherwise rather strict forum regarding other brands making bricks or sets. I never said I don't like, I said I don't get it, as a) there is the Community Forum and b) the topic popped-up out of nowhere, if I remember correctly. And as a generally curious individual asking/thinking too many times "why" (they hate this questions during any kind of exam ), it just pops in there, from time to time. That's all there is to it. I am very happy with your suggestion, makes absolutely sense. Best regards, Thorsten

Hi Thomas, And that is perfectly fine! Zero criticism from my side, on the contrary!!! This is what open source is about! Legoino is on GitHub for everybody to improve - at least this is my understanding of what Cornelius meant to create. I strongly believe that open source is the most powerful way of developing, improving, and maintaining software (of any kind). I myself did change Legoino here and there for my own needs. Oh yes, I am 100% with you. I pledge allegiance to the gods of C and C++ ... BTW, I myself would like to have the brain in the hub - well, there is one in there, and a powerful one, but it appears as if memory size becomes an issue, at least with the City hub I love so much. With the ESP memory monster, even large and diverse libraries (e.g., fancy display stuff, PUp, VLL, IR (all the LEGO protocols), WiFi ... all in parallel) are readily available all the time, when the program runs. And lastly (I may be wrong as I grew-up in 8-bit world, when one single bit in 64kByte of RAM was more expensive than 1 million bits in 64GByte RAM ; John McCallum has very nice data regarding memory, drives etc. on his site, https://jcmit.net/mem2015.htm), I find it easier to coordinate inter-hub communication with an ESP (or the like) acting as central brain. At least I did not have any issues with timing, as my LEGO stuff operates on much smaller time scales than BLE communication and data crunching on the ESP. But again: Never tried PyBricks and the like, all is just from just reading here and elsewhere. That is the core of the matter. Open source. Same in research, real life, everywhere. All the best, Thorsten

Well, we do in the Community Forum around here. Maybe not in the Technic et al. Forum. Or better, "we are allowed to do that". I never got why CADA is in this very forum ... there will be reasons. Best, Thorsten

I have absolutely no clue, whether there is a chance that either this German company ("Mellerud") has subsidiaries in the UK or not, Brexit is Brexit, but this product will absolutely work: https://mellerud.de/spezial/aufkleber-und-klebereste-entferner?gclid=Cj0KCQjw4bipBhCyARIsAFsieCz2XYG2EvXZ8mhvzMl6H92foouhWoYktIqhdwqu2BQSqMjIRhZi1sAaAmjyEALw_wcB Maybe there is something similar/comparable in the UK; I for sure know it works without damaging ABS (and many other plastic materials). All the best, Thorsten

So cool! Isn't that the Legoino approach as well? Steffen quoted Corneliuz' approach - which I am using: Connect the remote to an ESP32 (or two or three ...), connect hubs (one two three ...) and then let the remotes do to the hubs, what you program into the ESP32 (using the Arduino IDE). As @Lok24 pointed out, this sign-up procedure is a bit on the C++ side, but once you made such a sign-up work-flow, it works flawlessly. An ESP32 dev kit board I am frequently using is not as small as an M5 Atom "cube"; but hey, both share the ESP32 chip :D. And can be programmed using the Arduino IDE. I like this idea of shared tasks/functions very much: Instead of direct remote-hub communication, a third, and very powerful device is coordinating remote and hub com: "The Server", clients sign up to (remote(s) and hub(s). As ESP 's have virtually unlimited memory (recall, that I come from the 80's, where 16kBytes were ... vastly overpowered attempts of freak companies to tell us, we need more memory And yes, I know that an ESP has memory stack overhead you would not want to know, but: It works nicely. Totally cool project here; as said, I love it. Verrry much!!! All the best, Thorsten

What I love so much is your love for the detail. The interior detail, that is. I would so drift away in your store, would be sooo excited to climb the stairs and find out what is up there - I would spend hours and hours in there. This is so nice, and really resembles what an old (or antique) toy was back then: Excitement, something new in every niche, tales of mystery and imagination, fun. Never wanting to leave feeling ... And yes, it is beautiful from the outside as well, keeping the inside ... an adventure, to say the least. Thank you very much for sharing! All the best, Thorsten

Wow!!! Technic at its absolute very best. One motor, about a thousand functions - and you have to manually pull and push levers in the right order and have to remember which one causes what motion. How cool is this!!! All the best, Thorsten

And it will be exciting. Truly exciting. Whatever you come up with - big, small, medium - it will be exciting. And inspiring and motivating - I love your approach. No way that I could do it, not the point. For me, it is the passion (skills, OK, yeah, this needs incredible skills as well ... man) All the best, Thorsten

Ah, I see. That means invasive changes to the hub/s right? Adding ports = hardware additions. Now I get it. Well, this is going to be very interesting. All the best, Thorsten

This sounds very exciting! I don't get the "without any IO/UART" bit (I am old, a boomer, grown up in 8bit world) - IO is related to the hub ports, right? Physically, there are two (City hub) or four (Technic hub, or six, duh - with the Spike whatever hub). So I/O is there and nicely supported by the LEGO firmware (forget any outside Android crap). So, what do you mean by UART? In the olden days, this would be an Universal Asynchronous Receiver Transmitter, which is BLE by default, the wireless access to the hub. As far as I understand, LEGO hubs do have IO/UART heavily supported by their firmware factory installed. What am I missing? Best, Thorsten

I take it that you are using PUp train motors for your engines, is that right? I am asking, because PUp motors having the "tacho" function (it is just a - fancy - rotation sensor; there are some LEGO motors having this feature, even with rather low footprint), allow you to use the "speed" rather than "power" command. I know, has been discussed over and over again, but I can tell from experience that the moment you use that feature, the whole world changes. Particularly when using the acc/dec profiles of your choice: the trains closely and swiftly adjust the necessary motor power to maintain or arrive at the speed you wish or the profile asks for. This is bolted into the LEGO wireless PUp protocol and runs flawlessly when using e.g. an ESP32 device as control unit (the remote/s and hub/s connect to). And for sure, if you have to redesign from PUp train to PUp M/L motor, it means the hell of a redesign - and may be unacceptable. But again: It is worth a try; after redesign LEGO trains almost behave as true trains do. No speed loss in curves, no issues with load. Provided of course that your motor does not max out at 100% power; at this point, no speed regulation is possible. But that again is a design issue. Best regards, Thorsten Which is totally cool!!! However, the original firmware running on the hubs is really nicely designed. TLG's smart device apps are - sorry to say - not my cup of tea and are buggy and shaky, but when you use an ESP32 as your central device and use (e.g.) Legoino libraries within the Arduino IDE, you can code in C++ from dusk to dawn. And man, you can do crazy stuff. Best, Thorsten

@evank Hi Evan, All, just to keep things straight: As posted in the Technic etc. forum, I'd like to introduce another 8bit-wonder from the 1980's controlling (writing to and reading the outputs/inputs) the LEGO Interface A #9750: The Sinclair ZX81, which appeared in Germany in late 1981. I still have my "issue one" machine; fixed the power supply and 16kRAM pack in 2021. Two additional TTL chips were added to the ZX81 "main board" (well, it is only one board, and only a small one); the ZX Printer interface I made for the Speccy is fully compatible with the Zeddy's edge connector exposing the Z80 system bus: Top: Zeddy hooked up to the ZX Printer interface, which connects to #9750. Bottom: The Zeddy all set-up for playing with LEGO as well. Here's the link to the main post - as usually with a 10s stupid video showing that the Zeddy actually speaks with 9750): Here are my three contestants in this challenge in one picture; the monitor is hooked up to a 4-port video/audio switch shared by the three musketeers - and a C64, below the Atari. In the photograph, the Zeddy is hooked-up to #9750 and the screen shows that is had heard from Deep Thought: BTW, as said in the main post, there was this ad back in the days (1983); well here they are happy - and in color: All the best, Thorsten

Dear All, motivated by Evan’s 9750 EuroBricks hacking challenge, I tried to get my beloved ZX81 (Zeddy) in touch with the LEGO Interface A (#9750). It appears as if TLG never wondered into Sinclair world; they were more on the professional IBM, Apple, Acorn, Commodore, and Philips side of things. Expensive things that is, not on the el cheapo side, where I was. My Zeddy is an ISSUE ONE (as it is printed on the PCB, I am not exaggerating here!) machine from 1981 … Does the text above sounds familiar? Yes, I just c/p’d from my ZX Spectrum thread posted earlier. And yes, my posts in this regard may be annoying, but so are super cars. Or Cada stuff, 2++ m tall cranes, ++$600 sets – >only< to me, that is! And here is to feeling good! The Zeddy is one of a kind, I can tell … its design is beyond belief – in the absolutely positive sense. Made for the masses, using incredible techniques. IBM just went ballistic with regard to parts and pieces in their original PCs and then XTs (which I am madly in love with). 8000 something German Mark in 1983. And TLG was sailing along – after three more years they introduced Technic Control, and PC’s, XT’s, Apples, and so on were the prime machines targeted for that technology – in schools that is … no way to go cheap there! There was a nice ad in the back-then magazines (this one from the 1983 April issue of Sinclair Projects: So, here we go again: The Sinclair “interface” for LEGO Interface A is exactly the same as described earlier on EB for the ZX Spectrum, so there is nothing to add. The edge connector layouts of the Speccy and Zeddy are “identical” (for the Zeddy’s contact range); thus the interface for #9750 I built into the ZX Printer case along with the printer’s edge connector plug/cable are fully compatible. All that is needed is (again) CE#, RD#, and WR#; CE# is enabling reading/writing from/to the interface and includes resolving address and memory request (MREQ#). Why not I/O request (IORQ#) as for the Spectrum? Simply because standard ZX81 BASIC does not feature the OUT/IN command/function. Machine code works well using the Z80 out/in directives as well on the ZX81 of course, but I like to keep it simple; BASIC command POKE and function PEEK are my best friends. Both issue MREQ# rather than IORQ# for getting access to the data bus. The really crazy part is the address decoding, which should be compatible with the 1kByte ZX81 base unit as well as with a Zeddy having a 16k Sinclair RAM pack attached; who knows what I will program into these sheer endless rows of empty bytes … Here’s what we are dealing with: The 8kByte ROM of the ZX81 has 13 address lines A0 to A12 (0x0000 to 0x1FFF) – so Sinclair only attaches these with no further decoding of A13, A14, and A15. In other words, the ROM also responds to addresses from 0x2000 to 0x3FFF, and so on (these additional “regions” are sometimes called “shadows”). However, for one, there is the clever Ferranti ULA, which is connected directly to the Z80 CPU using all 16 address lines, and always knows what’s going on in the system. And the ULA can control the ROM and RAM access via its RAMCS# and ROMCS# outputs. It does clean up the address mess a bit but certainly not everything, as it has other, way more important things to do. If you want to dig any further, I recommend starting here: https://www.zx81keyboardadventure.com/2023/02/zxio-interface-for-zx81-part-2.html As my Zeddy does have a 16kByte RAM pack attached, which is located at 0x4000 to 0x7FFF, followed by ROM shadows 3 and 4, which are followed by 16k RAM shadow 1, all 64k addresses are in use. Furthermore, the 16kByte RAM pack does not have a RAMCS# input. I did not want to open it (again that is, needed to do it a couple of years ago to replace two 4116 memory chips); I was thus left with cleaning out ROM shadows and use corresponding addresses to read from/write to the ZX Printer interface which in turn talks to #9750. This approach has been frequently used back in the days as well of course; see for example this article also referenced in the above zx81keyboardadventure blog thread on page-1. And without further ado, here is my approach to a) free up addresses 0x2000 to 0x3FFF (the first ROM shadow) and establish 8 (memory mapped) I/O ports for – well – controlling 8 #9750 interfaces: As I am going cheap here, in the tradition of Sinclair Research Ltd., I am using only 2 TTL chips from the 1980’s (this an essential is part of @evank 's challenge!), to get 8 I/O ports (and not only one, as described in the ETI article referenced above) at the addresses 0x2000 to 0x2007, when address lines A0, A1, A2 are actually connected to the 3 channel select inputs of the 74LS138 de-multiplexer. OK, in principle only; currently I have hard-wired only one I/O port at 0x2000 (8192 dec), as all three channel select inputs of 74LS138 are connected to ground (L), which always resolves to output Y0#. Only when this chip is enabled though, otherwise Y0# is H. Taking advantage of the 3 enable inputs (FE1 needs to be H AND FE2A# needs to be L AND FE2B# needs to be L) allows appropriate address decoding when the de-multiplexed A, B, C input information (3 bits = 8 combinations = 8 I/O ports) is used to select an Y# output port. In the above configuration, A15 AND A14 AND MREQ# need to be L AND A13 needs to be H (= CPU memory access to address 0x2000), and as A-C are L = 0, Y0# then goes L. This is exactly the same approach I used for the ZX Spectrum – in other words, I can use the exact same interface described before built into the ZX Printer case. This is also in the tradition of Sinclair Research, of course; the ZX Printer works on both the ZX81 and the ZX Spectrum. Now the ROM shadow needs to get kicked out; this is done by inverting Y0#, and use one additional npn transistor as “tristate” driver: When Y0# = L, the output of IC2c is H and the transistor pulls the ROMCS# line high (ROM = not responding), when Y0# = H, the output of IC2c is L and the transistor is in “high impedance” state and the ULA can do whatever it wishes to do on the ROMCS# line. The only thing left is to route the Y0# (CE#), RD#, and WR# lines to the interface as well, as was also done for the Spectrum. And now we can add the good’ol Zeddy (Grrrrrr …) to the list of 8 bit machines operating the LEGO Interface A. At >very< low cost: Left: The Zeddy - a full-blown 8bit computer! The tape is for insulation. Soldered extra wires are for connecting to the "interface" shown on the right. This is the circuit enclosed in blue in the above schematic. Left: "Interface" mounted to the PCB. Right: Focus on the 16kByte RAM pack (me and photography, this was on purpose, of course) and the ZX Printer interface connecting to #9750. The Sinclair workspace - here, the Zeddy illuminates the 4.5V light bricks: POKE 8192,63 does it ... This is the program playing the lights as shown in this video: https://bricksafe.com/files/Toastie/zx81/ZX81 8750.mp4 All the best, Thorsten

And add that to the pinned topic as well. This is a major improvement, as far as I am concerned! Best, Thorsten

This is a very nice solution! Did you see this pinned topic? I am not sure about the different power sources you guys are using, but getting rid of that battery compartment really cuts the size of the hub down to the brain. As said: very nice!!! And welcome to EB - this is a wonderful place to be, share, learn! Best wishes, Thorsten

Oh yes! It consists of vaporized aluminum (turned into oxides, so no worries!) and the tiny electric discharge produces - among other things - ozone. And most importantly, some vapors from the black paper underneath the aluminum layer, which are adding a little smoky smell to it. Whenever I take a sniff from a glass of 12 years old Lagavulin, it reminds me of ... well, I liked this smell Best, Thorsten

Thank you @Coder Shah for this marvelous thread. As far as I am concerned, it should be pinned, as it is of great value to the robotics heads in this forum. Topics like this one readily drown in contest entries and so on. This is a true reference thread - and is an inherent part of this forum. All the best, Thorsten

I am closely following your posts here on EB @oracid One thing that is worth watching all your videos, regardless of topic, is education. Every time, I learn a lot. The other thing is: Your friendliness - without saying a word. It is just so enjoyable, and every time they make my day. I always take it as motivation. And finally: This robot is mind-blowing. Simple as that. Congratulations on your achievement!!! With best regards, Thorsten

Well, time-travel is about a comparable endeavor - as you want indefinite clutch power, indefinite geometrical stability, light weight as well, right? And breathe a 20%/80% oxygen/nitrogen atmosphere illuminated by a G2 V star in about 100 millions miles distance, correct? Hmmm ... Tricky. 7 and a half millions years later ... Thorsten

Oh yes - I wonder why I did not kill any of them back in the days - I glued one additional TTL to the CPU and piggybacked others ... But you know that you can get all system components including the ULA, 4116, 4164, Z80A CPU, etc., for relatively small money. There are so many people out there still enjoying these machines! Even mass storage is available for less than €100. That seem to be very exciting projects you have going with the Mega and Unos!!! Did you see this? I am also very much into Arduinos and even more so into ESP32's - this interface works with all sorts of computers (via the blessed RS232 port) ... All the best, Thorsten

Sorry, late to the game. I have seen a similar behavior on some of my 8878's. Sometimes that is. They always perform though. The charger you use is the 10V type from TLG, isn't it? If so, did you try a more capable charger? You can charge 8878 with any DC power supply up-to (very safely) 15V, unlimited amps, as the circuit built into 8878 takes care of "everything". Is pulling for more than 30 min OK? If so, there is nothing wrong to the extent of being worried. Swelling of the LiPo pouches will not show on the outside; there is plenty of room inside 8878 for expansion (TLG did do the math, I believe). I'd just go and let it run. Best, Thorsten

Oh yes, I saw these monsters - how nice to use stereo amps as H-bridge drivers! What's wrong with your Speccy? Any wish to get it up and running again on your side? Best, Thorsten

@Jonas Holy moly - attempts? You call that attempts? Attempts? I call that LEGO Interface A++!!! This is extremely nice - I have tears of joy in my eyes! Are you in the picture above and on Brickshelf? When did you build that nice interface? When did you take the b/w photographs? Do you have any schematics? Programs? Did you program in Sinclair BASIC, machine code, or both? I guess the photodiodes needed some fast code to give reliable feedback? Questions over questions It is so nice to see a Spectrum+ along with a powerful home-built interface for LEGO Technic! Thank you very much for sharing! All the best, Thorsten

What a fantastic train ... others have said what I feel and admire, there is nothing to add. Well, maybe just this: It is personal, I know, but I love the way, Dave is presenting "That's Railroadin!" on his channel (https://www.youtube.com/@ccrx6700). They operate something >remotely< related to what you built (OK, they haul coal, with all lookalike coal cars), at least with regard to the appearance of their locomotives - and their color scheme. Yes, I am color-blind, but rather good on blue and white. And yes, your locos are of different make - I believe. Not the point. It is the love for Railroadin that I believe is common ground here ... I instantaneously thought about Dave's channel, when seeing your beautiful train, the story behind it - simply wonderful. Congratulations and a slight bow (after tipping hat). With very best regards, Thorsten