Toastie

Dear All, quick update: passive #9751 sensor ports have a bias voltage of 5.0V. This will be the same for powered sensors during the sampling time of the internal A/D converter, as the same touch sensor applied to a passive (yellow) port gives exactly the same reading when pressed, as attached to an active (blue) port In addition, as speculated, the voltage scale of #9751 sensor ports is linear. Used a lab power supply to take some readings: The little deviation around 0V is because my power supply did not like the 5V bias voltage from the sensor port; it showed 0.02 V on its display, but that seems to be off a bit. A 9V lamp attached to the port (acting as "almost" short) gives a reading of 4, so we know a reading of 0 is very close to 0 V. The data point size in the diagram reflects experimental uncertainties. Furthermore, at 0.02 V applied (which is not exactly that, see above, it is a little more), the external power supply sinks 0.48 mA. In this case, the voltage drop across the internal #9750 resistor(s) is 4.98 V (or a little less), assuming the internal resistance of my meter is 0 Ohm, which is also not true. But all that does not matter: Simply taking the numbers as they are yields: R(internal) = U/I = 4.98V/0.48E-3A=10375 Ohm, or 10k, as speculated. Conclusion: #9751 sensor ports behave as RCX sensor ports do. Not that much of a surprise Best, Thorsten

Hi Jo, well, I simply wrongly assumed 2 stop bits, as I said in the little bit sheet. So I have to multiply my (rounded) 135 value with 11/10 = 1.1; this yields 148.5 ... Yeah, I blew it again. This is how I do initialize the COM port in QBASIC: OPEN ComPort$ + ":9600,N,8,1,CD0,CS0,DS0,OP0,RS,TB2048,RB2048" FOR RANDOM AS #1 Guess what, the 1 stands for 1 stop bit ... So I stand correct and will make the changes did change the text and also the bit sheet. Thank you very much for pointing that out!!! All the best, Thorsten

Hi Evan, wonderful video!!! Not only the new product is shown but all the alternatives as well! OK, the original is THE original ... and my favorite is OF COURSE the home brew card. And what the heck is going on with all these blue Technic bricks in the back? (I just got clearance from the higher authority here, to make a BL Xmas order, used stuff, of course ...). I'll get to see all that on Christmas Eve ... Anyway, looking forward to what the secrets are about!!! All the best, Thorsten

