Just so you're aware, no more than the first 32MB (or at most 64MB if write-through or always dirty write-back) of RAM would be cached, and Windows allocates from the top down, so the uncached memory would be used first. In addition, if you're using an SVGA VLB card with a linear framebuffer, you would want to make sure it can map it very high in memory and that the board and card is actually wired with address lines to map it beyond 64MB. More on that here: https://www.xfree86.org/3.3.6/cirrus5.html#5

Personally, I would use a PCI 486 system, or a later era VLB board like an SiS 471-based one, if I wanted to max out memory that high. Plus, 128MB in 72-pin will be much cheaper than 30-pin, since most of what you're paying for is shipping and the labor of testing by the piece at this point.

16Mx9 is referring to 8 data bits and one parity bit. It doesn't mean it needs to be 9-chip memory. The difference between 9-chip and 3-chip has something to do with how it is refreshed, I believe. You can search mkarcher's posting history for a detailed description of this as he is very good at explaining such things, or he or someone might jump in. IIRC anything 486-era supports 3-chip.

It would surely be 5 volts FPM; don't think you can find 30-pin in anything else easily, and you won't find faster than 60 nanoseconds without jumping through hoops.

You can look in the BIOS for an option to disable parity check. If you don't have it working yet, you could try finding the BIOS image or reading it, and booting it in PCem. It could be hidden, which would be annoying. Ideally it's already off by default.

Thank you very much for the detailed information!
I'm going to start by trying: 64MB (4 X 16MB) FPM PARITY 60NS SIMM 30-PIN 5V 16X9 MEMORY RAM
I didn't know about the memory capacity to cache ratio. The motherboard has 256k of cache and I plan to run it in write-through mode.
I'll report back here with some results!

I'd like to kindly direct you to the listing for your board on The Ultimate Retro

https://www.ultimateretro.net/en/motherboards/1041

Please stop linking to stason. UR is a community project run by guys from this very forum

maxtherabbit wrote on 2022-06-29, 19:37:

Please stop linking to stason.

OK now I am curious why it matters. Did Stason do something bad?

PDXTony wrote on 2022-06-29, 19:39:

maxtherabbit wrote on 2022-06-29, 19:37:

Please stop linking to stason.

OK now I am curious why it matters. Did Stason do something bad?

Not really, just don't loike em simple as

maxtherabbit wrote on 2022-06-29, 19:45:

PDXTony wrote on 2022-06-29, 19:39:

maxtherabbit wrote on 2022-06-29, 19:37:

Please stop linking to stason.

OK now I am curious why it matters. Did Stason do something bad?

Not really, just don't loike em simple as

I think the "Don't let your bike seat ruin your SEX LIFE" book ad is bad enough to avoid Stason like the plague 😛

TheMobRules wrote on 2022-06-29, 20:00:

maxtherabbit wrote on 2022-06-29, 19:45:

PDXTony wrote on 2022-06-29, 19:39:

OK now I am curious why it matters. Did Stason do something bad?

Not really, just don't loike em simple as

I think the "Don't let your bike seat ruin your SEX LIFE" book ad is bad enough to avoid Stason like the plague 😛

I think those ads base themselves off your browsing history, good sir... 😉

PDXTony wrote on 2022-06-29, 21:51:

TheMobRules wrote on 2022-06-29, 20:00:

maxtherabbit wrote on 2022-06-29, 19:45:

Not really, just don't loike em simple as

I think the "Don't let your bike seat ruin your SEX LIFE" book ad is bad enough to avoid Stason like the plague 😛

I think those ads base themselves off your browsing history, good sir... 😉

Nope, my ad blocker prevents that 😉 , those are fixed ads of books written by Mr. Stason himself. Just take a look at the homepage, he has all kinds of weird stuff besides the "PC Info" section which, if I'm not mistaken, he lifted entirely from "Total Hardware 1999". That's a very good reason to use Ultimate Retro (or fall back to TH99 if necessary).

PDXTony wrote on 2022-06-29, 21:51:

TheMobRules wrote on 2022-06-29, 20:00:

maxtherabbit wrote on 2022-06-29, 19:45:

Not really, just don't loike em simple as

I think the "Don't let your bike seat ruin your SEX LIFE" book ad is bad enough to avoid Stason like the plague 😛

I think those ads base themselves off your browsing history, good sir... 😉

They don't we all see that same bullshit

maxtherabbit wrote on 2022-06-29, 19:45:

PDXTony wrote on 2022-06-29, 19:39:

maxtherabbit wrote on 2022-06-29, 19:37:

Please stop linking to stason.

OK now I am curious why it matters. Did Stason do something bad?

Not really, just don't loike em simple as

😀 OK ok ok - got it - AND...I even contributed some pictures and a BIOS dump to: https://www.ultimateretro.net/en/motherboards/1041

