UPDATE: Re: Project "Reveal" and realistic goals in the following few paragraphs...

------

This should've been two separate project-logs... The "secret-reveal" was supposed to be a minor bit merely as lead-up to the current state-of-things (interfacing with the bus).

-------

In case you haven't figured out "the secret" of this project... the idea is to use an AVR to emulate an 8088 *in circuit*... To pop out the original 8088 in my (finally-functioning) PC/XT clone, and pop-in my AVR, and see what the blasted thing's capable of.

A key observation, here, is that AVRs run at roughly 1 instruction per clock-cycle, while 8088's can take *dozens* of clock-cycles for a single instruction. I read somewhere that the 4.7MHz 8088 in a PC/XT runs at something like 500*K*IPS. Whereas, an AVR running at 20MHz would run at something like 20MIPS! FOURTY TIMES as many instructions-per-second!

(albeit, simpler instructions, only 8-bit, and I imagine much of the limitation of an 8088 is the fact it's got to fetch instructions from external memory at a rate of 1/4 Byte per clock-cycle... which of course an AVR wouldn't be immune to, either.)

Anyways, I think it's plausible an AVR could emulate an 8088 *chip* at comparable speed to the original CPU. (Yahknow, as in, taking minutes, rather than hours, to boot DOS). Maybe even play BlockOut! (3D Tetris).

But those are *Long Term* goals, and it's entirely likely I'll lose steam before even implementing the majority of the instruction-set. For now, I intend to pull out the BIOS ROM, and replace it with a custom "program" using an *extremely* reduced instruction-set...

First goal is to output "Hello World" via the RS-232 port... I think that wouldn't take much more than a "jump" and a bunch of "out"s... so should be doable, even by the likes of me.

...And, maybe, just maybe, I could fit that and the reduced "emulator" in less than 1K of total program-memory on the two systems (and not making use of other ROM sources such as LUTs for character-drawing on the CGA card)... A bit ridiculous, there's only a few days left for the https://hackaday.io/contest/18215-the-1kb-challenge, and I haven't even decided on which AVR to use....

(Regardless of the contest, it's an interesting challenge to try to keep this as compact as possible. You can probably see from the previous logs I've already been trying to figure out how to minimize the code-space requirements for *parsing* instructions... *executing* them is still a *long* ways off ;)

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

I was planning to use my trusty Atmega8515, since I've a few in stock...

I think it has *exactly* as many I/O pins as I need...

But... it gets complicated because:

The 8088 clock runs at 4.77MHz, this is derived from a crystal running at
14.318MHz (divided by 3), but that signal's not available at the processor.

8-bit AVR clocks generally max-out around 16-20MHz (but can be overclocked
a little, and sometimes even quite a bit).

The 8515 is rated for 16MHz. And, worse for this project, its internal (and
*calibratable*) clock is limited to somewhere around 8MHz.

So, let's say I could bump that up to 4.77*2=9.54MHz via the OSCCAL
(oscillator calibration) register... That means I'd only be able to execute
*two* instructions between each of the 8088's clock-cycles.

And, seeing as how the AVR is only an 8-bit processor, there's no way it'd
come close to the 8088's bus-timing, what with needing to write 20 bits in
a single 8088 cycle (A19:16, A15:8, A7:0, at the beginning of T1).

In my initial estimates, I was planning on having 4 AVR clock-cycles for
every 8088 clock-cycle. That's not far-fetched... 19.09MHz. (Again,
most AVRs these days are rated for 20MHz, and the 8515-16MHz could probably
handle 19MHz). Doable, but I'd need an external clock for the 8515, and
somehow would need to calibrate it to closely-match the 8088's (which, too,
can be adjusted via a variable-capacitor).

-------------
I also have a couple ATmega644's, MUCH more sophisticated, in general, than the 8515, (mostly due to increased memory, but also a few additional instructions) but these guys have a similar internal clock, and fewer I/O pins...
-------------

I have a bunch of ATtiny861's... These guys have an internal R/C
(calibratable) oscillator that runs at ~8MHz, as well.

BUT, it can be bumped-up to a higher system-frequency with the internal PLL.

So, I've some vague theory that if I take the 8088's 4.77MHz clock and feed
it into a Timer Input-Capture pin... I might just be able to create ....

Can the PLL be configured to sync with an external clock?

(Update: NOPE)

The thought is... using the Timer's Input-Capture pin, I could write a
little routine that runs at Power-Up, that adjusts OSCCAL to match the 8088's
clock, except at a higher multiple... e.g. 4x (19.1MHz), or maybe even 5x
(23.9MHz).

