Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!ogicse!pdxgate!eecs!bairds
From: bairds@eecs.cs.pdx.edu (Shawn L. Baird)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Copper mystery
Message-ID: <2112@pdxgate.UUCP>
Date: 28 Mar 91 02:48:14 GMT
References: <1991Mar27.211732.2436@kth.se>
Sender: news@pdxgate.UUCP
Lines: 60

d85-jmh@nada.kth.se (Jan-Olof Hendig) writes:

>x:
>	move #4000,$dff09a ; Kill multitasking

I don't have my hardware manuals at hand, but do copper interrupts still
occur with this instruction? Is the INTREQ or DMACON? DMACON, I think,
which will just disable some sort of DMA activity (probably the screen
or something. does the screen data go bye-bye for the duration of this
program?)

>	move.l #cop,$dff084 ; Put address of copperlist in COPADR2!!!

If interrupts are still taking place, it could be something to do with
that. Perhaps the Amiga OS uses COPADDR2 for the user copperlist or one
of the two interlace frames. I wish I had my manuals close by.

>	
>waitm:
>	btst #6,$bfe001 ; wait for user to press left mb
>	bne.s waitm
>	rts	; the end

Right here rts returns to some routine set up by the Amiga OS. This
routine, I would assume, probably does some cleanup, like restoring DMA
and starting multi-tasking. If multi-tasking was stopped by the program
it wouldn't make sense to leave it that way. Alternately, it may just be
chance due to the context switch going to another process (because the
OS is now running after the program ends and now the OS decides to run
another process out of its group that are still there) or some such.

>This rather 'dirty' program raises some questions that the article I took the
>listing from and the old Hardware manual fail to explain. Mind you, my german
>is not as good as it should be.

Personally, when writing a program that takes over the machine (as I have
been practicing recently) I do a few things. First, I save a pointer to the
old copper, which can be found in the GfxBase structure (this works on 2.0
as well, and I've seen some demos where the screen wasn't restored
properly under 2.0). Next, I call Forbid() to disable everything but
interrupts. I then disable all DMA and then restore DMA to the copper,
the blitter, bitplanes and audio, which is usually all I use. I make all of
my OS calls before shutting down with Forbid() by the way. Calls such as
AllocMem, etc. Upon restoration I try to reverse the process, enabling DMA,
putting the saved copper into the register and strobing it and then calling
Permit(). This is my guess as to what a compliant assembly language program
that wants to return the OS when it finishes does. If anyone has any
suggestions as to what else I might want to try to help save, be my guest.
I assume (I haven't tried it yet) that I should be leery of OS calls while
in a Forbid()den state, such as disk I/O, but I'm not sure yet. Any info
would be appreciated.

>No flames please, just constructive answers.

I hope this was at least somewhat constructive and maybe even helpful. ;)

>Jan-Olof Hendig
---
 Shawn L. Baird, bairds@eecs.ee.pdx.edu, Wraith on DikuMUD
 The above message is not licensed by AT&T, or at least, not yet.