Toastie

It really is sad and even much worse. However, I really like your attitude and what you make out of this situation: It is proof of your fantastic work! Best regards, Thorsten

I cannot agree more. However, it is where the money is ... it appears as if people want shiny replicas, rather than tinkering with the brick. Best wishes, Thorsten

https://en.wikipedia.org/wiki/How_to_Irritate_People#/media/File:How_to_Irritate_People_DVD_cover.jpg Simply don't take it seriously .

Well the moment you believe to be the one and only supplier of all these marvels and gems (or you even are) than in market world, keeping supplies low bolsters revenue. You just have to have enough folks on board, calculating it all through. Fewer supplies = lower margin, but compensated by new highly demanded supplies as the target audience freaks out on never seen before ... uhm, colors. From: The Beauty of Capitalism, chapter 1, section 3: The Axioms. OK, made that up. Best, Thorsten

Just my 2 cents: The first link is more suitable than the second, I believe, as you can choose the LED type (color = semiconductor material mix). An LED is not an ohmic resistor, as many have already pointed out, so in essence Ohm's law is not applicable :D I bet you have been here, just in case: https://en.wikipedia.org/wiki/Electrical_resistance_and_conductance. You "make" Ohm's Law applicable to your problem by defining boundary "conditions" not known to Ohm's Law, e.g., the forward voltage drop across the LED, which depends on its color (= material used) and manufacturer's tolerances when brewing the material. Thus, you first need to select the LED type/make, and look at the forward voltage drop as per data sheet. You don't have to do that when using ohmic material alone; two ohmic resistors in series simply add up, and then you can use Ohm's Law directly (yes I know, we know all that, just summarizing). Furthermore, you also need to define your desired current going through the diode(s). As the current is identical in the entire circuit, if you select 1 mA in the above referenced calculator(s), 1 mA goes through all LEDs. And then the resistor value is calculated based on Ohm's Law - the calculator simply "assumes" that if there is a given voltage drop at a given current over the LED, then its ohmic resistance is assumed to be R=U/I. Having a resistor in series with any of the (n) LEDs is always good - it does not really matter whether it is 1 or 5 Ohms (your example). Temperature affects the characteristics of any diode, including LEDs. With no series resistor in the circuit and with a powerful power supply (alkaline batteries can provide several amps for shorter times), things may very swiftly turn ugly, when the LEDs are slipping away from their nominal characteristics. More current = temp goes further up etc. Or: The beauty of exponential functions. With a resistor in series, the voltage drop across the resistor increases with current as well (Ohm's Law ;) and thus "regulates" the current in the circuit - to a certain extent. In order to make this regulation more effective, I'd always go with at least a 100 Ohm series resistor and the lowest tolerable (as in enough light) current in your setup. I'd rather leave out an LED in series and increase the resistor value at constant supply voltage than the other way around, just have LEDs in the circuit. May work, but may also become ballistic. As LED lifetime is also affected by the current flowing through it, again, I'd go with the lowest tolerable current. When I run 3/5 mm LEDs for test purposes in any of my projects, I'll take a 1kOhm series resistor (for 1 LED). They still "light" up. For powerful light generation, this of course won't work. Good luck with your project!!! All the best, Thorsten

I was asking for the availability (of parts in a color) - not for the improvement with regard to number of colors. But: All is good, I am happy with what I have in basic colors. So everybody is served well, as it appears. Best, Thorsten

But that is the thing: Not the limited colors, as this defines "failure" upfront. Nothing is easy with limitations. I lived through that period as well (and some earlier periods also) and was never looking for limited colors. I never had that idea, but regarding basic colors, put the green aside, it worked pretty well. With all the colors available now: Did this availability really improve? Regarding sets that is, not BL or whatever. I do well remember going into a not-LEGO-store and pickup packs of something - in basic colors, of course. So this is where I got my "idea"; it came from experience. I am not saying that TLG should do that with the gazillion colors they are now producing, not at all. Regards, Thorsten

6 hours passed ... I was hoping someone from the UK will reply - maybe later. I am located in Germany. And of course I'd build the truck for you. UK and Germany are a bit "disjunct", as Brexit did what it was intended to do. When you see a route to get the pieces and instruction to Germany, I am happy to send the assembled at tested models back. Just let me know. All the best, Thorsten

