写入BIOS Flash ROM时出现黑屏死机，请求排查相关汇编代码问题

Alright, let's break down exactly what's going wrong with your assembly code and why it's triggering that dreaded black screen crash—there are some critical red flags here:

1. You're Trying to Write to Read-Only BIOS ROM #

This chunk of code is an immediate showstopper:

mov ax,0F000h
mov es,ax
xor di,di
mov cx,0010h
mov al,11h
cld
rep stosb

0F000h is the start of the BIOS ROM address space—ROM is read-only by design during normal system operation. You haven't performed any steps to unlock write protection for this region, so attempting to write here will instantly trigger a hardware fault, crashing the system outright.

If your goal was to modify BIOS runtime data, you should target the BIOS Data Area (BDA) in RAM (usually the 0040h segment), not the read-only ROM itself.

2. No Error Checking for BIOS Function Calls #

You're calling INT 1Ah with subfunctions 0B108h and 0B10Bh, but you never verify if these calls succeeded. If your BIOS doesn't support these specific subfunctions (which is entirely possible—BIOS implementations vary widely across hardware), you'll be proceeding with invalid register values, leading to unpredictable behavior and crashes.

Always check the return status after BIOS interrupt calls. Validate the carry flag (CF) or return values in AX (depending on the specific function's documentation) and handle failures gracefully instead of plowing ahead blindly.

3. Unnecessary Long Interrupt Disabling #

You start with cli to disable interrupts, and only re-enable them at the end with sti. Leaving interrupts disabled for extended periods can cause the system to miss critical hardware interrupts (like timer ticks), leading to unresponsiveness. Worse, an unmaskable interrupt (NMI) hitting while interrupts are disabled can leave the system in an unrecoverable state.

Only disable interrupts for the absolute minimum time needed (e.g., during a critical data transfer), not for the entire duration of your code.

4. Misuse of wbinvd #

The wbinvd instruction writes back CPU cache to memory and invalidates the cache—this is only useful if you've legitimately modified memory-mapped hardware or unlocked ROM. Since your write to 0F000h is invalid, this command doesn't fix anything; it just ensures the faulty write is synced, speeding up the crash.

• Remove the ROM write code immediately: Unless you have a very specific reason to modify ROM (and know exactly how to unlock write protection for your hardware), this is the #1 fix needed.
• Add error checking: After each INT 1Ah call, validate the result before moving on to subsequent operations.
• Double-check your interrupt choice: If you're working with display-related functionality, VESA BIOS Extensions (VBE) typically use INT 10h, not INT 1Ah—you might be targeting the wrong interrupt vector entirely.

内容的提问来源于stack exchange，提问作者bruno salvador