Bliss

So we are stuck with this 9600 limitation with dosbox-x that gives max 960 bytes / sec rather than 1000 bytes / sec as required by TCLOGO... This represent 40 bytes we may miss once a while... that's a lot. And moreover, I found out BT is using some stack buffering so it might send to the ESP like 15-20 ms burst of data bytes read from TCLOGO_S. (Meaning that TCLOGO might send a byte every 1 ms but ESP will not get them every ms but will get maybe 20 bytes (20ms of data) at once after a delay of 20 ms... No data loss but still a delay...) So knowing all this I changed the code in the ESP32 to try to detect the duty cycle of the bytes stream sent by TCLOGO and then I calculate a ratio that I multiply 255 and use this value with the ESP real PWM... (So transform the software PWM to HW PWM) At first, I set the window time calculation to 50ms (which is about twice the estimated data burst of BT) and I could see a flicker once in a while but that could be very much caused by the baud rate limitation and the missing 40 bytes... I then raised the window time at 80ms which is better I think but this might affect response time too... (Only for tclogo..) This is not perfect as SETPOWER 1 sets the ESP PWM a little high I think (I rely on leds only...). I can adjust if really required. Please, try this new version Lego9750_PF_ESP32_V3 in: https://github.com/BlissCA/lego-blockly/tree/dev/SketchArduino And let me know. (The fix only applies to legacy bit bang protocol... The blockly protocol is still the same and better according to me as it allow to set a PWM value different for each individual output...) Thanks.

If we assume the Baud rate is irrelevant for Bluetooth, so ESP does not care, now with the software running in the OS using the virtual com port, like dosbox-x, there must be a speed for the data communication related to serial port... I also tried this in the dosbox-x.conf: serial1 = directserial realport:COM14 startbps:115200 parity:n bytesize:8 stopbits:1 But I did not see difference either to be honnest... And I don't know if there is a way to know if Dosbox-x (tclogo_s) is really sending/reading byte at the speed specified in the conf file... Gemini said: Also: Gemini also says BT can generate some jittering... Did you try with your Arduino UNO bit bang code? If BT may add some jittering, the Arduino Uno using direct USB -Serial FTDI shoud be better? Gemini recommands other settings adjustments etc to play with... I'll let you know if I find something.

Thanks, It works! :-)

I tested a bit and the outputs are working but when using keyword COUNT, and ajusting input 6 and or 7 it gives an error message when pressing F9 run. This is the error when using a patched version that works with my ESP32 board. (Patched means I just replaced 9D 03 by F8 03 in the LINES2.EXE file) When using your original NOT patched LINES2.EXE file it gives the same error. I also copied the .LIN sample file from the French version to the English version folder and the French Keyword are not automatically converted, so COUNT is actually showing COMPTE and it is not working even if I replace with COUNT after...

Out of curiosity, does it mean that the TC Logo Connect physical device itself is seen as a serial COM port in Windows Device Manager? So we could still use the device WITHOUT TC Logo Connect software in a bit bang mode using a simple Terminal program like Hercules or Termites that would connect at 9600, 8, N, 1 for example and that can send and receive Hex value bytes... For example, write "3F" with Hercules, would turn on all 6 outputs of int.A... Also, someone in dosbox-x could still adjust the dosbox-x conf file to redirect dos serial1 to the com port of the TCLogo Connect device in windows and make some Basic or QBasic program to read and write from/to IO Address 0x3F8 (Serial1)... I like to see that "seed studio" board have been used in the device because I I have some of their products and it is always good quality!

@Toastie, Since the back of the ESP is facing UP once installed directly in the Int.A port, and it is pretty "dull" lol, you could maybe solder a led indicator module (Cathode common) right on the back of the ESP which would align perfectly with GND pin and all 8 required GPIOs... I know Int.A already has led indication, but that would make the Board easy to use without the Int.A for testing purpose... (Like I do)

