Eudimorphodon
Veteran Member
As the thread title indicates, lately I've been fooling with an idea for increasing the amount of upper memory space available in a Tandy 1000 HX. To recap, the major internal difference between the HX and the otherwise similar EX is the HX has a whopping 128K of BIOS ROM, which according to various sources and spelunking on my own is set up like so:
E0000-EFFFF: Personal Deskmate resources (64k)
F0000-F001F: Simple ROM-DOS BIOS option ROM. (.5k)
F0020-FBFFF: Minimal DOS 2.11 FAT filesystem (47.5k)
FC000-FFFFF: Phoenix/Tandy PC BIOS. (16k)
The EX only has the 16k BIOS, although because of incomplete memory decoding all 64k of the F-page is still effectively off-limits. However, the "E" page is available for UMBs, EMS page frames, whatever.
Anyway: while looking through the HX's tech manual I found that the ROM is decoded by a PAL at position "U16", and the equations are in the manual:
According to the equations ROM enabled when A19, A18 and A17 are high (IE, CPU in the top 128k of the memory map) unless pin 14, labeled ROMDIS, is pulled low. Checking the schematic indicated that ROMDIS is just permanently tied to a pull-up resistor, R21A:
So... I attached a test clip to the U16 side of R21A and checked with the logic probe to see if the state on that pin was ever anything but high; it wasn't, so I proceeded with experimenting with my homemade memory board that can map upper memory blocks and an EMS page frames using GALs as decoders.
To try to make an already long story as short as possible: first I tried putting upper memory and/or an EMS page frame in the "E" page by simply configuring the switches on my memory board to think it was in an EX instead of an HX and connecting the jumper wire to U16 pin 14 to pin 19 on the 74HCT245 that sits in front of all the memory devices on my board; that seemed like it should work, since it would effectively let the expansion board trump ROM if anything on it clashed. And that worked, just fine. Dropping the EMS frame into E0000-EFFFF and testing with Checkit confirmed no conflict.
(And, for the record, when just the E-page is overridden the DOS-in-ROM is still there and can be booted, it has no apparent dependency on the E-page contents. Presumably the HX version of Personal Deskmate won't work, but I didn't try it.)
Here's where things get weird: Since the DOS-in-ROM "driver" presents itself as a normal BIOS extension my next test was to reprogram the GAL on my memory board to try replacing the built-in DOS with the XTIDE BIOS stored on a flash chip on the card. That didn't work; the DOS ROM *is* overridden, but peek-ing around at the F0000 mark shows garbage that's neither the built-in ROM nor the XTIDE BIOS. Here's the weird part, though: this "garbage" is only present from F000-F1FFF; I had the GAL configured to override 32k, and after the F2000 mark PEEK-ing shows nothing but zeros, which is expected; the ROM is blank except for the first 8k.
After several iterations of being sure I must have made a mistake in my GAL programming for the ROM mapping I decided to remove the dependency on the memory buffer and set up a spare I/O pin as independent signal that would effectively disable all but the last 16k of the built-in ROM, no matter how things were otherwise set up on the board. This works as expected, the ROM DOS is gone, but things are still weird over the F000 mark. Here's what I see when I peek around that area:
1: From E0000-EFFFF if I don't map anything there the area is full of "7",s; this is what you see on this machine if you peek in an unoccupied area of upper memory, so the "ROMDIS" line seems to be completely doing the needful.
2: From F0000-FBFFF there's "garbage" that's mostly decimal 240, with the occasional 176. The "176s" are different from run to run, like the data lines are just floating.
Whether I piggybank off the buffer signal or go with the separate line pulling down ROMDIS the results are still the same if I try putting my ROM at F0000; I get garbage. I haven't yet tried dumping it to see if it has some bitwise relationship with the ROM contents, but... I'm kind of at a loss. Does anyone have any idea why the HX treats the F-page differently from the E-page if the ROM is disabled? (And, even more specifically, why it seems to be treating the 8k from F0000 to F2000 even more strangely, since it seems like the ROM override is working okay from F2000 to F8000?) I'd suspect that the PAL equation was incomplete, but there's no connection from the PAL to A16 so far as I can tell it can't tell the difference between E and F. Staring at the schematics haven't given me any "aha!" moments.
E0000-EFFFF: Personal Deskmate resources (64k)
F0000-F001F: Simple ROM-DOS BIOS option ROM. (.5k)
F0020-FBFFF: Minimal DOS 2.11 FAT filesystem (47.5k)
FC000-FFFFF: Phoenix/Tandy PC BIOS. (16k)
The EX only has the 16k BIOS, although because of incomplete memory decoding all 64k of the F-page is still effectively off-limits. However, the "E" page is available for UMBs, EMS page frames, whatever.
Anyway: while looking through the HX's tech manual I found that the ROM is decoded by a PAL at position "U16", and the equations are in the manual:
According to the equations ROM enabled when A19, A18 and A17 are high (IE, CPU in the top 128k of the memory map) unless pin 14, labeled ROMDIS, is pulled low. Checking the schematic indicated that ROMDIS is just permanently tied to a pull-up resistor, R21A:
So... I attached a test clip to the U16 side of R21A and checked with the logic probe to see if the state on that pin was ever anything but high; it wasn't, so I proceeded with experimenting with my homemade memory board that can map upper memory blocks and an EMS page frames using GALs as decoders.
To try to make an already long story as short as possible: first I tried putting upper memory and/or an EMS page frame in the "E" page by simply configuring the switches on my memory board to think it was in an EX instead of an HX and connecting the jumper wire to U16 pin 14 to pin 19 on the 74HCT245 that sits in front of all the memory devices on my board; that seemed like it should work, since it would effectively let the expansion board trump ROM if anything on it clashed. And that worked, just fine. Dropping the EMS frame into E0000-EFFFF and testing with Checkit confirmed no conflict.
(And, for the record, when just the E-page is overridden the DOS-in-ROM is still there and can be booted, it has no apparent dependency on the E-page contents. Presumably the HX version of Personal Deskmate won't work, but I didn't try it.)
Here's where things get weird: Since the DOS-in-ROM "driver" presents itself as a normal BIOS extension my next test was to reprogram the GAL on my memory board to try replacing the built-in DOS with the XTIDE BIOS stored on a flash chip on the card. That didn't work; the DOS ROM *is* overridden, but peek-ing around at the F0000 mark shows garbage that's neither the built-in ROM nor the XTIDE BIOS. Here's the weird part, though: this "garbage" is only present from F000-F1FFF; I had the GAL configured to override 32k, and after the F2000 mark PEEK-ing shows nothing but zeros, which is expected; the ROM is blank except for the first 8k.
After several iterations of being sure I must have made a mistake in my GAL programming for the ROM mapping I decided to remove the dependency on the memory buffer and set up a spare I/O pin as independent signal that would effectively disable all but the last 16k of the built-in ROM, no matter how things were otherwise set up on the board. This works as expected, the ROM DOS is gone, but things are still weird over the F000 mark. Here's what I see when I peek around that area:
1: From E0000-EFFFF if I don't map anything there the area is full of "7",s; this is what you see on this machine if you peek in an unoccupied area of upper memory, so the "ROMDIS" line seems to be completely doing the needful.
2: From F0000-FBFFF there's "garbage" that's mostly decimal 240, with the occasional 176. The "176s" are different from run to run, like the data lines are just floating.
Whether I piggybank off the buffer signal or go with the separate line pulling down ROMDIS the results are still the same if I try putting my ROM at F0000; I get garbage. I haven't yet tried dumping it to see if it has some bitwise relationship with the ROM contents, but... I'm kind of at a loss. Does anyone have any idea why the HX treats the F-page differently from the E-page if the ROM is disabled? (And, even more specifically, why it seems to be treating the 8k from F0000 to F2000 even more strangely, since it seems like the ROM override is working okay from F2000 to F8000?) I'd suspect that the PAL equation was incomplete, but there's no connection from the PAL to A16 so far as I can tell it can't tell the difference between E and F. Staring at the schematics haven't given me any "aha!" moments.
Last edited: