I was just reading about the Byte-Enable pins (BE3:0) and how to convert them to A0 and A1. (Note the address-bus doesn't actually output A1 and A0, it starts at A2!)

Took a few minutes to wrap my head around it, but soon thereafter it seemed intuitive if not cut-and-dried to me: each byte-enable represents a value on A0 and A1...

A1:0   BE3  BE2  BE1  BE0
0      0    0    0    1
1      0    0    1    0
2      0    1    0    0
3      1    0    0    0

(actually, BEn are active-low, 
 but this is easier to visualize)

BUT NO!!!!
Since it's designed for 32, 16, and 8-bit devices, there are cases where multiple BEs are active at the same time... somehow that hadn't occurred to me. So decoding is a bit more complex than I thought.

I'm staring at a table in the datasheet as we speak, and my brain's just not parsing it at the moment...

And then, on top of that, there's a new oddity I just discovered, the datasheet says the 386 used to expect all 8-bit reads/writes on D0-D7... This is what I'd expect, seeing as how an 8-bit device only has 8 data lines, where else would one wire them besides the first 8-bit data-lines of the processor...?

BUT the 486 actually reads different data-pins depending on which byte it's reading, even when reading an 8 (or 16) bit device! So even if an 8-bit device is connected, and even if it's indicated with /BS8, it has to have its 8-bits repeated on (or rerouted to) each byte of the data-bus: D0-7, D8-15, D16-23, and D24-31. WTF. Apparently the chipset usually handles fanning it out like that.

"The external system must contain buffers to enable the 486 to read and write data on the appropriate data bus pins" LOL.

OK, so, for my NOP experiment that basically means I have to wire up all 32 data bits, so I guess there's no particular reason to use /BS8 (except maybe to intentionally slow it down... hmm).

So this *definitely* would cause issues with the instructions actually being read as NOPs... I've got floating inputs!

That's not to say there aren't other reasons for oddities, so @Nicholas Amrich, and others, keep those ideas coming, and thanks!

There are a couple other things I hadn't considered in my *really simple* circuit...

The CLK signal is supposed to be applied only after the power is stable... This one is, plausibly, a bit unlikely to cause difficulties... the datasheet says something like "Prior to this datasheet, this was unspecified, so this is *best-practice* that will be guaranteed to work now and in future versions of x86 processors..." ish. So, realistically, it's entirely plausible most motherboards supply the clock as soon as it starts oscillating, just as I have.

And the reset thing, did I mention that before...? I think it would be wise to feed that through a shmitt-trigger and possibly a D-Flip-Flop...

-----------------

This is getting a bit more complicated than I intended... Really, I just wanted to see what I could do with the simplest circuitry possible (a clock and a few passives was all I'd intended. Notice it's dead-bugged!)

But, I am learning some stuff I never expected to, and it's kinda interesting, and some of it applies to other architectures as well... and, maybe, with what I've learned, and a little bit more, I could actually build a functional standard 486-based computer at the component-level...

Though, I'm also starting to look at it from the *what can be done* perspective... e.g. I'm thinking about having 4GB of directly-addressable/executable memory/IO at my fingertips... Also have some experience with SDRAM, and lots of DIMMs, lots of other memories to mess with... who knows. Kinda cool to have access to such a wide data/address bus at this low-level I already (mostly) understand. as opposed to, say, trying to design a PCI card... and being able to access it at this low-level I already (sorta) understand, as opposed to, say, trying to design a driver for an operating system.

It's kinda like the old "Wild West" computer-era when people built their own hardware, added RAM to their KayPros by soldering it atop the chips already there, and more... Except, significantly more powerful.

Again, not at all the direction I'd intended from the start, and quite a bit more in-depth than I'd intended... it may be some time before any of *that* happens, if it does... Heck, I dunno if I even have a breadboard big enough for the PGA, let alone other circuitry. (And, if I actually intend to go the route of something more than just a counter, or even that, it looks like I might need to be adding a voltage-monitor chip, flip-flop, schmitt-triggers, etc. Though, some of these things might prove to be handy "drop-in" tools to have around for other projects...)

This was just supposed to be an easy side-thing since my brain had turned to mush on my other projects...