As I said earlier, I think the red/white wires ARE mandatory as they are used to send 3.3V and GND TO the Int.A. What is optional, the Pin 2 and 4 of the Int.A connector that You hacked to get 9V out of the Int.A to supply the ESP32 board which is an amazing hack by the way! Maybe I would rather order a "No Header" ESP32 Devkit 1 30 pins... Then you could fold the 8/10 pins required of one of the row of the IDC connector and insert these folded pins in the ESP GPIO holes directly and weld them there... With Bluetooth communication, no Flat cable, no USB to Parallel Box laying around and NO addional power from an external wall charger (if you do the 9v power from Int.A Hack), this makes the cleanest setup according to me. But it remains a DIY project which is quite fun but it is certainly not as Plug and Play as the new solution for legacy TCLOGO... (And this ESP32 solution is also working with Lego Blockly ;-) )

I saw the link before you remove it... Why did you remove it? I guess it is against some rules ? Anyway, from what I can see, This tc-logo dot com web site is offering another way of connecting a modern computer to interface A by using the very original non patched TCLOGO.COM but with a Custom Dosbox-x software called TC-Logo-Connect. So rather than patching TCLOGO.COM, they patched Dosbox-x I guess to redirect ISA board address to USB somehow... They are also offering to buy an arduino USB-C Bridge on tindie.

Are'nt the red/white wires mandatory (Not optional) to bring the 3.3V and GND to pin 1 and 5? Optional 9V and GND from the Int.A connector pin 2 and 4 are part of the same row that has the Outputs and Inputs (pins 6, 8, ...20) that are aligned with the ESP32 pins so you were able to weld all 10 pins directly including GND and VIN (9v) to power the ESP32 from int.A. If you do not customize the Int.A to get the internal 9V and Gnd to pin 2 and 4 of its connector, we can power the ESP32 from its usb port using a wall charger right? If you read the first couple of page of this current thread, you will see that @alexGS not only patched TCLOGO to run over a parallel port, but also made a patched version using serial1 IO address and that has been proven to work by @Toastie. All patched version of TCLOGO and other pertinent information on how he patched the files using hexed.it are on his bricksafe page: https://bricksafe.com/pages/alexGSofNZ/interface-a-tc-logo

Well, I saw that @alexGS was using hexed.it on his bricksafe Interface A, TC-LOGO page: https://bricksafe.com/pages/alexGSofNZ/interface-a-tc-logo. Indeed this is a great online tool! So I did the same for patching LINES2.EXE as he did for TCLogo.com... Thanks to him for giving all the needed information to patch a legacy software ... (He gave the IO address 0x039D (decimal 925) in the first page of your Lego Interface A thread already).

@Toastie, By the way, I found a "French" version of Legacy Lego Lines for MS-DOS on the Internet Achives. I did not find an English version. In the Zip files, there were a bunch of sample programs and two EXE file, LINES.EXE and LINES2.EXE. Then I used the online hex editor https://hexed.it/ and opened the LINES2.EXE and search for "9D03" using the hex editor search box on the right pane. It found 2 occurences not far away from each other. I then typed "F8" over the "9D" byte of the two found location (To have the 03F8 Serial IO Address). I saved the modified file as LINES2_S.EXE. I started LINES2_S.EXE in Dosbox-x (With serial1 pointing to my ESP32 Com port in dosbox-x.conf) and it appears to work great... So if you happen to have a legacy german or english version of MS-DOS lego lines, I assume you could do the same...

I just downloaded the publicly available Lego Mindstorms NXT BT Dev Kit... I'm trying to find a Minstorm NXT set on Marketplace to test. It should be too long after that to implement into blockly... Stay tuned :-)

Hello David, One of Lego Blockly primary goal is to provide a common programming environment for all "Brainless" lego control bricks from the past to todays bricks... This may include interacting (messaging) with Smart bricks or using Smart bricks as remote I/O hubs that would then act like brainless devices... So Lego Blockly is not meant to build programs uploadable INTO smart bricks... I know that PyBrick has a Blockly interface to do that (Uploadable programs) for recent smart bricks and hubs and also EV3 I think... I don't know if they do NXT... There is also the very good @maehw https://www.webpbrick.com/nqc/blocknqc/ that can do RCX programs using a blockly interface. I don't know if a blockly interface has been done for NXT series... Maybe it is missing ... However, I do want to eventually add support for NXT and EV3 but only for messaging with their programs or use them as dummy remote I/O hubs... Regards, Yves

10 000 Blockly blocks in SBrick? Are you sure? it is a serious load of blockly blocks I doubt Lego Blockly can handle that much! Do you have a peek view how your program looks like?

