Toastie

Just to make sure: I don't >know< either! I am speculating here - others, who have much deeper insight into the TLG dynamics, have voiced something remotely to this effect. I am simply concluding from my own observations: When you have to develop a firmware for a hardware configuration, you are usually 1:1 on the developer level. And you usually know about "all" the issues of power drawing and how to prevent brown out - and it is all in there, in the firmware, as said. When you use for example Cornelius Munz' Legoino to control PUp devices, it is also all there: You can (but don't have to) "throttle" the max. power consumption to a user selected value, let's say 60% power, when you want to reach a certain controlled speed, let's say 30% (of max). The PUp app does not allow you to do that. It more or less simply freaks out. There are many other examples, where Legoino is very closely giving you control over what the firmware on the hubs essentially provides you with. And the app does not. This is where my conclusion/speculation comes from: It is not deeper knowledge, just experience. All the best, Thorsten

I find this thread most valuable and relevant - and it will be, as far as I am concerned, one - if not the - most comprehensive coverage of LEGO Mindstorms! @Coder Shah: I believe that it will add much value to this thread (my personal judgement only!) if you'd edit your OP and add the link Evan Koblenz @evank has provided in his very recent post above: "There's more info about the early history on my website at http://www.brickhacks.com/0.php." What I find most interesting on that page is, that there is a book with the title "Mindstorms: Children, Computers, and Powerful Ideas" from Seymour Papert - published in 1980! What do you think? Best; Thorsten

This is so ingenious. As simple as that, and it needs its own thread. It is a solution to so many attempts. Correct me please, if I am wrong: As this awkward cross axle on its own may "slip" away if not secured, the securing comes through the Technic pins/axles pointing upwards, i.e., the Technic pieces on the cars receiving these, right? All the best, Thorsten

And you made an incredible movie on that. I love everything in it. It must have been an awful lot of work, surely fun, but ... von nichts kommt nichts, as we Germans say, at least in the chemistry sector; we also entertain the "viel hilft viel" phrase, as you have shown to be so true using the rechargeables. There is an awful (again) lot of information in there - and I share every notion and conclusion you are drawing with regard to TLG's support. Well, these issues have been discussed all over the place here and elsewhere - but you nailed it. You know, it has been like that (regarding the electronics/programming support at TLG) since the very beginning, in the mid to late 1980s. TLG always declared it as "find-out-by-yourself" = biggest learning goal ever ... which is bull$*!t, when it gets too complex. Whatever. Thank you very much for sharing, I enjoyed every second of your video. All the best, Thorsten

Wait, wait ... "is it a star?" (Ghostbusters - of course ) Now, there are two interface A boxes - I assume there are two "9767" cards in that Apple clone, is this correct? Or are you using some custom solution? BTW, I found 3 Atari STFM 1024 in the "basement" - one is in very good condition and is about getting a fitting Gotek drive. Played with the Hatari Atari emulator - there is no reason, not having a real Atari controlling any kind of "robot" with interface A attached to the parallel port ... I simply love your project. For one, it is the engine itself; then there is all that functionality, most importantly for me though is the real life implementation of so many things happening in a real combustion engine of that make. And of course, the real deal computer brain ... simply perfect! All the best, Thorsten

The colors used in this model are "white", "LBG", and "black"; the latter even not being a color at all ... and I am color-blind. That is why I mix. You and others do certainly not. Best, Thorsten

100% this - for me! Tend to lean towards the One and Only. But that slowly but constantly fades away. Last week, my group (including me ) attended ASMS in Houston/Texas, and one company was giving away (literally) a serious "set" of one of their instruments - not the point. The thing is, I was completely blown away by the quality of the bricks and plates - from a clone company. I have no idea which one that is, but there is zero reason to not mix them with TLC's stuff. Will post on that thing in the EB Community Forum. As a last resort, I sometimes drill through bricks and plates, cut them, and glue small pieces together. At age 60+, I simply don't want to waste any more time for TLG making the piece I need, they did not for 50+ years - but I was soooo long waiting for. And then sometimes (or better: quite often), they did. Best regards, Thorsten

Boom - June 2nd in Central Europe. Nothing happened I am on my way to central US (well, Texas - not that central, is it?) - conference in Houston. The gang booked a house with a roof terrace - they already spent a week in Galveston (before the conference) to get a little sun tan. Looking forward to a few cans of the 211 fruit juice. Guess there will be no issue on EB in that region either. Nice, that it all went so smoothly with the maintenance! All the best, Thorsten

I agree: They can. If they wanted. Just like that. But they don't - it's part of the game, I guess. Best, Thorsten

Wow ... It appears as if a long time ago in a galaxy far, far away they had LEGO Technic - which now by some oddity showed up on this planet. I have two LEGO X-wing fighters - a rather old one and a newer one - both came to me as a gift, as I am not that much into larger Star Wars models. I am also not a very big fan of Technic models better made by system bricks (particularly those with almost no functions). And then this happens. Limited piece range ... perfect outcome. When you put this one next to the brick built X-wings - at least on par. When this one opens the S-foils though, there is no par anymore: It is simply fantastic. All the best, Thorsten P.S.: B-model sounds odd. It is an A+ model.

Hi Brian, oh yes, I know that you are a huge fan of combining new and old LEGO - I am following very closely what you are posting - of course. And I love it. Well, you know that as well Just changed that back - I was sort of scared when YT (also via other channels) said - was it years ago? - something to the effect of "you will perish in hell, when you don't change your content to 'for kids' ". At least this is what I understood ... well nothing like that happened when I changed it back ... so thank you very much for that tip! And many thanks for your kind words, as always! All the best, Thorsten

Technic Control (TC) from 1986 is - at the very least - absolutely fascinating (to me). It was when TLG wondered into (electronic) robotics ... Evan Koblentz (@evank on EB), his website is http://brickhacks.com/, has assembled the most comprehensive resource available regarding TC - and it still grows ... a wonderful place to be. Thus nothing better to begin this thread with a spoiler … The project idea Building an “autonomously” operating, programmable “robot arm” constructed with original Technic Control (TC) LEGO elements (bricks, plates, 4.5V lamps and motors, interface A, all from 1986 – 1988) and PoweredUp (PUp) LEGO elements (hub, motor; from 2019). Most importantly: TC “interacts” with PUp in a way that TC tells PUp when to move the trolley “left/right” to pre-programmed locations consecutively , while operating “up/down/turn L/R, and grab/release” of the arm by itself. This thus requires 4 motors and TC cannot do that without help, as the interface A has only 3 reversible polarity motor outputs. See below for hardware/software details. What does this combo do? The robot arm [building instructions provided by @alexGS; shown here in a video on his YouTube channel (https://www.youtube.com/watch?v=xLENEktsZdQ)] “quasi-autonomously” exchanges the storage locations of two “parcels”, using three pedestals on a stand and a trolley: (Left) Lord Darth Vader checking on PUp stuff; (right) Captain James T. Kirk checking on TC stuff; (bottom) MK stand + some TC and other LEGO bricks + 4.5/12 rails + 3 pedestals. Trolley: pulled with a “run-around” chain by a PUp medium linear motor on the left (color/distance sensor not used); (back) PUp Technic hub, powered by the permanent ≈ 4.0 V output of interface A using a small DC/DC converter in the hub’s battery box, see below; (top left) interface A powering the three 4.5V motors of the robot arm and the three 4.5V lamps in the base; (top right) ESP32 Dev kit + opto-coupler board connecting to output A of interface A, Arduino serial to parallel converter, RS232 cable to Win11 laptop (not shown); (center) robot arm, design by @AlexGS). Further to the right is the XT (not shown). “Quasi-autonomously” because instead of a LEGO PUp hub or PBrick of any kind, an IBM XT running PCDOS 3.3 and QuickBasic 4.5 is the brain behind the TC hardware – and I simply failed to get the XT moving on the trolley as well :D Why such a weird project? a) I wanted to show that TC can interact with PUp with only modest and cheap 3rd party elements used; b) wanted to use original LEGO TC ABS elements mingled with modern LEGO ABS elements plus some MK ABS elements; c) love to bring together vintage and modern electronics, particularly from TLG as they >never< show(ed) us how to accomplish this, and d) because I am simply running out of space up here in my attic and can’t do much more other than rotating something rather small by 180 degrees on the spot :D Did some remodeling up here lately to accommodate an original IBM XT (this one from 1985) – and these monsters do consume some room. Even worse, in the setup shown in the above figure, for a full 180 degree turn of the arm, it needs to be a) in the upper position, otherwise it crashes into a shelf; and b) the arm also needs to be moved laterally when turning, otherwise it crashes into a pedestal :D Space … the final frontier … Here is a short (and very boring video) of what the robot arm does – it was way more fun to bringing those two LEGO programming worlds together than taking that video. More on that below. (Video does for some reason not load - it does on YouTube: Just click here: https://www.youtube.com/watch?v=-6WI4i-TcYs) LEGO Hardware used One version of the robot arm (grab/release, up/down, turn left/right) is depicted in one of the LEGO Dacta booklets coming with set #1092; however a >much improved< version was provided by @alexGS. I would not have been able (zill!) to build the robot arm without a ton of help from Alex. The turn table’s (the arm is mounted on) instructions are available as building card in Dacta set #1092. The simple trolley I made is pulled back and forth using the small LEGO chain elements and is operated by the LEGO Technic hub and a PUp tacho motor (see below). The trolley runs on dark gray LEGO plastic train rails. And oh boy – the rails are affixed to the base of a stand for the MK Flying Dutchman … for fun I added three LEGO 4.5V lights to the stand’s base – just for show, nothing else. Well, not exactly: It shows that the outputs of #9750 can drive much more than one 4.5V motor each … Up/down, rotation left/right, and grab/release of the arm is done with three #6216 4.5V motors, #9750 interface A, the XT (+ LEGO #9771 ISA bus card) running PCDOS 3.3 and a compiled MS QuickBasic 4.5 (1988) program I wrote for that purpose. So in essence most of the stuff used to build and operate the arm is about 35 years old; the stuff to pull it back and forth is from 2019 onwards. The Technic hub is powered from the permanent 4V DC output of interface A with an additional DC/DC converter: As said, the lateral motion of the robot arm is done with a trolley moving on 4.5/12V type LEGO rails, operated by the linear medium PUp M motor (#88008), hooked up to a 4-port PUp Technic hub #88012. An ESP32 Dev kit board running Legoino is used for controlling the PUp devices; there is also the PUp remote (#88010) for manual trolley operation and PUp program control. I cannot (and don’t want to) get used to the LEGO PoweredUp app. After all, this stupid app >always< crashes, when operating TLG’s very own #88008 motor in tacho (PID) mode – even after TLGs 4+ years of app development … Other electronic hardware employed It turned out that using the ESP32 Dev kit/Legoino hard/software combo was (again) a fortunate approach as I was too dumb to use the LEGO PUp color and distance sensor (#88007) to simply sense light on/off. The TC and PUp brains are thus synchronized via an opto-coupler (4N28, already referenced in this book from 1983, we have to keep it straight on the vintage front ;) http://www.bitsavers.org/components/motorola/_dataBooks/1983_Motorola_Optoelectronics_Device_Data.pdf) hooked up to the ESP32 board, in accord with the interface A electronic layout philosophy, which also uses opto-couplers (2x LTV 487 M; 4 couplers in each chip) for separating the circuitry of the control computer/interface card from the power lines of the interface A. In my setup, one of the 3 motor outputs of the interface A is wired via a bridge rectifier (because forward and reverse need to be sensed) and a 470 Ohm resistor to the photo diode of the 4N28. The photo transistor goes low when the diode is turned on; thus the corresponding ESP32 input is tied to VCC(+3.3V) via a 1kOhm resistor. This little PANT board (I made that PANT thing up of course, Arduino’s have SHIELDS, Pi’s have HATs …) is riding directly on the pins of the ESP board: Total cost here, including the ESP board, is about $15. I used 4.5V wires (#766c96) with 2prong connectors, took off one connector and soldered Dupont connectors to the bare wires, which attach to the corresponding pins on the PANT board (interface A <=> ESP32 connection). See below for some programming hints on that; essentially, the ESP notices even the shortest low-level pulses on its inputs; I simply very briefly turns on/off the corresponding interface A output, so that neither a motor nor a 4.5 light bulb (visibly) notice that at all, but the ESP does. Well the ESP is more than 30 years younger than the other old farts :D The computer running QuickBasic 4.5 (or QBasic 1.1) or TC Logo controls the LEGO interface A. The interface in turn “controls” the LEGO PoweredUp Technic hub. Well, not exactly true: It signals the state of one of its outputs to the ESP32, which runs Cornelius Munz’ simply wonderful Legoino (https://github.com/corneliusmunz/legoino) software, which then provides bidirectional access to PUp devices, i.e., the Technic hub and the PUp remote. The PUp remote is only used for moving the trolley into its starting position and then telling the hub to listen to what the ESP is telling it to do. It can also be used to simulate light events etc. A note on the PUp environment: The tacho motor has a very high rotational resolution on the built-in encoders – way more than the TC encoders, but the principle is exactly the same: With the TC elements, you actually learn how that works; with PUp it is an icon in the app – or some code in Legoino. Nevertheless, the high precision, along with the built-in ramping routine, the speed is going up/down in a very controlled fashion, and results in absolute smooth trolley motion. Software Computer hardware controlling the interface A may be a modern Win11 machine, a semi-vintage machine running Win98 or the like, or a true vintage machine, e.g., an IBM XT, I am using frequently for such experiments. This >35 years range of computers smoothly operating the interface A became possible after Alex paved the road by partly disassembling the original TC Logo software from 1986-89 for PC’s running DOS and creating two new versions: One that does I/O via the parallel port LPT1 (TCLogo_p) and one that does I/O via the serial port COM1 (TCLogo_s). Both DOS executables are provided on his Bricksafe pages (https://bricksafe.com/pages/alexGSofNZ/interface-a-tc-logo). The original TC Logo for IBM PCs running DOS uses a LEGO parallel interface ISA card (#9771) with its own address for I/O. In this EB thread, there is a little documentation on the efforts of Alex and me regarding running TCLogo on modern computers: Why all these efforts? Simply because people like Alex and Evan and most probably many others like to run original vintage LEGO electronic hardware with the original LEGO vintage software. That’s all there is. Running the software alone on a modern computer is not an issue; there are many (DOS) emulators out there, some tailored towards playing original vintage games, others to actually mimic the functionality of a vintage computer. However, modern PCs/laptops don’t have any “true” serial (RS232) or parallel ports anymore – they do almost everything via USB. Nor do they have any means of providing 8-bit ISA bus functionality – at least not at an affordable price – if at all. I am pursuing another route: I want to run QuickBasic 4.5 / QBasic 1.1 in an emulator environment, and write my own BASIC code on a Win11 machine. Then transfer the program to the XT and run the robot arm from that computer. The DOSBox-X emulator is perfectly suited for this task, as it also provides access to COM ports on the host computer (laptop) as per configuration file: serial1 = directserial realport:COM1 COM ports are “created” using e.g. an USB2Serial or USB2TTL adapter; they are showing up as such in device manager. Why not using the XT directly for program development? For one, an XT with 256 kByte memory cannot run QuickBasic 4.5 but surely compiled QuickBasic com/exe files. QBasic 1.1 in turn runs on a 256kByte XT, but cannot compile files; it runs them directly. Furthermore, a laptop is mobile, an XT is not. A modern laptop is quite fast – an XT is not. A modern laptop has a flicker free display, an XT has not … yeah, we got “softer” over the years … and older for sure … The last thing required to operate interface A is a fast enough serial to parallel “converter” to operate interface A through an USB channel into DOSBox-X and further into QuickBasic. This is a very simple task for any Arduino device; even an Arduino Nano can do that. I made such an “interface”: Serial to 8bit parallel, 6 output, 2 input lines, as shown again here: And finally the program codes, most probably full of bugs, but they run smoothly so far; my Bricksafe page is here: https://bricksafe.com/pages/Toastie; direct download links: QuickBasic 4.5/QBasic 1.1 program (9750 control/robot arm program): https://bricksafe.com/files/Toastie/lego-interface-a---9750---9771---tclogo/tc-meets-pup/Q9750_9.BAS Legoino (C++) source code for the trolley (Technic hub + tacho motor + PUp remote): https://bricksafe.com/files/Toastie/lego-interface-a---9750---9771---tclogo/tc-meets-pup/DactaArm_V2.ino Arduino Nano serial to parallel code (C++): https://bricksafe.com/files/Toastie/lego-interface-a---9750---9771---tclogo/program-files-/9750_Parallel2Serial_Interface.ino I am very happy to provide more info on the programs, but I guess I am the only one doing this weird stuff in BASIC … and I just keep it here for future reference. Updates will also go here. All the best, Thorsten

Hi all, just to wrap up the hardware setup(s), I am currently using for the operation of interface A / #9750 with the computers I have, particularly the IBM XT / #9771 interface card <=> #9750 combo and my win11 laptop USB <=> Arduino <=> #9750 combo. This is for direct operation of TCLogo.com (original, TCLogo_s, TCLogo_p) and/or QuickBasic 4.5 or QBasic 1.1. Essentially all computers (vintage/ISA, direct cable, serial-Arduino, USB-Arduino should work with one of the options shown in the picture below: Figure legend (A) IBM XT or any compatible system with ISA bus (or directly addressable bus system via out/in CPU commands) available. The communication is via ISA cards; either LEGOs #9771, parallel, and/or RS232 serial card. (B) Semi-vintage computer, i.e., one with parallel or serial port available, again directly addressable, as in (A). (C) Modern computer lacking any directly addressable serial/parallel ports - this requires a DOS emulator, here DOSBox-X. 20 ribbon cable = 20 wire flat cable which attaches directly to 9750. S2T = Serial (RS232) to TTL adapter; this is for BASIC programs using the serial port or TCLogo_s to operate 9750 via an Arduino "serial-to-parallel adapter" U2S = USB to serial (RS232 adapter); this can be used on modern machines for RS232 serial communication. As my Arduino is a one-4-all solution, this is the most flexible approach as it works flawlessly with all computer systems I tested. U2T = USB to TTL adapter; this is for computers with USB port only, as in the U2S <=> S2T approach. The charm is that the U2T +5V line can be used to feed power to the Arduino as well, just connect +5V out of the adapter to the +5V power rail of the Arduino board, it can't do any harm. DB-X = DOSBox-X emulator with serial port emulation enabled. The "/" broken line means long cable can be used. Arduino = Arduino Nano, Uno, Mega - these are the ones I tested - they all work fine. For the Nano, this program works fine as serial to parallel converter (note that the direct port addressing is specific to the specific Arduino boards): https://bricksafe.com/files/Toastie/lego-interface-a---9750---9771---tclogo/program-files-/9750_Parallel2Serial_Interface.ino Note 1 on the Arduino: The Arduino needs +5V as power supply; this is not shown here. The Arduino supplies/sinks 20 mA (cont) on each output pin (200 mA total); this should be more than enough for all 9750 varieties out there. Note 2 on the Arduino: The Arduino USB port for programming/power supply does not show up as "com port" in device manager and can thus not be used as com port device for serial / in/out communication in DOSBox-X. You need to use a USB to serial or USB to TTL adapter as com port, which can then be configured in DOSBox-X. Note 3 on the Arduino: The Uno and Nano have only one hardware serial port, RX/TX. These two pins are exposed on the board, but do also connect to the on-board USB chip for programming/power supply. I am not trusting the software serial solutions very much. When attaching the U2T or S2T adapters to the RX/TX pins directly, programming of the Arduino via USB port does not work anymore. There is a very simple solution: Either remove the adapter cable that goes to the RX pin when programming or put a simple switch in between that line. The TX pin on both the adapter and on board USB chip does not interfere at all. See also photograph on page one of this thread. Note on custom parallel cable: As noted by @alexGS, not all parallel computer ports can drive the 9750 opto-coupler input circuity; in this case, an additional +5V power supply is required here as well. Note on operating system: Essentially all DOS versions should work running TCLogo and/or BASIC; I tested DOS 3.3 (MS and PC/IBM versions). Win98 DOS prompt works as well. Not sure about WinXP. All other Windows consoles do not; for Win11, the DOS emulator DOSBox-X is working fine. Guess this is it. All the best, Thorsten

W-H-A-T ??? Is that a joke ??? The >m-e-t-a-l< axles are back? You know what that means??? They put in danger us! They put in danger their clients ... swallowing metal axles - oh crap. Well, cut the crap, I'd say: This is absolutely wonderful news!!! You know what that means? BB cars back on the track - provided the wheel sets w/ axles show up on whatever TLG's marketplace name is nowadays, I lost track - BB is what I turned to ... but their wheel sets still suck. Nice! Thanks for the news! Best, Thorsten

No. I find it absolutely fascinating!!! Although I am on my own route to reversing loops and so on, this is really nice work. Surely expandable - and the PFx soft/hardware is the best out there!!! Good luck with your project - and keep posting here! Very nice. All the best, Thorsten

Hi Alex, WHAT A FIND!!! Oh my - hopefully this comes back alive - will purchase one right away!!! How cool is that. I love the way they expose the CPU and other chips ... beautiful, simply beautiful!!! I shall also plow Tindie.com for similar things ... Will come back later ... back :D Yes, I also believe the USB or any other power supply providing 5V/100(+) mA should do the trick. In the schematics for 9750, LTV-817 M is listed as (4x) opto-coupler. Each draws 10 mA (max.) when on, if I am not mistaken (5V/560 Ohm). All couplers on = 60 mA max. The ULN2003 easily sinks that current. All the best, Thorsten

Long time, no necro-bump … Little update: Looked into TCLogo assembly code, as @alexGS has already done. Alex chased the occurrence(s) of the addresses used in the TCLogo I/O routines writing to and reading from the LEGO #9774 PC ISA card (either 39Dh/925d or 39Eh/926d, depending on address bridge presence on the PCB; out/in) in order to change them to parallel port addresses (TCLogo_p.com, 378h/888d out; 379h/889d in) or serial port addresses (TCLogo_s.com, 3F8h/1016d; out/in), so that semi-vintage computers lacking vintage ISA bus support can natively run the respective TCLogo version. He succeeded and has hacked and provided these TCLogo variants on his Bricksafe folder (https://bricksafe.com/pages/alexGSofNZ/interface-a-tc-logo). My interest focuses on the PWM pulses present on the 6 outputs of the LEGO interface A box #9750. As per oscilloscope measurements it became clear that each power setting in TCLogo (0-7; 0 = off, 7 = on, all other = PWM) is changing its output status from 0 to 1 with 1 ms temporal resolution. The thing is: independent of computer used, be it an original IBM XT or a Toshiba laptop – even in the DOSBox-X emulator running TCLogo_s on a i7/Win11 laptop. This strongly suggested the presence of a hardware interrupt routine to be responsible for this behavior – at least under MSDOS, regardless of DOS version. Executive summary: When starting up, TCLogo 1) changes partly the DOS interrupt vector table content 2) changes the time base of the programmable interrupt timer to 1 ms 3) hooks int 8 = IRQ 0 (timer interrupt) for 1ms PWM output 4) chains from int 8 to int 95 (which points to the original int 8 vector) every 55 times, int 8 is executed, to maintain the correct system time. My ultimate goal is to use this approach in combination with QuickBasic 4.5, so that PWM control becomes available as well in this programming environment (I am struggling with TCLogo’s programming logic …) – I am a BASIC person. QuickBasic 4.5 is also from the olden days, when 4.5V LEGO Technic Control was around, i.e, from the mid to late 1980ies. In more detail: For the analysis of TCLogo, Alex suggested to do that with the DOSBox-X debugger, as the assembly code of TCLogo swiftly becomes hard to trace using a disassembler. I first tried a disassembler as well; however when an assembly program begins with a relative rather long “jmp“ and then does a few things like producing the splash screen and then just waits for the user to hit return, things get a bit messy right away as you need to follow the jump targets – everything in between may just be – something, data, whatever – but not assembly code instructions. The free version of IDA Pro dissembler (5.0 from 2010) is a) disassembling 8086 assembly very well and b) does analyze the assembly code by tracing jumps. Nevertheless, after asking for the “return” key it is over as well. Particularly as TCLogo does what apparently was done back in the days, when games or other nifty programs needed to be fast: It changes some of the DOS interrupt vector table content, then manipulates the programmable system timer (PIT) and then hooks some of the new interrupt vectors. Then it does some house-keeping, produces the splash screen, and finally waits for the user to press “return”. This made it rather tough to produce any reasonable disassembler output even with IDA. This is entirely due to my limited capabilities, of course, I bet, IDA tells you everything when you know how to use it properly. Even worse, in the beginning I had no clue what “segment” and “offset” meant. My assembly world was so far limited to 64k computers = linear address space. It took me a while to figure out how this works … also the register operations of the 8086 seemed to be odd sometimes … very steep learning curve – and that still remains so. So I followed (again) Alex’ advice and used the debugger of DOSBox-X, as said, to log/read the code, TCLogo actually executes. The log file also contains all register content and so on. The debugger can also list the DOS interrupt table content – this way I figured out what changed after TCLogo is running. And sure enough, among others, the DOS interrupt vector 8 (hardware IRQ 0 = timer interrupt) is not pointing to BIOS anymore, but to TCLogo code. Somewhere else in the manipulated vector table the original interrupt 8 vector is stored. The two tables are listed in the spoilers below. Spoiler 1: Interrupt table DOS only (warning: 256 lines long) Spoiler 2: Interrupt table DOS + TCLogo_s running (warning: 256 lines long) What helped a lot in getting further into the TCLogo code per DOSBox-X debug log file was applying the “CPU = 8086” and “CPU speed of 8088 XT/4.77MHz” = 240 emulator cycles/ms options. That produces much smaller log files and got me faster to the timing sequence in TCLogo. I typed “TCLogo_s” in the program window (no return), then started the debugger, asked to log 200000 cycles, quickly returned to the program window and hit return. That took a while … the splash screen appeared, then the return prompt, then the logging was also done. I did not press return. The analysis of the log file took me quite some time – just to trace the output/input timing related things! This has nothing to do what TCLogo does as its main task: Providing a powerful programming language for (LEGO) robotics; this is just about the PWM timing loop. What happens upon TCLogo program startup in this regard is essentially the following. Note though that the segment:offset pairs shown below in the assembly code snippets are most probably different on other systems; these are from the debugger output of DOSBox-X, I have no clue if that changes on another machine. TCLogo is a true DOS COM file and thus should use only 64k of addressing, but I am not sure at all. Here we go: (1) Directly after startup at segment offset 100h, many things happen, memory is cleared, byte/words are “defined”, etc. I did not follow entirely through here. (2) At some point, the PWM signatures for the initial power setting of the 9750 outputs 0-5 (FF = 1111 1111 = power 7) are defined using four words. Each individual power PWM signature consists of 8 “serial bits”, as measured with the oscilloscope, shown in an earlier post in this thread. A further byte located at [9315] is set to 0, this is the mask for the 6 outputs; see below how the 6 bit parallel output signal to 9750 are (most probably) generated from the 8 bit signatures: 1481:0A0E mov word [9317],3F3F ;eight bytes are set to 3F = 0011 1111 1481:0A14 mov word [9319],3F3F 1481:0A1A mov word [931B],3F3F 1481:0A20 mov word [931D],3F3F (3) The presence of the interface is tested. This is where Alex has most probably hacked the original TCLogo software: First, 15h = 00010101 is sent out on the (hard coded) address (03F8) of the serial port, then TCLogo listens on this address for a reply of the same value. As my Arduino Nano does exactly that, just reply back what came in (plus the 2 input bits), TCLogo assumes a valid interface is present: 1481:0A26 mov dx,03F8 ;load serial port address into dx 1481:0A29 mov al,15 ;load 15h = bin 0001 0101 into al 1481:0A2B out dx,al ;write bin 0001 0101 to serial port 1481:0A2C in al,dx ;read serial port into al 1481:0A2D and al,3F ;al = al AND 3F (bin 0011 1111) 1481:0A2F cmp al,15 ;compare al to 15h = 0001 0101 1481:0A31 je 0A82 ($+4f) ;je=jump if zero flag is set; as the ;Arduino on the USB2Serial port replies ;with 0001 0101, the compare result is 1 ;= no jump TCLogo then stores this address two times; I believe these are the two other locations, Alex hacked TCLogo; one is used for the “out” command in the new interrupt 8 routine, providing the PWM signatures for the six 9750 outputs, the other for the “in” command reading the digital values of the two sensor inputs of 9750 in the same routine. Note that out/in addresses are identical for 9771 and the serial card, but different for the parallel card. Thus they are the same for TCLogo_s (serial version): 1481:0A87 mov word [9343],03F8 ;used for output 1481:0A8D mov word [9345],03F8 ;used for input (4) TCLogo stores a number of original interrupt vectors in an unused section of the DOS interrupt table, among these is int 8 = IRQ 0 (system timer interrupt), which becomes int 95 and points to the original BIOS section, where the system timing is handled. One example of how to get an interrupt vector is given below for int 5 = Print screen key: 1481:02B4 mov al,05 ;prepare call DOS int 21, function 35h (in ah): ;get vector for interrupt 5 (in al) - Print screen key 1481:02B6 mov ah,35 ;prepare call DOS int 21; return ES:BX = current int handler 1481:02B8 int 21 ;call DOS int 21 f35 i5 F000:D100 sti ;set interrupt flag; external, maskable interrupts enabled at ;the end of the next instruction F000:D101 callback 0038 (DOS Int 21) ;this loads requested data into ES:BX F000:D105 iret ;ES:BX now contains the (far) interrupt vector 5 (5) New interrupt vectors are copied into the interrupt table, among these is int 8 as well. DOS int 21, function 25h is used for this purpose, same way as above. The new vectors point to TCLogo code (interrupt service routines, ISRs). (6) The programmable interrupt timer (PIT; Intel 8253 on the XT, may be other but “compatible” timers on other DOS systems) is manipulated. I believe up-to the latest DOS version, int 8 = IRQ 0 is thrown every 55 ms, regardless of the hardware setup. On the XT, the CPU needs a number of peripheral chips to work the system, among them are the PIT and the Intel 8259 PIC (programmable interrupt controller). On the XT, the PIT uses a system crystal oscillating at 4.77 MHz. This frequency is divided by 3 = 1.193181 … MHz (for money saving reasons explained much better here: https://de.wikipedia.org/wiki/Programmable_Interval_Timer) and then further by a user accessible divisor register of the PIT. The original divisor is 65536; thus the system clock fires at 1193181 s-1 / 65536 = 18.2 s-1 => every 55 ms – as it apparently does on all DOS systems. To change the PIT clock rate i) the PIT mode may be (optionally) selected, then ii) the divisor latch has to be changed: (i) The PIT mode register is listening to I/O port 43h. TCLogo uses counter 0 of the PIT; low then high byte write to the 16 bit divisor register; runs the PIT in mode 3 (rate generator with symmetrical square wave output rather than short pulses); and sets the counter to 16 bit binary rather than BCD. The corresponding 8 bit word is thus 00-11-011-0 or 36h. (ii) The divisor latch of the PIT listens to I/O port 40h; TCLogo first writes A9h then 04h to this port = 4*256+169 = 1193 (decimal). (i) + (ii) assembly code: 1481:0358 mov al,36 ;00 11 011 0 = 36h 1481:035A out 43,al ;set PIT mode 1481:035C mov al,A9 ;divisor, low byte (A9h=169d) 1481:035E out 40,al ;write to PIT divisor latch 1481:0360 mov al,04 ;divisor, high byte 1481:0362 out 40,al ;write to PIT divisor latch 1481:0364 ret From this point on, the PIT fires with a frequency of 1193181 Hz/1193 = 1000.15 Hz => 0.9998 ms. This occurs before even the splash screen appears. (7) As TCLogo hooks int 8, the new interrupt service routine for int 8 (IRQ 0) needs to chain to the original int 8 BIOS routine (now int 95, which chains further to int 1C) every 55th time it was called; otherwise the system time and thus many things may screw up. The “count up” counter storage location is at [92FC] in the new int 8 ISR: (More code above; e.g. “PWM out” to and “sensor in” from the serial port connected to Arduino/9750) followed by 1481:0408 add word [92FC],04A9 ;this is the counter for calling int 95: ;04A9 = 1193 dec = 1/1000 of 8253 PIT frequency ;1,19318181818 … MHz) 1481:040E jnc 00000415 ($+5) ;(down) jump if no carry: Carry flag does not ;change here. It will change from 0 to 1, when ;[92FC] > FFFF. This will occur 55 times after ;this routine was called: ;55 * 1193 = 65615 = 1004F. ;4F is then stored in [92FC] - and thus adds up ;?to sync most accurately with system time? 1481:0415 mov al,20 ;20h=function "end of interrupt (EOI)" for PIC 1481:0417 out 20,al ;PIC listens on I/O port 20h 1481:0419 pop ds ;restore registers 1481:041A pop dx 1481:041B pop bx 1481:041C pop ax 1481:041D iret ;return from HW interrupt When the Carry flag is changing to 1 (this is during the 55th call of int 8) int 95 is chained (the original int 8 BIOS routine): (Same entry point as above) 1481:0408 add word [92FC],04A9 ;this sets the carry flag to 1: ;FBA6 + 04A9 = 1009E and thus int 95 is called; ;9E is stored in [92FC] 1481:040E jnc 0415 ($+5) ;(no jmp) no jump = int 95 call via seg:04AD 1481:0410 call 04AD ($+9a) 1481:04AD int 95 ;interrupt chain 1: int 95 ;(= original int 8 (IRQ 0) call) F000:FEA5 sti F000:FEA6 callback 0008 (IRQ 0 Clock) F000:FEAA push ds F000:FEAB push ax F000:FEAC push dx F000:FEAD int 1C F000:CC00 callback 0010 (Int 1c Timer) ;interrupt chain 2: int 1C F000:CC04 iret ;return from int 1C F000:FEAF cli F000:FEB0 mov al,20 ;only last chain ISR signals EOI to PIC F000:FEB2 out 20,al F000:FEB4 pop dx F000:FEB5 pop ax F000:FEB6 pop ds F000:FEB7 iret ;return from new int 95 That is pretty much it with regard to the I/O timing for the serial (and of course parallel or 9774 card) in TCLogo. PWM signal generation One last section on the PWM signal generation on the 6 out lines (0-5), which go to 9750 via either Arduino (TCLogo_s), the parallel port (TCLogo_p) or the 9774 card (TCLogo). Upon further inspection of the int 8 routine (again using the DOSBox-X debugger log repeatedly, but logging after hitting return and setting each output to an individual power level (6x “tto X”; “setpower Y”; “on”), I believe to having understood, how that works. The PWM signatures are 8 bit serial “packets” continuously sent out at a 1 ms rep rate to the 6 individual output lines. These packets are re-calculated only, when the user changes the power setting. They are stored as bytes in locations (cf. section 2) [9317] to [931E] Let us assume the following: TCLogo Settings: talkto setpower on/off ---------------------- 0 1 on 1 2 on 2 3 on 3 4 on 4 5 on 5 7 on The output mask byte at [9315] is now 00111111 = 3F=all on Tracing "out dx,al" in the consecutive int 8 code calls (every ms) yields: (9750 output#: 54 3210) 1) 1481:0394 out dx,al ;AL: 3C = 0011 1100; byte [9317] 2) 1481:0394 out dx,al ;AL: 32 = 0011 0010; byte [9318] 3) 1481:0394 out dx,al ;AL: 3C = 0011 1100; byte [9319] 4) 1481:0394 out dx,al ;AL: 29 = 0010 1001; byte [931A] 5) 1481:0394 out dx,al ;AL: 36 = 0011 0110; byte [931B] 6) 1481:0394 out dx,al ;AL: 38 = 0011 1000; byte [931C] 7) 1481:0394 out dx,al ;AL: 3C = 0011 1100; byte [931D] 8) 1481:0394 out dx,al ;AL: 23 = 0010 0011; byte [931E] (9750 power level: 75 4321 -> as measured) The columns “9750 output#” 5->0 represent the PWM signatures for each 9750 output. These signatures are thus as listed below, in full accord with the oscilloscope data: 7: 1111 1111 = FFh = 255d (6: 1111 1110 = FEh = 254d) ;not used in the above experiment) 5: 1110 1110 = EEh = 238d 4: 1011 0110 = B6h = 182d 3: 1010 1010 = AAh = 170d 2: 0100 1001 = 49h = 73d 1: 0001 0001 = 11h = 17d (0: 0000 0000 = 00h = 0d) ;not used in the above experiment In conclusion (on PWM output generation): TCLogo calculates and stores 8x8-bit data (bytes) each time the power data of 1 (or several) channels is (are) changed. The new PWM data have to be calculated only once after the change(s) and then simply 1ms repetitive mov/out instructions generate the PWM pattern for all 6 outputs, which saves a lot of time within the interrupt routine. This behavior is readily replicated in QuickBasic – but it takes much longer to execute – certainly not at 1 ms rep rate! But it works as expected. Nevertheless, the TCLogo code is simply beautiful!!! Summary I believe it may be worthwhile to program this behavior into the QuickBasic program I am currently using for controlling 9750 also with PWM. So far the outputs are simply “on” at power level 7 or off. Nothing in between. The nice thing is that QuickBasic does not claim any of the new interrupt vectors, TCLogo is occupying for hooking. So I can maybe do some c/p’ing here. Who knows, it will be a (very) long journey for sure! All the best, Thorsten (P.S.: Will edit this surely quite often, as there will be many typos)

I 100% share this notion. On an even further and different direction, but basically on the same general approach. As already voiced back then, when the forums "Mindstorms" and "Technic" were reunited: Mindstorms is basically absent - as in drowning. For one, TLG abandoned ship - or will, rather soon. Not the point: That "programming stuff" is not that popular. Nevertheless: EB is essentially a repository of deep knowledge spanning decades (not of posting, of interest and knowledge, e.g., about stuff that disappeared more than several decades ago; I take TCLogo as one example, RCX as another and will add PUp rather sooner than later, as TLG will come up with another electronic "thing"). However, the structure currently is more of a "knowledge dump", rather than a "dictionary". In other words, the forum search function is a joke. Google always finds what I am looking for. >Targeted< that is. A non-targeted inquiry simply does not work, but would, even using Google, when there is a structured content "database". So I'd propose to not only do show finished projects - when it comes to TC, CodePilot, Mindstorms, PUp and the like, i.e., all programmable stuff, projects are hardly finished at all. But they represent a repository of invaluable knowledge. My perception only, of course. One example: I did some deep digging on the TCLogo software, wanting to understand, how they did PWM back then, in 1986/7 using 9750 and 4.5V motors. And found out how they did it. Where to post? I will simply add this to my own thread on this forum - and it will be on this forum's page 3 tomorrow and thus dead. It is not about reads, I cannot care less about that metric - it is about 5 people on the planet being able to readily find it, when they occasionally, as you do, visit here. My 2 cents only! Best wishes, Thorsten

Ohhh - niiiiice! Two RS-FF using discrete elements - it does not get any better. I truly love this. Thank you very much for sharing! All the best, Thorsten

@astyanax I love it Thanks for sharing, haven't seen that one! Best, Thorsten

... with a slightly different color scheme - base in black and cover in gray (compared to base in gray and cover in white). Inside, these two are simply identical. Nevertheless: BL teaches us that the Dark Side is way more expensive than the Bright Side Tip: Just go for the cheaper MicroScout. Best, Thorsten

That is so true. Been there (and still am there, some ancient LEGO stuff is simply not on BL, no chance ;) But once again: @AlmightyArjen does now have a "Santa Fe" in his hands, and surely on his layout. I am always soooo unsure about that "real thing", "original", "MINT", "Unopened box", "Box with scratches" and so on and so forth "thing". I am on the LEGO lasts forever trip - so there is absolutely no reason for me not using modern parts in modern colors on a vintage model. Actually, I believe it renders these models more LEGO-philosophy-like. And not collection-philosophy-like. Watching Arjen's incredible videos on YouTube - I may over interpret them - makes me believe "collection" is in the background, but having fun with the true idea of LEGO, leg godt, is much more in the foreground. All the best, Thorsten

Me neither. 10020 was essentially "starting" my train layout - I had one set early on, then all the cars - and some time later (close to retiring) cars and another engine. They came all with old light gray parts. I followed closely what was happening to all the beautiful train sets back then - The "My own Train" series etc. But who knows, maybe others have had other experience! And so what, you do now have a 10020 Santa Fe with all stickers. That is what counts. All the best, Thorsten

I also believe so - the 1x2 technic brick seems also to be very close. The two bushes on this axle are also a bit "loose". I had similar issues of such "play" resulting in not optimum behavior. I used thin metal washers to get rid of that play and having to "readjust" when running the setup for some time. Nothing for purists, though. Best, Thorsten

That is really nice to read. Persistence ... I love it. Have fun with the set, and please report here, how you felt upon arrival and opening the box! (I had to wait for 35 years to get my hands on an original IBM XT ... which I restored to almost factory condition. That was and is an incredible and rewarding feeling) Best wishes, Thorsten