http://www.bttr-software.de/forum/ DOS ain't dead en Reply from Zyzzle, 04.02.2012, 07:08:

New Logs:

C2D Motherboard Biostar G41-M7 (Intel G41 chipset)
PCI MMIO Allocation: 4 GB to 3072 MB before WC (memory remap enabled)

LFB address: D0000000h
MTRR #0 = 000000000h, 000000000h, 06h, used
MTRR #1 = 000000000h, 0C0000000h, 06h, used
MTRR #2 = 0C0000000h, 0C0000000h, 00h, used
MTRR #3 = 0BDE00000h, 0FFE00000h, 00h, used
MTRR #4 = 0BE000000h, 0FE000000h, 00h, used
MTRR #5 = 000000000h, 000000000h, 00h, unused
MTRR #6 = 000000000h, 000000000h, 00h, unused
MTRR #7 = 000000000h, 000000000h, 00h, unused
MTRR area D0000000-D1FEFFFFh was set to mode: UC

c2d after WC and memory remap enabled

LFB address: D0000000h
MTRR #0 = 000000000h, 080000000h, 06h, used
MTRR #1 = 000000000h, 0C0000000h, 06h, used
MTRR #2 = 0C0000000h, 0C0000000h, 00h, used
MTRR #3 = 0BDE00000h, 0FFE00000h, 00h, used
MTRR #4 = 0BE000000h, 0FE000000h, 00h, used
MTRR #5 = 0D0000000h, 0FE010000h, 00h, used
MTRR #6 = 000000000h, 000000000h, 00h, unused
MTRR #7 = 000000000h, 000000000h, 00h, unused
MTRR area D0000000-D1FEFFFFh was set to mode: WC

c2d after WC and FastVid and memory remap enabled

LFB address: D0000000h
MTRR #0 = 000000000h, 080000000h, 06h, used
MTRR #1 = 000000000h, 0C0000000h, 06h, used
MTRR #2 = 0C0000000h, 0C0000000h, 00h, used
MTRR #3 = 0BDE00000h, 0FFE00000h, 00h, used
MTRR #4 = 0BE000000h, 0FE000000h, 00h, used
MTRR #5 = 0D0000000h, 0FE010000h, 01h, used
MTRR #6 = 000000000h, 000000000h, 00h, unused
MTRR #7 = 0D0000000h, 0FE100000h, 01h, used
MTRR area D0000000-D1FEFFFFh was set to mode: WC


i7 system after WC
VESA 3.0 Intel(R)Sandybridge Desktop Graphics Chipset Accelerated VGA BIOS [32704 kB]
Intel Corporation
Intel(R)Sandybridge Desktop Graphics Controller
Hardware Version 0.0
LFB address: E0000000h
MTRR #0 = 000000000h, 000000000h, 06h, used
MTRR #1 = 0E0000000h, 0E0000000h, 00h, used
MTRR #2 = 0DE000000h, 0FE000000h, 00h, used
MTRR #3 = 0DD800000h, 0FF800000h, 00h, used
MTRR #4 = 000000000h, 000000000h, 06h, used
MTRR #5 = 000000000h, 000000000h, 06h, used
MTRR #6 = 000000000h, 0E0000000h, 06h, used
MTRR #7 = 000000000h, 000000000h, 00h, unused
MTRR #8 = 000000000h, 000000000h, 00h, unused
MTRR #9 = 000000000h, 000000000h, 00h, unused
MTRR area E0000000-E1FEFFFFh was set to mode: WC


Do these help you further to troubleshoot the MTRR problems?

On further investigation, you are right. It seems some areas of lfb are still uncached after the WC enabled. Some programs show no improvement in speed. For example, AdvanceMAME v .106 (last DOS compile) is very slow using VESA vbe modes on my i7 (eg, 47% of 'normal' speed playing Popeye, 43% of normal speed using Crusin USA), where my c2d system playes Popeye at ~500% of normal speed and Cruusin USA at ~ 80% of normal speed).

What is a good option to benchmark MPLAYER, to test its absolute flatout speed, using 100% CPU power? Tried turning off VBE, and -speed, but are there other options?]]> http://www.bttr-software.de/forum/forum_entry.php?id=11105 Sat, 04 Feb 2012 07:08:31 GMT Reply from ron, 04.02.2012, 00:54:

