Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

8595 LCD Display Codes

83 views
Skip to first unread message

ohl...@boss1.bossnt.com

unread,
Dec 20, 1997, 3:00:00 AM12/20/97
to

Does anyone know the meaning of the 8595 LCD display codes? (eg. CP:25,
CP:BE)

The error codes are in the PS/2 FAQ (I see those too often). No problem
finding those.

-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet

Peterwendt

unread,
Dec 22, 1997, 3:00:00 AM12/22/97
to

Hi !

You need to know it exactly, right ? Think so.
Now here's a list that makes it easier to look in 95s underwear during boot :-)

Checkpoints

The following Stage 1 checkpoints are output to the async port only

cp Description

0110 Check processor
0120 Rom checksum
0130 Check power on values for memory controller registers
0140 Check local registers on processor card
0150 Check JTAG device ID and static capture
0160 Check L2 cache
0170 Check L1 cache
0180 Check memory controller registers
0181 Test memory address bus on processor card
0190 Check power on values for DMA controller registers
0191 Check DMA controller registers
0192 Initialize DMA controller static capture
0193 Test DMA transfers
0210 Check BIU controller registers capture
0220 Verify JTAG cycle capture on LEPB
0230 Verify error detection and enable detection for parity errors
0240 Verify ECC logic of the Memory Controller and Memory Data Bus Buffers
0250 Verify DMA transfer
0260 L1 cache snoop test
0270 L2 cache snoop test

The following checkpoints are output during Stage 1 Post

CP Description

01 Disable clock interrupts, turn off screen, mask off parity, initialize
interrupt
controller, initialize error logging formats
02 Memory DMA refresh test
03 Channel reset
04 Test planar ports (94, 96, 100, 102),initialize default planar POS
05 Check Cmos/Nvram for validity, initialize Expressway (on Model 90
systems only)
06 Initialize dot clock
07 Enable base memory
08 Base memory testing - data integrity
09 Base memory testing - addressability
0F Fatal base memory error - recovery not succesful
10 Start up drive 80, execute CFP3
11 "Enable extended memory, initialize base memory; disable SRAM, reset
parity/"
channel check, initialize row, column of cursor
12 Test protect mode
14 Initialize the 8259 interrupt controller
15 Initialize the interrupt vectors
16 Initialize BIOS interrupt vectors
17 Verify DMA transfers
18 POS setup, set CMOS clock
1A Set divide - by - 0 interrupt vector
24 Set cmos equipment byte
25 Check for manufacturing boot request
30 Test DMA transfers
34 Protected mode shutdown
35 Test video card type error
40 Check for video feature Rom and video presence
41 Reset parity and channel checks, load NMI vector with dummy interrupt
handler, test timers, load NMI vector to POST NMI handler
42 Test interrupt mask register
43 Test interrupt mask register with device interrupt
44 Check hot interrupts
45 Check hot interrupts without I/O - memory parity enabled
46 Interrupt mask error
47 Timer 2 read/write, verife Timer 0 bits
48 Verify Timer 2 output
49 Verify Timer 0 on/off bits
4A Verify Timer 2 output
4B Verify Timer 0 interrupt
4C Verify Timer 0 count/refresh
4D Verify Timer 3 NMI
4E Check keyboard controller for last command accepted
5C Set hardware interrupt vectors 0-7
5D Set hardware interrupt vectors 8-15
5E Set rest of interrupt vectors
5F Test serial port
62 Turn on drive 0 motor
64 Test ASYNC registers, modem control lines, and data loop. ASCII console
selected -
initialize ASCII console as system display device
65 Enable timer interrupts
66 Check for manufacturing boot and unmask NMI interrupt
6E Check for system security or CE overrride conditions, run diskette
testing and setup,
go load first IML image
80 Start of IML process. SCSI POST
81 Diskette IML. Load in and verify IML boot record from diskette
82 Disk IML. Load in and verify IML boot record from disk
83 Diskette IML. Diskette recovery from SCSI IML failure. Load in and
verify IML boot
record from diskette
90 Protected mode exception - divide error
91 Protected mode exception - single step
92 Protected mode exception - NMI, system request for D!
93 Protected mode exception - breakpoint
94 Protected mode exception - into detect
95 Protected mode exception -bound
96 Protected mode exception - invalid opcode
97 Protected mode exception - processor extension not available
98 Protected mode exception - double exception
99 Protected mode exception - processor extension segment error
9A Protected mode exception - tss bad in gate transfer
9B Protected mode exception - segment not present
9C Protected mode exception - stack segment not present
9D Protected mode exception - general protection
9E Protected mode exception - page fault
9F - AF Protected mode exception - reserved
B0 Protected mode exception - processor extension error
B1 - B6 Protected mode exception - reserved
BE Buid descriptor tables for protected mode
BF Completion of descriptor tables for protected mode
C0 Base memory addressing test, CFP3, extended memory enable, base memory
initialization
CA Cache testing (tag RAM, linefill, DMA snooping)
CB Second Group Cache Testing - L1 DMA snoop
CC Second Group Cache Testing - L1 linefill
CD Second Group Cache Testing - noncacheable range boundary
CE Second Group Cache Testing - L2 DMA snoop
CF Second Group Cache Testing - L2 linefill
EB Dual Bus Interface Controller internal register errror
F0 Protected mode initialization
F1 Test interrupts in protected mode
F2 Test exception interrupt in protected mode
F3 Verify 286 descriptor instructions in protected mode
F4 Verify 286 BOUND instruction in protected mode
F5 Verify PUSHALL/POPALL instructions in protected mode
F6 Verify ACCESSRIGHTS function in protected mode
F7 Verify ADJUSTRPL fields in protected mode
F8 Verify LOAD instructions in protected mode
F9 Verify LOAD instructions in protected mode (continued)
FA Test low meg chip select in protected mode

