Minor update:

I let my kids play Duke3D with the testbed system: 85 MHz SXL2 and AHA-1542CP. After 15 minutes, I hear some B&M ("bitch and moan"). Duke3D is hung with some DOS error layered over the game graphics, stating DOS cannot write to the HDD or something of this nature. When I inquired, I was told it was the 3rd time he tried to save the game progress which then hung the system. The first two saves were successful. This was with the Alpha1 interposer and the MEMW# wire connected.

I fiddled with some cyrix.exe settings, but the same problem occurred. I swapped the CPU for the Evergreen SXL2 and ran again. Same problem. Upped the voltage on the Evergreen, still hung after the same time period. I swapped the AHA-1542CP in favour of the AHA-1522B, and the kids played for 2 hours without incident.

It is probably best to just stick with the AHA-152xB in 386 systems containing an SXL2. Some systems might run OK with the AHA-1542CP, but resolving these intermittent issues can be time consuming and frustrating.

I have my AMI Mark V Baby Screamer setup with the AHA-1540CP running at only 66 MHz and my kids haven't run into this issue. On the testbed, I suppose should have tried taking the DRAM speed down from 1 ws to 2 ws. Maybe with the AHA-1542CP it needs the extra time at 85 MHz?

Good evening,

I am currently testing the TI486SXLC2-50 on a HT18(a) mainboard running formerly a 386sx/25. All cyrix.exe parameters work fine and show changes in NU SI. But what is not working is the -cd command. The system always hangs no matter what I try.

Do you have any idea why that is?

What happens if you use a 33 or 40 MHz crystal oscillator instead of a 50 MHz crystal? Some CPUs won't clock double on certain motherboards, but the result is usually that the CPU stays in 1x mode.

I've not experienced a freeze-up like this with clock doubling. The normal hang-up is when enabling L1 cache. Try enabling clock doubling (-cd) without having the L1 cache enabled to see if 50 MHz is possible.

feipoa wrote on 2024-12-31, 11:57:

Minor update: […]
Show full quote

Minor update:

I let my kids play Duke3D with the testbed system: 85 MHz SXL2 and AHA-1542CP. After 15 minutes, I hear some B&M ("bitch and moan"). Duke3D is hung with some DOS error layered over the game graphics, stating DOS cannot write to the HDD or something of this nature. When I inquired, I was told it was the 3rd time he tried to save the game progress which then hung the system. The first two saves were successful. This was with the Alpha1 interposer and the MEMW# wire connected.

I fiddled with some cyrix.exe settings, but the same problem occurred. I swapped the CPU for the Evergreen SXL2 and ran again. Same problem. Upped the voltage on the Evergreen, still hung after the same time period. I swapped the AHA-1542CP in favour of the AHA-1522B, and the kids played for 2 hours without incident.

It is probably best to just stick with the AHA-152xB in 386 systems containing an SXL2. Some systems might run OK with the AHA-1542CP, but resolving these intermittent issues can be time consuming and frustrating.

I have my AMI Mark V Baby Screamer setup with the AHA-1540CP running at only 66 MHz and my kids haven't run into this issue. On the testbed, I suppose should have tried taking the DRAM speed down from 1 ws to 2 ws. Maybe with the AHA-1542CP it needs the extra time at 85 MHz?

Have you tried a 154xB too (instead of a 152xB or a 154xC)?

Disruptor wrote on 2025-03-18, 23:44:

feipoa wrote on 2024-12-31, 11:57:

Minor update: […]
Show full quote

Minor update:

I let my kids play Duke3D with the testbed system: 85 MHz SXL2 and AHA-1542CP. After 15 minutes, I hear some B&M ("bitch and moan"). Duke3D is hung with some DOS error layered over the game graphics, stating DOS cannot write to the HDD or something of this nature. When I inquired, I was told it was the 3rd time he tried to save the game progress which then hung the system. The first two saves were successful. This was with the Alpha1 interposer and the MEMW# wire connected.

