Just realized that Marvin might not be the best section for this topic - if any admin feels this is the case, please move this to a more suitable subforum.

IIRC when IDE was introduced, the primary master channel used the same ports as the old MFM/RLL interface. This would normally not be a problem, since most people (then) would be unlikely to have both controller types in the same system.

What hardware are you emulating? Is there an MFM/RLL or IDE controller in the emulated system? I'm just wondering whether the wrong controller type might confuse the XTIDE firmware. For that matter I don't even know whether XTIDE appears to the system like a "real" IDE controller, or whether it's a completely different interface, relying on the firmware to provide access to the devices. In that case it's possible the firmware would misbehave if the XTIDE hardware itself was missing.

However the fact that you've got it to come up during boot suggests that everything is working fine as far as your ROM-in-RAM method goes. I didn't know you could do that - very interesting!

On an unrelated note, I've often thought about designing an ISA card you could slot in to a PC to use as a debugger, but I didn't think there'd be much interest in it. Looks like this is one situation where it could come in handy though (assuming it doesn't work in the real PC - doesn't sound like you've tried yet?)

PCEm, when configured as a PC/XT-class machine, presents a normal 8-bit IDE interface (I did look at its source code) at port 300h. The XT-IDE board is just that - a regular ISA IDE interface which can be configured to listen to different ports, defaulting to 300h. I know this ROM works because, if I copy the file to the "roms" subfolder, PCEm loads it as an option ROM and it boots from HDDs normally. I suspect it is a difference of context: something is different either in the IVT or registers or even memory, but I've inspected XTIDE's source code and it does zero out the memory it uses at segment 030h for its variables, and it doesn't look like it assumes anything about the registers. If only I could set a breakpoint and dump both memory and registers I might be able to tell the difference, but PCEm doesn't do that, and Bochs, which does allow that, does not emulate a pre-Pentium machine, and doesn't even execute a XT-class BIOS image without throwing errors.

What I might try doing is loading an HDD floppy option ROM and test if it works fine. But besides editing XT-IDE's code itself and dumping debug info on the screen, I'm out of ideas.

Are you loading the option ROM into the same address space? It's not something like it has to be loaded at x000 rather than xD00 as in the screenshot above?

Is there any way you can skip the disk detection and finish the boot process with the ROM loaded into RAM, so you can dump the memory with debug or similar to confirm that the image is intact? You said you've done this with skipping int19, but maybe int19 changes the memory in some way?

Can you make the ROM take up more memory (say a full 64kB and put it at 9000) in case the boot process tries to write to that part of memory for some reason? (Perhaps something writes there to see if the system has 640kB RAM, instead of checking the BIOS value.)

These are just random suggestions, I don't claim to have any great insight 😀

Malvineous wrote:

Are you loading the option ROM into the same address space? It's not something like it has to be loaded at x000 rather than xD0 […]
Show full quote

Are you loading the option ROM into the same address space? It's not something like it has to be loaded at x000 rather than xD00 as in the screenshot above?

Malvineous wrote:

Can you make the ROM take up more memory (say a full 64kB and put it at 9000) in case the boot process tries to write to that part of memory for some reason? (Perhaps something writes there to see if the system has 640kB RAM, instead of checking the BIOS value.)

I've tried several different values to no avail before even posting here, even 64kb. Makes no difference (unless I use a value that is too small, then things just go boom)

Malvineous wrote:

Is there any way you can skip the disk detection and finish the boot process with the ROM loaded into RAM, so you can dump the memory with debug or similar to confirm that the image is intact? You said you've done this with skipping int19, but maybe int19 changes the memory in some way?

Will try that, thanks for the suggestion.

Btw, I replaced XT-IDE with an HD floppy ROM, and same thing happens (freezes when trying to boot after the firmware is loaded).

You could try it in MAME (which merged with MESS), which has an awesome debugger, and I've heard the pre-386 system support is pretty good. 😀

Color me impressed... it actually boots fine on my XT clone. Only god knows what went wrong on PCEm. Well, I stil have to see if it is working 100%. FDISK from Compaq DOS 3.31 is taking its sweet time... It is on the screen to create a primary partition, and already returned that the total disk space is 1023 cilinders.... but it is reading this old 700MB HDD like crazy as if it were trying to read something else. Is it normal for it to take so long? If this goes on long enough I might try MS-DOS 6.22.

IT LIVES!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
My 700MB HDD doesn't play nice with my 16-bit multi-IO card (probably doesn't support 8-bit mode), but my CF card boots fine! I did not even format it, I just plugged it in and the existing MS-DOS 6.22 install booted fine! Sure, I'll have to sort this out since 12KB of RAM is nothing to be sneezed at when your machine has only got 512, but alas! It works!!!!!
I'll update the first post when I get around to properly commenting my modifications to the original version. As situational as this might be, I'm proud of this little 1KB binary fine. By the end of the day I feel I learned a few more things about PCs, and that is fine by me.

Btw, what DOS version do you guys feel is best for a XT-class machine. It will soon have the full 640KB, but unless I get around to adding UMBs to this machine, would DOS 3.3 be better than 6.22 due to lower memory usage? Its default shell is garbage, but 4DOS runs fine on anything above 2.0.

I just wanted to say thanks for this. I'd been trying to do something similar when I found your post. I've created a step-by-step guide in this thread on the VCFed site: http://www.vcfed.org/forum/showthread.php?525 … nstead-of-EPROM