Some more:
https://groups.google.com/d/msg/comp.sys.ibm. … ag/clWUxJ6tiDIJ

IBM 386SLC: 386SX pinout with addition of some pins for cache control &
suspend mode. 24-bit Address bus, 16-bit external Data bus. 8Kb internal L1
cache. Able to run all Intel 486SX instructions. Model-Specific Registers
(MSR) to control CPU function. Low-power design. No internal clock
multiplying. Usually clocked at 20MHz to directly replace a 386SX. CPUID
A301h ('A' is IBM, '3' is CPU Family, '0' is clock multiplying, '1' is mask
revision).

IBM 486SLC2: 386SX pinout with addition of some pins for cache control &
suspend mode. 24-bit Address bus, 16-bit external Data bus. 16Kb internal L1
cache. Able to run all Intel 486SX instructions. Additional Model-Specific
Registers bits to control more CPU functions than the 386SLC. Low-power
design. Internal clock doubling at 40 or 50MHz. CPUID A421h or A422h.

IBM 486SLC3/486DLC2: PQFP 386DX pinout with addition of some pins for
cache control, suspend mode, & CPU bus width modes. Hardware pin switchable
between 24-bit Address bus/16-bit external Data bus or 32-bit Address/Data
bus. 16Kb internal L1 cache. Able to run all Intel 486SX instructions.
Additional Model-Specific Register from the 486SLC2. Low-power design.
Internal clock tripling at 60, 75, or 100MHz. CPUID A439h in 486SLC3 mode.

On the clock multiplier, I was curious if anyone had ever tried 3x.

Here's some SiS code that would init these cpus:
old_ibm_init:
mov si,sp
mov ecx,00001000h ; MSR = 1000h
RD_MSR ; EDX|EAX = current content
mov ax,140ah ; Enable EIKN, Cache Parity chk, snoop
or al,00100000b ; Set bit-5 (EPWI)
WR_MSR ; Write back to machine specific reg
inc cx ; MSR = 1001h
mov edx,0fffffff0h ; All memory above 1MB cacheable
mov eax,0f000ffffh ; Seg C,D,E,F read only, 0 - 9 rd/wr
WR_MSR
mov ax,cs:[bx].FAMILYSTRUC.wFuncField
and ah,00001110b ; Seperate Init code
cmp ah,InitIBM2 ; Clock programming needed ?
jnz skip_pgm_clk
inc cx ; MSR = 1002h
RD_MSR
or eax,03000000h ; CLKMD = 011, means internally double
WR_MSR
skip_pgm_clk:
mov ax,IBM
PushNS eax ; Restore EAX = VendorHandle as IBM
mov sp,si
ret_iccs:
ret

Here's also what looks like scans of the MSR pages from that reference doc I'm looking for, I may have found a guy who has it.

Note: I've read elsewhere that setting all 3 CLKMD bits will set an x3 multiplier on the 486BL3.

furan wrote on 2020-01-18, 21:13:

I may have found a guy who has it.

Message him and let us know how you make out! I've been asked to help find these docs before too! (maybe by you?)

Stiletto wrote on 2020-01-19, 00:52:

furan wrote on 2020-01-18, 21:13:

I may have found a guy who has it.

Message him and let us know how you make out! I've been asked to help find these docs before too! (maybe by you?)

Working on it, I'm certain we've discussed it in the past. Thanks!

furan wrote on 2020-01-18, 20:28:

I have been reading up on some of your other projects (google searched a few things and some of your threads came up) - pretty neat!

Unfortunately a lot of my projects have been on ice for years now for a lot of different reasons. I want to finish a few things off, but the way things are these days it may never happen. I've had a few run-ins with the IBM 486 hybrid chips over the years. The Alaris boards in particular are great, because they have chipsets and BIOSes specifically designed for these CPUs. I've also owned a few upgrade modules. All of them had issues related to the internal cache. One was the IODATA PK486BL (for 386DX). These can be coaxed into working well if you set JP4 to the I/O + DMA polling setting, but there is a pretty bad performance penalty. Then I had
an Evergreen Rev to 486 with an SLC2-66 (286 upgrade). This one more or less worked, but not with my 1542C SCSI controller unless cache was disabled. I currently own a Japanese Buffalo upgrade with SLC2-50 (286 upgrade) that I haven't yet had a chance to test. All of these upgrades seemed to have extensive glue logic to make them work, yet they still didn't really operate at their full potential, so I don't know how far you're going to get using these as a direct replacement with none of the cache control lines connected. If we had the databook, we might be able to make them sit well with certain chipsets.

