OK. I see what you are doing now. The question marks ??? probably go to pins on the QFP144. To determine what the group of ??? pins are, you could map all direct PGA132-to-QFP144 pins. The pin designations without direct mappins, and minus the assignments you already found for the PAL and NOR, would likely be the ??? mark designations.

feipoa wrote:

OK. I see what you are doing now. The question marks ??? probably go to pins on the QFP144.

That would make sense... though on initial mapping... I briefly brushed the tip of the wire cutting over the QFP pins whilst probing pins underneath... didn't get any beeps. More extensive mapping may change that.

feipoa wrote:

To determine what the group of ??? pins are, you could map all direct PGA132-to-QFP144 pins. The pin designations without direct mappins, and minus the assignments you already found for the PAL and NOR, would likely be the ??? mark designations.

Though this method would not link what function goes to each "???" pin.

The best way would be to map all the remaining "???" pins (around 15 left)... then whatever remains assume to be directly linked...

... rather than map directly nearly 100 pins and not know to which functions go to the remaining 15 "???" pins.

Ultimately, is any of this any use to you? What is your plan should all the pins be mapped?

I'm curious...

What are the main differences of the PGA-168 to the QFP-144?

What are the 24 missing pins used for and are they important?

The way i'm looking at it is there's two step downs...

1st) 168 pins to 144 pins (requires additional logic?)

then

2nd) 144 pins to 132 pins (requires PALCE & triple 3-input NOR)

According to the manual, the QFP-144 and PGA-168 versions should be identical in pinouts, with one exception: the QFP-144 has a second W/R# input. The manual mentions the two W/R# pins must be connected together , then says that, "these devices are functionally the same". Refer to page 1-15. The extra pins on the PGA-168 (compared to QFP-144) are 19 extra N/C (no connection) pins, two extra Vcc pins, and 7 extra Vss (GND) pins.

The pin assignments for the NOR gate can be useful for me because this is something I can implement on my board. Unfortunately, for the PAL device, I would need the microcode on it to be able to add this to my module. But it would still be nice to know which pins your module is interrupting and see if I can make sense out of why.

For me, the one-to-one direct mapping is important. I am hoping that there are some pins not connected, which I'd like to copy on my design. Or maybe they have sent some of these pins to Vcc or Vss directly?

What does your module do with Vcc5? It is pin 47 on the QFP-144. Vcc5 is not found on the PGA-132 chip. Do they have it wired to 5 V, or to the voltage output of BB1117? What is the voltage output of BB1117? Are they running it at 3.3, 3.45, or 3.6 V? What are they doing with FLT#? FLT# is not found on the PGA-132 version. MEMW# is another pin not on the PGA-132 version. Where does this pin go? As noted in the OP, these are the only pin differences between the PGA-132 and PGA-168.

My hope is that the PAL is used mainly for hardware L1 cache flushing, or synchronisation with the L2 cache, which I do not need on my motherboards. It would be lucky if the magic resides in the NOR gate, however some of those ??? marks on the NOR gate may go to the PAL. Were you able to check this?

Because the 5 V SXL2-50 works fine on my motherboards, I should, in theory, not need any of the additional logic provided by the NOR and PAL circuits on your module. I'm thinking there is something simple that I'm missing, which is why a direct mapping is of interest for me, as well as determining if any of the non-Vcc and non-Vss pins on the QFP144 are connected to Vcc or Vss (GND).

I don't mean to be a doom and gloom'er though I think the PAL is more than just cache control. Two of the PAL functions that I've mapped: -

1) READY (communicates directly with chipset)

2) R/W (instruction to read/write to address lines)

... are essential for a 386. Without these, it may be game off. The PAL is more important than we believe. It may be worth your while spending time with the datasheet I posted and try to better understand it. The NOR gate has no control functions so far.... only address lines. Already with the PAL... we have 3 control functions. My advice is get to know the PAL... this is key.

Regarding the BB1117, how do I measure the volts when the CPU is in the socket? To measure QFP pins while powered on is risky... any bridging on neighbouring pins, could mess up the QFP! The QFP does have 3.6V printed on it, you know?

All Vcc lines on the PGA are linked i.e. all 5v. All Vcc lines on the QFP I would imagine also to be linked, but instead 3.6V as it is a 3.6V rated CPU. Vss will be the same for all.

