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

[sqpat]

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.

Mine's a 20 mhz biostar, called MB-1220VS. BIOS is attached. I feel like I uploaded it at some point to theretroweb but don't remember 100%.

There's also a PCChips m218 up there with a bios which I tried in the past. It's similar but has fewer bus timing options in the BIOS. Theres like 8 different scamp chipsets listed on that site and the boards are spread out amongst them. (Including a IBM PS/2 or PS/2 with a 486)

Hacking mobo BIOS is not something I have ever done, in fact yesterday was my first time trying to write x86 too so it's sort of new for me. I was looking for ASM that was doing I/O writes to the configuration registers but did not make a lot of progress, i found some but it looked like a lot of undocumented behavior was going on too. If it helps to know, the BIOS' behavior is to scan memory at startup, and it automatically sets the value - there's no way to manually edit it in the menu.

EDIT: Uploaded the board update with BIOS on the TRW discord, it wasn't previously uploaded after all...

 

[sqpat]

I tried a few more things this morning -

- I tried to enable the Backfill register bit in the option ROM but this caused a hang. (Setting it in DEBUG only crashed command.com upon quitting DEBUG)
- I tried running at slower ISA and CPU clocks, didn't help. I did run so fast one time that I locked up the machine, probably because there arent any NOPs in between my OUTs. (I've been told it's best practice to do this).
- In my dozens of boots and reboots, there was one instance a while ago where the EMS driver seemed to load successfully. It did not seem to test all the pages like in the previous instances. But then I went to my program I wanted to run and there was a ton of garbage and a crash, so it probably wasn't 'really' working - but at least the EMS pages were reported as free and in the correct amount in MEM. The exact sequence was I did a cold boot, running the driver in config.sys with page frame Dxxx, noticed that it should have been E000, so i edited the config.sys, rebooted, and i got the different behavior. I could not reproduce this for half an hour of trying the same and different things though.
- I usually have HIMEM.SYS with TESTMEM:OFF. I ran it with memory testing, and it fails at the 2 MB mark, and prompts a restart. 2MB is where I have defined the end of XMS and the start of EMS in the chipset registers (SLTPTR). Seems to indicate the chipset does have different behavior with this set.
- I found this interesting thing in the VLEMM.SYS readme that stands out:

In order to use the EMS 4.0,first,you must use BIOS setup program to change the
chip setup to enable the EMS function and select the EMS memory size you want.
Refer to your BIOS setup menu to do this.

Well, this comes from some DTK board with the 386SX version of the chipset, but it seems like a further indication of an incomplete motherboard BIOS implementation considering my board doesn't have this. Maybe I will take a quick peek at one of those 386sx scamp BIOSes to see if I can find any obvious writes to the memory registers. Of course I still would not really know how to port this over to the 286 BIOS yet.

I will be away from this board until February, so this project will probably be on hold for awhile.

 

[Krille]

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?

No. The third byte is what determines the size of your option ROM BIOS. You need to set that to 4 (*512=2048).

 

[sqpat]

No. The third byte is what determines the size of your option ROM BIOS. You need to set that to 4 (*512=2048).

Oh I see what you mean, set that to 4.
Well in the end, I've removed XT-ide from the equation entirely which makes upper memory and EMS shenanigans simpler anyway.

I tried one last thing. What I did try was directly changing the CMOS RAM values for available expanded memory (17h/18h, and 30h/31h) in the option ROM before ms-dos loaded. This actually led to ms-dos thinking the desired amount of extended memory was available - so I assume it sort of fulfilled the int15h purpose 'well enough'. Of course the CMOS checksum is bad on every subsequent post, but oh well. This all did not change the behavior of the driver, though. I will give a quick shot at hacking the driver to skip the testing phase.

Here are some screenshots of the last attempt, just to illustrate where I'm at.

 

[sqpat]

OK - I can't edit older posts with updates so here's a new one...

