alexGS

I found the same - calibration does not seem to work. You’d think it would measure the centre position easily, but no - always ends up slightly left. I think it’s more likely a software problem, since the responsiveness of the steering motor to the slide control seems erratic. It doesn’t ‘try’ to move much of the time, so maybe the calibration process is erratic too. I was really disappointed in the lack of drive power (forward and back) - but fortunately I didn’t buy it for being an RC car; I bought it as a parts collection and I’m not disappointed at all in the assortment of black-coloured parts at the price :) I paid NZ$259 which is €144, but I’ve just seen it even cheaper at NZ$235 (€130) although that has shipping to pay (I bought the last one in a local store).

Thanks for starting this thread - I’m watching with nervous excitement :) I don’t know anything about Pascal and the chances of finding those libraries seem slim, but at least we’re a bit closer to learning how the 1092 plotter was programmed in an old scan/photo I saw somewhere (where Pascal was shown).

Thanks for the idea, Thorsten :) Worth a try, using the 4V to supply the Interface A’s optocouplers instead of relying on parallel port control outputs. The laptop PCs that were having problems turning on the outputs were new enough to have USB ports, so I decided taking the 5V from USB was the easier ‘fix’; I think it’s electrically better to have the 5V coming from the PC rather than externally, but I could be wrong. There doesn’t seem much ‘rhyme or reason’, i.e. no obvious pattern to which laptops can turn on enough outputs or which laptops need this 5V boost. I was disappointed that my 2004 Compaq Evo laptop had difficulty where my 2002 Toshiba did not. I think on balance, Toshiba seems a good choice of retro laptop :) Thank you for your efforts to move the Interface A software discussion into a new thread. It was confusing me when I had email notifications about the Control Lab thread updates. Incidentally, for the sake of completeness in this thread, here is my document about the parallel port cable (trying to make it easy for anyone who stumbles into this). https://bricksafe.com/files/alexGSofNZ/interface-a-tc-logo/ParallelPortInterfaceAConnection.pdf

Indeed - I think everything from this post onwards needs to be a new discussion, as it doesn’t have anything to do with Control Lab? I was confused :) There is Thorsten’s thread about Interface A, but it’s long already

Nice one, Thorsten - again, I really respect that you have developed the idea of the old software on modern hardware with a new USB interface as a workable solution :) And then; yes, writing one’s own software opens up all kinds of platforms and possibilities! An Amiga from the period has a parallel port, perhaps it’s possible to control with AmigaBASIC, I mean to try that. And someone gave me a Psion Organiser - a handheld thing that appears to include BBC BASIC and a number of I/O lines. I joined the dots and wondered if it’s possible to control Interface A with it; the two-line LCD is rudimentary, may not be worth the trouble ;) but it would be a ‘period’ hack… Then finally there’s the idea of using a RaspberryPi, with programming in Python or Scratch (a modern hack). Although at that point it’s perhaps easier to forgo the Interface A altogether and use modern motor controllers and IR sensors (something I’ve done already). -Alex

