• Please review our updated Terms and Rules here

Memory parity error when doing large disk operations?

Hey all, I know it's been nearly 3 months since I last replied to this thread - I got a full-time job over the summer, and now I'm back in school. Either way, my hands have been full!

A few days ago I got the hard drive working perfectly on the Epson for the first time. The problem was just as I feared and what the helpful folks on here said it probably was - bad RAM on the motherboard. I remedied the problem by creating a RAM disk large enough to leave me with 92k of usable RAM. I was able to partition and format the hard drive and install MS-DOS 3.2 without a hitch.

Looks like I've reached an impasse. I can use the computer with the hard drive with 92k of RAM (possibly a few KB more), or with only floppy disks (to this day I have yet to receive a memory error running the computer solely from floppies) with the full 640k. My year old soldering skills are far too horrid (or maybe it's because of my dinky 25W iron or my 30 year old spool of solder) to try something as daring as replacing the RAM. Perhaps I could acquire a RAM card that disables the onboard RAM?

Anyhow, that's what's up so far on this matter.

-Trent
 
I'm currently running SpinRite II on the hard drive. It passed the Quick Surface Test with flying colors, as well as the head positioning sub-system test, but upon finishing the sector transfer timing test, I got this:

Code: 
ATTENTION!
SpinRite has determined that this drive cannot be safely formatted.
Consequently, SpinRite will be suppressing all low-level formatting on
this drive. However, SpinRite's extensive data pattern testing can
still be performed with all of the significant benefits of such tests.

Anyone have any insight on this? The first sentence kind of throws me off, as I have formatted and have attempted to format this hard drive several times before I finally got it working. I wonder what's unsafe about it? Perhaps the memory parity error plight isn't concluded yet?

-Trent
 
Spinrite is talking about "low level formatting". Certain drives (such as IDE drives, but there are others) cannot be low-level formatted, safely or otherwise.

What are you using for a hard disk?
 
It's a 20 MB Kyocera KC-20B on a Western Digital controller. I have low-level formatted it, using the built-in software on the controller. Before I knew how to execute said software, I formatted it unsuccessfully numerous times using the MS-DOS FORMAT command. After learning how to low-level format it, I tried that a couple of times, if I remember right both without success, until I made the RAM disk, after which I successfully low-level formatted it, partitioned it, and formatted it using the FORMAT command.

-Trent
 
Hello again Vintage-Computer Forums. It was 4 years ago that I created this thread, and a few months shy of that since I last posted or tackled this computer. I still have the computer, and it's still in the same condition it was in when I lasted powered it on 4 years ago. I've gained a lot of knowledge and experience over that length of time, and I'm in a position now where I want to try again and get this computer fully working.

Here are the facts as I recount them, both from my memory and from re-reading this thread:

We're dealing with a circa 1989 XT-class system, with a Kyocera KC-20B 20 MB MFM hard drive mated to a Western Digital controller. The issue is that whenever a significant amount of data is written to the hard disk (about 100 KB or more), the computer throws up a memory parity error, which you can read in my first post on this thread. Upon dismissing the error, the data write is completed, but the written data is corrupt. Situations which have brought up the error include installing MS-DOS 5, copying files from a floppy to the hard disk, and partitioning the drive with FDISK.

The drive itself also has a minor problem in which it does not spin up to full speed and initialize until the drive electronics become warm. I considered this a possible cause for the main problem, as at that point I was grasping at straws. However, I have since acquired a 486 machine that I can test the drive and controller with. I did so in 2012, and, if I remember correctly, everything functioned perfectly. I could throw as much data at the drive as I wanted, and it performed flawlessly. As such I am no longer considering the drive's spin-up problem as a cause for the memory parity issue, and I'm considering the drive and controller fully functional and not a catalyst to the main problem in any way.

When the drive and controller are removed from the computer, and it is used as a floppy-only system, it performs flawlessly. I have tried my hardest to bring up the memory parity error or otherwise crash the computer in floppy-only operation, and I never once have. I've tried running the most memory-intensive programs I could find that would fit on a 720k floppy, and it simply performed perfectly. As such, I am ruling out an actual memory problem with the computer. With that said, I have never run any memory testing programs on this machine. Now that I own some 720k floppies, and a 486 machine that should properly interface with the 5.25" floppy drive should I need to, I will get on doing that.

The computer originally operated with a CGA video card. The original owner never saw the memory parity error. The few times I used the computer when it was still in the original owner's possession, I never saw the memory parity error. When I acquired the computer, I had to swap the card out for a VGA unit. The VGA card the machine now employs is a mid 90's Trident 16-bit 1 MB card that happens to work in an 8-bit ISA slot. As such, I am considering the possibility that the video card is causing the issue. I'm thinking the next course of action with this computer is to acquire either a CGA monitor (not likely), a CGA-to-VGA converter, or an older, 8-bit VGA video card.


To summarize my hypotheses as of present:
- The hard disk and hard disk controller are not the cause of the problem
- Bad memory is not the cause of the problem
- The video card could be the cause of the problem

It very well could still be the hard disk or controller, or the memory, and I just haven't managed to cause it to occur under those circumstances. Or maybe it could be something completely different. At any rate, I'm determined to get the hard disk working correctly in this computer, and I'm going to harness the extra resources and abilities I've gained over the last four years, and tackle it once again. I'm living and working away from home where the computer is right now, but as soon as I get access to it I will begin running more tests.

I will update here whenever I have something new to share. Feel free to express any thoughts.

