LEGO Interface A (9750/9771) – LEGO Technic Control 1 (TC1) reference/ideas thread

[BatteryPoweredBricks]

11 hours ago, evank said:

Except that the video title says 90s! It should be 80s.

I included that particular "um actually" in the comments

[evank]

Guys - I've got a dilemma. A few months ago, I found someone selling a massive supply of our favorite Lego gear. So now I'm in possession of too many 9750s, too many 9771s, and too many 9700 kits. I sold a couple of them already, but I need to sell the rest soon, because of credit card bills. I want these go to people who'll really appreciate them -- I don't want to see people hoard them, or stick them on a shelf and never use them. And I'm not trying to make a profit, I'm only looking to recoup my costs.

I'm offering five bundles for sale. Each bundle includes two 9700, one 9771, and one 9750. The cost is $400 each (US), plus shipping. I previously posted in the for-sale forum but we all know that here in the 9750 discussion is where people might actually respond. :)

I also expect to have some extra 9700 kits, maybe a few extra 9750s, and some other miscellaneous stuff, after the bundles are sold.

Please help me out by buying these bundles :) because I got myself into too much debt, so I'm panicking a little bit.

Last year I purchased a bunch of the Apple II versions, and those found new homes very easily. I expected the same from the PC versions. It's not been the case.

I also have avoided putting these on eBay or Bricklink. Rather get them to the best hobbyists and people I know!

Edited August 28, 2023 by evank

[Toastie]

On 8/28/2023 at 9:50 PM, evank said:

Guys - I've got a dilemma.

Heavens - this should not be anywhere near a dilemma ... you are selling Marvels of the Universe ... and $400 is a very low price!

I believe a bit more of advertising may help? Pictures of the content (I guess the boxes are "unopened" - no need to do that, as we apparently have video?), some nice words about each item?

And then: Maybe telling folks the prerequisites for running that incredible stuff? Yes, we are in a very well-educated LEGO forum, but when going that much back in time, the set numbers alone - I believe - may not make that much sense even here. I may be very wrong on this (sorry folks!!!) but this stuff was sold to schools and was hardly available to the average LEGO customer.

When you google the numbers, not that much of "trusted content" shows up. I'd - as said - would advertise a bit more, and graphically. After all, 9771 is pure Unobtainium. 9750 is on BL for $50 (EU, only 2 items!!!). 9700 for $100 (US, only 1 item); all + S&H. Again, your offer is very reasonably priced!

I asked around in my university today - not much of a response; the folks I work with are all weird chemists - they believe that ABS is a bit outdated. In my research group, they believe everything before 2000 is - Tomb Raider stuff. The physicists - well, are physicists. The don't even have a remote idea regarding element 42-4 in the Periodic Table.: Unobtainium.

I will push on. Sorry that I failed so far.

All the best,
Thorsten 

 

[evank]

Don't apologize, you're probably right. I just figured in * this * sub-forum no pictures or further explanations are necessary. :)

[maehw]

Wow, what a nice thread!

Thanks everyone for sharing their knowledge, insights, experiments and so on!

While reading through the thread and before stumbling across @Toastie's diagrams, I've started to create my own one to get an overview of the hardware+software from that era... as I am more a "visual learning type":

This may be wrong (please help me fix it) - and for sure is incomplete.

Also special thanks to @evank for publishing videos! Do you have an update on the Philips P2000? And: are you still wanting to sell a hardware bundle?

If I find time - and a 9750 - I'd like to use @Toastie's approach with a USB/serial converter + an Arduino acting as serial/parallel converter + DOSBox-X + @alexGS' modified TC Logo version for the serial port (on either Mac OS, Linux or Windows - preferably one of the first two)... and also see if there's other software we can run (or bring it to the browser such as I tried with WebPBrick).

Cheers!

 

Edited November 1, 2024 by maehw

[Toastie]

Welcome to the club @maehw!

Your diagram is marvelous - I can't find anything wrong. Thank you for your effort!!!

