DOS ain't dead

Hi,
I have a chance to test quite new mobo Gigabyte GA-B75M-D3V with UEFI for a day or two. CPU is intel Pentium G860 Sandybridge, chipset (PCH) intel B75 and 4GB RAM. It has integrated VGA - intel HD gfx in CPU core with configurable VRAM size (par of syste4m RAM - I allocated 256MB). It has also one LPT, COM and PS/2 port.

I just done some quick tests using my utils to see how well it works under DOS.
First you can look at new UEFI SETUP interface. It run in gfx mode and use mouse. http://rayer.g6.cz/1tmp/GA-B75M-D3V/SETUP/. There are some legacy settings like SATA IDE mode vs AHCI, emulation of port 60/64 for USB KBD, mouse emulation, loading ROM and UEFI ROM modules from peripherals, setting of LPT mode, address and IRQ. There's no advanced. setting for COM ports. I found the setup has quite poor set of settings compared to my old classic Award BIOS 6.00.

I ran FreeDOS and MSDOS on it without problems. Kbd and mouse emulation works quite well. Even when set IDE mode my tool SMB /ide was unable to detect HDD on legacy port. But it worked when I installed Windows XP.

One issue I observed was that JEMMEX and HIMEMX detected wrong XMS size - only 0,5GB instead of 3,x GB like MS himem.sys from Win98 did. I tried varios options for both but I was unable to increase detected XMS. Japhets, could I help you with providing some further debug?
See all my logs here: http://rayer.g6.cz/1tmp/GA-B75M-D3V/LOGS/

I was very satisfied with VESA speed, both for BS and LFB mode when MTRR was enabled it blits incredibly fast :) Also I should mention that VBE supports widescreen VESA modes (I hate it but someone with such LCD may like it :)

I will also try to run Win98SE on this machine for test. Final will be Win XP for the user as he required.

---
DOS gives me freedom to unlimited HW access.

> One issue I observed was that JEMMEX and HIMEMX detected wrong XMS size -
> only 0,5GB instead of 3,x GB like MS himem.sys from Win98 did. I tried
> varios options for both but I was unable to increase detected XMS. Japhets,
> could I help you with providing some further debug?

What does the memstat tool, included in jemm, tell?

> See all my logs here:
> http://rayer.g6.cz/1tmp/GA-B75M-D3V/LOGS/

---
MS-DOS forever!

> What does the memstat tool, included in jemm, tell?
>
Here is it: http://rayer.g6.cz/1tmp/GA-B75M-D3V/LOGS/MEMSTAT.TXT

---
DOS gives me freedom to unlimited HW access.

> I was very satisfied with VESA speed, both for BS and LFB mode when MTRR
> was enabled it blits incredibly fast :) Also I should mention that VBE
> supports widescreen VESA modes (I hate it but someone with such LCD may
> like it :)

Yes, but try with more than 4GB of total system memory and report back if LFB WC mode is enabled correctly. I remember your utility couldn't set registers correctly with > 4GB installed in system... I posted awhile ago on this forum, and I was using SandyBridge 2600k CPU, with Gigabyte MB and integrated SandyBridge graphics. We tried to debug / work get it working without success

Ok, the problem is that the himems and jemm stop scanning the int 15h ax=e820h blocks once an available block of extended memory has been found.

addr 000000000, size 00009ec00, type 1 (available)
addr 00009ec00, size 000001400, type 2 (reserved)
addr 0000e0000, size 000020000, type 2 (reserved)
addr 000100000, size 01ff00000, type 1 (available) <--- makes them stop

To skip int 15h-e820h is no option, since int 15h-e801h also reports the size of the first block only.

FD himem/emm386 will behave identically, because the strategy was inherited from those tools.

I vaguely remember that there's a problem with managing multiple blocks. A simple solution might be to scan via e820h until the end and then use the largest block ( within the first 4 GB ). However, this might cause problems with SoundBlaster emulators, since, IIRC, they expect to be within the first physical 16 MB.

---
MS-DOS forever!

Thx for explanation. I don't have any idea why they put some reserved memory holes there. I would understand if it is for ACPI or other MMIO devices but they are usually allocated near the top of 4GB.

