VOGONS


First post, by Rav

User metadata
Rank Member
Rank
Member

Here is the first version of an universal chipset configuration for, initially, 386 and 486 systems.

Current version : 1.1.1 ->

Filename
ucp111.zip
File size
40.42 KiB
Downloads
18 downloads
File comment
UCP 1.1.1
File license
Fair use/fair dealing exception

Functions:
Permit changing the different chipset registers to allow proper configuration for when the BIOS is limited. Or to do testing instead of to prevent needing to reboot many time.
It also allow to change the cache mode between Write-Back and Write-Through.

Currently implemented:

  • ALI 1429/G (If you have an Acer with some A1G/A1GX motherboard, it's the program you need to make it from meh to actually good)
  • ALI 1489 / FINALi

Implemented features

  • Display chipset parameters
  • Change chipset parameters
  • Display parameters valid only for selected chipset
  • Perform memory test for every memory configuration change (with /test parameter). Automatically rollback in case of a failure
  • Change cache mode

Generic parameters

  • /test -> Will execute memory test after important memory timing change. Soon will also do the same for cache
  • /list -> Display configured parameter. Can be used while setting parameter then in that case, it will display all current configured parameter once it is done configuring them
  • /cs -> Specify cache size in KB. Normally it will detect the cache but in case it miss-detect or if you want a slightly faster execution, say, if you put it in the autoexec.bat, you can specify it there
  • /v -> Verbose mode, only used for cache configuration or memory test
  • /chip list -> show list of supported chips
  • /chip chipname -> select a chip

Base parameter and /list usage:

ucp1.jpeg
Filename
ucp1.jpeg
File size
94.24 KiB
Views
378 views
File comment
Show base param and /list
File license
CC-BY-4.0

Selected chip help plus actually configured parameters:

ucp2.jpeg
Filename
ucp2.jpeg
File size
101.41 KiB
Views
378 views
File comment
Select chip help and configurated param
File license
CC-BY-4.0

Demonstration of applying parameters then displaying the list of configured settings with /list

ucp3.jpeg
Filename
ucp3.jpeg
File size
105.25 KiB
Views
378 views
File comment
Setting param them display /list
File license
CC-BY-4.0

Upcoming feature:

  • More supported chipset
  • Bruteforce mode
  • Perform cache test for every cache configuration change (with /test parameter)
  • Ability to do a memtest or cache test without changing any parameters

Current limitations:

  • Patching cache mode [WT/WB] on Windows (it can work... some rare time by luck, but it usually endup with a system crash. There is no problem about changing the other registers on Windows, but know that changing them will be more sensitive)
  • Patching cache mode [WT/WB] when himem.sys memory manager is used and there is actually more than ~32MB of used memory (say, you have xhdd /S32 in the config.sys, then it crash every single time I tested). Work fine with QEMM.
  • Cache detection work fine in real mode and protected mode but if you use the tool in protected mode while the whole kitchen sink is loaded, miss detection may occure
  • Cache detection on Windows, don't expect that to work reliably
  • Running the tool from a etherdfs network drive will result into a crash (real mode) or a memory protection error (protected mode). Netware drives are fine, did not test with LANMAN.

Special thanks to : mkarcher, feipoa
I will also need chipset register dumps from you guys, I will also update my dumping too to be more complete and release it. That should help me for the "chipset detection" update.
I will add a credit switch in the program, and list all the peoples who help.

Last edited by Rav on 2024-02-14, 14:29. Edited 10 times in total.

Reply 1 of 8, by jakethompson1

User metadata
Rank Oldbie
Rank
Oldbie

It's a nice idea, but: 1. What about CTCHIP?, and 2. in an application of Murphy's Law, the chipsets with the least capable BIOSes (making it hard to reverse them to determine a register map) also are the ones with elusive datasheets.

Also, you might get mired in chipset revisions. For example, I was curious about changing the cache line size on a 386-based UM480 board, but MR BIOS displays the cache line size and won't let me change it (making me think the capability is revision-specific) and when I write my own program to do it (including cache flush et al), the system locks up.

Reply 2 of 8, by Rav

User metadata
Rank Member
Rank
Member
jakethompson1 wrote on 2023-10-10, 01:05:

It's a nice idea, but: 1. What about CTCHIP?, and 2. in an application of Murphy's Law, the chipsets with the least capable BIOSes (making it hard to reverse them to determine a register map) also are the ones with elusive datasheets.

CTCHIP is great.
But:

* try to change cache mode (specially WB->WT) without crashing

* It does not test the settings after applying them, with is what a plan to do with 1.1.

* Can you get cfg file included in a new release? oh wait, last one is from 1999 😒 So you have to hunt them with no hope of getting them added in an official way.

Personally I did use ctchip34 a little, but that was after I made my own .asm tool. Then I made a ctchip34 cfg file for my chipset... And used it mostly for debugging purpose 😉

jakethompson1 wrote on 2023-10-10, 01:05:

Also, you might get mired in chipset revisions. For example, I was curious about changing the cache line size on a 386-based UM480 board, but MR BIOS displays the cache line size and won't let me change it (making me think the capability is revision-specific) and when I write my own program to do it (including cache flush et al), the system locks up.

That is why I want to detect chipset if possible, and not propose options that won't work on X or Y
As you said, you need to program something to flush the cache, because ctchip can't do it....

I don't think I can support all chipsets.

Reply 3 of 8, by mkarcher

User metadata
Rank l33t
Rank
l33t
Rav wrote on 2023-10-10, 01:13:

As you said, you need to program something to flush the cache, because ctchip can't do it....

Actually, ctchipz can do it. Some cfg files contain "macros" that perform different operations in sequence. Flushing / reloading the cache is available in macros. There is a bug in the reload code if you try to reload more than 512K. This needs to happen in protected mode and this code path reloads an insufficient amount of data, IIRC it reloads 1KB/2KB instead of 1MB/2MB. This only gets relevant if you have 512K of cache or more.

I have a patched version of ctchipz somewhere that fixes the bug concerning big reloads. If there is interest, I might dig for it and post how to fix that bug. On the other hand, a legal open-source chipset adjustment program would be great, too.

Reply 4 of 8, by Rav

User metadata
Rank Member
Rank
Member
mkarcher wrote on 2023-10-10, 06:56:

Actually, ctchipz can do it. Some cfg files contain "macros" that perform different operations in sequence. Flushing / reloading the cache is available in macros. There is a bug in the reload code if you try to reload more than 512K. This needs to happen in protected mode and this code path reloads an insufficient amount of data, IIRC it reloads 1KB/2KB instead of 1MB/2MB. This only gets relevant if you have 512K of cache or more.

That's good to know

mkarcher wrote on 2023-10-10, 06:56:

I have a patched version of ctchipz somewhere that fixes the bug concerning big reloads. If there is interest, I might dig for it and post how to fix that bug. On the other hand, a legal open-source chipset adjustment program would be great, too.

I do plan to release the source once I reach 2.0 (once the program is feature complete for what my current plan is). Initial post updated.

Reply 5 of 8, by Rav

User metadata
Rank Member
Rank
Member

Next millstone coming soon!

Memory tester working (pattern in screenshot, if you guys have recommendation for better patterns, let me know)
Now that it work, I have to update the code so "/test" will just execute the test after every memory/cache register change.... instead of just do a memory test alone
The function already return 1 if it fail, and 0 if it success, so with that I can just revert to old timing if it fail.

On DOS, all available XMS is tested
On Windows 3.1, 16MB worth of XMS is tested.

if the memory is fragmented, it still allocate all the available blocks to test them so it work fine if the available XMS is not contiguous.

soon_v1.1.jpeg
Filename
soon_v1.1.jpeg
File size
562.99 KiB
Views
824 views
File license
Public domain

Reply 6 of 8, by Rav

User metadata
Rank Member
Rank
Member

So automatic test for critical timing when /test parameter is set, is working, including setting rollback.

Have to polish it a little (maybe replace all that verbose stuff by just replacing the "OK" on the right for "TESTING[pattern]", then change for OK if OK or failed if Failed.
Then add an extra "revert the setting" line when there is a fail.

Will be more easier to read when user change many settings in the same time...

soon.jpeg
Filename
soon.jpeg
File size
475.63 KiB
Views
817 views
File license
Public domain

Reply 7 of 8, by Rav

User metadata
Rank Member
Rank
Member

Added millstone:

{1.11->1.12}

-> 1.11 : Display currently configured things in the same page as the option list (when you just type ucp without parameters)

-> 1.13 : Bruteforce settings : /bruteforce, will set and test memory and cache related timing and find best "stable" timing for you, including listing all the parameters at the end, if you wish to just stuff them in the autoexec.bat or do some test later. That probably won't replace real applications / stress testing but that could give a fast start with optimum settings. ( And if detected, will also set Cyrix 5x86 CPU to max feipoa recommended "optimal", The one without BTB" settings. Other CPU I don't know yet as I don't have what available for properly testing. - yet -)

Reply 8 of 8, by Rav

User metadata
Rank Member
Rank
Member

New version have been released
Two new versions have been released
First post updated for new version

Changelog 1.1.1

  • Fixed *char length for the chipset text data... 1489 have longer string that I initially planned

Changelog 1.1

  • Added support for ALI 1489 / FINALi
  • Added support to list all parameters /list
  • Refactored the code so it can support many chipset
  • While it display the selected chipset available configuration parameters, it now use color to show what are the currently configured settings
  • Added L2 cache detection. It is used when cache mode is changed, instead of a fixed value
  • Added cache size override option /cs
  • Memory test and cache change mode are not verbose anymore, only with /v