🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.amiga.tech
Article #8496

Re: Fixing flicker, & future frame rate issues

#8496
From: Bryan Bayerdorffer
Date: Thu, 14 Apr 1988 21:09
36 lines
3012 bytes
In article <8691@agate.BERKELEY.EDU> doug@eris.UUCP (Doug Merritt) writes:
=-In article <11226@ut-sally.UUCP> bryan@mothra.cs.utexas.edu writes:
=-> [...] and recall that all of memory is ALSO a display
=->device, just with a limited part visible at anytime, and the coordinates of
=->that 'ViewPort' (now where did he get that word?) given by a pair of base 
=->registers.  That means no DMA at all, ONLY writing to memory.  Like it even
=->better now?
=-
=-This is the final point that I still don't see. If all of memory is the
=-display device, does that mean that you're not using normal RAM? I simply
=-cannot visualize how this is supposed to work. Even if the display
=-device *is* your main memory, what does that *mean* ? Does it contain
=-RAM that it moves to Pixels or Smudges? ("Smudges" == nonpixels, of course.
=-Or would "Trixels" -- Triangular Picture Elements be better? :-)
=-
=-You said you "didn't want to get this specific", but without more
=-specifics I have difficulty seeing what you have in mind. So far it
=-*sounds* like a mutually exclusive set of specifications. Can you clarify?
=-Ideally what I'm after here is an architectural description; the display
=-could be Alien Crayons, but how is it functionally linked to memory??
=-
	Yes, I can see where confusion might arise.  I've been treating
these as two separate lines of discussion.  They are indeed mutually
exclusive specifications:  The 'non-frame' system has nothing to do with
the 'non-pixel' system.  Now, is there still a problem when, as you said,
you think of the display device as BEING your one and only memory?  Or with
the OTHER system, in which there is NO memory map of the display (which
would imply pixels) in the usual sense?
 ______________________________________________________________________________
/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/
|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|
_No dark sarcasm in the classroom|_____|_____|_____|_____|_____|_____|_____|___
|____Teachers leave the kids alone__|_____|_____|bryan@mothra.cs.utexas.edu___|
___|_____|_____|_____|___{ihnp4,seismo,...}!ut-sally!mothra.cs.utexas.edu!bryan
|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|
Technical Details
Message-ID: <11254@ut-sally.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!mnetor!uunet!husc6!im4u!ut-sally!gamera!bryan
References: <11157@ut-sally.UUCP> <8528@agate.BERKELEY.EDU> <11182@ut-sally.UUCP> <8557@agate.BERKELEY.EDU> <11196@ut-sally.UUCP> <8577@agate.BERKELEY.EDU> <11204@ut-sally.UUCP> <8651@agate.BERKELEY.EDU> <11226@ut-sally.UUCP> <8691@agate.BERKELEY.EDU>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!mnetor!uunet!husc6!im4u!ut-sally!gamera!bryan
From: bryan@gamera.cs.utexas.edu (Bryan Bayerdorffer)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Fixing flicker, & future frame rate issues
Message-ID: <11254@ut-sally.UUCP>
Date: 14 Apr 88 21:09:39 GMT
References: <11157@ut-sally.UUCP> <8528@agate.BERKELEY.EDU> <11182@ut-sally.UUCP> <8557@agate.BERKELEY.EDU> <11196@ut-sally.UUCP> <8577@agate.BERKELEY.EDU> <11204@ut-sally.UUCP> <8651@agate.BERKELEY.EDU> <11226@ut-sally.UUCP> <8691@agate.BERKELEY.EDU>
Sender: news@ut-sally.UUCP
Reply-To: bryan@gamera.cs.utexas.edu
Organization: Spam Detection & Removal Squad, Austin, TX
Lines: 35
Spam-Content: Negligible