English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 04 August 2008, 18:21   #1
Leffmann
 
Join Date: Jul 2008
Location: Sweden
Posts: 2,177
Problems when handing the hardware back to AmigaOS

I'm trying to give the hardware back to AmigaOS in a system friendly manner but run into some problems. The Intuition and Graphics libraries have always been a bit of a gray area to me, and while using the graphics library base address to find the system copper list works fine, it has always seemed like a non intended method to me and so I've been trying to do it in another way.

The code below works almost every time, I don't even have to restore the DMA settings because I've noticed this will be done through RemakeDisplay, but then there's this 1 time out of 100 where this code simply pops out to AmigaOS without rebuilding the view and related copper list and so I just get a blank screen. Anyone have a clue to why it does this?



Code:
dmacon  = $96
dmaconr = $2
intena  = $9a
intenar = $1c

OpenLibrary   = -552
CloseLibrary  = -414
LoadView      = -222
WaitTOF       = -270
RemakeDisplay = -384


    move.l   4.w, a6
    lea      graphicslib, a1
    moveq    #33, d0
    jsr      OpenLibrary(a6)
    move.l   d0, a6
    move.l   d0, -(sp)
    sub.l    a1, a1
    jsr      LoadView(a6)
    jsr      WaitTOF(a6)

    lea      $dff000, a6
    move.w   dmaconr(a6), d0
    move.w   intenar(a6), d1
    move.w   #$7ff, dmacon(a6)
    move.w   #$7fff, intena(a6)
    movem.w  d0-d1, -(sp)

    move.l   #copperlist, cop1lch(a6)
    move.w   d0, copjmp1(a6)
    move.w   #%1000001010000000, dmacon(a6)

wait
    btst     #6, $bfe001
    bne.s    wait

    move.w   #$7ff, dmacon(a6)
    move.w   #$7fff, intena(a6)
    movem.w  (sp)+, d0-d1
    or.w     #$8040, d0
    or.w     #$c000, d1
    move.w   d0, dmacon(a6)
    move.w   d1, intena(a6)

    move.l   4.w, a6
    lea      intuitionlib, a1
    moveq    #33, d0
    jsr      OpenLibrary(a6)
    move.l   d0, a6
    jsr      RemakeDisplay(a6)

    move.l   a6, a1
    move.l   4.w, a6
    jsr      CloseLibrary(a6)
    move.l   (sp)+, a1
    jsr      CloseLibrary(a6)

    moveq    #0, d0
    rts


intuitionlib
    dc.b     "intuition.library", 0

graphicslib
    dc.b     "graphics.library", 0


    section  dat, data_c

copperlist
    dc.l     $8001ff00, $01800800
    dc.l     $9001ff00, $01800080
    dc.l     $a001ff00, $01800008
    dc.l     $b001ff00, $01800000
    dc.l     -2
Leffmann is offline  
Old 05 August 2008, 18:31   #2
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,581
Had a quick look and saw an obvious one, replace the $7ff with $7fff. Promax has a good NonSystemStartup.S on the AsmOne disk, but basically you

0) save system copper (is good even if you only use cop1)
1) wait for last scanline ($138 on PAL, less on NTSC)
2) save intena and dmacon
3) turn off all int requests, ints, and dma
4) set your copper
4) run your code
5) wait for last scanline
6) turn off intreq, intena, dmacon
7) restore saved copper, intena, dmacon and RTS.

(ofc you have to restore all registers except d0 and set d0 to 0 too)

I don't really see why the rebuild is necessary, unless you use the workbench screen temporarily, or is this for something above kick 3.1?

But that $7ff thing should make it better I think
Photon is offline  
Old 05 August 2008, 20:47   #3
Leffmann
 
Join Date: Jul 2008
Location: Sweden
Posts: 2,177
Hi, thanks for your answer!

The method you're describing is the same I've always used previously, but I've been trying to find a more OS friendly way. The #$7ff is intentional, bits 11-14 consist of two unused and two read-only bits and so they can be ignored.

I'm using RemakeDisplay because this call will, as far as the RKM Libraries Manual tells me, reconstruct and install the master copper list for the entire display, based on the current visible screens. I reasoned this was more OS friendly than grabbing addresses from inside the graphics library, thinking the previous view structure might not be valid since it was no longer in use after my call to LoadView.

