also, abstract your communication transport. in C++ this is easy to do as an abstract base class, in Rust you would define a trait interface.
The bulk of your code should not know it is talking over USB.
Now if you ever want to talk to your microcontroller over TCP/IP you can implement a new transport and not have to rewrite absolutely everything.
these posts are directed at me, four years ago.
In my defense, splitting my debug messages out onto the serial UART made sense for #ArduinoX86 when I started that project because the Arduino MEGA I was using had no USB-CDC channel, it was all UART; so a second UART was a logical extension.
But now having a 115kbaud serial UART hanging off an Arduino Giga with a 480Mbps USB-CDC channel is a bit stupid.
This also means if I ever want to host #ArduinoX86's on the internet, I don't have to worry about providing a ton of USB ports; they can all just hang out on a special firewalled SSID, and sit on a shelf in my closet out of the way
I had both the 286 and 386 boards plugged in today to debug the protocol changes, and I got an especially stupid idea
I added support in the GUI to connect to two CPUs at the same time.
And then we can wire IO ports together, via mail slot ports. Two pairs of IO addresses indicate data and data-ready in both directions - like a virtual serial link.
So now the 386 can talk to the 286 and vice versa. What is the point of that? I don't know.
The multi-cpu support itself is useful since I want to implement support for a 'consensus' mode where I can execute the same code on say, two different steppings of 8088, and see how they may differ.
Differences in registers, flags, or cycle execution can be highlighted.
it still blows my mind that a i soldered a 138-pin 386EX to a PCB I slapped together in KiCad without any sort of engineering degree and it actually functions
actually I wonder if @MuseumJoe would be interested in carrying #ArduinoX86 boards.
The 8088/8086 board is completely passive and the software GUI is becoming quite mature. It has huge potential for use by educational institutions
The best thing about ditching the serial UART though - I get two 5v tolerant GPIO pins back.
This lets me hook up the PEREQ and /PEACK pins that implement the CPU<->FPU handshake. Capturing those pins in future FPU instruction tests isn't strictly necessary for emulation, but they will make the tests that much useful as an oracle of hardware behavior
@gloriouscow Yes?
@gloriouscow I mean, certainly. I can make them available for less than folks can get them in small batches on their own.
Not sure what the demand is, but I'm always amenable to a conversation.
@gloriouscow I know enough people with an engineering degree who completely unable to design a PCB.
You can get very far without an engineering degree by just following best practices. The engineering degree however might help you understand where they come from.
Nov 10, 2026, 10:32 PM@gloriouscow I’m sure Intel had a point when they glued two completely different CPU cores with different instruction set capabilities into a single socket *stares in Alder Lake*
@jpm that's pretty cursed
@gloriouscow Though if you do only have a UART handy, the popular UART<->USB dongles have reliably supported 1Mbps and 3Mbps operation for about a decade now, so there's definitely no need to limit yourself to 115kbps like it was the early 90s.
Nov 10, 2026, 9:40 PM@gloriouscow 8051 much?