The following checkpoints are output during Stage 2 POST.

CP Descriptions

01 Flush , enable first meg of memory as cacheable, disable clock
interrupts, mask off
parity
0B Write output port command
0C Test keyboard
0D Write byte command to keyboard controller
0E Keyboard error
14 Initialize the 8259 interrupt controller
15 Initialize display row count
1B Count memory size
1C Protect mode entered, determine extended memory size
20 Extended memory size determined, store in CMOS/NVRAM
21 Extended memory size stored, enter real mode
22 Return from count memory size
23 Set real mode stack and data area
24 Set CMOS equipment byte
34 Protected mode shutdown
35 Test video card type error
40 Initialize the video subsystem, set ASCII vectors, clear manufacturing
error flags
41 Teset the data segment
4F Determine warm start
50 Call extended memory testing
51 Protect mode entered, retrieve extended memory size
52 Address test extended memory
53 Memory test extended memory
54 Extended memory testing complete
55 Check if password is enabled
56 Keyboard and mouse testing
57 Keyboard auxillary device test
58 Verify an interrupt is generated by the keyboard
59 Keyboard stuck key error
5A Auxillary device testing
5B Reset timer, initialize keyboard, disable A20
5F Enable kyboard interrupts
60 Enable diskette interrupt vector
61 Diskette and FDC Test
62 Diskette and FDC test, diskette setup
63 Initialize the Bios Data Area
65 Enable timer interrupts, check Cmos and battery, check for memory
configuration errors
66 Initialize diskette setup
67 Enable interrupts
68 Initalize real mode data segment
69 Perform Rom scan
6A Initialize printer parameters
6B Set comos rs232, calculate usable memory values for cmaos 35h, 36h
6C Initialize math coprocessor
6d Close window, setup keyboard, initprogs, set cach boundaries, enable
cache, remove
duplicate EBDA errors, check full Nvram errorlog, set time of day, clear
descriptor
tables, set Post stack, enable master 2, check for mfg mode, enale level 71
int, return
to overlay
6E Cleanup tasks before leaving Post, run boot routine
6F Boot strap loader, Interrupt 19h
70 Read primary disk/diskette
71 Reset disk/diskette
72 Interrupt 18h path
73 Rpl via Interrupt 18h
73 Rpl via Interrupt 18h
84 Image overlay
85 Image overlay
86 Store system partition pointer and system partition type. Return from
boot record
90 Protected mode exception - divide error
91 Protected mode exception - single step
92 Protected mode exception - NMI, system request for D1
93 Protected mode exception - breakpoint
94 Protected mode exception - into detect
95 Protected mode exception - bound
96 Protected mode exception - invalid opcode
97 Protected mode exception - processor extension not available
98 Protected mode exception - double exception
99 Protected mode exception - processor extension segment error
9A Protected mode exception - tss bad in gate transfer
9B Protected mode exception - segment not present
9C Protected mode exception - stack segment not present
9D Protected mode exception - general protection
9E Protected mode exception - page fault
9F - AF Protected mode exception - reserved
B0 Protected mode exception - processor extension error
B1 - B6 Protected mode exception - reserved
BE Build descriptor tables for protected mode
BF Completion of descriptor tables for protected mode
D0 Basic and VPD copies form Rom to Ram
F0 Protected mode initialization
F1 Test interrupts in protected mode
F2 Test exception interrupt in protected mode
F3 Verify 286 descriptor instructions in protected mode
F4 Verify 286 Bound instruction in protected mode
F5 Verify Pushall /Popall instructions in protected mode
F6 Verify Accessrights function in protected mode
F7 Verify Adjustrpl fields in protected mode
F8 Verify Load instructions in protected mode
F9 Verify Load instructions in protected mod (continued)
FA Test low meg chip select in protected mode
41 Teset the data segment
4F Determine warm start
50 Call extended memory testing
51 Protect mode entered, retrieve extended memory size
52 Address test extended memory
53 Memory test extended memory
54 Extended memory testing complete
55 Check if password is enabled
56 Keyboard and mouse testing
57 Keyboard auxillary device test
58 Verify an interrupt is generated by the keyboard
59 Keyboard stuck key error
5A Auxillary device testing
5B Reset timer, initialize keyboard, disable A20
5F Enable kyboard interrupts
60 Enable diskette interrupt vector
61 Diskette and FDC Test
62 Diskette and FDC test, diskette setup
63 Initialize the Bios Data Area
65 Enable timer interrupts, check Cmos and battery, check for memory
configuration errors
66 Initialize diskette setup
67 Enable interrupts
68 Initalize real mode data segment
69 Perform Rom scan
6A Initialize printer parameters
6B Set comos rs232, calculate usable memory values for cmaos 35h, 36h
6C Initialize math coprocessor
6d Close window, setup keyboard, initprogs, set cach boundaries, enable
cache, remove
duplicate EBDA errors, check full Nvram errorlog, set time of day, clear
descriptor
tables, set Post stack, enable master 2, check for mfg mode, enale level 71
int, return
to overlay
6E Cleanup tasks before leaving Post, run boot routine
6F Boot strap loader, Interrupt 19h
70 Read primary disk/diskette
71 Reset disk/diskette
72 Interrupt 18h path
73 Rpl via Interrupt 18h


