8086 uP Require

Yes.

Pretty much. IBM used the 8088 (later than the 8086) mainly to save connectors.

That was no issue at the time. The alternative was the 8085. I'm sure that would have mane many happy! ;-)

The fence isn't what you think it was. Motorola wasn't in the running.

--
  Keith

yeah, but which vax? I'd expect more performance from your setup than from an than an 11/760.

--

Bye.
   Jasen

Actually that was only the IBM PC, they used a 5 MHZ part and derived the microprocessor clock from the same crystal that was used to generate NTSC video clocking, thus the weird 4.77. Same way with the 640k vs 1M, a PC-ism. Of course, 8088 and 8086 boxes that weren't really IBM compatible didn't fare too well in the marketplace, so ...

An 8088 is perfectly useless in an app that calls for an 8086. The core is the same, but the 8086 has an actual 16-bit data bus, where the 8088 has only an 8 bit bus, and doubles up on memory/peripheral access. I've read somewhere that the reason they did this is because existing peripheral devices were all 8 bits, and a 16-bit wide RAM costs twice as much as

8-bit.

I wonder why the OP wants a "vintage" model. Something to do with rev. level?

Thanks, Rich

My origrinal request states why I need an 8086.

WayneL

Hi

Could anyone help us find an old very early 8086 uP for our University's SEM? It is a very old unit be our Scanning Electron uScope will not operate untill we find one. I think the speed is either 1 or 4MHz. It is imprtant we get one of the earliest version.

Thanks

WayneL

You need an NMOS 8086 in its standard 40-pin DIP package. It's maximum speed capability should not be important; any of them can be run more slowly, so an 8086-2 should work.

Alternate brands to Intel, such as Kryten's Fujitsu parts, should also work well, they were meant to be replacements.

Yo'all should have easily gotten one by now, is your party at the University still looking for one? Shall we bring out one of s.e.d.'s big guns for you? {smile}

Or, is it possible the failure has been mis-diagnosed, and it's not the microprocessor? A common problem in very old instruments is that the PROMs fail, so the program crashes. Many types of old PROMs only had 10-year lifetime ratings.

A maintenance safety procedure for an old valuable machine is to read and store away copies of all the working PROMs, before they fail. :-)

A smart thing to add to a micro's code is a CRCC check of the entire code very early in the bootup, so a "program started, and ROM code OK" LED can be turned on. This can save a lot grief in maintenance debugging, when the machine is otherwise just sitting there, apparently doing nothing after applying power.

--
 Thanks,
    - Win

Hi Win

We have tried the 8086-2 and it works but the monitor rolls. When we tried an 8086-1 (or there abouts) from another University it works fine. So we are sure we need an 8086-1. One of the people from this group sent me a 8086-2 but it did not work. So if your offer is open to send a 8086 then we would greatly appreciate it.

WayneL

I wonder if there's a difference in the execution time of some of the instructions, and your instrument has critical software timing associated with generating the display. Software timing is simple and was popular for a time in the early days before programmers realized what a mistake it was. The IBM PC had from the beginning Timer0, running at 1.19MHz, which could be checked anytime, adding hardware certainty to software timing tasks, despite changes in CPU clock rates or instruction-execution time.

I don't have one to send, but I may be able to help you get one.

--
 Thanks,
    - Win

OK, here's what I've found out so far. First, I looked at our old ICs, and sorry, no 8086s.

I have in front of me my old Intel databooks. First, a huge book called The 8086 Family User's Manual, dated October 1979. This book covers the 8086 in great detail, but doesn't mention a -1 version. Second, the Intel Component Data Catalog, dated 1981. Aha, here they cover the 8086, 8086-1 and 8086-2 on the same datasheet. What this reveals is that they're the same IC but with different speed grading during inspection. They all have the same minimum clock speed, 2MHz. The 8086 has a 5MHz maximum, the 8086-2 has an 8MHz max, and the 8086-1 is tested for up to 10MHz maximum. That's right, the -1 version was later than the -2 version.

My third book is the Intel iAPX 86/88 User's Manual, dated 1985. This book shows the 8086, 8086-2 and 8086-1, but nothing faster. Since by 1985 Intel was starting to make other more powerful ICs, it seems they didn't go fooling with instruction execution times or anything else for their basic 8086 processor.