Hello Ry - sorry I’m late to the party (again) - not enough free time here at the moment, sometimes I have a lot and other times little (self-employed)… Thorsten has made a nice diagram above showing that there are different approaches, and he has done an enormous amount of work to test and refine the Arduino-based serial-to-parallel conversion for a modern PC. Meanwhile, I’d like to point out that the parallel cable approach (B) is still a simple way to go - IF you happen to have suitable old PCs lying around that have parallel ports and boot into DOS or Windows 3.1/95/98. My requirement is that it must allow the use of the TC-LOGO programming environment as described in the original materials (e.g. the Reference Guide downloadable from EvanK’s page at the Internet archive; search ‘vintage LEGO robotics). That’s why the hack came about; to allow TC-LOGO to run without the original ISA card. And the PWM (Setpower) still works, since that’s done in software as Thorsten proved. I happen to have a 1995 Compaq Contura 410/1994 Contura Aero (Win 3.1), 1999 Toshiba Satellite 4800 (Win 98), and 2004 Compaq Evo n620c (Win 98) - actually a couple of each - and these are all laptops with native parallel ports that work with the interface cable. The 9750 interface with the flat-top LEDs may require a ‘boost’ from a USB port to supply the 5V to the interface, which is easy on the latter two machines as they include USB ports. The older 9750 interface with round-top LEDs doesn’t require the ‘boost’. EDIT: I just tested with the Contura 410C and the flat-top LED interface works fine without the extra ‘boost’. So that’s still the way I do it, just a parallel cable without Arduino and without DOSBox (although I feel guilty for not using Thorsten’s solution!) I think it’s up to you to decide which path you’d like to take. I like collecting and restoring early laptops - 1994-era is old enough for Interface A in my opinion, even though it also works with Control Lab (Interface B). To quote a LEGO ideas book from the 1980s - “the most important thing is to use the bricks you have in new ways. Have fun!” -Alex

Hello Thorsten - nice work with proving the operation of the 1ms interrupt timer for the PWM - that explains how it works consistently across systems of different speeds. I think you will be successful in your quest to use the same approach from QuickBASIC (or QBASIC?) Thank you for your kind words about my ‘hacking’ - and for proving that the use of the port address in three places is (i) for testing the port, (ii) for outputs, and (iii) for inputs - I appreciate that. Meanwhile, I have had some difficulties with parallel port use on later laptops from the early 2000s, but since these usually have USB ports as well, I hope to try using USB to feed the (relatively hungry) 5V supply to the Interface A of the later type with the flat-top LEDs. I need to do a little more testing to check this solves the problem of not being able to activate more than two or three outputs simultaneously. The parallel port alone cannot supply enough current in this situation (it can for the earlier interfaces, or for earlier laptops). Last night I became aware of this rather-bizarre piece of new hardware: https://www.aliexpress.us/item/1005005528944178.html It has sold out already, even at the rather high price for what it is. You’ll notice that while it doesn’t have a printer port, it does expose the ISA bus - so could support a version of the LEGO 9771 card - check your post above for the typo under “PWM Signal Generation” ;) All the best -Alex

Hello Thorsten - you’ve done extremely well, I’m impressed by your work in checking the timing. I’m sure that 1ms timer resolution isn’t a coincidence ;) I wonder how those baud rate instructions can be added in to the TCLOGO program. Are you confident we can add assembly-language instructions, or should we just start it by a .BAT file instead? :)

Yes, exactly right. Using the original software allows us to ‘play along’ with all the original LEGO teaching material available on the Archive. For us the Arduino is just serving as an interface that works with a more modern PC. I hoped perhaps the use of interrupts for inputs might give some inspiration for how you might code the Arduino to catch the inputs - I haven’t really got my head around it all! :)

Hello Thorsten, Oh! That is interesting - I wasn’t expecting that serial data to work! So now there’s just the problem of inputs to solve, by having the Arduino ‘poll’ the inputs and send data back to the PC? Thank you for your work on this it will be great to have a solution for the newer PCs as well as the DOS dinosaurs.

Hello Thorsten, I started to write a reply, but didn’t get a chance to finish it in time - sorry about that. I wanted to make a proper diagram and a full pin-to-pin list, as so far I’ve been assuming everyone will follow Tom’s instructions, then make the modification I detailed above for the inputs. Indeed the optocouplers must be supplied with 5V, and the combination of an early parallel port with later Interface A causes some problems in this regard; there isn’t enough power from those pins to drive more than two outputs. I’m glad it’s working for you (I think you have a ‘later’ parallel port). While considering your other serial-data question, I stumbled across a very interesting YouTube video yesterday which may resonate with what you’re achieving with the Arduino - have you seen this?