Probably the last update for now. I looked at the driver code for a while and read up on device driver format... after about an hour, when I figured out where the print routine was, I found a string along the lines of "press esc to cancel memory testing" and I went and tried it out right away. So this is how I got the driver to "somewhat work" that one time - I must have hit the ESC key. The problem is the message is being overwritten by every line of "Test Expanded Memory Page XXX" as that scrolls by at dozens of lines per second, so it's impossible to read in realtime. Anyway, what I found with my own programs and EMSTEST is that the page frame is unwriteable. What this made me realize about the driver testing too, is that it is testing (and silently failing) every page, which is why there are 0 pages for EMS at the very end of driver installation. If you cancel midway, or at the very start, you can get pages available, but they will fail in practice.

I think I will have to give the chipset documentation another lookover when I'm back. While it definitely seems as if the BIOS doesn't set things correctly, there may be more things to fix than I have found at this point. It feels like I've learned a lot and some progress has been made so far.

 

[orion24]

I've been monitoring this post, as I'm also trying to get this EMS to properly work on this board. My system:

Biostar MB-1220VE
Harris 25 MHz CPU (switched 40MHz to 50MHz crystal on the board)
80287XL FPU (32MHz crystal for 24 MHz operating speed)
16MB RAM
DRIVES are 1.44MB, 360K, MITSUMI 1x CD-ROM, IOMEGA ZIP 100MB IDE
XT-IDE BIOS for AT @ D000 address

Having all the problems mentioned above with trying to get EMS to work with the VLSI driver, I could only get EMS to partly work with lastbyte memory manager and EMM286.EXE, but it was givving me problems. Master of ORION that was the game I wanted to work, was hanging at certain screens and it wasn't alone.

Then I found this page online http://www.win3x.org/win3board/viewtopic.php?t=26070
It has a utility called UMBDRVR and another one called UMBEMS4. The first one does something similar to lastbyte memory manager and enables UMB and the other one enables EMS. With this utilities I managed get EMS running with 607K free conventional (up from 587 with lastbyte) and with the BIOS having Global EMS set to disabled. This works a lot better than EMM286 for my system and Master of ORION finally runs flawlessly.

The config.sys lines I used for this were the following:

DEVICE=UMB_DRVR.SYS /C=12
DOS=HIGH,UMB
DEVICEHIGH=HIMEM.SYS /NUMHANDLES=64
DEVICEHIGH=UMB_EMS4.SYS

 

[sqpat]

Then I found this page online http://www.win3x.org/win3board/viewtopic.php?t=26070
It has a utility called UMBDRVR and another one called UMBEMS4. The first one does something similar to lastbyte memory manager and enables UMB and the other one enables EMS. With this utilities I managed get EMS running with 607K free conventional (up from 587 with lastbyte) and with the BIOS having Global EMS set to disabled. This works a lot better than EMM286 for my system and Master of ORION finally runs flawlessly.

Yes, UMBDRVR works. But it is an EMS simulator and does not use hardware, so it will be really slow (copying data back and forth, rather than remapping near instantly). If you don't have particularly high demands then it will be perfectly fine to get a program running, though.

 

[sqpat]

I got ahold of a 386sx based scamp board, also made by biostar. (I wanted to keep things pretty similar) After fixing the keyboard connector, I tried to get EMS working on it.

So this board's BIOS had a new page of options. My eyes lit up when i saw "Slot Pointer" there. Slot pointer is basically going to be the memory address where EMS starts. It defaults to 16 MB, but i set it to a value lower than the total memory of the board (4 MB at the time). Unfortunately, after saving settings, the bios complains that the cmos memory settings don't match! And why don't they match? Because the bios doesnt seem to adjust the XMS memory amount downward to match the EMS start point, and errors must occur when addressing overlapping memory regions during mem check. The entire available memory just gets allocated to XMS with no way to change it. So you cant even set the slot pointer to anything useful despite the bios option existing!

I may go bios hacking, or try doing bootrom shenanigans on this board for a bit. But i may ultimately have to track down another scamp 386sx board after all. Disappointing...

 

[sqpat]

So I was organizing and cataloguing things in the collection today and found another scamp 386sx (!). Well, I gave it a try, and it has the same bios options as the 286, and also has all the same problems.

