Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!spool.mu.edu!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!liuida!isy!lysator.liu.se!zap
From: zap@lysator.liu.se (Zap Andersson)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Copper mystery
Message-ID: <545@lysator.liu.se>
Date: 29 Mar 91 09:21:44 GMT
Article-I.D.: lysator.545
References: <1991Mar27.211732.2436@kth.se> <2112@pdxgate.UUCP>
Sender: news@isy.liu.se (Lord of the News)
Organization: Lysator Computer Club, Linkoping University, Sweden
Lines: 52

bairds@eecs.cs.pdx.edu (Shawn L. Baird) writes:

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

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

UGLIEST I've SEEN TODAY! BLEACH!

>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.

There is no restricion in calling OS stuff while in a Forbid(), since the OS
is smarther than that: Forbid() only turns off multitasking while YOUR process wants the processor! I.e. you may forbid all you like, but when you do any kind
of waiting-function, such as WaitTOF(), WaitPort() or similiar (I use a lot of WaitTOF()  in my hacks) the OS is running. But YOUR process should NEVER notice this, since it has MAXIMUM priority. Yes, that is really what forbid does,
crank up your process's priority to infinity. But, as all good multitaskers,
nomatter how high priority, you don't get the processor while waiting for
something.


>>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.
-- 
* * * * * * * * * * * * * * * * *          (This rent for space)
* My signature is smaller than  * Be warned! The letter 'Z' is Copyright 1991
* yours!  - zap@lysator.liu.se  * by Zap Inc. So are the colors Red, Green and
* * * * * * * * * * * * * * * * * Greenish-yellow (Blue was taken by IBM) 
--
* * * * * * * * * * * * * * * * *          (This rent for space)
* My signature is smaller than  * Be warned! The letter 'Z' is Copyright 1991
* yours!  - zap@lysator.liu.se  * by Zap Inc. So are the colors Red, Green and
* * * * * * * * * * * * * * * * * Greenish-yellow (Blue was taken by IBM)