Lego Blockly supports all kind of communication type like USB (USB HID device like WeDo 1.0, USB-Serial using Virtual Com ports) and it supports BT and BLE. Lego Blockly already supports some LPF2 (PU) BLE devices (WeDo 2.0, Boost, Technic Hub etc...) But SBrick for me was unkown until today... From what I read, SBrick also has its own Hardware? Does it have Inputs or just Outputs? I think I saw that SBrick published its GATT communication protocol openly... So might be fairly easy to integrate to lego blockly... (But I do not own any SBrick hub so cannot make tests...) And how many BLE Hub connections can blockly handle at a time, that I don't know... I can't find any sbrick devices on marketplace in canada... What is a PF-plug distance sensor? you mean a WeDo 1.0 Distance sensor? If you have the WeDo 1.0 Hub, Lego Blockly supports WeDo 1.0... In lego Blockly you can mix Lego Interface B, WeDo 1.0, WeDo 2.0, LPF2 (PU, Boost, Technic Hub, etc) all together... I doubt very much you can connect a WeDo 1.0 sensor to the 9v Int.B... It would be better to get some 9V Light sensor maybe? they are not distance sensor but can detect proximity... If you have LPF2 distance sensor, or WeDo 2.0 sensors, you can use them in Lego Blockly (WeDo 2.0, LPF2 hubs)...

But Interface B still has some current limitations... I doubt it can run 8 train motors at the same time no? And how you do when you have long 9V train tracks... There must be some load loss over the distance? I admit I don't know much about those Lego Trains... I already had a 9V train though...

Hello Ashi, I'm mostly developping the Lego Blockly project these days... You may also look after the Python module for lego Interface B: https://github.com/BlissCA/LegoBpy Python is a fairly easy language to learn AND if you download and install Thonny IDE, it make the Python learning experience easier according to me. I believe for Bigger projects, it might be a good option. And you can use many Int.B at once. The github has a Readme to explain how to use. I also made another thread for a MicroPython version that runs on an ESP32 MicroController which is also very Cool as it makes the ESP32 autonomous. This is a bit more advanced though if you're not familiar with MicroControllers... I did not worked more on the micropython driver to add more features but as far as I remember, it was pretty solid... See: LEGO BLOCKLY Since few months now, I'm working on the Lego Blockly project. Lego Blockly is running in a Browser (Chrome or Edge) but it is possible to use it offline. When you visit the page the firstime, there is a small TV icon on the right of the Address (URL) bar and if you click on it, you can "Install" Lego Blockly. Note that it is still using Google engine but it is suppose to run without access to internet. Lego Blockly page: https://blissca.github.io/lego-blockly/ You can connect more than one Interface B and the programming language is based on Blockly, like lego blocks you connect together. I think it is very simple but it needs some time to get the hang of if. It supports many Lego Devices and more needs to be added eventually. I did not implement any thrid party devices like SBrick that I just learn the existance by you :-) I may in the futur add support for other brand devices if the interest is there and if there is public information available on how to interface with them... It is easy to play with Lego Blockly but I'm not so sure it is well suited for Big projects though that will run for many hours non stop... The code area is infinite, you can zoom, scroll etc but I read that running programs that have 5000-7000 blocks may become slow and laggy... While it runs a program, the Page needs to have focus all the time and you must disable Power saving on your PC etc... But you may try it as it is really VERY super simple to use. No special software to install. And do not hesitate to ask question here and talk here about your experience and even suggest features so I can improve Lego Blockly. Thanks for your interest. There are also projects by others you may look after like @Mr Hobbles BrickLogo: https://github.com/openbrickproject/BrickLogo/tree/main It is also very well documented! It's using LOGO software like the original Lego TC Logo and LEGO DACTA Control Lab... I'm pretty sure there are others available.

We posted almost at the same time :-) I changed the freq already in the github. This works well because you use the 30 pin ESP32 Devkit which is great indeed. With the 38 pin version, there is a GND pin between the 13 and 12 pin that would break your setup and also the Vin/Gnd are not at the same location... Using the 30 pin is really the best then and It makes a really small fooprint wireless adaptor ! Modifying the Int.A to get the 9V on pin 2 is a must for sure! Thank you for your time testing all this!

