• Please review our updated Terms and Rules here

Tandy TL/2 and HIMEM.SYS

I tried as you said, and it gives me even less upper memory (48k) from C400 -CFFF. No additional ram.

Are you running a VGA adapter? I saw a note indicating that you won't get the full amount of ram if you are using 16 color because it allocates it for video use.
 
Thank-you for trying that. I'm hoping to do the same with the EMS-5150 card either today or tomorrow, and am curious to see if the outcome is any different...

I do have a VGA card installed in my TL/2, but if the system has been upgraded to 768K (which you seem to have done), the result should be the same.
 
So, at the moment, it seems that you can obtain, with the lo-tech 2MB EMS board, either 2MB of EMS or 64KB of UMB, but not both at the same time.

Perhaps an ultimate board would essentially be the 1MB RAM board and the 2MB EMS board on one card, which should do both and more. C'mon James, you know you want to make it! :)
 
I did toy with the idea of adding a 62-pin header/socket on the boards, such that both boards could be installed in a single slot. But I was thinking more of the 5150 - is the TL short of slots?
 
I did toy with the idea of adding a 62-pin header/socket on the boards, such that both boards could be installed in a single slot. But I was thinking more of the 5150 - is the TL short of slots?

You can never have enough slots! The SX, SL, SL/2, TX and TL have five slots, the TL/2 and TL/3 have four, the original 1000 has three and the RL and RLX just have one. Expansion cards can have 10" maximum length in a Tandy.

Tandy used a 62-pin header (the PLUS connector) on its 512KB & DMA Expansion card where you could install another expansion board without having to use up or block a precious slot. Tandy released serial, modem, clock + mouse, and PLUS/4 network boards. Then they used it in the EX and HX computers, much to everyone's annoyance.
 
I'm hoping to do the same with the EMS-5150 card either today or tomorrow, and am curious to see if the outcome is any different...
So, as tested, and using the LIM EMS 4.0 driver, the Micro Mainframe EMS-5150 behaves the same as James' board does with QRAM - UMBs are provided with the "FORCEEMS" switch, but sans additional EMS.

For now at least, it seems the Acculogic card is still the most feature-laden EMS solution for Tandy systems. They're dastardly difficult to obtain, however...
 
So, as tested, and using the LIM EMS 4.0 driver, the Micro Mainframe EMS-5150 behaves the same as James' board does with QRAM - UMBs are provided with the "FORCEEMS" switch, but sans additional EMS.

For now at least, it seems the Acculogic card is still the most feature-laden EMS solution for Tandy systems. They're dastardly difficult to obtain, however...

It's actually the FL=0 flag that gives you the 64k of UMB with the Tandy TL/2. Some games require more conventional ram anyways, and this is a great option that I didn't knew you could to until you mentioned QRAM.

Is it free to distribute the QRAM.SYS file? If so, James should add it to the site as an option for using the card as UMB space.

I'll try the card with QRAM.SYS on my Tandy 3000nl, which is a true 16-bit 286 with a VGA card and see if the results are any different.
 
Well, the 3000NL 286/12 machine does not like the 2MB EMS card no matter the setting. C000 and E000 boots with a continuous beep. D000 I can boot successfully, but trying to do anything, and I get severe lockups. QEMM installed makes things even worse - it allocates space, but freezes almost immediately after running.

Guess there are some machines that this card was not meant for.
 
The 2MB EMS card. I can provide some more details if I run a diagnostic on the system.

It's a fairly unique system that requires you to tell it how much ram you have via a SETUPNL utility (which updates the bios).

It uses cards (like the one below) to expand the memory, which may mean it has compatibility problems with generic cards.

57.jpg

If you need some more details, i can probably run a diagnostic to see what is being used in address space.
 
Last edited:
I think my TL/2 is unable to run himem.sys.

Is this a limitation of the TL/2 architecture? I've tried every flag for machine type with "himem.sys /cpuclock:eek:n /machine:#" with no luck.
Circling back to the original question, the 286-based Tandy 1000 systems implement an I/O-based A20 gate control, using bit 1 of port 68h. From what I can tell, this is similar to, if not exactly the same as, the "Fast" implementation standardized in IBM's PS/2 at port 92h (as also found in Tandy's own 1000 RLX).

Perhaps I'm overlooking something obvious, but if HIMEM.SYS (XMGR.SYS, HIMEMX.SYS, etc.) can be patched/recompiled to support 68h as an A20 handler, and assuming a memory expansion card is installed to provide it, can the Tandy TX/TL(2/3), in fact, utilize extended memory?

Edit: Nevermind, this is a much larger undertaking than previously supposed. There really doesn't appear to be a great/easy means of getting the additional address lines out to an expansion card. Thanks again for crippling the 1000 line, Tandy!
 
Last edited:
Indeed, the problem is that there are only the twenty address lines available on an 8-bit slot.
 
As an interesting parlor trick, I was able to to allocate 8MB of expanded memory as extended memory using Quarterdeck's EMS2EXT.SYS driver, and afterward leveraged QEXT.SYS to manage that as XMS. Granted, it's not actually usable as such, but it did fake out at least one program that had previously refused to start otherwise.