True. But shit happens, even with hyper space equipment and triplicate checking. I do "live" in such an environment: The impossible happening. So they flagged him. Now humans should kick-in, equipped with a brain that believes the impossible may nevertheless happen. I am still really surprised that they did not come to another conclusion than: Fraud. Well, maybe they do deeply believe in their machines. Regards, Thorsten

So I heard my group was just awarded with a major EU program fund - this needs some attention from my side :D It is within a consortium of some chip manufacturers, research institutions and universities, all playing around with EUV light and such things ... So just FYI - here is the 5 line c++ code (plus a lot of text, so I still may understand what I did. Tend to forget such things after a couple of days ...) Few remarks: The LED illumination is entirely optional, as 9750 has its own LEDs. It was just for me during programming as quick visual feedback. I am a BASIC person. For me, C++ is like coming from outer space and I have to look up nearly everything - and over and over again ... In other words, this reduces the "code" to 4 lines w/o the remarks and definitions :D I am using direct port manipulation only (which is NOT recommended by the Arduino folks, as this is of course board/microcontroller specific. But I find it cool. Also, all bits are changed >simultaneously< as the register content is thrown onto the outputs in essentially one instruction step. I like that. 6 x digitalWrite is not cool :D. It is more an homage to the 9771 card and 9771/9750 communication The traditional way of I/O pin handling is thus commented out and just for me to remember. All that is needed is either an Arduino Nano or Uno (watch the pinout, microcontrollers have identical port descriptors), I have tested both; a serial2TTL converter just running in parallel to the TX/RX lines of the Arduino. For programming, only the RX line of the converter needs to be temporarily disconnected, as otherwise the Arduino can't listen to the USB port. This is why I installed a little switch, see page 1 of this thread. I bet there is a much more elegant way to manipulate the ports in c++ using &|<>!^ ... But: It works. // //Serial Interface for TCLogo to 9750 parallel input/output //Uses port manipulation: https://playground.arduino.cc/Learning/PortManipulation/ // //Port commands: DDRX : port direction of port X; 0=in, 1=out // PORTX : write to port X // PINX : read port X (also to read back output status //Works on Arduino Uno R3 and //Arduino Nano using the "Processor: ATmega328P/old bootloader" option in menu Tools /* Traditional pin definition setup #define bit0_output 2 // 9750 output 0 #define bit1_output 3 // 1 #define bit2_output 4 // 2 #define bit3_output 5 // 3 #define bit4_output 6 // 4 #define bit5_output 7 // 5 #define bit6_input 8 // 9750 input 6 #define bit7_input 9 // 7 */ void setup() { // Init IO pins ---------------------------------------------------------------------------------------------- /* Traditional I/O setup pinMode (bit0_output, OUTPUT); pinMode (bit1_output, OUTPUT); pinMode (bit2_output, OUTPUT); pinMode (bit3_output, OUTPUT); pinMode (bit4_output, OUTPUT); pinMode (bit5_output, OUTPUT); pinMode (bit6_input, INPUT); pinMode (bit7_input, INPUT); */ pinMode (8, INPUT_PULLUP); // Pullup needs to be defined >before< port direction settings pinMode (9, INPUT_PULLUP); // This mimics the behavior of the 9750 sensor ports: Open = true //Port configuration for Arduino; see above Arduino reference link // pins 76543210 // port D 765432XX // TCLogo 543210 // 9750 543210 DDRD = DDRD | B11111100; // Port D direction setting 1 = output; 0 input. // This is safe: It sets pins 2 to 7 as outputs // without changing the mode of pins 0 & 1 (RX/TX) // pins XXX21098 // Port B: Ports 5-7; pins 13-15 not usable on Nano // port B XX543210 // DDRB |= B00001100; // Ports B2/B3 = outputs, all other unchanged (B5-7 not usable). DDRB &= B11111100; // Ports B0/B1 = inputs, all other unchanged. // Init serial ports ----------------------------------------------------------------------------------------- Serial.begin(19200); // Init hardware serial port (pins 0+1) // Notes: 9600 baud is the native QBasic maximum as well as the // maximum on the IBM XT. // 19200 baud work when reprogamming the UART using DEBUG within // DOSBox-X (although not fully) and on the Toshiba 4090. // 38400 baud work (only) on the 4090 as well // using DOSBox-x while (!Serial) {} // Wait for serial port to connect } // end setup ------------------------------------------------------------------------------------------------- void loop() { //------------------------------------------------------------------------------------------------ uint8_t newPINB; // For temporal storage of port B status. newPINB = PINB & B00000011; // Read port B, lower 2 bits (=> sensors 6+7 on 9750). // Need to use a variable for temporal storage of port B status: // PORTB |= ((PINB & B00000011) << 2) does not work. //PORTB |= (newPINB << 2); // CRAP, DOES ONLY WORK ONCE!!! The LEDs simply stay ON. PORTB = newPINB <<2 // Much better: LEDs on port B 3+4 showing the sensor status (optional). if (Serial.available()){ // Something arrived at the serial port = TCLogo_s write // -> no error checking! PORTD = Serial.read() << 2; // Arduino output port LEDs (0-5 on 9750 = PORTD 3-8). Optional. Serial.write(((PIND & B11111100) >> 2) | (newPINB << 6)); // Reply to TCLogo_s: // Read the output status, shift right by 2 = bits 0-5. // Add bits 6+7 by shifting the port B input bits left by 6 } }//void loop --------------------------------------------------------------------------------------------------- Best wishes, Thorsten AND EDITED AGAIN - oh my. Don't code in C++ if you are a BASIC person ... the line: PORTB |= (newPINB) << 2); works exactly once when an input on 9750 goes low - after that no changes occur on the IN LEDs anymore; they simply stay on. The code needs to be PORTB = newPINB << 2. I am very sorry - change that above as well.