DonT, you have LEDs too attached to the ESP in addition to the Int.A? On my side, the LEDS attached to ESP32 GPIOs are dimming smoothly on the full range 0-255. In Arduino IDE, the code to adjust the frequencey is at line 241: // ========================================================= // PWM (ESP32 LEDC) for Blockly outputs // ========================================================= const int LEDC_CHANNELS[6] = {0,1,2,3,4,5}; const int LEDC_FREQ = 20000; // 20 kHz const int LEDC_RES = 8; // 0-255 I changed the 20000 for 1000. Could you please try again? (I also read the 3.3v may also affect, so if not better, using a logic converter may help too. But 20 kHz was way to fast for sure). Use the sketch: Lego9750_PF_ESP32_V2 in the following folder: https://github.com/BlissCA/lego-blockly/tree/dev/SketchArduino

And Blockly offers a far more precise real PWM using the PWM engine the ESP offers... So someone can still use PWM with Int.A and ESP32... I just wonder how Int.A would behave with a PWM output signal to its connector that is 3.3V level... Might be better use a Logic Converter for PWM with Int.A? For the choice of ESP32 format, I much prefer ESP-WROOM-32 Devkit1 board as it as always been reliable in my projects... I had bugs with some ESP32 Mini clones in the past... I would probably choose the 30 pin version though... I had only 38 pins in my stock...

But did you try with real 4.5v Motors connected to the Int.A? I was wondering if motors really cared about the not that good pwm pulsing? There Baud rate is irrelevant in ESP32 BT version. You can set the baud rate of the COM in the end-user app... I tried in the dosbox-x.conf: "serial1 = directserial realport:COM14 startbps:19200 parity:n bytesize:8 stopbits:1" I even tried 115200. But still can see some inconsistent blinking. No real improvement between changes in the conf file so I wonder if Dosbox-x take them in account... I also tried with the FT245 which is a more direct way (TCLOGO_S DOsbox-x -> COM6 -> FT245 GPIO'S...). And I can see inconsistant blinking but maybe less not sure... I was also wondering about the BT thing is it could really sustain a constant 1ms write/read from TCLOGO_S... AI told be BT can be faster than that... But is there other thing to look after too... For sure there must be some Communication in the ESP32 and in windows... Don't know... So, I wonder if this inconsistency can also be seen at the motor level... If not, I will not look further than this... If it does affect, I don't see much how we can improve using BT solution...

I saw that Order mismatch and kept it for you to point this out haha... I did rearrange the order in the main sketch :-)... https://github.com/BlissCA/lego-blockly/tree/dev/SketchArduino They are supposed to have a regulator on board too as they have an USB port with 5 volt and the board must bring it down to 3.3v... But have to double check if it is the same spec etc... When you tried the TCLOGO_S, did you also tried the setpower and PWM simulation?

Super! And in addition, the Power Function IR should also work (with the ESP32 pin 4) in Blockly... I finally found a better IR Led in my recuparation stock (The previous one was working but the distance was like few cm only, but the new one is quite a few meters) and it works great! I've been told that you can safely connect a 9V DC source to the VIN (often labeled as 5V/VIN) pin of an ESP32 DevKit V1 because it goes through an onboard voltage regulator, but never connect 9V directly to the 3.3V pin or standard GPIO pins, as it will destroy the chip I never tried though...

There is also a ESP32 MiniKit that has almost same footprint as the ESP8266 D1 Mini, but i'm not sure the same pins I used are available... But we could probable adapt the Sketch to use the pins avail for the ESP32 MiniKit... But did you try the real advantage of the ESP32 solution? I.E., using the same setup with TCLOGO_S (And maybe your QBasic program) in dosbox-x (You must change the serial1 parameter in the dosbox-x.conf file)? You will then see that the ESP32 can handle the bit bang protocol too! (And at a different Com Baud rate !) Thank you very much for the testing and clear reports!

For the FT232RL Setup, indeed there are the Python Gateway and com0com emulator in addition to Dosbox-X... For the ESP32, it is the same as an arduino except it is using BlueTooth which may add a layer of glitching?, Idon't know... Ok cool! , thanks. That makes the ESP32 setup even simpler and attractive. I still hope someone will eventually be able to try the ESP32 sketch with a REAL Int.A to have a true POC (Proof of Concept) :-)