Toastie

@Bliss Got it out (oh my, lots of "damage" here on my layout, but it IS worth it) - my original Arduino Nano as posted on page 2 in the 9750 thread ... It works. At 9600 Baud, as expected there is this hickup, as you can't send 1 ms interval data fast enough. But the flickering is absolutely minimal. I then tried 115200 Baud on the Arduino. Compiled (of course) without any problems. Next: Tried to change the DOSBox-X conf file in the serial section to 115200 serial1 = directserial realport:COM20 startbps:115200 Fail, the Arduino does not respond. Back to 9600 Baud on the Arduino, but not on DOSBox-X: Works So I cannot change the Baud rate for COM1 (serial 1) in DOSBox-X - it is always 9600. Best Thorsten

That is exactly what I did - no change. Strange. Well the kHz sending/listening is bolted into the machine code of TC Logo: As I found out, when disassembling the running TC Logo.com file, here is that part of the ISR that is called every ms: 1481:0A26 mov dx,03F8 ;load serial port address into dx 1481:0A29 mov al,15 ;load 15h = bin 0001 0101 into al 1481:0A2B out dx,al ;write bin 0001 0101 to serial port 1481:0A2C in al,dx ;read serial port into al 1481:0A2D and al,3F ;al = al AND 3F (bin 0011 1111) 1481:0A2F cmp al,15 ;compare al to 15h = 0001 0101 1481:0A31 je 0A82 ($+4f) ;je=jump if zero flag is set; as the ;Arduino on the USB2Serial port replies ;with 0001 0101, the compare result is 1 ;= no jump I wrote the comments, DOSBox-X did the logging and disassembly of the running code. This is TCLogo_S running. The PIT registers and corresponding interrupt vectors are set accordingly before any of that happens. I also used an oscilloscope for catching these pulses on the outputs of my cable bound Arduino: These pulses are present on each Arduino output, all the time. I shall get my old Ardunio sketch out and repeat these runs ... Best Thorsten

@Bliss The one (among many others ;) thing, I simply don't get is this: I connect to the ESP board, it is on COM 17 on my laptop. I open HTerm (similar to the terminal program you use, I am just familiar with it), select COM17 and press connect. It always does that, regardless of the baud rate, be it 256000 or 4800. It always works. Even 7 bit data work for sending out "bytes". You have already explained that, but I am still lost. If it always works, then what is the Baud rate in DOSBox-X upon start-up? I tried to set it in the config file to 115200 as the UART emulated in DOSBox-X can handle that. But it does not change anything when running TCLogo_S: >Everything< works, but the power setting: tto 0, setpower 3, on: It flickers unsteadily. A 4.5V lamp attached does that as well. 1kHz rep rate should be no problem to send to the ESP, shouldn't it? At 115200 Baud? I know I sound stupid, but can't do any better. I simply don't get the flickering. Everything just works: LEGO Bockly, QBasic (w/o PWM of course), LEGO LINES (does not have PWM), TCLogo (when not using PWM = power level 7), HTerm ... In addition: TCLogo cranks out the 6 bit output signature regardless whether there were changes to the output power levels or not. Even if all outputs are fully on or off, it sends out the data at 1kHz. They are the same, but it does crank the bytes out. Where do they go and why don't these cause any flickering? I am confused ... Best Thorsten

Relax Brian, all my fault. I take back the "commercial" product term - had to press the "Buy Now" button on the tc-logo.com website and find out that I was redirected to a Tindy store. And Tindy is a marketplace for independent maker tech products (and not commercial products). I am sorry for that and will delete that comment in the above post! Well - I simply love open source and open development. And thus I was yesterday indeed a bit frustrated when that website popped up. Everything discussed in this thread as well in the LEGO Blockly thread is entirely in the open world. Just to make sure that everyone can contribute, test, criticize, come up with alternative ideas, throw in comments and so on. But that is just my personal view, and that's all there is. We are referencing as many times and to the best of our knowledge, so that that knowledge base can grow and get better and better. Again, this is just my personal view. I like the box Diego is selling, and I am glad that people can buy something that works out of the box! I'll stick to the ESP32 open source solution, as this leaves much room for further developments. My apologies to all how feel offended! I should have slept over it! Regards Thorsten

