Bliss

I finished a first version of an ESP32 code (Arduino sketch) for Lego Interface A (and PF IR) support. Advantage over the Arduino UNO/NANO: No HW serial, only use Internal ESP32 Bluetooth. So it is Wireless natively! Dual Protocol support (automatic detection). Supports Blockly protocol AND Legacy DOS Lego Software like TCLOGO_S.COM Requirements: ESP-WROOM-32, 30 or 38 pin version Do not use newer ESP32-C3, C6, S3 etc as they only support BLE. In Arduino IDE, Menu Tools, Board, Board Manager, you must use ESP32 Package 2.0.17. Do not use the latest 3.x.x package. Since ESP32 GPIO's are 3.3v voltage level, you need to use a 8 channel Logic Level Converter like DFR0844 or TXS0108E between GPIO and Lego Int.A connector pins... It is BLUETOOTH so you must have BT on your PC... I bought myself a cheap TP-LINK BT/BLE dongle... Once the ESP32 is paired in windows, it creates 2 virtual com port. Only one will work, the one flagged Outbound... In windows Bluetooth device page, there is a section for associated parameters and then More Bluetooth parameters... This will give you more information about the com ports created... I tested only with LEDs connected to GPIOs using 3.3v, NO Logic level converter. THIS HAS TO BE TESTED/VALIDATED with a real Interface A using Logic level converter before we can decide to make this solution the recommended one. I successfully tested (with leds) the following: Legacy mode TCLOGO_S.COM Legacy Mode using a terminal software that can send and receive raw bytes like Hercules and Termites. Blockly mode Input and Output (PWM) blocks. Blockly mode Infrared Power Function. Note that in legacy TCLOGO_S.com, when I "setpower" to anything less than Max (7), the output leds are blinking fast (PWM) and the blinking looks inconsistent. I don't know if it is normal, I also observed this with FT232RL tests... Get the ESP32 sketch Lego9750_PF_ESP32_V2 here: https://github.com/BlissCA/lego-blockly/tree/dev/SketchArduino

I'm having fun experimenting new ways to connect to the Old Lego Interface A with Legacy DOS software using Serial communication even If I don't have an interface A haha... So after playing with the FT245/232H and recently with FT232RL in bit bang mode using a software gateway which works really great but no wireless BT solution can be used, I decided to go back to the microcontrollers but not with an arduino. I did a test with an ESP-WROOM-32 devkit that is a very popular WIFI/BT etc relatively cheap board. I used BT NOT BLE (The newer ESP32-S3, C6, C3, etc can only do BLE) to have serial com port at the PC Side like an HC-05. BT is fast and can do sub msec communication as required by legacy TCLOGO_S.COM... We can use the Arduino IDE to program the ESP32... The ESP32 GPIO are 3.3v so we have to use a cheap bidirectional voltage Level shifter like the "TXS0108E"... I uploaded a simple BT to GPIO program in the ESP32 that does the same byte protocol as my previous FT232RL Gateway program and it appears to work very reliably with TCLOGO_S via dosbox-x ... This solution requires NO software Gateway nor com0com null modem emulator... it is direct Serial COM to BT. And it makes the Lego Int.A wireless (Well at least for communication, still need power supply...) Is it better than a Arduino with a HC-05 BT to Serial adapter...? I don't know but we eliminate the Serial code with the ESP32 because BT is managed internally... Arduino UNO/NANO: PC End-User program <-> PC Virtual Serial COM port from HC-05 pairing <-> PC BT Dongle <<->> HC-05 BT <-> HC-05 SERIAL Pins <-> Arduino SERIAL Pins <->Using Serial instructions in arduino Code so Baud rate in Arduino code must fit baud rate in end-user programs... ESP32: PC End-User program <-> PC Virtual Serial COM port from ESP32 pairing <-> PC BT Dongle <<->> ESP32 Builtin BT<-> Using BT instruction in arduino code. The ultimate goal though is to make a solution that would work with both Legacy protocol and a specialized Blockly protocol... So i'm going to look after making a arduino code that can be used for both legacy protocol AND blockly protocol... I put the arduino IDE sketch for the ESP32 BT (Lego Legacy Protocol only, no blockly yet) in the following folder if some of you want to give a try: https://github.com/BlissCA/lego-blockly/tree/dev/SketchArduino In the board manager in Arduino IDE, you must use version 2.17 of ESP32 package. latest version seems to have a bug for standard BT... GPIO pins used: 12, 13, 14, 25, 26, 27 for Int.A Output 0 to 5, 32, 33 for Int.A Input 6, 7.

I added in https://github.com/BlissCA/lego-blockly/tree/main/Misc a diagram that explains this software gateway project for using legacy DOS Lego software for Interface A in a modern computer using a cheap FT232RL in GPIO mode... EDIT: Please, note that all serial com happens at 9600, 8, N, 1... This was just to demonstrate another way of interfacing with Lego 9750 without using an arduino. The arduino way still remains the best way according to me (Fairly cheap and flexible)... There are other direct HW solutions (Serial to GPIO) using FT245/232H board that i'm evaluating, which appears to work WITHOUT any software gateway, (NO com0com, NO python) just plain TCLOGO_S running in dosbox-x communicating through serial/USB to FT245/232H then using FT GPIOs wired somehow to Interface A connector... BUT FT245 is discontinuated, FT232H is more expensive and it requires a fair amount of TTL and Passive components to be added... I might give schematic eventually... EDIT: I tried this FT232RL Gateway with @maehw brick_lines.py and it works. However, when I run a lines program like BTEST.txt sample that wait for input 6 at one point, it works great but when the lines program finishes and return to dos, the dos window hangs for 1 min and CPU fan runs fast... But besides that it works.