PDXTony wrote on 2022-07-03, 01:56:

maxtherabbit wrote on 2022-06-29, 19:45:

PDXTony wrote on 2022-06-29, 19:39:

OK now I am curious why it matters. Did Stason do something bad?

Not really, just don't loike em simple as

😀 OK ok ok - got it - AND...I even contributed some pictures and a BIOS dump to: https://www.ultimateretro.net/en/motherboards/1041

Have any luck with the RAM?
I believe the UM491 does not support robbing a bit from the tag RAM to use as the dirty RAM. So your cacheable area is indeed 64MB, and likely "always dirty" as there is no dirty RAM that I see. You can use CACHECHK once you get it going to see. On my 486DX2/80 UM491 board, I get 16 us/KB for L1, 20 us/KB for L2, and 37 us/KB for RAM.

jakethompson1 wrote on 2022-07-03, 02:01:

PDXTony wrote on 2022-07-03, 01:56:

maxtherabbit wrote on 2022-06-29, 19:45:

Not really, just don't loike em simple as

😀 OK ok ok - got it - AND...I even contributed some pictures and a BIOS dump to: https://www.ultimateretro.net/en/motherboards/1041

Have any luck with the RAM?
I believe the UM491 does not support robbing a bit from the tag RAM to use as the dirty RAM. So your cacheable area is indeed 64MB, and likely "always dirty" as there is no dirty RAM that I see. You can use CACHECHK once you get it going to see. On my 486DX2/80 UM491 board, I get 16 us/KB for L1, 20 us/KB for L2, and 37 us/KB for RAM.

Hey! Yes, the 64mb of memory I ordered works perfectly in the board. Tonight I plan on running CACHECHK and a few other utilities to ensure it's stable.

There is almost nothing(*) that runs great on 486 and requires more than 16MB of ram, but there is plenty of things that go wrong with more like already mentioned caching and linear VESA buffer access.

* linux proxy/local file server in 1994?

Done!!

If I were you, I will choose a 72 pin fast page memory. They are a bit faster, around 25 MB/s.

It is nearly impossible to find a VL-bus based graphics card, as well as Isa. If you are lucky, those can only have 1 to 2 MB video ram. With 1 MB you can use 640 x 480 (or 640 x 400) 24 bit, 800 x 600 16 bit color, with 2 MB you can use 800 x 600 24 bit, 1024 x 768 16 bit, to use 1024 x 768 24 bit you need a 4 MB one as you know. But, if you have a PCI based 486 mainboard, you can easily find a graphics card up to 32 MB with 2D and even 3D acceleration. (If, not Voodoo or S3)

Fast page memory is the normal standard 72pin simm dram. The other kind would be EDO, rarely supported on 486. Third non option was BEDO, standard that failed in the market.

PDXTony wrote on 2022-07-12, 00:45:

Done!!

PXL_20220712_004103973.MP.jpg

That picture shows clearly that all 64MB is cached. If the BIOS offers "memory relocation", I recommend disabling it in this configuration. It might push a small amount of memory (like 128KB) over the 64MB limit, which might be uncached or (even worse, but unlikely in your) mis-cached. In contrast to the 64MB you have, the extra 128KB isn't worth the trouble it might cause. I own a board with the predecessor chipset, the UM480 (consists of the 82c481 and 82c482), which supports up to 32MB. The manufacturer (Elitegroup...) omitted one technically required jumper for the cache size configuration causing mis-caching when the full amount of 32MB is installed and relocation is enabled.

mkarcher wrote on 2022-11-23, 21:43:

PDXTony wrote on 2022-07-12, 00:45:

Done!!

PXL_20220712_004103973.MP.jpg

That picture shows clearly that all 64MB is cached. If the BIOS offers "memory relocation", I recommend disabling it in this configuration. It might push a small amount of memory (like 128KB) over the 64MB limit, which might be uncached or (even worse, but unlikely in your) mis-cached. In contrast to the 64MB you have, the extra 128KB isn't worth the trouble it might cause. I own a board with the predecessor chipset, the UM480 (consists of the 82c481 and 82c482), which supports up to 32MB. The manufacturer (Elitegroup...) omitted one technically required jumper for the cache size configuration causing mis-caching when the full amount of 32MB is installed and relocation is enabled.

I also found a bug in the Trident 9440 VLB video driver for Windows 95 when it was trying to determine where to place its linear framebuffer. On a UM491 system with 32MB and memory relocation enabled, the tests it performed to determine whether RAM might exist at 32MB somehow passed, and it attempted to locate the framebuffer there, causing the screen to scramble right away. Disabling relocation (and then turning it back on but patching the driver) fixed the issue.

I had a problem with a Cirrus VLB graphics card when memory size was above 48 MB.