Just recently I though trying the "modern computer link to 9750" with a Bluetooth-2-USB adapter, these HC-05 (or HC-06) thingies. Works like a charm. All you need in addition is an Arduino - this time I used a Pro Mini, which essentially is a Nano without USB port, as the HC-05 does that. I made an ugly socket to connect both - this way I can use them for other things as well. The Pro Mini gets nicely conditioned 9V from #9750; I just soldered two wires +9V and GND to unused pins 2 and 4 of the 20 pin socket of the Interface A - the Pro Mini has a 5V regulator on board and supplies that to the HC-05. The nice thing is: Wherever you place the #9750 box with the BT extension, you can access it from your computer, as the HC-05 just becomes another COM port visible in device manager BT after pairing. Then edit the DOSBox-X config file in the serial section, it all works:

More here: https://bricksafe.com/pages/Toastie

Will post that in the next weeks along with an updated QBASIC program.

All the best and have fun!

Thorsten

[maehw]

This is not a sponsored ad — I just thought that this might interest some of you:

>Do you like Lego? Do you like the Apple IIe/IIgs? 

>

>Blocko is an interface card that allows you to control Lego Technics machines with the LOGO programming language, just like we did in elementary school!

>

>Available in November 2024

>

>https://blocko.net

 

[evank]

@maehw - Welcome to the fun of connecting Lego to 8-bit computers.

I do not yet have a P2000 update.

Yes, I routinely have stuff available for sale. I'll send you a private message.

I heard about Blocko last week. Hoping to get one soon for testing.

[maehw]

Hey all,

I am asking myself if anyone has access to LEGO Lines for the IBM PC/DOS?

• http://lukazi.blogspot.com/2014/07/lego-legos-first-programmable-product.html mentions it with number 9537 as "the IBM-PC version" -- so it must have existed
• https://archive.org/details/vintagelegorobotics currently lists versions for the BBC Micro, the Apple II, the C64.. but not the IBM PC
• https://lgauge.com/technic/LEGOInterfaceA/9750(1093).htm is "very much interested in the IBM (DOS) software, if anyone has it for download or even the original diskettes"

Is this piece of software really lost? Or maybe only slumbering on floppy disks in attics? Has it really not found its way to the interwebs?

I'd really like to see this piece of software running in DOSBox-X as well.

 

[Toastie]

1 hour ago, maehw said:

Hey all,

I am asking myself if anyone has access to LEGO Lines for the IBM PC/DOS?

If anyone, chances are @evank may know ...

Best,
Thorsten

Edited November 7, 2024 by Toastie

[maehw]

13 hours ago, Toastie said:

If anyone, chances are @evank may know ...

Best,
Thorsten

Thanks. Yeah, I anyway contacted Evan.

Actually, there's a German book called "Steuern und Regeln mit LEGO Lines und dem LEGO TC Controller" (1989/1990). It's also avaliable on the archive.org website IIRC. I am currently trying to reach out to the authors from back then. It mentions an IBM compatible disk but also that LEGO Lines had only been available for two types of machines — but does not mention which ones (edit: from the details in the chapter: it is Commodore C64 resp. the IBM PC running DOS). This would not match with the info from above. But it's still possible that the software has been posted to other machines. Who knows. 

Edited November 8, 2024 by maehw
Add info

[Toastie]

32 minutes ago, maehw said:

I am currently trying to reach out to the authors from back then.

Hello @maehw,

I believe this may be not that successful, but who knows.

@evank did the scanning of the book, which, if I recall correctly, was sent to him by Helmut Albrecht, one of the authors. Back then, Helmut was high school teacher and later became Professor at the University of Education, Schwaebisch Gmuend. I have been in contact with Helmut last year and this year, a very nice individual. He tried to find stuff related to TC Controller and LEGO Technic Control in general - to no avail. They had issues with water damage to their building/s etc. 

Helmut also contacted Herbert Hödl - but again, all TC stuff they had (and that was a lot) seems to be lost. Herbert has retired since long, Helmut retired recently and has a long list of non-LEGO related activities.

I then contacted LEGO dacta customer service and told them the entire story with reference to EB etc. They actually replied and told me to be patient, as they wanted to inquire at LEGO Archives in Denmark. Evan and I were particularly interested in the TC Controller software as well as PASCAL code implementation, as discussed in the reference book. TC Controller provides, as the LEGO Interface in combination with #9771 and TC Logo, PWM control.

Well, what should I say: TLG decided that it is not possible to release any further information or even software from their archives due to patent and NDA regulations. Wow. That software is from <1990 ... about 35 years ago.