And then... I'd be able to execute 4 or 5 AVR instructions per every 8088
clock-cycle... which should be *just* enough to handle writing *all the*
address-bytes in a single bus-clock. (NOT within the 8088 timing-specs of
something like 100ns from the clock-edge to the 20-bit address-output, but
we'll see where that goes. I should probably look into the 8288 and other
"slave"-devices' expectations, since they're what really matter).

.......
Thing is, the Tiny861 only has TWO 8-bit ports, and no other pins for I/O.
(Trying to do the work of a 40pin 16-bit CPU with a 20-pin 8-bit microcontroller!)
You can see from the above diagram, for bus-interfacing alone, I need
18 outputs (A19:16, A15:8, /S2:0, QS1:0 and /RD) *as well as* 8
I/Os (AD7:0) (which I'll come back to later).

-----------
Say for those 18 outputs I use 3 8-bit latches such as the 74AC574's in my
collection. Those latch on the rising-edge of their clock-input.
Alrighty... Something like:

Here's a single bit routed to two latches:

This would take 3 AVR clock-cycles to write each byte-wide latch. (Write-Data to Latch-Inputs, Strobe-high, Strobe-Low).

Short of pins, the strobe inputs could be reduced via demuxing:

Now I can handle four bytes with only 3 additional GPIOs.

This might take an additional AVR clock-cycle to write a byte-wide latch. (Select, Write-Data, Strobe-high, Strobe-Low).

But we got here because this system's already too slow! It was already too slow when I could write each byte-wide port on the original 8515 with a single instruction! (Three address-bytes, three ports, three AVR-instructions, needed to fit within one 8088 bus-clock).

So, these muxing-schemes would make the system *even slower*. No good.

The Tiny861 has an optional clock-output that matches its internal clock...
And Tiny861 outputs are toggled on the rising-edge of the internal
clock. What if I use that output-clock as the "strobe" for my latches?
Then I wouldn't need a GPIO to toggle twice for each latch operation, reducing the latch-write-instruction-count to 2 (select, write).

(This may introduce a glitch between select/write, but that can be dealt-with).

And I reduce the GPIO-usage by one pin.

But, we'd have the same problem... I'd first have to select which latch,
then write the 8-bits of data... 6 instructions to write three bytes.
(select, write, repeat, repeat), and still only 4, maybe 5 instructions can fit within an 8088 bus-clock.

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

Ignoring AD7:0, for now, I need 18 outputs to transition during a single bus-clock...

And 18/3 just happens to be 6...
So, if I only used 6 of the 8 latches in each chip, and only wrote 6 bits
each time, I'd have two remaining pins on the AVR's 8-bit port.

Two pins which could be fed into the select-inputs of a 1-in-4-out demux,
for instance! (Random luck, here!)

AND, Importantly, those two pins, on the same port, would be written at the same time as the 6 address-bits-to-be-latched, so only *one* instruction must be executed to both *select* a latch *and write* data to it!

Now, I haven't *fully* wrapped my head around this, yet... It might be
necessary to insert some delays between the AVR's Clock-Output and the
demux's input, such that the data arrives at the latches' inputs *just
before* the clock-output reaches the selected latch's clock-input. But I
think that can be handled with little more than a few gates inserted for
the sake of adding a delay. OR, maybe... inserting a (fast) inverter
inbetween, so the latches' inputs are loaded with data on the rising-edge
of the AVR clock, but the latches are clocked on the following (inverted)
falling-edge of the AVR-clock.

Should be doable.

AND, amazingly, will take *exactly* the same number of AVR
instruction-cycles to write these three external latches as it would've to write
3 dedicated I/O ports (on a chip which has that many).
(Of course, a little preprocessing would have to be done, to merge the data
and select info. But, the actual writing of the three latches will take
exactly 3 instruction-cycles. And that's what's important, here... that the
changes all occur within a single 8088 bus cycle).

=====================

I wrote a program to calculate the possibilities for future-endeavors:

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

TODOs:

For the I/O byte (AD7:0), I'll use the fourth output from the demux. I've some ideas regarding that, including some that've been well-thought-out in #sdramThingZero - 133MS/s 32-bit Logic Analyzer, making use of resistors as data-paths (and virtual "open-circuits") without necessitating additional Output-Enable or Direction signals (which would have to be driven by GPIOs). I'll come back to that later.

So, assuming I run my AVR (Tiny861?) at 4x the 8088's bus-clock, we'll *just* fit in all the necessary transitions. With QS1:0 changing midway, that might add a 5th transition (5x clock is pushing it, but plausible).

The 8088 timing specifications show those transitions happening within a very short time-period... E.G. ALL the address-bits (20!) are supposed to be written within 100ns of the bus-clock's edge. Again, doubtful an 8-bit AVR could handle all that in 100ns. But I've some ideas for how to make it work if it really needs to be *that* precise. Good thing I ordered so many 74AC574's!