Can further support this speculation: My Satellite 4090 laptop (I believe @alexGS is also using, correct Alex?), a 16550 equivalent UART is doing the serial communication. That one handles baud rates > 9600 and has serial I/O buffers: https://www.minuszerodegrees.net/manuals/Toshiba/Satellite/Toshiba Satellite 4090XCDT - Product Specifications.pdf On this computer, TCLogo_s works absolutely fine within margin of error using 19200 baud for the serial communication with the Arduino. There is some very minor jitter, I can't even quantify on my scope. But there is no hiccup at all. I may have a look at my 5 lines of Arduino c++ code, but that seems to be fine. Just as a test: 38400 baud work as well - this gives more time to do other things on the Arduino, if desired :D (when not wanting to use interrupts, that is). There is of course no real reason to run the serial TCLogo version Alex made on this particular machine, as the 4090 has a parallel port as well, and thus TCLogo_p runs perfectly well. However, it is always good to know what causes which jitter or hiccup ;) on home brew stuff made by an amateur. Conclusion: The slightly off timing at 9600 baud in DOSBox-X is due to the 8250 UART simulation. The hiccup (= 1 ms wrong output after 24 ms) is due to the 9600 baud. The weird behavior at 19200 baud in DOSBox-X (timing becomes simulated processor dependent) is a simulation artifact, mostly caused by the 8250 simulation, I believe. Best regards, Thorsten

"Another" big boy model ... Yeah, sure. Another as in: "Look, this thing can fly to the Moon, return safely to Earth, as they did it before. The only subtle difference is: It is made of plastic bricks" Dave - this isn't another big boy model - it is a new definition of a brick built big boy model. Man. Incredible. With very best regards, Thorsten

With your skills in building locos using bricks and plates and so on, there will be a time, when Maerklin and others simply will go bankrupt Absolutely stunning. All these details ... and technology used. With best regards, Thorsten

Sorry for bringing this up again. I surely have a (n updated) copy of your wonderful Technic History book. It is a repository I never want to miss. As far as I am concerned, 9750 (and dependencies) runs under the LEGO Technic as well as LEGO Dacta program. All the best, Thorsten

I fully agree to your assessment. Current low power LEDs shine nicely on 1kOhm resistors at 5V DC. The PF voltage is 9V (PWM modulated). Just try it out. Begin with 1kOhm and see what you get - at full PWM = DC ("power 7") or dimmed down (power 1, 2 ...). And then decide. Best, Thorsten

