Hello sedrosken,
Since DMI is one of those things stashed in the BIOS Flash chip like the ESCD, I wonder if a slight incompatibility between the BIOS and the Flash chip you're using could cause an issue.
Do you have any trouble with Updating ESCD... freezing on this board or does it work ...Success or perhaps you've never done anything to trigger it?
Hopefully chkcpu will see this thread.

jakethompson1 wrote on 2026-09-14, 06:31:

Hello sedrosken, Since DMI is one of those things stashed in the BIOS Flash chip like the ESCD, I wonder if a slight incompatibi […]
Show full quote

Hello sedrosken,
Since DMI is one of those things stashed in the BIOS Flash chip like the ESCD, I wonder if a slight incompatibility between the BIOS and the Flash chip you're using could cause an issue.
Do you have any trouble with Updating ESCD... freezing on this board or does it work ...Success or perhaps you've never done anything to trigger it?
Hopefully chkcpu will see this thread.

Nope, no weird lockups when booting. I’ve cleared and had it rebuilt a couple of times now. It updates the ESCD, builds the DMI, verifies the DMI, then boots without issue. The freezes come in when something later tries to look at the DMI data (Speedsys, WMI, DXDiag like I said).

This is the original MX28F1000P that came with this board and the J.3 BIOS is a modified version of the latest Biostar build as far as I understand.

Messing around with the older versions of the BIOS has informed me that apparently this DMI freeze happens regardless of BIOS version. Has anyone successfully ran a BIOS from another board on this one? I hesitate to try that as I understand things got way more complicated regarding that around this time versus doing something similar on a 486 platform.

Hi Sedrosken,

I’m the guy who did the MB-8500TTD patch J.3 BIOS.
This J.3 BIOS is indeed a modified version of the latest Biostar TTD0616B build. When I made this patched BIOS last year, I didn’t change anything in the DMI processing, so the DMI support is the same as in the original TTD0616B BIOS.

I see that you already tried older BIOS versions as well, but you still get these DMI freezes.
This makes me wonder if we are dealing with a BIOS issue here, or if there is something else at play.
To find-out if the BIOSes DMI structure is correct, I’ve attached the CTDMI DOS tool. One of many great tools from the German c’t Magazine.
Run CTDMI.EXE from a clean-boot DOS prompt and use the command:

CTDMI /DEB > DMI_TTD.TXT

to get a debug dump from the complete DMI structure, and send the TXT-file with your reply.

I also like to know if you get the “Verifying DMI Pool Data …….” line on the BIOS summary screen. Normally there should be nothing behind this line.
Only when changing hardware, like adding or removing memory, you should see “Update Success” behind this line.
Let us know if you see something different.

Cheers, Jan

Thank you so much for your reply! I’ll grab the utility and give it a whirl when I get home from work this afternoon.

I couldn’t tell you for certain exactly word for word what it says regarding DMI during bootup, but I’ll grab a screencap with pause/break as well to dissect. If it helps, it doesn’t seem to depend on what devices I have attached — I’ve tried my G200 vs a Trident card, and a 3com 905 card vs my PRO/100B. I’ve left out my sound card at various times as well.

Typically I disable com2/lpt1 and leave com1 active at standard settings, if that’s useful information to have too.

Again, I’ll grab those dumps for you when I get back this afternoon.

DMI-Info, c't/Devid Espenschied (/as), V1.50, 02/2001 PnP-Struktur bei : F000:BB60, Checksum: 00, V1.0, API: F000:BBB0, Sel: F00 […]
Show full quote

DMI-Info, c't/Devid Espenschied (/as), V1.50, 02/2001
PnP-Struktur bei : F000:BB60, Checksum: 00, V1.0, API: F000:BBB0, Sel: F000
SM-Strukur : nicht gefunden
DMI-Struktur : nicht gefunden
DMI gefunden, aber keine Strukturen vorhanden.
Programm wird beendet.

Is... this correct? If I'm translating this correctly, there... aren't any structures to read? Is that what's causing the freeze?

I use the J.2 patch on my MB-8500TTD system and I can run dxdiag without issue. I'm using an AMD K6-III+ at 6x83.3 MHz, GF4, Win98SE, and Direct X 8.1.

Sedrosken wrote on 2026-09-18, 01:23:

Is... this correct? If I'm translating this correctly, there... aren't any structures to read? Is that what's causing the freeze […]
Show full quote

DMI-Info, c't/Devid Espenschied (/as), V1.50, 02/2001 PnP-Struktur bei : F000:BB60, Checksum: 00, V1.0, API: F000:BBB0, Sel: F00 […]
Show full quote

DMI-Info, c't/Devid Espenschied (/as), V1.50, 02/2001
PnP-Struktur bei : F000:BB60, Checksum: 00, V1.0, API: F000:BBB0, Sel: F000
SM-Strukur : nicht gefunden
DMI-Struktur : nicht gefunden
DMI gefunden, aber keine Strukturen vorhanden.
Programm wird beendet.