I don’t want to derail the thread, so will keep this brief - but remember the Interface A was an educational product designed in England to work with the BBC Micro first. The C64, Philips P2000, and Apple II were alternatives; all four used LEGO Lines, and the first set of teaching materials was designed around this and set 1090 (1986). The second round of teaching materials (1988) was designed around Logo and therefore only for the IBM PC/Apple II. It seems LEGO partnered with MIT after the Interface A was developed, so effectively ‘re-launched’ it with Logo and the new set 9700. However, there is also Logo-based material in the archive for set 1090. It intrigues me that set 1092 seems to have never been featured in teaching materials.

Hehe - yes - once you try it, you’ll see the prompt says “Continue? J for Yes, N for No” ;) At least I managed to convert all the code keywords, as it really was a bit of a challenge otherwise. I added a few of the shortcut keys I discovered to the background image, since there was no way of knowing apart from trying lots of keys… I also took the liberty of replacing ‘LEGO’ with a LEGO logo similar to the one that appears in the BBC version - complete with (R). However the program does run quite slowly, because it highlights each line as it runs. Pressing F8 runs it without redrawing the display (‘FAST’ mode)

Indeed - couple of years ago, I used my other PC to edit the LEGO Lines program files - and the bitmap image for the screen. The copy of LEGO Lines translated from Dutch to English, at the archive, is my work :) The only compromise is that it requires J or N entered for Yes or No respectively, since I couldn’t change the input part of the assembly code. I should have another try I guess, I understand that one of Evan’s friends is sorting that out…

I got a bit busy this week and still haven’t made a cable diagram - will do it soon - but I have made a video to prove it works

Sorry for the small print and distracting pen-marks, but here’s the answer in the New Zealand price list for 1991… NZ$239 was roughly 1.7x the US$ at the time, so US$140. Yep, I’ve been collecting this stuff for a long time (I was 11 when I had this posted to me) :D

Hello Thorsten, I haven’t quoted, in an effort to save space :) Just quickly - you don’t need a bidirectional parallel port for this - ALL parallel ports have a set of status inputs (from the printer) and we just use two of those (379h). As I noted above; it isn’t practical for us to use bidirectional data in 378h, because of the need to clock the data through. Sorry to say that most USB-to-parallel adapters will not work for this, for the simple reason that they don’t actually emulate an LPT port. I have tried one and it simply adds a USB ‘port’ for a Windows printer driver to use. It does not add a 378h port to the Device Manager. But if, somehow, you DO get one to add a 378h port to a Windows machine, then yes, absolutely the software and hardware will work with it. Now - the last point - something I’ve considered carefully in the last few days - “why didn’t LEGO do this” :) Firstly, the Interface A was designed to work with the BBC Micro’s User Port (the ribbon cable for that machine has the same plug both ends wired straight-through). The user port is practically identical to the Printer Port also available on the same machine. A related challenge therefore; make the BBC software run on the Acorn Electron, which has only the printer port? The C64 cable connected to the C64’s User Port - printers were usually attached to the serial port on a C64. Not always, but usually - all Commodore-branded printers anyway. Likewise, Apple-branded printers were usually serial (except an early dot-matrix offering between 1982-1984 which was parallel; later dot-matrix ImageWriter I/II were serial). The Apple II family, except for the IIc and IIGS, relied on added-in cards for most I/O - disk drives, the serial printer; I don’t think a parallel port was standard or typical, so the 9767 card was a necessary addition. So on these three machines that didn’t use the printer port to attach the Interface A, it would have still been possible to use the printer in a typical classroom scenario of students printing out their code, perhaps to annotate/explain while other students used the same computer… You see where I am going with this? If LEGO had commandeered the PC’s parallel port for connecting the Interface A, they would have created a classroom situation where the printer could not have been used easily, at least not without hot-swapping cables, which is hardly to be encouraged. It was probably intended that the simple 9771 card would be cheaper than an additional printer port card; although marketing doesn’t always turn out how the designers plan it :) Anyway, it does feel like LEGO may have started with the DOS TC-LOGO software working with a printer port, considering they allowed for the different read/write addresses - if it was designed for the 9771 card only, I don’t think they would have made that allowance in the code. At the time of Interface A development, printer ports were not bidirectional, i.e. could not be read from and written to at the same address. The status lines that we are using have been in the specification since the 1960s. Just my thoughts… I have to get some sleep. I also just realised I could use an Amiga with the same cable, its parallel port and AmigaBASIC, which would be kinda cute, if nothing else :) or even its software PC emulator! Never an intended platform, I’ve already had my Amiga 1200 emulating a Mac and operating Control Lab/Interface B through its serial port… the Amiga is that ‘jack of all trades’ with brilliance widely ignored ;)

