did you set up the correct voltages? 'cause PMMX uses 2.8v for vcore and 3.3v for io
it seems that your motherboard doesn't support 2.8v which can be the cause of the problems
mmx processors are compatible only with motherboards that support that dual voltage scheme, either via an external vrm or the integrated one.

Yes, it does allow dual voltage operation.
I guess 2.9V is close enough to 2.8V so things don't blow up.

shock__ wrote:

Yes, it does allow dual voltage operation.
I guess 2.9V is close enough to 2.8V so things don't blow up.

it should work fine, it may be something else that's not up to the task
try less ram, or use just the motherboard without hdd's, it may be a power problem
also you can try with another psu

Any other ideas?
Tried my whole collection of EDO/FPM RAMs, disabling the Cache/pulling the module and verfying the voltages.

I've also verfied the PSU ... I've previously used an AT one without a 3.3V rail (since I don't use PCI cards with the system usually) but also adapted an ATX one - no change. Voltages on the CPU socket are within spec.

PICMGs I've used tended to be rock solid considering their industrial use. There maybe a jumper to choose a split voltage CPU, even though you have chosen the two voltages...?

Split voltages do arrive at the Processor and the !VCC2DETECT pin on the MMX goes low.
I've now even gone as far as bypassing the original 3.3V supply on the board (3.45V are what I consider within spec, but a bit on the high side) and feeding 3.3V directly. No change.

^^ After that test, seems more like a BIOS issue. If you can't find a newer BIOS, try an older one...? I've had desired results by downgrading, too.

That's pretty much what I expected and why I uploaded the BIOS I have in the first place.
Problem is, IEI seems to no longer support the board (and seems to be supporting on a corporate level only - just like AMI) and Acquire Inc. which is mentioned in a few other places seems to have gone out of business. Google pretty much comes up with nothing regarding any alternative BIOSes.
I've thought about going with "generic" BIOSes at one point, but it seems like the Aladdin II chipset found on the card never was an overly popular choice.

Anyone good with disassembly? Would be interesting to know why the BIOS fails ... maybe it has a whitelist of CPUIDs or attempts to access an MMX instruction that fails?

Slight edit: Apparently at least the keyboard works ... holding INS on the AMIBIOS splash screen shows some additional info about the BIOS versions, including the version number 1.01 for the CPU.

In case it helps: "51-P001-001588300111111-101094-M151X" is the BIOS identification string.

^^ Have you tried Wayback Machine? Also, if you are using on-board graphics, try disabling it and use a known working card instead, or vice-versa?

Going with a graphics card doesn't seem to help either.
I've found some tools for fiddling with AMIBIOSes, but most fail ... best I've got so far is a tool which can uncompress individual parts. Seems like the POST section doesn't know MMX processors (but then again it accepts my IBM 6x86 [rebranded Cyrix] perfectly fine listing it as "unknown").

I've gone slightly out of my way now by buying another 166MHz MMX - this time instead of a SL27H I'm going with a SL239 in a ceramic package. Since almost seeming like an attempt to add insult to injury google shows one of the boards listed on alibaba with a MMX in the socket (https://ae01.alicdn.com/kf/HTB1QPubifJNTKJjSs … ted-working.jpg) ... might just be a random CPU they had lying around for the photo (voltages are set wrong as well) but who knows.

Well, that didn't work 🙁
Different mask + CPUID for the MMX CPU, same result.

EDIT: BF0/BF1 also seem to be set correctly on the machine. Hmpf.

Looks like borrowing a "similar" BIOS (same chipset, similar general specs) doesn't work either ... AMIDIAG also reports the current CPU as running at 132MHz ... so I guess the issue isn't in the frequency department either.
Anyone know "for sure" if the ALI Aladdin II (M1511/M1512/M1513) chipset is MMX capable?

Well ... in case anyone of you ever comes across "WBCP511.EXE" give me a ring ... that one seems to be able to modify the BIOS version found on my board.

"WBCP511.exe for core BIOS 10/10/94". I don't have that file but I do have a 10/10/94 AMI BIOS utility, see attached file. Never used it so can't help you with that.

That's a tool that was developed out of desperation about not being able to find WBCP511.EXE by a NexGen CPU enthusiast 😉
Already found it ... it can uncompress modules and list their start adresses, but not modify them or output information I'd be able to interpret (i.e. being limited to P54C cores).

shock__ wrote:

developed out of desperation about not being able to find WBCP511.EXE

That's not a good sign... Sorry, don't have that file in my filedrawer 😢

Thanks to a friends ISA postcode card I can determine the PC gets stuck at an errorcode 40 ("preparing the descriptor tables") + 41/42 (undefined/"The descriptor tables are prepared. Entering protected mode for memory test next").

Any ideas?

EDIT: Turns out some NC/INC pins on the socket7 were connected to GND/VCC3 while the manual mentions they should be left unconnected ... since I couldn't modify the socket without possibly harming the board I've gone as far as snipping pins off the MMX - sadly no improvement either. I guess it comes down to faulty microcode, as the problem seems to be related to switching to protected mode and the description tables having changed between P54C and P55c? I guess without any proper means to unpack/repack the BIOS and massive assembly knowledge I'm stuck?

Well ... my final desperation actions didn't seem to help (or harm) either ... snipping off all NC/INC pins off the CPU (what's INC btw? Internally not connected?) didn't improve anything ... the CPU still boots Win98 and runs Final Reality in another machine nicely, so I guess everything is still fine.
Another attempt was to change the discrete keyboard controller, as A20 for real/protected mode gets generated there in the hopes that this would be the origin of my troubles ... no improvement or disadvantage either when exchanging the "Mega-Key" with an "Amikey 2" controller.

^^ Have you tried a Socket 5/7 interposer (Powerleap or Evergreen), and have the MMX CPU boot from it? IIRC, there was an Evergreen utility disk which may modify the BIOS to make it MMX compatible...