I don't know what are FLT#, MEMW#... if they are not on the PGA-132 then I will be limited on these.... they are on the PGA-168 you say?

The PAL is probably essential for some older motherboards, which is why it is added on the module - to be more cross-platform compatible, particularly on boards which are not L1 cache aware. The TI 486SXL2 PGA132 is the same chip as your TI 486SXL2 QFP144, except that it runs at 5 V as opposed to 3.3-3.6 V. It makes sense that your PAL is interfacing with control pins, probably to hold the CPU while the cache is being updated/flushed on motherboards which are not L1 aware. When using the PAL on boards which are L1 aware is just redundancy. This is my theory. How do you explain why the PGA132 SXL2 works on my system and the PGA168 does not? They are the same chips, running at a different voltage. At least this is what the reference manual says. The caveat would be if TI changed something which is undocumented on the 66 MHz version of the chip.

You cannot get to know the PAL without the microcode. It is a programmable logic device. If you don't have a copy of the software which is written to the PAL, then how do you get to know the software?

The less risky way to measure the actual voltage would be to solder a 30 AWG wire to the BB1117 and bring the wire out between the PGA pins to your voltmeter. Or if you are feeling on top of the world, you'd touch the QFP with a strand of thin wire while activated. If you aren't comfortable with any of these, I do not recommend doing it. Whether it runs at 3.3, 3.45, 3.6, or 3.65 V is not all that important. I can vary these on my module with a turn of the trimmer. I was just curious if the maker of the module may have found that 3.6 V too high, or too low and decided to run the unit at more/less voltage.

Vcc5 is different than Vcc. It is a special pin on the QFP and PGA168 modules, which is really strange. Under some conditions, the manual request 5 V coming to Vcc5, while all other Vcc pins are 3.6 V.

If I had your module in front of me, I would probably mount it in a third hand vertically, this way I could probe the QFP-144 side, and the PGA-132 side simultaneously.

FLT# should be the "float" pin. This pin was defined by Intel on the 386SX C-stepping (and later) as a way to disable the surface mounted CPU when an upgrade module is installed. This is how clip-on CPUs like the Cyrix 486SRx2 are able to work.
I'm not sure if the 132-pin QFP version of the 386DX also had FLT# (no upgrades were ever designed for systems with these CPUs), and it's not entirely clear to me why the 144-pin 486SXL2 would need it, being the only 144pin QFP x86 CPU that I am aware of. You can probably just ignore it.

Anonymous Coward wrote:

FLT# should be the "float" pin. This pin was defined by Intel on the 386SX C-stepping (and later) as a way to disable the surface mounted CPU when an upgrade module is installed. This is how clip-on CPUs like the Cyrix 486SRx2 are able to work.
I'm not sure if the 132-pin QFP version of the 386DX also had FLT# (no upgrades were ever designed for systems with these CPUs), and it's not entirely clear to me why the 144-pin 486SXL2 would need it, being the only 144pin QFP x86 CPU that I am aware of. You can probably just ignore it.

Ah ok, I've been looking for this function / pin... and is something I was going to get around to investigating when I had finished a couple of other ongoing projects (there are many!).

I was looking at possibly fabricating a module from scratch; a 132-pin PGA to QFP converter... that can be used on 386 motherboards that have no socket but only a surface mounted QFP. Essentially converting the surface mounted QFP into a socket.... like the clip on modules.

I know there was a pin which provided this function but did not realise it's name.... so far I've conceptually drawn by hand external circuitry which caters on two scenarios... which depends if this pin is held high at Vcc or pulled down low to Vss.

Though what it would be doing on a SXL2-66 beats me.

feipoa wrote:

The PAL is probably essential for some older motherboards, which is why it is added on the module - to be more cross-platform co […]
Show full quote

The PAL is probably essential for some older motherboards, which is why it is added on the module - to be more cross-platform compatible, particularly on boards which are not L1 cache aware. The TI 486SXL2 PGA132 is the same chip as your TI 486SXL2 QFP144, except that it runs at 5 V as opposed to 3.3-3.6 V. It makes sense that your PAL is interfacing with control pins, probably to hold the CPU while the cache is being updated/flushed on motherboards which are not L1 aware. When using the PAL on boards which are L1 aware is just redundancy. This is my theory. How do you explain why the PGA132 SXL2 works on my system and the PGA168 does not? They are the same chips, running at a different voltage. At least this is what the reference manual says. The caveat would be if TI changed something which is undocumented on the 66 MHz version of the chip.

