TL;DR: I’ve patched the pc.boot file so that an XTIDE (or any other Option ROM) works perfectly while maintaining the ability to use amouse, aread & awrite. You need:

• An XTIDE bios with the VERY_LATE_INIT option (it definitely works with the current ide_at.bin from r625: https://www.xtideuniversalbios.org/binaries/r625/)
• To set up your XTIDE to any memory address less than 0xD000 (I am using 0xC800)
• Either:
  • The modified pc.boot file in this directory (https://github.com/jfharden/bridgeboard-pc-bo … working-pc-boot); or
  • Patch your own pc.boot file with the program I wrote (https://github.com/jfharden/bridgeboard-pc-bo … releases/latest)
• To be using Janus 2.1 (which includes janus library v36.83)

I really wanted to get my XTIDE to work in my Amiga 2000 with the A2286 bridgeboard, and with amouse, aread, and awrite able to work. I saw that at least one person had luck by writing the XTIDE ROM into the pc.boot file, but I found no matter where in the pc.boot file I put it if i was trying to use amouse, aread, or awrite, DOS and/or the Amiga would crash. I had even heard “maybe Option ROMs don’t work with the bridgeboard”.

I knew that definitely wasn’t true since if I turned off mapping the memory (the choices being off, A000, or D000) the XTIDE worked, it also worked when set to A000, but with that setting you can’t use amouse, aread, awrite so that was out.

I had a look at the pc.boot file and found at 0x400 within the file was an Option ROM, meaning an Option ROM at D400 when the memory segment used is D000. It was also clear to me if the XTIDE was set to anything in the D000-DFFF range it isn’t visible, so the bridgeboard is completely obscuring anything in the D000-DFFF range. Option ROMs for booting are only valid below E000, so there’s no chance of setting the XTIDE to be in the E000-EFFF memory space (I tried, I had to hardware mod my XTIDE card to force it into the E000-EFFF range, and it’s visible, but the BIOS just ignores it since it isn’t looking for standard option roms in that memory region).

So I set about reverse engineering the ROM in the pc.boot file, I used GHidra to disassemble it and spent a lot of time learning X86 assembly (and more often than I would like having to learn the actual machine language instructions where the disassembler wasn’t understanding it), learning how Option ROMs work, learning about the original IBM XT Bios (thanks to the original reference manual still being available online).

Anyway after months of on and off coming back to it and gradually understanding more of it I hit the jackpot. There’s a segment where it looks if hard disks are ready (meaning a physical hard disk which the actual BIOS is configured to be able to access, and is working), then if it is ready the ROM overwrites the INT13 (hard disk access) vector to run hard disk access through a routine within the ROM. If the hard disk is not ready, it still overwrites the INT 13 vector (and sets it to a different routine than the previous one within the ROM), but it also overwrites INT 19 (which is a vector that the BIOS will return to after all other setup is done). Crucially these are the 2 vectors which are the possible operating paths of the XTIDE. This explains why the XTIDE doesn’t work (and in fact no booting option roms will work as far as I can tell), since the INT vectors it sets to work are totally overwritten by the pc.boots Option ROM.

I tried patching the ROM so that it skips past the 2 different hard drive initialisation paths, I also had to update the final byte of the ROM to make the checksum routine the BIOS does to validate the ROM as a valid Option ROM. I made a program to do all this automatically, it searches an input file for an Option ROM (in our case searches a pc.boot file for an option ROM), then searches within that ROM to find the HDD ready check, and patches the result of that check so it jumps past all the hard disk initialisation routines, updates the option rom checksum, and then writes our a patched pc.boot file.

As you can imagine this could be quite brittle depending on the version of the pc.boot file and how much the HDD init code in the pc.boot file has (or hasn’t) changed. I’ve only tried it with the Janus 2.1 version (which has Janus Handler version 36.85, and Janus Library version 36.83), but now I can successfully boot from the XTIDE with its complete functionality, and also use amouse, aread, and awrite and it is absolutely stable.

I was happily running Planet X3 using the shared amiga keyboard, a PicoGUS (in adlib mode) for sound, a 1MB VGA card, and the XTIDE with a CF card for the primary hard drive. The mouse using amouse works perfectly, and I can reliably copy files to/from the amiga with aread/awrite and all with no instability.

I haven’t tried it but I am quite certain you wouldn’t be able to use the ‘virtual hard disk’ from the amiga, since I’m quite sure the routines that make that work are what I am skipping in the ROM.

The code for the patching program I made is all open source and available on Github, it’s written in rust (I’ve been looking for projects to do in rust, and this seemed perfect).