I'm glad that you seem to understand what 5V I/O tolerance means. I've seen so many people who think this means the core can handle 5V.
The TI486SXL(C) 3.3V "G" version is also listed as 5V I/O tolerant, but it seems to be the odd exception that you can run their cores at 5V without issue since the 3.3V and 5V versions of these chips were made on the same die process for some reason.

Thanks for posting the links to what you have. I think I have some of them, but I'll have to check and see.

Anonymous Coward wrote on 2020-01-19, 12:54:

I'm glad that you seem to understand what 5V I/O tolerance mea

Yes, you are talking to a hardware/software engineer. I make FPGAs talk to old hardware for fun, and typically my logic level is 3.3v and I'm going in the other direction.

Anonymous Coward wrote on 2020-01-19, 12:54:

Thanks for posting the links to what you have. I think I have some of them, but I'll have to check and see.

Surely not the IBM SLC FAQ w/IBM saying the SLC series is SX pin-compatible? Or the MSR sheets? 😀

I got an IBM PS1000 on the way from Europe. It's either going to take over from my dream to build a VESA 486DLC, or depending on what I find inside, become another long term project. DLCs are the best!

Jed118 wrote on 2020-01-20, 03:58:

I got an IBM PS1000 on the way from Europe. It's either going to take over from my dream to build a VESA 486DLC, or depending on what I find inside, become another long term project. DLCs are the best!

I've got a few but I wouldn't say that. They searve a niche and do it quite well.

Caluser2000 wrote on 2020-01-20, 06:26:

Jed118 wrote on 2020-01-20, 03:58:

I got an IBM PS1000 on the way from Europe. It's either going to take over from my dream to build a VESA 486DLC, or depending on what I find inside, become another long term project. DLCs are the best!

I've got a few but I wouldn't say that. They searve a niche and do it quite well.

Clearly my DX4/100 kills it, but my goal is to build the best 386-type system you can. The goal is getting harder as the years wear on...

Anonymous Coward wrote on 2020-01-19, 12:54:

The TI486SXL(C) 3.3V "G" version is also listed as 5V I/O tolerant, but it seems to be the odd exception that you can run their cores at 5V without issue since the 3.3V and 5V versions of these chips were made on the same die process for some reason.

I can vouch for that, though obviously I've not run these chips at 5V for years. Who knows, maybe after a long enough time something will break but so far it works. Obviously the power dissipation is a factor as well, once the cache is enabled and the clock multipier set to x2 the chip gets way hotter than original 386SX. I think it also triples the current draw so not all mobos will be able to cope with that (at least with clean power delivery). I've using small heat sinks glued with 2-sided sticky tape. Thermal conductive tape in general but I didn't go for a metal one, I figure the plastic package is already bad enough.

Curiously the 5V 486SLC has a metal pad on the bottom precisely for heat dissipation reasons (you don't solder to it, after all it's a 386SX replacement and the 386 doesn't have it) but the later 3V3 variants do not.

As for connecting a true 486 (or Pentium OD) to a 386 system, forget it. All 486 class CPUs will attempt to burst in entire cache lines, in fact even if you disable internal cache (and that's why a 486 with iCache disabled is usually horribly slow, way slower than 386 even). I don't think there is any way to force the CPU to not do that, unless maybe if you pull the KEN# pin up permanently. But then there isn't any caching at all and in that case what is the point of using a 486. It might be 10-20% faster in some cases (multiplication heavy code for example) but in general a 386SX is pretty much limited by the bus. Because lets not forget each instruction must be fetched from RAM, every time.

Also, if memory serves, the BS16 signal is not compatible between 386 and 486. Mostly it has to do with how the data is presented to the CPU, which bytes occupy which D0-D31 lines. Some extensive glue logic would be required to fix that, since usually it's the chipset job, and that additional in-between step will probably not work fast enough to keep up with 40MHz bus. But if anyone finds a modern FPGA or PLD that can do that, at 5V, I'm all ears. I have use for such devices.

PS. I'm not all that familiar with IBM SLC chips but AFAIK the 386SLC is pin-compatible with 386SX, except it's 3V3 and the cache control lines are not in the same place as the Cyrix/Ti.

Deunan wrote on 2020-01-21, 12:03:

As for connecting a true 486 (or Pentium OD) to a 386 system, forget it. All 486 class CPUs will attempt to burst in entire cache lines, in fact even if you disable internal cache (and that's why a 486 with iCache disabled is usually horribly slow, way slower than 386 even).

Please have a look at http://www.s100computers.com/My%20System%20Pa … CPU%20Board.htm

Deunan wrote on 2020-01-21, 12:03:

Also, if memory serves, the BS16 signal is not compatible between 386 and 486. Mostly it has to do with how the data is presented to the CPU, which bytes occupy which D0-D31 lines. Some extensive glue logic would be required to fix that, since usually it's the chipset job, and that additional in-between step will probably not work fast enough to keep up with 40MHz bus. But if anyone finds a modern FPGA or PLD that can do that, at 5V, I'm all ears. I have use for such devices.

PS. I'm not all that familiar with IBM SLC chips but AFAIK the 386SLC is pin-compatible with 386SX, except it's 3V3 and the cache control lines are not in the same place as the Cyrix/Ti.

I am not conflating the 386 BS16 signal with that of the 486, simply talking about how one uses the BS16 signal of the 486 (as can be seen in the s100 link above) to work with a 16 bit bus. If I had the luxury of the way the 386 BS16 signal works it'd just be an inverter on the fpu enable. I have been wondering about making a dlc/dlc pin compatible QFP board that takes one of the later non-cyrix IBM chips, and hosts a 32 bit FPU, but has an inverter on the enable for the fpu across BS16, so that it can talk to a 16 bit bus. It's so easy with the 386, you don't have to worry because in that case they always shove the bits in the lower 16.

If you read earlier in the thread I link to a page where IBM says the IBM chip is 386sx pin compatible. I link another PDF earlier in this thread about the 3.6v power vs 5v I/O compatibility.

http://ps-2.kev009.com/pcpartnerinfo/ctstips/b01a.htm
"Question:
What is an IBM 486SLC2 processor?
Answer:
It is an IBM-developed derivative of the Intel 386SX chip, called the 486SLC2. The 486SLC2 processor includes the instruction set of the 486SX, rather than the 386. It only uses the same socket pin configuration as the 386SX."

Deunan wrote on 2020-01-21, 12:03:

As for connecting a true 486 (or Pentium OD) to a 386 system, forget it.

I don't know. There's a guy on VCfed who upgraded his XT (with original motherboard) to a POD with a series of adapters. First he installed the Intel Inboard PC, which upgrades the 8088 (8-bit external datapath) to a 386DX16. Then he upgraded the Inboard with a Transcomputer 386 to 486DX upgrade module (I have one of these and they work pretty well for upgrading 386s). Finally, he installed the POD into the 486 upgrade module. It's pretty convoluted, but apparently it works. As for upgrading a 386SX to POD...very difficult but possible.

By the way, I thought you couldn't get the 66MHz TI in BQFP-100 form, but it turns out I was wrong. Now I need to find a couple:

The B in BQFP stands for "buffered" - it's part of the JEDEC standard for the BQFP100/BQFP132 that describes the "wings" that come out from the corners of the package.

furan wrote on 2020-01-21, 16:25:

Please have a look at http://www.s100computers.com/My%20System%20Pa … CPU%20Board.htm

I just did but I do remember seeing this page a long time before. However it's an "almost proper" 486 board, not a 386-to-486 one. But perhaps I misunderstood something, originally you wanted to swap a 386SX for something faster, in 486 or Pentium class - is that no longer the case? Because if you are building a new thing with a 486 just cut down to 16-bit data path, then obviously you don't need to worry about what I wrote. Just need a custom logic for the 486.

It's "almost proper" however but not just that. Now, I did misremember, it's not really KEN# that you want to pay attention to (well, that too actually) but BRDY#. The 486 docs says this:

BRDY # is sampled in the second and subsequent clocks of a burst cycle. The data
presented on the data bus will be strobed into the microprocessor when BRDY # is
sampled active. If RDY # is returned simultaneously with BRDY #, BRDY # is ignored
and the burst cycle is prematurely interrupted

I was never sure if it's possible to just "abort" all bursts on cycle 1 with RDY# (since it has higher priority) but that board does exactly that. BDRY# is permanently tied high and so each and every bus cycle is then a 286-compatible one . So you can, it seems, have the internal cache working after all. Filling it up will be slow so you won't get a full-speed 486 core out of it, but all short loops will benefit from running at core clock speeds from the cache, and that obviously frees the bus to do the actual memory operations you want. Driving KEN# is easy, you pretty much allow it for RAM and nothing else.
Also, EADS# is not used here (and not even connected, it has internal pull-up) so only FLUSH# works. Probably used on every DMA sequence start - if you are doing this, make sure you do not assert FLUSH# on every DMA cycle (unless the DMA is so slow it only steals a cycle at a time) - a full flush is costly and will stall the CPU. That goes for Cyrix CPUs as well and so you can safely assume also IBM ones.

Frankly I got a bit lost on your FPU explanation, what do you mean by 32-bit FPU? Do the later IBM 486SLC chips have one internally? As I've said I'm not familiar with that series, not much solid info around.

furan wrote on 2020-01-21, 16:25:

If you read earlier in the thread I link to a page where IBM says the IBM chip is 386sx pin compatible. I link another PDF earlier in this thread about the 3.6v power vs 5v I/O compatibility.

Well, FAQs are fine and all but I've based my reply on personal experience with a dead IBM SLC board. I've traced most of the package pins to their destinations and tested the power planes.
As for the MSRs, I'm pretty sure these are scans of "The Undocumented PC" book. I have it, the second edition, it looks like the scans came from the first one but the info is otherwise the same. A great book but it too has some errors and is not exactly focused on electrical side of things. It's not a substitute for a datasheets and I've yet to find those.

Anonymous Coward wrote on 2020-01-21, 16:28:

I don't know. There's a guy on VCfed who upgraded his XT (with original motherboard) to a POD with a series of adapters. First he installed the Intel Inboard PC, which upgrades the 8088 (8-bit external datapath) to a 386DX16. Then he upgraded the Inboard with a Transcomputer 386 to 486DX upgrade module (I have one of these and they work pretty well for upgrading 386s). Finally, he installed the POD into the 486 upgrade module. It's pretty convoluted, but apparently it works. As for upgrading a 386SX to POD...very difficult but possible.

Whoa, wait, isn't that basically bypassing the CPU and the RAM in the original mobo, and treating it like an ISA backplane? Because once you take the RAM (and thus a lot of the chipset - decoding and cache logic) out of the equation, then you could put anything in there. Even an ARM MCU running an emulator core and just interfacing with the cards I/O space.
I suppose it all depends on how much logic we can/want to substitute here. Typically I would assume that due to space and complexity reasons all you can do is swap a chip for another one, and maybe add a wire or two, or a small PCB for some extra logic. I mean, with the clock slow enough I could probably put an FPGA there with all the voltage translators required and it would work. A lot of effort but an interesting project to be sure.

Deunan wrote on 2020-01-21, 18:09:

BDRY# is permanently tied high and so each and every bus cycle is then a 286-compatible one. So you can, it seems, have the inte […]
Show full quote

BDRY# is permanently tied high and so each and every bus cycle is then a 286-compatible one. So you can, it seems, have the internal cache working after all.
<snip>
Frankly I got a bit lost on your FPU explanation, what do you mean by 32-bit FPU? Do the later IBM 486SLC chips have one internally? As I've said I'm not familiar with that series, not much solid info around.
<snip>
Well, FAQs are fine and all but I've based my reply on personal experience with a dead IBM SLC board. I've traced most of the package pins to their destinations and tested the power planes.
As for the MSRs, I'm pretty sure these are scans of "The Undocumented PC" book. I have it, the second edition, it looks like the scans came from the first one but the info is otherwise the same. A great book but it too has some errors and is not exactly focused on electrical side of things. It's not a substitute for a datasheets and I've yet to find those.

Sweet.

FPU - let's ignore the IBM part for a sec - I was saying that a 386 DX upgrade would be fairly simple - if you wanted to make a board with a 386 DX and a DX FPU, you could have the 32 bit bus between 386DX and FPU, and only assert the very easy to use on 386 BS16 when the FPU is not in use. Kind of off-topic, but then extrapolate from there, the IBM BLX2/etc are pin compatible with the QFP 386 DX series, so you could make a blue lightning 75mhz upgrade with a nice coproc, and have that coproc be on a 32 bit bus, and only use that BS16 line when it's not in use.

I bought a bunch of IBM boards cheap in a lot and reversed out a few of them - one other nice thing is some of the IBM 486slc/2 supporting chipsets have datasheets, so I think I could figure out all of the cache pins if needed. Cool that you traced them out too!

Shame those MSRs have incorrect content - any idea what? I'm thinking about building a little wiki. Also still searching for the real IBM docs.

furan wrote on 2020-01-21, 18:44:

FPU - let's ignore the IBM part for a sec - I was saying that a 386 DX upgrade would be fairly simple - if you wanted to make a board with a 386 DX and a DX FPU, you could have the 32 bit bus between 386DX and FPU, and only assert the very easy to use on 386 BS16 when the FPU is not in use.

Oh yeah, that should work. I think some DX mobos only test bit A31 and if it's set then:
- a memory access is mapped to BIOS ROM (initial post-reset boot sequence, also BS8# is usually asserted)
- an I/O access is FPU

furan wrote on 2020-01-21, 18:44:

Shame those MSRs have incorrect content - any idea what? I'm thinking about building a little wiki. Also still searching for the real IBM docs.

Oh, I didn't mean to say it's incorrect. Just not clear at times the way it's worded (like, do I need to set or clear the bit), and perhaps not always accurate as to which CPU in the family has that register implemented. In general it's always a good thing to verify on real HW to make sure. And I mostly meant the Cyrix stuff because, again, I do not have experience with IBM chips. Chances are the book is 100% correct on those, but I wouldn't bet the house on it.

Deunan wrote on 2020-01-21, 19:24:

Oh yeah, that should work. I think some DX mobos only test bit A31 and if it's set then:
- a memory access is mapped to BIOS ROM (initial post-reset boot sequence, also BS8# is usually asserted)
- an I/O access is FPU

nice.

Deunan wrote on 2020-01-21, 19:24:

Oh, I didn't mean to say it's incorrect. Just not clear at times the way it's worded (like, do I need to set or clear the bit), and perhaps not always accurate as to which CPU in the family has that register implemented.

Agree. I compared this to various txt files I found on the internet that contained an assortment of MSR documentation, and it seemed to be more verbose than those at least. I have found a post where someone wasn't able to change their SLC2 internal multiplier, but it looked like they didn't set the "speed change notification" and unset the "use motherboard pin" bit before trying.

furan wrote on 2020-01-18, 15:40:

Here's an overlay of the 386sx/cx486slc/IBM 486slc2: https://i.imgur.com/oa7ImsC.png […]
Show full quote

Here's an overlay of the 386sx/cx486slc/IBM 486slc2:

Is there absolutely any way you can label those yellow pins with how they are different compared to the stock Intel 386SX? Or link to a page that discusses this? This would solve many of the questions I have, along with I am sure those that many others have, regarding the exact pin-out differences between an IBM 486SLC2 and an Intel 386SX.

furan wrote on 2020-01-21, 17:20:

By the way, I thought you couldn't get the 66MHz TI in BQFP-100 form, but it turns out I was wrong. Now I need to find a couple: […]
Show full quote

By the way, I thought you couldn't get the 66MHz TI in BQFP-100 form, but it turns out I was wrong. Now I need to find a couple:

The B in BQFP stands for "buffered" - it's part of the JEDEC standard for the BQFP100/BQFP132 that describes the "wings" that come out from the corners of the package.

There is a good chance I have a solid lead on this chip you are looking for.

I have a company that I have worked with over the years to locate several uncommon/rare chips from the 90's.