You cannot get to know the PAL without the microcode. It is a programmable logic device. If you don't have a copy of the software which is written to the PAL, then how do you get to know the software?

Vcc5 is different than Vcc. It is a special pin on the QFP and PGA168 modules, which is really strange. Under some conditions, the manual request 5 V coming to Vcc5, while all other Vcc pins are 3.6 V.

If I had your module in front of me, I would probably mount it in a third hand vertically, this way I could probe the QFP-144 side, and the PGA-132 side simultaneously.

I think I see what you're sayin.... the PAL holds off normal 386 operation... almost like adding wait states while it writes/reads L1 QFP cache? My initial thought were that every standard 5v 386 CPU, even without L1 cache uses READY and R/W. Intel's DX33 has it... as does AMD's DX40.... and with neither of those having L1 cache that it would be used for control logic for transfers ISA bus, DRAM, and SRAM cache etc via the chipset.

Even without knowing the microcode... we get a better idea of what is going on by looking at the inputs and look at the outputs. The datasheet shows what pins are inputs and what are outputs.

Interesting to know of this Vcc5, I'm away travelling with work right now but when I get home I'll have a look and see where it goes. It may be that it leads to BB1117... which can be checked by simple continuity test rather than testing the device while active.

Third hands / hands free is what I am using... but it is easier typed than done.... believe me.

feipoa wrote:

FLT#, which can be left floating as it contains a built-in pull-up resistor... I also tried setting FLT# to ground at startup and also to set FLT# to GND after power-up, but the result was the same. FLT# is for floating the bus signal.

What does your module do with FLT# ? I suspect it is left unconnected. But if for some reason the 66 Mhz versions did not connect this pin to a pull-up, that it might be left floating, hence enabled! Maybe I should try connecting it to Vcc (although I sort of recall trying this already).

386_junkie wrote:

I don't think you understand my meaning.... every standard 5v 386 CPU, even without L1 cache uses READY and R/W. Intel's DX33 has it... as does AMD's DX40.... and neither of those have L1 cache. It will be used as control logic for transfers ISA bus, DRAM, and SRAM cache etc via the chipset.

Unfortunately, I still don't quite follow your train of thought. Why do you think the QFP144 version of the SXL2 needs to have READY# and R/W# interrupted, while the PGA132 version does not? The CPUs should be the same inasmuch as these pins and functions are concerned. It was my understanding that pins are often interrupted like this with logic devices to increase compatibility (e.g. cache coherency) with older motherboards. I have already noted that my motherboard works with uninterrupted READY# and R/W# signals with the SXL2 PGA132.

386_junkie wrote:

Even without knowing the microcode... All you need to do to get a good idea of what is going on is look at your inputs and look at your outputs. The datasheet shows what pins are inputs and what are outputs.

Sounds like you know more about CPU architecture and design than I do. I have never worked in this field and don't know all that much about CPU-motherboard interfacing and design. If you figure out the PAL mapping, perhaps you could tell me what function you think the PAL is serving? Hopefully, it is some simple boolean function(s).

386_junkie wrote:

Interesting to know of this Vcc5, I'm away traveling with work right now but when I get home I'll have a look and see where it goes. It may be that it leads to BB1117... which can be checked by simple continuity test rather than testing the device while active.

OK, thanks. I did try Vcc5 on 5.0 V and on 3.6 V with the same results though. Keep in mind, though, that you will need to determine which of the BB1117 pins is Vin, Vout, and GND. Obviously, Vin is 5.0 V and Vout is likely 3.6 V.

386_junkie wrote:

Third hands / hands free is what I am using... but it is easier typed than done.... believe me.

Everything is! I realise it is cumbersome. To make it easier, I would probably use an additional (2nd) third had to hold/press the 24-30 AWG solid test wire onto the QFP144. This way, you don't need to keep bobbing your head left and right and turning it 90 degrees. One other way is to use tape to hold the solid test wire onto the QFP144. The test wire would come down onto the QFP pin (z-plane) in a sort of fashion which bends the wire into a sort of lever arm/spring. This way, there is pressure on the pin. A higher gauge wire might work better for this. It has worked for me in the past with 24 AWG. The larger gauge tends to hold the spring force a little better due to its rigidity.