Hope it helps to make you glad ;-)

Very friendly greetings from Peter in Germany
http://members.aol.com/phwimage1/mcaindex.htm

Tomas Slavotinek

unread,
Aug 25, 2022, 4:42:55 AM8/25/22
to
Well, this would have been bloody useful to have some 2 years ago...

I don't have time to dive into this now but I can tell that the list is outdated (much like the list of 2-digit CP codes for the premium PS/2s). Many of these SDL CP codes are not used by the shipped T4 firmware builds, and on the other hand, some codes that are used are missing from this list.

Anyway, looks like I got most of it right:
https://ardent-tool.com/complex/T4.html#SDL_POST_Diag

It's really helpful to know that the two remaining CPs (0150/0220) are related to JTAG. Some of the associated code certainly looked like a serial comms to me, but the complexity of the code was rather discouraging and I have mostly ignored it thus far. But now we know that ports E6/E7h are JTAG. I wonder what kind of tests are they running there. JTAG is available on the CPU, cache controller, SRAMs, and the debug connector. I wonder if the SSC ASIC has it as well... will have to probulate when things get less hectic on my end.

(eh, this my first post through the Google Groups iface, hopefully It makes it through unmangled)

Tomas Slavotinek

unread,
Aug 25, 2022, 4:48:16 AM8/25/22
to
On 25.08.2022 10:42, Tomas Slavotinek wrote:
> Anyway, looks like I got most of it right:
> https://ardent-tool.com/complex/T4.html#SDL_POST_Diag

