Hacking a Tandy 1000 SL BIOS

[CarlosTex]

Hi there everyone!

As everyone knows the Tandy 1000 SL machines allow only 640KB RAM onboard, and a part of that memory is reserved for video. The amount of reserved memory is defined by what is configured at the serial EEPROM.

So i've been thinking about this:

1. ROM BIOS must have a RAM check routine and then reserve the amount for video on the top end RAM.

2. ROM BIOS must stop checking after 9FFFFh physical address, as the motherboard does not support any more than that.

3. Tandy 1000's must have special circuitry that map the reserved video memory to be mirrored on the B000h segment for monochrome and CGA compatibility.

4. C000h and D000h are allowed for option ROM's and/or UMB's.

5. E000h segment for DOS/DESKMATE ROM and must have additional circuitry for page flipping to access the rest of the DOS/DESKMATE ROM; F000h segment for system BIOS.

6. A000h segment can't be accessed by Tandy 1000 SL at all, unless special hardware is used, like a VGA card, that includes RAM and a BIOS to actually use it.


So points 2 and 6 are the most interesting to me. Using a lotech 1MB RAM card and adding memory on the A000h segment does nothing at all and no software can find it. So i've been wondering if the Tandy 1000 SL system BIOS can actually be patched to force detection up to AFFFFh.

The point of this is to actually use the A000h segment for video memory, to allow a Tandy 1000 SL to have the full 640kb for DOS, much like a 1000 TL does.

I see 3 things that stop me from doing this:

1. I have no idea how to properly disassemble ROM BIOSes, as i only done that to .EXE and .COM files.
​​​​​​
2. If i manage to successfully disassemble the BIOS, i have to actually patch it correctly, and that could be difficult as i am inexperienced with ASM code.

3. Even if i manage to do the 1 and 2 points correctly i would have to find compatible chips and burn them to swap the originals on the motherboard.


Any help is appreciated, whether its advice, tools or whatever. You can also call me stupid, if you think the idea is stupid or otherwise impossible, but make your case why that is.

 

[CarlosTex]

Can someone point me to a tool that can at least disassemble a ROM BIOS? I would like to have a look at the Tandy 1000 SL system BIOS

 

[alank2]

Check my thread here:

https://www.vcfed.org/forum/forum/genres/pcs-and-clones/80902-format-with-write-protect-on

Someone posted a site that had some disassembled Tandy BIOS's using IDA.

 

[Eudimorphodon]

(snip)
2. ROM BIOS must stop checking after 9FFFFh physical address, as the motherboard does not support any more than that.
(snip)
So points 2 and 6 are the most interesting to me. Using a lotech 1MB RAM card and adding memory on the A000h segment does nothing at all and no software can find it. So i've been wondering if the Tandy 1000 SL system BIOS can actually be patched to force detection up to AFFFFh.

I kind of think this was discussed before, but just in case I'm curious: have you by any chance ever tried using your lo-tech card to map RAM from 80000-9FFFF? (IE, in the 512k-640k block.) Here's why I ask:

First off I'm going to preface this with the proviso that I've only immersed myself in the tech manuals for the "X" series (EX/HX/SX/TX) machines and thus can't be 100% positive everything applies to the "L" series, but on the older machines at least this is how RAM works on them:

1: When the machine is first turned on the 128k (or 256k in the case of the EX/HX) that's "owned" by the video chip is mapped so it only appears, page-flipped, in the Bxxxx address range. This "video-owned" RAM corresponds to the *only* RAM that was present in the original 1000, and technically speaking these machines don't "steal system RAM" from DOS, they share unused video RAM the other direction.

2: After counting fingers and toes to make sure the video RAM works the memory test for expansion memory kicks off. The old machines count in 128k chunks starting from 0000h and work their way up; I assume the SLs probably do something similar but it's possible their tests might behave differently to take into account that they all by default have dedicated "expansion RAM" built in, in addition to video RAM.

3: Once the machine finds the top of "expansion RAM" it adjusts the video chip registers so the memory it owns is placed *after* the CPU-owned memory, and then the BIOS top-of-memory flag is set (at least) 16k below the end of *that* to reserve enough RAM for CGA graphics, unless one of these two things is true:

A: You have an EGA/VGA card, in which case the Tandy puts its built-in video to sleep and just sets the BIOS top-of-memory to the end of the video memory, giving it all to the CPU, OR:

B: You have a "T" machine (TX/TL) that was expanded to "768k". In that case that additional 128k of memory you added is the block from 512-640k and there's no more need to backfill up to 640k with video memory. In that case the video hardware is set up to keep all the video memory to itself and page it around within the A0000-BFFFF area. I don't think the "X" series machines (can?) actually use Axxxx but the L-series can put video memory there, that weird hack that lets you fake the VGA 256 color mode with the SL/TL 640x200x16 mode relies on that.

The architecture of these machines prevents anything but memory "owned", as in physically wired to it, by the video chip from being able to display graphics, so putting memory at A0000 "to use as video memory" is a non sequitur. Therefore the only way to get your full 640k in your SL would be to relieve it from having to share the 128k of video memory with DOS by filling the space between 80000-9FFFF with RAM like the TX and TLs can.

So, this is where we get back to BIOS hacking: according to the tech manuals indications are that all machines using the Big Blue chip (X-series) and later would theoretically support being expanded to 640k of CPU-wired memory and treating video like a 768k TX or TL does, paging it around "up there". I've actually experimenting with poking the TX register values into my HX and confirming that it makes the video memory mapped under the 640k mark "go away" while video keeps happily humming along. The problem is I don't believe the BIOSes in the non-T-machines actually supports it, IE, they won't count up to more than 512k CPU-wired memory and switch to "TX" video handling even if the hardware is there. (But I haven't definitively tried it myself, I don't have the hardware. Which is why I think using the low-tech to fill the 512k-640k window is the litmus test to see if a BIOS hack is actually necessary.)

I have to say, if I could find a BIOS hacking god interested in the problem I'd be totally willing to try piggybacking a RAM chip to one of my homemade HX expansion boards so it has a full 640k of wired conventional memory and see if a hacked TX BIOS could tie everything together. The same hacked BIOS would probably work on an SX plus a lo-tech card.

 

[Eudimorphodon]

FWIW, I dug out the 1000SL tech manual, and there's a lot of good information in there. Search it for "8079024", which is the part number for the do-all buffer/CPU control/DRAM control ASIC. This section is very interesting:

[FONT=TimesNewRomanPSMT]DRAM [/FONT][FONT=TimesNewRomanPSMT]Control [/FONT]

[FONT=TimesNewRomanPSMT]The CPU address decode for the Dynamic Random [/FONT][FONT=TimesNewRomanPSMT]Access [/FONT][FONT=TimesNewRomanPSMT]Memory [/FONT][FONT=TimesNewRomanPSMT](DRAM) [/FONT][FONT=TimesNewRomanPSMT]array [/FONT][FONT=TimesNewRomanPSMT]is [/FONT][FONT=TimesNewRomanPSMT]generated
by the 8079024 custom (U41). These [/FONT][FONT=TimesNewRomanPSMT]signals [/FONT][FONT=TimesNewRomanPSMT]are [/FONT][FONT=TimesNewRomanPSMT]latched by ALE internally [/FONT][FONT=TimesNewRomanPSMT]to [/FONT][FONT=TimesNewRomanPSMT]the 8079024 custom[/FONT]
[FONT=TimesNewRomanPSMT]IC [/FONT][FONT=TimesNewRomanPSMT]and held for the complete cycle. The address decode signals [/FONT][FONT=TimesNewRomanPSMT]are [/FONT][FONT=TimesNewRomanPSMT]RASO-, RAS1-, RAS2-, RAS3-
and CAS-. Memory configurations supported by the Tandy 1000 SL [/FONT][FONT=TimesNewRomanPSMT]are [/FONT][FONT=TimesNewRomanPSMT]256K, 512K, [/FONT][FONT=TimesNewRomanPSMT]or [/FONT][FONT=TimesNewRomanPSMT]640K bytes
(in addition [/FONT][FONT=TimesNewRomanPSMT]to [/FONT][FONT=TimesNewRomanPSMT]128K [/FONT][FONT=TimesNewRomanPSMT]of [/FONT][FONT=TimesNewRomanPSMT]video memory). The following table shows the different options available
on the 8079024 custom [/FONT][FONT=TimesNewRomanPSMT]IC. [/FONT]