386_junkie wrote:

I think I see what you're sayin.... the PAL holds off normal 386 operation... almost like adding wait states while it writes/reads L1 QFP cache? My initial thought were that every standard 5v 386 CPU, even without L1 cache uses READY and R/W. Intel's DX33 has it... as does AMD's DX40.... and with neither of those having L1 cache that it would be used for control logic for transfers ISA bus, DRAM, and SRAM cache etc via the chipset.

It looks like you altered your previous post while I was replying to it. Anyway, yes, something of that nature. I do not know enough about the inner workings of CPU architecture and cache coherency to form a more detailed hypothesis. I do know that a lot of boards are not plug-in-play with DLC and SXL chips when L1 cache is used, so I figure this is the most likely issue for an CPU upgrade company to address in this type of upgrade module, hence the PAL. The PAL could also be setting the L1 cache type (direct-mapped or 2-way associative), setting some registers for cache range, setting up clock-doubled mode, etc. There's a lot of things the PAL could be doing, but my point really is that I should not need any of them because the 5 V PGA132 SXL2 works fine, UNLESS there is something different in the 66 MHz design! The 486SXL2 manual does not specifically mention the 66 MHz version. This is why I was interested in a full mapping of your QFP144 to the PGA132, to see if any pins were intentionally not connected, connected to GND, connected to Vcc, etc. Now if the 66 Mhz version is different in some aspect (e.g. it is left in a stand-by state when powered up and needs to be brought out of it with some logic), then knowing the PAL inputs or outputs might provide some light to this. The NOR gate is easy enough to duplicate once you know the entirety of the inputs/outputs and would certainly be the first thing to alter.

As noted previously, the other potential issue is wire length in my custom module - coupled capacitance, impedance matching, etc - which increase with increasing frequency. I briefly discussed this in the vcforum thread and my very minimal research lead me to think that the frequency used should not cause the CPU not to function at all. Here is the thread, it is also unresolved. http://www.vcfed.org/forum/showthread.php?587 … an-oscilliscope

I am waiting for a 33.3 Mhz oscillator to arrive from Israel. This will run the system at 16 MHz. If this works, then I have a pretty good idea that my issue is with wire length and capacitance.

The PAL would not be setting up the L1 cache type, because as stated in the technical manual, this feature was eliminated in order to use reuse the register to enable/disable clock doubling.
I tend to the agree that the likely purpose of the PAL is to provide better compatibility with older 386 motherboards.

As noted previously, the other potential issue is wire length in my custom module - coupled capacitance, impedance matching, etc - which increase with increasing frequency.

I think this is the most likely issue. I think you're going to have to get a proper logic analyzer to proceed further...

I just got this video about cheap (relatively) logic analyzers.

https://www.youtube.com/watch?v=ttvgJqbCXRs

seems legit.

The alternative would be to just design from scratch a PCB with copper traces and not wire.

I used to do this kinda thing at college... you don't even need a computer or software, a normal black pen and ruler would work!

There's a good few videos on youtube: - https://www.youtube.com/watch?v=lxRNQbEGwm4

Aside from the ability to probe several pins simultaneously, what can a logic analyser do that an oscilloscope cannot?

I do not even know what to look for on the scope, how will I know what to look for with a logic analyser? What pins should show what during power-on?

386_junkie, sounds like you have the experience - maybe you can produce a PCB of your own and see if i works.

Anonymous Coward, did you follow the thread and read the links I posted on the vintage computer forum? I've tried adding decoupling capacitors. Some linked thread didn't think impedance matching was necessary. Remember the 1024 K L2 cache modification I did for the MB-8433UUD? The wires on that are longer than for the SXL2 interposer.

feipoa wrote:

386_junkie, sounds like you have the experience - maybe you can produce a PCB of your own and see if i works.

I think I'm going to try... you can too, it's good fun!

I just posted over on another thread that I'm going to try reverse engineer a PGA168-to-PGA132 adaptor... i'm sure it will be possible to reverse this though... and go the other way i.e. PGA132-to-PGA168

I have made some progress on this project, though it is far from finished.

Using my VIA 495-based 386 motherboard 386 and a 33.33 MHz oscillator (CPU runs at 17 MHz), I am able to get the system to startup. It runs through various BIOS tests which pass, it runs the memory test, which passes, after which the system usually will finish POST and boot with a floppy disk. The screen never switches over to booting up.

