View Full Version : Memory parity error when doing large disk operations?

June 15th, 2011, 08:50 AM
Hello all,

I recently acquired what is the first vintage computer i've owned in 9 years, and the second i've ever owned. It's an Epson Apex Plus with an 8088 clone CPU and 640K of RAM.

It works great, except for one problem: when doing something that involves a lot of disk work, like transferring a 100K file from a floppy disk to the hard drive, MS-DOS 5 throws me the following piece of news:

Memory Parity Non-Maskable Interrupt at C800:0747.

Then it gives me the option to (S)hut off NMI, (R)eboot, or to press another key to continue. If I continue, things resume as normal, but anything that was being copied from disk to disk is corrupted along the way.

So far, this has happened every time i've tried to install MS-DOS 5 on the hard drive (it happens whilst copying either MS-DOS.SYS or IO.SYS from Disk 2), and the result is that it finishes installing, supposedly successfully, but I just get a bunch of garbage when it attempts to boot to the new DOS install from the hard drive. It has also happened in the command prompt while attempting to transfer a ~200K file from a floppy to the hard drive (although a second attempt was successful), and in the MS-DOS Shell, while attempting to exit to the command prompt.

It is the same message every time, at the same memory address. I would hope that it is a sort of software or disk problem, but I have a feeling that it's a physical problem with a memory chip. I have no idea, though.

So far it hasn't happened when running from the original MS-DOS 3.2 floppy, although I haven't done anything rather intensive while running from that, yet.

I hope the knowledgeable folks on this forum will be able to assist me with this matter.

June 15th, 2011, 08:56 AM
You have a flakey RAM chip. DOS doesn't do anything but call your system BIOS for I/O. The address given in the message does indeed show that the NMI is hitting somewhere in your hard disk BIOS code, probably while waiting for the disk DMA to complete.

Run a good memory diagnostic and replace the failing chip.

June 15th, 2011, 04:58 PM
That's what I figured. Until I get a replacement chip (if I ever decide to), assuming I can remove the bad memory and use the computer with less for now, is it possible to remove the one chip and still use the computer, or must I remove the entire bank? Also, how can I tell which chip out of the 27 is the bad one?

Finally, are there any particular memory testing programs for DOS you can recommend?

Thanks for your help,

June 15th, 2011, 05:07 PM
You might want to start with the IBM diagnostics disk for the PC XT for testing. There are lots of others.

If you're faulting on a parity error, then no, you need all 9 chips per bank.

June 16th, 2011, 11:31 AM
Okay. Anywhere in particular I can download this disk? A search on Vetusware and a quick Google turned up fruitless for me.

DOS lives on!!
June 16th, 2011, 12:18 PM
You can find the diagnostic disk here. Yes, it's sad that Vetusware no longer works.


June 16th, 2011, 03:31 PM
Thanks! Unfortunately, I have another problem at the moment. My makeshift 3.5" DD floppies, while they work fine when transferring data from the Epson to my other computer, ultimately fail when doing the opposite.

Looks like the only way to make the diagnostic disk is to hook the 5.25" floppy drive to my other computer. I don't really want to do too much inside the Epson, because it would ruin my day if I were to break anything (although I am seasoned with working inside computers, i've never worked inside anything this old). But I guess i'll have to if I want to get the Epson fully working, especially to remove a memory bank, since they are under both floppy drives.


June 16th, 2011, 04:02 PM
Well, I was just inside the computer, and I learned something interesting - out of the three memory banks, only one is removable. That makes things easier, if that bank is the one with the bad memory chip. Otherwise, I don't know what I would do. I sure as heck wouldn't be taking a desoldering tool to the motherboard, haha.


June 24th, 2011, 01:51 PM
I finally found courage to disassemble the computer enough (which was pretty much entirely) to get to the RAM banks. I removed the one removable bank, which turned out to be 128 KB in size, leaving me with 512 KB soldered on the motherboard. I reassembled the computer, booted it to the first MS-DOS 5 install diskette, and the problem still exists. It appeared even sooner than before removing the bank, before it even started writing the first file to the hard disk. Also, now instead of the address being C800:0747, it's C800:0750.

So it appears the problem chip is soldered on the motherboard. Is there any possible way I could rectify this problem other than soldering on new banks?


