home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!munnari.oz.au!spool.mu.edu!umn.edu!csus.edu!netcom.com!netcomsv!terapin!paulk
- From: paulk@terapin.com (Paul Kienitz)
- Newsgroups: comp.sys.amiga.programmer
- Subject: Re: Going to the metal
- References: <RwqqwB5w165w@lakes.trenton.sc.us>
- Message-ID: <paulk.31yq@terapin.com>
- Date: 2 Jan 93 10:43:04 PST
- Organization: BBS
- Lines: 28
-
- > > Imagine if you will a "spec" that says that address X contains
- > > the X position of the mouse, Y contains the Y position, and Z
- > > contains the state of the buttons. Further, J contains the bits
- > > associated with joysticks 1 and 2 in the upper and lower 4 bits
- > > and at address I is the bits for the display plane 0, I+n plane
- > > 1, etc. Now using this virtual machine is just as easy as using
- > > the actual hardware, except that now, the changes in the O/S are
- > > "invisible" to games that use them.
-
- > I think this is a great idea, and an acceptable one at that.
- > Perhaps a library of sorts, a hardware.library?
-
- This is only applicable to the simpler hardware operations where
- performance isn't an issue in the first place. I doubt you could
- model the blitter and copper in a general way that would be
- applicable to other hardware, without getting a lot closer to an
- abstract model like the real OS uses.
-
- At best it would simplify the job of making other graphics devices
- have an ECS compatibility mode. That might be worth doing but it
- aint a general solution ...
-
- Maybe there could be an aga.library to let people do stuff similar to
- what they do with hardware banging on the old chipset, with the new AGA
- features. Then they could make the next chipset less compatible and
- provide a new aga.library with compatibility glue and tell people "well
- if you hit the registers instead of using aga.library then of course it's
- not going to work."
-