• Please review our updated Terms and Rules here

Mitsubishi 386 - Crashes going into protected mode

Scruit

Experienced Member
Joined
Apr 9, 2022
Messages
105
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.
 
The cache would be used in both real mode and protected mode.
I don't know of a tool that tests cache specifically. The cache would be tested as part of a standard memory test since memory accesses will go through the cache.
Bad cache RAM should show up all the time.
Check the BIOS. Most systems with cache had an option to turn the cache off. If the system still crashes with the cache turned off, it would be likely that the cause lies elsewhere.
Without HIMEM, any software trying to use XMS to access extended memory will fail. HIMEM is not needed to go into protected mode nor to access extended memory with programs like IBM's VDISK.
 
Thank you for your response.

It's an older bios that doesn't appear to have the option to turn cache off. In fact, I only have GSETUP to work from right now.

I'm embarking on a more intensive test of the memory chips. I'll remove it all back to base memory and work from there upwards.

Thanks!
 
Check the motherboard for any breaks in the traces running from the memory expansion card. If no bad RAM has turned up in tests, motherboard flaws would have to ruled out. I am hoping what little information I can find on the Mitsubishi systems is close to accurate for the specific hardware.

Could you post the types of chips installed? Another longshot but maybe there would be an identifiable clue. I remember that some 3-chip and 4 MB SIMMs didn't work with 386 systems.
 
Are you using the specific A20 handler for this machine?

Thank you for your response.

Checkit 3 is specifically lists the processor type as "80386 AT Machine (A20 Active)"

I am currently running a memory check with all of the socketed extended memory removed, so only the base 1024m is in place. Checking for parity errors that are randomly causing a "note" in CheckIT 3, although not specifically failing the test. I'm trying to break it doesn and test small areas at a time to see if the parity error could be a problem with individual ram chips, or overall/systemic
 
Check the motherboard for any breaks in the traces running from the memory expansion card. If no bad RAM has turned up in tests, motherboard flaws would have to ruled out. I am hoping what little information I can find on the Mitsubishi systems is close to accurate for the specific hardware.

Could you post the types of chips installed? Another longshot but maybe there would be an identifiable clue. I remember that some 3-chip and 4 MB SIMMs didn't work with 386 systems.

Thank you for your response.

This PC does not have SIMM slots. It has individual m5m4257 in rows of 9 chips (256 Kbit, so 8 = 256 kbyte, plus one more for parity).

I started mapping out the connections on the daughterboard (where the memory is) to see if anything stands out. I'm hoping to be able to logically narrow it down to a group with some commonality that might help point me at a particular row/column/chip. If not an individual chip, then maybe an octal bus transceiver is bad and taking out a whole column, or address line.
 
As I recall, the keyboard interface wound up controlling A20, maybe it is bad?

Thank you for your response.

Interesting. I'll take a look at that. I'll have to take a closer look at the pics I took of the disassembled parts to try to find the keyboard controller type, and grab a datasheet if I can.
 
https://jeffpar.github.io/kbarchive/kb/096/Q96711/ lists the command line switches that go with HIMEM. I don't see anything that would be relevant but seeing what HIMEM reports when run in verbose mode can't hurt.

Thank you for your response.

I will give that a shot. Right now I'm finding the memory parity errors have gone away after removing the extended memory and the IDE controller. I will be adding select memory chips back in until I can get 512kb of extended memory that passes memory tests with no parity errors nopted, then I will attempt himem.sys.
 
The point is that if the switching is done through the BIOS, then you're fine. However, Windows and many other programs use their own A20 handlers rather than the BIOS version.
 
Back
Top