Is... this correct? If I'm translating this correctly, there... aren't any structures to read? Is that what's causing the freeze?

The attachment IMG_5231.jpg is no longer available

The attachment DMI_TTD.TXT is no longer available

Okay, this explains a lot!

The CTDMI tool doesn’t find the DMI structure on your system, which is incorrect.
When I run the 8500TTD patch J.3 BIOS in a compatible i430TX machine in the 86Box emulator, I get this CTDMI output:

DMI-Info, c't/Devid Espenschied (/as), V1.50, 02/2001 DMI-Struktur bei : F000:5830, Checksum: 00, V2.0, Tab: F000:1000, Anzahl: […]
Show full quote

DMI-Info, c't/Devid Espenschied (/as), V1.50, 02/2001
DMI-Struktur bei : F000:5830, Checksum: 00, V2.0, Tab: F000:1000, Anzahl: 29
PnP-Struktur bei : F000:BB60, Checksum: 00, V1.0, API: F000:BBB0, Sel: F000
SM-Strukur : nicht gefunden

DMI-Revision : 2.0
DMI-Basisadresse : FFFFA000h
Anzahl Strukturen: 29
Grösse Struktur : 73 Bytes
APM-Version : 1.2

This is only the header. The complete CTDMI output is much longer and describes each of the 29 DMI structure entries in detail.

Do you get the three ESCD and DMI Pool messages on every boot? This is also incorrect if so. On a normal boot, you should only see the last “Verifying DMI Pool Data ….” Message, like in this screenshot of the patch J.3 BIOS:

My best guess about the source of this issue would be a failing Flash chip.
Do you have another MX28F1000P chip, or an equivalent 128KB EEPROM like an SST29EE10-PH, W29C010, or W29EE011? You will need an EEPROM programmer though, or use the HOT-Flash method to get the BIOS in the replacement chip.

Jan

feipoa wrote on 2026-09-18, 06:06:

I use the J.2 patch on my MB-8500TTD system and I can run dxdiag without issue. I'm using an AMD K6-III+ at 6x83.3 MHz, GF4, Win98SE, and Direct X 8.1.

Hi feipoa,

Thanks for chiming in and confirming that the patch J.2 BIOS works correctly on your 8500TTD system.
I can add that both the patch J.2 and J.3 8500TTD BIOSes produce the same CTDMI output in 86Box.

I’ve only added 2 additional bug fixes to the J.3 BIOS:
- Fixed the Win98 UDMA mode bug
- Fixed a second 64GB limit bug so the IDE HDD Auto Detection menu selection in the BIOS doesn't hang anymore on >64GB drives.

For all other functions and fixes, the patch J.2 and J.3 BIOS for this board are identical.
So only the latest patch J.3 BIOS is available now on my k6plus page and on TRW.

Cheers, Jan

Sorry, I wasn't intending to highlight the "J.2 patch", implying that it somehow worked better than J.3. It just so happened that J.2 was the patch on my motherboard at present. I have since upgraded to the J.3 patch and it works fine. I'm also able to run Dxdiag without issue. I've not had any issues with this system.

I too, however, also see:

Updating ESCD ...
Building DMI Pool ...
Verifying DMI Poor Data ...

I have the same EEPROM chip model as user Sedrosken, that is, MX28F1000P.

Chkcpu wrote on 2026-09-18, 10:05:

This is only the header. The complete CTDMI output is much longer and describes each of the 29 DMI structure entries in detail.

Yep, indeed that explains a lot. I don't have a DMI structure for it to read, which likely isn't a case these programs have in mind.

Do you get the three ESCD and DMI Pool messages on every boot? This is also incorrect if so. On a normal boot, you should only see the last “Verifying DMI Pool Data ….” Message, like in this screenshot of the patch J.3 BIOS:

Yep, every time.

My best guess about the source of this issue would be a failing Flash chip.
Do you have another MX28F1000P chip, or an equivalent 128KB EEPROM like an SST29EE10-PH, W29C010, or W29EE011? You will need an EEPROM programmer though, or use the HOT-Flash method to get the BIOS in the replacement chip.

I have an AT29C010A in another Socket 7 board I can pull, that one's VPX-based so no big loss even if it worked, which it doesn't really. I've got a TL866II+ and am familiar with the use of minipro, but is the AT29C010A also a 'comparable' chip like you say? Can I just flash the BIN directly to the chip? My file browser seems to believe they're LHA-compressed executables.

Must have indeed been a failing EEPROM. With the AT29C010A off the dead VPX board, freshly written with a copy of TTD_J3, I get "Success" messages after all of the DMI messages during boot and then I can run Speedsys without any weird switches or anything. Thanks so much for the help!

Is the issue related to using an EEPROM chip with a 12 V programming voltage requirement? Does the ESDI space on the EEPROM require 12 V or 5 V to write its data? Do all EEPROM's have the same ESDI space? You have replaced an MX28F1000P (12 V programming) with an EEPROM chip which only needs 5 V for its programming.

