I'm seeking a collaborator with extensive knowledge of IEEE-754 floating point math to help me devise an Intel FPU test suite for emulator authors.

My previous test suites for x86 CPUs including the 8088, 8086, V20, 286 and 386 have been used by dozens of emulator authors to date. You would be participating in producing an invaluable technical resource that will help preserve the accuracy of emulation for decades to come.

It would be nice if you used Discord for ease of collaboration, but you're averse to that we can work around it.

Give me a private mention if interested.

Boosts for visibility appreciated.

#retrocomputing #vintagecomputing #reverseengineering #emulation

you know i didn't even check to see what was installed in my AT

Be sure to read the installation manual

anyway I didn't own an AMD 80c287 but now i do

no wonder Intel partnered with Harris for the 80c286 design considering they were suing AMD at the same time. That would have been an awkward date.

It sounds like Intel thought they were just giving AMD a license to the microcode that they had written to that point, but accidentally gave them a perpetual microcode license which allowed them to continue legally reverse-engineering every Intel chip.

It's crazy to think about the fact that AMD probably only exists today because Intel's lawyers were high on cocaine and couldn't write a proper contract

Like why is it even a question whether their agreement covered the 287. why didn't they spell out exactly what it covered.

they just gave a license to AMD for "Intel Microcodes" and just left that hanging there. what does that mean?

I am not even a lawyer and I realize how stupid that was

https://ir.amd.com/financial-information/sec-filings/content/0000950130-94-000448/0000950130-94-000448.pdf

What amazes me is how many lawsuits there were over the terms of Intel's technology sharing agreements with other companies.

... did they just have really shitty lawyers? Why were the terms so ambiguous that it led to a decade of court battles?

Who needs Intel chips though really? AMD has our back.

Intel sued AMD over this chip too. But what didn't Intel sue AMD for?

So about that 80287XL chip.

bummer! It's not going to play nice with single stepping.

So the AMD 80c287 it is.

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

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

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

Differences in registers, flags, or cycle execution can be highlighted.

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.

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.

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

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.

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.

Having learned the hard way from several microcontroller projects, if you're going to talk to a microcontroller, packetize your communication protocol. Give yourself a message type field, flags, message id, and packet length, and then read whatever out of that.

then, when you are struggling to debug something, you can easily extend your protocol with in-band debug messages that can be discriminated from normal control traffic.

the overhead is really minimal.

#embedded