In my spare box of random memory parts, I found these two 32MB SIMM memory chips:

but alas, the PC does not POST with either of these memory in the first socket (testing with the second socket empty).

Unfortunately I could not find any 16MB SIMM memory parts to match the existing 16MB part to get 32MB, so I'll have to order one.

But that brings me to my question: given this kind of scenario that the PC doesn't boot with either of the above 32MB memory in place, and that the manual is conflicting on whether it even supports 32MB memory, what do you think - would it be possible to get 2x32MB = 64MB of RAM on this board somehow?

My memory is a bit hazy on the whole EDO vs FPM memory things. Were those two different standards? Did I try incompatible 32MB memory units, and some other 32MB chips might be worth a test?

Or should I just get a second matching 16MB SIMM to go for 32MB total on this motherboard?

Thanks!

That chipset comes in both EDO-capable and non-EDO-capable versions.

Your UM8886 chip revision is what determines whether it can do EDO or not. There is also a potential BIOS support issue. It depends what default settings the motherboard manufacturer programmed into the BIOS.

FPM will work universally. Both of those 32MB SIMMs are EDO.

That chipset can do 64MB and maybe even 128 or 256MB. It won't be able to cache all of it though.

Thanks for the info, super helpful. So if I go with a hypothesis that I would want non-EDO RAM, then I suppose trying with e.g. https://www.ebay.com/itm/175530666209 might be worth a shot?

I use a 64MB FPM from MemoryMasters in my MB-8433UUD-A (which has a newer revision 8886BF than yours). So, 32MB should work fine, and if you have 256K of cache, is the limit for cacheable area with 7+1 tag anyway.

Warning: Please consider the cacheable area limit of your L2 cache configuration.
With your 256 kB of L2 cache installed, your cacheable area ends at 32 MB in write back mode, and at 64 MB in write through mode.
If you install 64 MB of RAM and still have set your L2 cache in write back mode, half of your RAM will be uncached.
If you use software that takes advantage of the 64 MB RAM, it will run slower.

Non-cached RAM is still faster than swap.
For running very memory-hungry software, it may be worth to add more RAM than the cachable limit.

Grzyb wrote on 2024-09-01, 00:50:

Non-cached RAM is still faster than swap.
For running very memory-hungry software, it may be worth to add more RAM than the cachable limit.

It’s not completely uncached, you still have a tiny bit of L1 to cover it which is still better than absolutely nothing

If boards taking more RAM than they can cache (and the user being able to afford it) stayed relevant for a longer period, maybe PC OSes would have been tuned to optimize for that.

For example, if the system has 64MB and the bottom 32MB is cached, a heuristic could work like this: keep everything below 32MB until there is pressure; say more than 24MB full. At that point put disk buffers above 32MB and code/data/stack below 32MB. When memory is more than 48MB full overall maybe you abandon this and put things wherever they fit.

Clustered computers already have to deal with this in a more complex form (NUMA).

And even PCs had to deal with different "kinds" of physical memory like ISA DMA capability below 16MB but not above.

Grzyb wrote on 2024-09-01, 00:50:

Non-cached RAM is still faster than swap.
For running very memory-hungry software, it may be worth to add more RAM than the cachable limit.

Just curious: Other than RAM drives, was there any memory-hungry software designed in the 486 era that could utilize 32 or 64 MB of RAM?

dormcat wrote on 2024-09-01, 07:02:

Just curious: Other than RAM drives, was there any memory-hungry software designed in the 486 era that could utilize 32 or 64 MB of RAM?

Windows NT.
The official minimum was 16 MB, but in practice it was neverending pain.
The reasonable minimum was 32 MB, and 64 MB highly recommended for using NT with large applications.

dormcat wrote on 2024-09-01, 07:02:

Grzyb wrote on 2024-09-01, 00:50:

Non-cached RAM is still faster than swap.
For running very memory-hungry software, it may be worth to add more RAM than the cachable limit.

Just curious: Other than RAM drives, was there any memory-hungry software designed in the 486 era that could utilize 32 or 64 MB of RAM?

In non-dos environments it wasn’t uncommon for 16mb+ even as early as 1986.

Targeting and moving heavy hitting tasks from proprietary /non-dos to x86 started in the 80’s and was in full swing by the 486 era

The first money is no object industry whereby a computer of immense expense was dwarfed in cost by deadlines and millions of dollars of equipment was desktop publishing. Oddly now a dead industry with minimal relevance that if you still are doing it are also probably using freeware at this point due to going to zero budget .

The other that became relevant in the 486 era was cad and 3d (like catia). The 486 stayed in business and schools until the end of the 90’s and I remember my schools cad class contemplating circa 1995 moving from a dos based cad to windows 95 or even a 3d version and upgrading the 486’s but even then 32mb+ was a minimum.

Variations on 3d Catia even in 1990 were definitely recommended on as much ram would fit if not a monolithic mainframe, 100+ mb workstation configurations weren’t uncommon and x86 forks became more popular in the 486 era.

I have encountered NCR 486 Banking systems with high resolution 20/21” screens running databases on 486 machines circa 1991+ that required more than 16mb

Thanks all for the great notes.

It definitely wouldn't hurt to upgrade the cache from 256KB to 512KB as well.

In my spare parts box, I find these:

One of those UMC UM61256AK-15 chips seems like a direct replacement to the existing Aster AE88128AK-15 chip, and I presume that if I find four W241024AK-15 chips, they would go to replace those W24512AK-15 chips. I'll poke around to see what eBay and AliExpress might turn up.

