Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!dimacs.rutgers.edu!rutgers!cbmvax!jesup
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.arch
Subject: Re: Dynamic Display Architecture
Message-ID: <20812@cbmvax.commodore.com>
Date: 21 Apr 91 02:56:01 GMT
References: <1991Apr15.200955.3438@waikato.ac.nz> <3340@crdos1.crd.ge.COM> <20670@cbmvax.commodore.com> <1991Apr17.051746.15592@sbcs.sunysb.edu>
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA
Lines: 61

In article <1991Apr17.051746.15592@sbcs.sunysb.edu> jallen@libserv1.ic.sunysb.edu (Joseph Allen) writes:
>I had an idea for a hardware windowing circuit once which was very simple and
>which would eliminate most of the problems windows have today.  All you do is
>break up the screen into small (maybe character sized) blocks.  Then for each
>block you have a pointer to where in memory the actual data is.  It's really as
>simple as normal character refresh memory,  but with no font chip and with
>wider (32-bits instead of 8) refresh memory.

	Sounds a lot like "character graphics" - define a custom font, and
store character numbers for the screen.  If you use 16 bit "characters", and
reasonable sized "characters", you can put up anything arbitrarily.  There
are some signifigant drawbacks to this approach, and a few advantages.

>	When a window overlaps another, pointers are simply not made to the
>hidden parts- and the program in the window doesn't have to know that it has
>been overlapped.

	This is (effectively) a very limited version of a graphics copper.
It loses all the bandwidth advantages from making use of the fact that the
windows are sequential within the window (you are effectively executing a
copper instruction for each "character" on the display).  You could get the
same sort of effects (any many more interesting ones) with a reasonably
functional and fast copper (people have made hires windows in the middle of
lores screens using tricks like this, I'm told).

>	The only real disadvantage is that the window sizes are quantized on
>the block sizes instead of on pixels.  I feel this is a very small price to
>pay compared to having to calculate window overlaps everytime you write to the
>screen or any of the other perversions done in current window technology.

	Small is in the eye of the beholder.  Agreed, overlaps are a pain,
but most of the work is done when windows are created/moved/etc.  It's not
cheap, though.

>>Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
>
>Ah-Ha! So now we see who's responsible for AmigaDOS not being a UNIX port/clone
>as it should have been...  (whoever made ':' mean "start the path in root" for
>AmigaDOS path strings should be shot along with the person who made the shell
>wildcard '#*' (or whatever) and not just '*' along with whoever decided to
>copy the MS-DOS device: convention etc., etc., etc.. :-)

	Don't talk to me, talk to some grad students and profs at Cambridge,
the birthplace of Tripos.  In 2.0, you can make * == #? by flipping a bit.
As for ':', etc, it's different, but different does not mean bad.  Be careful
about getting Unixitis (OS likes/dislikes are almost as religious as editors).
At least it's in C/asm now instead of BCPL.  It even has some things Unix
doesn't nowadays.  AmigaOS 2.0 is a major change - I took over AmigaDos
(dos.library) in ~June 1989.

	It wasn't ever going to be a Unix clone (on a 68000 with 256K memory
in 1985).  The Exec kernel is similar to Xinu, though, to this day.  We do
have Amiga Unix, though (see comp.unix.amiga).

-- 
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com  BIX: rjesup  
Disclaimer: Nothing I say is anything other than my personal opinion.
Thus spake the Master Ninjei: "To program a million-line operating system
is easy, to change a man's temperament is more difficult."
(From "The Zen of Programming")  ;-)