Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!killer!ames!ucsd!rutgers!rochester!pt.cs.cmu.edu!spice.cs.cmu.edu!bader
From: bader@spice.cs.cmu.edu (Miles Bader)
Newsgroups: comp.sys.amiga
Subject: Re: new chips questions
Message-ID: <2838@pt.cs.cmu.edu>
Date: 31 Aug 88 02:40:12 GMT
References: <8X635hd38k-041lzFc@andrew.cmu.edu> <4601@cbmvax.UUCP>
Sender: netnews@pt.cs.cmu.edu
Organization: Carnegie-Mellon University, ITC
Lines: 20

In article <4601@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes:
>The same problem now occurs again in the new Denise, only more so.  We're
>now dealing with 35ns pixels instead of the previous 70ns pixels, since 400
>line non-interlaced must double the horizontal scan rate.  While you might
>think that you could again Mux the 16 registers into 8, the method of
>multiplexing on the inputs to the CLUT would work out too slow for the new
>mode.  So we're really multiplexing the output of the CLUT, not the input. 
>So where there were 12 lines of pixel data emerging from the CLUT, there
>are 6 lines in high speed mode.  And 2^6 is obviously 64. 

My understanding of how interlaced output works must be wrong.  I would
have thought that the horizontal rates would be the same, and it would just
stall every other scan line (so other people could use the bus).  From what
you said, I gather that both modes output continuously, the slower rate of
the interlaced mode letting the beam drift farther vertically (and so
leaving the gap between lines).

Is this right?

-Miles