Did you try the 9190914s.rom BIOS?

bertrammatrix wrote on 2024-12-15, 22:45:

Here-

v1.5 with cyrix at 2 x 60, 512k, 32 vs 64mb edo, only basic lssr and linear burst enabled

You had the L2 in write-through mode?

If you run the same test with your v3.4, do you see the same performance drop when using 64 MB?

feipoa wrote on 2024-12-16, 13:27:

bertrammatrix wrote on 2024-12-15, 22:45:

Here-

v1.5 with cyrix at 2 x 60, 512k, 32 vs 64mb edo, only basic lssr and linear burst enabled

You had the L2 in write-through mode?

If you run the same test with your v3.4, do you see the same performance drop when using 64 MB?

I had the v1.5s L2 in write back mode. I have tried this both ways previously- it has no effect on the bug.

No, my v3.4 doesn't exhibit this whatever I do.

I think i found the answer to that though- another user confirms that the bios my 3.4 has is apparently the only one unaffected by this, here:

Best BIOS for PC-Chips M919?

I figured I should try to not be chicken and tried to flash the 1.5s bios yesterday - turns out it (along with all my other pcchips boards) has one of those non-erasable eproms. I found a compatible erasable SST chip on one of my parts designated early Pentium boards, I will try to hot flash it later today or tomorrow and see how that goes

From what I've seen, all PC Chips socket 3 boards came with one time programmable (OTP) EPROM chips.

Are you able to attach to this thread the version of the M919 v3.4b/f which does not exhibit the 64 mb performance bug?

feipoa wrote on 2024-12-17, 01:48:

From what I've seen, all PC Chips socket 3 boards came with one time programmable (OTP) EPROM chips.

Are you able to attach to this thread the version of the M919 v3.4b/f which does not exhibit the 64 mb performance bug?

Sure, the one without the 64mb bug is this one:

https://theretroweb.com/motherboard/bios/9190 … d9075133637.bin

And that's interesting, it being dated at 05/06/96 makes it the oldest bios revison of a v3.4 listed on the retroweb. So the bug is absent on the first version but present on all following bioses. It really makes me wonder - was it intentional? Why? Did this perhaps "fix" some different issue that isn't immediately apparent? Could there have been reliability issues caching that memory region due to faulty chipset silicon or some other factor, and doing something like this was a good bandaid? Hmmm

According to the MD5 checksum, that's the same file as my 9190506.BIN file. From what I could discern, this was the latest BIOS file to be shipped on v3.4 b/f motherboards.

I think my cased system w/Am5x86 at 180 MHz is using 9190914S.ROM -- 09/15/1998. I don't recall why I switched from the 05/06/1996 BIOS. It may have just been because others were using it. I will need to check again if there are any performance differences between these two BIOSes. I'm running some pretty tight timings.

If you run 9190914S.ROM, do you witness the 64 MB bug?

feipoa wrote on 2024-12-17, 04:21:

According to the MD5 checksum, that's the same file as my 9190506.BIN file. From what I could discern, this was the latest BIOS file to be shipped on v3.4 b/f motherboards.

I think my cased system w/Am5x86 at 180 MHz is using 9190914S.ROM -- 09/15/1998. I don't recall why I switched from the 05/06/1996 BIOS. It may have just been because others were using it. I will need to check again if there are any performance differences between these two BIOSes. I'm running some pretty tight timings.

If you run 9190914S.ROM, do you witness the 64 MB bug?

Sorry I can't try. It looks like the chip I was intending to flash for the 1.5 may have a software lock, or is no good, and I always get a lockup while trying to flash, one attempt that did appear to progress yielded nothing, so untill I purchase some more that's that. The 3.4 also has a nonflashable one and seeing it doesn't have the issue I'm not to keen on messing with it anyway.

I have no reason to believe otherwise though as the author of the "best 919 bios " thread also concluded that the 9190506 is the only one to be bug free.

If anything, I'd be more interested to try the older bios available on my v1.5 just to see if it's first bios is also free of this

You should invest in a cheap EEPROM programmer. If you stay in the hobby, you won't regret it.