I have tried oscillators from 50 to 100 MHz, all of which do not produce a screen of any sort on this motherboard. The only other motherboard which shows any signs of life is my SiS Rabbit-based 386 board, but only with a 50 MHz oscillator. On the Rabbit board, the system won't even do the memory count. All I see is a start screen and key strokes have no influence.

Back to the VIA495-based board - I figured there must be some sort of interference or cross-talk with my wires placed so close together and with the kynar cladding being so thin. So the theory was to reduce the operating frequency until the system was able to boot. Next in line, I tried 20 MHz and 12 MHz, but neither of them showed any signs of life. Lastly, I tried an 8 MHz oscillator. With an 8 MHz oscillator, the system runs so incredibly slow that you must wait significantly longer for the screen to come up - and it did!

It ran all the BIOS tests and counted the memory, then it proceeded to attempt to boot from the floppy disk, but failed. I view this as a good sign because even if I use a stand PGA-132 SXL processor, the system will not boot up when using an 8 MHz OSC.

I'm not entirely sure where to proceed from here. I suppose I could create the prototype again with wires containing thicker cladding to ensure that capacitative coupling is part of the issue, but that is really laborious.

I would image at this stage, your wiring is probably correct, and a printed pcb would be the way to go. I know wires need to be the same length and there is impedance matching, just for starters. A small 4-layer should not be THAT much.

luckybob wrote:

I would image at this stage, your wiring is probably correct, and a printed pcb would be the way to go. I know wires need to be the same length and there is impedance matching, just for starters. A small 4-layer should not be THAT much.

I was also considering this as a possible next step - straight to PCB. I do not really have all that much time to devote to that. As the months and years progress, I'm having less and less time for anything (as I'm sure anyone with 3 growing kids can attest to). Ideally, I'm looking for a PCB designer who is familiar with motherboard PCB design or CPU upgrade design who can get the gerber files whipped up for free. So, preferably an enthusiast who has passion for this type of thing. At the place I used to work, we usually had a dedicated PCB guy on staff. There's things like impedance matching, decoupling of capacitance, minimum separation between traces, trace width, insulator type, wire length, intended frequency, etc. which are all usually considered. This should be a cake walk for someone who designs PCB's all day. I honestly don't recall if I ever had to design a PCB. Even way back in school, I can only seem to recall using Magic (in Unix) for VLSI design of some algorithmic functions on the gate level, e.g. the doped transistor layers that goes inside the IC's/CPU's.

Is there anyone here who might want to design this PCB? I can provide the PGA168 to PGA132 pin mapping, as well as the components I am using for voltage regulation.

My next course of action is to fully map out the TI486SXL2-66 QFP144 to PGA132 upgrade module which I recently obtained.

It contained 2 broken pins, but that issue has been rectified by soldering on donor gold pins in place of the missing ones. To strengthen the weaker pins, the whole unit is placed into an additional socket.

I want to map out the pins on this professionally produced module to ensure there aren't any "gotcha's" with my mapping. Once I have confirmed that the pins are one-to-one, with the exception of some PAL pins, the next step may be for a PCB. I am already noticing some drawbacks with the professionally produced TI486SXL2-66 PGA132 upgrade module in comparison to a straight one-to-one mapping as on my module. I'll comment on this later when I've been able to test the module in greater depth.

I also want to check the trace width and separation on the manufactured module.

luckybob wrote:

I know wires need to be the same length...

Do you know which wires? All data and address? The intended freq. is 80 MHz.

About that 80 MHz... something I do not really understand on 386 motherboards (for non-clock doubled CPUs) is why an 80 MHz oscillator is used and the CPU runs at 40 MHz? If I recall correctly, I measured 80 MHz going right to the CPU, so for all 1x 386 CPUs, each CPU has an internal clock divider of 1/2? If that is correct, why is this done? What is the design benefit of this?

In the case of this interposer, the CPU is a clocked doubled CPU, but not by default - it must be doubled in software. So the 80 MHz comes into the CPU, it halves the freq, then you tell the CPU to clock double and, presumably, it just takes away the halving. In which case, then is it safe to assume that the custom interposer is designed around 40 MHz? Or since the clock coming in is 80 MHz, design it around 80 MHz?