Dacta Control Lab Software

[evank]

9 hours ago, AJB2K3 said:

When you put faith in AI, always be disappointed. Now I know the core foundations I have to start from scratch because Gemini keeps hitting what I call the Admiral Ackbar crash

What does this have to do with the discussion topic?

[AJB2K3]

42 minutes ago, evank said:

What does this have to do with the discussion topic?

I used AI to create the ULI blockly front end for my Interface B code but it got to a stage where the AI kept getting confused blocking the port and causing the "Its A Trap" error when running the code which instantly crashes code and programs.

 

[maehw]

Hacker voice: "I'm in."

(I got a response from my Interface B via serial.)

[Toastie]

23 minutes ago, maehw said:

Hacker voice: "I'm in."

Heehee, oh yes.

Just read these 31 bytes, and the byte bombarding begins ...

 

Here it is, in QBASIC 

PRINT #1, "p" + CHR$(0) + "###Do you byte, when I knock?$$$";
 'Programm stalls here, when USB2Ser adapter was unplugged during run
 'time and then plugged back in; CTRL NumLock = break into program.
R$ = INPUT$(31, #1) '"###Just a bit off the block!$$$"=31 byte
 'If it is 31 byte, just throw it away; if not throw an error.

Fun time.

Best
Thorsten

Edited February 12 by Toastie

[AJB2K3]

8 hours ago, maehw said:

Hacker voice: "I'm in."

(I got a response from my Interface B via serial.)

Nice work.

[evank]

15 hours ago, Toastie said:

Heehee, oh yes.

Just read these 31 bytes, and the byte bombarding begins ...

 

Here it is, in QBASIC 

PRINT #1, "p" + CHR$(0) + "###Do you byte, when I knock?$$$";
 'Programm stalls here, when USB2Ser adapter was unplugged during run
 'time and then plugged back in; CTRL NumLock = break into program.
R$ = INPUT$(31, #1) '"###Just a bit off the block!$$$"=31 byte
 'If it is 31 byte, just throw it away; if not throw an error.

Fun time.

Best
Thorsten

I always LOL'd at that communication string, but what baffles me is why it's mentioned in an Interface A manual! I can't recall which one right now.

[Toastie]

6 minutes ago, evank said:

but what baffles me is why it's mentioned in an Interface A manual!

I guess it isn't? This is only relevant for getting "access" to Interface B = starting its serial data spit-out frenzy, isn't it?

You even need the 5 chars in front of the "phrase", I forgot how many of these chars it actually reads, maybe all. 

Interface A requires no initialization at all, just the I/O chips in the computer driving it may need port direction initialization. 

Best
Thorsten

[evank]

I could swear I saw it in an A manual once, which made no sense at all. I don't have time to go look right now.

[Toastie]

2 hours ago, evank said:

I could swear I saw it in an A manual once

The RCX needed that string as well, as far as I remember, without the ### and $$$ ...

Best
Thorsten   

[maehw]

4 hours ago, Toastie said:

The RCX needed that string as well, as far as I remember, without the ### and $$$ ...

Best
Thorsten   

You're right. 

It's in the ROM code. 

Seems to be used for checking the firmware image – which resides in RAM after having been successfully transferred via the infrared serial interface.

So it also needs to be contained in every firmware image as this check is executed during the "unlock firmware" command.  

[Toastie]

1 hour ago, maehw said:

So it also needs to be contained in every firmware image as this check is executed during the "unlock firmware" command.

Yes, that was it. Back in my days, using QBASIC (I am still using and will "never" stop using it, owing to DOSBox-X), that was the way to get "in". With NQC and foremost BricxCC, things got relatively "easy" ;)

When folks want to go from scratch today, well, then use the "from scratch" information, which is all out there. AI so far does know that much about it, it will learn though, of course.

All the best
Thorsten 

 

[maehw]

On 12/13/2024 at 12:31 AM, Toastie said:

Here is the updated little bit diagram for #9751 data traffic:

All the best,
Thorsten

Hi all! I've been playing around with the WebSerial POC every couple of days. And it looks nice so far. "Only" a WebSerial-capable browser is needed to control an Interface B with a "modern system", no RPi in the middle (IMHO -- I may still run into performance issues though).

 

Dear @Toastie,

I am not 100% sure if this was the latest diagram posted by you.

Concerning the pressed stop button in the first byte (you call it byte #1): for me the indicating bit is bit 4, i.e. I read 0x10 when the button is pressed and 0x00 when the button is released. I am not sure if this is a typo/error in your diagram or there are really different revisions of the ROM code out there.

Cheers,
Mäh

 

PS: In case anyone is interested in this kind of technology, let me know and I'll upload my code some day. I think I'll open source this anways, but always motivated by others to do it rather sooner than later. And happy for feedback and improvements. ;)

____

Edit: If anyone of you who is reading this is located in the EU and willing to sell me a compatible temperature sensor, please get in touch with me!

Edited February 23 by maehw

[Bliss]

3 hours ago, maehw said:

Concerning the pressed stop button in the first byte (you call it byte #1): for me the indicating bit is bit 4, i.e. I read 0x10 when the button is pressed and 0x00 when the button is released. I am not sure if this is a typo/error in your diagram or there are really different revisions of the ROM code out there.

It is bit 4 indeed.  0x10 or binary 00010000 for the red stop button status.

[AJB2K3]

10 hours ago, maehw said:

PS: In case anyone is interested in this kind of technology, let me know and I'll upload my code some day. I think I'll open source this anways, but always motivated by others to do it rather sooner than later. And happy for feedback and improvements. ;)

____

Edit: If anyone of you who is reading this is located in the EU and willing to sell me a compatible temperature sensor, please get in touch with me!

https://www.hackster.io/AJB2K3/lego-dacta-interface-b-part-3-starting-again-42100a
 

My Hackster page has has a few guides on the interface B.
I work in Python using py serial which bypasses all the web serial problems and is completely OS independent.
I also have a Work in progress version of Blockly I am building just for lego devices.

[maehw]

Thanks everyone for sharing their knowledge and fun projects!

This is what the web-based program currently looks like (I am really bad at CSS, so this is pretty much hacked together):

 

You can control outputs (switch them on and off and set their polarity). No slider for output power yet, but that should be pretty easy to add. You can also read sensor inputs -- as boolean and as raw values. It's just that the UI becomes more and more confusing when not properly designed.

I've currently decimated the output rate by a factor of 10 (configurable in software of course) -- which still gives a nice responsiveness, but does not provide enough data when you really want to dive into the details when working with the rotation sensor.

If you want, you can uncomment several `console.log()` calls to see more details such as every decoded received frame.

This is really fun!

 

@AJB2K3 nice blog posts, Adam. It seems that you do not check the checksum byte in the frame. This may work when you always read the 19 bytes when always perfectly in sync and no byte is ever dropped. -- Python is a very good choice to be platform-agnostic. I'd do the same, if I wasn't experimenting with the web tools... -- also don't want to bother the user to install a Python environment.

Still, my solution "only" requires a web browser that supports WebSerial.. which Firefox for example unfortunately does not. So this is also a limitation for the usable environments. Besides that, no installation/configuration should be required.

Those of you who are more familiar with the ecosystem -- some official TLG software uses or generates LOGO code, right? Is this the same "dialect" as used with Interface A? So far only "worked" with LEGO Lines... ;)

