Help Creating a Graphics Lib View

[bodhi]

Hi,
I've successfully used the Intuition lib for graphics, opening screens, windows, menus and general GUI stuff - which has been pretty easy going. But I'm now trying to move to "lower-levels" of the Amiga's OS, so I'm moving away from Intuition and playing with the Graphics lib.

I'm starting with the basics and just trying to create a basic custom View complete with its own bitmap and colour table but I'm not having much luck. Everything I'm doing is based directly on the descriptions and C examples from the official RKM manuals, I haven't been able to find any ASM example code for this stuff

Here is the sub-routine I'm jumping to in my code:

CreateDisplay
	; initialize the View struct
	lea myView,a1
	CALLSYS InitView,_GfxBase
	; initialize the BitMap struct
	lea myBitMap,a0
	move.b #1,d0 ;bit depth
	move.w #320,d1 ;width
	move.w #256,d2 ;height	
	CALLSYS InitBitMap,_GfxBase
	; allocate space for raw bitplane/s used by the BitMap struct
	move.w #320,d0
	move.w #256,d1
	CALLSYS AllocRaster,_GfxBase
	lea myBitMap,a0
	move.l d0,bm_Planes(a0) ; store address of the new bitplane
	; initialize the correspending RasInfo of the BitMap
	lea myRasInfo,a0
	move.l #myBitMap,rp_BitMap(a0)
	move.w #0,ri_RxOffset(a0)
	move.w #0,ri_RyOffset(a0)
	move.l #0,ri_Next(a0) ; 0 = no dual PF
	; initialize the ViewPort struct
	lea myViewPort,a0
	CALLSYS InitVPort,_GfxBase
	move.l #myRasInfo,vp_RasInfo(a0) ; associate a RasInfo struct with VP
	move.w #320,vp_DWidth(a0)
	move.w #256,vp_DHeight(a0)
	; link ViewPort to View
	lea myView,a0 
	move.l #myViewPort,v_ViewPort(a0)
	; create and initialize a ColorMap struct for ViewPort
	move.l #2,d0 ; number of entries in this ColorMap
	CALLSYS GetColorMap,_GfxBase
	lea myViewPort,a0
	move.l d0,vp_ColorMap(a0) ; attach to a ViewPort
	;set a colour in ColoMap
	lea myViewPort,a0
	move.l #0,d0
	move.l #8,d1 ;RGB...
	move.l #0,d2
	move.l #0,d3
	CALLSYS SetRGB4,_GfxBase
	; create intermediate Copper instructions (puts pointer in viewport.DspIns)
	lea myView,a0
	lea myViewPort,a1
	CALLSYS MakeVPort,_GfxBase
	; merge all the intermediate Copper instructions. View then contains complete Copper list
	lea myView,a1
	CALLSYS MrgCop,_GfxBase
	; Display the View
	lea myView,a1
	CALLSYS LoadView,_GfxBase
	rts
myView ds.b v_SIZEOF
	cnop 0,2
myViewPort ds.b vp_SIZEOF
	cnop 0,2
myBitMap ds.b bm_SIZEOF
	cnop 0,2
myRasInfo ds.b ri_SIZEOF
	cnop 0,2
myColorMap_p ds.l 1
	cnop 0,2

After calling LoadView in the code above, I'm expecting the Workbench screen/copperlist to be replaced with the copperlist defined by myView (and the ViewPort, ColorMap, etc associated with it). But nothing happens and the Workbench screen stays up.

I knoiw this is really rough/bad code. I'm not attempting to check for errors, or even save the current AmigaOS view....I just want a sign that my view is installing (which it isn't) before I clean it up.

At this stage, I just can't think what I'm doing wrong. If anyone has any advice I'd really appreciate it! Bare in mind, I'm a complete noob at both assembly and AmigaOS coding, so forgive me if I'm making obvious mistakes.

ALSO: note I'm trying to create a 1.3 View, with none of the fancy 2.0+ extensions, etc.

[bodhi]

hm, well, I'm using Picasso emulation (WinUAE) and it seems I need to add these mysterious lines just before I my LoadView to knock out the RTG and return to native:

        sub.l	a1,a1
	CALLSYS LoadView,_GfxBase    
	CALLSYS	WaitTOF,_GfxBase  ;  gfx-card hack
	CALLSYS	WaitTOF,_GfxBase

With this added, the screen at least turns grey now. Also GfxBase->ActiView does hold the address of myView but seen as I set index 0 of my ColorMap to red and BltClear the plane, grey isn't the colour I was expecting. So I'm not convinced.

[mark_k]

LoadView(0) is the "official" way to reset the display, typically used before killing/suspending the system. So it switching to a grey screen is normal. I guess the WinUAE Picasso96 driver detects that and switches to the native display.

Have you tried running your program without RTG emulation, maybe just boot it alone under Kickstart 1.3?

[bodhi]

Yep, I have a number of WinUAE configs (with/without fastram, RTG, 1.3/2.0+, AGA/OCS, etc) and a real A1260. I've tried the exe on all configs and get the same result. Which to me suggests that I'm doing something very wrong with my code - it's just not clear from the documentation I've read so far.

One thing I've noticed is that if I run my exe with RunLame, for a brief moment the Red coloured screen I defined and expect to see flashes on the screen just before the program exits. So executing the code via RunLame fixes my lame code...somehow

I'll keep at it...

[davideo]

@bodhi

If you are getting a flash of Red before going back to the Grey is it because you need to put a delay() within your code to see the result of the subroutine before your program returns to the OS?

Dave G

[bodhi]

dave, it's not shown in the code above but I do have a dos Delay of 3 seconds in my "Main" section, just after jsr CreateDisplay

[bodhi]

having said that, apart from the delay() in Main and the opening/closing of libs, there is not any other code. So I'm now wondering if there is more to creating and installing a custom View than the RKMs mention in the Graphics lib documentation?

I mean, I'm assuming stuff like screen DMA does not need to be touched for a simple swap of Views? Also, I'm not disabling multitasking or anything using forbid()/disable(). The RKM documentation for creating a View doesn't mention such things and I haven't looked into these commands in any detail, but maybe they're needed before I can activate my own screen?

[davideo]

@bodhi

In C you need to do -

MakeScreen(myscreen);
RethinkDisplay();

When creating a double buffered display otherwise the incorrect BitMaps are used. Do you need to do something like that in your code?

Dave G

[bodhi]

from reading the docs, MakeScreen & RethinkDisplay basically Intuition's version of what I'm already doing with the Graphics.lib in my code above (calling MakeVPort, MrgCop, LoadView, etc).

But I gave RethinkDisplay a go at the end of my code, just to see. It didn't help. I'm stumped atm - but I won't give in! I'll report back when/if I find a solution to this.

[Toni Wilen]

lea myViewPort,a0
CALLSYS InitVPort,_GfxBase
move.l #myRasInfo,vp_RasInfo(a0) ; associate a RasInfo struct with VP

Do you see the problem?

btw, I'd take over the system and use hardware directly or use intuition Screens. Low level graphics routines are not that useful, slower than direct code and probably not RTG compatible.

[bodhi]

OMG, thank you so much Toni !

I was aware of this simple rule, but I somehow overlooked it completely! Thank you again, I appreciate your eagle eye.

	move.l #myViewPort,a0
	PRINTF a0,#FORMAT_HEX ; output #1 
	CALLSYS InitVPort,_GfxBase
	PRINTF a0,#FORMAT_HEX ; output #2

output #1: $104c50bc 
output #2: $104c50e4

For anyone else interested, the problem was: System Functions Do Not Preserve D0, D1, A0 and A1.
SO, *DO NOT ASSUME THE VALUES OF THESE REGISTERS ON RETURN FROM A SYSTEM CALL! *

With the fix, my code now works as it should.

And you are right (of course), creating a view this way is pointless. But I saw the RKM's description of how to create a View this way and just wanted to try it at least once. I will probably never use this method and simply use Intuition Screens or (like you say) just take over the system.

Thank you, thank you thank you!

[redblade]

As you can tell from my programming technique. It's copy and paste style.

I don't know if this code works on something other than 15khz tho.