yes but i prefer the 2 for the language

Firtasik wrote:

The newest version is 3.33:
http://www.htasoft.com/u98sesp/index.htm

Are these really necessary? I never used a single patch in my W98SE builds and haven't had any issues. The only patch I install is a USB storage driver so I can use USB flash drives.

Looking at the changelog I get the impression that not much is left off the original Windows 🤣

hellzakk wrote:

ok, update... […]
Show full quote

ok, update...

i installed 4 Hynix dimm SDRAM 256MB 133MHz

at the start up the system recognize only 256mb, in control panel - system it's write 256mb, but cpu-z recognize 1024mb...

so... 😕

A few things:

1) CPU-Z is probably just reading the SPD information from those modules, and telling you that they are supposed to be 256MB each. This doesn't mean your system is actually using them correctly. It's doing the electronic equivalent of reading what the sticker says. This is the same info that your BIOS looks at when you boot, but because of the limitations of the chipset, it's not able to make that whole 256MB available for use (see point 2).
If the BIOS POST and Windows are saying 256MB is available, then that's what's really being utilized.

2) What part number is written on those Hynix memory chips? I mean the chips themselves, not the sticker on the module.
Unbuffered 256MB modules on the 440BX need to have a particular chip type, where each chip has 16 million addresses of 8 bits each (16Mx8). This means there will be 16 or 18 chips on it (18 if it's ECC). If it's a brand name module and has that many chips then it should be compatible. There might be rare exceptions, but I think that's mainly with off-brand memory that have been known to do things that violate JEDEC standards.

The notation "32Mx64" describes the whole module, not the individual chips, so it doesn't really tell you if it will be compatible.
For similar reasons as above, some 128MB modules could also be incompatible, but it's a much more common problem with 256MB.

3) Using all 4 DIMM slots on the 440BX technically requires the use of registered memory. If you break this rule, there is a chance you can have inconsistent amounts of memory appear at POST. Actually the real rule is having more than 4 "rows" of memory, which gets used up by just 2 double-sided modules, giving you 512MB max with unbuffered memory. In practice though, this rarely seems to be an issue.
If you're running the standard 100MHz frontside bus speed then I doubt you're having this problem. I ran into this on my old P2B-F but only when I was installing 4x 256MB PC133 CL2 memory on a 133MHz overclocked bus. It would inconsistently POST lesser amounts of memory, but I was pushing it hard to make this happen. I never saw it happen at PC100 speeds. If you want to rule this out, try dropping to 2 memory modules and see if they start POSTing at their correct size. If not, then this isn't your problem.

If you want to max out that board's RAM, the technically correct way to do it is with 256MB PC100 Registered modules. Registered memory has a few extra smaller chips near the edge connector. These modules buffer the signals so that the system can handle the load of larger amounts of memory, but this also slows it down a bit. Registered memory is normally associated with servers, so it usually sells cheap on ebay (obsolete server gear has no market so it crashes in value).
In practice, this probably isn't necessary, the main advantage is just that it's cheaper.

4) Registered memory and unbuffered memory cannot be mixed. If you do this, I'm not sure if it would even boot. Also, note that "registered" and "ECC" don't mean the same thing. Some ECC memory is still unbuffered.