June 24th, 2011, 03:25 PM
So it appears the problem chip is soldered on the motherboard. Is there any possible way I could rectify this problem other than soldering on new banks?
It may be possible. It comes down to how configurable the motherboard is at enabling/disabling RAM banks.

Example: 5 banks of 128K RAM (0 to 4) with faulty chip in bank 4. Disable bank 4. Fit memory expansion card configured to start at bank 4 starting address (512K), and sized at 128K.

Example: 5 banks of 128K RAM (0 to 4) with faulty chip in bank 3. Disable banks 3/4. Fit memory expansion card configured to start at bank 3 starting address (384K), and sized at 256K.

Example: 5 banks of 128K RAM (0 to 4) with faulty chip in bank 2. Disable banks 2/3/4. Fit memory expansion card configured to start at bank 2 starting address (256K), and sized at 384K.

June 24th, 2011, 04:08 PM
The address given by the message (e.g. C800:0747) is actually in ROM; it's the address of the instruction when the problem occurred. However, that may not mean a lot, since most 8088 MFM hard disk controllers use DMA for memory access. In other words, all you know is that the memory error occurred when the hard disk BIOS (usually located at segment C800) was executing.

As I suggested, find a good memory diagnostic.

June 24th, 2011, 04:27 PM
Ah, I see. Yes, I must make that PC/XT diagnostic diskette.

For the time being, I have some more information that would lead me to believe that this problem is not the memory itself, but perhaps the hard drive or controller (is that possible?). To start with, I successfully installed MS-DOS 5 on a set of floppy disks, instead of the hard drive. The install was flawless, as well as booting from and using DOS 5 on these floppies.

Next, I ran FDISK from the floppies to wipe the hard drive clean, re-partition it, and see what I got. While creating the new partition, I got the parity error again. This time at yet another address, C800:074E. I pressed a key to continue, and it finished creating the partition, probably incorrectly.

Next, I formatted the hard drive, and it got to 22%, at which point it started groaning loudly, and DOS gave something like "Trying to recover allocation unit 2072". Then it continued to format and finished. I'm going to guess that this was because of the parity error while creating the partition, but I thought I would mention it here anyway.

Next, I used the SYS command to transfer DOS to the hard drive, and rebooted. It would not boot from the hard drive, however. Again, this is probably because of the fudged partition creation.

However, I have used MS-DOS 5 a bit from the floppies so far, and it has worked perfect. I've done some disk work using the MS-DOS Shell, transferring a file from floppy to floppy, renaming, deleting, etc., all without a problem. I was also able to exit back to the command prompt without a problem. All of these were actions that threw me the parity error when MS-DOS 5 was on the hard drive. As such, I have a feeling that if I pretended the hard drive didn't exist and just used this computer with floppies (a task not too demanding since this computer has both 5.25" and 3.5" floppy drives), I would never see this parity error again. (Not that I will hold my breath right now.)

If it's information of any use, the hard drive in this computer originally didn't work - part of the reason it was given to me. Upon booting, the hard drive would spin up, reach a speed slower than normal, then shut down. When I took the computer home, I can only think that the ride home did something to make it work. Now, when you turn the computer on after it has been sitting a while, the hard drive still won't work, acting like before, but after the computer has been running a few minutes, turn it off, turn it back on, and the hard drive will spin up to full speed and work. It's a Kyocera KC-20B mated to a Western Digital controller, all on a hardcard.


June 26th, 2011, 01:38 PM
The PC/XT diagnostic disk is a no-go. I hooked the 5.25" floppy drive to my other computer (which runs Windows 98 and the BIOS of which supports 360K drives), and WinImage would only crash whenever it tried writing the image to a disk. I tried a different version of WinImage, same thing. I exited to MS-DOS and tried the imaging program that came with the diagnostic disk, and it wouldn't start either. I did successfully write the image to a 3.5" 720K disk, but when I tried booting it in the Epson, it only said "Boot disk failure". That could be because I use a 1.44 MB drive and 1.44 MB disks to make my 720K disks, although the Epson has had no problems with these makeshift disks except for failing to boot the diagnostic disk.

Now that I think of it, does this diagnostic disk have to be booted from, or is it possible to execute it from a running DOS environment? While I had trouble writing the disk image to the 5.25" drive, I had no problems copying files to and from the drive via Windows Explorer, so if possible I could extract the diagnostic disk contents to a 5.25" diskette.


