[QUOTE="William"] The Floppy disk I had that I marked BIOS for Syntax mother board did had AWD822A.exe and a SP3917.bin file on it when I unziped it. I executed the flash utility and enter file name sp3917.bin. Flash utility seemed to accept the file. Screen flashed and then was blank. The floppy drive light was still on so I waited about 3 minutes but still nothing was happening so I pushed reset. Screen came on with same checksum message. How long does it take for the bios to flash? William [/QUOTE] 3 minutes should be enough time for a flash update, and your EEPROM is 256KB, so the thing isn't that big. Still, I'd be careful with pressing the reset button too quickly. Did you investigate the command line options for the flash program at all ? For example, if you can still boot to DOS, can you use the flash program to make an archival copy of the current contents of the flash chip ? Then, examine the file with a hex editor, and see what is in there. These are some examples of what you might see in the existing 256KB archival file. Address 0 - Main BIOS Code modules delimited with "-lh5-" On the PCChips M811LU V3.1 board, the module names I can see are "a.BIN", "awardext.rom", "ACPITBL.BIN", "AwardBmp.bmp", "awardeyt.rom", "_EN_CODE.BIN", "via_pxe.lom" (for network boot). Each code module is compressed with LHA. The main BIOS body is checksum protected. As far as I know, the boot block won't jump into the main code, unless the checksum is good. The first steps to using the code would be, decompression, followed by shadow copy into system RAM. Address 0x27240 - A blank area. I don't see DMI and ESCD default values in the rest of the file. On an archived file from a working computer, this area of the EEPROM could have been overwritten as a normal part of the BIOS POST process. DMI and ESCD are updated according to the hardware present. This area may also contain text strings, like a serial number put there by the system builder (using a DMI utility). Ideally, it would make the most sense, if these areas were aligned to a block boundary, as the flash could be segmented, and to update DMI or ESCD, you'd want to erase some number of blocks, to make room for the info. Address 0x3E000 - Boot block starts here, and runs to 0x3FFFF. This is an 8K piece of code, which is what is currently being used to boot from the floppy. For a hex editor, you can use a program like this one. Their free edition. [URL]http://www.softcircuits.com/cygnus/fe/[/URL] The M811LU V3.1 motherboard has a manual, even if it is a bit skimpy. Unzip to find a PDF manual. Skip to page 31. [URL]http://download.ecsusa.com/dlfilepcc/manual/m811/811s31.zip[/URL] On page 31, you can see "BIOS Flash Protect" and the default value is [Disabled]. If you clear the CMOS, then the default value should be put back there. That is the only thing I see in the manual, that could prevent the flash update from happening. The M811LU doesn't appear to have a jumper to prevent flash updating. When flashing, always make sure the flash file is the right size. If the board documentation says it is a 256KB EEPROM, then a 256KB (262144 byte) file should be used to flash the board. Similarly, when you make your archive copy of the current rom, it should also weigh in at 262144 bytes. If I look at the options for the award flash program, pn means "No flash programming" and sy means "backup original BIOS". What I'm not sure about, is whether the syntax has to have two file names (even though we're not flashing here), or just the filename that will be used for the archival copy. awdflash.exe backup.bin /pn/sy And checking here, that does appear to be a usable syntax. [URL]http://www.hardwaresecrets.com/printpage/41/1[/URL] When you look at the BIOS flash options, there are these: Sb = Skip boot block Wb = Write boot block Writing the boot block is dangerous, in the sense that you may not be able to boot into DOS any more, if this goes wrong. That is how motherboards get bricked, by the boot block being corrupted (erased but the programming fails to complete). Skipping the boot block, means the area from 0x3E000 to 0x3FFFF should not get updated. Some BIOS flashers beep when the flash update is complete. But I don't know enough about all of them, to say what to expect in this case. There are later Award Flasher programs with slightly more screen information displayed, and that can make it easier to see how the thing is going. This web page shows an example of a more elaborate GUI. [URL]http://support.asus.com/technicaldocuments/technicaldocuments_content.aspx?no=532&SLanguage=en-us[/URL] Paul