dormcat wrote on 2024-09-01, 07:02:

Just curious: Other than RAM drives, was there any memory-hungry software designed in the 486 era that could utilize 32 or 64 MB of RAM?

In this case I am looking to run the latest version of DJGPP, which is from January 2023.. so this is not for running old "period correct" software. It seems that GCC 9.3 is memory hungry to compile. (That, or there is some other odd bug with temp/swap setting.. I guess I'll see one way or the other)

It sounds like this might be a software issue - using RHIDE to compile works under DOSBox even with 8MB ram.

clb wrote on 2024-09-01, 19:45:

Thanks all for the great notes. […]
Show full quote

Thanks all for the great notes.

It definitely wouldn't hurt to upgrade the cache from 256KB to 512KB as well.

In my spare parts box, I find these:

The attachment IMG_5888.jpg is no longer available

One of those UMC UM61256AK-15 chips seems like a direct replacement to the existing Aster AE88128AK-15 chip, and I presume that if I find four W241024AK-15 chips, they would go to replace those W24512AK-15 chips. I'll poke around to see what eBay and AliExpress might turn up.

Cheers.
Yes, all of these modules may replace your L2 tag module.
No, with these modules you just can downgrade your L2 cache from 256 kB to 128 kB as you have one bank only. But your cacheable area would double up with that increment of L2 cache too.
You will need to look for four 128k x 8 modules and hope all will be working.

clb wrote on 2024-09-01, 19:45:

Thanks all for the great notes. […]
Show full quote

Thanks all for the great notes.

It definitely wouldn't hurt to upgrade the cache from 256KB to 512KB as well.

In my spare parts box, I find these:

The attachment IMG_5888.jpg is no longer available

One of those UMC UM61256AK-15 chips seems like a direct replacement to the existing Aster AE88128AK-15 chip, and I presume that if I find four W241024AK-15 chips, they would go to replace those W24512AK-15 chips. I'll poke around to see what eBay and AliExpress might turn up.

dormcat wrote on 2024-09-01, 07:02:

Just curious: Other than RAM drives, was there any memory-hungry software designed in the 486 era that could utilize 32 or 64 MB of RAM?

In this case I am looking to run the latest version of DJGPP, which is from January 2023.. so this is not for running old "period correct" software. It seems that GCC 9.3 is memory hungry to compile. (That, or there is some other odd bug with temp/swap setting.. I guess I'll see one way or the other)

Why does one of the chips have an "X" on it? I would guess it had been tested as not working?

jmarsh wrote on 2024-09-01, 21:06:

It sounds like this might be a software issue - using RHIDE to compile works under DOSBox even with 8MB ram.

Yeah, I was kind of doubting about this as well.. although I was not able to figure out why it wouldn't run. Only thing that came to mind was to ensure I have

SET TEMP=C:\TEMP
SET TMP=C:\TEMP
SET CWSDPMI=C:\TEMP\CWSDPMI.SWP

env. vars set, and C:\TEMP exists. And I got about 200MB of free disk space. So then I thought maybe it's finally time to populate the empty RAM slot after all these years.

H3nrik V! wrote on 2024-09-02, 05:02:

Why does one of the chips have an "X" on it? I would guess it had been tested as not working?

Probably not working.. Glad I've got enough to go as spares, assuming the others do then work!

After a while, I now got around to testing out increasing the memory.

I had ordered an extra 16 MB RAM stick. Added that in, and 16MB -> 32MB increase checks out. Great!

I had also ordered four W241024AK-15 L2 cache chips.

From my spare parts bin, I changed the previous Aster AE88128AK-15 tag RAM into UM61256AK-15 tag RAM, and then replaced the previous four W24512AK-15 chips with the four new W241024AK-15 L2 cache chips, like this:

Also changed the jumper settings to upgrade from 256KB cache to 512KB cache.

Boot -> no POST. 🙁

Kind of at loss what might be the cause, I made an assumption that maybe the W241024AK-15 L2 cache chips should work in place of W24512AK-15 chips also when the motherboard is configured to use only 256KB cache RAM.

So I set the jumper setting back to 256KB of L2 cache, and started replacing the cache RAM back to the original ones:

Reverted the bottom W241024AK-15 back to the original W24512AK-15. No POST still.
Reverted the second bottom-most W241024AK-15 back to the original W24512AK-15. The system now POSTs, yay, but it crashes when processing CONFIG.SYS Creative Sound Blaster drivers, and doesn't reach C:\ prompt. Bah.
Reverted the second to top W241024AK-15 back to the original W24512AK-15. Same symptom, CONFIG.SYS crashes.
Reverted the last W241024AK-15 back to the original W24512AK-15. The system is now stable and boots to C:\. That is, the only change I now have in the system is that I had doubled the tag RAM.

Meh, not sure what's going on. Maybe I got sold duds 🙁

I suppose I'll find a chip tester to verify these W241024AK-15 chips next.

clb wrote on 2024-08-31, 21:45:

Thanks for the info, super helpful. So if I go with a hypothesis that I would want non-EDO RAM, then I suppose trying with e.g. https://www.ebay.com/itm/175530666209 might be worth a shot?

Edo can be converted to fp by shorting 2 pins.

https://www.youtube.com/watch?v=nk8uEFpYbBw

I'm moderately sure it can be the correct pins on only one chip on a stick. (Ie you don't have to short all 8/16 chips.)