I'll have to put this 64 mb bug back on my books for testing. I have a foggy memory suggesting that the 64 MB performance bug also occurred on that 9190506 BIOS.

feipoa wrote on 2024-12-17, 13:06:

You should invest in a cheap EEPROM programmer. If you stay in the hobby, you won't regret it.

I'll have to put this 64 mb bug back on my books for testing. I have a foggy memory suggesting that the 64 MB performance bug also occurred on that 9190506 BIOS.

Anything inexpensive you'd point me to that would work? Preferably Amazon

A lot of people have the TL866 II Plus. There's some upgraded versions now, like the T48 or T56.

Here's a kit on Aliexpress for about $20.

https://www.aliexpress.com/item/1005004605106 … iBoCLxsQAvD_BwE

Prices on amazon are 3-4x more expensive for the same product compared to aliexpress. Just do an Amazon search for TL866 and you'll see options for the TL866II plus, the T48, and T56. Here are a few examples:

https://www.amazon.com/Universal-Programmer-T … 34482468&sr=8-5

https://www.amazon.com/TL866II-Upgraded-Progr … 34482468&sr=8-2

I bought the TL866II plus many years ago because of all the adaptors it came with, about 2 dozen. I still prefer to use my old Wellon, but its much more expensive. I've tested some SRAM on the TL866II plus and it came back good, but on the Wellon, it came back bad. The Wellon was correct in it's determination; the SRAM was, in fact, bad.

Customer support for missing models was very good with Wellon. They added missing parts within 5 days. I tried to get similar support for the TL866II, but never received a reply.

feipoa wrote on 2024-12-18, 00:52:

A lot of people have the TL866 II Plus. There's some upgraded versions now, like the T48 or T56. […]
Show full quote

A lot of people have the TL866 II Plus. There's some upgraded versions now, like the T48 or T56.

Here's a kit on Aliexpress for about $20.

https://www.aliexpress.com/item/1005004605106 … iBoCLxsQAvD_BwE

Prices on amazon are 3-4x more expensive for the same product compared to aliexpress. Just do an Amazon search for TL866 and you'll see options for the TL866II plus, the T48, and T56. Here are a few examples:

https://www.amazon.com/Universal-Programmer-T … 34482468&sr=8-5

https://www.amazon.com/TL866II-Upgraded-Progr … 34482468&sr=8-2

I bought the TL866II plus many years ago because of all the adaptors it came with, about 2 dozen. I still prefer to use my old Wellon, but its much more expensive. I've tested some SRAM on the TL866II plus and it came back good, but on the Wellon, it came back bad. The Wellon was correct in it's determination; the SRAM was, in fact, bad.

Customer support for missing models was very good with Wellon. They added missing parts within 5 days. I tried to get similar support for the TL866II, but never received a reply.

I persisted with the hotflash method and was finally able to get it to work using uniflash.

Confirmed again - with the 05/06/96 bios programmed on the v1.5 board the bug is gone and all memory is cached when using 64mb. Quake score goes back up to where it was with 32mb.

Thanks. I'll have to check myself to ensure it is, indeed, a BIOS bug and not a hardware bug. You are using M919 3.4 B/F?

It may be that I switched to the 1998 BIOS because the 1996 BIOS couldn't handle the tight timings I was pushing at 180 MHz. If I remember right, I'm running 128 MB with DRAM read/write at 1/0 WS and SRAM at 2-1-2.

I can confirm that the 9/15/1998 BIOS for the M919 contains the 64 MB performance bug, whereas the BIOS dated 5/6/1996 does not. Thank you for pointing this out. Does anyone know where the 10/16/1996 and 09/15/1998 BIOSes came from? Were they on the PC Chips website? What benefits came with these two later BIOSes?

feipoa wrote on 2025-03-24, 02:48:

I can confirm that the 9/15/1998 BIOS for the M919 contains the 64 MB performance bug, whereas the BIOS dated 5/6/1996 does not. Thank you for pointing this out. Does anyone know where the 10/16/1996 and 09/15/1998 BIOSes came from? Were they on the PC Chips website? What benefits came with these two later BIOSes?

