I have a problem:
Anyone familiar with 386 LIF (Low Insertion Force) sockets knows that the trouble isn’t installing the processors—that indeed doesn’t require much force and is easy to do. The real problem is getting the processor out without bending the pins and/or damaging the ceramic package.
This got me wondering… surely it would be possible to build a ZIF (Zero Insertion Force) socket for the 132-pin PGA used on 386s, just like the larger sockets used for 486 processors? Is anyone familiar with such a thing?
Searching for a 386 ZIF socket wasn’t very fruitful. It is possible that Aries Electronics 32-PLS14016-12 is the right thing, but I’m not willing to invest almost 100 Euro just to try.
Just to be clear, I’m looking for an adapter that would plug into a traditional 386 LIF socket and provide a nice lever-operated ZIF socket. Something that would allow me to easily swap 386 chips without worrying about damaging them. Anyone seen such a beast?
And apropos of nothing, a gratuitous reader challenge: In the above photo, one of the chips is not like the others. That is to say, one of them would do no good in a 386 CPU socket. Which one is it? The full-size photo should be detailed enough.
Update: Just to be clear, the idea of a 386 ZIF socket is not something I made up. It’s mentioned in Intel’s own 386 datasheet. For example document number 231630-011, the Intel386™ DX datasheet. Search for ‘ZIF’ in the PDF to see a 386 ZIF socket presumably manufactured by AMP.
I am not sure if it is possible to find compatible PGA ZIF socket. It could be much easier to get an extractor like this one: http://www.aliexpress.com/item/Free-Shipping-IC-Extractor-PLCC-PGA-PCLL-DIP-IC-Removal-puller-tool/869968818.html
Since they’re (almost) all either Intel or AMD 386SX/DX chips, and the 486DLC were pin-compatible to the 386, I guess the culprit must be one of the two chips with the very small print (that I cannot make out).
Either that, or the one with the question-mark 😉
The Intel chip near the bottom right (which doesn’t say Intel but has the “i” logo) is a 82385 cache controller.
Also the two 486DLCs aren’t like the others as they are 486 chips which plug into a 386 socket.
Website note: if you respond on an attachment page it is separate from if you respond on the main article page.
Yep, that’s it 🙂 One of the “plain” chips is a 20 MHz 386, but the other is a cache controller. The 486DLCs are like the others in that they work in a 386 socket just fine. The cache controller on the other hand won’t.
I solved the pin-damaging problem… from a certain point of view. I bought LIF sockets just like the sockets on 386 mainboards. Then inserted each of my 386 chips on a LIF socket… and plugged the 386 + LIF socket “pair” on the mainboard LIF socket. As the LIF socket pins are much stronger than the 386 ones, it is much easier and safe to remove the 386 + LIF socket “pair” than the 386 alone.
As I intended to swap CPUs and mainboards to test different combinations, it solved my problem. But maybe it’s not a solution for a different purpose. Anyway, I would be happy to hear about a 386 ZIF socket. I used this later approach for 486 mainboards without socket 3, but it was much more expensive (1 socket 3 costs like 12 386 LIF sockets). LIF sockets for 387 were also easy to find.
IIRC on some datasheets (but please, don’t ask me which ones) it’s written the maximum number of times that you can extract an IC from the socket without risking to break the pins. Over that number there’s no warranty. I think it was ~30 times for a 386 or 486 on a LIF socket.
Yeah, and I don’t know how many times the pins of my 386s have already been bent 🙂
BTW see the article update for where the idea came from.
The cache controller!
Damn, dosfan beat me. I admit I was stumped at first. My eyes read the 80385 as a 6. Either my eyes or memory are failing me (maybe both today?). My initial inclination was “he must have one of those double sigma 16-bit only chips”.
If you ever do find one of those ZIF sockets, do let us know. I’d love to scoop up one. It’s a neat idea.
It’s actually 82385. At first sight it does look deceptively like 80386, especially when 80386 is what the brain expects to see 🙂
The double-sigma chips were actually the good ones, suitable for 32-bit use. See http://www.cpu-world.com/CPUs/80386/Intel-A80386-16.html
If that Aries Electronics 32-PLS14016-12 is actually in stock on that site I’d say you should ask them for pictures, otherwise set up some donation link and maybe enough of your readers would chip in.
Sorry for the double post, I found this a few minutes later:
http://www.arieselec.com/products/data/10004-pga-zif-test-and-burn-in-socket.htm
Yes, I looked at the datasheet and it looked like it might be the right thing.
Anyway, I was rather hoping that someone has already seen/used one of these 🙂
Hi Michal,
A while back you did some research on undocumented 8086 instructions, so maybe you can answer this question, or suggest a place where I can find an answer.
What does an 8086 or 8088 do with an instruction 0x8c or 0x8e (MOV segment register) that has bit 5 of the MODRM byte set? Recall that for these two instructions, bits 3-5 specify which segment register is the source/destination (depending on the instruction) of the move.
On an 80186 or later you get an illegal instruction exception if the segment register is out of range (0-3 on a 186 or 286, 0-5 on a 386 or later) but of course an 8086 has no such exception.
I’ll have to defer to Raul… he’s the one with an actual 8086.
The document at http://textfiles.com/programming/86bugs.lst sometimes has useful information, but apparently not in this case.
That’s a very interesting question, as I focused on the gaps in the opcode map, and not in the addressing scheme. Before I can test it, I would say that chances are that bit 5 is ignored. Just because it is the simplest option, any other one would have meant more work for engineers.
Probably, I will be able to test it this weekend. When I have the results I will write them on a comment in the undocumented opcodes article.
But I could make a quick test on a NEC V20 which was available near here and changing bit 5 from 0 to 1 doesn’t change the result. For example, 8EE0h executes as MOV ES,AX (like 8EC0h) and 8EF0h executes as MOV SS,AX (like 8ED0h). I expect the same behaviour on the 8086, not meaning that NEC copied Intel, only that it was the simplest option for both engineer teams. But maybe there’s a surprise.
Actually, NEC did copy the microcode, see e.g. http://jolt.law.harvard.edu/articles/pdf/v03/03HarvJLTech209.pdf 🙂 But of course NEC might have made changes, so checking a real 8086 is still needed.
I forgot to mention: SYMDEB also recognizes 8EE0h as MOV ES,AX and 8EF0h as MOV SS,AX (possibly because ignoring bit 5 was the simplest option for programmers, too.)
Pingback: 386 ZIF Socket Adapter | OS/2 Museum