If anyone has been experimenting with these things, setting various view modes with or without graphics boards etc. to ensure best compatibility I'd be interested in hearing about it.
Leffmann is offline  
Old 05 August 2008, 21:46   #4
ganralf
Registered User
 
Join Date: May 2006
Location: Germany
Posts: 97
I thought the agreed on method is to save the current View from Gfxbase, call LoadView(0) and afterwards restore the View with another call to LoadView():
Code:
  movea.l GfxBase,a6
  move.l  gb_ActiView(a6),oldView
  suba.l  a1,a1
  jsr     LoadView(a6)
  jsr     WaitTOF(a6)
  jsr     WaitTOF(a6)
.
.
.
donedoingstuff:
  movea.l GfxBase,a6
  movea.l oldView,a1
  jsr     LoadView(a6)
  jsr     WaitTOF(a6)
  jsr     WaitTOF(a6)
.
.
.
  rts

oldView:
  dc.l 0
For some reason I forgot it is import to call WaitTOF() two times after LoadView().

Is that something you already tried?
ganralf is offline  
Old 05 August 2008, 22:42   #5
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,581
Well, I told you my standard startup/exit, which is for games and demos. You have some other application? Just thought it was strange to do it this way, make sure it's compatible!
Photon is offline  
Old 06 August 2008, 12:15   #6
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,104
The way I do it is like this:

- save old view
- flush current view to 0
- save both copperlists
- rest of startup (setting DMA/IRQ etc.)

intro/demo code here

- restore both copperlists
- restore old view


This approach works fine for me and I never had problems with it. I don't see how reading the ptrs to the copperlists from gfx library is not systemfriendly.

I'll attach my ministartup, maybe it helps.
Attached Files
File Type: txt ministartup.txt (5.4 KB, 148 views)
StingRay is offline  
Old 06 August 2008, 12:17   #7
Leffmann
 
Join Date: Jul 2008
Location: Sweden
Posts: 2,177
Ganralf:

Thanks I'll try this as well, though I think calling RemakeDisplay will effectively do the same thing as it rebuilds the entire view structure. Maybe the fault is inside RemakeDisplay and this might work better.

Photon:

Compatibility is my #1 priority, that's why I'm leaning towards so many OS calls
Leffmann is offline  
Old 06 August 2008, 12:24   #8
Leffmann
 
Join Date: Jul 2008
Location: Sweden
Posts: 2,177
Quote:
Originally Posted by StingRay View Post
This approach works fine for me and I never had problems with it. I don't see how reading the ptrs to the copperlists from gfx library is not systemfriendly.
You're right, that has always worked fine for me as well and there's nothing that says it's not system friendly. I guess my real question here is why the call to RemakeDisplay does a complete restore 99 out of 100 times, and then fails once.

I wish the AmigaOS docs were a bit more thorough on how to take and retrieve the hardware in the most compatible way.

Thanks a lot for your code, I'll take a look at it
Leffmann is offline  
Old 06 August 2008, 15:31   #9
Leffmann
 
Join Date: Jul 2008
Location: Sweden
Posts: 2,177
I found the weird bug which causes the display not to be restored. If you hold down the right mouse button while exiting and calling LoadView, it somehow fails to set all display registers properly. You end up with an untouched DMACON and other registers are initialized for a lowres NTSC display. Really weird

EDIT: I tried with both one and two calls to WaitTOF after LoadView (not that I can see what good two calls would do) and it has no effect. Not even the AmigaOS is aware of system friendliness
Leffmann is offline  
Old 06 August 2008, 17:07   #10
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,104
Quote:
Originally Posted by Leffmann View Post

EDIT: I tried with both one and two calls to WaitTOF after LoadView (not that I can see what good two calls would do) and it has no effect. Not even the AmigaOS is aware of system friendliness
The 2nd WaitTOF() call is just there for interlaced displays.
StingRay is offline  
Old 06 August 2008, 17:38   #11
Leffmann
 
Join Date: Jul 2008
Location: Sweden
Posts: 2,177
Ah you're right, didn't think of that they were using two copper lists, which makes sense now.

