megatog615 wrote on 2023-07-06, 15:07:

Other times the POST screen will complain that the cache memory is bad and that I shouldn't enable cache.

This is the definite proof that the cache messages are not fake. If this message appears, the board actually tried to enable the cache, but detected that it malfunctions grossly (like one of the four chips missing).

megatog615 wrote on 2023-07-06, 15:07:

I installed a set of rare 32-pin sram chips and one of them let out magic smoke and could cook an egg with how hot it got!

The most lilkely cause is that you inserted the chip backwards. I know it's embarassing and at first you don't want to believe it, but it happened to me, too. I have a fried Winbond 64kx8 cache chip now, wondering what to do with the other seven chips of that type...

megatog615 wrote on 2023-07-06, 15:07:

The board seems hard-wired for a 256K jumper setting possibly, given how other PCPartner boards of the same era were laid out.

The photos on the retro web show jumpers JP21-JP24 which are exactly at the position on the board where I expect cache size jumpers to be.

megatog615 wrote on 2023-07-06, 15:07:

I genuinely cannot math out the correct chips to order because of how confusing the actual amount of memory they are advertised to handle(256K = 32Kx8??? Okay, so do I need 512K chips rated at 64Kx8 to fill 4 sockets for 256K? What about TAG? Are both the sockets TAG? Or is it a TAG and a dirty socket? What math do I have to do to figure out what to put in those?)

Most likely both sockets are for tag. A 256K configuration on that board would use 4 chips of 64K x 8 for the data memory, and one or two chips at 32K x 8 for tag. Maybe you can leave a socket unpopulated resulting in a smaller cacheable area.

megatog615 wrote on 2023-07-06, 15:07:

I think I'm at my wits end with this thing. It really sucks how a 486DX @50MHz seems to be really hampered by a lack of L2 cache.

It's a DX2 @50MHz, so the FSB is at 25MHz. For that board, it's a good thing. As you only have 4 data chips, this is a single-bank cache configurations. Many 486 boards interleave two banks in the common 8-socket configuration. At 50MHz FSB, using single-banked cache would be no fun. At 25MHz, it should work perfectly given a suitable chipset.

mkarcher wrote on 2023-07-06, 19:53:

megatog615 wrote on 2023-07-06, 15:07:

I installed a set of rare 32-pin sram chips and one of them let out magic smoke and could cook an egg with how hot it got!

The most lilkely cause is that you inserted the chip backwards. I know it's embarassing and at first you don't want to believe it, but it happened to me, too. I have a fried Winbond 64kx8 cache chip now, wondering what to do with the other seven chips of that type...

Well, I remember checking to make sure but it's possible I made a mistake. In any case I don't trust the chips in that set anymore.

mkarcher wrote on 2023-07-06, 19:53:

megatog615 wrote on 2023-07-06, 15:07:

The board seems hard-wired for a 256K jumper setting possibly, given how other PCPartner boards of the same era were laid out.

The photos on the retro web show jumpers JP21-JP24 which are exactly at the position on the board where I expect cache size jumpers to be.

I'm willing to believe you on this. However, I have no idea how they are supposed to be configured. Any time I have one of the TAG sockets populated(it's a specific one, I'm not sure) with the cache sockets also populated the BIOS just says 256K enabled. When I shift the jumpers over by one, for example, it says the cache is bad.

It'd be nice if there was a similar motherboard that I might be able to copy over some configuration on. I get the feeling I might have to turn some sideways and such. However if I just try to install 256K as it seems to expect, it should just work, right?

mkarcher wrote on 2023-07-06, 19:53:

megatog615 wrote on 2023-07-06, 15:07:

I genuinely cannot math out the correct chips to order because of how confusing the actual amount of memory they are advertised to handle(256K = 32Kx8??? Okay, so do I need 512K chips rated at 64Kx8 to fill 4 sockets for 256K? What about TAG? Are both the sockets TAG? Or is it a TAG and a dirty socket? What math do I have to do to figure out what to put in those?)

Most likely both sockets are for tag. A 256K configuration on that board would use 4 chips of 64K x 8 for the data memory, and one or two chips at 32K x 8 for tag. Maybe you can leave a socket unpopulated resulting in a smaller cacheable area.

Okay. It turns out at one point I had enough chips to try this configuration but I never did. I burned one of the 32-pin chips so I'll have to wait for a new set to come from eBay. As it stands I have two ISSI IS61C256AH-15's I can populate the TAG with. I've bought way more cache SRAMs than I care to admit for this thing. Guess I'll sell all the rest if the new ones work.