@Bliss heehee - that was exactly what I was thinking the first time I figured out that it needs to be "upside down": dull. But then I thought why not putting something interesting "on" there ... My initial idea was the IR LED for PF along with a LINX TXM433, as all my PF operated trains have the corresponding receiver (RXM433) on board. The LED array is a brilliant idea, particularly when the LED board has no header soldered. Because then you can just push the board all the way down onto the ESP's header pins, solder those and then solder the 2x10 connector. And they show nicely! You are right: You can still prototype/code without an Interface A attached. I shall try that out, as I just received three ESP32 Devkit1 boards. There must be now about 10 around here ... one controls my LEGO Crocodile (PUp), another one my Pantasy suspended Steam Punk train (and the station), another one my BR89 along with a turntable, another one m MulPI interface and on and on. Hopefully I can find such a board in my favored stores, we'll see. EDIT: Not in one of my preferred stores, but these are so nice, I ordered them from China for $2 each. Thank you! Best regards Thorsten

I believe it depends - when I was writing some elaborate replied or longer posts, and wanted to insert a link etc. I frequently press "back", instead of opening a new tab and work from there. Going back again to EB (screaming DAMIT), scrolling down and clicking "Reply to this ..." brings up, what I typed in before and asks me whether I want to continue or start over. Press the "X" and continue ... but there are occasions, when that did not work. My fault I believe, I just need to focus, I guess. Best Thorsten

Oh man - I screwed up again, you are right of course! The red/white cables need to be there, but not the pin 2/4 connection to internal +9V/GND of Int.A. These are optional. I made this thing and cannot write it up correctly. Thank you very much for catching that (again)! Best Thorsten

EDITED: We have a new solution for operating Interface A, developed with the help of the depths of the internet and very smart people. This is for sure a major step forward for all Interface A enthusiasts who don't want to tinker and mess with all the stuff required if you want to do something similar on your own. If you do want to mess around, here is a DIY solution, entirely developed in the public domain by @Bliss; I just happen to be the guy having a couple of Interface As and tested (as good as I could) with whatever he came up with. I simply love this approach: Telling what is going on, make it public, and thus invite interested people to try (intermediate or even final) solutions out. In addition, there is almost instantaneous developer response - well offset by global time delays, when living on different continents. I am a researcher and truly believe in shared knowledge. DELETED A little history: The development of Yves' ESP32 based solution is documented in his thread. It is much more about LEGO Blockly; a "simple" but powerful(!) graphical, non-blocking software running in a browser - or off-line. Initially it was connecting to serial devices, such as Interface B, but swiftly proceeded: Support for RCX, and many legacy LEGO devices were added. USB2Serial/TTL is simply "now". But then came Interface A, and that needed an interface to connect to USB, as it is 100% parallel. There are many ways to convert serial to parallel - and they were all investigated. With certain boundary conditions: Can emulators run legacy software to the extent that an interface can do the required serial to parallel conversion? On modern machines, parallel is dead. It then went from Arduino (Uno, Nano, Pro Mini) based interfaces, trying FT 245/233 adapters to finally use ESP32 VROOM boards. Arduinos don't have Bluetooth on board, but can easily connect to a BT board, i.e., COM based communication. Thus, the DOSBox-X emulator got attention. ESP32's have BT onboard, so cable connections were rendered less interesting. Corresponding microcontroller programs were developed, and finally, a line was drawn: Arduinos for USB cable based connections to Interface A, and ESP32s for BT wireless connections. In addition, the ESP32 interface was supposed to connect to both: Legacy LEGO software AND LEGO Blockly. Without doing anything other than pressing "connect" in Blockly or declaring the matching COM port in DOSBox-X. Which in turn requires legacy LEGO programs such as TCLogo or LINES to be patched: Exchange the 9771 board ISA address with one of the serial board addresses. As there are less than 5 such programs, patching them and providing them to the public seems to be a reasonable route. So here we go: The DYI solution Purchase an ESP32 VROOM Devkit 1 board and a female 2x10 pin header looking like this; total cost about $/€6: These are the I/O ports used: LEGO Blockly allows additional PF support if you see fit = GPIO 4. Here is the workflow ; the ESP board is flipped around - because then you can attach it directly to the Interface A connector. The gray lines in 2 and 3 mean, that you need to make a little recess (Dremel ...) because the Int.A port wants to make sure, you don't plug it in the other way around: The combination of the female connector and the board headers is really sturdy, when all 8/10 pins are soldered. Note, that you need to solder the red/white cables: This is required to enable the Int.As internal opto couplers. The pin 2/4 connection is mandatory just in case you want to be entirely “autonomous” (no cables other than the power supply cable to Int.A, my favorite approach!). However, this only works, when you open up Interface A and solder the internally stabilized +9V (and GND) lines to pins 2 and 4 of the connector, as shown here: But you don't have to: Just power the ESP board with a USB power supply on its USB C connector (Step 6 below, blue arrow). Once that is done, just plug in the ESP board to your Interface A (step 5): And that's it. As there are still a good number of GPIOs available on the left side of the board (view: component side, in 5/6 right side), who knows what will come up! Have fun and all the best Thorsten