> I just uploaded my package of ODT2TXT so you can take a look at it. As far
> as I could test it works as expected including German "umlauts".

Does that run under plain DOS without HX ?
Never mind, I find it does. :)

And do you have a link to that ?
And I found that, too.

It works fine, and much faster than my own efforts (http://www.ausreg.com/files/odt2htm/) and with very similar results (at first glance).

Ron]]> http://www.bttr-software.de/forum/forum_entry.php?id=11104 Sat, 04 Feb 2012 00:54:35 GMT Reply from georgpotthast, 03.02.2012, 20:16:

> > By the way, I just managed to compile the odt2txt utility with DJGPP:
> > http://www.bttr-software.de/forum/forum_entry.php?id=5861
>
> Cool! I can confirm that the original Win32 version works under HX. Do
> you have a link to your DJGPP binary?
>
> (Looks like last update from program author was 2008-Jun.)
>
> - Doug B.

I just uploaded my package of ODT2TXT so you can take a look at it. As far as I could test it works as expected including German "umlauts".

I also compiled UNRTF which converts RTF to HTML. Not as well as FlWriter converts them to RTF but quite good. These utilities shall be included with FlWriter in the next version.

Georg]]> http://www.bttr-software.de/forum/forum_entry.php?id=11103 Fri, 03 Feb 2012 20:16:48 GMT Reply from RayeR, 03.02.2012, 19:19:

Thanks for debug reports. Please remove my email address from your post. I can see that your C2D machine has more intelligent BIOS (What mobo? mine is gigabyte GA-P31...). It mapped user RAM area to 3 smaller blocks set to write-back that doesnt't spread entire address space but ending probably at CDFFFFFFh. So when I add new MTRR for LFB area it doesn't conflict (overlap) with any other area and it works as expected. Please send logs with remapping enabled too, I'd like to compare them. I don't have such option in BIOS. AFAIK remapping use PAE (36bit phys addr) some way...

But your i7 system really confusing me:
MTRR #0 = 000000000h, 000000000h, 06h, used
MTRR #1 = 0E0000000h, 0E0000000h, 00h, used
MTRR #2 = 0DE000000h, 0FE000000h, 00h, used
MTRR #3 = 0DD800000h, 0FF800000h, 00h, used
MTRR #4 = 000000000h, 000000000h, 06h, used - WTF? why duplicate MTRR0?
MTRR #5 = 000000000h, 000000000h, 06h, used - WTF? why duplicate MTRR0?
MTRR #6 = 000000000h, 0E0000000h, 06h, used - WTF? why duplicate range of MTRR1 with different caching?

As I think that less caching should have higher priority, so LFB is still uncached.

Looking at MTRRs after:
MTRR #0 = 000000000h, 080000000h, 06h, used - well my hardcoded setting
MTRR #1 = 0E0000000h, 0FE010000h, 00h, used - WTF? why still uncached? Didn't you made typo error and set "UC" instead "WC"? Please try again. I cannot imagine what error could cause that base and mask was set but mode not.
MTRR #2 = 0DE000000h, 0FE000000h, 00h, used
MTRR #3 = 0DD800000h, 0FF800000h, 00h, used
MTRR #4 = 000000000h, 000000000h, 06h, used - still overlaping entire 4G
MTRR #5 = 000000000h, 000000000h, 06h, used - still overlaping entire 4G
MTRR #6 = 000000000h, 0E0000000h, 06h, used

Looking at MTRRs after FastVid:
MTRR #0 = 000000000h, 080000000h, 06h, used - well my hardcoded setting
MTRR #1 = 0E0000000h, 0FE010000h, 01h, used - WTF? why there's 1 now?
MTRR #2 = 0DE000000h, 0FE000000h, 00h, used
MTRR #3 = 0DD800000h, 0FF800000h, 00h, used
MTRR #4 = 000000000h, 000000000h, 06h, used - still overlaping entire 4G
MTRR #5 = 000000000h, 000000000h, 06h, used - still overlaping entire 4G
MTRR #6 = 000000000h, 0E0000000h, 06h, used
MTRR #7 = 0E0000000h, 0FE100000h, 01h, used - new LFB area setting by fastvid

