Toastie

Well, yes, when TLG's bricks are used for turning them into something way better than what TLG ever accomplished. But wait, there is more, there always is: Why not using e.g. GoBricks? These folks may even be happy to cooperate ... or at least some suppliers of GoBricks bricks may be. The lawyers TLG hired in this case behaved like a**holes. The judge - well, you know, a judge is a judge; when the "prosecution" ^^ brings strong legal arguments and there is essentially no tough defense, then hey, what should the judge do. My take on this is: Goodbye TLG, thank you for all the fish. It was fun, it was good, you impressed me when I was younger, and in the end you just suck. I may continue buying this <$4 plastic bag type stuff from you when I am traveling, because I find it rewarding to bring something home for memory sakes. But that should be it. 1965 I got my first LEGO set. 2024 - I did not buy anything from TLG. 2023 it was "used (vintage) LEGO stuff", same some years before - actually these sets and pieces seem to come from a totally different "TLG". I just go East. No end to my hobby there, not even close. All the best, Thorsten

Yup, that's what I heard - and it tells a lot ...

Or you use the superior GoBricks bricks - they have no markings like "GB" just numbers ... That's the thing, isn't it? TLG hires lawyers - from what I understood when watching some YT channels regarding legal issues related to TLG (as said, "they" tore down some small businesses in Germany in the recent past), some lawyers also approach TLG, "offering" low hanging suits to them - and they reply: Do it, or they don't reply. As far as I know, in all this "destroying small businesses" law crap, it is more or less up to the hired lawyer(s) or law firms having a certain reputation (or not), how it goes. Some lawyers are essentially "reasonable" to a certain extent, others like to see blood, solely for seeing blood - and I don't want to know how much the compensation (or better bounty) is, TLG offers for "some success", "success", or "total success". Surely one never sees or talks to any TLG staff or gods! These are simply saints - they don't want to have blood on their hands. Best, Thorsten P.S.: Currently brwosing Pantasy's webshop - and will hop over to BlueBrixx after that ... I wonder why they don't shut down BB in Germany ... there muszt be good reasons

Illegal in one universe. A working solution in another; no "but" required @oracid I am madly in love with the universes you create over and over again. Thank you so much for every of your videos. All the best, Thorsten

When you attach 1x2 bricks in two layers to 4.5/12V rails and then secure them underneath with a further layer of 1x2 plates, it will certainly work. I used 12V rails on one layer of 1x2 bricks + another layer of 2x2 bricks, because I simply had not enough 1x2 bricks. The 2x2 bricks don't add any stability. The two-layer design also allows you to attach supports anywhere you want. Best, Thorsten

That >is< the reason - they simply have no chance, so wipe them out. Also, maybe the lawyer in this case has some fun with it. Is building a certain "reputation". TLG hires these folks on whatever basis ... I simply don't want to know what they are. It has happened now so often - and mostly the small ones, the smart ones, the startups with brilliant ideas go down the drain. It is simply so shameful. Well, it is what it is. For me, a very good reason to simply look at TLG as one option among many, many others. Oh yes, indeed. They have. And never underestimate jealous people, who can't do better. All the best, Thorsten

Says the guy, who is running a ton of 9767 cards in his Apple ][ I am using dead cheap DE9 four-way switches (serial port switches) for that purpose; I searched (a lot) for alternatives but did not find anything reasonably priced. 9 wires leaves you with the 8 data lines, 9750 services + GND. You also need +5V though, otherwise the opto-couplers in 9750 won't work. So what I do is adding a 5V/GND jack to the switch, and, as I like lights, an LED indicating power is applied. The computers are attached through 20 -> 9 ribbon cables (you have to make) and only provide their data lines + GND. The 5V needed to drive the couplers in 9750 is provided by the "extra" power supply (any USB power supply would do). Can make photographs and wiring drawings - just let me know. Best, Thorsten

Yeap, that works. When I was still living in pure-LEGO-land, that was the thing to do. On models/layouts providing that space. The moment you go 6-8 wide mobile, it usually won't work that easily anymore. For GBCs and other ground based MOCs, it may very well be the appropriate solution. Best, Thorsten

Hi @MSF, and welcome to EB! Nice that you unpacked your vintage (they are not "old", they are "nicely aged" !) 12V LEGO trains and tracks for your kids! That must be so much fun for you all! Yes, IPA won't do any harm at all. It gets rid of grease. Not so much of corrosion, that needs more attention. I'd say, first try IPA. I also recommend to use very fine sandpaper on the 12V train motor contacts, but not on the rails. On the rails: Should IPA not do the trick, apply some WD40 (or the like) on a piece of cloth and then give the conducting rails a good go. I'd never use WD40 inside any electronic device, but these 12V conducting rails can take it. When the WD40 worked, I'd clean the remains off with another IPA cleansing in the same way, but that is somewhat optional and just keeping it on the very safe side. Best regards, Thorsten

That is true, but once again, you can easily make your own 9V -> PF receiver power cable! I have done that multiple times. Best, Thorsten

I'm afraid, it does not work in this direction without some cutting wires and soldering. The other way around (from PF battery box or from PF receiver to 9V motor/light). The PF system uses 4 wires; the outer two are permanent +9V and GND as power supply for the PF receiver, the inner wires are supposed to connect to PF motor and lights. When you open up a PF receiver, you will find out that on the PF cable attached to the PF receiver, only the outer cables are used, the inner cables are cut. The PF receiver then generates the PWM signal from the 9V supply and put these on the two inner wires of its PF terminals. And here you will also find the 9V and GND. (PF motors and the PF light have only the inner wires connected inside the motor housing) The cable you are referencing connects the 2 inner wires of the PF terminal to the 9V terminal. When you attach the 9V terminal to a 9V battery box or the train regulator output, and the PF terminal to a PF receiver supply cable, nothing happens, as the now powered two inner wires are not connecting within the receiver. When you google "lego pf wiring" you will find many links to YT videos and also to EB forum posts on that issue. @BatteryPoweredBricks has made excellent tutorials in this regard. Also Philo's homepage (https://www.philohome.com/pf/pf.htm) explains all you want to know about PF - and so much more! Best regards, Thorsten

@evank Hi Evan, All, as just posted in the Technic etc. forum, and as this post will simply sink into oblivion in about a day on that forum, I cross post () here, because this the 9750 challenge thread, which drives me, and I would like to bolster my bragging rights on Evan's webpage: I managed to get the Amstrad PCW 8512 "Joyce" from 1985, a Z80 CPU driven 8-bit wonder, to read/write from/to the LEGO Interface A from within BASIC on that CP/M 3.0 system. The BASIC dialect bundled with the Joyce is Mallard BASIC, made back in the days by Locomotive Software. Here is the link: Here is the video proof : https://bricksafe.com/files/Toastie/amstrad-8512-and-9750/Amstrad 8512 LEGO 9750.mp4 All the best, Thorsten

Dear All, motivated by Evan’s 9750 EuroBricks hacking challenge, I tried to get my beloved Amstrad PCW 8512 (named by Amstrad's CEO Alan Sugar “Joyce”, which is the given name of his assistant) along with an SCA Systems parallel/serial interface in touch with the LEGO Interface A (#9750). It appears as if TLG never wondered into Amstrad 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, were I was. Here is the video proof that it works ;) I did not upload that video to YT - it is too crappy https://bricksafe.com/files/Toastie/amstrad-8512-and-9750/Amstrad 8512 LEGO 9750.mp4 To begin with: Here is my vintage compuing corner in the attic (this room also serves as my home-office) - along with the vintage LEGO stuff, which is controlled by these machines: (1) is the PBrick section (RCX, Scout, IR serial and USB tower, Sybotics with optical serial connection; the Vision Command camera setup is controlled by the Scout; Cybermaster with the RF tower below. The barely visible TC brick sorter robot is controlled by the RCX. (2) is the LEGO interface A (#9750) section; there is a 4-way switch that allows to use multiple computers for the interface: The IBM XT (A), the Toshiba Satellite 4090 (B), which is on a pull-out shelf, or any modern computer via an Arduino USB28bit parallel interface mounted right to the interface A. The 4.5V motors of the TC robot (3) below are hooked up to the Interface A; additionally, a PUp tacho motor and a Technic hub control the lateral movement - synching and programming reported here on EB. (4) is a second Interface A - this again is on a 4-way switch (located above the (D)) to be controlled either by the Amstrad PCW 8512 (C) or the ZX81 or ZX Spectrum (D) or the Atari 1040 ST or the C64 (E). The second Interface A is intended for testing and trying out things; there are 8x 4.5V lamps and 2x 4.5 motors with 2x light sensors on a 32x32 base plate. Both, the interface as well as the Atari and C64 are on pull-out shelves. So without further ado: Here we go again ... 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 Joyce [(C) in the above photograph] 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! Now, the PCW (Personal Computer Word-processor) 8512 was not as cheap as Sinclair’s ZX computers; it cost about one quarter of what IBM charged for their PC. But: It was a fully blown word and database processing system. No built-in graphical stuff, just pure text and number crunching. The OS was CP/M 3.0 (“CP/M Plus”) – which was “the basis” of (or better copied by) Microsoft’s early versions of MSDOS. CP/M is so cool … and of course programming languages also work on the Joyce; as I wrote many times, I am a total BASIC person. Joyce came bundled with the “LocoScript” word processor and with “Mallard BASIC” for CP/M Plus, both made by Locomotive Software in the early 1980’s. The following citation is what I really like about the name of that BASIC dialect (copied from the referenced Wikipedia article): “It was also optimised for speed — it is named after the LNER Class A4 4468 Mallard locomotive, the fastest steam locomotive in the world, once again displaying the company's fondness for railway-oriented nomenclature. In fact, the Locomotive Software name came from the phrase "to run like a train" and it was this theme that was used to name Mallard BASIC — no other Locomotive Software product was named after anything railway-oriented.” And behold, Mallard BASIC is fast! Joyce came also bundled with a 9-needle dot-matrix printer, which mechanically attached seamlessly to the keyboard mimicking a type writer; there are recesses for 2 brackets in both devices. I believe though, virtually >no one< actually used that feature, as it consumes considerable space in front of the screen. Joyce’s brain is a Z80A CPU – my all-time favorite microprocessor. Why? Because back in the 1980’s, I must have referenced the German edition of Rodnay Zack’s book “Programming the Z80” a thousand times as I was fascinated by the performance boost when programming in Z80 assembly code, as compared to e.g. BASIC. All my computers I had back then (and still have today) had Z80 CPUs: Sinclair’s ZX81 and ZX Spectrum, and Amstrad’s PCW 8512 “Joyce”. On the Joyce, almost all Z80 CPU signals are exposed on the back connector along with some other lines. But there is more (there always is): Joyce features a printer port, which is (exclusively) connecting with the Amstrad/Joyce 9-needle dot matrix printer. One can of course connect custom devices to that port, but that needs intimate knowledge of the innards of the hardware. Which is not that straight forward, as Joyce features some rather powerful chips, among them an 80 pin flat pack gate array which does a lot of housekeeping tasks, the well-known NEC µPD765AC-2 floppy disc controller, and even a second microcontroller, the NEC µPD8041AH, which is a programmable peripheral interface controller. The latter features an 8bit CPU, 1kbyte ROM, 64 byte RAM, 8bit timer/counter, and 18 I/O lines, which all go to the 9-needle dot matrix printer! Nothing really easy to hack for the interfacing of Joyce with LEGO interface A, particularly with access from BASIC. Mallard BASIC does provide the command “OUT address, data byte” and the “INP(address)” function for direct Z80 I/O port access, but I would not know how to dig through the PPI controller to read and write to #9750 through the built-in printer port. Fortunately, I got hold of the SCA Systems serial/parallel extension interface for the Joyce. There are at least four such interfaces from different vendors I am aware of. Two of these are the Amstrad CPS 8256 and the SCA Systems interface. At first glance, both their PCBs look identical, but closer inspection revealed that there are differences, particularly in the address decoding section. The circuit diagram and photographs for the CPS 8256 are available on the internet, similar stuff for the SCA interface is not, as far as I know. So I had to do some PCB track tracing, at least for the address decoding. After a lot of beeping through the tracks, I came up with the partial circuit diagram below. I was very happy to learn that the TTL 74LS373 chip (8 transparent D-flip flop latches, as TLG used in their #9771 ISA card for IBM PCs) directly connected to the 8 data out lines of the Centronics port of the SCA interface! From there it went straight downhill. Above: Circuit diagram of the address decoding section and the 8-bit 74LS373 output latch interfacing to #9750. The blue box contains my additions, i.e., a second 74LS373 and a 4x NOR gate 74LS02 TTL chip. Address decoding and data read/write procedure I wanted this interface to act in exactly the same way as TLGs #9771 card behaves: Upon emitting 1) the correct address, 2) the 6 data bits for the 6 output channels of the interface A, 3) IORQ# (# = active low), and finally 4) WR#, the C line of the “output 74LS373” goes H and thus it mirrors the content on the 6 D lines connected directly to the Z80 data bus transparently to the corresponding 6 Q outputs. As there is no change on the data bus as long as WR# = L, all emitted data are securely latched, when WR# goes H again (i.e., the C input of 74LS373 goes L). No more changes of the output lines are possible until the next complete write cycle. OC# is connected to GND and thus the chip has always activated outputs, see below. Well, this is how it is done on the #9771 card. But to my surprise, I did not find any WR# line connecting to the address decoder, I found only address lines and IORQ#. At first, I was puzzled but then realized: The 74LS373 in the SCA interface is for writing only. No data are read from the 8 Centronics data lines; the two Centronics flow control lines BUSY and STROBE# are routed to the Z80DART in the SCA interface. In other words, no WR# decoding is necessary in this scenario. SCA used the 3-to-8 demultiplexer 74LS138 for Centronics port address decoding in the following manner: The output Q7# of 74LS138 goes L (= is selected) when its data input lines A(=A3), B(=A5), and C(=A6) are all H, the enable line FE1(=A7) = H, and the enable lines FE2A#(=IORQ) and FE2B#(=A4) = L. In all other cases Q7# = H. This signal needs to be inverted, and SCA used the second 2-to-4 demultiplexer in the 74LS139 TTL chip to do just that: When Q7#(74LS373) = L, Q2#(74LS139) = H. The decoded Centronics port write address is thus: A7 A6 A5 A4 A3 A2 A1 A0 H H H L H X X X ; = 0xE8 to 0xEF, as A0 – A2 are not decoded The Q2# line of 74LS139 used as simple inverter is routed to the C input of the 74LS373 8-bit latch: When the address is within 0xE8 to 0xEF, the data bus content is latched upon IORQ# = L. However: This approach does work with a Centronics printer but not for bidirectional operation of LEGO interface A: Using TLG’s TC Logo and other programming languages, you can write to the 6 outputs and read back the status of the outputs as well as the status of the two sensor inputs of #9750 at the same address. So this calls for a (very) little tinkering with the SCA circuit board and the addition of a second 74LS373 (read latch) and a 4x NOR gate 74LS02 TTL chip, see circuit diagram above. In addition, pin 6 of 74LS139 in the SCA interface needs to be bent up – there is no use for this inverter after pimping the board. Next the WR# and RD# lines (connectors 39 and 41 on the Joyce expansion port) are wired to the inputs of two NOR gates; Q7# is wired to both other inputs: When WR# and Q7# = L, the NOR gate for reading = H; when RD# and Q7# = L, the NOR gate for writing = H. The latter means that this signal can be directly connected to the C input of the 74LS373 latch for storing write data. For reading back all 8 bits with the additional 74LS373, the corresponding NOR gate output signal needs to be inverted: This signal goes to both, the C input as well as the OC# chip enable input. When OC# = L; the chip is enabled; when it is H, the outputs are in “tristate”, i.e. not visible on the data bus. All inputs remain active though. When C and OC# = H (wrong address, IORQ# is not = L, RD# is not = L) the outputs of the second 74LS373 are in tristate but the D-inputs follow (transparently) the data bus content. When C and OC# = L, data on the D inputs are immediately latched (no more changes recognized) and the outputs are activated, mirroring the D lines content very shortly before C became L for the time of the RD# signal = L (i.e., the Z80 CPU fetches the data bus content). The moment RD# goes back to H (= data are in the corresponding register of the Z80 CPU), the second 74LS373 goes again into tristate. This is in principle how it is done on the IBM XT #9771 ISA card as well. I also used a similar approach for my ZX81 and ZX Spectrum interface for #9750. It is a bit different on my Atari 1040 ST, as the printer port is handled differently on these machines. Here are some pictures of hacking the SCA Systems interface for operating LEGO Interface A with an Amstrad PCW 8512: Left: I had to cut into the SCA interface enclosure to access the built-in 74LS373 - this "channels" all 8 data bus lines as well as +5V and GND to the outside. Also the 6 Q outputs going to #9750 are available. Right: I simply soldered two 1x10 Dupont type connectors to the solder pads of the 74LS373. The wires seen are RD# and WR# from the control bus, Q7# and the new line replacing the Q2# line going to the C input of 74LS373. Left: The TTL chip on the lower right is the 74LS373 output latch I am tapping into (or better onto ;) Right: The add-on board attached to the RCA interface; the front connectors are compatible with the orginal LEGO 20 ribbon wire for the Interface A. As always: Tried to match an enclosure - the golden 1x6 tile is from the stand of my MK Flying Dutchman. 3 windshields make the side walls. Left port: Centronics - still works. Right port: RS232 - still works. Top port: LEGO Interface A - works. And finally, we can add another computer system from the 1980’s, which was not endorsed by TLG, to @evank #9750 challenge list. The chippies used are all from way before 1990. I feel good . All the best, Thorsten

@cbqmp27 I don't have any experience with PyBricks and @Lok24 will know much better! I am just wondering: Do you have to tell some code lines, which motor you have attached? I guess not, as the hub figures that out (at least when running on the LEGO firmware). Also, the LEGO PUp L-motor is a tacho motor - it has a built-in rotation sensor you can use for different tasks and purposes, among which is "SetSpeed" rather than "SetPower". This is particularly interesting for the Crocodile. Using the SetSpeed command makes it run with - well constant speed. The firmware adjusts swiftly the power setting when speed is not as wanted. But again this is all pure speculation. Best, Thorsten

That is what I thought! My all-time favorite PBrick. Now, the RCX running LEGO firmware is not that fast to do PID calculations - it has to do that since that firmware had no built-it PID routines. I guess it runs on another firmware. The RobotC firmware (Dick Swan) was pretty fast - I did implement PID train motor control back in the days. And there are other programming languages as well. However, I cannot discern any rotation sensor. Without - no PID control. I also believe that the 9V Technic motors are in favor of using higher rpm's. Best, Thorsten

@Peppermint_M Thank you very much for that post. I believe this really makes a difference - knowing where it came from and what the initial impetus was, puts many things into perspective. I really enjoyed reading about the history of EB! All the best, Thorsten

Well, may the 1st be with you Day off here too, but wife called for major living room renovations, which started 3 weeks ago ... almost done though. May 1st came in handy for some cleaning frenzy. Anyway: Very nice and really impressive (!) work on reverse engineering that set. It sure needs a >lot< of Technic experience, visual interpretation skills, and then virtual construction. All the best, Thorsten

Oh, I really wish I could help out - but no interface B here, nor Robolab 2.5.4. Hope that someone can help out here on your issues! Good luck and best wishes, Thorsten

100% my take. I am nowhere but YT (videos) and EB - and for picture and "stuff" storage on Brickset. I like to add that we have >educated< discussions here on EB. This forum is as well a repository for so many LEGO related things, from today to going way back. The search function on EB usually results in a mess of hits, but Google has it very well indexed. Nice to read that there are some folks not going nuts on "social media" when it comes to LEGO. There is nothing wrong with sharing ideas, projects and results on these platforms (!), nothing at all! But for me, it is EB. Best, Thorsten

It really is, nice find! However I believe the authors are slightly off with regard to the beginning of LEGO robotics. They write that in the late 1980's it all began with the Interface B using serial communication. I may be wrong (and @evank as well as @alexGS and some others will know better), but I believe it was the LEGO Interface A using parallel communication on a number of computers via their built-in ports (e.g., C64) or LEGO interface cards (Apple, IBM), which started it all. Around 1986. The Interface A directly (more or less ) listened and talked to the data bus of the computer. Evan has composed an introduction to LEGO robotics on his website, which nicely covers the very early days: https://www.brickhacks.com/0.php Thanks for sharing!!! Best, Thorsten

Oh yes, that is true. The whole CM environment is so cool. I have the original software (not) running (on Win11 but) on my Toshiba Satellite 4090, and I really admire the work they put into that true adventure. CM was before RCX, and it was much more play-oriented than programming. More or less the same approach TLG tried (again, but in reverse order) with the introduction of the Scout PBrick after the RCX. Both, the CM and the Scout have rather limited memory space of accommodating about 400 LEGO byte codes - but you can do a lot(!) with that, because you can tap into the countless built-in routines for sound, light and whatnot. I really like this approach: CM and Scout for having fun, RCX for heavy lifting - I have no idea, though, how many lifts were done ... But you need to fire up your CM bricks again - even the moment it recognizes the tower = computer is a blast. Best, Thorsten

Hi Lars, no, unfortunately, I don't. It is one of the "last" ;) vintage items, I really like to acquire. So, on your side, does interacting of Robolab with the RCX work? And if so, how? Do you use the serial or the USB tower? Best, Thorsten

@Carsten Svendsen oh, I can see that so clearly; the Cybermaster PBrick, even without all the bricks and builds, is a true blast! And Technic Gold. I never had any Cybermaster sets back then, but recently got hold of a couple of CM PBricks and RF towers; they sell for next to nothing on BL, which I do not understand. Well, actually I speculate that these $5 prices are caused by the often faulty motors, where the disk magnets inside were corroding; the same issue some 9V Technic motors had, even with Chromium plated magnet surfaces. I bought about 8 CM units and could assemble two fully working PBricks. Changing the motors is, due to the wonderfully designed circuit board, really easy. And on each faulty unit, you still have the third motor output (9V 2x2) working! Now, with regard to VMs, serial ports, and so on: If you want to program these beauties, just install the BricxCC suite on any modern (Win11, 64 bit - works) computer, get an USB2Serial adapter, plug that in, run device manager, find the COM port number of that adapter, edit the address to < COM 8 (if necessary, simply move anything modern occupying the low COM port address space to port numbers > 8), run BricxCC, choose CM, choose the COM port of your adapter and then program, remotely control, monitor ... your CM PBrick. It is really cool - and does not need any line of sight. I have so much fun with these! All the best, Thorsten

Hi Lars, unfortunately, I don't have Robolab. However, Google tells me that it was intended to be used for programming the RCX and the NXT. The RCX uses either the serial or the USB tower, the NXT a USB cable or Bluetooth. As per Google, Robolab 2.9 does not support BT - that leaves you with the UBS cable for the NXT; I would not know how to attach the NXT via a serial cable. The only "RS232" only device in your list is then the interface B, correct? That works with a USB2Serial adapter, right? Or is your inquiry software related? As in: "Does Robolab 2.9 support direct RS232 communication?" I am a bit lost here. I'd just use the USB ports on the XP machine with USB2Serial adapters where required (i.e. for the interface B). Best, Thorsten EDIT: I just found Robolab on the InternetArchive, installed it and ran it on my Win11 64 bit laptop without problems. As it shows the RCX, NXT, and interface B on the "RCX/NXT settings" tab, and you can select the COM port you want to use along with each of those, I guess all should be fine with USB2Serial adapters, right?

No 9V motor though, no LED lights, no PF control, no proper wiring, no stickers, just the barebone loco (for € 36.95,- + shipping) And for sure, no concrete slabs on no concrete slabs wagons! These are really cool. Congratulations again, Emanuele, and again well deserved! I'd love to see some pictures of your soldering - I don't know anyone who does that that accurately. How do you turn on the lights? By switch or per PF remote? All the best, Thorsten