DOS lives on!!
June 26th, 2011, 04:01 PM
You could try these utilities on this page,


I haven't had much luck with Winimage writing 5 1/4 disks. Kind of following this thread to find out how to make a diagnostic disk for my XT. For some reason, the extracting program theat came with the diagnostic disk files only makes a blank extracting file. I'll try to find a (working) copy of this disk.

To make 720k drives read a 1.44mb floppy disk, cover up the hole on the right side of the disk with tape. Copying the files to the disk with Windows Explorer won't work. The diagnostic disk does have to be booted from in order to work.

June 26th, 2011, 07:15 PM
All right, thanks, i'll have to try those.

I didn't know 720K drives were capable of reading 1.44 MB diskettes? I just thought the tape trick was so a 1.44 MB drive would think it was dealing with a 720K disk and format it as such - what I've done to many of my 3.5" diskettes. Come to think of it, since 720K disks lacked that hole on the right side, a 720K drive would have no mechanism to detect said hole, would it?


June 27th, 2011, 12:14 AM
Kind of following this thread to find out how to make a diagnostic disk for my XT. For some reason, the extracting program theat came with the diagnostic disk files only makes a blank extracting file.
Some of the DOS based image extraction programs cannot create diskettes if they are run via a CMD or DOS window - one must boot to DOS then run the image extraction program from that DOS. Maybe that's the cause of your problem.

June 27th, 2011, 09:34 AM
That's what I did. It's Windows 98, so I can exit Windows, back to DOS, via the Shutdown menu.


July 6th, 2011, 08:07 PM
Alright, I haven't been able to work with the Epson lately, so i've been unable to attempt to make the PC/XT diagnostic disk to try on it or anything else at the moment. However, I just accidentally uncovered another clue which points at the hard drive for possibly being to blame for this memory parity error upon trying to read and write to it.

To recap what I said earlier, the hard drive itself has a quirk that developed a couple of years ago. When the computer is turned on from sitting for a while, the hard drive spins up, runs for a few seconds (without ever budging the heads) then spins down, afterwards flashing the activity light indefinitely. If I wait a few minutes, turn the computer off, then turn it back on, the hard drive spins up again, a little faster, then spins down and flashes the activity light again. Then I repeat the cycle, and every time I turn the computer on again, the hard drive spins up a little faster and a little faster. Eventually, I turn the computer on, and the hard drive spins up fast enough that it stays running, performs a self-test, and works, to the point of getting the memory parity error.

I just found this video on YouTube of the same hard drive:

Listening to it spin up, this guy's drive spins up to about the RPM of mine when starting from a cold boot, and it self-tests and everything. Mine has to spin up to MUCH faster than that before initializing.

As such, I have a theory that my drive's electronics are malfunctioning in two ways, first, thinking that the drive is not spinning up fast enough when it is, and second, as the computer runs and the drive's circuit board warms up, the electronics drive the spindle motor faster then they should, and eventually they warm up enough that they drive the motor fast enough that it initializes at what they think is the correct spindle speed. As such, the drive spins at an incorrect speed, causing the problems.

Does this sound possible? If anyone wishes, I can make a video of both a cold and warm boot so you can compare the speed of the drive between the boots, as well as compare it to this person's drive.


DOS lives on!!
July 7th, 2011, 04:20 AM
It is possible. One of my hard drives and laser printers does this. I have to turn them on and off repeatedly for them to work properly. Your hard drives sounds like it's defenitely showing it's age and may be on it's way out. Have you ran SpinRite aginst it?

July 8th, 2011, 12:43 PM
SpinRite sounds like a good idea. Is there a download for it anywhere in particular though? I Googled and couldn't find a thing.