I can see there's a difference how fastvid calculated the mask: FE100000 vs FE010000. LFB size is for some strange reason not aligned to 32MB but 32MB-64kB. This may cause problem, maybe my mask calculation is wrong. If I calculate well, fastvid covers only 31744kB of 32704kB - not entire LFB area. But available VESA modes doesn't need 32MB at all.
Anyway because of MTRR 4 and 5 is still set I wonder that this setting has any effect. Really confused... :surprised:]]> http://www.bttr-software.de/forum/forum_entry.php?id=11102 Fri, 03 Feb 2012 19:19:49 GMT Reply from Doug, 03.02.2012, 18:40:

> By the way, I just managed to compile the odt2txt utility with DJGPP:
> http://www.bttr-software.de/forum/forum_entry.php?id=5861

Cool! I can confirm that the original Win32 version works under HX. Do you have a link to your DJGPP binary?

(Looks like last update from program author was 2008-Jun.)

- Doug B.]]> http://www.bttr-software.de/forum/forum_entry.php?id=11101 Fri, 03 Feb 2012 18:40:11 GMT Reply from Rob, 03.02.2012, 18:36:

I have discovered the problem: the program freezes if I use mupdf before (the Rayer's port, version 0.7)

>
> when can you run FlWriter - just once and then you need to reboot? Can you
> run "redir -e err.log -o out.log flwriter" on the second time and see if
> there are any error messages in the log files? (redir comes with DJGPP)
>

Good luck ;)

> By the way, I just managed to compile the odt2txt utility with DJGPP:
> http://www.bttr-software.de/forum/forum_entry.php?id=5861
>
> Regards
>
> Georg Potthast]]> http://www.bttr-software.de/forum/forum_entry.php?id=11100 Fri, 03 Feb 2012 18:36:31 GMT Reply from georgpotthast, 03.02.2012, 15:01:

> Another issue: the first time I enter I donīt have any problem but when I
> exit and try to enter again I canīt; the program freezes without the
> writing window, only the green screen and the mouse in the center.
>

Rob,

when can you run FlWriter - just once and then you need to reboot? Can you run "redir -e err.log -o out.log flwriter" on the second time and see if there are any error messages in the log files? (redir comes with DJGPP)

By the way, I just managed to compile the odt2txt utility with DJGPP:
http://www.bttr-software.de/forum/forum_entry.php?id=5861

Regards

Georg Potthast]]> http://www.bttr-software.de/forum/forum_entry.php?id=11099 Fri, 03 Feb 2012 15:01:47 GMT Reply from Zyzzle, 03.02.2012, 08:20:

Your test version of MTRRLFBE.exe works now for my in c2d system AND also in my i7 SandyBridge system! There are some interesting results I posted in the below logfiles as you requested. On my c2d system, I could configure BIOS to not do "memory remapping" and so detected memory was 3328 MB and MTRRLFBE works perfectly for enabling WC in lfb. When I changed bios option to enable memory remapping, memory is detected as 4096 MB, and MTRRLFBE appears to set WC in lfb successfully, the system does not freeze, but VESATEST.EXE speeds are still the same as UC mode.

On my i7 system, there is NO memory-remapping feature in BIOS, detected memory is 16384MB and your testversion WORKED! No lockup or freeze as in your old version of MTRRLFBE. However, it was only partially successful, as you had also seemed to experience on your i5 system.

I had to run FASTVID.EXE 1.10 and use its option to enable WC in lfb to get full blazing speed. It looks FastVid lfb WC uses MTRR 0 to 7 while your program only uses 0 to 6. Maybe this is the reason for your partial success? Incidently, running FastVid first WITHOUT first running your new testversion of MTRRLFBE freezes my i7 system solid.

-----------------------------------------------------------------------------
c2d E8400 system with 3328 MB RAM before WC in lfb

MTRR-WC enabler for VESA LFB 1.3 (C) 2005-2011 by Martin Rehak;
Compiled by GCC 4.6.2 at 10:33:26, Feb 2 2012
Host machine CPU vendor: GenuineIntel, ID: 10676h

VESA 3.0 Intel(r)Eaglelake Graphics Chip Accelerated VGA BIOS [32704 kB]
Intel Corporation
Intel(r)Eaglelake Graphics Controller
Hardware Version 0.0

LFB address: D0000000h
MTRR #0 = 000000000h, 080000000h, 06h, used
MTRR #1 = 080000000h, 0C0000000h, 06h, used
MTRR #2 = 0C0000000h, 0F0000000h, 06h, used
MTRR #3 = 0CDE00000h, 0FFE00000h, 00h, used
MTRR #4 = 0CE000000h, 0FE000000h, 00h, used
MTRR #5 = 000000000h, 000000000h, 00h, unused
MTRR #6 = 000000000h, 000000000h, 00h, unused
MTRR #7 = 000000000h, 000000000h, 00h, unused
MTRR area D0000000-D1FEFFFFh was set to mode: UC

c2d system with 3328 MB RAM *after* enabling WC in lfb

LFB address: D0000000h
MTRR #0 = 000000000h, 080000000h, 06h, used
MTRR #1 = 080000000h, 0C0000000h, 06h, used
MTRR #2 = 0C0000000h, 0F0000000h, 06h, used
MTRR #3 = 0CDE00000h, 0FFE00000h, 00h, used
MTRR #4 = 0CE000000h, 0FE000000h, 00h, used
MTRR #5 = 0D0000000h, 0FE010000h, 00h, used
MTRR #6 = 000000000h, 000000000h, 00h, unused
MTRR #7 = 000000000h, 000000000h, 00h, unused
MTRR area D0000000-D1FEFFFFh was set to mode: WC

NOTE: c2d system with *4096 MB* RAM in BIOS enabling WC in lfb has no speedup

i7 2600k system with 16384 MB RAM *before* WC in lfb

MTRR-WC enabler for VESA LFB 1.3 (C) 2005-2011 by Martin Rehak;
Compiled by GCC 4.6.2 at 10:33:26, Feb 2 2012
Host machine CPU vendor: GenuineIntel, ID: 206A7h

VESA 3.0 Intel(R)Sandybridge Desktop Graphics Chipset Accelerated VGA BIOS [32704 kB]
Intel Corporation
Intel(R)Sandybridge Desktop Graphics Controller
Hardware Version 0.0
LFB address: E0000000h
MTRR #0 = 000000000h, 000000000h, 06h, used
MTRR #1 = 0E0000000h, 0E0000000h, 00h, used
MTRR #2 = 0DE000000h, 0FE000000h, 00h, used
MTRR #3 = 0DD800000h, 0FF800000h, 00h, used
MTRR #4 = 000000000h, 000000000h, 06h, used
MTRR #5 = 000000000h, 000000000h, 06h, used
MTRR #6 = 000000000h, 0E0000000h, 06h, used
MTRR #7 = 000000000h, 000000000h, 00h, unused
MTRR #8 = 000000000h, 000000000h, 00h, unused
MTRR #9 = 000000000h, 000000000h, 00h, unused
MTRR area E0000000-E1FEFFFFh was set to mode: UC


i7 2600k system with 16384 MB RAM *after* enabling WC in lfb

LFB address: E0000000h
MTRR #0 = 000000000h, 080000000h, 06h, used
MTRR #1 = 0E0000000h, 0FE010000h, 00h, used
MTRR #2 = 0DE000000h, 0FE000000h, 00h, used
MTRR #3 = 0DD800000h, 0FF800000h, 00h, used
MTRR #4 = 000000000h, 000000000h, 06h, used
MTRR #5 = 000000000h, 000000000h, 06h, used
MTRR #6 = 000000000h, 0E0000000h, 06h, used
MTRR #7 = 000000000h, 000000000h, 00h, unused
MTRR #8 = 000000000h, 000000000h, 00h, unused
MTRR #9 = 000000000h, 000000000h, 00h, unused
MTRR area E0000000-E1FEFFFFh was set to mode: WC

(success but 1024x768x32bpp (mode 4118) in VESATEST.exe "only" 769 mb/sec)

i7 2600k system with 16384 MB RAM *after* enabling WC in lfb *AND* running FastVid 1.10 by John Hinkley, and enabling its "linear framebuffer write combining mode"

