Bliss

The WebHID api in chrome works only for HID-compliant device in the "Device Manager → Human Interface Devices". Delete any other drivers that appears when you plug the Toypad... (Check the box for delete its software as well)... Reboot

@Toastie, Did you check the permissions in chrome? Type the following in the address bar: chrome://settings/content/usbDevices You already used USB to serial adapter with your setup, so It cannot be the permissions... When you plug your toypad, does it appear in the Windows Device Manager in the "Device Manager → Human Interface Devices" (HID-compliant device)? (Mad Catz, Harmonix, LEGO, Unknown device, Vendor HID driver, HID-compliant vendor device, all those are bad) Here, it shows many generic HID devices but I can see that one more HID is adding up when I plug the toypad... If you have the wrong driver, in dev manager, uninstall device and check the "Delete the driver software for this device"... unplug toypad and reboot. Can you try on another PC?

I don't see why right now because my code filters for the same vendor and product ID shown in your images. const devices = await navigator.hid.requestDevice({ filters: [{ vendorId: 0x0E6F, productId: 0x0241 }] }); On my side, I tried Blockly and your NFC color changer and both works. Make sure you have the latest version of Chrome in case. Check the Chrome Console (F12) for any error message. Make sure you do not try to connect while your pad is already connected to your NFC Color Changer program. What OS are you working with? Did you tried on different USB port? Also, the NFC Color changer software, use libusb.dll which is not the same as the Chrome's WebHID... If your using windows 10, make sure the permission are enabled in chrome for USB devices. Type the following in chrome: chrome://settings/content/usbDevices

I read your long experiment in the INT A thread but diagonnaly so I missed some key elements... I tried the setpower in TCLOGO_S and the Leds I wired for the outputs of the FT245 were blinking fast :-) So about this FT245/232H thing, It might work in its native configuration (Standard OS driver) after some good effort (Still struggling for the inputs) natively but it needs a bunch of circuitry (TTL, Res, Cap)... The Bit Bang Mode, which involve loosing the Serial COM port, so purely USB, is more interesting for me as there are NO external component needed, only wire the pins directly to INT.A... That was my primary goal, find a solution that almost works out of the box with no microcontroller to deal with. (Still have to wire the pins of FT to INT.A somehow and change the Driver with Zadig). It works with Modern software, but not with original TCLOGO/LINES... But using FT in its native mode, Serial COM and shared FIFO input/Output requires some DIY circuitry which for me, render the whole project less appealing... However, thinking about it, we could maybe think of a software gateway, I remember this com0com null modem serial com port emulator... Between TCLOGO_S/DOSBOX-X and the FT245/232H, there would be a gateway software to catch the TCLOGO serial traffic (com0com comes handy here) and convert it to USB Direct IO to FT in bigbang mode and then to the Int.A... Just to keep things somehow compatible with old software... Anyway, I might evaluate this route eventually.

@evank Now that's the tricky part... USB I believe did not exist in 1980s I think... And in today's computer, no more parallel port and no more ISA bus and no more serial port... But we can still get seiral comm with the use of USB to serial adapters... Suppose you accept the USB-Serial adapter and start your rules from the serial RX / TX pin and GND... The FT245 / FT232H does more, as it allows to transform Serial comm from the USB port (Still seen as COM port in the OS) to parallel data lines (D0 to D7) directly... FT245 is called a USB to parallel FIFO interface... (Still using COM port on the PC, but no TX RX at the other end, it is directly parallel lines). (FT232H can do the same but is more universal as it can also do basic USB to serial with RX TX etc). So it depends if you accept the FT245/232H like you would maybe accept a USB-Serial adapter... For the TTL part, I'm pretty sure everyting was available back then but was 74LSxxx, not the more efficient 74HCxxx. (Gemini said all the 74LS174, 244, 573 were avail at the end of 1970s)

@Toastie, Since the FT232H seems to do the job and has even a FT245 mode, I decided to pursue my test with the FT245 while I'm waiting for the FT232H delivery later this week (Amazon). So I tested the FT245 in its native mode (Serial Com port) which sends Bytes directly to its Datalines D0-D7 and reads bytes from the same datalines (Shared). Since the datalines are shared, we need some TTL chips ... I juste tested the Outputs D0-D5 for now with the 74HC174 that was lying around... (74HC573 would also do the job). The CLK of this 74HC174 is wired to the FT245 RXF and RD pins but for the RD pin I needed a small RC circuit (1K res + 10nF Cap) to make a pulse... Easy. It is working flawlessly with a Terminal utility like Hercules sending Bytes one at a time (Hex). AND IT IS WORKING with TCLOGO_S.com as well in DOSBox-X ! No arduino at all, just the FT245 (Should be soon the FT232H) and 74HC174 and RC circuit (1K Res + 10nF cap ) (And LEDS :-) ) Now for the Inputs (6, 7) There is more to add... I guess that TCLogo_s read continuously when it is not writing ? (DOS shares the same IO Adress right?)