> I vaguely remember that there's a problem with managing multiple blocks. A
> simple solution might be to scan via e820h until the end and then use the
> largest block ( within the first 4 GB ). However, this might cause problems
> with SoundBlaster emulators, since, IIRC, they expect to be within the
> first physical 16 MB.

I think that SBemu use EMS (not sure but it requires EMM386) so all 32MB of EMS can fit to low 512MB. But depends how memory holes will be assigned on other PCs. Anyway SBemu no longer works for me so I don't care...
Maybe you could add an option to JEMM to enable scan through all available blocks (would be off by default) and manage them...

---
DOS gives me freedom to unlimited HW access.

> Yes, but try with more than 4GB of total system memory and report back if
> LFB WC mode is enabled correctly. I remember your utility couldn't set
> registers correctly with > 4GB installed in system... I posted awhile ago
> on this forum, and I was using SandyBridge 2600k CPU, with Gigabyte MB and
> integrated SandyBridge graphics. We tried to debug / work get it working
> without success

I know, it's still on my growing todo list... I didn't find clean solution I just use dirty hack that shoot of the 4GB MTRR entry overlapping LFB.
And this may happen even on systems with 4GB only (some use remapping of the rest of 4GB above 32bit barrier)- if you look at logs you will see that it happened in this case (there are 2 logs before and after enabling WC for LFB).

---
DOS gives me freedom to unlimited HW access.

> Maybe you could add an option to JEMM to enable scan through all available
> blocks (would be off by default) and manage them...

Well, yes, might not be too hard - but someone with an appropriate machine will have to stand up and test the option. You?

---
MS-DOS forever!

> Well, yes, might not be too hard - but someone with an appropriate machine
> will have to stand up and test the option. You?

Sorry I cannot. I had this PC only for a shot time, just installed WinXP there and returned it to colleague for his parents... I don't have any other such crippled PC for test so it may wait :)

BTW I also tried to install Win98SE there just for fun but I was unable to run setup (regarless various options an configuration). So I just copied my working copy but it failed to boot with message about missing c:\windows\system\vmm32.vxd - sure it was there and ending with message you ma turn off PC now. It happened in 1sec. When I enabled F8 tranking and answer no to load all drivers it booted in safe mode. That was all I can did.

WinXP works fine there. This machine has Samsung 840 SSD and I was able to install AHCI driver after installation but performance gain is weak:
IDE mode: 400MB/s, CPUI load 10%
AHCI mode: 405MB/s, CPU load 7%
I also tried to integrated iastor.sys into my instllation CD, then I was able to run windows setup in AHCI mode but after last restart (windows install almost complette) it didn't boot - ended in restart loop. So this is reason why I installed in IDE mode and enabled AHCI later. I suspect taht driver was installed but registry entry was not properly set to load iastor.sys _during_ system boot. But I don't know where to change it in install scripts. I was able to install all drivers for chipset, network, intel core VGA, sound... except:
radic jednoduche komunikace pro sbernici PCI
(controller of simple communication for PCI bus)
VID:8086 DID:1E3A sub 1C3A/1458 rev 04
but it's not important for working system.
It runs very fast from SSD, boot time about 12sec. :)

---
DOS gives me freedom to unlimited HW access.

Hello,

J.R. Ellis just gave me this information about his XMGR:

------------------------------------------------------------
If he ever has more time on that board, ask him to try XMGR
with it. I was not aware HIMEM/HIMEMX/etc. in fact "quit"
scanning Int 15h AX-E820h memory blocks, when the first has
been found, and XMGR should detect and use all such blocks.
------------------------------------------------------------

---
MS-DOS forever!

> Hello,
>
> J.R. Ellis just gave me this information about his XMGR:
>
> ------------------------------------------------------------
> If he ever has more time on that board, ask him to try XMGR
> with it. I was not aware HIMEM/HIMEMX/etc. in fact "quit"
> scanning Int 15h AX-E820h memory blocks, when the first has
> been found, and XMGR should detect and use all such blocks.
> ------------------------------------------------------------

I cannot test it, maybe in future when I meet similar mobo...

---
DOS gives me freedom to unlimited HW access.