I went back to using my old startup routine instead of fiddling with this. Thanks for all input!
Leffmann is offline  
Old 08 August 2008, 13:02   #12
TheDarkCoder
Registered User
 
Join Date: Dec 2007
Location: Dark Kingdom
Posts: 211
Hi Leffmann,

years ago I tried to do what I think you are trying now: a startup/restore which does not use hardware registers. But in the end using the Intuition functions to do the restore was not 100% working, so I ended up to the old method of "manually" reloading COPxLC and COPJMP1. This method works on any Amiga OS up to AGA with 3.9. Since there will be no more Amiga ( I don't care about OS4 and powerPC) compatibility is 100% :-D
TheDarkCoder is offline  
Old 08 August 2008, 13:08   #13
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,104
Quote:
Originally Posted by TheDarkCoder View Post
years ago I tried to do what I think you are trying now: a startup/restore which does not use hardware registers.
Hi TDC

I think the idea to have a startup/restore that doesn't use hw registers doesn't really make sense, after all in the demo you're going to use them anyway. So why bother?
StingRay is offline  
Old 10 August 2008, 11:48   #14
TheDarkCoder
Registered User
 
Join Date: Dec 2007
Location: Dark Kingdom
Posts: 211
Quote:
Originally Posted by StingRay View Post
Hi TDC

I think the idea to have a startup/restore that doesn't use hw registers doesn't really make sense, after all in the demo you're going to use them anyway. So why bother?
indeed

it was just an exercise, the idea being that ideally an OS should provide a safe way to lock/unlock a resource (in this case hardware registers).
Theoretically, one could imagine that if the system is using a (possibly new) RTG display, then the method of direct poking COPxLC may not work.
But in practise it seems to work (I think, I never used a real gfx card on my chipset-only system!), and since the Amiga platform development is over and it's unlikely that newer RTG systems will be made, in the end I totally agree with you !
TheDarkCoder is offline  
Old 19 November 2008, 14:35   #15
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,581
Quick q: I've always used OldOpenLibrary. Will OpenLibrary work on kick < 2.0?
Photon is offline  
Old 19 November 2008, 15:12   #16
thor
Registered User
thor's Avatar
 
Join Date: Mar 2006
Location: Germany
Posts: 898
At least since Kickstart 1.2. OldOpenLibrary() actually calls OpenLibrary() with 0 in d0.
thor is offline  
Old 22 November 2008, 11:44   #17
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,581
OK, so my code is compatible. And 1 instruction shorter!
Photon is offline  
Old 22 November 2008, 19:05   #18
a4k-oerx
Registered User
 
Join Date: Oct 2008
Location: EU
Posts: 111
Lightbulb Another approach

This old tool, called LoadFix, should work for all "classic" amiga hardware to get ready compiled executable intros/demos/games to work. If the intro/demo/game does not destroy things and can exit, LoadFix will return to AmigaOS.

Syntax: LoadFix filename [with params if any]

Have fun with it, ASM-One source-code below and attached...

Code:
; LoadFix for all Amiga
; ---------------------
; by Thomas Kessler (05.04.1994)
;
; Syntax: LoadFix <filename ...>

_LVOOpenLibrary	= -552
_LVOCloseLibrary = -414
_LVOLoadView	= -222
_LVOWaitTOF	= -270
_LVOExecute	= -222
_LVOSupervisor	= -30
_LVOCopyMem	= -624

ActiView	= $22
copinit		= $26
AttnFlags	= $128

	SECTION	LoadFix,CODE_C	; CHIP MEMORY!
	
fix	move.l	a0,d7		; d7 used below

	moveq	#1,d1		; any params?
	cmp.l	d0,d1
	beq.w	.exit
	clr.b	-1(a0,d0.w)

	move.l	$4.w,a6
	move.b	AttnFlags+1(a6),d1
	and.b	#$f,d1		; 68000?
	beq.b	.vbr_end

	lea	read_vbr(pc),a5
	jsr	_LVOSupervisor(a6)
	move.l	d0,oldVBR
	tst.l	d0
	beq.b	.vbr_end	; already $0.L

	move.l	d0,a0
	sub.l	a1,a1
	move.l	#$400,d0
	jsr	_LVOCopyMem(a6)

	moveq	#0,d0
	lea	write_vbr(pc),a5
	jsr	_LVOSupervisor(a6)
.vbr_end

	lea	gfxname(pc),a1
	moveq	#0,d0
	jsr	_LVOOpenLibrary(a6)
	move.l	d0,gfxbase
	lea	dosname(pc),a1
	moveq	#0,d0
	jsr	_LVOOpenLibrary(a6)
	move.l	d0,dosbase

	move.l	gfxbase(pc),a6
	move.l	ActiView(a6),oldview
	sub.l	a1,a1
	jsr	_LVOLoadView(a6)
	jsr	_LVOWaitTOF(a6)	
	jsr	_LVOWaitTOF(a6)	

	lea	newcop(pc),a2
	bsr.w	GetChipset
	tst.l	d0
	beq.b	.noECS
	cmp.b	#2,d0
	bne.b	.noAGA
	lea	agacop(pc),a2
.noAGA
	; If ECS+, we can force PAL or NTSC:
	move.w	#$20,$dff1dc	; PAL
	;move.w	#$00,$dff1dc	; NTSC

.noECS	move.l	a2,$dff080
	
	move.l	dosbase(pc),a6
	move.l	d7,d1		; d7 from above
	moveq	#0,d2
	moveq	#0,d3
	jsr	_LVOExecute(a6)

	move.l	gfxbase(pc),a6
	jsr	_LVOWaitTOF(a6)	
	jsr	_LVOWaitTOF(a6)	
	move.l	oldview(pc),a1
	jsr	_LVOLoadView(a6)
	move.l	copinit(a6),$dff080

	move.l	$4.w,a6
	move.l	dosbase(pc),a1
	jsr	_LVOCloseLibrary(a6)
	move.l	gfxbase(pc),a1
	jsr	_LVOCloseLibrary(a6)

	move.l	oldVBR(pc),d0
	beq.b	.no_copy

	sub.l	a0,a0
	move.l	d0,a1
	move.l	#$400,d0
	jsr	_LVOCopyMem(a6)

	move.l	oldVBR(pc),d0
	lea	write_vbr(pc),a5
	jsr	_LVOSupervisor(a6)
.no_copy
.exit	moveq	#0,d0
	rts

read_vbr
	movec	vbr,d0		;dc.l	$4E7A0801
	rte
write_vbr
	movec	d0,vbr		;dc.l	$4E7B0801
	rte

GetChipset
	; d0 = 0 old Chipset
	;      1 ECS
	;      2 AGA
	;     -1 other (AAA?)
	btst	#13,$dff004
	beq.b	.noECS
	move.w	$dff07c,d0
	cmp.b	#$f8,d0
	beq.b	.AGA
	cmp.b	#$fc,d0
	beq.b	.ECS
.xxx	moveq	#-1,d0
	rts
.noECS	moveq	#0,d0
	rts
.AGA	moveq	#2,d0
	rts
.ECS	moveq	#1,d0
	rts

gfxname	dc.b	"graphics.library",0
dosname	dc.b	"dos.library",0
	dc.b	"$VER: LoadFix 1.0 von Thomas Kessler (05.04.94)",0
	cnop	0,2

gfxbase	dc.l	0
dosbase	dc.l	0
oldview	dc.l	0
oldVBR	dc.l	0

agacop	dc.w	$0106,$0c00
	dc.w	$01fc,$0000
newcop	dc.w	$0180,$0000
	dc.w	$0100,$0000
	dc.w	$0108,$0000,$010a,$0000
	dc.l	-2
Attached Files
File Type: 7z LoadFix.7z (1.4 KB, 95 views)
a4k-oerx is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
A1200 Hardware Problems Riempie support.Hardware 8 01 April 2010 22:09
ADF back to Amiga disk Problems RokChild Amiga scene 4 31 May 2009 21:00
AmigaOS 3.9 problems... th4t1guy support.Apps 4 26 March 2003 12:57
For you with hardware problems KombatSanta support.Hardware 9 06 August 2002 11:00
Hardware problems with Ebay? Zeewolf MarketPlace 7 20 June 2002 21:28

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 22:49.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.71725 seconds with 16 queries