So that's all there is to it, and it appears any 8086 processor IC version that doesn't crash should work fine in your machine. I'd guess that the 8080-1 parts should work fine as well, even at 10MHz. I'd also say that newest 8086 ICs you find should have the best chance of working at higher clock rates. Second- source 8086 chips should be even better.

OK, that's it, over to you Wayne, for comments.

--
 Thanks,
    - Win

Further to the story. I have now read the datasheets of three second-source 8086-1 ICs, by AMD, Siemens and Fujitsu. I've also read datasheets dated through 1995 for all four manufacturers. The parts offered by the four are just the three original Intel versions listed above, despite the years of fab development and the likely obvious improvements in performance of the real parts. I'd venture to say that any of the three versions, from any of the four manufacturers, if made after say 1985 or so, should in fact run just fine at 10MHz, or above.

I'd also include the CMOS versions, the 80C86, made by Intersil, (also called Harris), OKI and Intel. These became quite popular and there's extensive inventory available in the aftermarket. OKI explicitly rated their msm80C86A-10 version at 10MHz.

As for finding exact ancient 8086-1 marked parts, I have located some and asked for quotes. We'll see what they say. But in the meantime, I'd continue to try in your machine whatever 8086 ICs you get your hands on, whatever the label.

--
 Thanks,
    - Win

Hmm, if it is a speed issue - and it looks like it is - then you might be able to compensate for the slower CPU by using faster RAM. I have lots of

32Kx8 SRAM chips from Pentium caches, rated at 15 ns. That ought to be fast enough for an antique 8086.

I understand that most everyone is enamored to high clockosis, but OP made it clear that is had to operate at original equipment clock speed. Just the same it is nice to see that it is still available.

--
JosephKK

I beg your pardon ! You reckon a 10MHz cpu needs 15ns RAM ?

What a funny idea.

Graham

Funnier yet is that he seems to think faster RAM will 'compensate' for the slower processor. Not on any slow bug I'VE ever used. I think he may think there are wait states thrown in for 'slow' RAM that can now be avoided. Good luck on that one. GG

Would be interesting to know more about the rolling. Horizontal or vertical? How fast? Can you put a scope on the synch signals and see if they are off frequency, and if so by how much?

Any idea what the monitor driver architecture is?

Can a hold control be adjusted to get the monitor to lock, even at the wrong frequency?

It just seems like an odd failure mode...

No, I just said I'd got some that fast, and that it might be something he could try.

It sounds like he is trying to run an 8 MHz rated part at 10 MHz. If the CPU is slower to set up address lines then this shortens the address valid time, perhaps to less than the memory permits. Hence if the memory was faster, it might be able to deliver the data in the shorter valid address time.

Of course if the CPU cannot run at 10 MHz then the memory speed don't enter into it.

The CPUs he tries seem to be running programs fine, it's the display screen he's complaining about. But I think your intuition might be right on target, with respect to the shortened timing requirements. It's not necessarily access speed, since that was pretty relaxed for the 8086 family. My concern was with the data bus hold-time issue.

. CLK ___ ___ ___ ___ ___ ___ . ___/ \____/ \____/ \____/ \____/ \____/ \__ . ________ ___________________________________ . ---X________X___________________________________X--- . ADDRESS DATA OUT | . TWHDX . ________________ |___________ . WR* \________________________________/

I'm thinking that the TWHDX data-hold time, which can be as short as 20 to 40ns for the 8086-1, can get designs into trouble. Look at the time scales here. Faster memory might get them out of this trouble. Of course, the new fast memory may not be pin compatible. Life is not easy.

--
 Thanks,
    - Win

Unlike some of the right-wing advocates here on s.e.d., I'm not one to see things in black and white. While faster ram memory might help solve WayneL's problem, it's also possible slower memory might be the solution. That's because some slow memory ICs will store the data-bus contents 50's of nanoseconds before the end of the WR* strobe pulse. Slow memory tends to have a longer data-change setup time. In some designs, slow RAM available when the design was tested might have led to an unworthy confidence. Later on, new, faster RAM can destroy the design's safety margins, and render late production a fragile product. As in so many issues, the precise details determine the exact answer.

Modern designs could potentially suffer from these same issues, but many employ a power solution, that wasn't available in the old days.

--
 Thanks,
    - Win

It would be great if it would solve his problem!

--
 Thanks,
    - Win