Once I have some 512k eproms delivered, I will try some different BIOSes. There is an award bios from DTK board (from a commodore 386sx-25) and DTK is mentioned in the driver. All these other boards I've tried have had AMI BIOS, and if that award bios works then maybe thats part of the solution.

 

[predator99]

I find this topic quite interesting. I wrote an EMS driver for the ST62 chipset back in the 90s based on the chipset documentation only. I dont have a board with SCAMP chipset so I cannot contribute and test very much here.

You dont want to enable "backfill EMS" as it will create a EMS window within the lower 640 kb....

"Primary EMS" can create 12 frames with 16kb each in the range C000-EFFF. This is still too much, usually you only use 4 frames as far as I remember. "Primary EMS" only is the way to go.

Therefore I would start to create the EMS frame starting with C000 and check with debug.exe if RAM is really mapped to this location.
Type
E C000:0 12 34 56
D C000:0
Are the bytes 123456 still there? If yes, your frame should be there. If not, no RAM is at this location and initialization was wrong.

himem.sys must _not_ be loaded of course...it will be more complicated to mix XMS and EMS, so you should start with EMS only.

 

[sqpat]

Some progress:

I tried the Award BIOS found here: https://theretroweb.com/motherboards/s/dtk-ppm-2563v#bios which is from a 386sx SCAMP DTK board (same as the EMS driver). I tried it in my Biostar 386sx board, and it had options to set EMS/XMS (but honestly not a lot else). I was able to get EMS working fine on the board. Kind of as expected, AMI BIOS is just not configuring things properly.

I tried the same BIOS in a different 386sx SCAMP board (a DataExpert one i think) and in this one, which has a separate RTC chip - I could not boot into the system or get into settings because the BIOS asked for a password. I looked online and found that apparently Syxz was a common bios password, and it worked.. This board due to having an RTC chip seems to behave a little differently with BIOS options.

It's not a perfect solution for now. This BIOS is a pain, and seems to default to isaclk/6 for its isa bus speeds and im running at 2.66 or so mhz isa clocks. It seems QRAM wont work, TLB sucks/is buggy for this chipset, and on the biostar board UMB_DRVR wont recognize the chipset (but its okay on the dataexpert). But it's still buggy in combination with VLEMM.SYS. So I can't seem to get UMB and EMS coexisting yet, which is a requirement. Also, backfill is not configurable in bios and it throws the machine for a loop if i try to enable it in the chipset post-boot.

Tried the 386sx bios in the 286 just in case... it didn't post. (-- -- POST card)

Then I tried these two 386sx bioses:
https://theretroweb.com/motherboards/s/dataexpert-vlsi-311-386sx-ver-1.0#bios
https://theretroweb.com/motherboards/s/fic-80386sx-vh-com#bios

Both were AMI bios, with varying EMS options. One of them in particular had a few more EMS options corresponding to the chipset registers. It actually automatically adjusted the XMS down, so when ms-dos booted I thought I had a winner. But ultimately, the EMS driver never worked, nor did it on the one with fewer options. This is on the same board that the award one worked on, and I don't see anything different in the register settings post boot between the working and non working BIOS.. I'm going to have to really dig deeper or dump the contents of the CMOS and registers, perhaps, to try and figure things out.

 

[sqpat]

This driver here: https://theretroweb.com/motherboards/s/jetway-jet-386sx#bios has a couple more features and seems more stable than the commodore sx-25 award bios. It seems to be the 'best so far'. I tried a few other bios that would not properly POST due to A20 issues. Most of the rest are 128k instead of 64k bios.

So here is where we stand right now.

Problem 1: Award SCAMP 386sx BIOS properly configures EMS, but SCAMP 286sx BIOSes do not.
Solution: Figure out what the 386sx bios configures, and copy this behavior to the AMI 286sx BIOS or a boot script or bootrom.

Problem 2: Existing VLEMM EMS Driver does not seem to support backfill.
Solution: Probably write a better EMS driver.

Problem 3: There does not appear to be a UMB provider driver that coexists with the EMS driver. (QRAM does not support the chipset. UMB_DRVR is buggy, TLB is very buggy)
Solution: Investigate while solving problem 2. May have to write a UMB driver, or maybe the existing VLEMM driver is buggy and this can be fixed there.

