Path: utzoo!attcan!uunet!husc6!cmcl2!rutgers!apple!bionet!agate!saturn!ssyx!koreth
From: koreth@ssyx.ucsc.edu (Steven Grimm)
Newsgroups: comp.os.minix
Subject: Re: Minix ST graphics
Message-ID: <5582@saturn.ucsc.edu>
Date: 24 Nov 88 20:33:57 GMT
References: <595772331.26840@minster.york.ac.uk> <568@mks.UUCP> <273@cstw01.UUCP>
Sender: usenet@saturn.ucsc.edu
Reply-To: koreth@ssyx.ucsc.edu (Steven Grimm)
Organization: The Mad Scientists' Guild
Lines: 19

In article <273@cstw01.UUCP> meulenbr@cstw01.UUCP (Frans Meulenbroeks) writes:
>What if we add a new device /dev/screen or something like that.
>What this device should do:
>upon open malloc a chunk of 32000 bytes on a 256? byte boundary to
>store the screen.
>This area can be written to using the write call (just like for
>/dev/mem).

This is bad because it is nonportable; how about having writes contain
command strings that do various things portably?  Your speed would suffer,
but your programs would work on PCs and STs.  There could be a bitblt
ioctl, and also a library call to normalize a bit-image to the current
screen resolution and so forth (either scaling up or down).  Then you'd
have arcade-style games that worked on both the PC and the ST.

---
These are my opinions, and in no way reflect those of UCSC, which are wrong.
Steven Grimm		Moderator, comp.{sources,binaries}.atari.st
koreth@ssyx.ucsc.edu	uunet!ucbvax!ucscc!ssyx!koreth