IMO it'd be fun to get a LOGO programming language interpreter working in the browser and running it in interaction with the Interface B.

[AJB2K3]

31 minutes ago, maehw said:

Thanks everyone for sharing their knowledge and fun projects!

This is what the web-based program currently looks like (I am really bad at CSS, so this is pretty much hacked together):

 

You can control outputs (switch them on and off and set their polarity). No slider for output power yet, but that should be pretty easy to add. You can also read sensor inputs -- as boolean and as raw values. It's just that the UI becomes more and more confusing when not properly designed.

I've currently decimated the output rate by a factor of 10 (configurable in software of course) -- which still gives a nice responsiveness, but does not provide enough data when you really want to dive into the details when working with the rotation sensor.

If you want, you can uncomment several `console.log()` calls to see more details such as every decoded received frame.

This is really fun!

 

@AJB2K3 nice blog posts, Adam. It seems that you do not check the checksum byte in the frame. This may work when you always read the 19 bytes when always perfectly in sync and no byte is ever dropped. -- Python is a very good choice to be platform-agnostic. I'd do the same, if I wasn't experimenting with the web tools... -- also don't want to bother the user to install a Python environment.

Still, my solution "only" requires a web browser that supports WebSerial.. which Firefox for example unfortunately does not. So this is also a limitation for the usable environments. Besides that, no installation/configuration should be required.

Those of you who are more familiar with the ecosystem -- some official TLG software uses or generates LOGO code, right? Is this the same "dialect" as used with Interface A? So far only "worked" with LEGO Lines... ;)

IMO it'd be fun to get a LOGO programming language interpreter working in the browser and running it in interaction with the Interface B.

One of the top requests I had for my project was a install that configured everything with no hunting and cross platform, the other was that it had to be beginner friendly hence why the m running blockly on python so that users can start with blocks and see how the code links. I had to make an install script for Linux based systems after the security change to them requiring the use of VM’s

As to checksums, that’s not implemented as I don’t understand them at present 

[Toastie]

23 hours ago, maehw said:

Dear @Toastie,

I am not 100% sure if this was the latest diagram posted by you.

Concerning the pressed stop button in the first byte (you call it byte #1): for me the indicating bit is bit 4, i.e. I read 0x10 when the button is pressed and 0x00 when the button is released. I am not sure if this is a typo/error in your diagram or there are really different revisions of the ROM code out there.

Hello @maehw,

it was the last diagram, and it is of course wrong in that place as 0x10 is not 0000 0010  sorry for that, will clear that up when I find the damned diagram. 

In my QBasic program to speed up things a lill bit, I don't even check for any value other than 0, as I never found any other information in that byte.

I shall correct that!

Thanks again for noticing!

All the best
Thorsten

   

[Bliss]

8 hours ago, AJB2K3 said:

As to checksums, that’s not implemented as I don’t understand them at present 

I tested few sync logics with the checksum to see it can recover from desync and it does not work all the time depending on input values (if all zeros for ex).

So it is not perfect unless someone has a better algorithm that works in every situation.

So the best according to me is to ensure we have enough processing power to never miss a stream of data :-)

[AJB2K3]

Thats the other reason that I didn't put much thought into the Interface B's checksum, it just doesn't really serve any purpose once you understand the byte stream.
Writes don't need a checksum so its (in my uneducated eyes) not important.