A20 control or jumper is maybe what you need to fiddle with.

Suspect I'm going to have to trace all the jumpers as there isn't a single one labelled, nor is there a motherboard on TH99/UH19 that remotely matches mine. Lots of VL82C200's, but none that are the same.

There's a note in the TLB chipset manual that indicates the VLSI shadow ram enable/relocate state is toggled by a certain pin on the vl82c202 IC. I may have to take a close look at where that goes.

megatron-uk wrote on 2021-05-27, 15:37:

There's a note in the TLB chipset manual that indicates the VLSI shadow ram enable/relocate state is toggled by a certain pin on the vl82c202 IC. I may have to take a close look at where that goes.

There is, should be as simple as finding continuity with a multimeter from that pin (pin 69 on the VL82C202) to the jumper header.

Logic high enables shadow ram.

(BTW I strongly recommend UMB_DRVR over TLB for this chipset)

Ah, I didn't realise umb_drvr also supported it. I'll have to have a look at that as well.

might also look into the old amisetup program to fiddle around with settings unavailable in the bios.

I found the jumper that seems to control shadow RAM and/or memory sizing:

J16, when set to 3-4 (I'm numbering from board edge inwards) gives a BIOS memory count during POST of 4096KB and TLB produces the error previously shown (pin #69 was showing as tied to ground with that jumper in place). If J16 is left unset, the BIOS memory count is 3712KB and TLB loads:

However, it's incredibly unstable in this configuration - keyboard input at the command line is enough to lock things up. I need to try UMB_DRVR as recommended to see if it is just TLB causing the instability, or this particular jumper configuration in general.

The behaviour you described sounds completely normal (other than the instability)

Setting jumpers usually pulls the signal logic low. Shadow RAM enable is active high.

There should be no impact on stability from simply unsetting the jumper, it's got to be TLB. Try running the system with the jumper unset and no UMB provider loaded as a control

Yep it's definitely TLB. I've run it with config.sys bypassed and it's fine. I've also now installed UMB_DRVR 5.22 using /c=02 and it detects and converts the shadow ram region to ~170KB or thereabouts of free UMB's:

No instability. So that's got to be down to how TLB was programming the memory controller IC.

One thing I need to do now is figure out how to exclude certain ranges from UMB_DRVR, as by default is uses all of the regions that my EMS card (an 8MB Everex EV178) uses for its page frame. I guess that will be listed in the manual, as its going to be a fairly common thing to need to do.

So umb_drvr.sys uses a weird dots-and-dashes mechanism for determining what to do with each 16kbyte block in the 640-1024 region. i.e.

device=c:\drivers\umb_drvr.sys /c=02 /m=........................

That's the default behaviour, with each 16kb block being used for UMB unless it has a ROM in it, in which case it is (usually) excluded. It automatically shadows ROMs too, which is neat; so I get my XT-IDE BIOS shadowed for free, which with this very basic AMI BIOS itself I had no option to do.

If you want to 'protect' a range from being turned into a UMB, then you insert a '-' into its place. So for me, my Everex card places a 64kb page frame at C8000. So I think that means:

device=c:\drivers\umb_drvr.sys /c=02 /m=..........----..........

And that does indeed cause umb_drvr to not use that region for UMB memory (and the available UMB drops by a corresponding amount), but the Everex driver still refuses to load, complaining that it is unable to find a free page frame. I uncomment umb_drvr and the Everex EMS driver loads again (with all 511 EMS pages 🤣!).

Can you adjust your Everex card to use D000-DFFF instead? And then exclude that region in UMB_DRVR?

Or maybe just load the Everex driver first?

The latter works just fine, except for the fact that the Everex EMS driver takes up another 15KB of conventional memory doing it that way.

I can try shifting the page frame around, but I'll need to alter where the XT-IDE BIOS appears via the 3Com card... and for some reason it's not letting me save the updated card settings back.

IME device drivers for hardware EMS boards don't take kindly to being loaded high period. You might just have to load it low and live with it

maxtherabbit wrote on 2021-05-27, 21:26:

IME device drivers for hardware EMS boards don't take kindly to being loaded high period. You might just have to load it low and live with it

IME device drivers ?

IME: in my experience

...

... and I think this is the crux of it. It doesn't matter how much of the reserved memory region I tell umb_drvr to exclude, if I try to load emm.sys high, it complains about not being able to find space for the page frame. If I leave it to load into conventional memory, it appears to be happy (and respects the address of the page frame I give it).

The only difference between these two outputs is the first is loading emm.sys as device=c:\...., and the second is loading it as devicehigh=c:\.... all other parameters are identical:

I think that's just going to be what I'll have to live with.

Edit: Also, I forgot to mention, the Everex driver wants an 80KB page frame - not just 64KB. I only spotted this via CheckIt, where it reported that the size of the EMS frame that had been installed was not 64KB as I expected.

Many LIM 4.0 EMS cards are capable of having a page frame larger than 64kB, and will often automatically fill up any space available in the UMA to them (in 16kB page increments). There is generally little to no benefit to using a page frame above 64kB and you can probably control this with switches on EMM.SYS

Isn't the whole point of LIM 4.0 EMS that it can do large page frame mode?

Unfortunately there exists no manual for the EV178, just the emm.sys driver and one config exe to change the eeprom settings on the card.

No jumper or switch block details.

There is a driver for a similar card (a 10mb version) which does list some flags to emm.sys, but there's no page frame sizing amongst them - just page fram base address, number of EMS handles and a 'verbose' initialisation mode.

Anonymous Coward wrote on 2021-05-28, 05:30:

Isn't the whole point of LIM 4.0 EMS that it can do large page frame mode?

Not really, I'd say the "point" was being able to map pages in and out of conventional memory with register writes

That's what large page frame mode is.
With LIM 4.0, you can have multiple page frames larger than 64kb, and you can also locate them in conventional memory.