mkarcher wrote on 2023-07-06, 19:53:

megatog615 wrote on 2023-07-06, 15:07:

I think I'm at my wits end with this thing. It really sucks how a 486DX @50MHz seems to be really hampered by a lack of L2 cache.

It's a DX2 @50MHz, so the FSB is at 25MHz. For that board, it's a good thing. As you only have 4 data chips, this is a single-bank cache configurations. Many 486 boards interleave two banks in the common 8-socket configuration. At 50MHz FSB, using single-banked cache would be no fun. At 25MHz, it should work perfectly given a suitable chipset.

Windows 95 absolutely crawls. Rendering windows, for example, is a tedious process and I rarely drag windows around because of it. I can't believe this performance was acceptable back in 1995(it is my family's first desktop computer) but then again, technology was moving so fast back then. The machine was made for Windows 3.1 but 95 is what it ran for most of its working life(now it is retired and plays DOS games).

I'll update this thread if the new chips work.

Okay, the chips came in the mail today. I tried them out and luckily none of them exploded. However, I am still getting CACHE MEMORY BAD errors, curiously only for a few boot attempts. I think there's some kind of "warming up" that this machine has to do for things to start working 'correctly'. For example, another issue this machine has is that you need to press the RESET button after starting it for it to POST, but after it's been on for about an hour it will start right up from cold just fine. I don't really get why this is, but I replaced the electrolytics on this board(all twenty-something as well as the ten or so on the ISA riser card) so it shouldn't be that? EDIT: I should note that I am running this machine with a modern ATX(FlexATX, really) PSU with an ATX->AT adapter cable. I don't think it's the PSU(the machine was VERY temperamental while using its original PSU).

