Commit 830bc852 authored by Jeffrey Lee's avatar Jeffrey Lee Committed by ROOL
Browse files

OS_Byte 19 fixes

* Don't wait for VSync if we're in IRQ context, since (a) IRQ handlers
shouldn't take lots of time, and (b) it may hang the system. Fixes
* Extend the DPMSUtils-inherited "don't wait for VSync if HSync output
is off" fix to also deal with the case where VSync output is off, since
it's reasonable to assume that turning off VSync output could also
prevent the CPU from receiving the associated interrupts.
parent 0830af41
......@@ -529,6 +529,16 @@ Osbyte12 ROUT
Osbyte13 ROUT
; Bail immediately if we're in an IRQ handler.
; (it's bad form for IRQ handlers to take too much time, and
; depending on various factors, it may be impossible for us to
; receive VSync IRQs from within a handler)
LDR R3, =ZeroPage+IRQsema
LDR R3, [R3]
CMP R3, #0
MyOsbyte NE
MRS R3, CPSR ; Interrupts disabled at the moment
LDRB R2, CFStime
......@@ -540,6 +550,9 @@ Osbyte13 ROUT
; When the screen is DPMS-blanked this osbyte will now return
; immediately. This is equivalent to the operation of the DPMSUtils
; module shipped with OS 3.50.
; For RISC OS 5, we've now extended it to also skip the wait if DPMS
; has turned off VSyncs, since it's plausible that hardware/drivers
; won't generate VSync interrupts in that state either.
......@@ -547,7 +560,7 @@ Osbyte13 ROUT
LDRB R1, [LR,#ScreenBlankDPMSState]
TEQ R0, #0 ; NE => blanked
TSTNE R1, #1 ; NE => blanked and DPMS turned off HSyncs
TSTNE R1, #3 ; NE => blanked and DPMS turned off HSync or VSync
MyOsbyte NE ; if true exit immediately
; Also, exit now if we don't have a driver active
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment