I have added the chipset here, you can click on the chipset's name to get more infos (maybe mR_Slug even added the datasheet somewhere)
http://www.win3x.org/uh19/motherboard/show/4034

An older revision of your board is already documented in our database here http://www.win3x.org/uh19/motherboard/show/4035

Your revision seem to have spots to install a 3.3v regulator so I guess that is the main difference.

Also your board has "fake cache" in the sense of Octek lied with their "DCA" claims and thus made a vlb cacheless motherboard.

A more straight photo for our database would be perfect (although if you don't have time, the current one will suffice, we can just to improve it ourselves)
And a bios dump could be interesting as well. If your version is missing we can add it.

From my experience, I have swapped KBCs without a hitch, but maybe they're not always 100% compatible, just tried it few times.

I will take a more topdown photo for you tonight, as well as dumping the BIOS currently on the chip with my 688II Pro. Always happy to help.

Now, someone help me fix it 😁

I'd suggest try an AMIBIOS, perhaps ? You might be more familiar with AMI POST codes/beeps.

If the BIOS is outputting codes/beeps then there is hope. Things I would check:

• Since you had to straighten some pins on the chipset, it would be a good idea to go one by one with a needle and give them a slight nudge, to verify that they're still soldered to their pads
• I have seen shorted KB controllers a few times, maybe it blew due to the previous user hot-plugging the keyboard? In any case, a controller from another 486 or similar is probably compatible
• As the battery was near the power connector & memory slots, make sure the +5V line is properly connected to the SIMM slots (you may need the SIMM pinout)
• You can also check connectivity between the SIMM slots, not sure if they are always connected in the same way on all boards though
• Try using only one bank of RAM (Bank 0) and swapping the SIMMs to discard failed memory modules
• If there is corrosion under the memory slots, you will need to desolder. I have done it in the past and yeah, not fun, but I had a worse time with 72-pin sockets... ugh

Well, it seems the BIOS chip is also toast? It's a TMS JL 27C512-15, and for whatever reason I can't seem to program it with my 688II Pro. I managed to read and dump the BIOS, though, which seems to be an MR BIOS v1.63 that does not appear to be available anywhere online, so find it attached here. After I tried to program the EPROM to a later BIOS version (and failed) I realized that a few bits in the first byte of the dump came up as different from what was on there, for whatever reason (I think trying to program it may have corrupted it?). Regardless, this dump may not be 100% correct so do not flash it unless you know you can revert.

I ordered some 27C512 EPROMs to program with the AMI and a later MR bios images, I will see if those actually resolve the issue.

I pulled one of these boards out of storage and was struggling with the same beep code issue thinking the BIOS ROM was bad or, worse, the motherboard was bad. Eventually I landed on this post so figured I might as well post what ultimately fixed the problem for me.

Reading the manual on TRW it turns out these things need special ED-RAM modules in the first two slots. And as chance would have it, I happened to have two sticks of ED-RAM in my big box of 72-pin RAM:

And sure enough with those two sticks of RAM installed in the first two RAM slots, the board POSTS fine:

Based on the configuration diagrams in the manual and its behaviour with regular 72pin FPM modules installed the board won't function without ED-RAM installed in those first two slots. The other two slots can be used for regular 72pin RAM but the manual notes that this may reduce performance.

davidrg wrote on 2024-04-10, 10:15:

Reading the manual on TRW it turns out these things need special ED-RAM modules in the first two slots. And as chance would have it, I happened to have two sticks of ED-RAM in my big box of 72-pin RAM:

Do you have any additional info on ED-RAM?

I don't see anything listed here: https://www.vogonswiki.com/index.php/72-pin_SIMM

sucks appiah4 uploaded picture to postimage and not directly here 🙁
retroweb still doesnt have an entry for this VL with 72pin simm model.
Is it still based on Headland HTK340? ED-RAM is really weird. Very fast, Cache fast in fact!

Deksor wrote on 2020-11-09, 09:29:

Also your board has "fake cache" in the sense of Octek lied with their "DCA" claims and thus made a vlb cacheless motherboard.

turns out they didnt lie like pcchips
davidrg module is 15ns 😮
http://bitsavers.trailing-edge.com/components … ry_Products.pdf 2-81:
• 2KByte SRAM Cache Memory for 15ns Random Reads Within a Page
• Fast DRAM Array for 35ns Access to Any New Page
• Write Posting Register for 15ns Random Writes and Burst Writes
Within a Page (Hit or Miss)
• 2KByte Wide DRAM to SRAM Bus for 58.6 Gigabytes/Sec Cache Fill
• On-chip Cache HitlMiss Comparators Maintain Cache Coherency
on Writes
• Hidden Precharge and Refresh Cycles

Those are DRAM modules with build in SRAM cache 😮 and 15ns burst access:
"EDRAM memory module supports zero-wait-state burst read
operations at up to 40MHz bus rates in a non-interleave configuration
and >66MHz bus rates with a two-way interleave configuration"

My board is this:

Which seems to match this page on TRW: https://theretroweb.com/motherboards/s/octek- … o-dca-ii-486-33 - I assume its the same as what appiah4 had, though perhaps there are other models with this DCA stuff.

I wonder what the chances are of finding more of this RAM are. I guess having more than two modules isn't useful, but having two larger modules would be. Apparently they came in an 8MB flavour, with 16MB modules scheduled to be released in Q2 1995 (no idea if that happened).

Edit: A post over here with a bit more detail on this stuff. Apparently the DCA2 boards need ED-RAM, while the regular DCA boards don't. And it turns out I probably do have more EDRAM, though I don't know if its compatible with a PC or if I really want to steal it from some DEC KZPAC array controllers.