Tandy 1000 SL with 768Kb memory. Seems possible in theory!

[CarlosTex]

I've been looking into the Tandy 1000 SL and TL tech reference manuals. These 2 seems to pretty much the same in terms of I/O port configurations.

I've took a look into port FFEA on both the TL and SL. It seems that bit 6 and 7 control the memory configuration for the system. On the TL tech ref manual there is a writtend hand note stating:

Writing 0 to bit 6 or 7, with the 128Kb upgrade installed, will diable access to memory between 80000 - 9FFFF

So if it disables that access is because setting 0 to bit 6 or 7 will make the video memory behave like the SL or in the TL as if the 128kb upgrade is not installed. Intrigued by this i wrote a small program to set my FFeA port on my Frankentandy:

IDEAL
MODEL small
STACK 32
p8086


DATASEG
value        DB "Value on port FFEA is: ", '$'
res          DB 6 dup ('$')
value2       DB 13,10,"Value on port FFEA is now: ",'$'


CODESEG

PROC hex2dec 
    mov cx, 0
    mov bx, 10
   
loop1: 
    mov dx, 0
    div bx
    add dl, 30h
    push dx
    inc cx
    cmp ax, 9
    jg loop1
     
    add al, 30h
    mov [si], al
     
loop2: 
    pop ax
    inc si
    mov [si], al
    loop loop2
    ret
ENDP  hex2dec


start:
        mov ax, @data
        mov ds, ax
        xor ax, ax
              
        mov dx, 0ffeah
        
        in al, dx
        
        push ax
        mov si, offset res
        call hex2dec
        
        mov dx, offset value
        mov ah, 9
        int 21h
        
        mov dx, offset res
        mov ah, 9
        int 21h
        
        pop ax
        mov dx, 0ffeah
        or al, 11000000b
        out dx, al
        
        in al, dx
        
        mov si, offset res
        call hex2dec
        
        mov dx, offset value2
        mov ah, 9
        int 21h
        
        mov dx, offset res
        mov ah, 9
        int 21h
               
        mov ax, 4c00h
        int 21h
        
END start

Yes i know i get the return value in decimal, but it was just easier for me, i got that code elsewhere. So trying it out i actually set the port to the right value. Before i set both bit 6 and 7 to 1 i read the port and get a value of 88 decimal or 58 hexadecimal. That's 0101 1000 in binary.

So i after i set bit 6 and 7 to 1 i get a decimal value of 216. 1101 1000 in bunary. If i run the program again the values go between 216 and 200. The reason for this is explained in the SL tech manual, that when bit 4 is read the returned bit is inverted.

In any case, after setting the port value to D8 or C8 the system locks when i try to load any program. I think the reason for this is that now when a program tries to load data into the video memory it tries to do it on the A000 to BFFF range, which of course does not exist on the SL. There is no memory in that range so the system locks. That's my theory at least.

A 768Kb memory upgrade might be possible in theory, but 2 things need to be done. Physical hardware mod on the Sl motherboard for the additional 128Kb of RAM and patching the SL BIOS to set the ports accordingly to the detected RAM. My guess is that the TL BIOS sets the FFE9 port accordingly when it detects 768kb during RAM test on POST.


Unfortunately this is not a trivial task. Tandy probably did this to justify the TL as a more desirable machine and the higher price.

 

[Eudimorphodon]

In a previous thread you mentioned you have one of those Lo-Tech RAM boards that lets you map RAM in 64k chunks? I'm curious if you've tried using it to fill the 80000 - 9FFFF space with an extra 128k of RAM and seeing if the BIOS detects it, just on the off chance it uses the same RAM counting routine as the TL. It probably doesn't but it might be worth a Hail Mary.

(In the discussion thread about building add-on RAM cards for the EX/HX we actually did some experimentation along these lines to understand if there might be undocumented-in-the-manual RAM mapping configurations for those machines that would be activated if you put 512K of base memory in it instead of 384k; Tandy actually sold a second version of the memory card for those machines that had 512k on it, so we wanted to figure out if it simply linearly mapped all the RAM in the machine into a 768k chunk. Turns out that wasn't the case and EX/HX BIOS won't intelligently handle the situation even though the hardware is almost certainly capable. The TX, which also allows 640k backfill, uses the same hardware.)

In any case, after setting the port value to D8 or C8 the system locks when i try to load any program. I think the reason for this is that now when a program tries to load data into the video memory it tries to do it on the A000 to BFFF range, which of course does not exist on the SL. There is no memory in that range so the system locks. That's my theory at least.

From what I've read there *is* a subtle incompatibility with video RAM access on the TX/TL with "768k" that affects a few Tandy 1000 programs, but I doubt that's what's happening here. (The issue being that a few programs that use Tandy graphics like writing to the spot where the frame buffer is double-mapped in lower RAM instead of the B800 CGA window; since there *is* no double-mapping in the TX/TL with 640k of "real ram" they fail.) My guess is what's happening is *if* the remapping is taking effect successfully and you're configuring the video ASIC to act like it does in an expanded TL you're suddenly effectively amputating the last 112k from end of the DOS memory space without updating BIOS values that indicate where the top of usable memory is. Off the top of my head I don't know if it's possible that in the process you might be clobbering where a transient part of command.com or something resides.

I *think* there may be some application you can run to dedicate additional RAM to video memory pages? (In BASIC there's a "Clear" command for that, I believe, but I think there may also be a DOS utility?) Perhaps if you can reserve a full 8 video pages for Video RAM before running your program you can kick the top of where DOS thinks it can allocate memory down to where it's safe.

 

[CarlosTex]

Yeah i had tried filling up 80000 - 9FFFF but in fact there's no point, that area is already filled. Filling up both A0000 up to BFFFF obviously results in a black screen, as B800 segment is reserved for CGA compatibility. I think this is all down to the BIOS, it does seem possible, but the SL BIOS just doesn't allow it.

It would be interesting to remove the BIOS ROMS from a Tandy 1000 TL and put them on an SL. I'm pretty positive that the system will boot will count the memory on the SL up to 640kb but will never set bit 6 and 7 on port FFEAh both to 1 because it only detects 128kb on the board. Using a RAM board and filling up the A000h and B000h segments might work.

A good test to try on a TL would be: remove the 128kb upgrade on the board, fill up the A000h and B000h segments with a RAM card, boot up again and see if the BIOS detects 768k. If it doesn't, it is probably due to some signal being generated on the board itself when the 4 remaining sockets on the TL are filled. In any case i expected that a hardware mod would need to be performed.

So best case scenario would be just down to the BIOS, where modifying it could enable using a RAM board to give 128kb for video. I am suspicious that if this would work it would have a huge disadvantage on my Frankentandy though. I suspect that using 16Mhz on the system wouldn't be poissible anymore. In any case a hardware RAM mod on the board would always be preferred.


Since i cannot perform the test i suggested with a TL, only thing left to try would be disassembling the SL and TL BIOS and try to figure out how they differ in terms of RAM detection. Problem is that i'm not really good at disassembling.

 

[Eudimorphodon]

Yeah i had tried filling up 80000 - 9FFFF but in fact there's no point, that area is already filled. Filling up both A0000 up to BFFFF obviously results in a black screen, as B800 segment is reserved for CGA compatibility. I think this is all down to the BIOS, it does seem possible, but the SL BIOS just doesn't allow it.

....

A good test to try on a TL would be: remove the 128kb upgrade on the board, fill up the A000h and B000h segments with a RAM card, boot up again and see if the BIOS detects 768k. If it doesn't, it is probably due to some signal being generated on the board itself when the 4 remaining sockets on the TL are filled. In any case i expected that a hardware mod would need to be performed.

So, this is a common misconception about what that extra 128kb in a TX or TL does. It does *not* reside in the A or B segments. (Annoyingly I cannot find online a technical manual for the TL, but I'm basically 100% confident that it behaves the same as the TX in this regard.) The extra RAM is mapped in the 8-9 segments so when it's installed those machines have 640k of hardwired base memory just like a standard PC.

The way a Tandy 1000 detects and configures memory is only really explained in detail in the original 1985 "Tandy 1000 Computer Service Manual". (It is really easy to miss the forest through the trees in all the subsequent "Technical Reference" manuals.) The startup procedure is laid out under "Troubleshooting the Main Logic Board" starting on page 75. The TL;DR is basically this: The RAM behind the video controller (128k in most machines except the EX and HX) "Natively" resides in the A0000-BFFFF space, but it can be selectively moved, masked, and paged so it can be used both for system memory (by mapping it into the 640k space) and page-flipped in the Bxxxx area so multiple video pages can share the CGA-compatible video window. On a standard 8088 Tandy 1000 at boot time the system, after counting fingers and toes with the planar memory at the A0000 location, starts counting up from the 00000 in 128k chunks looking for RAM. After it figures out how much RAM is present it sets the mapping registers of the video chip so the planar memory will be mapped immediately after it, with (at bootup) the last 16k marked out-of-bounds for DOS because it's *also* mapped at B8000 for video RAM.

The thing you're dealing with here is that on the 808x Tandy 1000s the memory test stops at 512k. Apparently that's as high as it will count, and it apparently insists on using the Planar RAM to fill the remainder of 80000-9FFFF. By contrast, the 1000 TX technical manual specifically says that the extra 128k lives at those addresses (See page 13 of that manual), and therefore on that machine the video chip's mapping registers are set up so the backfill behavior is disabled. Instead all the onboard connected-to-video memory is masked out except for inside the B0000 page, where it can be page-flipped.

There's plenty of reason to believe that the video IC in the non-T 1000's would be capable of setting this mode if you had RAM at 80000-9FFFF, it's just a BIOS limitation that they don't test for it. (And that's why that area is "full" on your SL; it's not hardwired there, the SL is putting the "spare" video memory there on purpose because it doesn't bother checking.) But that's where you'd want your RAM expansion to live, not A0000-BFFFF. The Tandy video chip can *only* display video using the 128k specifically wired to it, it doesn't do DMA to any arbitrary section of RAM. So additional RAM wired into the space would simply conflict with it.

 

[Eudimorphodon]

A good test to try on a TL would be: remove the 128kb upgrade on the board, fill up the A000h and B000h segments with a RAM card, boot up again and see if the BIOS detects 768k. If it doesn't, it is probably due to some signal being generated on the board itself when the 4 remaining sockets on the TL are filled. In any case i expected that a hardware mod would need to be performed.

... forgot this earlier, but this probably would be an interesting experiment to try, with the one correction that the external memory you want to see if it detects should be in the 8-9000h segments. I'm of two minds whether it would work. The Tandy TX has a physical jumper to tell it if there is RAM present there, I don't think a TL does? (Totally just a vague recollection?) The question this might answer is whether the RAM test on those machines that decides how to program the video hardware simply probes for RAM in that space the same way a standard 1000 software-probes for RAM under the 512k mark and doesn't care how that RAM is supplied, or if the TX/TL actually use a *hardware* detection routine linked to the circuitry that drives the additional 128k RAM.

EDIT: As I said, can't find the TL manual, but page 9 of the SL manual shows the MCONFIG1/0 bit settings for a 768k RAM config, in the same breath as saying it's not a supported memory configuration. I assume your program is flipping these two bits? You could try doing this with your RAM card set for the 8/9000h pages and see what happens. Booting with the card set for that and overlaying where the machine is mapping VRAM is *probably just causing bus contention, but if the machine actually boots with it set like that it *may* sucessfully be mirroring the top 128k of the 640k window, so when you flip the bit you'll still have RAM where DOS thinks the top of RAM should be. That doesn't mean that things won't immediately get clobbered anyway because the BIOS depends on being consistent about where it left things when it tries to switch video modes, of course.