Looking for EMS Driver for VLSI VL82C311L (SCAMP DT-286) chipset

[sqpat]

I have a pretty fast 286 board I've been working on with a really late 286 chipset. There a driver online (VLEMM.SYS) for the VL82C311 chip (not VL82C311L), which is the 386SX version of this chip. When I run that driver it says EMS is disabled, regardless of the "Global EMS Control" option in the BIOS's on or off setting.

I was wondering if anyone had a driver for this. The boards using this chipset were primarily the PCChips m218 and the Biostar MB-1220VE or MB-1216VE. According to the chipset documentation, there was a custom phoenix bios for some VLSI boards with a "Phoenix Extended Memory Manager (PEMM)", but I've never heard of this and can't find that driver either. There are "VEMM" drivers online for a much earlier VLSI chipset that aren't compatible and didn't support hardware EMS anyway. Given how detailed the chipset documentation is, i suppose it's possible to write a driver, but I'm holding out hope this exists online somewhere.

 

[maxtherabbit]

I believe that driver should work for both versions of the 311(L)

 

[sqpat]

Well, the driver did come from a 311 board and says 311 on it and doesn't work - I have seen evidence of it working on a 311, and someone on a russian forum with the other 286 311L board had the same issue as me.

I tried the other (pcchips m218) BIOS and the BIOS is almost the same, it's only lacking a few clock and wait state configuration items - the EMS behaviors and switches are all the same. Just one switch for "global EMS control" which doesn't seem do anything.

Another possibility of what is going on - the BIOS has no way to edit the amount of memory allocated to Expanded or Extended memory like many other 286 EMS compatible boards/BIOSes. It automatically allocates 640k, then all non-conventional memory to extended. Even if I try to 'trick' it by adding more memory before power on and skipping the bios configuration screen, all the newly added ram is detected and allocated as Extended by the time the OS has booted. So it could be an issue related to no memory being available to the driver for EMS. If there were some chipset tool I might be able to edit those fields directly. Maybe i'll try poking into the CMOS contents. (Is there a program out there that dumps or writes CMOS fields ?)

 

[Svenska]

Some 286 systems will always allocate non-conventional memory as XMS (no BIOS options). The EMS driver will then "steal" some of that XMS memory from MS-DOS and configure the chipset for EMS instead.

 

[sqpat]

Some 286 systems will always allocate non-conventional memory as XMS (no BIOS options). The EMS driver will then "steal" some of that XMS memory from MS-DOS and configure the chipset for EMS instead.

Oh ok, I hadn't run into such a board before. So maybe this is a BIOS settings problem, then.

So I read through the chipset documentation here and figured out the i/o ports I need to write to to read and write to the chipset registers to change EMS settings. On page 33, it shows the EMSEN1 and EMSEN2 "configuration registers" at 0Bh and 0Ch have various EMS related settings. On page 60 it describes that you must do writes to ports 0FBh and 0F9h to enable and disable reads/writes from the registers. Lastly, page 70 describes that ECh is the index port and EDh is the data port, and you address and write data to the "configuration registers" through these ports. So basically, 1) write to port 0FBh 2) write 0Bh to port ECh and read/write [whatever settings] to/from port EDh 3) repeat for the other settings register at 0Ch D) write to port 0F9h.

I'm going to futz around with DEBUG tomorrow to see if I can do it without writing code, and confirm via read what the values are. My suspicion is the BIOS is not setting these values correctly. But even if I'm right, then I will need to create a driver/some executable code that I can run from config.sys before the EMS driver loads. Could someone explain to me how that works? Ive never written anything loaded by config.sys. Is it similar to a COM file?

In the worst case, if this doesnt fix things, the chipset documentation does seem to have enough information to write a full-fledged EMS driver.

 

[maxtherabbit]

My suspicion is the BIOS is not setting these values correctly. But even if I'm right, then I will need to create a driver/some executable code that I can run from config.sys before the EMS driver loads. Could someone explain to me how that works? Ive never written anything loaded by config.sys. Is it similar to a COM file?

Also my suspicion. See this thread for a couple examples of how to do this:
https://forum.vcfed.org/index.php?threads/pc-dos-3-2-for-5150.78476/

Both eudi's original EMS2UMB code snippet as well as my derivative WDSRAM tool are examples of what you're looking for

 

[Plasma]

I'm going to futz around with DEBUG tomorrow to see if I can do it without writing code, and confirm via read what the values are. My suspicion is the BIOS is not setting these values correctly. But even if I'm right, then I will need to create a driver/some executable code that I can run from config.sys before the EMS driver loads. Could someone explain to me how that works? Ive never written anything loaded by config.sys. Is it similar to a COM file?

Files loaded in config.sys must be device drivers. These are probably the two best books on the subject.

There are also utilities to load device drivers from the command line, like devload and loadsys. You may be able to load the EMS driver in your autoexec.bat, which would allow your utility to be a simple com file.

 

[sqpat]

Funny, I've seen that book before...
Dug out my DOS books from the attic, few of which I've ever actually read:




I will try the DEBUG thing in a moment, and hopefully I can toss a quick solution together with devload or loadsys. I'm about to be away from these boards till Feburary, and wanted to test some EMS code i've written on a fast 286 before I left.

 

[sqpat]

Update:

I used DEBUG to interface with the registers a bit. Everything lined up with chipset documentation, at least.

- The BIOS setting "Global EMS control" enables the page frame and the Dxxx address range as the page frame, which seems about right. (EC = A0, ED = F0)
- If you try and turn on the backfill registers setting the machine locks up ("command.com halted") when exiting debug. Maybe it requires some default mapping values to be written to all the page registers.
- Anything ive tried turning on or off with debug (whether the BIOS setting for global EMS control was originally enabled) does not seem to make a devload/loadsysed VLEMM.SYS driver detected EMS as enabled, so it still fails in the same way. I don't think it's super likely that doing this in config.sys will make a difference.

I'm curious about hacking the bios to make global EMS control turn on the EMS 4.0 (backfill registers) bit... maybe it would work if it were done pre-boot with some more correct settings.

Im going to give the chipset documentation another look-through. Incompatible driver (or worse, incompatible hardware for some reason??) feels most likely.



UPDATE 2:

I got it. sort of. There is another register, SLTPTR (register 02h) which seems to basically point to the end of XMS (and thus start of EMS). So I set that to 4 MB instead of 8 MB and the driver ran... and then failed? It seems like EMS pages exist but none are free... I think MS-DOS thinks theres 8 MB of XMS still, too.

So it indeed does seem to have to do with the bios allocating everything to XMS. I think it's best if this is done in BIOS, not in a driver. The system shouldn't be posting thinking all that memory is okay as expaxnded as i thought. I will think about how to tackle this. a BIOS hack is probably best, but I don't have time for that right now.

 

[Plasma]

If you need to run some code before DOS loads, you can create an option ROM and stick it on a NIC with a boot ROM socket.

 

[sqpat]

If you need to run some code before DOS loads, you can create an option ROM and stick it on a NIC with a boot ROM socket.

Ahh good idea! I can try that...

I've been trying the driver out a bit with different memory amounts and SLTPTR values. Basically what is happening is it is testing EMS pages counting up from when it should (the SLTPTR defined memory area) but it never stops testing for more pages, and eventually it gets to a bad address - with 16 MB in the system it even tried to allocate beyond when it got to the end of the 16 MB barrier and failed. Unfortunately the vlemm.sys driver has no options besides choosing a page frame. I don't see anything jumping out at me in the chipset documentation about marking an "end region". I even made XMS completely unused (turned off himem, etc) and the driver still never stopped testing for memory.

I think i will try the adapter solution... i have a NIC somewhere i think.

 

[Svenska]

I got it. sort of. There is another register, SLTPTR (register 02h) which seems to basically point to the end of XMS (and thus start of EMS). So I set that to 4 MB instead of 8 MB and the driver ran... and then failed? It seems like EMS pages exist but none are free... I think MS-DOS thinks theres 8 MB of XMS still, too.

That is what I thought about when I mentioned my weird 286 system. The board has 4 MB of memory, and MS-DOS always sees ~3 MB XMS. However, loading the EMS driver (size specified on the command line) marks the stolen memory as "used". MS-DOS still believes the XMS to exist, but won't touch it anymore, and will list the same memory again in EMS memory (i.e. my 4 MB system will appear to have 6 MB of memory).

I think a similar approach should work for you. Allocate the correct XMS range in your driver first, then convert it to EMS.

 

[sqpat]

OK, I tried the NIC solution with a handful of things.
These are essentially the DEBUG commands that need to run.

O FB 01 ; enable writes O EC 0B ; write to register 0B O ED 8F ; enable EMS and page frame E000 O EC 0C ; write to register 0c O ED 00 ; disable page frame c000/d000 O F9 01 ; disable writes

this corresponds to the following ASM which worked fine for me in DEBUG with the g command - it set the registers.
0: b0 01 mov al,0x1 2: e6 fb out 0xfb,al 4: b0 0b mov al,0xb 6: e6 ec out 0xec,al 8: b0 8F mov al,0x8F a: e6 ed out 0xed,al c: b0 0c mov al,0xc e: e6 ec out 0xec,al 10: b0 00 mov al,0x00 12: e6 ed out 0xed,al 14: b0 02 mov al,0x2 16: e6 ec out 0xec,al 18: b0 20 mov al,0x20 1a: e6 ed out 0xed,al 1c: b0 01 mov al,0x1 1e: e6 f9 out 0xf9,al 20: cb retf 21: 5b pop ebx