The best will be to test it :-)

It should send Input status ON CHANGE only OR after an Output Write. (The read byte is always the In 6/7 status AND the Out 0-5 last write state) If the inputs change their state quickly i.e. faster than the end user software can take it, It is not supposed to overflow , nor fill the com RD/WR buffers etc... So the input status read of the gateway should adapt to the end user software input scan time... But I only tested with TCLOGO_S to make sure it was still working with instant response of the input changes... And I tested with Hercules terminal utility connected to COM12 (Same COM port configured for TCLOGO_S)... With Hercules, even if no output write sent, it reads a byte only when input changes. (Input 6/7 state with last outputs 0-5 state as well) When it writes a byte to output, it reads a byte back which will be the input and new output state. Maybe it would work with your QBasic program as well in Dosbox-x...

I improved I think the Gateway program for the FT232RL for better support of TCLOGO_S AND also other than TCLOGO_S software... Like maybe Lego Lines if a patched version ever happens... https://github.com/BlissCA/lego-blockly/blob/dev/Misc/LegoGwy_FT232.py Because the first version of the gateway was only sending back sensor status if it received an Output write from TCLogo... It was fine for TC LOGO because it writes continuously every 1 ms to achieve PWM... But I doubt Lego lines does that... So the new version alway send input status with or without the write of outputs...

Actually, FT232RL breakout red board is a USB-TO-SERIAL TTL adapter in its standard configuration, used with Windows native driver. To use it in a parallel lines configuration to attach an Interface A directly to the board , you need to change the native Virtual COM port OS driver with a more generic one (Zadig utility allows us to achieve that)... NOT TCLOGO_P but TCLOGO_S which is a patched version that uses serial communication. Original TCLOGO.COM (ISA Board) or the patched TCLOGO_P.COM (Parallel IO Address) will not work. Because we cannot easily redirect any IO Ports address used in DOS... EDIT: For now, it is more a fun project as I do not intend to implement into Lego Blockly, the "Continuous BYTE WRITE/READ" protocol TCLOGO uses. It is a 1ms continous Write/read that allows to do some kind of software PWM which I doubt a WEB APP could achieve as it is not fast and deterministic enough.

@Toastie and others... I finally tested this route with a VERY cheap FT232RL breakout board. (NOT THE FT232H which is another project ;-) ) Please see the following post for the details of the pinout and pictures of this RED board and also how to set it up in big bang mode (Use Zadig to replace the OS driver by a generic usb driver) Don't forget to set the jumper to 5v. I asked Gemini to make a program to act as a software gateway between Serial traffic from TCLOGO_S and the FT232 board which utilise USB comm Bit Bang mode (Not serial COM). He first suggest a Node.JS code but I also asked for a python program as I already familiar with Python and the famous Thonny IDE. I STRONGLY SUGGEST to use THONNY to try it out as it is so easy for beginners like me. Thonny is available here: https://thonny.org/ Here are the easy steps: - Get com0com virtual com emulator: use the version 2.2.2.0 64 bit signed as the 3.0.0.0 does not work for me and for many people. (Windows 11). https://sourceforge.net/projects/com0com/files/com0com/2.2.2.0/com0com-2.2.2.0-x64-fre-signed.zip/download After installation completed, Lauch the setup for com0com and type over the proposed virtual port pair port names. While you type a port name, if the port is not avail, the text becomes red. I have choosen the port name COM12, COM13. Click Apply. You should have the following in the Device Manage: Modify you Dosbox-x.conf file: serial1 = directserial realport:COM12 Download the LegoGwy_FT232.py : https://github.com/BlissCA/lego-blockly/blob/dev/Misc/LegoGwy_FT232.py Open this python file in Thonny. Make sure Thonny has the pyserial and pyusb library. Go to Tool menu, Manage Plug-ins, in the search box enter pyserial and install if not already and do the same for pyusb. In the code window of thonny, search for "GATEWAY_PORT = " and change COM13 for the second port you configured in the pair in com0com earlier... Now in Thonny, you are ready to press the Green "Play" button ("Run Current Script"). If everything is setup correctly, it will print: >>> %Run LegoGwy_FT232.py FTDI Chip successfully locked into raw Bit-Bang Mode via Python! Gateway listening for DOSBox-X traffic on virtual COM13... Some outputs initialize to ON when we connect the FT232 to USB... Make sure you interface A is not powered on until the gwy is running properly and found the FT232. Running the python program succesfully resets the output to OFF... Now you can start Dosbox-x, Mount the Folder that has TCLOGO_S.COM from @alexGS: https://bricksafe.com/files/alexGSofNZ/interface-a-tc-logo/TCLOGO_S.COM Execute TCLOGO_S, and try it out... It is very fast, at least with LEDS ;-) I tried the Inputs 6, 7 too with a logo command WAITUNTIL [SENSOR?] ONFOR 20... (I previously ran the command TTO [0, 2, 4] and LTO 7...) I guess this will work with Legacy Lego Lines for DOS too... But this Lego Lines would also have to be patched to use COM port IO Address rather than Parallel/ISA IO Address... ALSO NOTE that this configuration DOES NOT allow the use of a BT adapteur (HC-05)...

Set your variables using TEXT values (found in the Text toolbox). No conversion needed... The Tag Hex Region returns Hex IDs as Text (String) not numbers. There is a tooltip if you leave your mouse on the block for a moment.

I also get this once in a while, but when I disconnect the toypad from USB and reconnect it to USB, then the Lego Blockly connect dialog show "LEGO READER V2.10"...

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