Would have been REALLY nice to hear about all that before - but - it is what it is. You guys have fun! Best Thorsten

Yeah - and had something similar developed here even before the cat was out of the bag! And much more - the Arduino approach for those, who like cables and - well - Arduinos ... Unos, Nanos, Pro minis. And the ESP32 approach as well. So you forked DOSBox-X and made a custom version, correct? The approach here to leave DOSBox-X as is and patch legacy LEGO software. Turns out it is really straight forward, as even I can do that now, owing to @alexGS and @Bliss. I am thrilled to see all that activity regarding legacy LEGO software and hardware! It continues to be pure fun! Best wishes Thorsten

Well - whatever. I like what you/we have accomplished >much< better! Fully transparently developed, no intent to make any money, well documented. If you want to make your own - $5 + shipping. I am absolutely happy!!! Composing the DIY instructions. If you know how to operate a soldering iron: Wait for it. Furthermore: With the ESP32 approach, and being able to use both, legacy LEGO software AND LEGO Blockly, well, there is no reason for me to go the other route. But it's absolutely OK! Best regards Thorsten P.S.: @Bliss I believe you can remove/add what you want in your own posts ... too bad though that the link was removed. Was it this one ? https://tc-logo.com/ And this is the interface: https://www.tindie.com/products/control-lab-io/tc-logo-connect/. $18 + shipping. He is also on EB and makes this "Interface C": Well, why not. It's good to have alternatives. All the best Thorsten

Well. It would be a new, from scratch approach I believe. Control Lab expects the serial data flow for 8 encoded sensors, Interface B is cranking out all the time. You'd have to program the Arduino to mimic that flow for 6 dummy sensors (all zeros) and then encode the two remaining sensors as touch sensors. Secondly you need to encode the Control Lab output data arriving at the Arduino to 6-bit parallel out in addition to PWM. Will be tough but appears to be doable. Best Thorsten

You are right: Here is to Alex!

@Bliss Exactly 1, and this is why powering them from pins 2, 4 of Int.A is optional. If you don't want to open your Int.A you don't have to, you can use any USB power source via the USB port of the ESP32 board. Exactly 2, it was @alexGS who made the patched versions. If I recall correctly, he made the parallel version of TCLogo for his laptop (and general use in legacy computers still having a parallel port of course) as he could not fit a 9771 card into that machine. And secondly, because 9771 cards are ... rare. Since it worked so nicely, Alex also made the serial version, as I wanted to operate Int.A with my Dell laptop, which has just USB ports, and I had made the little Arduino serial to parallel adapter. At that time, we also discovered how TCLogo is addressing the ISA bus to control Int.A (address dec 925/6). Since parallel and serial cards on the ISA bus work similarly to parallel and serial cards using different I/O addresses, Alex patched TCLogo after looking for dec 925/6 (hex 39D, 39E) with the corresponding ISA parallel and serial I/O addresses. Best Thorsten