I'll update the page later.

I wonder I about the source of this info. It's not in any of the
references we have. Time to ping Peter I guess...

Louis Ohland

unread,
Aug 25, 2022, 7:46:18 AM8/25/22
to
https://ardent-tool.com/complex/T4.html#Address_Mux

The primary chip used in this implementation only requires 39 bits of
data in the ECC mode, 32 data bits and 7 check bits. Therefore, the only
support required for DQ39 in this implementation is to tri-state the
multiplexed logic outputs when a 40 bit ECC memory module is being
addressed. This prevents contention at the DRAM's output on DQ39.

Tomas Slavotinek

unread,
Aug 25, 2022, 10:13:08 AM8/25/22
to
Unrelated, but yes. We have talked about this before - pretty much all
ECC SIMMs are 40-bit wide internally, even if the algorithm requires
only 39-bits.

Some modules have all 40 bits exposed on the pins, but the special Model
90/95 16 and 32MB ECC SIMMs don't. This is because IBM had to redefine
some of the pins to squeeze in the additional address lines that are
missing from the "set in stone" processor complex interface (and
planars). The lines are then multiplexed on the processor complex side
and the muxing is activated or deactivated based on the SIMM ID - ECC
SIMMs with lower capacity use the standard IBM ECC pinout and are marked
as 40-bit bit wide. This how they got 16/32MB modules working with the
existing complex interface and the "old" 8590/8595 planars.

Yes yes, I know, I have promised a write up about this long time ago.
Meh, one day...

Tomas Slavotinek

unread,
Aug 25, 2022, 10:19:17 AM8/25/22
to
Peter doesn't recall where it came from, but I don't blame him... this
was 25 years ago. Oof!

Anyway, iirc some of the listed SDL CP codes that don't exist in the T4
POST code are used in the T3 codebase... (yes, the T3 complex has a
serial diagnostic link too, but the implementation is different and the
header is not populated on production boards).

I'll check how closely it matches the T3 POST code base when I get back
to the firmware shenanigans.

Tomas Slavotinek

unread,
Aug 29, 2022, 8:09:07 PM8/29/22
to
Expanded and moved to a separate page:
https://ardent-tool.com/trouble/cp_codes_sdl.html

I can also confirm that the SynchroStream chip has a JTAG interface. It
doesn't appear to be on the same chain with the CPU or the C5/C8 cache
set - at least not on the "N" complex.

No time to probe the Type 3 complex, but it probably has a JTAG chain
between all the major chips. That would explain the significantly larger
JTAG data set in the T3 ROM.

Tomas Slavotinek

unread,
Aug 29, 2022, 8:18:46 PM8/29/22
to
All this also reminded me of the AMD K6 experiment I've done some time
ago. It failed on one of the tests that were now identified to use the
JTAG interface.

