The main issue is that in WT cache mode the cacheable area is 128 MB. (64 MB in write back mode)
So most memory will run uncached.
Yes, for a system with only 512 K of L2 cache. But for one with 1024K, WT will cache 256 MB. But for 256 MB, I could just use 4x64MB. The issue I have run into, though, is that when pushing the FSB speed, cache/RAM wait states, it is more beneficial to have less sticks, that is, 1x64 works better than 2x32 under such conditions. For the reason of module reduction is why I started testing 128 MB SIMMs.
On the MB-8433UUD with IBM 5x86c at 2x66 MHz, I seem to be able to get away with 1 ws for RAM if I use 1x64 MB. If I use 2x64 MB, I must use 2 WS for the system to stable to my satisfaction. I was hoping that 1x128 MB will let me get away with 1 ws. I was not expecting 128 MB sticks to work at all, in fact, and got me wondering if the UM8881 chipset could actually address all 512 MB. Unfortunately, I do not have that many sticks, but might be able to try out 128+128+64+64. As 256 MB would be the max cacheable, this experiment is really just for gross curiousity. Another issue I was wondering, though, is if using a 128 MB stick, is it possible that the memory test might read all 128 MB, but cannot actually write to it? That is, say it skips every other 1 MB, thus really only using 64 MB?
What I seemed to experience with uncachable memory in the past was... by the time your application needs that amount of RAM, the time is long past where the system will ever be fast, and it's made even more dog slow by swap file thrashing, so cached or not, more memory makes it faster. You put 128MB in a system that caches only 64, and will it slow down doom or quake under dos? No, because they don't use that much. You want to run a windows game when you've got your system so bogged down with other crap that the game can't load under 64MB, well then it's just gonna churn swapfile if you don't put more RAM in. I mean if you can, pick the system with more cachable area, but in general your slow CPU is the biggest problem by the time you are running something that huge to be outside the cache. There are edge cases.... like you can slap a K6-2 non plus into a TX mobo that only caches 64MB and show that it's slower than a MVP4 that caches 128, and slower still than sticking a +2 or +3 in any board where all the cache is on the CPU, but that's kinda beside the point. There's just not enough situations where a huge amount of RAM would be a benefit, where a 486 would not be the factor slowing it down the most.
On the flip-side, if you put in 128 MB for a system which can cache only 64 MB, and you run a game which doesn't really need more than 64 MB, you'll really want to remove that extra 64 MB stick because I recall people saying that Windows 9x uses memory from the top down, meaning that the memory in the 64-128 MB range would be used first. If that is true, then it seems you'd want to be able to, on the fly, flip between using 0-64 MB and 0-128 MB.
I have to wonder why they put so much memory in. Bragging rights?
For some, perhaps bragging rights. For others, like myself, I like the feeling of a motherboard taken to its limits. There are also those who probably don't like seeing empty sockets and slots. From my own experience being an NT4 user in the 90's, 128 MB was far more ideal than 64 MB. I do try to setup the software on my retro systems to those which I used at the time, and I tended to use my systems well past their prime. The purpose of the thread, though, is not so much about practicality as for curiosity.
ugg... My 128mb simms cost me like $30 each. I'm not gonna dick with them. But that's 512mb for a 486. Do they even make larger simms?
One user above says he's heard of 256 MB SIMMs, but I'm skeptical of their existence. Are there even 128 MB SIMMs with parity?
Do you have 3 or 4 128 MB SIMMs and a MB-8433UUD? If so, I'd be very interested in your results.