Do you recall if this motherboard has a 5V and 12 V jumper setting for the EEPROM? It feels like I have run into this issue on other motherboards which used 12 V EEPROM chips, for which the solution was to use 5 V (programming only) EEPROM chips. This raises the question, why did the board come with 12 V EEPROM chips if this problem exists? Earlier MB-8433UUD boards came with Intel PF28F001 (12 V) EEPROM chips, but later versions of the board tended to come with 5 V EEPROM chips.

I'm not qualified to answer basically any of that... I don't see anything that seems relevant to EEPROM programming silkscreened or in any of the documentation, but I was able to flash updated BIOSes with awdflash in the machine itself, so I don't think it was a programming voltage issue in this case.

Sedrosken wrote on 2026-09-18, 13:34:

Must have indeed been a failing EEPROM. With the AT29C010A off the dead VPX board, freshly written with a copy of TTD_J3, I get "Success" messages after all of the DMI messages during boot and then I can run Speedsys without any weird switches or anything. Thanks so much for the help!

Hi Sedrosken,

Okay you solved it, great!
Yes, the AT29C010A is an equivalent EEPROM and is pin-compatible with the MX28F1000P. And it appears to be supported by the MB-8500TTD BIOS as well, because you report Success messages when the BIOS writes the ESCD and DMI data to the appropriate blocks in the EEPROM at the first boot with the AT29C010A.
Otherwise, you would have seen an “Unknown flash chip” message.

What I’m curious about is what you get for ESCD and DMI Pool messages now on subsequent boots.

feipoa wrote on 2026-09-18, 15:56:

Is the issue related to using an EEPROM chip with a 12 V programming voltage requirement? Does the ESDI space on the EEPROM require 12 V or 5 V to write its data? Do all EEPROM's have the same ESDI space? You have replaced an MX28F1000P (12 V programming) with an EEPROM chip which only needs 5 V for its programming.

Do you recall if this motherboard has a 5V and 12 V jumper setting for the EEPROM? It feels like I have run into this issue on other motherboards which used 12 V EEPROM chips, for which the solution was to use 5 V (programming only) EEPROM chips. This raises the question, why did the board come with 12 V EEPROM chips if this problem exists? Earlier MB-8433UUD boards came with Intel PF28F001 (12 V) EEPROM chips, but later versions of the board tended to come with 5 V EEPROM chips.

The MX28F1000P indeed requires 12V for programming. This 12V supply is needed for any write operation, so both for flashing a new BIOS and for writing other data like ESCD and DMI structures.
For normal (read) operation, the EEPROM uses its 5V supply.
To let this work without having to set a 12V jumper, these ‘28’ type chips have both a Vcc (5V) pin and a Vpp (12V) pin.

The AT29C010A is a ‘29’ type EEPROM that uses 5V for write and read operations. For compatibility with 12V/5V EEPROMs, these 5V only types simply have the Vpp pin internally not connected, so the 12V supply on this pin is not used.

Jan

On subsequent boots, I just get Verifying DMI Pool Data... and then it boots. Everything seems to work as expected.

This system is actually 100% stable at 75FSB -- didn't even need to touch voltage on the CPU. It seemed like it WANTED to work at 83FSB but I got garbage out of my NIC's PXE ROM with the PCI clock at 41.7MHz sometimes and it would pretty universally not finish booting, though it would POST. I bet if I found a NIC that was more tolerant of the out-of-spec PCI bus and bumped the CPU voltage I'd have it at 291MHz right now no sweat.

I played with BIOSes a bit.

I tried another 12 V programming EEPROM, namely an Intel P28F001BX-T150, but the result was the same - ESDI does not update.

I tried W27C010-70, but when approaching the screen which shows DMI, I get "unknown flash type"

I tried W29EE011-150, which is 5 V programmable, and I get "success" when updating DMI/ESDI. This is good news, but makes me wonder why Biostar was shipping these motherboards with an MX28F1000P, which cannot seem to update the ESDI information.

You should be able to use an Intel Pro /1000MT or 100. This is what I use in my motherboard, which runs with an 83 MHz FSB.

The PRO/100B is apparently known to not be especially friendly to out-of-spec PCI busses. Same for the 3C-905/B. I did use a 905C for testing and that did work but even at 3.2v vcore it was just this side of unstable -- able to more or less complete any DOS benchmark (except, oddly, PC Player Bench) and boot into Windows, but closing out of 3DMark 99 Max in a recoverable manner about halfway in. 75FSB is still pretty fast, a noticeable bit of extra pep. I wonder if it's that I'm using SDRAM and didn't disable the L2/remove the TAG, but to be completely honest, if I have to do all that, I'm losing out on the main point of running an 83MHz FSB anyway.

jakethompson1 wrote on 2026-09-14, 06:31:

I wonder if a slight incompatibility between the BIOS and the Flash chip you're using could cause an issue.

I suppose I was on to something.
I'm not sure if DMI is in a special "bank" or "page" on the chip and perhaps the one you had wasn't 100% compatible.