>"This debugger is divided into two parts: the debugger (written entirely in assembly and running on the hardware being debugged) and the bridge, written in C and running on [a second PC running] Linux.
The debugger is the injectable code, written in 16-bit real-mode, and can be placed within the BIOS ROM or any other real-mode code. When executed, it sets up the appropriate interrupt handlers, puts the processor in single-step mode, and waits for commands on the serial port.
[...]
BREAD can also debug arbitrary code in real-mode, such as bootable code or DOS programs too."
There's a brilliant idea here, beyond just BIOS debugging -- that idea is that you don't run (don't need to run!) an entire debugger with all of its code, lookup tables, complexity and GUI dependencies on one PC (where running such code has a greater chance to interfere with the program being debugged -- this is especially true in non-multitasking, non-multiuser, pre-OS, pre-Protected Mode boot environments), you run them on a second PC, and you only run the absolute minimum amount of code on the debugged PC, only enough to send the smallest amount of binary information to the debugger on the second PC, where it can perform all of the necessary processing (lookup assembly instructions, convert them from binary to human readable, display them on its GUI, allow mouse movements, etc., etc.)
Which has applications beyond mere BIOS debugging, which the author points out.
>"This debugger is divided into two parts: the debugger (written entirely in assembly and running on the hardware being debugged) and the bridge, written in C and running on [a second PC running] Linux.
The debugger is the injectable code, written in 16-bit real-mode, and can be placed within the BIOS ROM or any other real-mode code. When executed, it sets up the appropriate interrupt handlers, puts the processor in single-step mode, and waits for commands on the serial port.
[...]
BREAD can also debug arbitrary code in real-mode, such as bootable code or DOS programs too."
There's a brilliant idea here, beyond just BIOS debugging -- that idea is that you don't run (don't need to run!) an entire debugger with all of its code, lookup tables, complexity and GUI dependencies on one PC (where running such code has a greater chance to interfere with the program being debugged -- this is especially true in non-multitasking, non-multiuser, pre-OS, pre-Protected Mode boot environments), you run them on a second PC, and you only run the absolute minimum amount of code on the debugged PC, only enough to send the smallest amount of binary information to the debugger on the second PC, where it can perform all of the necessary processing (lookup assembly instructions, convert them from binary to human readable, display them on its GUI, allow mouse movements, etc., etc.)
Which has applications beyond mere BIOS debugging, which the author points out.
Anyway, to the author -- well done!