Thanks for sharing your code! I have a truly pie in the sky idea I have no idea how to get started on which this may help...

Awesome, I look forward to trying it when I have K6-2/3 systems up and running.

Oerg866 wrote on 2021-08-26, 11:57:

It's probably not even good code (my first time dancing with low level DOS stuff), but it gets the job done (I hope).

What's that saying, something like "Perfect is the enemy of good enough." meaning it's great to have something that works, instead of vaporware perfection that never gets released.

Nice!

I had to use a wrapper in CONFIG.SYS to enable the write combining with K6WCX prior loading an extended memory manager. One thing in K6DOS.SYS that other related utilities doesn't do is setting the write ordering mode for an additional little boost apart from the write combining.

Thanks for the nice comments 😀

Gmlb256 wrote on 2021-08-26, 14:56:

Nice!

I had to use a wrapper in CONFIG.SYS to enable the write combining with K6WCX prior loading an extended memory manager. One thing in K6DOS.SYS that other related utilities doesn't do is setting the write ordering mode for an additional little boost apart from the write combining.

Yep, that's on the TODO-Pile; in fact, I am about to do some datasheet diving to implement this. 😁

Best,
Eric

Cool. I'll be able to make use of this (or the final version) when I get round to setting up a system with my K6-3+/550. Not in a rush with that project though, my first priority is setting up some more recent systems (X58 and later, AM3 and later), and testing a few items in my collection prior to selling to try raising funds to build a Zen3 system 😀

I guess you proved all the guys in the other thread calling you a dumbass wrong!