What's really a shame is that the DRAM controller used in the TX and TL systems supports an additional megabyte of memory in the 100000-1FFFFF range. This capability went unused, but appears to have at least been partially implemented with the TX motherboard...

This is mostly conjectural, but per the technical reference manual, it looks like 128K of extended memory can be had in the TX by:

- Installing four 64K x 4 DRAM chips in the unpopulated/unmarked positions beside U54, U55, U56, and U57.

- Installing a jumper at E7-E8, thereby selecting "Memory Configuration 4," which is defined as follows:

BANK0BANK1BANK2CONTROLADDRESS RANGE
512KRas0000000-07FFFF
128KRas1080000-09FFFF
128KRas2100000-11FFFF
- Enabling the A20 gate, using the aforementioned port 68h control (through a modified handler).

BAM!
 
Last edited:
As an interesting parlor trick, I was able to to allocate 8MB of expanded memory as extended memory using Quarterdeck's EMS2EXT.SYS driver, and afterward leveraged QEXT.SYS to manage that as XMS. Granted, it's not actually usable as such, but it did fake out at least one program that had previously refused to start otherwise.


What's really a shame is that the DRAM controller used in the TX and TL systems supports an additional megabyte of memory in the 100000-1FFFFF range. This capability went unused, but appears to have at least been partially implemented with the TX motherboard...

This is mostly conjectural, but per the technical reference manual, it looks like 128K of extended memory can be had in the TX by:

- Installing four 64K x 4 DRAM chips in the unpopulated/unmarked positions beside U54, U55, U56, and U57.

- Installing a jumper at E7-E8, thereby selecting "Memory Configuration 4," which is defined as follows:

BANK0BANK1BANK2CONTROLADDRESS RANGE
512KRas0000000-07FFFF
128KRas1080000-09FFFF
128KRas2100000-11FFFF
- Enabling the A20 gate, using the aforementioned port 68h control (through a modified handler).

BAM!




Cloud:

Did all of this come to you in a dream or in tablet form? :D That's some good work! Seriously, how did you figure it all out?
 
Did all of this come to you in a dream or in tablet form? :D That's some good work! Seriously, how did you figure it all out?
Yeah, burning bush and whatnot. ;)

No, it was just a matter of poring over the tech refs. Keep in mind that it's still just conjecture at this point. I would certainly love to test the theory, but lack a TX myself. It shouldn't be a terribly difficult modification though - involving soldering-in four DIP sockets and a 2-pin header - if some enterprising TX owner would like to further the cause of academia and volunteer.


Following-up on my statement about emulated extended memory, I would like to mention that, while the XMS "trick" using QEXT.SYS was bogus, and only resulted in the system claiming to have XMS memory, the extended memory provided by EMS2EXT.SYS is actually valid and usable, but ONLY when accessed indirectly, through the (archaic) INT 15 interface. Older versions of VDISK.SYS, RAMDRIVE.SYS, and SMARTDRV.SYS support the use of extended memory in such a manner, and I completely validated the use of an 8MB virtual disk in the emulated space, but various versions of these utilities also happen to natively support EMS directly, so it's not as terribly impressive a feat as it might be otherwise.
 
various versions of these utilities also happen to natively support EMS directly, so it's not as terribly impressive a feat as it might be otherwise.

EMS is much higher performance than XMS anyway; on a hardware board, window switches are instant, whereas all versions of XMS copy memory around in blocks. So other than getting a program to run that wouldn't, there's really no reason to do this :)
 
Yeah, burning bush and whatnot. ;)

No, it was just a matter of poring over the tech refs. Keep in mind that it's still just conjecture at this point. I would certainly love to test the theory, but lack a TX myself. It shouldn't be a terribly difficult modification though - involving soldering-in four DIP sockets and a 2-pin header - if some enterprising TX owner would like to further the cause of academia and volunteer.

I happen to have a pristine Tandy TX, and might be willing to try over the holidays!
 
So other than getting a program to run that wouldn't, there's really no reason to do this :)
Agreed. Still, there's something satisfying about seeing extended memory on a system that really shouldn't have it. :)

I happen to have a pristine Tandy TX, and might be willing to try over the holidays!
On further reflection, I'd suggest holding off until some additional information can be obtained. Perhaps you can help with that instead...

1. It looks like a capacitor needs to be installed beneath each DRAM chip. These aren't documented, but ought to be the same as those used for the U54 - U57 expansion sockets (found underneath the DRAM chips, if already installed). Are those capacitor values readable?

2. It's still just assumed that the extra DRAM sockets are tied to the DRAM controller, given the lack of actual circuitboard layer schematics. While a full pin trace would be ideal, it would be great if at least pins 4 and 5 for one of the uninstalled sockets could be traced-out. On a revision "A" motherboard, pin 5 should route back to pins 1/16 of the RP10, resistor pack DIP, and then back to pin 40 on the DRAM controller IC. In a revision "C" motherboard, the connection from the DRAM controller to RP10 is presumed to not exist, and perhaps even from the resistor pack to the DRAM circuitry as well.
 
I'll have a look at the motherboard tonight. I think I may be able to remove it so I can take some high res pictures for reference.
 
Back
Top