I'm glad you finally had time to test this. I have recently acquired a second identical v3.4 so that I don't have to mess with my "daily driver" 486 while testing nuances of this chipset.

I was hoping for a "fast " capable board, however preliminary testing with the factory bios (no uncached areas) has shown that again for reliable 60mhz fsb operation I have to use 3-2-2 cache settings. Anything faster and good luck making it to dosbench let alone windows. Amount/type of ram only affects this very little, with 50ns ram not fairing any better then 60ns. Added filtration caps on a few spots of the board + a different power supply also didn't help. Moving VGA to anything but the topmost PCI slot makes things worse (can anyone confirm?)

I may revisit the bios shuffle to see if the versions with the cacheability issue do anything speed stability wise, even though this proved not to be the case on my first v3.4

Some searching turned up this

http://th2chips.freeservers.com/syl8884/index.html

It sounds like bios revisions were made to deal with larger HDD support and a problem with some sound cards, which I can understand. What I don't get is why all v1.x and v3.x bioses have the bug until the factory v3.4 which doesn't, but any subsequent releases after that have it again. It almost feels like "not" having the bug was found to be a mistake and thus reverted.

Feipoa did you mention somewhere that you run 128mb of ram on this? If so, does the uncached region only go from 5x mb to 64mb or from 5x mb all the way to 128mb (ie all memory above that point is uncached)

Which L2 cache sticks are you using? You need exceptional sticks to obtain 2-1-2 at 180 MHz. In the M919 1024K cache thread, I outlined what I had to do in order to create exceptional sticks. Not all were exceptional with the L2 timings. On the other hand, certain IC's stood out to some degree. You want the 8 ns and 10 ns SRAM ICs referenced in that thread.

Similarly, to obtian 1/0 ws at 180 MHz, you need exceptional DRAM modules. I have 64 MB and 128 MB 50 ns modules, but the 64 MB sticks caused errors. The SIMM slot used seems to matter to some degree. I am using the innermost slot (not near PCB edge). The system is on the edge of stability. Any stable system must face the rath of my children. They have a nack for crashing just about any system while playing games as they pound agressively on a half dozen keys at a time randomly. For the M919 test, I let them play Turok and Turok2 using the Voodoo2 in Win95. Played for hours, but no crashes. Then I let them play Blood and the system frooze after a little over 70 minutes, even though I let mp3 playback go for 4 hours w/out issue. I swapped to a different 128 MB 50 ns modules to see if I can improve upon that 70 min timeframe.

Even with the 5/6/1996 BIOS, I am having trouble getting a straight 64 MB module going well, and I have tried a large stash of 50/60ns modules. It is these particular 50 ns, 128 MB modules with a 3.3 V VRM module which I have had the best of luck with. Alternately, 16 MB and 32 MB modules have been OK, as far as I recall.

I have 3 M919 v3.4 B/F boards. The board I am using now was from my original 486 system I bought in Jan 1997. In about 2001, I killed the board when I had installed some unsupported DRAM modules. In about 2021 or 2022, I did an Um8881 chipset transplant which brought the board back to life. It is the copper coloured board without the fake PB cache chips.

I have another identical board, but it is extremely flaky. The PCB's used by PC Chip were so thin that I suspect the years of flexing the board can detach vias. On my second flaky M919, it had the L1 WB stuck in WT mode. After some probing, I found some vias not connected to the WB/WT select pin (B13 IIRC?). I jumpered that and fixed this problem. However, I think there's more bad vias. The cache will start acting up after some time turned on. If I pull the L2 stick out a few times, and re-insert it, it fixes the problem, but after a day or so, the L2 starts acting up. I reflowed the cache slot pins, but it didn't help. Thus, I suspect a semi-detached via somewhere.

I have a 3rd M919 v3.4 B/F which has the fake PB cache modules and is green coloured. I have no problem with it and it acts as my backup board. I am doubtful that I will find the issue with the 2nd copper coloured board.

bertrammatrix wrote on 2025-03-25, 16:20:

Feipoa did you mention somewhere that you run 128mb of ram on this? If so, does the uncached region only go from 5x mb to 64mb or from 5x mb all the way to 128mb (ie all memory above that point is uncached)

