Toastie

OK, I have to admit, I read your post with some - no with a lot of joy. But I would rephrase that piece of text as follows: Obviously TLG is run by a bunch of greedy scum bag capitalists. Why? "Obviously" becomes obsolete, as "greedy" + "capitalist" is like a "black rap". "scum bag" is well, again a black rap in this context ... Other than that: Yes. I agree. Don't know about IP infringement rights in this case, the internet is essentially "open source", I do know though how low, how very low TLG's approach on this documentation really is. @kbalage: Your website was so much better. In every regard. Best, Thorsten

OK, full report is out in the Mindstorms Forum. No, I meant the Technic Forum, of course . Cross posting is strongly discouraged on EB, so I leave it with the link to that thread as it will drown there in a couple of hours So this is my second entry for the challenge! More importantly: When rummaging through my salvaged electronics parts and pieces, I found this: As all of you know, this is a ZX Spectrum main board connector - in MINT condition! I have two Spectrums and did quite a bit of programming and made hardware additions for them back in the days, some 35 years ago. And recently ... so now that the Atari is done, I am considering to get one Speccy in touch with 9750. On the connector, there is everything: Address, data, control lines, power ... and I do still speak a bit of Z80 assembly ... hmmm. The Speccy has a totally messed up address management, but that is so well documented, I'll find two unused I/O addresses ... TLG endorsed system, as per @evank are: Apple II (CPU: MOS 6502, 8-bit) BBC Micro (CPU: MOS 6502, 8-bit) Commodore 64 (CPU: MOS 6510, a variant of the 6502, 8-bit) IBM PC (CPU: Intel 8086, internally 16bit, with 8-bit data bus) Philips P-2000 (CPU: Zilog Z80, 8-bit) How many other non-LEGO endorsed systems from < 1992 were used for that purpose? I have added the Atari ST to this list, what else is there? There must be so many! The ZX Spectrum would be Z80/8 bit as well. Atari 1040 STFM (CPU: 68000, internally 32 bit, with 16-bit data bus) All the best, Thorsten