In any case, once the machine gets its head screwed on correctly it will boot without error but will crash/hang on disk I/O almost immediately. The XTIDE in this machine will report a read error on some disks(I'm using CF cards) or hang up on first read.

I am so close to getting this working I can taste it. It may come down to me having to replace the ceramics if I have to. The machine works fine still if I disable the external cache in the BIOS so at least I haven't broken anything.

megatog615 wrote on 2023-08-08, 14:26:

I think there's some kind of "warming up" that this machine has to do for things to start working 'correctly'. For example, another issue this machine has is that you need to press the RESET button after starting it for it to POST, but after it's been on for about an hour it will start right up from cold just fine.

This sounds like some broken trace, via or solder joint on the board. Thermal expansion can cause a torn trace or broken joint to still make contact when the system warmed up.

Electrolytics could cause "warm-up" issues, too, but you already replaced them, and electrolytics failing when cold is mostly an issue with switch-mode power regulators, and most 486 boards don't have them.

mkarcher wrote on 2023-08-08, 20:21:

megatog615 wrote on 2023-08-08, 14:26:

I think there's some kind of "warming up" that this machine has to do for things to start working 'correctly'. For example, another issue this machine has is that you need to press the RESET button after starting it for it to POST, but after it's been on for about an hour it will start right up from cold just fine.

This sounds like some broken trace, via or solder joint on the board. Thermal expansion can cause a torn trace or broken joint to still make contact when the system warmed up.

Electrolytics could cause "warm-up" issues, too, but you already replaced them, and electrolytics failing when cold is mostly an issue with switch-mode power regulators, and most 486 boards don't have them.

Checking out this board at the workshop we found

U42 (possible tag RAM) assume 62256 pinout -- 80486 address lines
A0-A14
A1-A15
A2-A13
A3-A12
A4-Vcc
A5-NC
A6-A16
A7-A11
A8-A10
A9-A9
A10-A8
A11-A7
A12-A6
A13-A5
A14-A4
--> Given A4 and A5, it seems an 8Kx8 SRAM actually belongs here?

U43 (possible tag RAM) assume 62256 pinout -- 80486 address lines
A0-A16
A1-A15
A2-A14
A3-A13
A4-Vcc
A5-A12
A6-A11
A7-A10
A8-A9
A9-A8
A10-A7
A11-A6
A12-A5
A13-A4
A14--appears to go to the VTech chipset; 0.7 ohms to Vcc, 1.3 ohms to ground

We tried an 8Kx8 in U42 and 32Kx8 in U43 and the system locks up during POST. Various other combinations cause either a hang during POST or a false detection of 256K cache.

Two traces going to the tag write enable pins looked scratched through (the blue wires are from the factory); we asked for advice at the workshop and they thought this was an intentional cut at the factory.

If this image https://theretroweb.com/motherboard/image/35- … b5211517599.jpg is a working configuration, it appears U42, U43, and the data SRAMs are of various types, but it is too blurry to read. It does not appear that it could be integrated comparator tag RAM because MATCH would be hardwired to Vcc. And it doesn't look like relevant x1 SRAM would be 28-pin.

The manual says that using x9 DRAM and x8 SRAM, it is possible to have "Parity checked; must be in WT. Lower performance but better data checking." <-- this suggests there is a way to borrow data bit(s) for use as a cache parity bit instead. If both U42 & U43 are tag RAM, the tag seems unreasonably large (16 bits), looked briefly and did not look like either had obviously unused inputs.

We confirmed based on how the jumpers work that the 32-pin sockets are to support 32Kx9, not 64Kx8 nor 128Kx8. Pin 31 always goes to A16 on the 486; the associated jumpers switch pin 12 between a parity bit vs. A16 to support 28-pin SRAM.
We're giving up on it for now unless something jumps out as super interesting here.

By the way, the symptoms are identical to here: Re: VTech / Laser computers history
Suggesting it does need some special type of chip

jakethompson1 wrote on 2025-04-26, 22:15:

U42 (possible tag RAM) assume 62256 pinout -- 80486 address lines A4-Vcc A5-NC --> Given A4 and A5, it seems an 8Kx8 SRAM actual […]
Show full quote

U42 (possible tag RAM) assume 62256 pinout -- 80486 address lines
A4-Vcc
A5-NC
--> Given A4 and A5, it seems an 8Kx8 SRAM actually belongs here?

I don't think there is an universal agreed numbering of the address pins of the 62256, but going with a common scheme, this would be pin 6 to Vcc and pin 5 not connected. Strapping pin 6 to Vcc makes sense if you want to reduce a 32K x 8 SRAM to 16K x 8, which is the usual requirement for a tag RAM at 256K cache. On the other hand, having pin 5 open makes no sense at all!. If, OTOH, you mean pin 26 is tied to Vcc and pin 1 is open, this is a correct wiring for an 8K x 8 SRAM. In that case, to make that socket compatible with 32K x 8 SRAM, apply a pull-up or pull-down (resistor or direct connection) to the unconnected pin 1.

Assuming pin 5 is open, this indicates an fault. The fault might be a missing jumper or a broken trace. Having pin 5 open causes random (likely possibly unstable) levels at that pin, that might slowly drift towards a constant 0 or 1 while the system is operating, so this is a possible cause for "works after warm-up" effects. If the open pin is pin 5, the most likely issue would be a missing jumper that toggles pin 8 between Vcc (for 8K x 8 at 128K cache) and A17 (for 256K cache).

jakethompson1 wrote on 2025-04-26, 22:15:

U43 (possible tag RAM) assume 62256 pinout -- 80486 address lines
A4-Vcc
A14--appears to go to the VTech chipset; 0.7 ohms to Vcc, 1.3 ohms to ground

0.7 ohms / 1.3 ohms doesn't make sense. I guess you mean 0.7 V / 1.3 V drop displayed in diode check mode, which would make sense for a logic level signal. Having A4 pulled to a constant level clearly seems like the board is intentionally reducing this chip from 32K x 8 to 16K x 8, which is what you would do at 256K cache. If the board supports 512K cache (using 4* 1024KBit data RAM), there should be a jumper that toggles A4 (both sockets) between Vcc and A18.

jakethompson1 wrote on 2025-04-26, 22:15:

We tried an 8Kx8 in U42 and 32Kx8 in U43 and the system locks up during POST. Various other combinations cause either a hang during POST or a false detection of 256K cache.

Assuming you used the "common" layout of 62256 pins, which has A13 and A14 on pins 1 and 26, plugging an 8K x 8 chip there would not use A4 and A5 for addressing that part of the tag, which would be bad and explain why the system doesn't work at all.

jakethompson1 wrote on 2025-04-26, 22:15:

Two traces going to the tag write enable pins looked scratched through (the blue wires are from the factory); we asked for advice at the workshop and they thought this was an intentional cut at the factory.

Yes, I agree. They bodged a "new" write-enable circuit and for that to work, they needed to disable the old write-enable circuit. Whoever installed the blue wires also cut the traces.

jakethompson1 wrote on 2025-04-26, 22:15:

It does not appear that it could be integrated comparator tag RAM because MATCH would be hardwired to Vcc. And it doesn't look like relevant x1 SRAM would be 28-pin.

Yeah, I don't think x1 SRAMs at 28 pins ever were common, so I agree with that. Integrated Comparator also looks unlikely.

jakethompson1 wrote on 2025-04-26, 22:15:

The manual says that using x9 DRAM and x8 SRAM, it is possible to have "Parity checked; must be in WT. Lower performance but better data checking." <-- this suggests there is a way to borrow data bit(s) for use as a cache parity bit instead. If both U42 & U43 are tag RAM, the tag seems unreasonably large (16 bits), looked briefly and did not look like either had obviously unused inputs.

This is an interesting clue. If you didn't mention that the 32-pin sockets were for 32K x 9, I would have expected that one of the tag RAM chips is used either as dirty (in WB mode) or as 4 parity bits (in WT mode), and it might be a x4 chip with 4 separate write enables. But possibly, both is possible: Either you install x9 SRAMs and use their dedicated parity bits, or you install x8 SRAM and repurpose the dirty tag as parity chip.

I didn't yet find x4 SRAMs with dedicated /WE inputs, but I do know that x4 DRAMs with dedicated /CAS pins to enable the individual bits do exist, and they are used on PS/2 SIMMs for parity. Given the board supports quite unusual 32K x 9 data SRAMs, I wouldn't be surprised if one of the tag chips also is a strange type. However, I did find the L7C161 and L7C162 which is an x4 chip with dedicated data in and data out, another scheme common for parity chips! This chip is claimed to be pin compatible with the IDT71981 and CY7C161 (for the L7C161) or the IDT71982 / CY7C162 (for the L7C162). On the other hand, that kind of chips doesn't have /WE on pin 27, so it likely is not the correct chip for this board, too.

mkarcher wrote on 2025-04-27, 08:30:

jakethompson1 wrote on 2025-04-26, 22:15:

U42 (possible tag RAM) assume 62256 pinout -- 80486 address lines A4-Vcc A5-NC --> Given A4 and A5, it seems an 8Kx8 SRAM actual […]
Show full quote

U42 (possible tag RAM) assume 62256 pinout -- 80486 address lines
A4-Vcc
A5-NC
--> Given A4 and A5, it seems an 8Kx8 SRAM actually belongs here?

I don't think there is an universal agreed numbering of the address pins of the 62256, but going with a common scheme, this would be pin 6 to Vcc and pin 5 not connected. Strapping pin 6 to Vcc makes sense if you want to reduce a 32K x 8 SRAM to 16K x 8, which is the usual requirement for a tag RAM at 256K cache. On the other hand, having pin 5 open makes no sense at all!. If, OTOH, you mean pin 26 is tied to Vcc and pin 1 is open, this is a correct wiring for an 8K x 8 SRAM. In that case, to make that socket compatible with 32K x 8 SRAM, apply a pull-up or pull-down (resistor or direct connection) to the unconnected pin 1.

Sorry about that; I printed a cheat sheet before the workshop and can't remember which 62256 datasheet I pulled a pinout from as a reference, but it is attached. It's indeed pin 26 Vcc and pin 1 open on U42. We put a 8kx8 chip in that socket so we wouldn't have to worry about the non-connected pin. And then U43 does use pin 1 (meaning an 8Kx8 does not belong there, so we tried a 32Kx8), but still has 26 wired to Vcc. Winbond 16Kx8 pinout has pin 1 disconnected, so we know that U43 doesn't take that either (and you've pointed out to us before that 16Kx8 was late to the game, and this is a 1991/1992 era board).

mkarcher wrote on 2025-04-27, 08:30:

jakethompson1 wrote on 2025-04-26, 22:15:

U43 (possible tag RAM) assume 62256 pinout -- 80486 address lines
A4-Vcc
A14--appears to go to the VTech chipset; 0.7 ohms to Vcc, 1.3 ohms to ground

0.7 ohms / 1.3 ohms doesn't make sense. I guess you mean 0.7 V / 1.3 V drop displayed in diode check mode, which would make sense for a logic level signal. Having A4 pulled to a constant level clearly seems like the board is intentionally reducing this chip from 32K x 8 to 16K x 8, which is what you would do at 256K cache. If the board supports 512K cache (using 4* 1024KBit data RAM), there should be a jumper that toggles A4 (both sockets) between Vcc and A18.

Those readings were indeed in resistance mode (continuity check) unless we made a mistake in reading the scale while copying them down (you'd think those would be low enough for the continuity check to beep, and it didn't). We tried to interpret your diode check instructions and couldn't figure it out; perhaps the multimeter used is too simplistic as it's just a Harbor Freight one.

mkarcher wrote on 2025-04-27, 08:30:

jakethompson1 wrote on 2025-04-26, 22:15:

The manual says that using x9 DRAM and x8 SRAM, it is possible to have "Parity checked; must be in WT. Lower performance but better data checking." <-- this suggests there is a way to borrow data bit(s) for use as a cache parity bit instead. If both U42 & U43 are tag RAM, the tag seems unreasonably large (16 bits), looked briefly and did not look like either had obviously unused inputs.

This is an interesting clue. If you didn't mention that the 32-pin sockets were for 32K x 9, I would have expected that one of the tag RAM chips is used either as dirty (in WB mode) or as 4 parity bits (in WT mode), and it might be a x4 chip with 4 separate write enables. But possibly, both is possible: Either you install x9 SRAMs and use their dedicated parity bits, or you install x8 SRAM and repurpose the dirty tag as parity chip.

I didn't yet find x4 SRAMs with dedicated /WE inputs, but I do know that x4 DRAMs with dedicated /CAS pins to enable the individual bits do exist, and they are used on PS/2 SIMMs for parity. Given the board supports quite unusual 32K x 9 data SRAMs, I wouldn't be surprised if one of the tag chips also is a strange type. However, I did find the L7C161 and L7C162 which is an x4 chip with dedicated data in and data out, another scheme common for parity chips! This chip is claimed to be pin compatible with the IDT71981 and CY7C161 (for the L7C161) or the IDT71982 / CY7C162 (for the L7C162). On the other hand, that kind of chips doesn't have /WE on pin 27, so it likely is not the correct chip for this board, too.

I found this blog about a different motherboard but that uses the same chipset. See https://hex.ro/wp/blog/laser-expression-486dx … 50-restoration/ , figure "External cache memory + TAG chips installed".
They just have 8Kx8 chips in both tag sockets. As we've found pin 1 of one socket to go to A12, there must be a difference in how the boards are wired, as it seems impossible to put an 8Kx8 into U43 as it wouldn't see A12. Maybe the blurry picture I linked before also was a difference board version, or had different or additional bodge wires (given that the cache area is already suspect with bodges, anything goes).

I also had a look at the BIOS cache detection in the BIOS some more. The cache size is detected by reading a 512K block to flush the cache, then reading 32K beyond that (a guaranteed miss) and measuring the number of 8254 ticks elapsed. Then the code proceeds go downward in memory to read additional 32KB blocks, measuring the number of 8254 ticks elapsed. If the absolute value of the difference between those ticks and the reference "guaranteed value" is more than 511 ticks (428 microseconds by my calculation), the current 32KB block was now a miss instead of a hit, and the cache size has been determined. The code then proceeds to do another check to confirm that the data RAM is working. If the data RAM check fails, there is no option to shrink the detected size of the cache to match that, the cache is declared faulty. In addition, the cache size is stored in a CMOS register only and doesn't affect the chipset registers, nor is there a way to reallocate address lines between tag data lines and address lines as in more sophisticated chipsets. I thought about whether the spurious detections of 256KB cache could have anything to do with having an internal clock multiplier faster than was anticipated when the BIOS was written, or the internal cache being 16KB, or increasing the bus from 25MHz to 33MHz (which the OP has done also), all of which would change this timing somewhat. He did temporarily take out the Am5x86 and restore the onboard 486SX but it still detected the spurious 256K.

jakethompson1 wrote on 2025-04-27, 20:35:

Sorry about that; I printed a cheat sheet before the workshop and can't remember which 62256 datasheet I pulled a pinout from as a reference, but it is attached. It's indeed pin 26 Vcc and pin 1 open on U42. We put a 8kx8 chip in that socket so we wouldn't have to worry about the non-connected pin.

Makes perfect sense, and this likely is what the board designer intended.

jakethompson1 wrote on 2025-04-27, 20:35:

And then U43 does use pin 1 (meaning an 8Kx8 does not belong there, so we tried a 32Kx8), but still has 26 wired to Vcc. Winbond 16Kx8 pinout has pin 1 disconnected, so we know that U43 doesn't take that either (and you've pointed out to us before that 16Kx8 was late to the game, and this is a 1991/1992 era board).

Nevertheless, the Aster 16Kx8 might fit, even though I highly doubt this old board was designed to accept it. That's why you have the Aster/Winbond jumper on some boards.

jakethompson1 wrote on 2025-04-27, 20:35:

mkarcher wrote on 2025-04-27, 08:30:

0.7 ohms / 1.3 ohms doesn't make sense. I guess you mean 0.7 V / 1.3 V drop displayed in diode check mode

Those readings were indeed in resistance mode (continuity check) unless we made a mistake in reading the scale while copying them down (you'd think those would be low enough for the continuity check to beep, and it didn't). We tried to interpret your diode check instructions and couldn't figure it out; perhaps the multimeter used is too simplistic as it's just a Harbor Freight one.

The "continuity check" works different on different meters. It usually is a secondary function either to the 200ohm range, or to the diode check range. It seems the meter you used uses the "diode check" function as "backend" for the continuity test. In that case, the beep threshold is typically around 0.05 to 0.1V. No beep at 0.7/1.3 is perfectly fine. If "continuity check" were backed by resistance measurement, the beep threshold is typically around 20 to 50 ohms. So "no beep" at 0.7 / 1.3 further enforces my assumption, that those readings are voltage readings, not ohms reading. The meter display should display a unit as well, but I wouldn't trust a harbour freight meter to have the correct unit indicator displayed in continuity check mode.

jakethompson1 wrote on 2025-04-27, 20:35:

I found this blog about a different motherboard but that uses the same chipset. See https://hex.ro/wp/blog/laser-expression-486dx … 50-restoration/ , figure "External cache memory + TAG chips installed".
They just have 8Kx8 chips in both tag sockets.

...which clearly is enough for 128KB of cache. You only have 8K cache lines.

jakethompson1 wrote on 2025-04-27, 20:35:

As we've found pin 1 of one socket to go to A12, there must be a difference in how the boards are wired, as it seems impossible to put an 8Kx8 into U43 as it wouldn't see A12. Maybe the blurry picture I linked before also was a difference board version, or had different or additional bodge wires (given that the cache area is already suspect with bodges, anything goes).

The bodges you showed seem to send a modified /WE signal to the tag RAMs, while still sending the original /WE signal somewhere else. It shouldn't affect address routing. We have this strange extra connection into U43 on pin 10 (the one next to the data pin typically called D0), which may be another address bit (assuming 32K x 8 is the correct assumption), or another control signal. As all the other address bits match the location of the 62256 pinout, a x4 or x1 chip wouldn't make sense. But, what if there were 8Kx9 chips? I found a datasheet for 32Kx9 chips, the Motorola MCM6205D, which has a pinout matching what you observed on the data sockets, and would you look at this!, the Fujitsu MB81C79A is a perfect match to what you observe on U43, albeit this specific chip is quite slow. Further research showed a firmware update for the retro chip tester pro, which mentions these chip numbers for 8K x 9: P4C163, CY7C182, IMS1695, IDT7189, M5M5179, uPD4369, TMM2089. I randomly picked one of those numbers, and again got the same pinout. That's very likely the solution to the tag mystery.

jakethompson1 wrote on 2025-04-27, 20:35:

I also had a look at the BIOS cache detection in the BIOS some more. The cache size is detected by reading a 512K block to flush the cache, then reading 32K beyond that (a guaranteed miss) and measuring the number of 8254 ticks elapsed. Then the code proceeds go downward in memory to read additional 32KB blocks, measuring the number of 8254 ticks elapsed. If the absolute value of the difference between those ticks and the reference "guaranteed value" is more than 511 ticks (428 microseconds by my calculation), the current 32KB block was now a miss instead of a hit, and the cache size has been determined.

OK, I seem to get the first part: You read 512KB with L1 enabled. This makes sure the end of this 512KB block is in cache. For 128KB of cache, 384k..511k is now cached (assuming the 512K block starts at 0). This obviously means 512k..543k is not in cache, and reading this block is a guaranteed miss, which can be used as reference time for misses. After that read, 416k..543k is now in cache, and you can go downwards, expecting hits until you get to 384..415, which is a miss again. The correct implementation of that interpretation would be to "proceed to go downward in memory to read additional 32KB blocks" (as you set), until the timing difference between reading that block and the reference value for miss is low again. While reading cache hits, the difference will be high, if the reference value is indeed what was obtained the first time 512k..543k was read. Obviously, this algorithm only works if the tag is working. As I am quite confident that the chipset requires an 8Kx9 tag (for addresses) and th 8Kx8 tag (used as 8Kx1 for dirty or 8Kx4 for parity), failure of this algorithm with a bad type of tag chip isn't surprising.

mkarcher wrote on 2025-04-27, 21:22:

jakethompson1 wrote on 2025-04-27, 20:35:

As we've found pin 1 of one socket to go to A12, there must be a difference in how the boards are wired, as it seems impossible to put an 8Kx8 into U43 as it wouldn't see A12. Maybe the blurry picture I linked before also was a difference board version, or had different or additional bodge wires (given that the cache area is already suspect with bodges, anything goes).

The bodges you showed seem to send a modified /WE signal to the tag RAMs, while still sending the original /WE signal somewhere else. It shouldn't affect address routing. We have this strange extra connection into U43 on pin 10 (the one next to the data pin typically called D0), which may be another address bit (assuming 32K x 8 is the correct assumption), or another control signal. As all the other address bits match the location of the 62256 pinout, a x4 or x1 chip wouldn't make sense. But, what if there were 8Kx9 chips? I found a datasheet for 32Kx9 chips, the Motorola MCM6205D, which has a pinout matching what you observed on the data sockets, and would you look at this!, the Fujitsu MB81C79A is a perfect match to what you observe on U43, albeit this specific chip is quite slow. Further research showed a firmware update for the retro chip tester pro, which mentions these chip numbers for 8K x 9: P4C163, CY7C182, IMS1695, IDT7189, M5M5179, uPD4369, TMM2089. I randomly picked one of those numbers, and again got the same pinout. That's very likely the solution to the tag mystery.

In this picture: https://theretroweb.com/motherboard/image/35- … b5211517599.jpg U43 definitely could be MCM or M5M something, it's just super hard to read. Thanks for the catch, now those resistance values (it did say ohms) on pin 10 make sense if it's really a data pin, and that's why it goes to the chipset rather than the CPU.

mkarcher wrote on 2025-04-27, 21:22:

OK, I seem to get the first part: You read 512KB with L1 enabled. This makes sure the end of this 512KB block is in cache. For 128KB of cache, 384k..511k is now cached (assuming the 512K block starts at 0). This obviously means 512k..543k is not in cache, and reading this block is a guaranteed miss, which can be used as reference time for misses. After that read, 416k..543k is now in cache, and you can go downwards, expecting hits until you get to 384..415, which is a miss again. The correct implementation of that interpretation would be to "proceed to go downward in memory to read additional 32KB blocks" (as you set), until the timing difference between reading that block and the reference value for miss is low again. While reading cache hits, the difference will be high, if the reference value is indeed what was obtained the first time 512k..543k was read. Obviously, this algorithm only works if the tag is working. As I am quite confident that the chipset requires an 8Kx9 tag (for addresses) and th 8Kx8 tag (used as 8Kx1 for dirty or 8Kx4 for parity), failure of this algorithm with a bad type of tag chip isn't surprising.

And that sounds right about me reading the hit/miss logic backward, I've stared at it for a while, the 511 thing isn't implemented obviously, rather:

; bx = guaranteed miss timing, ax = current hit/miss timing
sub ax,bx
jns L1
neg ax
L1: cmp ah,1
jbe miss
dec di ; di = 16-size of cache in 32KB units
jnz again

64kb of Cache is Good
256kb of Cache is Great.

You only gain at best 3% CPU performance
After this you don’t gain much better performance

Run “Topbench” and “check cache” programs to bench mark you computers performance.

Link to DOS benchmark tools package
https://www.philscomputerlab.com/dos-benchmark-pack.html

Well, with the help of jakethompson1 we were able to track down some 8kx9(MCM6265CP15). It was expensive, and it still doesn't work, so I'm pretty bummed out.

HOWEVER, the machine consistently reports its "CACHE MEMORY BAD. DO NOT ENABLE CACHE !" line after memory check. I don't know what this means for figuring this out but at least it's consistent.

I have to say that cache memory on vintage boards like this is near-absolutely arcane to me. Lucky I have the most difficult board to get cache working to confuse me even further.

EDIT: Oh yeah, jakethompson1 told me to run this in debug(cache memory bad message disables external cache):

megatog615 wrote on 2025-05-01, 21:03:

Well, with the help of jakethompson1 we were able to track down some 8kx9(MCM6265CP15). It was expensive, and it still doesn't work, so I'm pretty bummed out.

HOWEVER, the machine consistently reports its "CACHE MEMORY BAD. DO NOT ENABLE CACHE !" line after memory check. I don't know what this means for figuring this out but at least it's consistent.

So you put an 8Kx8 RAM chip into U42, and the new 8K*9 chip into U43? Do not use an 8K*9 chip for both!

The message looks like the verification of the data cache now fails. jakethompson1 mentioned jumpers to switch between a 32K*8 and 32K*9. Are you sure those jumpers are set to the 32K*8 position? Is the data RAM 4 chips of 32K*8 each? You need to have the size of data RAM consistent with the size of the tag RAM, which seems to be fixed at 8K * 8/9. The data RAM needs 4 times as much depth, because the tag has one entry per cache line, and each data chip has 4 entries per cache line, so the data chips need to be either 32K*8 or 32K*9. Assuming you have 4 chips of 32K*8 installed, the jumpers J21..J24 need to be in the position closer to the cache chips, assuming "image 3 of 7" on The Retro Web shows a working configuration.

Do you have configuration for parity in cache in SETUP? Can you select WB/WT in SETUP? If you don't have a setting to disable parity, try setting the cache mode to WT.

megatog615 wrote on 2023-07-06, 15:07:

I have this 486 board by PCPartner(part of a VTech Laser 486SX/3). It has four 32-pin cache sockets and two 28-pin TAG/dirty sockets(I am speculating here). I lost the documentation for this machine years ago(and lament it every day), but I have tried various configurations of cache.

I have a board with the same chipset with 128KB cache installed. According to the chipset documention that is the maximum. (See the documentation for for this board: https://theretroweb.com/motherboards/s/pcpart … 9b-c0044-1#docs)

Anyway here is a picture of the cache on my board:

Dorunkāku wrote on 2025-05-01, 21:53:

megatog615 wrote on 2023-07-06, 15:07:

I have this 486 board by PCPartner(part of a VTech Laser 486SX/3). It has four 32-pin cache sockets and two 28-pin TAG/dirty sockets(I am speculating here). I lost the documentation for this machine years ago(and lament it every day), but I have tried various configurations of cache.

I have a board with the same chipset with 128KB cache installed. According to the chipset documention that is the maximum. (See the documentation for for this board: https://theretroweb.com/motherboards/s/pcpart … 9b-c0044-1#docs)

Anyway here is a picture of the cache on my board:

Nice.
We're 99% confident ruling out a 6164 chip in the upper tag socket on his board, because of the pinout going to it.
Given all the factory bodge wires on the back, I would not be surprised if there are various revisions and bodges within revisions to change the pinouts around.
It's too bad, a datasheet would be very helpful.

mkarcher wrote on 2025-05-01, 21:21:

So you put an 8Kx8 RAM chip into U42, and the new 8K*9 chip into U43? Do not use an 8K*9 chip for both!

Yes, 8Kx8 in U42, 8Kx9 in U43.

mkarcher wrote on 2025-05-01, 21:21:

The message looks like the verification of the data cache now fails. jakethompson1 mentioned jumpers to switch between a 32K*8 and 32K*9. Are you sure those jumpers are set to the 32K*8 position? Is the data RAM 4 chips of 32K*8 each? You need to have the size of data RAM consistent with the size of the tag RAM, which seems to be fixed at 8K * 8/9. The data RAM needs 4 times as much depth, because the tag has one entry per cache line, and each data chip has 4 entries per cache line, so the data chips need to be either 32K*8 or 32K*9. Assuming you have 4 chips of 32K*8 installed, the jumpers J21..J24 need to be in the position closer to the cache chips, assuming "image 3 of 7" on The Retro Web shows a working configuration.

Yes, 32Kx8 x4 data cache is set. Jumpers are set closest to the cache chips(short 1-2).

mkarcher wrote on 2025-05-01, 21:21:

Do you have configuration for parity in cache in SETUP? Can you select WB/WT in SETUP? If you don't have a setting to disable parity, try setting the cache mode to WT.

All combinations of these settings still fail with the same message. Note that the board also has jumpers for enabling or disabling parity, which I have left OPEN(no parity). Shorting 1-2 or 2-3 enables parity in one of two configurations, I believe: Cache and RAM, or just RAM.

Noted something in the pictures of the various boards. The white sticker model number on back top of back port near KB port seems to vary a lot even though the board silkscreen show same model.
The TRW ones have 522535xx, both mine and Wzrd have 52252715. Just an observation and most likely revisions...

megatog615 wrote on 2025-05-01, 21:03:

Well, with the help of jakethompson1 we were able to track down some 8kx9(MCM6265CP15). It was expensive, and it still doesn't work, so I'm pretty bummed out.

HOWEVER, the machine consistently reports its "CACHE MEMORY BAD. DO NOT ENABLE CACHE !" line after memory check. I don't know what this means for figuring this out but at least it's consistent.

Does it report any cache amount before that error with the 8kx9 in u43 ?
Fastest 8kx9 I recently found were -30 which I figure would not work, not fastest enough.
Funny thing is that using 2 x 8kx8 tags (with 32kx8's) my board says "256k cache enabled" then either hangs or gives an error after..same with all 32kx8.
added: found a TC5589P-15 (8kx9) in my junk pile, not sure if it works (and why was not in with my other cache chips)...similar pinout to MCM6265CP...