I fiddled with some cyrix.exe settings, but the same problem occurred. I swapped the CPU for the Evergreen SXL2 and ran again. Same problem. Upped the voltage on the Evergreen, still hung after the same time period. I swapped the AHA-1542CP in favour of the AHA-1522B, and the kids played for 2 hours without incident.

It is probably best to just stick with the AHA-152xB in 386 systems containing an SXL2. Some systems might run OK with the AHA-1542CP, but resolving these intermittent issues can be time consuming and frustrating.

I have my AMI Mark V Baby Screamer setup with the AHA-1540CP running at only 66 MHz and my kids haven't run into this issue. On the testbed, I suppose should have tried taking the DRAM speed down from 1 ws to 2 ws. Maybe with the AHA-1542CP it needs the extra time at 85 MHz?

Have you tried a 154xB too (instead of a 152xB or a 154xC)?

As I recall it, I could not get the 1542B to recognise my HDD's. I would need to hunt the card down and look at the post-it note I put in the anti-static bag with the card to be sure.

Done. Also without L1 it will crash. Very strange. Maybe power supply issue?

Update: tested with second PSU. Same.

Marco wrote on 2025-03-19, 08:41:

Done. Also without L1 it will crash. Very strange. Maybe power supply issue?

Update: tested with second PSU. Same.

My suggestion contained two parts. When you wrote "done", did you try both suggestions?

No sorry. the osci part I didn’t do so far as no 4pin holder nor <50MHz part in place so far. I will follow up on this.

will try this cpu in a second board in parallel.

I specifically recall encountering one motherboard for which I could not clock double the SXL2 beyond an FSB of 33 MHz. The command to clock double would be ignored by the SXL2 CPU. I'm not sure which checks the CPU has for this.

Try measuring Vcc at the CPU to ensure it is 4.9 to 5.1 V. Also try to remove all ISA cards from your system except for the graphics and I/O for booting.

Tests updated: also with 40MHz oscillator exactly the same issue 🙁

Did you measure Vcc? Could you share a photo of your soldering job?

I will check the voltage later. Attached a picture from the exercise. Although you might see bridges there are non - verified by glasses and multimeter. The chip wouldn’t work then at all I assume.

Thanks for your help

After checking the voltage at the QFP pads themselves, you could try soldering on a Cyrix Cx486SLC2-50MP. These should run at 60/66 MHz and have 2x permanently enabled. The SXLC2-50, in my experience, has been problematic chip to get working unless you bought it on an interposer designed around that CPU.

Hm not what I hoped to hear 😉
But thanks

feipoa wrote on 2015-11-28, 10:01:

-x0,64 may be needed, as suggested by rasz_pl. I think he suggested it for some A20 failures.

Remark from me: I also had himem.sys a20 control issue with the ti486. I could resolve it by adding "/machine:13" option.

Marco wrote on 2025-04-16, 06:45:

feipoa wrote on 2015-11-28, 10:01:

-x0,64 may be needed, as suggested by rasz_pl. I think he suggested it for some A20 failures.

Remark from me: I also had himem.sys a20 control issue with the ti486. I could resolve it by adding "/machine:13" option.

You got your SXLC2-G50 working completely now? How did you land upon /machine:13? Was this needed to resolve your issue with clock doubling, or some other stability issue? Normally I only need to experiment with /machine:1 or /machine:3 when using a BL3 chip. Do you recall what the '13' is for?

1. yes and no. I soldered the CPU onto another chipset/board (VLSI). it works flawless now. difficult to say whether it was soldering or chipset issue
2. I ran into issues with himem.sys (cannot control A20 or something like this). I then searched for options and tested with machine:13 as it was also for generic AT systems "alternative delay". Since then no himem.sys errors anymore.

If I'm remembering things correctly, sometimes changing the Fast Gate A20 Enable/Disable option in the BIOS will also clear that himem error.

I keep getting parameter error for 5x86 with a machine for my friend. I dont understand why? Everything seems ok. IT does not understand the parameters coming after 5x86.exe???

I've not run into this problem. I suggest sharing a screenshot.

You also may want to try the Evergreen utility to set the registers and the IBM 5x86 utility. There's also a Free5x86 utility packaged in the original post.