Dear All, strongly motivated by Evan Koblentz’ (@evank) “9750 LEGO Interface A hacking challenge” announced here on EB (https://www.eurobricks.com/forum/index.php?/forums/topic/195711-a-challenge-lego-9750-interface-a-hacking/), I wandered into the Atari ST world, looking at the ST’s hard- and software for the first time in my life – never had the chance to play or work with one of these beauties back then. Found three of them in “the basement” of my research institution’s labs, and one of them worked flawlessly (the other two need a little attention, as they throw bombs when booting up). Executive summary As already briefly “announced” in the referenced challenge thread: I managed to get the Atari’s “a-bit-special” 8-bit parallel port (it is fully bi-directional, but has only two control lines, strobe, STR#, and BUSY) with the help of just one (ancient) 74LS273 TTL chip, some resistors, and a 5V power supply, to operate the 9750 LEGO Interface A from 1986/7. This is a brief write-up of how I found out how the I/O hardware protocol of the Atari ST works, when using GFA BASIC 3.0 as programming language (1988). GFA program(s) and interface schematic are here: https://bricksafe.com/pages/Toastie/atari-st-and-9750. Video to follow, I am running a little short of time at the moment. Here we go, another long vintage LEGO story … According to the three challenge rules, Evan posted in the above referenced thread, namely Use any computer and any programming language you like, as long as it was for sale in 1992 or earlier (as the next-generation 9751 / Interface B debuted in 1993.) Don't use any add-on hardware that was not available back then. A breadboard is fine; an Arduino is unacceptable. It's okay to run emulators if you do not have original machines, but you can't use any additional features that did not exist back then. You can use Windows 1.0 or 2.0, but not 3.1 libraries, etc. I became very happy after reading that, as an Atari ST qualifies as a legit computer system in this challenge! My ST is from 1987 - and it features a parallel port - which gave me hopes that I can probably get this >68000 CPU loaded 32-bit power machine< (running at 8 MHz CPU clock speed with 1Mbyte of RAM available!) to controlling the 9750 LEGO Interface A. As Arduinos and the like are not allowed for interfacing, nor using any hard/software produced after 1992, I was dreaming of TTL world, as I did when I was more than 35 years younger. What did I have at my disposal for coming up with an Atari interface (that also met the three rules of the challenge)? An Atari 1040 ST(FM) (1987) with parallel and serial port GFA BASIC 3.0 (1988) with access to serial, parallel, and MIDI ports A good number of TTL chips saved from being trashed; they all date back from the 1980’s Soldering gear, an oscilloscope, multi-meter, bread board, resisitors, LED's … I began initial programming using the ST’s serial port. After all, I first had to learn GFA BASIC, and how GEM works, and so on, and so on. Never used an Atari before June 2023. I more or less “copied” (well typed in) my working DOS QuickBasic routines controlling 9750 on an IBM XT (https://bricksafe.com/pages/Toastie/lego-interface-a---9750---9771---tclogo/program-files-) into GFA BASIC – with – “some” limited success. The thing is, the Atari’s serial port has I/O buffers; the IBM XT has not. When garbage accumulates in these buffers, my Arduino “protocol” is seriously screwed up. This “protocol” does this: Send a byte to the Arduino over serial (RS232) or UBS and then immediately listen to the reply. After conversion to parallel on the Arduino, the sent byte sets the 6 outputs of 9750; the Arduino replies back the output states of 9750 in addition to the two sensor input states. This is the protocol (send and immediately receive one byte) TLG used on the IBM XT with the LEGO 9771 interface card as well, and (I believe) on all other LEGO endorsed platforms also. It turned out that the two GFA BASIC functions "boolean=OUT?(port,byte)" and "boolean=INP?(port)", which are replying the status of the ports as FALSE=busy or TRUE=available, did not really work as expected using the serial port (AUX: or “1” in GFA BASIC). In a hardwired “client/server” setting (client=Atari, server=Arduino), it is all about initialization. Once that is done, nothing much can disturb the communication other than programming errors. In other words: Whatever garbage is in the serial out buffer upon startup: just dump that. Then do the “LEGO style initialization process”: OUT 1,bin0010101; var=INP(1); IF var AND bin0011111=bin0010101 then hardware is present and works. And that worked very well on the Atari; 9750 was controllable with an Atari ST via its serial port with the help of an Arduino Nano as serial2parallel converter. SUCCESS!!! BUT, BUT, BUT: CHALLENGE RULE #2 says: Don't use any add-on hardware that was not available back then. A breadboard is fine; an Arduino is unacceptable. !BUSTED! Well, back to the drawing board. Atari forums and other websites note: The parallel (LST: or “0” in GFA BASIC) port of an ST is somewhat “special”: It lacks some control lines most printer ("Centronics") ports and parallel printers featured back in the days, such as an acknowledge (ACK) line, among others. The ST’s parallel port has (only) a “strobe” (STR#) and “busy” (BUSY) control line, the eight bit D0-D7 lines, and ground. That was good enough for most 1980’s printers, so in essence all was fine … Much more importantly, you can write to AND read from the parallel port using ALL 8 DATA BITS! WOW! As there is no reason to read the 8 bits from a printer, these Atari folks had certainly something else in mind than just printing from the parallel port. Third: Data copied to the parallel port are “transient” of nature, as the Atari operating system uses the 8 in/outputs for other purposes as well, according to Atari forums. And the internet tells you: Fast parallel data exchange via the Atari parallel port possible, using special cables, protocols, hardware, and software. What to do with that rather confusing information? Not much. Well, what did help me, was getting hold of the Atari ST PCB schematics, breaking out my good old Tektronix oscilloscope, solder/crimp a 25 sub-D connector style parallel cable (using only 11 lines: STR#, D0-D7, BUSY, GND), run GFA test programs, and poke around a bit with the two oscilloscope probes ... It quickly turned out that the Atari sends out data over the parallel port when using the GFA BASIC “OUT 0,byte” command only when BUSY=LOW. That is fully in line with the early Centronics “compliance mode” protocol: Check the BUSY=LOW condition, when that is/becomes true, put data on the data bus, assert a HIGH,LOW,HIGH) strobe (STR#) pulse of some microseconds length (Atari: 100 us), on the negative STR# slope, data are clocked into the printer, which in turn asserts BUSY=H, and when ready again, asserts an ACK LOW/HIGH/LOW pulse and then pulls BUSY to LOW again. The Atari however is lacking the ACK line; if BUSY is HIGH (=device not ready, see below though! This changes later to: BUSY=HIGH=external device ready for providing data and BUSY=LOW=external device ready for accepting data), it waits some 30 seconds and tries again before eventually timing out. The schematics of the Atari ST reveal that it’s parallel port is operated bi-directionally by the Yamaha YM2149 “sound chip” – but that chip it is much more than that: It features, among other things, two 8-bit wide I/O ports, one of which is used for the Atari parallel port; STR# is provided by one line of the osecond YM2149 I/O port, BUSY is connected to input “I0” of the Atari’s 68901 multifunctional peripheral chip. Note that the BUSY line is literally “bolted” to +5V via a 1kOhm resistor – pulling it LOW (< 0.8V!) needs a solid TTL LOW signal. All lines of the two I/O ports of YM2149 are internally pulled-up HIGH; according to the YM2149 datasheet with 60kOhm minimum resistance – here a grounded 4.7kOhm resistor should be OK to get below 0.8V = TTL LOW – 2.2kOhm should be on the safe side. Next step: Testing GFA BASIC simple input/output testing routines and record changes in the STR# and BUSY lines. BUSY was clamped to LOW and repeated OUT(0,byte) write data attempts in a simple for-next loop were performed: Worked fine. The oscilloscope trace of the STR# line is depicted schematically in panel A), top trace, in the figure below. All seems to be in line with the Centronics protocol. Check! Performed INP(0) read data attempts with the same setup – but nothing happened! Program froze up immediately, no break (CTRL+ALT+SHIFT) was possible. However, simply removing the LOW clamp from BUSY and letting it “float” (well, see schematic above, it is pulled-up via 1kOhm to +5V = HIGH) reanimated the program >instantaneously< and the upper trace in panel B) was recorded when repeatedly reading the data lines with INP(0). Check! But then … … I thought “strange” … when does the presumably negative slope trigger on the STR# line for OUT (according to the Centronics protocol) “transition” to a positive slope trigger for INP? It did not make much sense. Google was also not helpful, even after hours of searching. Which left me with: Trial and error. I love trial and error. At some point, I arbitrarily connected STR# and BUSY – did not work either, program froze again up. When trying repeated OUT commands that is. As said: Deep in trial and error territory I was. However: In retrospect, this could of course not have work but revealed the following: When turning the computer on, loading GFA BASIC, running the program, the first OUT command worked, a second did not. The oscilloscope showed: Initially (STR# + BUSY) = L. And then OUT works??? What??? This means, that a >positive< slope of STR# is supposed to clocking the data into the external device! Not the negative slope, as the Centronics protocol suggests. After the first OUT command, (STR# + BUSY) = H, so a second OUT cannot work. But an INP should – and did! After that step, (STR# + BUSY) = L again, and another OUT works etc. This also means that INP reads data on a >negative< STR# slope. The trace on the oscilloscope obtained with repeated OUT/INP loops are depicted in panel C) in the figure below. At that point, the “rules” for operating a dumb device (dumb=providing/having no control lines) >bi-directionally< using the Atari’s parallel port became rather clear: STR# + BUSY = LOW on initial OUT/INP sequence. This is straight forward: Gather the status of BUSY using OUT?(0); if FALSE then BUSY is H; if so, do one byte=INP(0) and simply dump returned byte; now BUSY=L and “endless” repeated OUT/INP sequences can be done: As the OUT data are “lost” on the parallel I/O lines at some point (according to the Atari forums after a few ms), and at latest, when reading the lines with INP, they need to be latched on the >positive< slope of STR#, see above. TLG used transparent 8 bit D-FF TTL latches with tristate outputs (74LS373) on their 9771 card. This fancy approach is not possible here, as there is are no dedicated IORead# and IOWrite# lines available, there is only “one” line (STR#=BUSY) for clocking data in and reading them out. For that purpose 74LS273 is a perfect match: 8 non-transparent D-FF TTL latches, having always logical defined outputs (L or H); all logical levels at the 8 D inputs are latched with a positive TTL slope at the CLK input and immediately show up on the 8 Q outputs. A negative slope at CLK does nothing, so when reading data with INP(0), nothing happens to the 8 Q (output) states of 74LS273. As all this is securely happening “behind” an I/O chip (YM2149) and not directly on the CPU’s data bus, and as we know that there are 60kOhm pull-up resistors on each parallel port data line, we can use a dirty trick to feed-back the Q output states of 74LS273 to its D input lines via 2.2kOhm resistors: In output mode, YM2149 easily drives the D inputs of 74LS273 to H/L, even when the corresponding Q outputs are L/H; the 2.2kOhm resistors prevent any harm: The maximum current flowing, when D=H and Q=L is 5V/2.2kOhm = 2.2mA. Each output of 74LS273 as well as each output of YM2149 easily sink/source that current (BTW, 10kOhm feedback resistors don’t work, as the voltage on the D line does not drop to or below 0.8V when Q is L. The YM2149 does not know what to do with such a voltage; it simply says it is still H, as tested). This approach of using resistors within the 8 data lines between an external device that can read and write and the Atari’s parallel port as security measure is widely known in corresponding websites and forums, see for example here: http://info-coach.fr/atari/hardware/interfaces.php#if_parallel. Finally: The two sensor lines of 9750 are routed to the D inputs 6+7 of 74LS273; on each OUT/INP sequence, the corresponding Q6+Q7 data become available to the program running on the Atari: The OUT command clocks the data in, the INP function reads them in (in addition to D0 to D5). And that’s it. Here is the schematic for the “interface” (= one 74LS273 + 8 x 2.2kOhm resistors + 5V power supply, which is not that much of an “interface” …). +5V power may be obtained from the Atari main board (this is a bit on the invasive side) or from any generic +5V power supply. Shown in the schematic is a stone-old 7805 regulator, which can be fed with DC power from +7 up-to +25V, +12V recommended. The LED’s are purely optional; with them you don’t need to connect the 9750 interface A but will have the same light show ;). The 1uF/10kOhm RC combo on the RES# input of 74LS273 ensures that it does not arbitrarily “flip flop” during power up. The very old TTL “trick”, I know. Also optional – upon initializing the parallel port, all is fine. In that case, just connect RES# to +5V. And here is the tidy, very organized and (or better but ...) working breadboard version of the Atari parallel I/O interface for controlling LEGO Interface A. As far as I know such a thing does not exist - correct me if I am wrong though!!! More on programs I am using for controlling 9750 per key clicks or per “user programs” in subsequent posts in this thread. All the best, Thorsten

"Major" update (for the 8-bit nerds only, of course) Yesterday I got it to work. Interface A (9750) controlled by an Atari 1040 STFM from 1987 (PCB says so) via its - a bit weird - parallel port and with a little help of: a 1987 5V (+12V, not used) power supply I used back then for powering two 5 1/4" floppy drives I added to my Schneider Joyce (PCW9256 from 1991, (https://de.wikipedia.org/wiki/Amstrad_PCW) a 74LS273 (https://www.ti.com/lit/ds/symlink/sn74ls273.pdf?ts=1692440430516&amp;ref_url=https%3A%2F%2Fen.wikipedia.org%2F) from >way< before 1990, used, most probably resurrected from an old computer - found that one "in the basement", well 10 of them. 8 x 2.2 kOhm resistors. optionally, 8 x 1 kOhm resistors and 8 x 3mm LEDs - just for program development, when you either don't have 9750 (which features corresponding LEDs) or want to program "offline" GFA BASIC 3.6 using only commands from GFA BASIC 3.0 from 1988. @evank: Are these conditions matching with the rules of the 9750 hacking challenge? If so, I'll prepare a full report on this All the best, Thorsten

Don't worry; 2.4GHz penetrates acrylic glass easily. Play well! Best, Thorsten

Update Moved yesterday from "coding" (well, BASIC; GFA BASIC 3.6 though ... that language is powerful(!), I surely have to admit!) within the Hatari emulator to my real Atari 1040 STFM. Took me a while to figure out the I/O mechanics on the serial port using "OUT serial_port,data" and "var=INP(serial_port)" - but got that to work today. I have now an Atari ST controlling 9750 via its serial port and my Arduino Nano serial2parallel converter. So this is >NOT< an entry for the challenge, just an update, as the entire "controlling infrastructure" is done: Yes, I know, this is nowhere being slick, but it works: Left row: Inputs. Blistering fast readings of both inputs and updating counters (2nd line). 3rd line = input bits numbers. 4th line = io_status byte, always up-to date. Center row: Outputs. T=toggle outputs on/off upon pressing numbers 0 to 5; P=pulse outputs with keyboard rep rate. Right row: Mode. So far simulation (checking any program operating a robot via 9750 without actually turning the output ports on), and serial work. Parallel is to be done. Commands recognized so far are: T=mode "toggle outputs" when pressing 0-5, P=mode "pulse outputs"; X=select I/O mode (sim, parallel, serial, space bar activates mode), R=reset counters. To be added: A ... G=User programs; corresponding subroutines are easily coded. My guess with the weird Atari parallel port is, that a modified 9771 circuitry will do the trick. No need for address decoding; this is done in GFA BASIC by selecting LST: as output and input port (yes, the Atari can read the 8 bits of its parallel port - sweet! However, latching the Atari's parallel port 8-bit outputs is required; and I need to figure out what happens to the strobe line when the Atari is reading the port. We'll see. Best, Thorsten

Yeah, number-wise that may be true. Color-wise as well. Inspirational and educational ... I have at least my doubts. It could also be that the smaller = more affordable sets have all the Technic "spirit" - I simply don't know. I also don't know about the price tag increase on the smaller sets ... when doubling $400 it seems to hurt and become "monstrous" in comparison to doubling the price for a $30 set ... but again: I'm out on this battle. Best regards, Thorsten

I totally agree and there is >nothing< wrong with that in the rich folks world. Nothing. The thing (for me) is, that TLG still pushes this "we care, we're educational, we are producing valuable toys, this is all about imagination, learning" and so on and so forth. (Just visit any of their websites, and it literally pours out). To me, TLG was like that, back in the days, as far as I remember (I am 60+ years old and since turning 3, I had a very modest amount of bricks, which grew into a modest amount of bricks over 12 years). And after about 40+ years, I can also afford all of their products. But I entirely lost interest in all that "new" money making stuff. There was "the RCX", and as I have learned from folks like @alexGS, @evank, @BatteryPoweredBricks, and so many more here on EB, there was a world of minds before the storm. The original Mindstorms series had it for me, as well as many Technic sets of that time. To me, it was educational. And semi-affordable. Expensive, but there were these annual Christmas and Birthday days ... where the entire family chipped in for a big one. Wandering into the forgotten worlds of LEGO - no replies from them. Zill. They are busy on making the big money. As said, I can totally live with that. It is what it is. TLG being educational? Inspirational? Not for me anymore. I am off to thrift stores, talking to people, paying (much) more than they are asking for. Because I can afford it. And these folks are inspirational. Well, I need to log off and research on @evank's challenge. Got my Atari ST talking to 9750 today ... I hope to find this key - Ready Player One ... Evank's challenge is a true LEGO adventure game - for me Best, Thorsten

And that is perfect!!! It does not get any better! Build cranes and feel good! Here is to feeling good My cynicism is not hitting on folks loving cranes, trains, LEGO in general - it is always about big brother over in Billund and what they do price-wise - and the total and utter loss of not looking at revenue. Which is fine in the world we all live in - and that world is what it is because we decided to let it become what it is. I am also living in this world and do my share. Being cynical is always the easiest way "out", and I know that - so please do not take anything personal I post in forums, where all I can do is simply admire what folks like you and others accomplish. A total different league. I just crash in here - they merged Mindstorms with Technic - so I "need" to be here. And I am enjoying it. All the best, Thorsten

I totally agree. Well, too small "it" is in every aspect, wasn't that the major criticism? Too small hurts, I guess. Twice as big is much better. So ... let the too small dust settle, then the other sets will magically appear. But first I'd rake in the Liebherr credits! If I were designing this game, of course. No, toy(!) of course. Sorry! Isn't that a cool conspiracy theory? We are now talking 1000$/€ per game played here ... I need returning to wrestling with GFA Basic on this Atari ST to find the second key for @evank's challenge ... may need to purchase another 9750 (for 50 credits) for that game ... Best regards, Thorsten

@alexGS Your approach is 100% the way to go!!! We should praise TLGs research department: They actually managed to use smart wire insulation material that - exposed to light or not, just not used at all or heavily bent back and forth - degrades terminally after 10+ years into slimy shreds of something. Even carefully heating this super smart material up makes things only worse. Congratulations on this one! Too bad, that the metal wires don't oxidize into some rusty crap - someone did not pay attention here!!! In conclusion: The historians will certainly cope with "wrongly" colored 9V terminals connected to new wires. All the best, Thorsten

Ah, TLGs good ol' PTT (passenger train trick) hits again with success! Since quite some time now, they only sell 1/2 of a passenger train - which always looks stupid; the HE, the new HE, the ICE, the new ICE (yes a wheel in perpetual motion it is), and so on and so forth. So, buy two and it looks "good". Or more "realistic". And since the equation (€ 650 - huge rabatz) x 2 = huge profit still holds (as in the train world, here we are looking more into the € 150 region), all is good. They did it again - this time in the high price region! All the best, Thorsten

Hi Alex, no, as far as I am concerned, you did not, in contrast. Your method works on 9V 2x2 connectors as well; yes, some are using the cutting blades again - I just cut them down and then solder. Carefully, as you do. Thank you very much for sharing! All the best, Thorsten

Here is to feeling good All the best, Thorsten

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