And at that point, we "gave up" - if you have more success, please report here!

All the best,
Thorsten

 

[evank]

@Toastie, that's a good summary.

Here's an update for everyone about the new Blocko card. I have been in contact with the inventor and the company selling it. They are mailing me a card to evaluate. It's already in the mail and should arrive later this week. I will make a Youtube video about it.

[Toastie]

5 hours ago, evank said:

It's already in the mail and should arrive later this week.

@evank this is going to be >very< exciting!

On another thought: Do you have an RS232 (serial) card on your Apple? I guess so - this would mean you can operate the CLI from that machine using Apple BASIC; maybe you have already done so.

I am reserving some time between Christmas and New Years for a little coding using QBASIC for my IBM XT operating the CLI ...

Best wishes,
Thorsten 

[evank]

Yes it has a serial card. I use it for connecting to a PC and running the ADTPro (Apple Disk Transfer) client/server application. This is for moving disk images between the retro and modern computers.

[evank]

I'm in possession of a Blocko card! It works.

I'll have a video review within a week or two.

Edited November 18, 2024 by evank

[maehw]

Hi all,

a short update from my side!

I had contacted both authors Helmut Albrecht and Herbert Hödl. I've gotten a reply from Helmut who seemed very nice and helpful - however, no software files in the end. And Helmut also mentioned that he was in touch with you Thorsten and Evan.

Regarding the book and its floppy, I must confess that I had made some wrong assumptions: I was thinking that it contained the MS DOS/IBM PC version of LEGO Lines. But nope, of course not. You had to have LEGO's master flopy along with the license to make copies. So the book's floppy "only" contains programs I guess - still very valuable and I'd like to get access. I found out that the German national library in Frankfurt actually does have the book. It seems that due to legal reasons, they don't want you to copy the floppy contents - or at least you should not get caught when doing so. Well, maybe some day...

I haven't contacted TLG about LEGO Lines - as you've written that this likely is a dead end.

But: Some weeks ago, I found the precious LEGO Lines floppy for DOS on ebay by a German seller. As at the time I didn't have the equipment to read old 5.25" floppies, I got in touch with Daniel Schmatz (the guy from eitle kinderkram/YouTube mentioned above). Also: it comes with a pile of paper for use in schools (DACTA 950026), so I think Daniel is the best fit with his "museum" near Vienna. In the meantime I do have a 5.25" floppy drive and a Greaseweazle and cabling. I am missing a power supply and some more time, though. Daniel got the floppy and may read it some day using his old equipment - he might be willing to read and archive it by himself or lend it for archiving, we will see.

In the meantime, I got myself an Interface A including a ribbon cable, two motors and IIRC opto-sensors and lights should be on their way. I haven't unpacked everything yet even though I am every excited to try things out soon! And I still need an AC or DC power supply - though I probably have one that already fits.

Also: I have started to re-create LEGO Lines using Python and am willing to share it - probably another software I've written which the world has _not_ been looking for. It will be able to import Commodore and Apple ][ LEGO lines files and run them (I tried to understand the save file formats and fortunately, they are not that complex). The following screenshot shows my remake "BRICK Lines" on the left and the LEGO Lines software for Commodore (C64, C128, ...) on the right. Interestingly, the Commodore and the Apple ][ versions look completely different and also have different sets of functionalities! Still curious about the DOS version...

I might even add functionality to edit your own programs if I or anybody else is willing to use this. I am aiming to use this with a USB/serial converter - so this could run under Windows, Linux and Mac OS! I will base it on @Toastie's Arduino project. But this finally leads me to some questions concerning the serial interface:

* The project assumes that before the input ports are read, they are always written. Is this how TC Logo works? Has this been confirmed to be working with other LEGO Interface A software?

* How do the emulated serial ports work? Would it also be an option that the Arduino detects edges on the inputs and sends them? Or polls the pins every millisecond and just sends an update? Or would the serial buffer in the emulated DOS machine "overflow" because the software does not read them? Or would it just.. work?

* Would the old parallel ports be able to detect edges on the input pins or were they polled (e.g. every millisecond as this is the frequency which as been observed with PWM)?

* A general Interface A question: did I get this right that the PC must feed a 5V voltage back into interface A to power LEDs or something or am I mixing things up here?

 

 

Edited December 1, 2024 by maehw