(no one actually did that, but I'm unironically happy for your success nonetheless)

Thanks for sharing!
K6DOS.SYS sets the multiplier default to 5.5 upon initialization.
Is that default setting also the case or planned for your implementation?

Thanks for the kind words, everyone 😀

@1541: Since I don't own a CPU that supports software side setting of the multiplier the driver doesn't support that as of now -- it will as soon as I have all the functionality I can verify and use with my own hardware in place 😀

Best,
Eric

Congrats ~

Yay, thanks! 😁
*downloads that for her K6-833*

v0.03 - Write ordering mode, custom regions & command line parameters!

NEW in this release:

• Write Ordering Mode configuration has been added
• Many command line parameters have been added!
• You can now specify custom Write Combining regions
• You can now specify custom Write Allocate Size & Memory Hole info
• You can now enable Write Combining for the legacy VGA memory region
• You can now skip autodetection for WC/WA in case they fail on your machine

Have a look at README.MD to see what is now supported!

This is all VERY UNTESTED and probably broken in some ways. Please help me by testing <3

Check out the new command line parameters! https://github.com/oerg866/k6init#command-line-parameters

Download here:

https://github.com/oerg866/k6init/releases/tag/v0.03

Oerg866 wrote on 2021-08-27, 23:38:

v0.03 - Write ordering mode, custom regions & command line parameters! […]
Show full quote

v0.03 - Write ordering mode, custom regions & command line parameters!

NEW in this release:

• Write Ordering Mode configuration has been added
• Many command line parameters have been added!
• You can now specify custom Write Combining regions
• You can now specify custom Write Allocate Size & Memory Hole info
• You can now enable Write Combining for the legacy VGA memory region
• You can now skip autodetection for WC/WA in case they fail on your machine

Have a look at README.MD to see what is now supported!

This is all VERY UNTESTED and probably broken in some ways. Please help me by testing <3

Check out the new command line parameters! https://github.com/oerg866/k6init#command-line-parameters

Download here:

https://github.com/oerg866/k6init/releases/tag/v0.03

Hi,
Just a suggestion: The VGA graphics memory region is only 64KB at A0000 -AFFFF. The next 64KB (B0000-BFFFF) is never used by VGA graphics modes. B0000-B7FFF is used by monochrome text video modes and B8000-BFFFF is the color text video memory region. On PC's with a VGA adapter the region B000-B7FFF can be freely used by EMM386 or other memory managers (I=B000-B7FF). But if you set write combining for this region this definitely cannot work.
Since text modes does not benefit from write combining and as I written above this can also cause serious compatibility problems I suggest to remove the B0000-BFFFF range or add an option to set it separately from VGA graphics region.

I've had systems where the entire 384k UMA is locked out by BIOS for shadowing and EMM386 works on those... guess it knows it's not allowed in there somehow. So it not being available to EMM386 shouldn't be a problem as long as it knows it's not available.

BitWrangler wrote on 2021-08-28, 00:11:

I've had systems where the entire 384k UMA is locked out by BIOS for shadowing and EMM386 works on those... guess it knows it's not allowed in there somehow. So it not being available to EMM386 shouldn't be a problem as long as it knows it's not available.

This setting does not influence availability. This only changes the memory region write policy form default 'uncached' to 'write combining'. Write combining means weak ordering which works for a frame buffer but does not work for memory that is used by programs (UMB) or EMS page frame.

I know it is only a 64KB region, but the minimum write combine block size is 128KiB as per the AMD K6-2+ datasheet.

Falcosoft wrote on 2021-08-28, 00:19:

BitWrangler wrote on 2021-08-28, 00:11:

I've had systems where the entire 384k UMA is locked out by BIOS for shadowing and EMM386 works on those... guess it knows it's not allowed in there somehow. So it not being available to EMM386 shouldn't be a problem as long as it knows it's not available.

This setting does not influence availability. This only changes the memory region write policy form default 'uncached' to 'write combining'. Write combining means weak ordering which works for a frame buffer but does not work for memory that is used by programs (UMB) or EMS page frame.

Are we sure you all are talking about the same thing. EMM386 uses V86 mode to redirect accesses to UMBs to other physical memory addresses taken from extended memory. All it needs to care about is whether it's ok to remap this memory to those parts of the address space, or if that part of the address space needs to be left alone because there's a hardware device with memory at those addresses, no? Oerg866's utility seems like it would work only with physical addresses, so there should be no problem.

On the other hand, it seems like if something like UMBPCI were used instead of EMM386, where the physical memory address really is B000:xxxx, when using that address space for UMBs, this utility could indeed break that somehow.

my opinion is that the entire B region of UMA should never be used for UMB - some obscure text modes require B000-B7FF even with a VGA

this can be seen with Checkit using the 'text' tests

jakethompson1 wrote on 2021-08-28, 02:45:

Falcosoft wrote on 2021-08-28, 00:19:

BitWrangler wrote on 2021-08-28, 00:11:

I've had systems where the entire 384k UMA is locked out by BIOS for shadowing and EMM386 works on those... guess it knows it's not allowed in there somehow. So it not being available to EMM386 shouldn't be a problem as long as it knows it's not available.

This setting does not influence availability. This only changes the memory region write policy form default 'uncached' to 'write combining'. Write combining means weak ordering which works for a frame buffer but does not work for memory that is used by programs (UMB) or EMS page frame.

Are we sure you all are talking about the same thing. EMM386 uses V86 mode to redirect accesses to UMBs to other physical memory addresses taken from extended memory. All it needs to care about is whether it's ok to remap this memory to those parts of the address space, or if that part of the address space needs to be left alone because there's a hardware device with memory at those addresses, no? Oerg866's utility seems like it would work only with physical addresses, so there should be no problem.

On the other hand, it seems like if something like UMBPCI were used instead of EMM386, where the physical memory address really is B000:xxxx, when using that address space for UMBs, this utility could indeed break that somehow.

Yes, we are talking about the same thing. If you use EMM386 with the include parameter for this region to gain access to additional 32K memory for UMBs/Page frame (that is: EMM386.EXE RAM I=B000-B7FF ) then EMM386 uses this 32K region and the segment B000 refers to physical address B0000.
So If you set write combining mode to region A0000-BFFFF AND you also set EMM386 to use this region (I=B000-B7FF) then the same problems will happen as with UMBPCI.

BTW, it seems setting write combining for VGA banked frame buffer (A0000-AFFFF) does not speed up banked VESA 1.2 graphics modes the same way as setting write combining for linear frame buffer speeds up VESA 2.0 graphics modes. So overall it's not a real problem (at least for me).

jakethompson1 wrote on 2021-08-28, 02:45:

On the other hand, it seems like if something like UMBPCI were used instead of EMM386, where the physical memory address really is B000:xxxx, when using that address space for UMBs, this utility could indeed break that somehow.

UMBPCI only allows to use the range C800-EFFF range as the others are usually reserved for video modes and motherboard BIOS ROM, assuming that the video BIOS ROM size is not larger than 32KB and there are no other ROMs located at that range.

It doesn't allow to include the range B000-B7FF as that range is reserved for mono text and graphics modes.