Using the Zadig driver removes completely the COM port in windows so the test I did with the FT245 and FT232 will not work for this particular purpose. The only thing about using an FT245 or 232 like I did is to be able to talk to interface A without microcontrollers... But softwarewise, you still need to be able to deal with Direct USB communication not using Serial at all. Which we can do with modern software like Javascript, python etc... Might also be possible if we can use USB in DOS... somehow or redirect DOS serial to USB I don't know. However, As I said earlier, we could have been able to use the FT245 with its native driver (Serial COM Port) using some external TTL component and then I believe it would have been fully compatible with TCLOGO_S.COM... I read that there are some replacement chip for the FT245RL available but I did not see any breakout board yet... That is why I love the Arduino idea so much as it will be available for many years and even after they die, there will be other uController to do the job... EDIT: I read that FT232H could be a good replacement for FT245 and widely available. I ordered one... we'll see... there is an FT245 mode that can be set in the FT232H eeprom...

Oh, I've been lucky then to find them in my local store... It might not be a good idea to pursue around this board then... To bad as it was doing parallel lines directly... For the FT232, I have to read more... In VCP std mode (Virtual Com port in windows) it is just a regular USB to Serial adapter like the ones you probably already have ... But with the Zadig bare USB driver, it is not seen as a COM port anymore in windows and my HTML test page is using USB Read Write command, not Serial Read Write commands... Still, I need to read more about the FT232 capability...

@Toastie, I read a bit more about the FT245 USB-Serial / Fifo board. In is std USB-Serial driver mode (No Zadig driver bypass) it handle some kind of parallel FIFO using the D0 to D7 pins and some Handshakes pins (WR and RD, TXE, RXF pins)... The D0-D7 are used for both Inputs and Outputs in a half duplex manner... So I think with external TTL chips, there would be a way to latch Outputs and isolate inputs while Writing outputs to Interface A for example, and Latch these outputs while reading inputs on D6, D7... This would mean would could Write through serial a byte 0x3F to activate all 6 outputs for example, and proceed to read bytes where bit 6, and 7 would represent the status of Lego Int.A Inputs... I have some ttl chips in hands like 74HC174N (Would prefer a 575N but that should do the latching work) and a 74HC244N (Input isolation)... I'll try to figure out the handshake and might do some tests for fun...

Good question as it might infringe @evank's binding rules... At first, Gemini said it should work using WebSerial API with the OS driver installed automatically (a COM port)... But it did not work and Gemini changed its mind and said we have to go Bit Bang mode... So by using Zadig, it replaced the OS driver by a bare USB driver. So we have to use WebUSB API which deals directly with USB (No more com port). According to Gemini, it can still be used in DOSBox-X by modifying the dosbox-x.conf file: (But Gemini has been proven to be wrong quite often) [usb] usbcore = true # This command forcefully captures the raw WinUSB device # and presents it to the DOS environment usbdevice = passthrough vid=0403 pid=6001 and I guess there is more to do if you plan to use original TC Logo software which expect the use of a ISA board and Direct IO read/writes... I do not think it would be easily feasable to have original TC Logo running in dosbox-x to use the USB directly... The Baud rate, parity, stop bit becomes a decoy I believe with the use of Shift registers... You need to rather use the RTS/DTR pins to write data (SR clock/data/load) and CTS/DSR to read... So this cannot, I believe but might be wrong, be used with TC Logo in DOSBox-X (Maybe by making some kind of dos driver and put it in DOS config.sys?)... But I think RTS DTR CTS DSR pins of a com port can be programmed using Q-BASIC...

Pictures of the tests with my FT245 board and LEDs only, no Interface A. The HTML test page (using Javascript and the WebUSB API): (It says Connected FT232RL but this is a bug in the JS code ...)