[Toastie]

Hello @maehw,

On 12/1/2024 at 11:48 AM, maehw said:

But: Some weeks ago, I found the precious LEGO Lines floppy for DOS on ebay by a German seller.

WHAT A FIND!!! Wow.

Daniel has so many "things" - it is incredible - and in the right "hands". I love his channel, his attitude, the things he brings across ... just wonderful.

With regard to 5 1/4 floppies: My IBM XT has two of those - happy to be at service.

Yeah, TLG and copyrights (of software on a medium, 99.X% of all inhabitants of Earth never heard about ... they'll make a fortune off the copyrights, I am sure, they are so smart) - forget it.

On 12/1/2024 at 11:48 AM, maehw said:

or lend it for archiving, we will see.

As said ...

On 12/1/2024 at 11:48 AM, maehw said:

willing to share it - probably another software I've written which the world has _not_ been looking for.

Hey, welcome to the club. Just turn "the world" into ... 10 people. It always makes the difference for me. The world ... let them do their thing. I am all 10 people do care world. Or maybe 5. 5 really happy people on this planet make the difference, as they not only freak out for a second or minute, but their enthusiam and appreciation simply persists for a very(!) long time.

On 12/1/2024 at 11:48 AM, maehw said:

* The project assumes that before the input ports are read, they are always written. Is this how TC Logo works? Has this been confirmed to be working with other LEGO Interface A software?

Yes. Interface A is a (dumb) parallel port device responding to changes on its input lines. It is the LEGO #9771 parallel interface card taking care of things. The #9750 box is a 6 "lines" output "driver" and provides 2 input "lines". You have to read or listen to the 8 bit port (6 bit out latched/mirrored to the 8 bit data bus, and 2 bit as momentary status of the 2 sensors (on or off)). You can always asynchronosly read from and write to #9771 => #9750.

I am using QBasic and it does seamlessly work with interface A using that approach.

On 12/1/2024 at 11:48 AM, maehw said:

* How do the emulated serial ports work? Would it also be an option that the Arduino detects edges on the inputs and sends them? Or polls the pins every millisecond and just sends an update? Or would the serial buffer in the emulated DOS machine "overflow" because the software does not read them? Or would it just.. work?

#9750 does not send out any data. It provides a "status" (along with #9771). Nothing overflows, as you are the one asking the port for its status. This is completely different for #9751 (interface B) -  here you have to swallow with what the 19 byte data frames are telling you. #9750/#9771 are not responding; they change the 8 bit port signals, and you have to interrogate.

The "writing before reading" approach synchronizes the two programs (in my case, DOS/QBasic <-> Arduino), i.e., they are "bolted together": Writing to the Arduino calls for an immediate reply, which I then read in turn into my QBasic program. This way, any programming overhead is essentially eliminated. QBasic is a bit on the slow side. Should the Arduino crank out data with lets say 1ms resolution, then indeed input buffer overflow will happen, as the program does other things as well ;)  

On 12/1/2024 at 11:48 AM, maehw said:

* Would the old parallel ports be able to detect edges on the input pins or were they polled (e.g. every millisecond as this is the frequency which as been observed with PWM)?

Well, I am not sure, what you are asking for ... What is happening on a DOS machine running, e.g., TC Logo is: The DOS ISR routines are manipulated such that the timer tick is 1 ms and at that frequency (1kHz) all 6 outputs are continuously (turned on/off) via ISR routines, depending on the software power setting. Thus, outputs do PWM at 125 Hz.

On 12/1/2024 at 11:48 AM, maehw said:

* A general Interface A question: did I get this right that the PC must feed a 5V voltage back into interface A to power LEDs or something or am I mixing things up here?

Yes. What you need to do is supply +5V to pins 1 and/or 3 of the interface A port. This will then make a transistor inside happy to enable the opto couplers driving the 6 #9750 input data lines.

Please feel free to ask more - I am one of the 5 people on this planet interested ... 

All the best,
Thorsten

P.S.: My interface A DOS/QBasic control program "Q9771_3" is here: https://bricksafe.com/pages/Toastie/qbasic-programs

There is also a brief program description (PDF) as well as the .BAS and .EXE file. The QPWM_5.BAS program just illustrates, how the PWM is done within TCLogo.

Edited December 2, 2024 by Toastie