I’m enjoying this too, for obvious reasons ;) well, obvious if you’ve been reading our big thread about Interface A and TC-LOGO :D Thanks for your work on this! I have Control Lab and all generations of Mindstorms, but it will certainly be interesting to see how they came into being…

Hello Thorsten, Thank you for sharing in the enthusiasm, I really appreciate it :) Yes, I am using one of my vintage (1994) laptops for this, a Compaq Contura Aero 4/33c (486SX33, passive-matrix colour 640x480 7.8” display - it’s a little one!) I have three of these. Running native DOS (after exiting from Windows 3.1) and running on a 28-yr-old battery, too (for 2hrs+) However, I have also tested it on my Toshiba laptop from around 2000 (running Windows 98) and my 2004 Dell Optiplex GX280 Windows XP desktop PC booted to DOS via a USB drive. All these machines have LPT1 ports, the newer ones are EPP/ECP but it doesn’t matter for this purpose. (For technical interest, the bidirectional capability of EPP/ECP requires data to be clocked through - and that is not practical to achieve with the LEGO software. Hence we use Status pins for input; port 379h). The LEGO software generates the PWM! It turns the parallel port outputs on and off fast enough for the motor to be effectively slowed without terrible loss of torque or horrid whining - so the PWM frequency must be several thousand Hz at least. I will check it with my oscilloscope tomorrow. This is the advantage of a tight assembly language loop (about ten CPU instructions between writes; that CPU is running at 33MHz so it’s hardly stressed…), an OS with few other overheads, and an output port that is latched without other translations or processes. It might look antiquated with the CGA display (and it is), but even by modern standards, this software is pretty fast - much faster than Python on a RaspberryPi can control its outputs, for example, just because of all the intervening layers in the modern OS environment (Raspbian Linux). I find Python can miss inputs even at 10Hz… needs to be interrupt-driven. And yes, I carried out the debugging/disassembly with DOSBox-X on a modern i7/Windows 10 PC, just for the convenience of downloading/installing, generating a 250MB dump of CPU instructions, etc. With even more patience, I’m sure this could have been achieved with old equipment, as debuggers and hex editors are nothing new. The story is not over, as I’d love to see a USB-compatible serial solution running from DOSBox-X. That will open this to a wider audience of tinkerers. As it stands, hopefully most people with an Interface A also have access to a parallel-port and DOS-capable PC, now that it doesn’t need to have an ISA slot and a special card made up. There are two other small catches to be aware of - Thinkpads are usually configured with LPT1 not at 378h but at some other similar address (that will be easy to adjust), and there is a slightly more serious problem that some laptop parallel ports may not supply enough current to turn on all the interface outputs together. I had trouble with the Compaq using a later Interface A (with flat-top LEDs) which worked fine on the newer Toshiba. It may be necessary to add another 5V power supply into the cable for some combinations of equipment. Tomorrow I shall test this properly with actual Logo code for my ‘Dacta arm’. There will be a video :) -Alex

I have set up (very roughly) at https://bricksafe.com/pages/alexGSofNZ/interface-a-tc-logo You can download the modified TCLOGO_P.COM (outputs to port 378 and inputs from 379; i.e. printer port LPT1 in most configurations) - https://bricksafe.com/files/alexGSofNZ/interface-a-tc-logo/TCLOGO_P.COM TCLOGO_S (outputs to port 3F8, COM1, not tested yet) - https://bricksafe.com/files/alexGSofNZ/interface-a-tc-logo/TCLOGO_S.COM This is the Turtle page included with the original TC-LOGO: https://bricksafe.com/files/alexGSofNZ/interface-a-tc-logo/TURTLE.LWR The parallel port cable I use is the same as Tom's (https://lgauge.com/article.php?article=technic/articles/LEGOInterfaceA) except for a small change to the inputs: Pin 18 from Interface A goes to Pin 10 of the DB25 plug Pin 19 - Ground - Pin 25 of the DB25 (as before) Pin 20 - goes to a 4.7kOhm resistor, then to the middle leg of a BC547 NPN transistor. The left leg of the transistor (collector) goes to Pin 11 of the DB25 plug The right leg of the transistor (emitter) goes to Pin 25 of the DB25 plug (ground, as used above) This inverts the signal for input bit 7 - and it works correctly, because the parallel port has an internal pull-up. Photo - please note that pins 12 and 13 of the D25 are NOT used - it looks like they are connected but those are pins 24 and 25 underneath Tomorrow I shall draw a diagram... Other files in that folder include the use of the DOSBox-X debugger, a sample dump of the code executed by the CPU, and the online hex editor I used to change the port addresses. The order of the addresses is important, since one is the input and one is the output (I don't know what the third is used for but probably for testing the port). -Alex

Hello Thorsten, I managed to substitute 3F8h for the address and immediately generated serial errors in the DOSBox debugger window - I think that's a good sign. Would you like to give it some testing please?... I will put the modified TCLOGO_S.COM into a DropBox soon. EDIT: I've put it into Bricksafe, I'm impressed that it accepts files of all types :) see below. I wondered if your Arduino program would run in a loop, continuously updating the serial port ('polling' the inputs) at the same time as it updates the outputs? I guess I expected that the Arduino would be the 'bus master' (so to speak) and the PC would put output values at 3F8 for the Arduino to collect, plus read the values that the Arduino places there. This expectation probably shows my complete lack of understanding of how serial communications work :) I was wondering how Setpower would function; would the Arduino update the values regularly enough for the PWM to operate, or would there be a 'Nyquist sampling error' (aliasing) where some of the cycles are lost? I like the use of the parallel port for three reasons; - The values stay 'latched', so that it works in the same way as the "dumb" ISA card :) This means it keeps up with Setpower - PWM works just as intended. - The cable is cheap to make. It needs a 20-pin header, a ribbon cable, a D25 solder plug (a little fiddly), one 4.7k resistor, and a BC547 transistor. - Five of my laptops and two of my desktops have a parallel port (none has an ISA slot). I realise that many readers will not have a parallel port, but there is a fair range of desktop and laptop PCs until about 2004 that were so-equipped. For example I have a Dell OptiPlex GX280 (Pentium 4, with parallel port) that runs Windows XP, but I can boot it into DOS from a USB drive. It doesn't hold much appeal as a retro PC, to be honest, since it can't run Windows 98, but it is highly functional for this kind of thing and probably very cheap to find, if they haven't all been thrown away by now. -Alex Thanks for your advice - I will try to get something set up there shortly :) EDIT: I now have, what an excellent service! Cheers for that, it made it easy...