@evank, @amine, @alexGS, Gentlemen, @Bliss has patched the French version of LEGO LINES he found in the Archives () to work in serial mode. He made a version that runs happily within DOSBox-X, which then communicates through Bluetooth to an ESP32 microcontroller directly plugged into Interface A!!! Here is how to patch LINES (we should maybe put patched version onto the Archives as well? Or is your TCLogo_S version, Alex, located somewhere else? I lost track what is where): This is how it looks like, when you have the ESP32 board attached to Interface A (<link to full post in Yves thread): The board costs about €/$6, all that is needed is soldering a 2x10 socket to the row of GPIO pins. The red/white wires are optional; inside Int.A, I have wired +9V and (IntA)GND to pins 2 and 4 of the 20 pin port. I do that on all my 9750's as I like to power (wireless) "stuff" from there. This means that we can now run any patched DOS version of legacy programs within DOSBox-X and have them communicate (really fast) with Interface A. This includes QBasic, Pascal, C ... programs. But even better: Without changing >anything< hardware-wise, we can use LEGO Blockly. All this fun is running wirelessly over BT, which is appearing simply as "just another COM port" in device manager, to be declared in DOSBox-X, and you are ready to go. Same in LEGO Blockly upon connecting to (any) Interface A, just click on the corresponding COM port. Yves did a phantastic job upon achieving all this! The best part is: You can have many Interface A attached to LEGO Blockly - or 4 in DOSBox-X using the 4 standard ISA addresses. DOSBox-X can handle even more, but that is a bit more tricky, I believe. Maybe not. Here is to Yves Best Thorsten P.S.: If you want me to, I can try to sketch briefly how to get this going.