I think this will be an ongoing problem I work on over a few months. My first steps are to identify the differences between the working/nonworking BIOS configurations for #1. I will also maybe disassemble the VLEMM driver, but I have also seen open source 4.0 drivers around. I don't think this will be the hardest thing in the world.

 

[Svenska]

You should be able to boot without DOS=HIGH (and without HIMEM.SYS), so that XMS is not available and not used while you investigate. That should allow you to play around with all registers and investigate without risking crashes.

A new EMS driver could just "allocate" the memory regions it converts to EMS. The Headland HT12 driver does this and apart from an unexpected MEM.EXE output it just works fine. This approach avoid changing the XMS total size, which should be easier to get correct for different memory managers.

For EMS and UMBs only, the driver could just ignore the BIOS configuration and enforce its own (maybe throw a warning if the BIOS does not map all memory as XMS). But that only works if there is no need to preserve anything until the driver is loaded...

Backfill seems the bigger problem to me; does DOS even support changing the conventional memory size from within a device driver? Obviously, it can be done by poking the internal structures, but that is hard to get right (and stable for different versions/implementations of DOS). Patching the bootsector is probably easier, but then the EMS driver needs to preserve the existing memory content in the area - which may be tricky.

In any case, this looks like an interesting challenge to me - good luck!

 

[sqpat]

Backfill seems the bigger problem to me; does DOS even support changing the conventional memory size from within a device driver? Obviously, it can be done by poking the internal structures, but that is hard to get right (and stable for different versions/implementations of DOS). Patching the bootsector is probably easier, but then the EMS driver needs to preserve the existing memory content in the area - which may be tricky.

I think backfill is usually for OS/multi-tasking level software. I don't know if it plays nice with DOS, but when I use backfill in my code I don't malloc or request from the OS, I just use it Just have to make sure to unmap that memory when you are done and return to COMMAND.COM.

 

[Svenska]

I think backfill is usually for OS/multi-tasking level software.

I believe we are talking about different things. To me, backfill means extending conventional memory (up to 640K), which is only a thing on some early AT clones (which cannot do a 640K / 384K memory split), and more common on XT-class machines (which cannot take 640K on the system board).

What do you mean by "backfill"?

 

[sqpat]

I believe we are talking about different things. To me, backfill means extending conventional memory (up to 640K), which is only a thing on some early AT clones (which cannot do a 640K / 384K memory split), and more common on XT-class machines (which cannot take 640K on the system board).

What do you mean by "backfill"?

Yes, backfill involves pagination of the 0x4000 - 0x9FFF segment ranges (256k-640k). Not very many programs make use of this, it's usually OS-level/multitaskers that do it. Most programs using EMS just use the page frame. Or maybe I'm wrong here? Anyway, many EMS drivers don't support backfill (NEAT and SCAT seem pretty good about it though). EMM386 and 386MAX support it but have a couple of bugs I've found. I think this has to do with it just not being used very much.

When I use this memory, I just use it and don't ask DOS for permission to access these memory ranges... the point being - I guess in my case I don't care if DOS "knows" that memory should be allocated or not. In my experience the drivers (EMM386 included) do not decrement the available conventional memory by the amount in that region though. If you are going to use that memory range for pagination it is really your own responsibility to deal with the fallout. If you have any drivers or part of your program or the stack in that region and you page it out, bad things may or may not happen. In my case, one thing I am exploring is trying to load my program's DS at 0x3C00 or so, such that I can page near memory in and out and have more than 64k worth of 'near data' depending on which code is running and what data I have paged in there, so I can deal with less far pointer code.

 

[Svenska]

I see the difference, you are talking about paging in the lower 640K. That's definitely not what I was thinking about, it seems like a very unusual/uncommon way of using memory. Multitaskers are probably the only programs which benefit, paging is generally cumbersome to use in an OS.

DOS is a single-tasking environment, so using available memory without asking for permission first is unlikely to cause problems - unless there is a background task which allocates and uses memory. But if you are paging conventional memory behind DOS' back, you must avoid any interference by design. In my opinion, it's courtesy to ask DOS for memory anyway.

But if it works, it works.