Yes! Tears of joy... I am very happy right now - I have the TC-LOGO program working with the parallel port - for outputs and for inputs! It turned out that the port number came from three places in memory. A little sleuthing in the assembly language showed me that the first occurrence is used for inputs, and the second for outputs! (I couldn't be certain of the third use, but probably for testing of the port). This is a true blessing for the use of the parallel port, since the six output bits can go to 378h (decimal 888) and the two input bits can come from 379h (decimal 889). The use of the parallel port has already been demonstrated by Tom at LGauge, but he used bits 4-5. TC-LOGO of course expects bits 6-7, so the cable needs a modification, and ideally bit 7 needs to be inverted due to the way the parallel port works. More to come, I will make a video and a diagram showing the cable requirement. I do apologise for the change of approach, which I will address in the next reply.

Quick recap in case anyone else reading this thread has lost track of what’s happening; there has been a change of plans since the start: 1. Thorsten has made the Interface A run off a serial port, via an Arduino to translate serial to parallel. This has wider compatibility than a re-creation of the 9771 card (even if the latter were on a PCMCIA or PCI bus as I was considering). 2. I’m trying to modify the LEGO TC-LOGO software to use the serial port (3F8) instead of the LEGO interface card (39D). It is a small DOS program written in assembly language, but I don’t know what I’m doing. I’ve used the DOSBox-X debugger to find the port address being used when the program runs, and now I need to find where it is first loaded into RAM so that I can change it. 3. If this modification works, I hope both solutions 1. and 2. can work together to program the Interface A using Logo without needing an ISA-slot-equipped PC and the 9771 interface card (or replica). -Alex

Thanks. It seems like a long time ago that I had to host images somewhere else - must be 20 years since I used imageshack.us. I don’t use any such sites these days; it would be easier to post a YouTube video. Maybe a Google Drive link would work. Links inevitably get broken anyway, and we are probably creating this for when someone else searches for it in 10+ years’ time..! The TC-LOGO software for Apple II allows selection of the slot number where the 9767 card is installed. I just expected the PC version would offer the same, in case you could run the same software twice with two cards installed. But I see what you mean - it’s more likely that it auto-configures just one card. Anyway, continuing with DOSBox-X Debugger, I need to find how the port address gets into memory (at two different offsets) when the program runs. This is a relatively simple program; there’s no protected mode memory paging, etc. But I still feel frustrated at not knowing where numbers come from. I’ve realised that the number in square brackets is an offset, rather than an absolute address. I’m hoping some other assembly-language line places the 39D value into those memory locations that are then used again and again whenever the port output is updated. I shall try again tomorrow, this time with debug ‘on’ as soon as the program starts. Hopefully I can step through the lines that run first, one by one, and recognise what happens with those memory locations. Otherwise, they must be part of some data area loaded when the program is loaded (I barely know how programs work). My qualification was electronics, not computer science… -Alex

Hello Thorsten, Thank you for the notes about your Arduino sketch and application - which I will need eventually ;) I haven't got that far yet. Today I tried Ghidra as promised - it was a dead-end though, as that clever decompiler simply isn't set up to handle old DOS .COM executables with no headers and unknown development language, etc. More convincing was the Reko decompiler, which seemed to spit out believable assembly language, but better still is the DOSBox-X debugger - because with that, you know the assembly code shown is the assembly code that's actually running, rather than some 'best guess'. As you said, DOSBox-X works fine with TCLOGO.COM and if only I knew how to use the Debugger properly, I think I could get somewhere. I prepared it by typing the TCLOGO command 'talkto "a onfor 1', and then in the debugger, I typed 'log 100000' to log the next 100,000 CPU cycles to a text file... then I clicked back in the TCLOGO window and hammered the Enter key... response was extremely slow (execution was slowed right down) so hopefully I got there in time. Looking in the text file (which is 256MB in size... whoops), I seemed to find the smoking gun in the first few lines... mov dx,[9345] ds:[9345]=039D I think that's trying to tell me that location 9345 (?) contains hex 039D, which is of course equivalent to decimal 925... After this line, the EDX register contains 039D for the next few dozen instructions. I would love to upload screenshots, but I can't because I can only upload 0.02MB here. A little further down, it seems 9343 also contains 039D - I don't know why it would be in two places, but a search of the text document confirms that it is consistently in both places. How does it get there? and how can it be changed (to 03F8)? These are the questions to answer... -Alex