LFB address: E0000000h
MTRR #0 = 000000000h, 080000000h, 06h, used
MTRR #1 = 0E0000000h, 0FE010000h, 01h, used
MTRR #2 = 0DE000000h, 0FE000000h, 00h, used
MTRR #3 = 0DD800000h, 0FF800000h, 00h, used
MTRR #4 = 000000000h, 000000000h, 06h, used
MTRR #5 = 000000000h, 000000000h, 06h, used
MTRR #6 = 000000000h, 0E0000000h, 06h, used
MTRR #7 = 0E0000000h, 0FE100000h, 01h, used
MTRR #8 = 000000000h, 000000000h, 00h, unused
MTRR #9 = 000000000h, 000000000h, 00h, unused
MTRR area E0000000-E1FEFFFFh was set to mode: WC
(Now mode 0x4118h tested in "FASTVID.EXe 1024 768 32 lfb" shoots up to 1992 MB/sec!)
--------------------------------------------------------------------------]]> http://www.bttr-software.de/forum/forum_entry.php?id=11098 Fri, 03 Feb 2012 08:20:17 GMT Reply from Rob, 02.02.2012, 23:49:

Oh thanks :)

Another issue: the first time I enter I donīt have any problem but when I exit and try to enter again I canīt; the program freezes without the writing window, only the green screen and the mouse in the center.

> Hello Rob,
>
> at least you can start the program :-)
>
> After you have LFN enabled, all you should do is click on the PDF button.
> This will save the current file - only ask for a name if that has not been
> done so - and then makes the readit.pdf file. All PDF files get this name
> for now. The name you have entered will allow you to open that file next
> time you start FlWriter. Or load it again if needed.
>
> FlWriter saves its files in the HTML format. Therefore you should select a
> filename with the htm suffix.
>
> Georg]]> http://www.bttr-software.de/forum/forum_entry.php?id=11097 Thu, 02 Feb 2012 23:49:21 GMT Reply from georgpotthast, 02.02.2012, 21:12:

> > Wow!
> > Great, thank you!
> > But, please, add some example .BAT file how to setup necessary
> environment
> > variables. I tried to adjust .BAT file from Dillo but somwthing is wrong
> > because graphics mode is successfuly set, mouse cursor is visible, green
> > clean desktop is drawn but nothing more happens.
>
> I unpacked the zip to H:\ drive having both dirs in root and it did the
> same. GUI started but mouse din't moved, I could just press ctrl-break...
> The same with doslfn.

I still don't know what the reason for this problem is.

- did you load a mouse driver?

- I forgot to add cwsdpmi.exe into the flwriter directory but if that would miss in your case the progam would not start at all

- can you start flwriter with the "redir" program from djgpp\bin please?
"redir -e err.log -o out.log flwriter" This way you can see any error messages send to STDERR in the err.log file.

- there is a nano-X environment variable which allows to reduce the colors to 16 bit if your graphics card or emulation requires it:
e.g. "set nanoscr=800 600 565"

Regards

Georg Potthast]]> http://www.bttr-software.de/forum/forum_entry.php?id=11096 Thu, 02 Feb 2012 21:12:14 GMT Reply from georgpotthast, 02.02.2012, 20:56:

> I think there is a bug in your program when I try to save in pdf.
>
> I write the name of the file and click on "accept" and the program creates
> two files: the file I have written and "readit.pdf", this second file is
> the right and the first one I donīt what it is.

Hello Rob,

at least you can start the program :-)

After you have LFN enabled, all you should do is click on the PDF button. This will save the current file - only ask for a name if that has not been done so - and then makes the readit.pdf file. All PDF files get this name for now. The name you have entered will allow you to open that file next time you start FlWriter. Or load it again if needed.

FlWriter saves its files in the HTML format. Therefore you should select a filename with the htm suffix.

Georg]]> http://www.bttr-software.de/forum/forum_entry.php?id=11095 Thu, 02 Feb 2012 20:56:23 GMT Reply from RayeR, 02.02.2012, 20:44:

I have partial succes on core i5 @work:

MTRRs before:
VESA 3.0 NVIDIA [14336 kB]
LFB address: CF000000h
MTRR #0 = 000000000h, 000000000h, 06h, used
MTRR #1 = 000000000h, 0E0000000h, 06h, used
MTRR #2 = 020000000h, 0F0000000h, 06h, used
MTRR #3 = 030000000h, 0FC000000h, 06h, used
MTRR #4 = 0CC000000h, 0FC000000h, 00h, used
MTRR #5 = 0D0000000h, 0F0000000h, 00h, used
MTRR #6 = 0E0000000h, 0E0000000h, 00h, used
MTRR #7 = 000000000h, 000000000h, 00h, unused
MTRR area CF000000-CFDFFFFFh was set to mode: WC

