Tandy 1000 RLX and XT-IDE V3

[Eudimorphodon]

In my RLX-B with the ADP-50, the drive list is as follows:

Out of curiosity, what are you using to grok the int13 drive assignments? I tried Checkit 3 and Norton Sysinfo 6, and neither seems to tell you that particular piece of info. I can confirm after switching the SD card that has Tandy 3.3 on it back into the HX that my memory that the ROM drive shows up is correct; if I use Norton to check out what disks are available there's not hide nor hair of it under PC-DOS 7, while under Tandy 3.3 it shows up as a 47k D: drive between the C: and E: drives (C: and D: under DOS 7). It's been a while but my vague recollection is if you had two hard disks the primary partitions on the two physical drives would show up first, followed by the extended partition drives, so I assume it must be assigning the XTIDE drive as 80h and ROM as 81h or higher... but again, only seems to happen with Tandy's DOS.

 

[Cloudschatze]

Bump and solution/workaround for 2024!

As a quick problem summarization, the XTIDE Universal BIOS fails to initialize in a Tandy 1000 RLX-B system unless an XTA drive (or comparably configured XTA2SD board) is also installed/present on the motherboard header. This problematic behavior does not occur with the RLX-A.

A salient difference between the RLX-A and RLX-B is that the former will disable the ROM drive when an internal disk or disk expansion adapter is present, whereas the latter will not. I recently made a one-byte modification to the RLX-B BIOS that short-circuits the ROM drive setup routine. With this change, the XUB initializes as expected, and without the need/presence of an XTA drive.

I'll create a separate post to include the modified RLX-B BIOS image, as well as some additional variants that contain updated VGA BIOSes.

 

[acadiel]

Bump and solution/workaround for 2024!

As a quick problem summarization, the XTIDE Universal BIOS fails to initialize in a Tandy 1000 RLX-B system unless an XTA drive (or comparably configured XTA2SD board) is also installed/present on the motherboard header. This problematic behavior does not occur with the RLX-A.

A salient difference between the RLX-A and RLX-B is that the former will disable the ROM drive when an internal disk or disk expansion adapter is present, whereas the latter will not. I recently made a one-byte modification to the RLX-B BIOS that short-circuits the ROM drive setup routine. With this change, the XUB initializes as expected, and without the need/presence of an XTA drive.

I'll create a separate post to include the modified RLX-B BIOS image, as well as some additional variants that contain updated VGA BIOSes.

Sweet, thanks for finding that. This made it full circle for me as the OP.

I wonder what is different about the ROM drive in this unit that causes these issues? My only issue with workarounds is the ROM based stuff for Deskmate. If there's a way to duplicate that and still disable the ROM drive, we're good.

 

[Cloudschatze]

My only issue with workarounds is the ROM based stuff for Deskmate. If there's a way to duplicate that and still disable the ROM drive, we're good.

The short answer is that yes, the RLX-B's ROM-based DeskMate version 03.04.03 is fully usable and functional even with the BIOS modification to support the XUB.

And now for the longer answer...

I'd never used DeskMate in ROM on any of my RLX systems, and had to look into this a bit. My understanding of how this works on the RLX-B is that DESK.COM and the hidden DESK.HID are initially launched/loaded from the letter-accessible ROM drive, and SPL.RES, DMGUF.R89, DMMDP.RES, DMCSR.R89, DESKTOP.PDM, DMVSVGA.RES, and PRGUF.RES get paged-in via the E000-EFFF window thereafter.

The BIOS modification for XUB usage prevents the ROM drive and files from being presented in DOS, but doesn't affect the ROM paging and access, so the only real issue to be addressed is that DESK.COM expects to find DESK.HID in the root of the drive-letter assigned to the ROM drive, as defined by the byte at 40:C2h of the BDA.

With that in mind, DESK.COM would ideally be modified to remove that behavior/limitation, but I haven't yet determined how, exactly, it's accessing the BDA information. So, for now, I've simply copied DESK.HID to the root of D:\ (needs to be a drive or mapped substitution other than where the full DeskMate install is), and have set 40:C2h with a value of 04h to match.

Et, voila.