home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.sys.amiga.programmer
- Path: comp.vuw.ac.nz!HERMES!maths!peterm
- From: peterm@maths.grace.cri.nz (Peter McGavin)
- Subject: Re: AddIntServer + VERTB strangeness
- Message-ID: <PETERM.96Apr7121414@tui.maths.irl.cri.nz>
- Date: 07 Apr 1996 00:14:14 GMT
- References: <199604021335.NAA17260@mailhost.unibol.com>
- Organization: Industrial Research Ltd
- In-reply-to: John Girvin's message of Tue, 2 Apr 1996 13:35:42 GMT
-
- John Girvin <jgirvin@bfs.unibol.com> writes:
- >On 31 Mar 1996 22:14:37 GMT, peterm@maths.grace.cri.nz (Peter McGavin)wrote:
- >:>Use
- >:>high-level OS calls for everything not exclusively allocated at the
- >:>lowest level.
- >
- >Do you mean something like "use graphics.library calls if you dont
- >OwnBlitter()" ?
-
- Um, I was trying to get across that there is no need to take over the
- -entire- OS for hardware banging. Just allocate the component(s) we
- need for hardware banging and continue using high-level OS calls for
- other things. For example, if we need to bang custom gfx then we can
- still use the OS to access the keyboard or disk or network or
- whatever.
-
- >This could be a little dangerous since you dont know
- >what hardware the high level calls might use. You could end up with
- >registers being not what you expect, interrupts you dont expect, OS
- >lockups waiting for you to free hardware (OK, *stupid* OS programmer
- >required for that bug ;) etc.
-
- High-level OS calls should internally use the same hardware allocation
- mechanisms as our own program, so there should be no conflicts. For
- example, a high-level graphics.library function might call
- OwnBlitter() and WaitBlit() before it bangs the blitter, just as we
- could in our own program.
- --
- Peter McGavin. (p.mcgavin@irl.cri.nz)
-
-