http://atariage.com/forums/topic/244946 … try4032449

Instead of assuming the content of the OS ROM, it would be safer to simply look up the address via HATABS, whose "E:" entry points to $E400. In turn, the GET vector in the table at $E400 is $F249 (EGETCH-1). Same result.

The FDISK.COM stub loader requires the three OVL files on CAR: to have the hidden (+H) attribute set, but this was overlooked and that's why it won't run. You can fix this yourself in the SDX Imaging tool (set +H on FDISK*.OVL), but I reminded Trub about it anyway. ;)

I see. In that case, one extra thing I can point to is the PLCC flash ROM used on the older (black) board. They were usually Amic (occasionally AMD too?) chips and sometimes replacing the flash ROM with an SST part can make a very big difference to system behaviour (as much as turning a non-booting system into one which works).

Anyway: thanks for positive feedback on firmware. You'll finally see an update this week, I promise. :)

Well, BIOS update 1.5 certainly made the XE throw up (unless the towering instability off what's hanging off the ECI caused communication issues), but the 600XL is still going strong:

EDIT: XE worked after I cleaned IDE Plus's ECI pads with Isopropyl alcohol. :)

Dual IDE/CF adapter. Here's a close-up:

Note female mini-IDE connector at left is not broken. Header is made from two different sections and arrived that way when the device was bought. :)

On an XE, one is of course forced to connect SIDE2 via IDE Plus's built-in cartridge port, and if that obscures the SIDE2's IDE registers somehow, it's hardly the fault of U1MB or SIDE2. Likewise, one's personal experience may vary depending on how much equipment is hanging off the bus. I merely show that the combination works as it is designed to do here on my desk, and that U1MB does not break any existing protocols. FDISK could not communicate with multiple IDE host adapters had this not been tested on real hardware, and here you see it with your own eyes. ;)

Yes: drive number conflict resolution cannot be managed between drivers, so one must carefully avoid conflicts on different devices, otherwise (as Pin says) those on SIDE will take precedence. Of course this is not necessarily the case if you use the U1MB PBI BIOS (which makes more sense on the U1MB machine). Then it's a question of which PBI handler the OS calls first (this will depend on the PBI device ID on the U1MB and IDE+).

It's said that XBIOS allows for the loading screen, but no music plays and the exact same progress bar animation could be accomplished by splitting the binary into multiple segments and having an INIT stub called between each one which updates the progress indicator. Using the segmented approach would have allowed the thing to load via the SIO (and thus via a PBI HDD) without alteration. Of course games saves would need a different approach, but that feature appears almost as desirable as the inability to load the game from a hard disk. :)

https://www.youtube.com/watch?v=yL8ZIpa_RRQ

Although the naming is confusing, the APT version of FDISK is the currently maintained partition editor and the only one capable of building APT partition tables.

As for "seeing" disks: I can't comment on FDISK2's methods, but with APT FDISK, it's really a question of whether the PBI HDD driver will detect media, not the application itself. FDISK issues STATUS and DEVINFO commands and simply reports back the results returned by the driver (this is how the partition editor remains hardware abstracted).