Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!uunet!overload!dillon From: dillon@overload.Berkeley.CA.US (Matthew Dillon) Newsgroups: comp.sys.amiga.programmer Subject: Re: Copper mystery Message-ID: Date: 30 Mar 91 19:38:09 GMT References: <1991Mar27.211732.2436@kth.se> <2112@pdxgate.UUCP> <545@lysator.liu.se> Organization: Not an Organization Lines: 58 In article <545@lysator.liu.se> zap@lysator.liu.se (Zap Andersson) writes: >bairds@eecs.cs.pdx.edu (Shawn L. Baird) writes: >>d85-jmh@nada.kth.se (Jan-Olof Hendig) writes: >> >>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 >> >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. > >>>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) Essentially, you are correct, Forbid() is a wonderful way to take over the machine... but you also want to increase your task priority (or decrease other task's priorities) so that when the operation you run is complete, EXEC will *immediately* give you the CPU back. I.E. you make a DOS call: Read(....), say, when that Read is done and DOS replies the packet, you want your task to IMMEDIATELY continue running and not allow other tasks (such as the input.device) to necessarily get CPU. Actually, as per my previous message, all that is really necessary is that you make your task the highest priority, period. I am happy to see that others have caught on to this excellent method. It doesn't break the machine It doesn't break the OS nor memory nor resources (you just obtain them normally) nor devices and handlers (i.e. the hard disk still works) the user doesn't have to reboot the game can be installed on an HD It doesn't require taking the machine completely over You get all the CPU when you need it ... and the machine goes back to normal when you quit -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA