Toastie

Just to make sure this thread is not drowning in this Liebherr forum ... I am making progress getting into GFA Basic (for my Atari ST) - it looks rather promising. The parallel port of the ST is a nightmare though (signals destroyed by interrupt routines every such milliseconds, and no ACK line - crap! Have to live with strobe and busy ... and have to figure out, how GFA Basic deals with that via the inp() and out() function/command). The serial port is plain vanilla, but using it will violate the rules (no Arduino etc.), as a breadboard will be, well, large to make a serial-to-6+2 bit parallel port ... Right now I am doing all this in the Atari Hatari emulator , but well, we'll see. I love challenges. Ready Player One! Best, Thorsten

I >totally< agree! Best, Thorsten

Sorry, you score 0 points . Actually, 0, 0.1, and 1E6 may result in negative points - we should discuss the 100 answer The moment TLG "needed" a 1x5 plate, they made a 1x5 plate - kids or not. They actually make so many things, a kid may struggle with. But: When they can identify a 1x6 in the presence of 1x8 plates, the 1x7 plus a 1:1 drawing in the current instruction will aid. Well, I believe. Alternatively: No odd number 1x plates in sets for kids ... Regards, Thorsten

I agree. In the beginning ... it already seems to have faded in the late 1990's. To "unlock" the firmware in the RCX, you had to provide that phrase as well ... "Start firmware download clears RAM from 0x8000-0xcc00. Unlock firmware requires "Do you byte, when I knock?" string to be located in firmware image starting before cc00; anything after cc00 is ignored, so the string does not have to be complete (!). Firmware execution begins at the address specified by start firmware download." (http://www.mralligator.com/rcx/romref.html) Hope you enjoyed a good, strong, black coffee this morning! Best, Thorsten

Yes, that code is in the manual for 9771 - I have that at home. Nothing, really nothing is special about that number. In binary notation, 21 dec (15h) is 010101 - some geek found it cool to test the presence of 9750 by alternately turning its 6 outputs on and off. On the other hand, that pattern stands out a bit when testing new hardware. I found it useful when making my serial-to-parallel Arduino thingy; when the pattern shows up on 9750, you know that at least the out command worked. Checking for the response by masking off bit 6+7 (AND 63 dec, 3Fh, bin 00111111) and getting the same number back, tells you the in command worked as well. They do that in TCLogo as well: 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 You can use any other number for testing, this 010101 pattern is maxing the probability that one or more lines on the data bus are not working. I guess. Maybe it is also just for fun. Programmers ... maybe 42 (101010 bin) was simply too obvious ... Best, Thorsten

@1963maniac - there seems to be a missing link in your post? Best, Thorsten

@evank, @alexGS and all others: OK, things become much clearer now in regard to that "LEGO TC Controller" book you scanned, Evan. There are principally two different approaches described in the non-LEGO Lines sections: Using IBM BASIC, Turbo C, and also COMAL (which to me is very similar to QuickBasic) Using the "LEGO TC Controller" program as provided by TLG in a) direct mode and b) as unit in Turbo Pascal. A unit in TP is a "module", you can transparently use in your TP program; well, did some minor TP programming back in the days for spectra analysis. In the Turbo C (from Borland; the book deals with the DOS versions only) section of the book (chapter 6.2), a number of routines written by the authors are presented, which do what makes life easier when wanting to work with Interface A. On the hardware side you need an IBM PC or compatible and the LEGO 9771 ISA card. The latter is easily exchangeable with an ISA parallel card; note that in this case you need to use two different ports and the special parallel cable, @alexGS has documented. This is not covered in the book, though; here only the I/O address of 9771 is used (925 dec for in and out, alternatively 926). For Turbo C, every service routine the authors provide (like BitOn, BitOff, Count, Delay, Time etc.) essentially rely on two C-functions which calling the x86 processor directives "var(byte) = in(addr)" and out(addr,var(byte)). These functions called "inportb" and "outportb" come with the Turbo C program package not included in the book, which you need to #include when you want to use them. They are part of the dos.h file of Turbo C. So all you have to do is put "#include <dos.h>" at the top of your C-program. With that you have the functions unsigned char inportb(int portid) void outportb(int portid, unsigned char value) available in your program. Usage is straight forward: "outportb(925,5)" will turn on 9750's outputs 0 and 2; "char test = inportb(925)" will read out the entire 8 bit wide status of 9750, i.e., the two inputs and the six outputs. As the authors state: "The entire interface control is handled by these two functions". All other functions are convenience functions to make life easier, e.g., turn one individual bit on/off or read only one input bit of 9750 calling a function with parameter: "int ein(0)", "int aus(0)", "int toggle(0)", etc. etc. Yes, functions names are in German; "toggle" is not though, I guess "hin-und-her-schalten" was too much and even in 1990 kids in the classroom may have already adapted to "cool", "f*ck", and "toggle" All C-functions are listed in the book, so if the disc is not available anymore, I can surely adapt them to English. As said, COMAL looks to me like QuickBasic - it has the line indentions in the editor window, no line numbers, and essentially the same vocabulary. So nothing new here, I guess. Again, convenience functions and routines are presented, centered around in(925) and out(925,byte) - as I did in my QuickBasic program, so it is all there already A somewhat different story begins with chapter 7: Here, the LEGO TC Controller program (control.exe, provided by TLG) is loaded (residently) into memory and then can be used either directly to control 9750 by pressing buttons (as with my QuickBasic program) or by running TurboPascal programs with control.exe used as unit and thus functions are called within TurboPascal. (The equivalent are my "UserProgramsA,B,C ... within my QuickBasic program): It says below the (c) info: "The LEGO TC direct control module V2.00 is loaded into memory. Call with <ALT> + <i>". For your LEGO history research @evank that means there must be a control.exe program designed by TLG for DOS/PCs out there; they call it "LEGO TC Controller". I have never heard of it, but that does not mean anything. The big advantage of control.exe is, that it is a) resident in memory, b) easily accessible by TurboPascal (and I bet by other compiler languages as well, once you know the hooks into it - it would be a blast to see whether it can be linked to in QuickBasic), and c) the SetPower command (PWM) availability. I bet they do the same thing as they did with TCLogo with that 1kHz interrupt handling!!! Usage within TP is as follows: Load controller.exe into memory (within the DOS shell). Return to DOS prompt. Load TP. Write a program with the units TP has access to by default (you can check that within TP) plus declaring: "uses LTCC.EXE" in the top section. That's it, and you have access to all the bells and whistles of control.exe. Oh my here it comes: This says "According to the [LTCC] manual, LTCC can be activated i) within a DOS shell, ii) from a (program) editor, e.g., the TurboPascal IDE, from a running program." And that is it! Full-blown 9750 access at your programming fingertips!!! It could be that the LTCC control.exe file is on the disk accompanying the book: This reads: "This book comes with an accompanying disk for IBM-PCs and compatibles. The disk is organized in the following manner (see above) and includes the program files listed in the book. Maybe control.exe resides in the <LTCC> folder? Maybe not; it sounds to me like another expensive piece of TLG software? EDIT (sorry for being that disorganized) I believe, control.exe and all the other files you need for accessing the code in TP are indeed part of the software package "LEGO TC Controller". This package also had update versions: This reads: "Over the past years, new versions of Turbo Pascal (upgrades) came out. Accordingly, there are several object code versions of the LTCC.TPU unit on the LEGO TC Controller master disk (...)" Summary: We desperately need the LEGO TC Controller software package(s). Best regards, Thorsten (P.S.: If you don't need PWM, simply use my QB program - it does the same + has the parallel and serial port support (+simulation mode) as well).

It would be good to see a diagram/photograph of how you wired the different configurations. When they are in parallel, both motors should run, at least without load ... Best, Thorsten

Oh well, he is a math prof at his university, and I am a chem prof at my university, and thus we're colleagues - I don't know him personally. So the world is not >that< small. Time is indeed an issue. I'll retire in 5 1/2 years ... But maybe I can extract the most important aspects? Best, Thorsten EDIT: I read a bit further - the world is weird The new commands provided in the LTCC.TPU include file for (Turbo) Pascal are to 90% available in my QuickBasic program: DECLARE SUB BitOn (Bitnumber AS INTEGER) DECLARE SUB BitOff (Bitnumber AS INTEGER) DECLARE SUB GetSensorBits (ClearInputStatus AS INTEGER) DECLARE SUB InterfaceInit () DECLARE SUB OutputsOnOff (OnOff AS INTEGER) DECLARE SUB SetMotors () DECLARE SUB ClearCounter (Counter AS INTEGER) DECLARE SUB WaitSeconds (Seconds AS INTEGER) DECLARE SUB Trigger (Bitnumber AS INTEGER) Missing is "SetPower" (as Alex knows, I am working on this; needs machine code though ;) - other than that it is all there But yes, I know, you want to do C and Pascal ...

Hi Evan, I downloaded the book and had a look. That is a nice one! The LEGO lines section is not that important, is it? Core to the matter in the Pascal section is having a software package called the "LEGO TC Controller", which is a collection of files providing the commands for direct and Pascal program access to 9750. Is this software available? As you have permission of the author for the translation: Is that my colleague Helmut Albrecht? Did you ask him about this software required? Best, Thorsten

Oh yes! This includes my Atari 1040 STFM!!! And I can use GFABasic 3.0 ... will take some time to come up with a decent program, as I a) never had an Atari back then, b) never did GFABasic with all the million commands and functions it provides, and c) the parallel port access is, well, interesting. So my first entry is this QBasic1.1 (interpreter)/QuickBasic4.5 (compiler) program; these are essentially identical; QuickBasic has a couple of interesting features, QBasic does not have. QuickBasic version 4.5 came out in 1988. Source Code: https://bricksafe.com/files/Toastie/lego-interface-a---9750---9771---tclogo/tc-meets-pup/Q9750_9.BAS DOS 3.3 or higher EXE file: https://bricksafe.com/files/Toastie/lego-interface-a---9750---9771---tclogo/tc-meets-pup/Q9750_9.EXE The program has 4 "modes": Simulation (SIM), parallel (PAR), serial (SER), 9771 (LGO). Pressing "X" circles through the modes; pressing the space bar tries to access "nothing" (SIM), an ISA parallel card (PAR), an ISA serial card (SER), or the LEGO 9771 ISA card (LGO). If the respective device is not present, only the serial mode requires breaking the program (^C) - all other modes except SIM raise an error and the program simply continues. ESC ends it. In SIM mode, everything can be tried out - pressing the numbers 0 - 5 turn the outputs of 9750 on/off. The text on the left should be self-explanatory, I hope. Program start: In DOS or a DOS emulator type q9750_9; main screen appears; program is in SIM mode. Press "o" for enabling the 6 outputs of 9750, then play around. User programs can be started; you need to code them in QuickBasic though. UserProgramA is currently used (in the q9750_9 program) to run the "Dacta arm" as shown in this video, just ignore the PoweredUp stuff; the IBM XT is doing all the work: https://www.youtube.com/watch?v=-6WI4i-TcYs In SIM mode you can start the user program as well; the outputs will be turned on and off accordingly. Some steps require one of the two counters to reach a certain limit - or there is a pause of x seconds. Just press space bar to skip this step. Used this to check the program flow. Best regards, Thorsten

Perfect! Thanks a lot @Jim!!! And thank you @evank for creating this thread! Best regards Thorsten

No, you are not, as far as I am concerned; this USB supply approach >is< he much better and more "in line with TLGs" philosophy way to do it. This is just a marvel! Thank you so very much for composing this document. It is of true teaching style - meaning it is a tutorial, a reference, and an instruction. The best of three worlds! All the best, Thorsten

Could be; or maybe the Technic hub is too "bulky"? The City hub is only 4 wide - I like that layout one very much. In addition, the weight of the batteries in the two hubs (although being AAA's) may add to stability of the build? Just guessing. This really is a brilliant MOC. Outstanding. Best, Thorsten

Hi Alex, (I am trying to have the Dacta Control lab thread of Brian untangled, let's see what happens) with regard to the additional 5V supply required for some of the parallel port/9750 combos using the method you describe above: For my PoweredUp/TC "coupling", I used the permanent ~4V DC output from 9750 to supply 9V DC to the Technic hub with the help of miniature step-up-converter (https://www.eurobricks.com/forum/index.php?/forums/topic/194832-lego-technic-control-tc-1986-meets-lego-poweredup-pup-2019-bridging-a-30-years-lego-technic-electronics-“gap”). Now, I believe you can either use the 4V DC directly to power the opto-couplers of 9750 directly, i.e., feeding that power into 1+3 (+) and any of the even pins (GND). This way, you won't need an external power supply. This "violates" TLGs approach of not exposing any 9750 voltage to the controlling computer or interface card, but whatever. Should that voltage not be high enough, the little step-up-converter would easily do it, as it produces the 9V DC for the hub without any problems. Not that it makes any difference, it would just look cool ;) Best, Thorsten

With a hardware device that features Bluetooth low energy (BLE) functionality, as this is what PoweredUp/Control+/whatever name is using as communication means. This device can be i) a cell phone/tablet (TLG wants you to use) running LEGO software, ii) a computer/tablet - in that case PyBricks is one popular software to access/program the hubs via web interface, iii) a microcontroller, e.g., a board that features an ESP32 wroom module running Legoino, and iv) other alternatives that I am unaware of but bet there are. The major difference between PyBricks and Legoino is that the code you compose in PyBricks is downloaded to the hub and then runs autonomously on the hub, whereas Legoino runs the code on the microcontroller board autonomously, which sends and receives data via BLE to/from the hub - sort of intelligent hub remote control, as you can use built-in hub features such as speed control and the like. As far as I know, others may know much more on this!!! Best, Thorsten

@Jim Hi Jim, sorry for bothering you but @evank and most prominently I have seriously derailed this thread, @BatteryPoweredBricks opened - which is meant to address and discuss Dacta Control Lab stuff. Quick question, if we open a new thread dealing with "ancient hardware controlling ancient 9750 (Interface A) using ancient software (everything <1990 or so), would it be possible that you (or other moderators move all entries wrongly placed here (that is all posts including and after this one https://www.eurobricks.com/forum/index.php?/forums/topic/67665-dacta-control-lab-software/&amp;do=findComment&amp;comment=3633756) to that new thread? Thanks in advance + best regards, Thorsten

Ahh, I see. That includes QBasic and QuickBasic from Microsoft as well, doesn't it? Both are from the time of TC - and both run on an IBM XT with 256 kByte of memory. This is the configuration I have: IBM XT (5160) with CGA, parallel, serial cards; in addition it has a 9771 card. The QuickBasic program I wrote for this combo works flawlessly with 9750; it can't do PWM at the 125 Hz pace (1kHz resolution) as TCLogo does, since the Basic code is simply too slow on an IBM XT - as is IBM Basic. This program (running on the original IBM XT, 4.77 MHz, 8088 CPU) can do the communication with 9750 via 9771, the parallel (with the cable @alexGS has described (https://www.eurobricks.com/forum/index.php?/forums/topic/192941-lego-interface-a-97509771-–-lego-technic-control-1-tc1-referenceideas-thread/&amp;do=findComment&amp;comment=3581909), and serial ports (with an Arduino, so that is out of the challenge) as summarized here: https://www.eurobricks.com/forum/index.php?/forums/topic/192941-lego-interface-a-97509771-–-lego-technic-control-1-tc1-referenceideas-thread/&amp;do=findComment&amp;comment=3619101. You simply select your communication hardware by pressing "X" repeatedly and then "space bar" to find out, whether 9750 is present on the respective card - or not. So IBM XT + 9771 and or + parallel card should be along the challenge rules, right? Next question is: If I can get the Atari 1040 STFM with only a custom cable operating 9750, would that count as well? All the best, Thorsten

This is an incredibly nice mechanism and solution! I love pneumatics, and yes everything needs to line up precisely, otherwise bad things will happen, as you said! Cool Back in the days, when encoders were hardly found in LEGO motors (the RCX era and before) such precise alignments were also possible using the light sensors and a light of course (https://www.eurobricks.com/forum/index.php?/forums/topic/154740-moc-lego-switch-drive-controller/) All the best, Thorsten

Challenge accepted :D (I believe we are in the wrong thread here, aren't we? Don't know ...) Regarding the control of Interface A (9750): What works as well in addition to the references you are listing on the 6.php page on your website is using the serial port of >any< computer, modern, semi modern or vintage with a little extra, an Arduino Nano (or any other of the smallest microcontroller boards put there featuring programmable 8 I/O ports). Even TCLogo in the serial port version @alexGS made as well, runs on a Win11 machine using DOSBox-X as vintage PC emulator. The modern machines can do that via USB2Serial ports - they are still addressable as classical COM ports. References are on EB. I used QBasic 1.1 for direct (as interpreter) interaction with 9750 as well as QuickBasic 4.5; with the latter I made a EXE/COM files which run on an original IBM XT using its parallel port, serial port as well as via 9771 - you can select the I/O route within the program. These run as well on a 1998 Toshiba 4090 laptop with serial and parallel port, and as said on modern Win machines w/DOSBox-X emulator. Files are all on Bricksafe and are discussed here on EB as well. With regard to the Atari: I recently talked and listened to 9750 using GFABasic on an Atari 1040 ST(FM); needed to first fit the Atari with a Gotek to get some software running (GFABasic, C, PASCAL) and study its hardware a bit. The VT52 emulator on the Atari lets you also talk (and listen) to 9750 - with the help of my little Arduino board running a 5 line C++ "code" . Oh, just for fun: I ran PCDitto (a DOS emulator) on my Atari - then ran my DOS 9750 control program made for the IBM XT on it; gues what: When suing the serial port communication, it talked to 9750 as well - but super slow. I am currently investigating the Atari's parallel port capabilities, which are a bit "different" from the classical "Centronics" configuration. Of particular interest in the GFABasic access via OUT/IN addressing. It appears as if the ST can read and write from/to that port, which in turn raises the question, whether the outputs are latched or not; if not then a read request may change the outputs; and apparently this is also happening because TOS does that frequently. In that case, either a 9771 analog TTL latch approach or an Arduino Uno will do the trick; I'd simply use hat one for latching the parallel data provided at the Atari printer port (in and out). Again, with about 5 line of C++ "code" ... So as said challenge accepted. I am travelling for three weeks - shall think about this and that during that time, and upon my return look further into the Atari world. BTW, the ZX Spectrum, which controls already my train layout, should also be well suited to talk to 9750. Fro sure via it's serial port. All the best, Thorsten

Very nice discussion(s) in this thread! However electronics never drives up the "price tag". In the world we are living in, it cannot. Even when you subtract the development costs ... when selling the product in a "mass" market (and a whopping 0.1% fraction of TLGs sales is still a massive mass market). No, the company selling the electronic device(s) can. It is not the electronics in PUp devices, it is the company selling these - making a fortune out of selling these. As simple as that. Another TLG masterpiece: "Sets like the new Liebherr are so expensive because of the electronics". Sorry, I really don't think so. Introducing a new "electronic" system? Phew. That would require to be able to sell these in mass products. Bat stuff. And all the other super selling products. All the best, Thorsten

Well, size matters ... but you are right of course, Tried to be funny ... It is beautiful, though. Best, Thorsten

May I add (carefully): "The problems have become:" The list is to the point ... It is what it is ... Best, Thorsten

What about 75827 Firehouse Headquarters? Best, Thorsten

You're right. That "tacitly" was missing. And it is more like "largely tolerated". The instruction booklet for the Robokit set (set = cartridge for the Atari STs and software on one diskette) makes references to Atari (at that time, the company selling the kit was apparently not (yet) acquired by Atari UK), Digital Research Corporation and The LEGO group in the legals section; the entire instructions shown are for LEGO models built from the LEGO Dacta sets of that time (1090, 1092 etc.) - no other construction material despite for the home brew sensors is used. In one sentence, "Fischertechnik" and "wood" is suggested as well as alternative building material, but is not used for any of the robots and other builds shown in the booklet. Technic and System bricks only. This is why I thought: TLG must have seen this - and they never complained. But as you said: They apparently tacitly endorsed it - for sure. Still looking for videos the guys marketing Robokit took back then. There are many references in forum entries, websites and text documents, but all interesting links - so far - are broken. The Wayback Machine is of some help, but not with regard to official endorsements ;) Best regards and looking very much forward to updates on your website!!! Thorsten