Project: Programs to allow interactions between old Lego Control Interfaces (RCX, Lego Interface B, others?)

[Ashi Valkoinen]

@Bliss

About SBricks:

There were three different products. SBrick, SBrick+ and SBrick light.

SBrick was the first one, 4 by 4 block with 4 PF plug outputs. Could have been powered from any 9V LEGO source via PF-extension cable, both battery boxes and 9V train speed regulators can power them. I use them in trains with AA battery box, and trackside powered from speed regulator, which doesn't consume batteries since they are plugged into the wall.

SBrick+ was the same case with 4 PF plug putputs, but the PF plugs can also read sensor data - the WeDo 1.0 sensors. 

SBrick light was a 3 by 9 block, with 8 channels of 5V light outputs. Each channel could handle an RGB led output (of course, you could split more leds on the same channel), or each channel could have been splitted into 3 different white led outputs, so in total 24 single white leds OR 8 RGB leds could have been controlled independently. 

All units using BLE. SBrick and SBrick plus could have been used with SBrick app (now removed from official sources, but apkpure have the corresponding apk files), SBrick+ with inputs and SBrick light can be controlled from pro.sbrick.com. 

It is quite logical you cannot find any on sale, I bought my last 5 SBricks one year ago from a LEGO-themes spanish store and the last store I found any. Sometimes they pop up on ebay, but quite rare.

About my current program:

SBrick Pro uses the same "building blocks" for programming. Almost the same, like it has some "events", less math options, but you can also construct a graphic interface and add buttons and sliders on the screen. It would be the best if we can arrange a date and I will show it and its options to you via shared screen, on Discord or Facebook call, whatever you prefer. You blocky seems very promising for me, and if you don't mind it will be nice if I can ask some questions during a call. But my Interface B is still on its way, so nothing in hurry.

[djm]

@Bliss, I'm wondering if you are willing to add the NXT's to the supported devices. While there are other programming environments available (e.g. NXT-G, Brickx), it would be nice if support could be added. I'm willing to undertake testing as I have a few NXTs.

There are two ways to connect to an NXT:

• via a COM port using the LEGO USB cable
• using (classic) Bluetooth

It might be easier to start with the COM port connection as the first iteration, deferring the Bluetooth connection as the second iteration.

The plus side of doing this is that no additional hardware is required with the NXTs.

Let me know if you are willing/interested.

Regards,

David

Edited Wednesday at 08:13 AM by djm

[Bliss]

5 hours ago, djm said:

I'm wondering if you are willing to add the NXT's to the supported devices

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

Edited Wednesday at 01:46 PM by Bliss

[djm]

Yes, I'm not looking for an uploadable program (that's what NXT-G provides). Simply the the ability to run Blockly programs as though the NXT were "brainless". The NXT-G IDE is notoriously unreliable.

David

[Bliss]

2 hours ago, djm said:

Simply the the ability to run Blockly programs as though the NXT were "brainless"

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 :-)

[Bliss]

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

 

[Toastie]

2 hours ago, Bliss said:

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...

@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

[Bliss]

5 hours ago, Toastie said:

Equally cool is "Hexed.it"

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).

Edited Thursday at 12:41 PM by Bliss

[Toastie]

2 hours ago, Bliss said:

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)

You are right: Here is to Alex! 

[Toastie]

@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    

 

[Bliss]

2 hours ago, Toastie said:

The one (among many others ;) thing, I simply don't get is this:

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:

Quote

DOSBox-X only uses your .conf file baud rate as an initial fallback default because real DOS applications bypass OS configurations and control the serial hardware (UART) directly. When your DOS program starts, it calculates its own timing using the emulated 8250/16550 UART registers, which often overrides whatever you wrote in the configuration file.

Also:

Quote

the inconsistent LED flickering when running a soft-PWM command like SETPOWER 3 is a classic latency and packet jitter problem introduced by modern layers

 

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.

[Toastie]

11 minutes ago, Bliss said:

serial1       = directserial realport:COM14 startbps:115200 parity:n bytesize:8 stopbits:1

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

   

[AJB2K3]

Wow, While I have been away, this has grown some much. Nice work.

[Toastie]

1 hour ago, Toastie said:

I shall get my old Ardunio sketch out and repeat these runs ...

@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

[Bliss]

6 hours ago, Toastie said:

So I cannot change the Baud rate for COM1 (serial 1) in DOSBox-X - it is always 9600

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...
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.