2010/3/10 Kevin O'Connor kevin@koconnor.net:
On Wed, Mar 10, 2010 at 11:49:48AM +0800, Roy Tam wrote:
2010/3/10 Kevin O'Connor kevin@koconnor.net:
SeaBIOS has a wealth of debugging information that could help solve these issues.
Tried this this BIOS and 2 debug logs generated. seabios-debug.log is booting fdos0138.img and closes QEMU after boots to prompt. seabios-debug-2.log is booting fdos0138.img and type something and Illegal Instruction occurred.
I don't see an "Illegal Instruction" message. Instead, I see the keyboard just not working. What qemu version and what command line did you use?
latest git today. when you type fast.
I've tracked down why keys are lost on SeaBIOS and not lost on Bochs BIOS. The fdos0138.img code is taking over the irq handler for the ps2 port hardware irq. When the irq fires, it reads the ps2 port for the key data and then calls the bios irq handler assuming it will reread the key and process it. However, SeaBIOS reads the ps2 port status indicator and finds that there is no data pending (because the key was already read by the fdos0138.img irq handler).
Bochs BIOS just reads the data from the ps2 port and assumes it is for the keyboard. SeaBIOS verifies the data being read and wont process random data from the port.
What the fdos0138.img image is doing is broken - once it reads the key from the ps2 port, nothing stops a new key from being read the next time something reads from the port. Indeed, although the keyboard works in qemu-0.11 for fdos0138.img, if one types fast they'll see duplicate and lost keys.
But it is how programs(Chinese/Japanese/Korean Display Systems, GW-BASIC, etc.) in the past get input from keyboard. "Consider" legacy as "broken" is wrong IMHO.