8088 prefetch algorithm

[westveld]

Here's my design for a bus sniffer, such as it is so far. Be gentle, it's my first attempt to design an ISA card. Also since this is a piece of experimental apparatus rather than a piece of end-user hardware, I didn't spend much time making (e.g.) the routing beautiful.

hey, wait a minute! You're the "sending code to the PC via the keyboard port" guy ... you might be able to make it work

 

[reenigne]

I'm a bit confused about that design. It looks like you have 11 8:1 mux's.

13 actually. I was going to do it with 11 (I'm only actually sampling 85 signals) but the layout was easier with 13.

2 MHz * 2.5x for Nyquest since your not phase locked to the ISA clock

I am phase locked to the ISA clock - I'm using the external clock input and driving the microcontroller at 14.318MHz from the OSC signal, and I'm using an IBM 5160, where the CPU clock is derived from the OSC signal. With an unrolled loop in the microcontroller I think I should be able to capture and store bytes at 4.77MHz.

* 2 since you need to perform 2 sets of mux captures * 8 inputs on each mux = 160 MHz sampling rate. And conservatively if it took you 8 instructions assuming 1:1 clock/instruction rate to change mux inputs, and perform the reads, you would need an AVR8 running at ~1.3 GHz.

Which is why I'm not going to try to capture everything at once. It's a deterministic system, so I can run the same piece of 8088 code over and over again and (hopefully!) get the same results. The idea is to capture 2K bytes (the amount of RAM in the microcontroller) of signals, send them over the serial port and then change the multiplexer select bits and run the same experiment again. We'll do each experiment at least 16 times (2 sets of multiplexers * 8 channels) to capture everything. Possibly even 48 for some experiments, so that I can change the phase of the sampling clock with respect to the the bus clock and have an effective sample rate of 14.318MHz so that I can see when everything changes.

It's a bit of a hack, but I think I should be able to make it work.

hey, wait a minute! You're the "sending code to the PC via the keyboard port" guy ... you might be able to make it work

Hehe - my reputation preceeds me!

 

[eeguru]

I don't want to discourage you from experimenting. However I'm not sure how useful or successful this design will be. You might be able to sample a specific set of 8 traces every other bus clock starting and ending at some random point in time. You definitely can't do every clock in only three cycles/instructions. And you need to know when to stop sampling and 6 instructions isn't enough to keep a counter and sample. So you'll have to rely on both external interrupt stop and start triggers. And you might have to do a lot of deductive analysis on the back end to infer what happened to the missing samples. If you miss an address latch cycle, you also miss the address. It's just not going to be useful. I've done ISA bus sniffing as well with a OBLS and that is way more useful than what you are proposing. They use an FPGA. If you really want to take this to the next level, start by understanding that design and extend it to buffer through a off-chip memory and improve the PC transfer on the backend using one of the three devices I proposed as a starting point.

Heck you could even chain 3 OBLS together and cascade the triggers to get a full view of the ISA bus for 6K samples with full programmable trigger conditions. That might also be cheaper than what you are proposing.

Edit: The only prayer of making 3 cycles is to fully unroll all 2k iterations in flash including the specific immediates for setting up where the samples are to be stored in RAM. Even then, I'm not well versed enough in AVR8 assembly to know if 3 is doable.

 

[reenigne]

Edit: The only prayer of making 3 cycles is to fully unroll all 2k iterations in flash including the specific immediates for setting up where the samples are to be stored in RAM. Even then, I'm not well versed enough in AVR8 assembly to know if 3 is doable.

AVR8 has an indirect store with post-increment instruction, so the unrolled loop would just be 2048 (or so - not sure how many RAM locations I'll need to use for other things yet) instances of:

  IN r0, PIND  ; 1 cycle
  ST Z+, r0    ; 2 cycles

And the same again for PINC. These sequences will take 16Kb out of the 32Kb of flash available - the remaining 16Kb will be plenty for the rest of the program.

I'm planning to have A19 trigger an interrupt on the microcontroller when it's in the idle state, so whenever the 8088 reads or writes to addresses 0x80000-0xfffff it'll trigger that interrupt. The microcontroller will then read some of the other address lines to figure out what command the 8088 is giving it. That means I'll have to keep the relevant address lines consistent for several 8088 cycles. I can do this by running a string of NOPs from a particular part of the 8088's RAM, and disabling DRAM refresh. I think if I run a string of 256 NOPs at (say) addresses 0x80000-0x800ff then address lines A19-A8 will be 100000000000 over that period of time, so I can just do a "CALL 0x8000:0" to send that command to the microcontroller. Then have similar strings at several other addresses to be able to send different commands. I only really need three different commands: "reset the microcontroller to a known state", "send a 0" and "send a 1", and then by sending a sequence of these I'll be able to configure the microcontroller to set its multiplexer bits differently, decide which port to use, how many cycles to wait before starting the sampling and how many cycles to sample for.

 

[eeguru]

Of course any access to a BIOS interrupt or video RAM would disturb the sequence. I understand it would be for a very specific use case you have in mind for your own code so that can be controlled. I just don't understand the effort to achieve the result you want over picking up a $50 OBLS like westveld suggests.

Even the design I've worked through on paper that I've wanted to build for a while captures every single bus access and sends it to a PC for monitoring in real-time. And I'm pretty sure there might only be only one or two people a year that would use that. So it was a little hard to justify building.

Keep hacking though. It's what makes all this great. Should probably start a separate thread though. Kinda hijacking this one.

 

[reenigne]

Should probably start a separate thread though. Kinda hijacking this one.

Good thinking - I made another thread about my sniffer. I'll post the results on this thread once I have some.