View Single Post
Old 13 December 2014, 22:03   #1008
Registered User
Join Date: Sep 2008
Location: Germany
Posts: 315
Originally Posted by Toni Wilen View Post
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.
* 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

Last edited by Ratte; 13 December 2014 at 22:11.
Ratte is offline  
Page generated in 0.04076 seconds with 10 queries