So I was curious and tested the FT232RL USB to UART board and also the FT245TL USB to FIFO (Parallel) board. AI Gemini suggested this as an alternative to control Interface A with modern computer without using Shift Register (74HC595, 165), MicroControllers (Arduino) etc... Ultimately, you can wire the FT board directly to Interface A connector... Since I have no Int.A, I used LEDs which would still be a great addition to a final setup anyway... Please be aware that to use these boards as parallel adapters, you need to bypass their original mode which is being recognize by the OS as a USB-Serial adapter. To do so, you need to use ZADIG utility which is free to download and easy to use. https://zadig.akeo.ie/ Plug your board, go to Zadig Option menu, select List all device. Then in the dropdown, select your FT245 ou FT232 device. On the right of the green arrow, make sure it says WinUSB... Then press Replace Driver. NOTE that you cannot have both FT245 and FT232 bypassed at the same time. Choose one or the other board. (This is because both are from same manuf and use same IDs...). It may ask you to reboot the computer but I did not reboot. It takes sometime to replace the USB Driver so be patient. The FT232RL red board is cheap and easy to find but the pins have been identified for a different purpose than parallel control... A refence table is provided below. FT232RL will require some header pins to be soldered as not every signals have headers... https://www.amazon.ca/CANADUINO-FT232RL-USB-Communication-Programming/dp/B07B28LV33 FT245 is a bigger board and more expensive. But All pins are there and have the right label (D0 to D7 which fits great with Int.A). I easily found a FT245 stock at my local electronic store. https://www.waveshare.com/ft245-usb-fifo-board-type-a.htm For both boards, do not forget to place the jumper to 5V, not 3.3V. Here is the Reference pinout table: FT245 Labeled Pin FT232RL Labeled Pin Lego Interface A Connector pin (And Function) D0 TXD Pin 6 (Output 0) D1 RXD Pin 8 (Output 1) D2 RTS# Pin 10 (Output 2) D3 CTS# Pin 12 (Output 3) D4 DTR# Pin 14 (Output 4) D5 DSR# Pin 16 (Output 5) D6 DCD# Pin 18 (Input 6) D7 RI# Pin 20 (Input 7) GND GND Pin 5, 7, 9, 11, 13, 15, 17, 19 VCC VCC Pin 1, 3 ? HOW TO TEST: I did not yet implement a driver in lego blockly. I'm goint to wait some feedback from people to convince me that this has some real values. But I did, with the help of gemini, developped a simple HTML TEST page that has a javascript code. (Has some ON/OFF buttons to activate outputs, and green / red input status leds alike). Copy the following file on your computer and drag it in Chrome. It works for both FT245 and FT232... https://github.com/BlissCA/lego-blockly/blob/dev/universal_lego_test.html I noticed that when unplugging and plugging the USB cable, the output (LEDS in my case) are blinking fast sometimes. And after plugging the USB cable but before connecting using the test page, the outputs are like dimmed a bit. Connecting to the board using the test page removes the dimming. Also, the led dimming disappears if you use 10K pull down resistors... But the glitching of outputs during USB cable disconects/connects remains. So I suggest to plug your Int.A only after the USB cable is fully connected and if no pull down resistors are used, wait until the Test Page is connected to the board. (I don't know if the dimming may affect the Int.A outputs though...) In short, the steps to test this: Place jumper to 5v on your board. Plug your Board to your PC USB port, use Zadig utility to replace the OS driver that is installed automatically by the OS... Wire your board (Better to unplug USB for doing this). FT245 is quite direct, use D0 to D7 connected to Out 0 to 6 and Inp 6 and 7, and GND to GND... The board also have a 5V out pin. I don't know if you need it at the Int.A Connector... For the FT232 board, use the reference table above. I recommend using LEDs with 1K resistors... for the outputs. Download the universal_lego_test.html file, Drag the file in Chrome, press connect and choose your board in the list. The ON/OFF buttons for outputs and Intpu status indicators will show. Have fun Hoping that some people will be able to try this out and comment...

^^^^^^ @Toastie, Indeed you're last code is even better and cleaner according to me. Thanks for bringing the idea of bitwise operations... This is a must in automation programming. @evank'rules are quite binding rules. However, I thtink the USB2TTL adapter + two SRs/latches could be an interesting project to try... I would be surprised if I have those IC's in my collection but I may order some ...

@Toastie and all, I added a Bitwise category under Math category where you will find a bunch of bitwise operation blocks. your ( @Toastie ) code could now look like the following I think: Bitwise operations work on 32 bit numbers. That might be of some concerns sometime like the shift left etc... But there is also a MASK block if needed. For the "Test Bit", set bit, clear bit, Toggle bit and Extract bit blocks, keep in mind that bit number starts at 0. In a math constant, you can type hex or binary literals directly but when you press enter, blockly converts immediately to numbers: Example: Once "ENTER" is pressed, it shows: I will probably add a format block to be able to display / print values in hex or binary and will also add a literal block to be able to specify binary and hex that will stay in these formats, not converted to decimal on screen. EDIT: I added a format block to convert numbers to hex or binary to display as a text (You cannot use the output of this block in a math or bitwise operand...) This format block is located in the Control, Interactive Control toolbox:

1. Indeed, there are no bitwise operators built-in in blockly but you did a great job to work around this flaw :-) . I will try to add a block to achieve basic bitwise operation AND, OR, XOR, NOT, >>, <<. 2. Round down is the correct block to use to achieve what the "INT" function does in other languages... (Take the decimal off a floating point number to get the integer part only). 3. In the math toolbox, the second block is a math operation block where the operator is a dropdown where you can choose between +, -, *, / and... "^" the latter being "exponent". So you can do 2 ^ 6 (= 64) for example. For a modern computer, the arduino way is great as it allows to add more functions like PWM the outputs, add internal fast input counters, etc... And with the Nano, it can be pretty small footprint. If we don't mind to let go the input counting and pwm, I guess we could make some circuit using the 74HC595 (Serial-in to Parallel-out for 6 output lines) and 74HC165 (Parallel-in to serial-out for 2 input lines) along with a USB-to-Serial chip (FTDI). "AI" also proposes using the Direct Bit-Bang method (No shift register) available in some FTDI (FT232RL, FT245R, ...). There would then be NO Microcontroller at all and would be a true Parallel conrol. I have no idea how simple this could be though compared to the arduino solution. I may look after this by curiosity. (I have a FT232RL red board I've never used...)