Thank you for your nice words - but this all builds on your changes to the TCLogo code and your many other insights into PC/LEGO hardware! I am doing more measurements - time is a little issue at the moment, though. Well, timing as well ;) I shall take more screenshots of my scope, here's the text version: At 9600 baud, the DOSBox-X DOS simulation runs rock solid. One 1 msec interrupt of TCLogo_s is exactly 1.04 ms long on the Arduino parallel outputs. As it should be, even on a serial hardware port: TCLogo drops the current PWM motor data byte into the 1-byte serial output "buffer" and continues on with other TCLogo stuff. This goes blistering fast. The serial adapter then recognizes that byte (oops, data coming in :D) and slowly cranks it out according to its settings, 1 start, 8 data, 1 stop bit = 10 bit. At 9600 bit/s this results in 104 usec/bit and 1.04 ms per 10 bit packet. And then the next packet can be transferred. As the 8250 UARTs in IBM PCs have no serial input/output buffers (https://en.wikipedia.org/wiki/16550_UART#The_16550_FIFO), the next byte to be transferred has to wait ;) This time lag will add-up and at latest (no overhead) after 0.04 x 24 = 1 msec there will be a hiccup. Interestingly, exactly this behavior is replicated in DOSBox-X. A hiccup occurs every 24 ms, as per measurement. Which makes me believe, DOSBox-X simulates a 8520 UART for the serial port. You can choose a Pentium processor - but I believe the serial port behavior remains identical. At 19200 baud, which is not recommended at all for 8250 UARTs - in fact my IBM XT says NO to everything above 9600 baud - things become a little "weird" in DOSBox-X. The hiccups are gone, as they should (!), but now the simulation timing becomes critical. That was not the case at 9600 baud; everything up to the 486/66MHz CPU does not alter the timing. Going faster makes the pulses >longer< - with still no hiccups. With 19200 baud I have to select a pretty fast processor - not too fast and not too slow - I believe because the simulation of the serial port and the CPU are not well-matched anymore. And I need to watch the oscilloscope to choose wisely :D. There is also some (minor) jitter, as I believe the simulation goes nuts - assuming a 8250 UART with no buffer running at 19200 baud - and having a Pentium throwing in data at a rate of 1 msec. Maybe we should not overdo it and test the waters with real LEGO models. How bad is the hiccup affecting the performance of the robot? How accurate does it need to be? If it is not 1 msec time slice anymore, does it matter? This could be a very cool school/university project. Citing the above referenced Wikipedia article: "Replacement of the factory-installed 8250 UART was a common upgrade for owners of IBM PC, XT, and compatible computers when high-speed modems became available. Above 9600 baud, owners discovered that the serial ports of the computers were not able to handle a continuous flow of data without losing characters. Exchange of the 8250 (having only a one-byte received data buffer) with a 16550, and occasionally patching or setting system software to be aware of the FIFO feature of the new chip, improved the reliability and stability of high-speed connections." With regard to the baud rate hard-coding into TCLogo: My assembler hardcore time was in the mid-late 1980s for the Z80 processor in my ZXSpectrum. 8086/88 was not in my universe, nor do I know anything about memory allocation in DOS. In the Speccy, all things began at address 0x0000 :D = the ROM, we hooked extensively as it saves a lot of assembler code ;). I believe in DOS, this is different? Question is: Does the TCLogo code (or any DOS code) have absolute addressing? Not the interrupts/hardware access, just within the program. I doubt it, but what do I know. In that case though, things will get messy, as any additional code inserted would possibly screw up absolute addressing. So I suggest (for now) going with the debug patch in a BAT file. And we should maybe do more research into other DOS simulators handling the serial port differently. Maybe simulating a 16550 or other chips natively handling 19200 baud, as this is all we need to break the 1.04 msec sound barrier. What do you think? All the best, Thorsten PS.: Just found this: https://www.tek-tips.com/viewthread.cfm?qid=73071. It is exactly what we are talking about here - however this is for slow QBasic - per byte (and not 1 msec byte hammering). Works with QBasic within DOSBox-X (per byte) - and look at the end of this thread ... it is all out there. I like the "you don't need assembler" bit very much; OUT address, value in QBasic is exactly the same as O address value in DEBUG ...

Same here! Thank you for your comment and interest! All the best, Thorsten

Absolutely! Thanks for noticing - changed it accordingly! Best wishes, Thorsten

Update #2 - and success For some reason, DOSBox-X always starts-up with 9600 Baud, regardless of config settings - at least this is what I am experiencing. Need to get on GitHub and ask the developers about it - and most probably they will tell me, I should not use DOSBox-X, when I don't know what I am doing And then I remembered DEBUG.COM/EXE ... It allows you to do many things, assembling, de-assembling, and so on. And: You can simply do I/O requests to all addresses that come to mind. A quick look into the IBM Async Adapter Manual: Running DEBUG and then typing the output command "O 3FB" (1111111011) addresses the line control register. The data to be sent for changing the baud rate are shown in this table: We want access to the divisor latch, which is essentially providing the baud rate from the base frequency (1.8432 MHz crystal on the async card), so the data to be sent with 3FB are 10000011 (0x83): Access DLAB, 8 data bits. The first DEBUG command is thus: O 3FB 83. Now the divisor needs to be sent: The lower significant byte (LSB) is sent to address 3F8, the most significant byte to address 3F9. The divisor we want (baud rate = 19200) is calculated as per IBM manual: Divisor = 1.8432E6/16/19200 = 6; LSB = 6, MSB = 0 The second command to be sent is thus: O 3F8 6 and the third O 3F9 0. Then the line control register is set to "normal" RX/TX operation: O 3FB 3 And this works: Run DOSBox-X, run DEBUG, type in the 4 lines (or use input redirection from a file, e.g. DEBUG < 19200BD.TXT), then run TCLogo_s. As 19200 baud is not at all supported on the original IBM XT, the processor used for the simulation needs to be at least a Pentium. Going to even more powerful processors does not help, as they screw up the correct simulated interrupt timing (1 ms). Conclusion: No more glitches as observed at 9600 baud (see above). Last thing(s) to do: Clean up Arduino code and that's it :D - 9750 operated running TCLogo_s off from a USB port of any modern computer. And compose a reasonable summary here, with all the things required. BTW: Did I mention, that I love 8/16 bit computers? If not: I do. All the best, Thorsten

FINALLY! These are my words since I began playing with LEGOs sss s - and they began making all sorts of pieces with "new" colors. As said before: I am color-blind - which doesn't mean I can't see red - I do see red very well. All reddish things are red or - not. Depends on the -ish bit. Could very well be that it is some sort of weird reddish-green. My absolute favorite is the brownish stuff. I have a small drawer with pieces that look brown to me. My daughter asked me recently, why I am mixing up all these colors in the drawer . But: That is my very personal problem and the reason I gave up on the mixed brick boxes LEGO sells as the ultimate part packs and inspirational and creativity turbo boosters: Too many dilutions into all sorts of colors. So I go BB. Parts packs with pieces of one type and one color for a fraction of the price TLG is charging. And a name tag on it: Blue. Dark gray. Oh, they also do have the -ish and pearl- and sand things - but not for me :D The other thing that I am interested in: I do watch a few YouTube channels ;) It appears as if TLG has a color quality control issue. Not that I can say anything about it - but how do all these myriads of colors, plus the additional tints they apparently get - depending on the land of confusion - still maintain their original name? The "sandish-dark-sort-of-white" names they have? Well, I believe normal people can still tell them apart from "sandish-allmost-dark-sort-of-white" even when manufacturer A's color is a bit on the "dark" instead of the "darkish" variety, and manufacturer B does it the other way around. Or this is all just hearsay. And over-amplified. Here is to all people of all colors: Best regards Thorsten

