Quote:
Originally Posted by Toni Wilen
Yes but uaegfx can be easily modified to also support alternative "hardware API", because it is mostly hardware emulation only, just poke parameters to some reserved memory, write command id to some address, just like real blitter-like hardware works.
|
I think it is not only a uaegfx.card problem!
This memory-area ($00F0.0000 - $00F7.FFFF) could be r/w-protected by os4 (Just like most other memareas).
Accessing any memory outside the os4-mempool is a problem.
I think someone from the os4-developers has to write a certified driver .. or better called config-structure .. that will enable access to the needed memory areas.
With such a granted access the old driver should work out of the box.
Code:
...
...
***********************************************************
SetPanning:
* set view origin for overscan displays
***********************************************************
* a0: struct BoardInfo
* a1: UBYTE *Memory
* d0: UWORD Width
* d1: WORD XOffset
* d2: WORD YOffset
* d7: RGBFTYPE RGBFormat
***********************************************************
move.w d1,(gbi_XOffset,a0)
move.w d2,(gbi_YOffset,a0)
move.l a1,d4
sub.l (gbi_MemoryBase,a0),d4
; UAECALL #22
movem.l d2-d7/a2-a6,-(sp)
movea.l d3,a5
moveq #22,d3 ; #22
movem.l d3,-(sp)
move.l a5,d3
movea.l #$F0FF60,a5
jsr (a5)
movem.l (sp)+,d2
movem.l (sp)+,d2-d7/a2-a6
rts
...
...