[evank]

I would be happy to put the Lego Lines for DOS disk image into the Archive.org Vintage Lego Robotics folder, if someone sends me a fresh copy of the disk.

[maehw]

Thanks for the motivating words, @Toastie!

19 hours ago, Toastie said:

With regard to 5 1/4 floppies: My IBM XT has two of those - happy to be at service.

Sounds good, let's give Daniel some more time until February until we start asking how the floppies are doing.

 

19 hours ago, Toastie said:

Hey, welcome to the club. Just turn "the world" into ... 10 people. It always makes the difference for me. The world ... let them do their thing. I am all 10 people do care world. Or maybe 5. 5 really happy people on this planet make the difference, as they not only freak out for a second or minute, but their enthusiam and appreciation simply persists for a very(!) long time.

That seems to be a good attitude.

I am happy to tell that today, I've been able to use my Interface A for the very first time. I've got a DC power supply which does the trick, I've also got an Arduino Nano which still works and some wires. Thanks to your Arduino software and my preparations in BRICK Lines, this was quite a quick starter. (I haven't tried the TC Logo version modified for the serial interface yet. Also no DOSBox-X experiments so far.. I am running BRICK Lines on native Windows, Linux and macOS.)

You can find the BRICK Lines software on GitHub: https://github.com/maehw/BrickLines - it's free and open... (MIT license). (It comes with a README.md!)

This is where I'd also like to add the Arduino code snippet which does the serial/parallel conversion. As the code is originally yours, I ask you kindly to license it under MIT as well, so that I can add it along with some pinout/hardware wiring info which I added.

I also think that the software still has a small bug where I can see issues when applying outputs for the first time. This might not be visible when outputs are set using TC Logo at a rate of 1 kHz but it is in (BRICK) Lines where outputs are only set when specific instructions are executed (all that are not equal to LEGO Lines keywords). I'll try to narrow this down and report with more details. There may also still be a bug in my code and/or wrong assumptions. It already seemed suspicious to me when I tried to talk with the Arduino with a serial terminal and it replied with different characters when I typed in the same character several times...

 

As you may have guessed, I only do have the Interface A (70455, i.e. the later 1987 version) without any cables or interface cards -- only the Arduino Nano as USB-to-parallel-adapter. Sorry, I think I did not make my point clear... or should have rephrased my question.

Your code does a `Serial.write()` for every `Serial.read()`. This implies that code running in the machine is always writing outputs before it can read the inputs - because serial is async. This brought up the following questions/assumptions:

1. Does TC Logo write the outputs before it does read the inputs? Always?
2. LEGO BRICK Lines can have instruction that only depend on the inputs (conditions such as `IF` or `UNTIL` or the `COUNT` statement). There's no need in setting the outputs before. Of course, to make this compatible with BRICK Lines, it could adapt the behaviour working with TC Logo and just re-transmit the last-known outputs it has set before to be able to receive the current input levels.
   (Note: Oops, that's actually what I should have added in the Python code here: https://github.com/maehw/BrickLines/blob/8ba5b78e233419ed867500548f6be82b21c972c7/brick_lines.py#L456 - it seems that I have tested outputs-only programs so far! Probably because I do not have received any sensors so far (neither touch nor opto)! Expected behaviour until I modify the code: the program should get stuck because it's waiting for a receive byte which never comes... and it's a blocking serial receive function.)
3. As this "need to write outputs in order to know the inputs" dependency may be problematic/unintended (see 2), I asked myself if it would also work when the Arduino Nano polled the inputs regularly (or implemented edge detection on the two pins) and sent the data periodically (at the polling rate; or event-based when an edge = level change has been detected). But: this could result in many many bytes being sent from the Arduino to the PC without being read from there... and could overflow a receive buffer until `receive()` is called. But this might not be a problem for "old serial" interfaces which just overwrote a single byte buffer and it was the application's responsibility to read the received input data just fast enough before it got overwritten by more recent data. Not clear if this description let's you get my point...

 

I'd be happy if some of you would like to try BRICK Lines. But it requires the Arduino Nano serial/parallel device as a hack... and so far I am only aware that Toastie has this and somebody else attempted to build another one for themself. So maybe this is a 2 people world only so far.

 

Edited December 2, 2024 by maehw

[evank]

Keeping the torch alive: the only correct way to use an Interface A is with a real Apple II, BBC Micro, Commodore 64, or IBM PC. :)