@alexGS, @evank, I am reporting a major update on the usage of TCLogo and LEGO Interface A (9750) without having an ISA card or a semi-vintage computer equipped with (real) parallel port available. It (almost) all (output as before but also input) works with a USB2Serial adapter on any modern computer - e.g. my Dell Precision 7530 running Win11/64bit and DOSBox-X. So why is this a major update? Well, it may very well be that I am again behind (as so often in this thread) but I simply did not find any reference out there ... please let me know if this is (again) incorrect Most importantly, all credit goes to @alexGS(!), as he has created, by literally working on the machine code level (see above), to make 2 new versions of TCLogo (see links in his post above). In these two new versions, Alex redirected the I/O access of the original LEGO TCLogo program, which directly addresses the LEGO 9771 ISA card at 0x39D (or 0x39E, address jumper removed): TCLogo_p: Redirection to I/O addresses of the PC (default) parallel adapter: ports 0x378 for motor/light output and 0x379 for sensor input. This allows you to run TCLogo without the 9771 card; instead, a true hardware parallel port is required. TCLogo_s: Redirection to I/O address of the PC (default) async (= serial) adapter: port 0x3F8 for output and input. In this case, either a true hardware RS232 port OR, and this is the thing, a USB2Serial adapter enables full bidirectional access to 9750. And thus modern computers are back in the game. Hardware requirements: TCLogo_p: A custom parallel port (DB25) to LEGO interface 9750 (20 pin) cable, see Alex's instructions above. TCLogo_s: Either a true RS232 serial port - OR - (1) a USB2Serial adapter, as the software required (DOSBox-X, see below) wants to detect a COM port upon startup; (2) a serial 1:1 cable; (3) a Serial2TTL adapter; (4) any suitable microcontroller board - I am using an Arduino Nano clone - for bidirectional serial-to-parallel data conversion, as LEGO Interface 9750 handles 8-bit parallel data only. Software requirements: Any "true" DOS computer (DOS, Win 98 and the like) will run TCLogo, TCLogo_p, TCLogo_s. Modern computers lacking "true" serial or parallel hardware ports need to run a DOS emulator. DOSBox-X is easily installed and runs TCLogo flawlessly. It just needs the virtual com port (e.g. COM1) to real com port mapping (the COM port the USB2Serial adapter is occupying) declared either in the DOSBox-X config file or typed in as a direct command within DOSBox-X. Some very low level observations when running TCLogo either on my IBM XT (1985) w/ 9771 ISA card attached to Interface A or a Toshiba 4090 (1998) with parallel cable attached to Interface A; the latter runs TCLogo orders of magnitude faster than the XT : I did break out my vintage Tektronics oscilloscope and did measurements on the pins going into Interface A, when changing the TCLogo "setpower" level from 1 to 6 (0 = off, 7 = on); here shown for Interface A's "output 0": These data imply that the minimum time for TCLogo to issue a write command is 1 msec. A "full output duty cycle frame" (green box) is 8 msec long. The corresponding motor on/off PWM times and the resulting duty cycle is shown in the table. By coincidence, the timer resolution in TCLogo is 1 msec. TCLogo counts sensor level changes, even if not asked to do so, with 1 msec resolution. Data available to the user at all times. The last time between two sensor changes is available with the "frequency" command, in msec. This strongly suggests that within TCLogo, there is a 1 msec timer interrupt routine, which: updates output 0-5 settings (PWM, even when all outputs are on power level 0/7, as TCLogo does not know, when a user or a program will change the power level) reads the inputs with the same temporal resolution, as the user can call "listento" along with "sensor?" at input line 6/7 anytime. Without timer interrupt handling of the I/O ports (and counter etc. housekeeping), both PWM intervals as well as accurate sensor change detection would be depending on time other TCLogo code needs to perform - which is not the case: When setting the power level of any (or all or some) of the outputs of 9750 to PWM (1 - 6), every ms the outputs are updated - even if there is no change in power data. I thus modified my Arduino serial to parallel program for my (very slow) QBasic application: Each time, TCLogo_s sends out a byte, the Arduino sets the outputs accordingly AND immediately replies with a full 8-bit serial data package (status of 9750 outputs and inputs). And did a little sniffing on the serial port: The very moment, TCLogo(_p) is starting up (just showing the welcome screen, nothing else), it cranks out 1msec updates on the serial port. The Arduino listens and does nothing else than sending back the current output/input status. TCLogo happily reads these data and upon issuing a "listento 6" followed by "show sensor?" in direct mode, TCLogo shows the correct status of input 6. Also, "setpower" works - almost - flawlessly. The thing is, that a 10 bit serial message (1 start, 8 data, no parity, 1 stop bit) takes at least 1.04 ms to transmit at 9600 baud. However, TCLogo cranks the data out and asks for replies at exactly 1 msec repetition time. So every 16 (have to check further) bytes arriving, there is a little glitch (1 msec) and then all is well again for the next 16 bytes. I simply cannot figure out how to use >9600 baud rates using this combination. It is not DOSBox-X: The config file accepts much higher baud rates. Also, when running QBasic within DOSBox-X, I can change the baud rates up-to 38400 with a little hack to the serial port settings (divider register of the virtual UART). Nor is the Arduino; that one easily manages Mbit rates. The thing is: The moment, TCLogo starts up, only 9600 baud works. This is strange and needs further investigation. BUT: For now, the "every 16 byte glitch" is more than tolerable. As TCLogo does not ask for or provides data faster than 1 msec/byte, a modern computer can thus operate the LEGO Interface A (9750) via a USB port! The syncing that I was discussing above as "very tough to accomplish" using async communication - is just >garbage<, as syncing is automaticlly provided by the exact 1 kHz (1 msec) rate of data "clocking" the Arduino synchronously with TCLogo timing. Conclusion: If the baud rate can be increased to 19200 or higher, TCLogo will work without any problems on modern computers. All the best, Thorsten