[FONT=Courier New]Memory MCONFIGl MCONFIG0 System Total System
Option                   Memory Memory*
0      0      0          256K   384K
1      0      1          512K   64OK
2      1      0          512K   640K
3      1      1          640K   768K
* Note: Total system memory includes 128K of video memory.
Memory Option 0 is the power up default. [/FONT]

Long story short; according to the tech manual the Tandy engineers who designed the SL intended it to support "768k mode" internally; my copy of the tech manual has docs for the 8079024 chip and explains what that "memory option" column means, and options "2" and "3" involve configurations incorporating a single bank composed 512k, with or without another 128k bank made of four 64kx4 DRAMs. Obviously this is an issue because the motherboard is wired to only support four 128k banks. The schematics show the MA8 line that'd be required for a 512k bank heading off sheet2 to the one that has the memory sockets, but that only has MA0-7 mentioned, so apparently somewhere along the line an idea to do this got dropped on the floor.

This raises interesting questions about how the BIOS sorts all this out. According to the datasheet for the DRAM controller part it selects "memory options" based on two bits of a control port at FFEAh (Same register used for ROM banking, apparently.) I'm curious if the BIOS even tries options 2 and 3; if it does an ambitious idea for expanding these machine's memory would be to come up with a daughterboard that would plug into one of the four sets of sockets that make up a 128k bank, clamp onto MA8 and use four 256kx4 (1 megabit) chips to give you a 512k bank so "Memory Option 3" takes effect.

 

[CarlosTex]

The schematics show the MA8 line that'd be required for a 512k bank heading off sheet2 to the one that has the memory sockets, but that only has MA0-7 mentioned, so apparently somewhere along the line an idea to do this got dropped on the floor.

This raises interesting questions about how the BIOS sorts all this out. According to the datasheet for the DRAM controller part it selects "memory options" based on two bits of a control port at FFEAh (Same register used for ROM banking, apparently.) I'm curious if the BIOS even tries options 2 and 3; if it does an ambitious idea for expanding these machine's memory would be to come up with a daughterboard that would plug into one of the four sets of sockets that make up a 128k bank, clamp onto MA8 and use four 256kx4 (1 megabit) chips to give you a 512k bank so "Memory Option 3" takes effect.

I had read the tech manual before and thought that there's maybe a way to do that, but i don't know enough of electronics to allow me to design such a daughterboard. In any case the BIOS ,might be hardlocked to actually never test the other options which means it has to be hacked.

The Tandy 1000 RL is very similar to the SL in the way it uses an 8086 too, so i wonder if the BIOSes between the RL and SL are interchangeable. Even if the SL BIOS needs hacking i wonder what kind of chips need to be used, i have a MiniPro programmer but the mask ROMs in the SL seem to be a bit obscure...

The SL is a great machine, with great potential, as some might know i unlocked the potential of my SL by doing a very simple mod, replacing all 150ns DIP RAM with 70ns ones, replacing the 8086 with a V30HL and cranking up the oscillator to 50MHz, gives me a system speed as fast as 16.6Mhz. Unfortunately the conventional memory limit really brings the system down, and a mod allowing it to go to 640kb or even 704kb by extending up to the A000h segment, like i did with my XT's would really take the system to another level, and pretty much run well all Tandy 16 color games. The V30HL at 16.6Mhz really puts my SL ahead of any TL.

 

[Eudimorphodon]

I had read the tech manual before and thought that there's maybe a way to do that, but i don't know enough of electronics to allow me to design such a daughterboard. In any case the BIOS ,might be hardlocked to actually never test the other options which means it has to be hacked.

I guess the only way to know would be to either build the hardware and try it, or disassemble the BIOS and suss out enough of the RAM test to see what options it tries. If I had an SL I'd probably consider taking a crack at the hardware, I don't think it'd be particularly complex. Don't have the datasheets in front of me but I suspect it'd be little more than just simply matching up the matching signals between the 18 pin 4464 chips and the 20 pin 44256's and route in MA8 via a jumper wire.