I never noticed cachechk pointing out any uncached regions. Cachechk looks identical for the 1996 and 1998 BIOSes. The only indicator that something was amiss with 64 MB installed was the horrific Quake benchmark score. Or are you referring to CTCM's uncached regions? I did not check CTCM.

EDIT:
I'm not sure what the 1998 and later 1996 BIOS brought to the system because I still was unable to use a 32 GB CF card w/BIOS support on the 1998 BIOS. To get around this problem, I have Win95 and NT4 setup on an 8 GB CF card, split 50/50. Then, I added a 32 GB CF card as slave to be accessed within Windows only. I had a horrific time finding a sound card that worked well at 180 MHz, so I'm not sure if these later BIOSes improved sound support either. Of my entire VLB card fleet, only two cards worked well at 180 MHz.

feipoa wrote on 2025-03-25, 22:44:

Which L2 cache sticks are you using? You need exceptional sticks to obtain 2-1-2 at 180 MHz. In the M919 1024K cache thread, I […]
Show full quote

Which L2 cache sticks are you using? You need exceptional sticks to obtain 2-1-2 at 180 MHz. In the M919 1024K cache thread, I outlined what I had to do in order to create exceptional sticks. Not all were exceptional with the L2 timings. On the other hand, certain IC's stood out to some degree. You want the 8 ns and 10 ns SRAM ICs referenced in that thread.

Similarly, to obtian 1/0 ws at 180 MHz, you need exceptional DRAM modules. I have 64 MB and 128 MB 50 ns modules, but the 64 MB sticks caused errors. The SIMM slot used seems to matter to some degree. I am using the innermost slot (not near PCB edge). The system is on the edge of stability. Any stable system must face the rath of my children. They have a nack for crashing just about any system while playing games as they pound agressively on a half dozen keys at a time randomly. For the M919 test, I let them play Turok and Turok2 using the Voodoo2 in Win95. Played for hours, but no crashes. Then I let them play Blood and the system frooze after a little over 70 minutes, even though I let mp3 playback go for 4 hours w/out issue. I swapped to a different 128 MB 50 ns modules to see if I can improve upon that 70 min timeframe.

Even with the 5/6/1996 BIOS, I am having trouble getting a straight 64 MB module going well, and I have tried a large stash of 50/60ns modules. It is these particular 50 ns, 128 MB modules with a 3.3 V VRM module which I have had the best of luck with. Alternately, 16 MB and 32 MB modules have been OK, as far as I recall.

I have 3 M919 v3.4 B/F boards. The board I am using now was from my original 486 system I bought in Jan 1997. In about 2001, I killed the board when I had installed some unsupported DRAM modules. In about 2021 or 2022, I did an Um8881 chipset transplant which brought the board back to life. It is the copper coloured board without the fake PB cache chips.

I have another identical board, but it is extremely flaky. The PCB's used by PC Chip were so thin that I suspect the years of flexing the board can detach vias. On my second flaky M919, it had the L1 WB stuck in WT mode. After some probing, I found some vias not connected to the WB/WT select pin (B13 IIRC?). I jumpered that and fixed this problem. However, I think there's more bad vias. The cache will start acting up after some time turned on. If I pull the L2 stick out a few times, and re-insert it, it fixes the problem, but after a day or so, the L2 starts acting up. I reflowed the cache slot pins, but it didn't help. Thus, I suspect a semi-detached via somewhere.

I have a 3rd M919 v3.4 B/F which has the fake PB cache modules and is green coloured. I have no problem with it and it acts as my backup board. I am doubtful that I will find the issue with the 2nd copper coloured board.

bertrammatrix wrote on 2025-03-25, 16:20:

Feipoa did you mention somewhere that you run 128mb of ram on this? If so, does the uncached region only go from 5x mb to 64mb or from 5x mb all the way to 128mb (ie all memory above that point is uncached)

I never noticed cachechk pointing out any uncached regions. Cachechk looks identical for the 1996 and 1998 BIOSes. The only indicator that something was amiss with 64 MB installed was the horrific Quake benchmark score. Or are you referring to CTCM's uncached regions? I did not check CTCM.

