Working on "Uncle Sherman", my Mitsubishi MP-3200 386SX-16.
Current issue that has resurfaced is that it reliably crashes when certain software tries to put it into protected mode.
CheckIT V1: Crashes on "(2) Test EXTENDED (Protected mode) Memory only" Specifically crashes at address 0x100000, which is the first byte over 1024Kb, IIRC. Shows the testing page, reboots immediately.
CheckIT V1: Crashes on CPU test immediately after displaying "Testing Protected mode" (Crashes even if all extended memory is removed, leaving only base memory)
CheckIt V3: Seems happy, reports protected mode test is successful. Tests all extended memory (with occasional "parity errors detected" note)
NSSI 0.60.45: Crashes on startup, right after telling me that April 2022 is an invalid date. Sequence of messages in the bottom left is:
- "Please wait while determining system contents..."
- "Determining computer type..."
- "Determining presence of PCI bus..."
- "Determining processor type. checking for Cyrix..."
- "Determining processor speed..."
- "Resetting CPU..."
(Crashes here with every character of the 80x25 text mode screen displaying a "mouse cursor" , begins to POST, the crashes again with a blank screen and boots normally)
NSSI 0.60.45: I can start it in safe mode ("nssi /safe") and it won't immedately crash, but crashes on certain cpu/memory tests (will have to go to the workshop and refer to my notebook, bear with me on this)
Adding HIMEM.SYS to CONFIG.SYS in DOS 6.2 causes the PC to halt with "MAIN RAM FAIL" message. DOS 6.2 without HIMEM is fine, an di Have played Prince of Persia and Indy 500 just fine on this PC.
All the memory chips above base memory are socketed, and I removed them all and tested them in a dramarduino. They all came back fine. Deoxit / reseated, and all lines up correctly. Having said that, it crashes in CheckIT 1 with all memory (above base memory) removed, so that suggests mayeb not an individual ram chip issue (or maybe it also crashes if it finds no extended memory..?)
Questions:
I've done some reading on protected mode and I know what it's for (running more than one program at a time) and that reaching into memory owned by another app will cause the CPU to rest the system. What I don't currently understand is how to break down and test the components of that.
- Is the 32kb cache used by, and only by, protected mode?
- Is there a DOS program that will lest me test the 32kb cache?
- Is bad cache ram a possible cause of crashing on entering protected mode? I'm trying to figure out of it is worth desoldering and testing the cache ram chips?
Testing extended memory in checkit3 often gives me a parity error note, but still lists the test as passed. My next approach will be to get collections of chips and install only 512K of extended memory and see if I can pass multiple memory tests without parity errors on any chips at all. If not, there is a more fundamental issue versus individual bad ram chips. If I test a memory range that is not populated with memory I get a hard fault/failure from the test, so I know the test is doing SOMETHING. Maybe going into protected mode is seeing the same thing that is causing checkit3 to detect parity errors in the memory, and the CPU crashes when the process tries to go outside of it's protected?
Or maybe checkit3 demands that I have himem.sys running? And not running it is the cause of the errors going into protected mode.
Current issue that has resurfaced is that it reliably crashes when certain software tries to put it into protected mode.
CheckIT V1: Crashes on "(2) Test EXTENDED (Protected mode) Memory only" Specifically crashes at address 0x100000, which is the first byte over 1024Kb, IIRC. Shows the testing page, reboots immediately.
CheckIT V1: Crashes on CPU test immediately after displaying "Testing Protected mode" (Crashes even if all extended memory is removed, leaving only base memory)
CheckIt V3: Seems happy, reports protected mode test is successful. Tests all extended memory (with occasional "parity errors detected" note)
NSSI 0.60.45: Crashes on startup, right after telling me that April 2022 is an invalid date. Sequence of messages in the bottom left is:
- "Please wait while determining system contents..."
- "Determining computer type..."
- "Determining presence of PCI bus..."
- "Determining processor type. checking for Cyrix..."
- "Determining processor speed..."
- "Resetting CPU..."
(Crashes here with every character of the 80x25 text mode screen displaying a "mouse cursor" , begins to POST, the crashes again with a blank screen and boots normally)
NSSI 0.60.45: I can start it in safe mode ("nssi /safe") and it won't immedately crash, but crashes on certain cpu/memory tests (will have to go to the workshop and refer to my notebook, bear with me on this)
Adding HIMEM.SYS to CONFIG.SYS in DOS 6.2 causes the PC to halt with "MAIN RAM FAIL" message. DOS 6.2 without HIMEM is fine, an di Have played Prince of Persia and Indy 500 just fine on this PC.
All the memory chips above base memory are socketed, and I removed them all and tested them in a dramarduino. They all came back fine. Deoxit / reseated, and all lines up correctly. Having said that, it crashes in CheckIT 1 with all memory (above base memory) removed, so that suggests mayeb not an individual ram chip issue (or maybe it also crashes if it finds no extended memory..?)
Questions:
I've done some reading on protected mode and I know what it's for (running more than one program at a time) and that reaching into memory owned by another app will cause the CPU to rest the system. What I don't currently understand is how to break down and test the components of that.
- Is the 32kb cache used by, and only by, protected mode?
- Is there a DOS program that will lest me test the 32kb cache?
- Is bad cache ram a possible cause of crashing on entering protected mode? I'm trying to figure out of it is worth desoldering and testing the cache ram chips?
Testing extended memory in checkit3 often gives me a parity error note, but still lists the test as passed. My next approach will be to get collections of chips and install only 512K of extended memory and see if I can pass multiple memory tests without parity errors on any chips at all. If not, there is a more fundamental issue versus individual bad ram chips. If I test a memory range that is not populated with memory I get a hard fault/failure from the test, so I know the test is doing SOMETHING. Maybe going into protected mode is seeing the same thing that is causing checkit3 to detect parity errors in the memory, and the CPU crashes when the process tries to go outside of it's protected?
Or maybe checkit3 demands that I have himem.sys running? And not running it is the cause of the errors going into protected mode.