That is a wonderful idea - making tunnels modular - but more so are these really nicely assembled tunnel scenes! I mean, a tunnel is a hole in rock or ground. What really makes them so nice on displays is: Train disappears. All of a sudden, all the attention is: where did it go? It was through that hole ... and then the eyes are trying to "follow" the train's pathway - and realize: What a wonderful scenery! So many things to discover! Look here - and then here - everything so exciting. And with your absolutely gorgeous modular tunnels - I'd lost interest in where the train reappears. It'll resurface, for sure. So let us further what is >on< the tunnels ... Really, really great, what you have achieved! I love it. Thank you very much for sharing! All the best, Thorsten

Right! I'd be fine, when the poor folks make "only" 1 Million or less per capita and year (no clue how many Kristiansens count towards the family, surely not 1898), but that is another story ... Although I am not that much into pizza, I very much like the approach regarding the question about stickers vs prints. I prefer prints. Best wishes, Thorsten

Well, as said, I did not - this is superb, breathtaking work, YouTube user atkelar has done!!! However, the goals are different, I believe. What he is doing is using 9750 as "simple" (it is simple :D) motor driver. The Arduino Mega does it all. And that's fantastic, but not the goal here, I believe. The whole communication/control is elevated to the Mega. Interrupts for the sensors etc. Totally cool! But the goal "here" ;) is mimicking a vintage computer running original/hacked TCLogo on a (semi) modern machine. And that is rather "different": atkelar transferres 9750 control completely to the Mega. With a >superb< program and approach. You (and now I :D) want to use it essentially to act as a serial2parallel I/O gateway (with no brain), and have TCLogo in control. Is this correct? All the best, Thorsten

Hello Alex, yes! As far as I am aware. And this is on one hand totally easy: Just hack in such a request, and then listen to the port. However, in machine code, these additional instructions may cause terrible things. Absolute jumps will go berserk and so on :D. Nevertheless: Here is a brief summary of all results reported in this thread so far: TCLogo: That requires 9771 (or clone) to listen to address 925 (926) = 0x39D (0x39E) and then act on these I/O ports = full write/read access to 9750. TCLogo_p: This is @alexGS' modified DOS com file 1: Original TCLogo I/O is redirected to a true parallel port responding on 0x378 (out) / 0x379 (in). This is taken care of by TCLogo_p and should run on any "medium-vintage" PC or laptop having a parallel port - and that is the real beauty of it: You can take such a laptop to a "show" or equivalent happening and bring 1986/7/8 4.5V computer controlled LEGO into action, as Alex has nicely demonstrated. TCLogo_s: This is Alex' modified DOS com file 2: Original TCLogo O (so far no I) is redirected to a true OR virtual COM port. So far, I got it to work with TCLogo running within DOSBox_x, USB2Serial adapter declared in the DOSBox_x startup file, connected with a 1:1 serial cable to an Arduino nano equipped with a Serial2TTL adapter, simply listening to what comes in on the serial port: 0x00 = 9750 output 0, 0x01 = output 1 ... and mapping that to 6 outputs/2 inputs using register programming. So far, it did not work on my Toshiba 4090, nor on the IBM XT, BUT I am pretty sure that these 2 beauties want handshake lines to be properly connected; I am just wiring RX, TX, GND. Today that is totally OK (XON/XOFF, and a gazillion of mega Hertz) but back then it was not. Need to make appropriate cables and will report back :D. All the very best and here is to Alex: Thorsten P.S.: Yes, LEGO bricks from 1986 clutch nicely with LEGO bricks from 2023. But LEGO software from 1986 does that as well!!!