EDIT:
I'm not sure what the 1998 and later 1996 BIOS brought to the system because I still was unable to use a 32 GB CF card w/BIOS support on the 1998 BIOS. To get around this problem, I have Win95 and NT4 setup on an 8 GB CF card, split 50/50. Then, I added a 32 GB CF card as slave to be accessed within Windows only. I had a horrific time finding a sound card that worked well at 180 MHz, so I'm not sure if these later BIOSes improved sound support either. Of my entire VLB card fleet, only two cards worked well at 180 MHz.

I am using Pancakepuppys 1024k cache stick, it has IDT chips, I think they are 12ns. I also have the stock 256k one for comparing with.

It looks like you are right- the ram itself influences this more then I realized. IE I can run most any ram at 1/0 at 60 mhz but only some likes to work with the cache settings sped up. Wouldn't you know it - the best for this out of my modules is the 64mb I'm using in the "daily driver", it also is one with 50ns chips and a voltage regulator.

I did more tests, There most definitely is a difference in what cachechk reports between the last 1998 bios, and the only properly working 1996 one, which corresponds to the crap quake results.

At 2x60 mhz with an IBM 5x86c, cache 3-2-2 memory 1/0 I ran -

256kb L2 wt 64mb ram w 98 bios

1024kb L2 wb 64mb ram w 98 bios

1024kb L2 wb 82mb ram w 98 bios - I wanted an answer if the board caches normally after the 8mb gap - it does. What really gets me is the access time for those uncached 8mb - you would think it would be at 19us like all other main memory accesses but it's actually 35us which is way worse, no wonder it hinders performance

1024kb L2 wb 82mb ram w 05/06/96 bios - everything works, all cached properly. Note the test only seems to go so high, not sure if it's a program glitch or has something to do that I was just using a random (stability unknown) 16mb stick to up the ram amount. You get the point though- no uncached areas.

My thoughts -
I wonder, would that difference in access time correspond to an extra wait state added to the access of those particular memory addresses? Could this have been initially done to compensate for a timing problem on one of the revisions of the board (perhaps to do with concurrent use of the 30 pin modules, which would likely be 70ns). Could it then be possible that this slowed down memory region was no longer a necessity on v3.4 b/f boards since they use only 72pin simms and hence the factory 05/06/96 bios no longer has this "feature"...? I guess we'll never know for sure

Forgot last photo

1024kb L2 wb 82mb ram 05/06/96 bios

The 64 MB bug may very well have something to do with the 30-pin SIMMs from the earlier revisions. I don't think PC Chips let their firmware guys spend much time on thinking about their little bugs.

You have a lot of patience to let cachechk run through the whole memory size. This explains why I don't see anything different in cachechk between '96 and '98 - I just let it run up to ~8 MB.

So you found a 64 MB module that will do 1/0 ws with 2-1-2 L2? Is it stable in Windows?

feipoa wrote on 2025-03-27, 02:03:

The 64 MB bug may very well have something to do with the 30-pin SIMMs from the earlier revisions. I don't think PC Chips let their firmware guys spend much time on thinking about their little bugs.

You have a lot of patience to let cachechk run through the whole memory size. This explains why I don't see anything different in cachechk between '96 and '98 - I just let it run up to ~8 MB.

So you found a 64 MB module that will do 1/0 ws with 2-1-2 L2? Is it stable in Windows?

I wish. Only on a cold morning can I get a completed 2-2-2 benchmark, and here and there I was able to pull off 3-1-1 in windows at 2/1 before things warm up. This is on the two v3.4's, my v1.5 definitely wont boot with anything but 3-2-2, which is to be expected, my best genuine dip sram is all just 15ns, and any chinese stuff that has 10ns labels that I have is just garbage comparatively (can barely pull off regular timings at lower frequencies)

Here's an image of the 128 MB, 50 ns, EDO module I use on my M919. Shown is the front/back of the module. Only this module would allow for the exceptional performance and stability. Perhaps reach out to Memory Masters on eBay to see if they have any more.