Dear all, I just wrote a summary of findings related to the serial data emitted by interface B (#9751), when different sensors are attached to the sensor ports. This is solely meant to be a reference and not any kind of new reporting. There are some minor new results below I did not find anywhere else, but this work is based on all the entries in this thread, as well as on data available on the web. Sensor ports of #9751 Sensor ports 1 – 4 (yellow) are passive analog inputs Sensor ports 5 – 8 (blue) are powered analog inputs; power is supplied, when A/D sampling is not active within #9751. Voltage supplied during powered state: 9V with a 15 mA current source (should the sensor ports of #9751 behave as RCX ports do, see corresponding circuit diagrams for powered RCX inputs here: https://brickshelf.com/cgi-bin/gallery.cgi?i=1067044, author Mark Bellis) The sensor port voltage range is 0 – 5V. Sensor port impedance/resistance is 10 kOhm internally tied to +5V for all sensor ports (when not in power delivery phase), should the sensor ports of #9751 behave as RCX ports do (see corresponding A/D reading vs. applied input port resistance here https://brickshelf.com/cgi-bin/gallery.cgi?i=1088015, author Mark Bellis). Note that the response to resistance change is highly non-linear (logarithmic abscissa scale used in the diagram). When no sensor is attached, the A/D reading “1023” corresponds to 5V. Short-circuiting the sensor port leads to an A/D value of “0” corresponding to 0V. However, the latter is not achievable with 9V touch sensors, as these have an internal resistance > 0 Ohm. There are different versions of touch sensors, in addition, they do age. The resistance of some of my touch sensors is about 500 – 1000 Ohm when tightly pressed. This results in an A/D response between “100” and “200”, which is in full accord with Marc Bellis’ findings for the RCX ports. When an external voltage is supplied to a #9751 sensor port (e.g., by an active sensor or any other suitable voltage source) in the range 0 – 5 V, it needs to have an internal resistance low enough to compete with the +5V/10kOhm internal pull up voltage supply to generate reasonable changes in the A/D converted data. Important: When doing so, pay attention to polarity!!! GND of the external voltage needs to be connected to 0V/GND of the sensor port. When the external voltage supply has a very low resistance (e.g., a laboratory 10A power supply), then the voltage to A/D value response is almost linear. Characteristics of the (serial) sensor data continuously emitted by #9751 The emitted data from #9751 regarding sensor readings are composed of 2 bytes (high byte first, low byte next, denoted as bytes “3” and “4” in the diagram below, corresponding to a 16 bit long word. Generally, there appear to be 2 data “segments” within the 16 bit word: Segment 1: First 10 bits = A/D converted “raw” value of the voltage present at the sensor input port shortly before serial data emission. When no sensor is attached: 5V internal pull up = “1023” = 1111 1111 11 (referenced as bits 3.7-3.0 and 4.7+4.6). Anything attached to a port with either a resistance or a voltage/current power supply in the range 0 – < 5V results in a smaller value. These values are completely independent of sensor used: All touch sensors produce almost the same A/D value returned, regardless of yellow (passive) or blue (powered) sensor port used. Active sensors naturally work only on blue (powered) sensor ports, as they need power (9V/max 16 mA, see above) to provide a voltage/current source at their output. Segment 2: Remaining 6 bits (referenced as bits 4.5 – 4.0) are encoded by the microcontroller of #9751 depending on states and changes or transitions occurring within the several A/D values sampled by the microcontroller between two 19 byte data emission cycles. They also depend on the order these transitions occur. This means changes from/to defined voltage levels are processed. They are done for all 8 inputs. #9751 does not know what type of sensor is attached to which port (I don’t believe is senses anything like “active sensor” or even more specific: “rotation sensor” or “light sensor”). The serial data emitted by #9751 simply need to be interpreted by the program controlling the interface: After several internal sensor “scan(s)”, #9751 always sends out the 10 “raw” A/D bits and the 6 “further processed” bits for each of the 8 sensor ports, in the format 2 bytes + 2x8=16 sensor bytes + 1 checksum byte. Attaching a (passive) touch sensor to an active sensor port does thus lead to rather “confusing” readings regarding bits 4.5 - 4.0: #9751 internally processes the raw A/D values it scanned several times during the period until a next 19 byte data emission cycle occurs. (All following data regarding the rotation sensor are taken from Philo’s website: https://www.philohome.com/sensors/legorot.htm). As an example, when input voltages transition from about 1.3V -> 3.3V, this is evaluated by #9751 as one rotation click (1/16th of a full turn) in clockwise (cw) direction. Thus, bit 4.0 = 1 (one click), 4.1 = 0, and 4.2 = 1 (cw). A rotation sensor always provides these voltage levels. When further transitions (3.3V -> 2.0V, 2.0V -> 4.5V) are detected, they remain (unequivocally) cw and are thus added up to a max. value of 3 (bits 4.0 and 4.1 = 1). This results in a max. resolution of 3 ticks x 50 data emissions/s = 150 ticks/s for rotation sensor counts. Higher rounds per second lead to data loss, as experimentally verified. Furthermore, this suggests that bits 4.0 – 4.2 make only “sense” when a rotation sensor is attached. However, they will also change when a light or touch sensor is attached, but they don’t mean anything valuable as certain light levels (and thus voltage level) transitions will cause arbitrary 4.0 to 4.2 bit changes. That leaves us with the 3 “processed” bits 4.5 – 4.3 for other sensors, i.e., the temperature, touch and light sensors; I believe back in the days (1993 onwards) no other active 9V sensors were available. I did some “bit masking” experiments and so on, and arrived at these conclusions: Temperature sensor: This seems to be a PTC-type sensor; the higher the temperature, the lower the resistance and thus lower the raw data value As there are no fast resistance transitions when the temperature changes, bits 4.5 – 4.0 have no real meaningful values. They do change though upon temperature change. In this context, "fast" is a change between "valid" states during the internal scans, #9751 performs between two serial data emission cycles. Touch sensor: In addition to the raw data value there is another bit, that does yield information: Bit 4.3 is 1 when the sensor is “open” (port LED off, high resistance) and 0 when “closed” (port LED on, low resistance) – and remains as such. In other words: The user control program has only to check this one bit for deciding “touch sensor closed” or “open”. Downside: The internal threshold and hysteresis of #9751 is (yet) not known. But we’ll find out! Secondly: Maybe threshold and hysteresis can be programmed into #9751 – who knows what other commands as reported are available. This needs also close inspection of the #9751 manuals! The RCX allowed such (powerful) manipulations Light sensor: Well, touch sensor behavior must be observed with all other sensors as well. And it does: Bit 4.3 is 1, when the light sensor’s A/D value is regarded by #9751 as “dark” = high resistance; the LED at the sensor port is off. It turns to 0, and remains there, when the A/D value is regarded at “bright”; resistance is low, LED is on. This behavior can be mimicked with a touch sensor, see above. Bits 4.5 and 4.4 represent numbers of transitions from bright to dark and dark to bright since last 19 data byte emission, encoded as 2 bit word (see rotation sensor). There is no direction bit, as the light sensor cannot provide such information. This also works with a touch sensor; however, the internal sensor scan time of the microcontroller inside #9751 is really short; it will certaily detect one "push" and report that (bit 4.4 = 1), but in the next data emission cycle, (most probably) this bit is 0 again, as only transitions are detected. The same holds true for the release transition. With a really "noisy" switch, the on/off jitter should lead to some bit 4.5 and 4.4 changes (e.g. bin 11 = dec 3) when the switch was ringing 3 time in a way that the on/off threshold and off/on threshold was three times crossed and the microcontroller's A/D converter caught that. Fun fact (I just read the microcontrollers data sheet more closely): The Siemens SAB 80C515 chip used as brain inside #9751 (an 8-bit CMOS microcontroller with factory mask-programmable ROM), features an 8-bit A/D converter with 8 multiplexed inputs - but wait - reports 10 bit A/D converted values. Huh??? Well, the A/D converter has programmable internal reference voltages; as far as I understand the data sheet, if a higher resolution than 8 bit is wanted, the thing makes a dual scan, first coarse and then, with adjusted reference voltages, a more precise scan in a narrowed voltage range. OK, maybe it is like that, I am not sure . But wait there is more, there always is, we’ll see … tonight a shall break out my lab power supply (yes, it is a power supply I will be snatching from the lab ) and see whether my "linear 0 - 5V scale" claim is true or not. Will report back here. Here is the updated little bit diagram for #9751 data traffic: All the best, Thorsten

@Bliss You are not alone I am also testing. Managed to get a QBasic program up and running, "servicing" all inputs and outputs (i.e., not only manual control, but full program control, e.g. setting the power of n outputs in parallel to on/off and all the other things). As far as I am sampling input data (19 byte@9600 baud), the rotation sensor is responding (naturally) with the lowest rate; counts swiftly "lose it" when rotating too fast. On the other hand, the rotation sensor bits 4.0 - 4.2 give you the direction and incremental count (max. 3 per 19 byte data frame sent + internal conversion rate). However, individual light or simple A/D conversion bits can change at the full 19 byte@9600 baud transmission rate, with no further internal conversion in the way. These bit changes are thus much faster reported than the 1/16th rotation increments. This also reflects the behavior of interface A, which just provided the digital level (bit) at its sensor ports; no direction provided, just the light/no light state, and the program had to sample these changes. More research underway, using your bit resolved information! Best wishes, Thorsten

Stream of pictures here (Firefox)

@Bliss Thank you very much for all these findings!!! I am particularly happy that the light sensor signal is A/D converted in the same way as the non-powered sensors. With these new findings, interface B's behavior is more and more like that of the RCX - which is, as far as I am concerned, the "follow-up" control device. On the RCX the threshold values (on, off, hysteresis) for sensors can be user defined/calibrated, which is extremely helpful. Very nice research results! All the best, Thorsten

Welcome to 7 wide train world The 6-wide scale is cool, the 7 wide (and yes, there is more, there always is) scale, is looking so much better (as far as >I< am concerned) would surely benefit. You don't, I do, but what the heck: So it is. We can build odd with even plates and pieces ... and we have the 1x1 and 1x3, even 2x3 plates. Best, Thorsten

@allanp Wow. I feel ... silence ... after reading your post - or better - your wonderful, powerful speech! I wish you were invited to a Billund dinner type event, with scheduled brief talks (not presentations) on "How does TLG do with Technic". You had to submit an abstract for your talk - it was a little vague - yes there would be some criticism, the reviewers said, but in the end, TLG would stand out, as they are the ones, who invented it. And then your speech takes off - in the end, you are jumping on a table close to the big guys: "Sorry, I am - NOT convinced". I am absolutely >not< joking or mocking. I truly believe that this kind of input would at least cause - silence and induce thinking. Whatever the outcome would be. I am not sure that they get this outstanding type of enthusiasm anymore. Thank you very much for sharing your thoughts - I enjoyed every word you wrote! Best regards, Thorsten

Does very well fit in (this is some heavy data bombarding, but scroll down to the customer's ages ;) summary the boomers (that's me!) - OK and then the coming folks - rock https://www.coolest-gadgets.com/lego-statistics/ And yes, this is just ONE website - but the data they show are partly from statista.com; and that site sucks (sometimes), as they (naturally) want you to pay for the interesting stuff ;) Oops, wait: Aluminum hat off . Best, Thorsten

And Alex S. pushed me so much during my "awakening" with regard to TC - and then Evan simply pushed me through ... these are all extremely nice and helpful guys. And there are more (there always are) of course ... As I said @maehw, "this particular" world is small, but one that I never want to leave ... Best wishes to you all Thorsten

Hmmm. We are opening Pandora's box, don't we? A couple of more discussion topics: Why do most many companies do their mass production in China? How large is the brain pool "they" can tap in? Or phrased differently: How many people are (still - China is of course "evolving", if not "there") willing to come up with brilliant technical solutions - for a toy? How "hungry" are people to thrive towards certain goals for a - let's call it still limited - salary? What else are these companies doing compared to what TLG does with regard to other activities? I have >no< clue. But when it comes to China, they literally kick butt everywhere. Not meant in a "positive" nor "negative" sense, just as an as cool as possible analysis (for me) of observations. They push every high-tech company on the other side of their world to their limits. Why not doing so in plastic brick fabrication? I am still thinking about your argument ... thank you for bringing it up! All the best, Thorsten

You nailed it And with them, because they make me happy and you guys as well! Have a nice evening! Best, Thorsten

Well, first, in a discussion like this, any viewpoint, assessment, perspective, argument, etc., is by definition a true personal thing. I as virtually all others here, don't know anything about what TLG does and why. Nothing. If my phrasing sounds like I am a TLG representative, then I am sorry, and I need to change that. I am one individual with personal opinions. What I like to do is throwing in such opinions, and I am generally waiting for flak from all sides. Call it criticism - or whatever the result of a discussion is. No one is explaining anything, it is a discussion. And a discussion literally lives through exchanging arguments. Should these sound offensive, OK, then I should begin each paragraph with "In my personal opinion", "after I thought about this", "may be", "... or not". I don't see that often here on EB, though, and secondly, for me this is the default. Hey, and if a TLG representative would bring some of my arguments, I'd simply faint. Summing up: Please accept my apologies for sounding like a smart a*s - I shall try better! All the best and here is to feeling good Thorsten

Money? It is costly to have smart designers think about smart things for a tiny fraction of TLG's total buyers crowd. And then the box art designers, the storage facilities or on demand pipe-lines, etc. etc. Just assume TLG has these consumer data: These four set do sell well. In parallel. In that case, I believe there will be more such cars on sale in parallel, as long as they sell. If one or more eventually underperform, out with them. That is the question - on a larger (global) scale, I doubt that. Otherwise, they would simply do it. Also, "plenty" is may be not enough, maybe they want the maximum possible. Maybe it is OK nowadays that it shows you "sort of" how it works - or even just pretends to show you how it works? When people buy such stuff at large - so be it ... I know this sounds all frustrating, but it should not: These (many!) people are happy. And (presumably very) few are not. What would you do in such a situation: Listen to the few? Crank out extra money to make the few happy? Yes, some would do, but not for long - one tough competitor and gone is the charity ... Best, Thorsten

But that is the thing: "True" Technic = "technic a couple of true technic nerds like" has migrated into "Display Technic" because TLG's decade long analyses have shown: Print "Technic" on the box, get rid of functional but "ugly" studs, use "premium" stuff licenses all over the place, make it big, adjust the mental effort of building it, and boom, the niche theme Technic sells. To the extent that more and more sets designed along these lines sell even better. Which simply mirrors (not causes) the changing Technic audience. If TLG had to compensate for their increasing operational costs (competition means more effort) by selling nerdy, functional machines - they'd pay a lot extra, as the numbers of "true LEGO technicians" has become so small, that on a logarithmic scale of 1 to 1E10 this number hardly shows up Arguing from a pure marketing perspective: Why pay extra for a smaller and smaller audience = market, when a much larger audience happily buys Technic display models? And as it seems, so far, regardless of price tag (not true: this is of course - and every serious company does that - carefully monitored as well: Test ballooning here and there, waiting for the market data, adjust accordingly. TLG has more than 6 decades of data at hand). Best regards, Thorsten

May I change the last three of your words to "some - actually rather few compared to TLG's audience - brilliant MOCers do". That is not only totally OK, I wish I could do that as well! Yeah, sometimes people with sufficient funds available for a hobby tend to overlook that aspect. Again, I wish I were in the same position, but so be it. I don't know about "changing populations" ... or "for looks", or "for functions" ... As others have posted: I do perceive the "Technic change" as 100% revenue/profit driven. Particularly in a world that - for TLG - has changed much more than any population has: Over the past decades of their 60+ years of selling their plastic product (yes, there are so many more system pieces, but they originate from the exact same idea and are made more or less in the same way), tough competition has build-up. Such a situation usually calls for changing gears. I believe TLG is simply targeting - or phrasing more politely - has identified, through decades of market analyses with ever-increasing powerful algorithms, a group of people, that are willing to spend >a lot< of money for just that: display models. The bigger, the better - for the same reason: maximizing profit. The larger the sets become the less suitable is System, which of course has in addition the 1960's touch to it, and throwing in just another gearbox is hardly possible. So even in this ("Technic") niche TLG can make some money, as apparently rich people, loving the expensive brands, who may not own a real Ferrari but now have a Ferrarili - with real technic inside! - on the wall, maybe tightly sealed in an equally expensive transparent case to save the Ferrarili from collecting dust. Once again: that is totally OK with me. I am happy when people are happy. But why not renaming "Technic" to "Model Team"? Well, "model" and "mold" are not that far away - "technic" sells better. I don't see any "degradation" in Technic - I just see how the plastic toy market evolves under changing conditions. And that is why I 100% revert to Technic with studs. The pieces are ubiquitously available for comparably "good" money, have the 1960 moldy touch to it (I am old). No new TLG sets >$10 for me anymore. I am still very happy though! All the best and have a nice day (or night ;) Thorsten

Hi Jo, been there; Anders' Delphi code (version 3, but version 1 is doing the same regarding sensor reading) as well as the information he lists on that page from 1994 (Newsgroups:rec.toys.lego, Andy Carol). However, on Tom's LGauge page (https://www.lgauge.com/technic/LEGOInterfaceB/9751.htm) there is a table that lists for the light sensor a different protocol (12 rightmost bits of a 2-byte sensor word = light data). But just looking at the non-used bits in the protocol I put into semi-graphical format above, I thought this could very well be. But I don't get it to work that way ... But thank you for your help! All the best, Thorsten P.S.: I am in touch with Tom; he said he will take a look into his C# code again, when he finds time - this is all so long ago. It could also be that there are different versions of interface B out there.

And after the mechanical treatment as described above (I am also a guy), I do a little "Kontakt 60" spray treatment to both, pin and socket, using a Q-tip swab (not directly spraying the contacts, just into the cap of the spray can and then soaking the cotton tip). Never use WD40! (https://www.reichelt.de/kontaktspray-kontakt-60-100-ml-oxid-und-sulfidloesend-kontakt-2010-p9462.html) Best, Thorsten

Dear LEGO interface B enthusiasts As said in a post above, I am playing with the interface B hooked up to DOS/QBasic or QuickBasic either on my laptop within DOSBox-X or on true DOS machines (Toshiba Satellite 4090 or IBM XT). So far all is good - on all machines the QBasic code runs flawlessly. However, I am a bit confused regarding the serial protocol, i.e., the information stored in the 19 byte data frames, #9751 cranks out at about 50 Hz. Or more precise: There seems to be contradictory information on the web ... Question is the following correct/complete? Does anybody have further information? I have a hard time believing that the white (=unused) bits are exactly that: Not used bits in the protocol. Byte #1 could be some sort of start byte with 6 zero bits leading but hey ... also, in byte 4 (6, 8, ...) bits 5-3 are not used OR there is more. For example, there is some information out there that the light sensor is sampled with 12 bit resolution (rightmost 12 bits) but that gives confusing results on my side. In addition, how should the hardware of interface B know which sensor is attached? Sure, I can tell my software which one it is, but the interface hardware does not, or does it? I can put a touch sensor on a blue powered or a yellow non-powered input: Same result. A light sensor needs power, so does not work on yellow inputs but on blue of course. Am I missing something, or is this "it"? As said, I am happy with that, but just want to make sure I don't drop data. Secondly: The A/D converted 4 voltage levels of the rotation sensor (depending on its internal rotor blade positions, see here: https://philohome.com/sensors/legorot.htm) are converted to the three lower bits of the second byte (of each powered = blue input); bit 2=direction of rotation, bits 1 and 0=number of rotation ticks since last frame was sent. 16 ticks=one full 360° turn. The other bits naturally don't mean much, as they represent the last analog value reafd from the rotation sensor. With two bits, the max. "changed ticks number" is 3. When we assume that the 19 byte frame repetition rate is 50 Hz = 50 s-1 (I read that somewhere ...) then the max. full 360° rounds per second of a rotation sensor that can be resolved are: 3*50/16 = 9 s-1 in other words about 10 Hz. Which is not that much, I must say; interface A does much better! OK, but does not know the direction of rotation. Is this what others observe as well? Thanks a lot in advance! Best regards, Thorsten

Easy: We make it - let's say 1 pm German time - that is 1 am in NZ and 7 am in New Jersey (I believe) - where is the problem? Best, Thorsten

100% agreed. It is just that I love BASIC so much. It is the only programming language, I managed to "understand" to the degree of feeling comfortable when using it. Logo simply made me nervous (seeing all these kids on the LEGO books and flyers, happily programming and me not getting it); C or C++ is always a wild ride for me ... pressing "compile" is generally: Close eyes, wait, prepare to open them again and hoping for a "successfully compiled" message ... So in essence, I just chickened out and do what I did for decades ... All the best, Thorsten

@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? 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: 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 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 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. 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. 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. 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

But wait - wasn't your machine an Apple clone? 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

Almost like 9V PF style CubicMotors from Tenka Best, Thorsten