[alexGS]

9 hours ago, evank said:

Keeping the torch alive: the only correct way to use an Interface A is with a real Apple II, BBC Micro, Commodore 64, or IBM PC. :)

And then, the only correct way to program it (ie. not just testing but actually programming a model) is to use either LEGO Lines or TCLogo, not any of the hacks with BASIC etc. :)

 

Still, BRICK Lines does sound clever, sounds like it implements the programmability of LEGO Lines with the same conditional capabilities - I’ll try it out! If it is ‘code compatible’ with Lines but runs on modern hardware, that is surely a good thing

Edited December 3, 2024 by alexGS

[Toastie]

5 hours ago, evank said:

a real Apple II

But wait - wasn't your machine an Apple clone?  

2 hours ago, alexGS said:

the hacks with BASIC

Ha! In the instructions that came with 9771, the LEGO folks are listing a (PC) BASIC program for interface A control  

To be (correct) or not to be (correct), that is the question. I generally tend to lean towards a little incorrect behavior ... :D Never take me seriously ...

You all have fun!!!

(so nice to know, that all 5 people are still here, I love it ...)

All the best,
Thorsten   

[alexGS]

3 hours ago, Toastie said:

But wait - wasn't your machine an Apple clone?  
 

Good point! 😁

Evan has diligently collected all of the LEGO software and accompanying materials - in his Internet Archive collection - making them available for all to use, and yet - he seems not to use them himself, stating (on Facebook) that he works in AppleSoft BASIC. Evan knows my disappointment about that 😉 and how I am interested to hear why he would not use Lines or TCLogo. He is a University professor of computing, teaching hardware and software; highly analytical and I doubt I could ever change his mind. So I couldn’t resist the chance to point out here that the LEGO software is the ‘correct’ way, if we’re going to be pedantic about the hardware 😁

You are of course correct that BASIC routines were provided in the 9771 instructions (complete with the famous typo in the bitwise mask), but I still see that as a ‘hack’ because it doesn’t provide the framework for solving an actual problem - much is left to the reader, and four programmers would come up with four different solutions - there is no ‘right’ way.

The use of LEGO Lines creates a quick, consistent, and easily-understood solution. It actually highlights the actions on the display as the program runs.

TCLogo is necessarily more complex but still with a high degree of imposed structure, allowing for code re-use, and it is backed up by many examples in the LEGO materials. Logo went on to form the basis of Control Lab as well, where it was beautifully woven into objects such as buttons and text boxes.

Personally I always find it odd working with Logo variables (using Make, and then remembering the reference colon seems to elude me) but I’ve managed to explain the operation of my functions at this year’s NZ shows quite easily; people can see how a complex task is broken into small steps (functions), and how variables are passed from one function to another. I think I would have a harder time explaining an equivalent BASIC program.

Anyway - the important thing is to have fun, as you said! 😁

Edited December 3, 2024 by alexGS

[Toastie]

@maehw,

now that the purists have chimed in (right, @evank and @alexGS? You guys are the best ...) it is time to move backward, didn't TCLogo show up years after BASIC?

22 hours ago, maehw said:

As the code is originally yours, I ask you kindly to license it under MIT as well, so that I can add it along with some pinout/hardware wiring info which I added.

I have no clue what I need to do in that regard - why not just take it and then do with it what you want! Everything I post is per definition in the true public domain and can be used in every way people like to use it. When J. Pesos comes around and makes a billion dollars using my oh so brilliant ideas - so be it. Good for him, I cannot care less. In contrast, I'd be honored.

With that set aside, I shall try to reply to some of your questions:

22 hours ago, maehw said:

I can see issues when applying outputs for the first time. This might not be visible when outputs are set using TC Logo at a rate of 1 kHz but it is in (BRICK) Lines where outputs are only set when specific instructions are executed (all that are not equal to LEGO Lines keywords).

Hmmm - could that be because any output buffer is writing something to the Arduino on startup? In fact, I do not see any such behavior, as I am also sending control words only when I need to, sometimes rapidly (in 9600 baud world) sequentially, or just one in a couple of seconds or minutes. So far, the Arduino never behaved badly ...