(My first 286 motherboard had DIP sockets, and the upper bank used this interesting arrangement of offset pin rows so you could populated it with either 64kx4 or 256kx4 chips plus the matching 1-bit wide parity chips for either 640k or 1MB of RAM. Maybe Tandy intended to do like this for one of the banks but thought the "better" of it. Also not sure about the availability of the 1Mbit chips at the time, which would make the other option having to have 16 1-bit sockets... feh. Basically it gets really complicated to have to support 384k as the starting memory option if you also want to do 768k)

Did you try the experiment of mapping your Lo-Tech board to the 512k-640k range to see if memory hanging off the expansion port after the built-in RAM gets tested and added to the total? (And therefore triggering the BIOS to move the video memory mapping to the "768k" configuration based on the aggregate total?) I'm skeptical it'll work because they've probably rewritten the RAM test to only assume that conventional memory is provided by the built-in hardware, but if you haven't tried it I'd still consider it worth a shot.

The Tandy 1000 RL is very similar to the SL in the way it uses an 8086 too, so i wonder if the BIOSes between the RL and SL are interchangeable. Even if the SL BIOS needs hacking i wonder what kind of chips need to be used, i have a MiniPro programmer but the mask ROMs in the SL seem to be a bit obscure...

If it's anything like the HX I'd guess that they're mask ROMs that don't quite have a programmable equivalent, but it probably wouldn't be too hard to come up with a socket adapter for a Flash part like an SST39SF series.

Unfortunately the conventional memory limit really brings the system down, and a mod allowing it to go to 640kb or even 704kb by extending up to the A000h segment, like i did with my XT's would really take the system to another level, and pretty much run well all Tandy 16 color games.

As I mentioned, it looks like the Tandy II 640x200x16 video mode needs the address space from A0000-AFFFF so 704k probably isn't an option if you don't want to break compatibility with the few games that use that.

 

[CarlosTex]

I guess the only way to know would be to either build the hardware and try it, or disassemble the BIOS and suss out enough of the RAM test to see what options it tries. If I had an SL I'd probably consider taking a crack at the hardware, I don't think it'd be particularly complex. Don't have the datasheets in front of me but I suspect it'd be little more than just simply matching up the matching signals between the 18 pin 4464 chips and the 20 pin 44256's and route in MA8 via a jumper wire.

(My first 286 motherboard had DIP sockets, and the upper bank used this interesting arrangement of offset pin rows so you could populated it with either 64kx4 or 256kx4 chips plus the matching 1-bit wide parity chips for either 640k or 1MB of RAM. Maybe Tandy intended to do like this for one of the banks but thought the "better" of it. Also not sure about the availability of the 1Mbit chips at the time, which would make the other option having to have 16 1-bit sockets... feh. Basically it gets really complicated to have to support 384k as the starting memory option if you also want to do 768k)

I'm more than willing to try it out, but it is the designing part that i can't wrap my head around. I could probably follow a schematic and build something to try it, but i wouldn't know to design it properly. But i favor this solution. I can probably source fast 256x4 chips which would go well with the 70ns 64x4 ones i currently have and allow me to keep my 16Mhz clock speed. Once i start putting RAM into the ISA slot i don't think it will be able to keep up.

Did you try the experiment of mapping your Lo-Tech board to the 512k-640k range to see if memory hanging off the expansion port after the built-in RAM gets tested and added to the total? (And therefore triggering the BIOS to move the video memory mapping to the "768k" configuration based on the aggregate total?) I'm skeptical it'll work because they've probably rewritten the RAM test to only assume that conventional memory is provided by the built-in hardware, but if you haven't tried it I'd still consider it worth a shot.

I surely did but it only counts 640k. I think the BIOS probably only counts to the penultimate 64kb segment and never checks for 9000h segment, since memory is only mapped to this are when you adjust the video memory.

If it's anything like the HX I'd guess that they're mask ROMs that don't quite have a programmable equivalent, but it probably wouldn't be too hard to come up with a socket adapter for a Flash part like an SST39SF series.