In the meantime, I unscrewed the hard drive and controller from the card so I could try it in my one modern computer with an ISA slot (it won't fit a full length card), just to see what would happen, but Windows 2000 didn't pick it up. I'll just put the controller and drive back on the card; no sense bothering trying to get that working.

I know one thing though, half of the ICs on the drive get damn HOT! I touched my finger to one IC for a second and it burned! While there is no sign of any overheating on the circuit board, there is a rather crap-looking wire running from one IC to another, presumably to replace what was a bad track on the circuit board. I tested continuity with my multimeter though, and it was fine.


October 4th, 2011, 03:56 PM
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.


October 5th, 2011, 04:33 PM
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:

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?


October 5th, 2011, 04:42 PM
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?

DOS lives on!!
October 5th, 2011, 04:44 PM
How many times did you format it before it worked? SpinRite is really finicky and will throw up a warning on any small error it finds.

October 5th, 2011, 06:18 PM
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.


May 29th, 2015, 07:22 AM
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

May 29th, 2015, 08:14 AM
I will update here whenever I have something new to share. Feel free to express any thoughts.

A much older Trent

Keep up the good fight, and get your boxen going again. :)

June 2nd, 2015, 06:25 AM
Feel free to express any thoughts.

I think you have a problem with the PSU. Check that first and then, if the PSU is OK, run a memory test using some diagnostic software like Checkit or similar.

June 6th, 2015, 04:35 PM
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.

June 19th, 2015, 05:00 PM
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

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

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.

June 20th, 2015, 03:33 AM
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

June 20th, 2015, 08:26 AM
I thought Memtest86 is 386+.

Maybe it is; I actually didn't know. I can't find a 720k copy or a way to otherwise get it on a 720k disk anyway, so I guess I'll turn to other tools.

Will try your other ideas, too. Thanks.

June 20th, 2015, 08:48 AM
CheckIt v3.0 is good, reliable and runs on an XT.

March 6th, 2016, 11:14 AM
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

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.

March 6th, 2016, 12:36 PM
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.)

March 6th, 2016, 06:40 PM
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.

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.)

I thought it might be; thanks.

March 6th, 2016, 07:39 PM
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.

Or check whether your MFM controller can change to a higher address? I know most of my cards can.


March 6th, 2016, 09:50 PM
Or check whether your MFM controller can change to a higher address? I know most of my cards can.

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.

March 7th, 2016, 02:01 PM
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?

March 7th, 2016, 02:20 PM
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:

N C000.BIN
M C000:0 8000 0100
W 0100
N C800.BIN
M C800:0 8000 0100
W 0100

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.

March 7th, 2016, 02:54 PM
Email sent. Thanks!

March 7th, 2016, 03:09 PM
OK, so the first three bytes of C000.BIN are 55 AA 40. 55 AA is the signature bytes for an option ROM, 0x40 * 512 is telling the BIOS to expect 0x8000 bytes, putting the end of the ROM at 0xC7FFF. (And, in fact, the ROM is empty past 0xC78B3.)

Mysteriously, C800.BIN is entirely filled with FFs. There's nothing there. The VGA card appears to be playing nice here. (That doesn't mean that there isn't some other conflict, but...)

What model is the HDD controller, and can you install it, and run the commands again? C000.BIN should be identical, I'd expect C800.BIN to be different. No need to connect the HDD, just insert the controller.

March 7th, 2016, 03:18 PM
The controller is a Western Digital WD1004A-WX1. It doesn't say Rev. A anywhere on the card, so I assume it's not the Rev. A version. I'll make the new files and send them to you in a bit.

March 7th, 2016, 03:43 PM
Email sent. I had the controller set back to the default address starting at C8000.

March 7th, 2016, 04:25 PM
That's interesting, because your dump has it at 0xCA000. (ROM appears to end at 0xCBDFB, but then there's 0x00s from 0xCBDFC to 0xCBFA2, then 0xFFs from 0xCBFA3 to 0xCBFFE, and a 0x25 at 0xCBFFF.)

Can you get a high quality photograph of the card? (Good enough to see any designations, as well as current jumper positions.)

March 7th, 2016, 04:34 PM
Oh whoops, I removed the wrong jumper! Do you want another dump at C8000? I'll send you a picture of the card, too.

Edit: Sent you the C8000 dump and a picture of the card.

March 7th, 2016, 09:47 PM
OK, I'm not seeing anywhere that conflicts are happening on what you sent me, the ROMs are mapping correctly. I haven't actually run the checksum algorithm against it, though.

March 7th, 2016, 10:06 PM
That's very intriguing. Thanks for looking anyway! Yet it works perfectly with the IBM CGA card, and it worked fine with the CGA card it originally shipped with. And it can be used perfectly fine as a floppy-only system. Strange indeed.

Would it be any use to provide you a dump after I get the memory parity error?