The 1kHz rate of TCLogo has only two purposes, as far as I understood the code: 1) provide a versatile 1 ms timer by modifying the PIT registers and ISR vectors, and 2) enabling PWM of the outputs. There is no hardware PWM driver electronics inside interface A, every change to the outputs has to come from the inputs. Now, when you set the power for output A to 3 and then turn on output 3, the TCLogo program takes care of generating the PWM signature. It can do that for all 6 outputs; see reference below. And does all the other things, the Logo language can do ... I wrote a little BASIC program mimicking that behavior. It is way too slow, but does illustrate the approach. However, as I don't do any PWM, motors are either permanently turned on/off at any given time. With 1) TCLogo can nicely "count time" or provide frequency information; this is done within TCLogo during each timer interrupt by default (count 1 ms timer ticks). Here is more on that:

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=3618487

22 hours ago, maehw said:

It already seemed suspicious to me when I tried to talk with the Arduino with a serial terminal and it replied with different characters when I typed in the same character several times...

Again, this never happened to me - I used this approach for testing (and just did it again): The Arduino always stupidly replies what I am sending. However, you need to apply a "signal" (GND or VCC) to the two inputs of the Arduino when no interface A is connected, otherwise they may respond to fingertip contact or other noise and then add 128 and/or 64 to your reply byte. When interface A is attached, this is rather unlikely, of course

22 hours ago, maehw said:

Your code does a `Serial.write()` for every `Serial.read()`. This implies that code running in the machine is always writing outputs before it can read the inputs - because serial is async.

You said it: Serial is async and this way I can sort of "force" synchronization: BASIC writes 6 bit data to the output ports and this is replicated on the outputs of interface A. When these 6 bits are identical to the last 6 bits written, nothing changes on the outputs. Then I am reading all 8 bits back (which are naturally the 6 bit I just wrote as they are latched into 74LS373 of the 9771 card - or in case of the Arduino, into its output latches in addition to - and that is the idea, I get the two input bits (synchronously) back, as I am just waiting for the 1 byte Arduino reply. No reply = something is bad. Again: This never happened to me.

22 hours ago, maehw said:

Does TC Logo write the outputs before it does read the inputs? Always?

Yes, it does: First write 6 bit to the 9771 card, parallel or serial port address, depending on TCLogo version, @alexGS has provided us with, then more or less immediately read back (there are only a couple of machine code instructions in between) 8 bit of data. The result is stored and thus available for TCLogo to a) count incremental ms and b) update sensor status on the same timescale. To be honest, I boldly copied that approach, however in my case for synchronization rather than 1 ms resolution.

22 hours ago, maehw said:

Probably because I do not have received any sensors so far

You don't need that: Just use the Arduino I/O pins: They fully mimic interface A without interface A attached. The latter is just an "amplifier" for the output signals and has some nice circuitry for the inputs. You can safely short the inputs when interface A is attached to the Ardunio for testing; a 4.5V touch sensor is a solid switch - open and close. The 9V touch sensors have an internal resistor of about 500 Ohm when closed (and some had even different resistances for recognition); 4.5V sensors have anything close to 0 Ohm.

22 hours ago, maehw said:

But this might not be a problem for "old serial" interfaces which just overwrote a single byte buffer and it was the application's responsibility to read the received input data just fast enough before it got overwritten by more recent data. Not clear if this description let's you get my point...

I do. However, writing 8 bit is a matter of about 1 ms at 9600 baud. And you don't need any buffer monitoring; there is only one byte present at a time at the UART, the most recently sent 6 bit + 2 additional new sensor bits. Of course, you can do it the way you describe - this is what interface B does: It sends out 19 byte frames of data at about 50Hz and your program has to either swallow that or will come up with a buffer overflow. You are right: The good old 8250 UART in the IBM PC/XT only had a 1 byte "buffer" which was simply overwritten, but program languages such as QBasic had interrupt controlled transmit buffers, which are prone to overflowing plus you need some sort of buffer control. Back in the days, that cost time; in modern environments this should be no problem at all, so you can have the Arduino crank out data at any rate you wish. I am just using all these old machines for programming (Sinclair, Atari, C64, TI99, IBM XT) and need to free some time for them to do more than monitoring the inputs :D  

Hope that helps!

All the best,
Thorsten

Edited December 3, 2024 by Toastie