A much older Trent
 
Last edited:
Whoops, forgot after four years that replies don't come in my email.

Thanks guys. Sure, I'll check power supply voltages once I get a hold of the computer.
 
All right gentlemen, I've fired up the computer for the first time in 4 years. Came to life and booted from a floppy, no problem. I played around just in floppies while I waited for the hard drive electronics to warm up so it would start. Everything worked with no issue. Once the hard drive came to life, I restarted. The hard drive still contained a copy of MS-DOS and some other software that I put on it while running it in one of my 486 machines, so it booted from that no problem.

The startup sequence involved loading CD-ROM drivers for the 486 machine. Obviously this machine has no CD-ROM, so it hanged solid at loading those drivers. So, I rebooted with a floppy so I could edit AUTOEXEC.BAT and CONFIG.SYS. But instead of booting, I got an error which I don't think I've ever seen on this machine:

C8000h Optional ROM bad checksum = 7Ah
Error. Press F1 key to continue
Click to expand...

Upon pressing F1, it booted from the floppy, but the hard drive fell off the face of the earth. FDISK reported no fixed disks present. Reboots didn't reproduce the checksum error, but the hard drive still wasn't showing up. The fix was, oddly, to remove and reinsert the controller card.

Booting from the floppy and being able to access the hard drive once again, I used EDIT to edit AUTOEXEC.BAT. As soon as I hit Save, and it began to write the new file to the hard drive, I got our main error of concern once again:

Memory Parity Non-Maskable Interrupt at C800:0750.
Type (S)hut off NMI, (R)eboot, other keys to continue
Click to expand...

I shut the computer off and turned it back on. It booted, and AUTOEXEC was weirdly corrupted. A couple of lines were repeated, and some letters were turned into other letters, or symbols.

I'm starting to wonder now if I actually might be dealing with a flaky drive controller or drive? When I go back to my apartment on Sunday I'll bring this machine with me, and I'll test the hard drive again in one of my 486 machines. Also, power supply voltages are perfect.

In the meantime, I'm gonna see if I can get MemTest86 and some other diagnostic software you guys have suggested onto 720k floppies to run on this thing.
 
I thought Memtest86 is 386+.

Maybe do the following on your harddisk controller (also not a bad idea for the other parts of your system):
- try to re-seat any socketed chips
- clean the ISA bus contacts of the card with a rubber (soft side)
- you should make a backup of your controller ROM chip while it still passes the test sometimes
 
Sorry once again for the 9-month hiatus. I never did get back to this computer - I spent the summer playing with some slighty newer machines I had recently acquired.

I think I may have finally found the solution to this 5-year long problem - I recently discovered the excellent minuszerodegrees.net, and found this blurb on the page about hard disk controllers and VGA video cards:

In the IBM 5160, IBM reserved the 32KB sized address space of C0000 to C8000 for any BIOS expansion ROM on a video card. The ROM on XT-class hard disk drive controllers typically starts at C8000. According to Microsoft's Q63588 article, the ROM on some VGA cards extends past C8000
Click to expand...

This confirms the theory that someone gave me a few years ago, which I posted here last year - that VGA video card I stuck in there isn't playing nice with the MFM controller. The memory parity error references C800 rather than C8000, but it's worth a look anyway. I recently acquired an IBM 5155, whose CGA video card has a composite television output, so I'm going to stick that card in the Epson, boot it up, and see if the hard drive works as it should. I will report back.
 
Last edited:
C800:0000 is the same as C8000, for what it's worth. (A side effect of Intel's approach to memory addressing, and IBM's approach to reporting the error as a result.)
 
A 5-year mystery has been solved. It was indeed the video card. I stuck my 5155's CGA card in the Epson, and formatted the hard drive, installed MS-DOS 5, and completely filled the hard drive with arbitrary files, all with zero problems.

Thanks to everyone who responded to this thread and helped me out. The next step is to see if there's a VGA card that's known to not extend into the hard disk controller's memory space. I'll make a new thread for that, if one doesn't exist already.

bhtooefr said:
C800:0000 is the same as C8000, for what it's worth. (A side effect of Intel's approach to memory addressing, and IBM's approach to reporting the error as a result.)
Click to expand...

I thought it might be; thanks.
 
Last edited:
bobba84 said:
Or check whether your MFM controller can change to a higher address? I know most of my cards can.
Click to expand...

I forgot all about that! I think vwestlife told me that a couple of years ago, and I tried it and it didn't work. I could be thinking of something else though, so I'll take a stab at it tomorrow. If I remember right the controller is a WD1004-WX1, which does have jumpers to set the address. I will try it and report back.
 
No dice. I can set the controller's address to start at CA000, and then the memory parity error occurs, citing CA00:750. If I try the other two addresses, the controller falls off the earth and is detected by neither the BIOS or FDISK.

The video card is a Trident TVGA8900CL. I've tried all the configurable settings on that card, to no avail.

Any other ideas?
 
Remove the hard drive controller entirely, give it a floppy with DEBUG.COM and at least 64 KiB free.

Start DEBUG, run the following commands:

Code: 
N C000.BIN
R BX
0000
R CX
8000
M C000:0 8000 0100
W 0100
N C800.BIN
M C800:0 8000 0100
W 0100
Q

You'll have two files, C000.BIN and C800.BIN. Post them somewhere and link them, or if you don't have somewhere to post them, send them to my username at gmail dot com.
 
You must log in or register to reply here.
Back
Top