To put it on a NIC I put a 55 AA 01 in front of this and a RETF at the end and made the checksum add up to 0. I mirrored it since it was on a 256k EPROM chip. The binary is attached. I set the NIC rom addr to a lower address than XT-IDE. Basically, when this runs, it sits there a bit - the XT-IDE BIOS doesn't run and it tries to boot from floppy. I think it's running and doing something, otherwise the system would run XT-IDE BIOS as normal. I'm not sure if RETF is the wrong way to end this segment?

I tried injecting this into an XT-IDE image before the relative JMP (E9 etc etc) but that caused a bunch of zeroes to be printed on screen then the system hung. Whoops.

I may try a boot floppy with DEBUG just to confirm the state of the registers when XT-IDE doesn't run.

 

[Plasma]

Are you calculating the checksum over the entire 512 bytes?

 

[sqpat]

Are you calculating the checksum over the entire 512 bytes?

Yes. I put it right after the retf at the end, but at that point the checksum is 00 and even if you mirror it every 8k, 32k, whatever, it still is 0 regardless.

 

[Plasma]

Ok. Apparently some BIOSes require the fourth byte to be a near jump. Also might be a good idea to push/pop ax.

 

[sqpat]

Ok. Apparently some BIOSes require the fourth byte to be a near jump. Also might be a good idea to push/pop ax.

I tried these things just now and got the same result - xt-ide got skipped and it looked for a floppy to boot from.
I went ahead and grabbed a dos 3.3 floppy with DEBUG here and I confirmed the registers were set, so my option rom ran. They were good ideas to throw in nonetheless. Anyway, maybe this motherboard BIOS is just configured to look for a single option rom to boot from, rather than scanning them all.

Some ideas
- JMP from my BIOS to XT-IDE's (since i've failed up to this point at combining the two.)
- Use a dos 6.22 floppy with himem, the ems drivers, just to confirm that works. Unfortunately I won't be able to run the code I wanted to test as it requires a few MB of storage space
- Try and skip XT-IDE and use a normal IDE controller and boot through BIOS. Always a headache to get HD geometry functional but if it works it works.

UPDATE: option 3 worked, i booted with an IDE controller and got the HD geometry working on the CF card. The option ROM ran without issue. Behavior of the driver is no different. MS-DOS is also still being told it has all 8 MB as extended. If i can figure out how to mess with the motherboard BIOS to set these earlier in POST, i will try that. Bad driver or badly designed hardware is always still a possibility but my gut says the way to go is fix this in the mobo BIOS.

 

[Svenska]

The BIOS will size the memory and store the result somewhere, then simply report it when DOS asks for it. Unless you change the reported size, DOS will not know that you just removed some of that memory.

You've got 3 options:
1. Figure out how the BIOS stores the data and update the value. (I couldn't find a location in BDA.)
2. Override "int 15h" to report less XMS memory.
3. Mark the memory as "in use" in DOS itself.

Also, I've checked www.theretroweb.com for this chipset and while there are multiple boards listed, none of them have a BIOS image. If you could dump your BIOS and update the page, that would be helpful to others. Especially if you have the chipset documentation.

Anyway, maybe this motherboard BIOS is just configured to look for a single option rom to boot from, rather than scanning them all.

Very unlikely.

 

[Krille]

I tried these things just now and got the same result - xt-ide got skipped and it looked for a floppy to boot from.

Make your option ROM BIOS with a size of 2 kiB and it should work.

EDIT: Just to expand a bit on this;

Most, if not all, system BIOS option ROM scans are made with the assumption that the start of option ROM BIOSes are aligned on 2 kiB boundaries. But they also add the size of each option ROM BIOS found to the pointer used for scanning so yours being 512 bytes will trigger a bug in the scan loop that causes it to lose sync and miss every following option ROM BIOS.

 

[sqpat]

Make your option ROM BIOS with a size of 2 kiB and it should work.

EDIT: Just to expand a bit on this;

Most, if not all, system BIOS option ROM scans are made with the assumption that the start of option ROM BIOSes are aligned on 2 kiB boundaries. But they also add the size of each option ROM BIOS found to the pointer used for scanning so yours being 512 bytes will trigger a bug in the scan loop that causes it to lose sync and miss every following option ROM BIOS.

I tried with and without mirroring, the same issue happened. Also, the ROM addresses didn't overlap anyway.

EDIT: The size of the BIOS was technically like, 50 bytes. Do you mean the size of the ROM chip?