MTRRs after I patched MTRR0 and removed MTRR4 that also seemed to overlap LFB area

VESA 3.0 NVIDIA [14336 kB]
LFB address: CF000000h
MTRR #0 = 000000000h, 080000000h, 06h, used
MTRR #1 = 000000000h, 0E0000000h, 06h, used
MTRR #2 = 020000000h, 0F0000000h, 06h, used
MTRR #3 = 030000000h, 0FC000000h, 06h, used
MTRR #4 = 000000000h, 000000000h, 00h, unused
MTRR #5 = 0D0000000h, 0F0000000h, 00h, used
MTRR #6 = 0E0000000h, 0E0000000h, 00h, used
MTRR #7 = 0CF000000h, 0FF200000h, 01h, used
MTRR area CF000000-CFDFFFFFh was set to mode: WC

Then I got performance gain from poor 29MB/s to less poor 270MB/s but still 10x less than expected :P Maybe on this system BIOS use PAT?]]> http://www.bttr-software.de/forum/forum_entry.php?id=11094 Thu, 02 Feb 2012 20:44:49 GMT Reply from Rob, 02.02.2012, 20:05:

I think there is a bug in your program when I try to save in pdf.

I write the name of the file and click on "accept" and the program creates two files: the file I have written and "readit.pdf", this second file is the right and the first one I donīt know what it is.]]> http://www.bttr-software.de/forum/forum_entry.php?id=11093 Thu, 02 Feb 2012 20:05:56 GMT Reply from RayeR, 02.02.2012, 10:51:

> Thanks for your efforts... By the way, on my c2d system with 4 GB RAM,
> MTRRLFBE works fine to enable WC in LFB.

Interesting. I'd like to see how BIOS set MTRRs. Please use this test version
http://rayer.ic.cz/350d/vesatest.zip
and run it twice and grab 2 logfiles. In 1st will be MTRRs before set, in second after set. Now for the test I hardcoded MTRR0 mask to 80000000h, 1 (writeback for lower 2GB). Try on both systems.

> It's only on my i7 system (with 16
> GB) and SandyBridge Intel graphics that it doesn't work. At first, it
> appears to set the WC, but then the entire system locks solid within 1
> second after the apparent success.

Hm it seems to be different kind of error. When some MTRR is overwritten wrong way it may freeze system. On my i5 at work I use nvidia GT230 and it doesn't freeze but didn't tested with inte. vga.

> Tried all BIOS options, PCI latency, etc to no avail. I suspect BIOS memory
> allocation problem is affecting the MTRRs.

This is doesn't releated to caching and MTRRs.

> Isn't there a way to limit the upper limit of RAM detected by HIMEM.SYS or
> some other extended memory manager (QHimem, etc) by use of a switch? Can't
> remember right now, but I thought there was some obscure, undocumented way.

I got this idea too but doesn't work. It must be done on lower level than memory manager.]]> http://www.bttr-software.de/forum/forum_entry.php?id=11092 Thu, 02 Feb 2012 10:51:14 GMT Reply from Zyzzle, 02.02.2012, 05:46:

> I'm on the track of the problem.

Thanks for your efforts... By the way, on my c2d system with 4 GB RAM, MTRRLFBE works fine to enable WC in LFB. It's only on my i7 system (with 16 GB) and SandyBridge Intel graphics that it doesn't work. At first, it appears to set the WC, but then the entire system locks solid within 1 second after the apparent success. Removing all but one DIMM didn't help the problem. I can't get to below 4 GB total system RAM since I only have 4GB DDR3 sticks.

Tried all BIOS options, PCI latency, etc to no avail. I suspect BIOS memory allocation problem is affecting the MTRRs.

Isn't there a way to limit the upper limit of RAM detected by HIMEM.SYS or some other extended memory manager (QHimem, etc) by use of a switch? Can't remember right now, but I thought there was some obscure, undocumented way.]]> http://www.bttr-software.de/forum/forum_entry.php?id=11091 Thu, 02 Feb 2012 05:46:29 GMT