@Bliss WOW again!!! Now we can run the DOS versions of LINES in DOSBox-X!!! LINES and TCLogo are the core programs of the 4.5V TC Control era, beginning about 1986 - and used in schools in so many countries. And now the ESP32 board may become even more famous! No, it is not the board, it is your software of course!!! Congratulations Equally cool is "Hexed.it" - I am always struggling when a want to simply change individual bytes in exe or com files. Debug is not that straight forward to use. Thank you again for that link! (You certainly know that "Hexe in German is "witch" in English - "hexed.it" sound like a German-English term translating to "I bewitched it" - I am sure, the authors did that intentionally ). Just went to the website - and I am blasted away again. So easy to use - another dream comes true ... All the best Thorsten

I am with @Sven J and @Murdoch17 on this one. Why? Because I am already mentally swamped with the good old ones. And I love the pirate emojis because I enjoy (and pursue) my personal and romantic myth interpretation of piratry When the old ones are still available, add whatever comes to mind. But then a search function would be good. Best regards Thorsten

@Bliss I did another test with the ESP/Int.A combo. It appears as if almost the entire PWM duty cycle range (0 to 255, 1kHz) is nicely covered when using 4.5V actors (motor, incandescent light bulb): A no load 4.5V motor begins to rotate at PWM level 40 (~15% duty cycle) and maxes out at level 220 (~85% duty cycle) An incandescent light bulb in the yellow brick spans the entire PWM range. Optically it is more responsive at low level intensity changes, but this how our eyes work. As a result, the 255 PWM step range is spot on! This reflects a bit TCLogo's PWM handling (as they have defined PWM signatures for the power levels 1 - 7, which are non-linear): The lowest power level 1 has more on time than the corresponding percentage (1/8 = 12.5%) , they begin with 25% see here: I thus believe that they did that, because a no-load motor is not present in a Technic model/machine in analogy to the Carnot machine . On the other hand, they clearly preferred good motor performance when using PWM. This also means that in TC Logo lights are intended to be used more or less as on/off signals. I experience the same thing, when using TCLogo to light up 8 4.5 lamps at different power levels. Was not as linear as it could be ... Conclusion: With LEGO Blockly we can nicely adjust the "active" PWM level range for 4.5V motors and 4.5V lamps. Motors start at about PWM 50 ... 60 (w/ some load), lamps almost cover the entire range. Which motivates me programming an optical vue-meter, as @alexGS already suggested in the 9750/9771 thread, when I tried the power levels in TCLogo ... Best Thorsten

No, it can't. But as Ashi wrote: Interface B is perfectly suited to operate switch pints and lights, as well as reading any 9V compatible sensors. This is where Int.B outperforms any other LEGO "interface", as far as I am concerned. The voltage drop along long stretches of track is considerable; this is why I have a spider web of good gauge wires connecting to 9V track all over my layout. My trains are running with power pick-up from the track (held at 15 V DC using an old laptop power supply ), feed that via bridge rectifiers to rechargeable batteries, which in turn power either PoweredUp hubs or PF receivers. This way I can mix all plastic and 9V track, uses wyes and reversing loop without problems; I just use 1 piece of plastic track for insulation to prevent shorting. All PF receivers are RF (433 MHz) operated using stone-old low power RFM transmitters and receivers. 16 years ago, I ran my first three remotely controlled trains using RCX'. The RF components were powered from an active RCX input. Well I still have them ... my 12V and 4.5V trains are also equipped with this "tech" As far as I am concerned LEGO Blockly is really perfectly matching with the switching and detection tasks of a train layout, even if it is large. It is visual, following logical paths. And it is multitasking as well! It does not get any better. In this application case, timing is also not that critical, I'd say. And with Blockly, everything is scalable. And lastly, I believe a wired serial connection hardly ever "drops", don't you think? Just my two cents. OK, I have to admit, I love LEGO Blockly. Best Thorsten

I believe that SBrick (as well as PU and others) connect through BLE and not BT, correct? Best Thorsten

@Bliss I hate to cite myself and mangle with code from other people without asking for permission - but I could not resist: PWM works with the 3.3V ESP32 GPIOs connected to Int.A, when the frequency is changed to 1kHz. I just edited your ESP32 code in the Arduino IDE // ========================================================= // PWM (ESP32 LEDC) for Blockly outputs // ========================================================= const int LEDC_CHANNELS[6] = {0,1,2,3,4,5}; const int LEDC_FREQ = 1000; // 1 kHz const int LEDC_RES = 8; // 0-255 and PWM works like a charm on Interface A! I believe it is the electronics inside the interface, which is behaving erratically at 20kHz? Or the 3.3V are not enough for 20 kHz? Anyway, the 4.5V motors and lamps don't need 20 kHz at all. But I don't know. All I know it works at 1kHz Even the motor make happy sounds when PWM is at low duty cycle. Here is the ESP board attached directly to my modified Interface A, which has +9V on pin 2 of the 20 pin connector and GND on pin 4: Just one cable required: Power for the Interface A: (It's the thing on the right side - very good photography ...) Here is are better views; ESP board attached (the red and white wires provide 3.3V and GND for the opto couplers), component side, and solder side: That's it for the moment ... Best Thorsten I guess you were some minutes faster ... I'd call this huge success!!! The remaining question is: What is the PWM frequency in the Arduino version? Because that works with PWM! If that is running at 20 kHz as well - well than the 3.3V don't allow 20 kHz. If it is lower (and I believe so, as I can hear the motor humming at low PWM. I am 64 years old, have developed a nice high frequency backgroud sound in my ears (music was always too loud back in the days ^^), so that everything above 8 kHz is gone . Thanks a lot and all the best Thorsten

@Bliss GPIO reassignment is perfect; Now I can use a classic 20 ribbon cable to connect to Int.A by sticking it directly onto the ESP pins and wire +3.3/GND from the other side making swift Arduino/ESP changes possible. Thanks a lot! Best Thorsten

Hmm - I did two experiments: Hooked up Int.A to the Arduino (V2 version, via BT/HC05), and then let a Blockly program ramp PWM from 0 to 250 in steps of 10. Response as expected: LEDs on my Arduino light slowly up, as do the LEDs on Int.A. A motor 4.5V attached to one output made the corresponding "PWM sound" (maybe in the low kHz range?) at low duty cycle, began to spin at about "70" and then ramped up to full speed. A 4.5V incandescent lamp begins to light up at "10" (very low intensity, but clearly discernible), and becomes fully bright at "250". Hooked up Int.A to the ESP32 board. Now it becomes interesting: At PWM "10", "20" max. all three, the Int.A LED, the motor, and the 4.5V light are fully on with no change all the way up to "250". This may be due to two reasons (or more ...) 3.3V is not enough to drive Int.A with PWM, for some reason I doubt that. The PWM frequency of the ESP is too high??? The electronics inside Int.A is optimized for 1kHz changes at its inputs ... also, I can't hear any motor sound at low PWM settings. When you did your experiments with the LEDs attached to the ESP: Did they respond accordingly to PWM changes? If so, then it is Int.A causing trouble - either 3.3V or something else (PWM settings? They can be changed to lower frequencies, can't they? If so to the max. kHz range?) Best Thorsten Hi Ashi, you found the right place!!! @Bliss will certainly reply in much more detail, just briefly: I know Interface B since long. In my opinion, of all LEGO electronics devices ever produced, Interface B is best suited for train layout control. As it has a serial port, it works with legacy as well as modern computers/programs. The latter via USB2Serial adapters. And with USB you can hook up many Interface B in parallel to your computer. You don't have to use BT at all. Note: It is BT, not BLE, which is much more so prone to dropped connections, as far as I have read. With regard to your questions: 1 - yes, 2 - yes. 3 - it depends on the nature of the distance sensor. What type is it? Interface B expects the legacy 9V Mindstorms sensors on its inputs, that would be passive = resistors/switches, or active (rotation, light, custom ...). If the distance sensor is, e.g., a REED switch it would work right way. But I doubt that it is such a sensor. The programming language for Interface B can be anything that connects to a virtual COM port. I prefer @Bliss LEGO Blockly, which operates such ports either on- or offline. I am using the offline version. You can also use the original Control Lab software, QBasic, C, Pascal - thanks to the serial port. As said, Bliss will reply in much more detail. Best wishes Thorsten