That would be great, again i can probably build an adapter if i have some instructions. I think at the moment a complete disassembly of the Tandy SL BIOS is needed, or at least a dissassemble of the critical memory part we might need to patch.

As I mentioned, it looks like the Tandy II 640x200x16 video mode needs the address space from A0000-AFFFF so 704k probably isn't an option if you don't want to break compatibility with the few games that use that.

I'd be more than happy to lose compatibility with Tandy video II, surprising as this might be. The high res 16 color is cool, but it would only break compatibility with games that would use that resolution and 2 video pages. I think even Planet X3 only uses 1 video page so the 64kb for the higher res 16 color mode is enough. In the end the added conventional memory would be much more important. If i manage to do that, i think i could probably "retire" the XT from my desk and use the SL for everything 1980's. Since i'm using dual oscillators and a switch i can probably use an oscillator that gives me IBM PC approximate speeds.

 

[Eudimorphodon]

I'm more than willing to try it out, but it is the designing part that i can't wrap my head around. I could probably follow a schematic and build something to try it, but i wouldn't know to design it properly. But i favor this solution. I can probably source fast 256x4 chips which would go well with the 70ns 64x4 ones i currently have and allow me to keep my 16Mhz clock speed. Once i start putting RAM into the ISA slot i don't think it will be able to keep up.

I think the hardest part would actually be the physical build, since you'd need to make a circuit board that piggybacks into four of the existing memory sockets. It'll take some careful measuring to get it to fit smoothly.

I surely did but it only counts 640k. I think the BIOS probably only counts to the penultimate 64kb segment and never checks for 9000h segment, since memory is only mapped to this are when you adjust the video memory.

The memory test of the older machines checks in 128k blocks, not 64k, because the granularity of the mapping registers in the Big Blue chip that adjust the starting point of the system memory mirror is 128k. I suspect, unfortunately, that the memory tests in the newer machines that have sockets for memory other than that associated with the video chip don't just "try" and see if a 128k block under the 640k mark is empty or not (IE, check to see if it got filled with arbitrary third party expansion memory) anymore, they've probably modified it to instead check jumpers/exercise config registers/whatever to specifically see how much memory they have installed "natively".

The registers that configure "Big Blue" are independent of the DRAM controller's RAM size register, so in *theory* a whack experiment you could try is configuring the Lo-Tech card for the 512k-640k block and then running a program that forces the "TX/TL" 768k setting into the video chip's register. This will unmap it from under the 640k mark, after which you could try POKE and PEEK-ing the address space to see if it "sees" the memory on the Lo-Tech card, or if there are issues preventing bus-connected RAM from working at all, like buffers on the motherboard driving the bus *whenever* it's under the 640k mark regardless of memory size. (This, unfortunately, is a real possibility.) A long time ago I posted a BASIC program that puts an original Big Blue into "768k" mode, I don't know off the top of my head if the BB2 chip in the SLs is compatible enough for that to work, but the addresses are in the service manual.

*IF* the above experiment actually worked it raises the possibility you could stick something in config.sys to patch things up to make it use 128k on an expansion card, but I suspect there's more to it than just hard-slamming the registers and manually poking a new top-of-memory into the BIOS data area; my guess is that the machine will still think it needs to adjust the memory size to the video mode whenever you set modes using the BIOS calls if you don't also find whatever flags control it knowing it's on a "768k" machine and do bad things.

I'd be more than happy to lose compatibility with Tandy video II, surprising as this might be. The high res 16 color is cool, but it would only break compatibility with games that would use that resolution and 2 video pages. I think even Planet X3 only uses 1 video page so the 64kb for the higher res 16 color mode is enough.

It's remarkable how bad the documentation for the Tandy II video modes is, but I kind of suspect that just pretending you don't care about its use of the "A" page might not be an option. At the least you're likely to have an ugly crash if something inadvertently makes it "wake up" over an active 64k DOS extension.

If you're able to combine a theoretical "768k" mod with adding some UMB memory it's not hard to get the DOS conventional memory footprint down to 9k or so, which I'd think would be adequate for just about anything.