I don't have the code fully reversed but looks like they are doing an
awful lot of bitbanging there. TCK is pulsed from the code with no
explicit SW delay. So, now I wonder whether there really was a critical
communication failure on the local/system bus or if this was just a
timing issue on the JTAG bus because of the CPU's ability to execute the
loops significantly faster... (sure, we are limited by the timing of the
local and system buses - 60/66 and 40 MHz, but JTAG from this era is
usually clocked even lower - 10-20 MHz maybe? The TCK signal goes
through a PAL, so it's possible that they are doing some synchronization
there, but idk... will have to probulate it with a logic analyzer.

But don't get your hopes up. It's quite likely that there will be more
problems down the road with the K6 if we push it past the JTAG tests.
But it makes me curious. I'll definitely revisit this at some point and
try bypassing the tests...

Shane Benting

unread,
Aug 30, 2022, 4:44:40 PM8/30/22
to
Tomas,

Which K6 did you try? I've been meaning to test out an Evergreen Spectra I recently acquired on one of my Ys. I was hopeful that since it offloaded the power to a separate connector that it wouldn't require the same level of modifications that the Overdrives do.

-Shane

Tomas Slavotinek

unread,
Aug 30, 2022, 5:55:17 PM8/30/22
to
On 30.08.2022 22:44, Shane Benting wrote:
> On Monday, August 29, 2022 at 5:18:46 PM UTC-7, Tomas Slavotinek wrote:
>> All this also reminded me of the AMD K6 experiment I've done some time
>> ago. It failed on one of the tests that were now identified to use the
>> JTAG interface.
>>
>> I don't have the code fully reversed but looks like they are doing an
>> awful lot of bitbanging there. TCK is pulsed from the code with no
>> explicit SW delay. So, now I wonder whether there really was a critical
>> communication failure on the local/system bus or if this was just a
>> timing issue on the JTAG bus because of the CPU's ability to execute the
>> loops significantly faster... (sure, we are limited by the timing of the
>> local and system buses - 60/66 and 40 MHz, but JTAG from this era is
>> usually clocked even lower - 10-20 MHz maybe? The TCK signal goes
>> through a PAL, so it's possible that they are doing some synchronization
>> there, but idk... will have to probulate it with a logic analyzer.
>>
>> But don't get your hopes up. It's quite likely that there will be more
>> problems down the road with the K6 if we push it past the JTAG tests.
>> But it makes me curious. I'll definitely revisit this at some point and
>> try bypassing the tests...
> Tomas,
>
> Which K6 did you try? I've been meaning to test out an Evergreen Spectra I recently acquired on one of my Ys. I was hopeful that since it offloaded the power to a separate connector that it wouldn't require the same level of modifications that the Overdrives do.
>
> -Shane
I believe it was a regular K6-266 (non -II/-III) with the PowerLeap
PL-ProMMX Plus interposer (v4.0 IIRC). This interposer (and the mounted
CPU) is also powered directly from the PSU and has a local switching
regulator. It takes care of the clock multiplier pins too, so no bodge
wires are needed. The Evergreen one should be similar in this aspect.

There are however other problems with the later Socket 5/7 CPUs.

The non-MMX P54C Pentium chips had 3.3V I/O and core, but the clock
input was still 5 V-tolerant (to make board conversion easier/cheaper).
So, to nobody's surprise, the "Y" platform uses IBM's own 5 V clock
driver - the same one as on the "P" and "Q" boards. The clock signal
goes directly to the CPU (unlike the other non-C5/C8 input signals that
*ARE* level-shifted on "Y"). Pentium MMX (P55C) not only introduced the
split voltage design but also dropped support for the legacy 5 V clock.
Most interposers probably don't level-shift the clock. This won't damage
the chip, despite it being beyond the absolute maximum voltage, but it
may compromise the clock integrity.

Further, the P5 and P54C chips can be configured to a C5/C8 mode (the
cache chipset used on all T4 complexes). This modifies the driving
capability of certain pins IIRC. At least some of the P55C MMX chips
still have this capability, but most if not all of them were not tested
in this configuration by Intel. That's another potential problem...

The former issue is fixable, and if that's what causes the
incompatibility/instability with some faster CPUs, then we should be
able to get them working.

The latter may be more difficult to solve... but I'll have to go over
the manuals again to see what exactly the C5/C8 mode modifies.

Later Socket 5/7 CPUs were designed with the "modern" PCI chipsets in
mind, so there very well may be other incompatibilities too (tighter
timings, etc.).

I plan to do more CPU experiments but first I wanna understand the T4
architecture better - down to a component level including the 74xx glue.
I'm almost there, but not quite... And the JTAG discovery will help me
crack the few remaining early POST bits too. (I had to delay all this
exciting stuff because of other more important things..)

The C5/C8 cache set is actually relatively fast - especially for its
time. But you can fit only so much into 256K. We are ultimately limited
by the relatively slow RAM subsystem (interleaved 64-bit 70 ns non-EDO)
and slow I/O bus (Micro Channel) where the best we can do is <40 MB/s
sequential from/to the complex - comparable to early PCI implementations
(Neptune). So at some point, the benefits of a fast CPU core flatten out
in practical applications, as it has to spend a lot of time waiting for
data/instructions... The fast internal L2 cache of the K6-III(+) chips
might mask the memory bottleneck a bit, but it's still only 256K...

Anyway, please let us know how your experiments go. It's always good to
have more data!

Louis Ohland

unread,
Aug 30, 2022, 6:33:43 PM8/30/22
to
Oh, hows about using the single row sockets to pump up the N to a POD?
Instead of removing the 17x17 and dropping in a 19x19 socket?

Tomas Slavotinek

unread,
Aug 30, 2022, 7:09:54 PM8/30/22
to
On 31.08.2022 0:33, Louis Ohland wrote:
> Oh, hows about using the single row sockets to pump up the N to a POD?
> Instead of removing the 17x17 and dropping in a 19x19 socket?

You could probably do that if you are careful with the alignment. The
connection won't be as reliable if you use a normal female pin-header (i
believe the CPU pins are slightly thinner).

I wanna replace the LIF on one of my "N"s with the old-school
"overdrive" ZIFs that were used on the Olivetti M6 planar, for example.
Mainly because these early sockets are more compact. I don't think a
regular ZIF would fit with its bulky lever base.

But more importantly, I need to get back to figuring out what makes the
"N" barf with anything but the DX2. Even with a regular 486DX-33 that
should be 100% compatible with the DX2-33/66 (externally). It either
executes POST for a bit and then loses the plot (even before the first
SDL checkpoint) or sometimes just sits there after reset.

One thing that comes to mind is the BIST execution time - that's one
aspect where the two differ. Of course there are probably other
undocumented differences too.

Eh, we will get there...

Tomas Slavotinek

unread,
Aug 31, 2022, 7:17:55 AM8/31/22
to
On 30.08.2022 23:55, Tomas Slavotinek wrote:
> Further, the P5 and P54C chips can be configured to a C5/C8 mode (the
> cache chipset used on all T4 complexes). This modifies the driving
> capability of certain pins IIRC. At least some of the P55C MMX chips
> still have this capability, but most if not all of them were not tested
> in this configuration by Intel. That's another potential problem...

I've added some basic info on the C5/C8 chipset here:
https://ardent-tool.com/complex/T4.html#C5C8

Louis Ohland

unread,
Aug 31, 2022, 8:12:28 AM8/31/22
to
https://ardent-tool.com/CPU/docs/Intel/Pentium/spec_update/242480-041.pdf

page 87 physical


2. Removal of VCC Pin A4
To resolve compatibility concerns with a limited number of incorrectly
designed motherboards, pin A4 (VCC) will be removed from the Pentium
OverDrive processors and will no longer be present on the package. The
removal of this VCC pin will not adversely affect the operation of the
processor due to the large number of VSS
and VCC pins remaining in the outer row.

Louis Ohland

unread,
Aug 31, 2022, 8:15:19 AM8/31/22
to
page 89

13. CLK Required for UP# to be Driven
PROBLEM: The Upgrade Present (UP#) output pin is intended to be driven
low after power-up to indicate that an upgrade processor is present in
the system. The UP# pin on the Pentium OverDrive processor requires that
the CLK input toggle while the system is starting to insure that RESET
reaches the UP# circuitry. If CLK does not toggle, UP# may or may not be
driven low, depending on the initial state of the UP# circuitry.

IMPLICATION: If an Intel486 processor system is dependent on having UP#
driven low before driving the CLK input on the Pentium OverDrive
processor, it may never boot since CLK may never be driven to the
processor if UP# remains high. This is generally only a potential issue
in systems with two processor sites, such as those with a surface-mount
Intel486 processor and a PGA upgrade processor site.

WORKAROUND: Most two site systems have the ability to disable the
processor in the surface-mount location so that a different Intel486
(non-upgrade) processor may be used in the PGA socket location. If the
system has a jumper or switch that is documented to specifically disable
the surface mount processor (or the original processor in a two socket
system), use it to disable the second processor and thereby route the
CLK signal to the upgrade PGA socket location.

STATUS: This erratum has been fixed in the C-0 stepping.

Kevin Bowling

unread,
Sep 2, 2022, 1:12:46 PM9/2/22
to
A random thought since you are looking in these directions.. The P54 is
supposed to be a glueless SMP
https://www.youtube.com/watch?v=-VkFyGPiy7E&list=PLQsxaNhYv8daltwYEVnbMdaJ35YFg-6vv&index=8

I wonder if this could be finagled onto single socket carrier with a
crazy interposer. I guess the hard part would be bringing the AP
online, not sure if that could be done after POST or would require major
BIOS rework.

Tomas Slavotinek

unread,
Sep 3, 2022, 1:12:19 PM9/3/22
to
On 02.09.2022 19:12, Kevin Bowling wrote:
> A random thought since you are looking in these directions.. The P54 is
> supposed to be a glueless SMP
> https://www.youtube.com/watch?v=-VkFyGPiy7E&list=PLQsxaNhYv8daltwYEVnbMdaJ35YFg-6vv&index=8
>
>
> I wonder if this could be finagled onto single socket carrier with a
> crazy interposer.  I guess the hard part would be bringing the AP
> online, not sure if that could be done after POST or would require major
> BIOS rework.

Yes, the P54C indeed supports "glueless" two-way SMP. But retrofitting
it into an existing design is not as simple as adding a dual-socket
interposer. The "glueless" aspect of it really only applies to new designs.

My main worry here are the hardware interrupts. The P54C has a local
APIC but we also need an I/O APIC on the expansion bus (Micro Channel).
All PS/2s, of course, have a PIC, but one that is not SMP-ready (APIC).
It would have no way of telling which of the two CPUs should a
particular interrupt be directed to, as there is only one interrupt line
(INTR) between the PIC and the CPU. To make things worse, in the Model
90/95 machines, the interrupt controller is part of the I/O chip on the
planar (either 85F0464 or 10G4672), and the single INTR line is part of
the "set in stone" processor complex interface.

With new designs, you simply connect the three-wire P54 APIC interface
to a compatible I/O APIC, and that's it...

I don't remember how exactly the different local APIC modes work in the
P54C, but we would probably need some sort of interrupt vectoring unit
on the complex/interposer to extend the functionality of the legacy PIC.

IBM was toying with the idea in the 486/early Pentium days:
https://ardent-tool.com/docs/patent/US5381541.pdf

With the P54C CPUs, none of the local bus buffers would be needed, and
the same is true for the CPU arbitration logic. This makes things
significantly easier, but a modified version of the "multiprocessor
interrupt director" would be needed to handle the vectoring and to
interface with the three-wire APIC bus.

There may be some other issues too, but this is probably the most
significant one...

I'll read through the Pentium manuals again when I have time... so far
I've been ignoring the SMP-related chapters for the most part.



Tomas Slavotinek

unread,
Sep 3, 2022, 1:34:20 PM9/3/22
to
On 03.09.2022 19:12, Tomas Slavotinek wrote:
> I'll read through the Pentium manuals again when I have time... so far
> I've been ignoring the SMP-related chapters for the most part.

Just scrolled through the Pentium dev manual real quick... Figure 19-5
on page 403 physical illustrates the APIC configuration rather well:

https://ardent-tool.com/CPU/docs/Intel/Pentium/241428-004.pdf#page=403

The I/O ASIC on the planar essentially contains a dual 8259 PIC and the
individual IRQ lines from MCA and planar devices are wired directly to
it... We don't have access to these IRQ lines on the complex, only to
the INTR line from the PIC. Hence the need for the "multiprocessor
interrupt director" - to take care of what the I/O APIC would normally do.

At least that's how I see things without a deep dive into the documentation.

Tomas Slavotinek

unread,
Sep 10, 2022, 11:03:27 AM9/10/22
to
On 30.08.2022 23:55, Tomas Slavotinek wrote:
> Pentium MMX (P55C) not only introduced the split voltage design but also
> dropped support for the legacy 5 V clock. Most interposers probably
> don't level-shift the clock. This won't damage the chip, despite it
> being beyond the absolute maximum voltage, but it may compromise the
> clock integrity.

Hmm, maybe some interposers actually take care of the clock level-shifting:
https://patents.google.com/patent/US5938769
Though the proposed method with a simple resistor to ground is far from
ideal. It may cause more trouble then good...

Louis Ohland

unread,
Sep 10, 2022, 12:50:22 PM9/10/22
to
https://patents.google.com/patent/US5938769

Is this the shift?

In accordance with still a further aspect of the present invention, the
CPU escalating adapter with multivoltage and multiple frequency
selection further includes a programmable array logic (PAL) for
converting a part of control signals of the CPU.

U2 GAL16V8

Inputs (I think)
ADS*
BA20M*
HRESET
HA20
HINIT
M/IO*

Outputs
F0-7
F8 TA20M*

Pin numbers don't seem to make sense.

Tomas Slavotinek

unread,
Sep 10, 2022, 1:24:36 PM9/10/22
to
On 10.09.2022 18:50, Louis Ohland wrote:
> https://patents.google.com/patent/US5938769
>
> Is this the shift?
>
> In accordance with still a further aspect of the present invention, the
> CPU escalating adapter with multivoltage and multiple frequency
> selection further includes a programmable array logic (PAL) for
> converting a part of control signals of the CPU.
>
> U2 GAL16V8
>
> Inputs (I think)
> ADS*
> BA20M*
> HRESET
> HA20
> HINIT
> M/IO*
>
> Outputs
> F0-7
> F8 TA20M*
>
> Pin numbers don't seem to make sense.

No, and I'm not sure what are they doing with the PAL. They take ADS,
BA20M, HRESET, HA20, HINIT, M/IO and use them to generate a modified
TA20M signal for the CPU. They must be working around some change or
errata. Not sure. (A20 is the line that enables the legacy
8086-compatible wraparound at 1 MB.)

I0-I9 are indeed inputs. F0-F7 are I/O pins and can be configured as one
or the other (they are using only F7 - as the only output).

The "level-shifting" I was referring to (if you can call it that) is
implemented using the 23K resistor R4 and can be enabled/disabled using
SW1-P4. It's more like loading the clock line down, which seems like a
really bad idea. Tbh, I don't know if the schematic is even right. The
value of the resistor makes me think that it was supposed to be part of
the LP2951 voltage set circuit. Or maybe they just decided to reuse a
resistor network they already had on the board.

The description says: "A fourth Switch of the toggle Switch member 70 is
connected with a clock pin CLK of the CPU 80 for setting the clock power
of the CPU".

And in the Fig. 4 table: "CLK Vcc SW1:P4" "5V" and "3.3V"

But the function seems inverted.

Idk. But looks like they at least considered tweaking the CLK level at
some point. The actual interposer may be doing things the right way...
or not at all. Will have to probulate it.



Louis Ohland

unread,
Sep 10, 2022, 4:19:32 PM9/10/22
to
Delay line? Ringing?

Louis Ohland

unread,
Sep 10, 2022, 4:50:26 PM9/10/22
to
P54C
P55C
M2
K6
K5
CYRIX 6×86 or 6×86L

Tomas Slavotinek wrote:
> TA20M signal
0 new messages