I completely agree! To be honest: There is only one "available" program that does PWM using a 1ms interrupt routine, as far as I know: TCLogo for DOS. There is another software, "TC Controller" for DOS, but that has gone into oblivion. I actually contacted TLG, was in touch with the very teachers who used it, got all the way through the LEGO Archives, and after two weeks, they came back with "sorry, IP prohibits any further disclosure". IP? Regarding a program, which was used 35+ years ago? Whatever, TLG was never of >any< help, when it comes to their vintage software. Never. This is why threads like this one and others do exist on EB. I shall try out incandescent 4.5V LEGO lamps and motors using TCLogo_S PWM. But as far as I man concerned, we should not pay too much attention to native LEGO software PWM: Any timing when using TCLogo is highly accurate, the sensor count rates are accurate, and so turning motors on/off at power level 7 upon reaching defined endpoints is good enough!!! It even works perfectly well in QBasic/DOSBox-X for classic LEGO Technic models. So it works even better with your ESP approach. The maximum update rate of the sensors is more or less Interface A input (sensor) hardware related, not by software. The sensor input circuit is simply bandwidth limited, I have shown that in my Interface A/Atari 1040 ST thread here on EB. The Atari can read faster, than the Interface A can deliver. If I had to decide, I would just address the miniESP32 vs. ESP32 DevkitV1 board question. And my take is: Use the Devkit1 board, stick it into Interface A and use LEGO Blockly. And if you like, use full power on/off outputs and control your 4.5V model using the light/touch sensors. What do you think, Yves? Best Thorsten

Thank you very much for rearranging the GPIOs! And the little "test" of course . Yes I did, and I also saw that unsteady blinking of the LEDs. Weird. I shall find one of my Arduinos programmed with my old parallel to serial code. If it does flicker as well that seriously then a) I did not pay enough attention to that matter back in the days or b) something changed in DOSBox-X. In Legacy mode of the ESP program, what is the baud rate on the BT connection "between" DOSBox-X and ESP? If I understand Gemini correctly, it should be possible to get the Baud rate in DOSBox-X as high as 115200. However, the MODE command does not work correctly and I need to boot DOS 6.22 within DOSBox-X??? Then the mode command should work? Weird. EDIT: Naa, Gemini changed its mind and said: No way ... I mean using TCLogo_S, the bottleneck must be serial, as a 1 ms interrupt should be easily emulated, right? And as Alex has just changed the ISA addresses from the 9771 card to HW serial port 1 (COM1), data should arrive at the emulated UART every ms. And when the serial connection to BT is fast enough, I don't see any reason for the flickering to occur? At 9600 Baud yes, but not at much higher Baud rates. I simply don't have any understanding of how all this works. Do you have any idea? I tried this in the config file of DOSBox-X, but nothing changed: serial1 = directserial realport:COM17 baudrate:115200 bytesize:8 stopbit:1 parity:N txdelay = 0 There is also this serial = nullmodem option (I believe only here the baudrate setting applies ?) but I am too dumb to get it. Best Thorsten