Having reviewed some of the APM1.2 specification, first impression is
that the APM bios is required to provide not only a real-mode and
protected 32-bit mode interface to its functions, but also a 16-bit
protected mode interface, which the apmbios.S code apparently does not
have.
I've tried adding one - although I'm not sure it's correct - and
adjusting function 0x00 (APM installation check) to return 0x03 in cx
(instead of 0x02 to signify the availability of this 16-bit interface)
what's interesting is the debug statements immediately become slightly
more promising:
APM: EAX=00005300
APM: EAX=00005301
APM: EAX=0000530e
APM: EAX=00005300
APM: EAX=00005304
APM: EAX=00005302 [16-bit protected mode interface connect]
APM: EAX=0000530e
As we can see, after having disconnected the real-mode interface the
Windows APM driver seems to try to connect to the 16-bit protected
mode interface (function 0x02). It then calls the APM driver version
function (0x0e). But this isn't good enough. Windows 2000 still
appears to call no further APM functions as it boots and shuts down.
So, what's next?
If it's fair to assume that the Windows 2000 APM driver needs to
interface with the APM bios using the 16-bit protected-mode interface
(instead of the 32-bit interface) then the first thing that seems
worth checking is my implementation of function 0x02, which I think it
could well be returning the wrong code and data segment addresses.
Here's the code:
;-----------------
; APM 16 bit protected mode interface connect
APMSYM(02):
cmp al, #0x02
jne APMSYM(03)
mov ax, #0xffff // 16 bit code segment base
mov bx, #_apm16_entry
mov cx, #0xf000 // data segment address
// 16 bit code segment size
mov si, #0xfff0
mov di, #0xfff0 // data segment length
jmp APMSYM(ok)
;-----------------
; APM 32 bit protected mode interface connect
APMSYM(03):
cmp al, #0x03
jne APMSYM(04)
mov ax, #0xf000 // 32 bit code segment base
mov ebx, #_apm32_entry
mov cx, #0xf000 // 16 bit code segment base
// 32 bit code segment size (low 16 bits)
// 16 bit code segment size (high 16 bits)
mov esi, #0xfff0fff0
mov dx, #0xf000 // data segment address
mov di, #0xfff0 // data segment length
jmp APMSYM(ok)
Can anyone advise?
Struan
Struan Bartlett wrote:
Paul Brook wrote:
In theory windows should be able to "turn off" qemu using APM, like
it does on real machines. However there seem to be bugs in the qemu
implementation that stop this working.
I thought I'd have a little look into why Windows 2000 doesn't turn
off qemu using APM properly. I enabled DEBUG_BIOS in hw/pc.c then
downloaded the latest Debian source for the Bochs bios v1.121 and
defined DEBUG_ROMBIOS and DEBUG_APM both to be 1. I recompiled and
installed the bios and ran qemu to load up Windows 2000. What we get
seems interesting. By the time Qemu boots Windows 2000 to its first
progress-bar, it has printed the following debug statements (with my
explanation added in square brackets):
APM: EAX=00005300 [53 is the int 15h identifier for APM checked for
in rombios.c. 00 is the APM installation check function]
APM: EAX=00005301 [01 is the APM real mode interface connect]
APM: EAX=0000530e [0e appears to request APM driver version]
APM: EAX=00005300 [00, again, is the APM installation check - why is
this called twice?]
APM: EAX=00005304 [04 is APM interface disconnect]
Then, while Windows 2000 boots and until shutdown is complete, I get
no more debug statements. My question is, why not? I'm no APM expert
but, judging from the 'apmbios.S' comments I might expect to see APM:
EAX=00005303 [03 is APM 32 bit protected mode interface connect]. I
could speculate that the return code from APM function 0e does not
satisfy Windows 2000 for some reason, so it does another installation
check and then disconnects the APM interface entirely - hence no APM
functionality in Windows 2000.
If I get more time I may research the APM functions more fully. In
the meantime, if anyone can suggest any alternative theories or how
to test them, I'd be curious.
Struan
_______________________________________________
Qemu-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/qemu-devel
_______________________________________________
Qemu-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/qemu-devel