bader+@andrew.cmu.edu (Miles Bader) (08/28/88)
Is it true that in the new graphic chips, the 400-line non-interlaced output will only be able to use colors from a total palette of 64? If so, is there a good reason? -Miles
papa@pollux.usc.edu (Marco Papa) (08/29/88)
In article <8X635hd38k-041lzFc@andrew.cmu.edu> bader+@andrew.cmu.edu (Miles Bader) writes: |Is it true that in the new graphic chips, the 400-line non-interlaced |output will only be able to use colors from a total palette of 64? |If so, is there a good reason? Yep. The ECS Enhanced Chip Set announced at DevCon in Wash provides a new non-interlace mode: 640 x 400 (640 x 512 PAL), 4 colors from 64. To use the ECS you'll need version 1.4 system software and a Bisynch or Multisynch monitor. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
bader@spice.cs.cmu.edu (Miles Bader) (08/29/88)
In article <11876@oberon.USC.EDU> papa@pollux.usc.edu (Marco Papa) writes: >Yep. The ECS Enhanced Chip Set announced at DevCon in Wash provides a new >non-interlace mode: 640 x 400 (640 x 512 PAL), 4 colors from 64. >To use the ECS you'll need version 1.4 system software and a Bisynch or >Multisynch monitor. But why not 4096? No extra memory bandwidth would be required; the D/A converters, etc, are already being run at the same rate for the existing 640 horiz. modes. I can think of restrictions that might have been required for the new modes, but this certainly isn't one of them... -Miles
wayneck@tekig5.PEN.TEK.COM (Wayne Knapp) (08/29/88)
In article <11876@oberon.USC.EDU>, papa@pollux.usc.edu (Marco Papa) writes: > > Yep. The ECS Enhanced Chip Set announced at DevCon in Wash provides a new > non-interlace mode: 640 x 400 (640 x 512 PAL), 4 colors from 64. > To use the ECS you'll need version 1.4 system software and a Bisynch or > Multisynch monitor. This is the worst news yet! I really hope there has been some error. If this is true it sounds like I could get better graphics by plugging a VGA card in to the B2000. Maybe there are some other very useful new modes? What all will we get with the new chip set. Wayne Knapp
walker@sas.UUCP (Doug Walker) (08/29/88)
In article <8X635hd38k-041lzFc@andrew.cmu.edu> bader+@andrew.cmu.edu (Miles Bader) writes: >Is it true that in the new graphic chips, the 400-line non-interlaced >output will only be able to use colors from a total palette of 64? >If so, is there a good reason? Of course there's no good reason. As everybody who reads this group knows, Commodore screws up decisions like this on purpose just to piss Amiga owners off. No, seriously, the reasons are quite good. The display chips have a set throughput - that is, they can put out just so much information in the small set period of time they are allotted. To put out a 640x400 non-interlaced display, you are in effect doubling the speed the chips must match, which in turn means halving the number of bitplanes. Thus, your 16-color hi-res display turns into a 4-color. As far as I'm concerned, this is a huge win for the simple reason that the workbench is 4-color, and I do all my editing in editors on the workbench screen. Commodore has done a good redesign job to get the new performance without completely starting over.
koster@cory.Berkeley.EDU (David Ashley) (08/30/88)
In article <614@sas.UUCP> walker@sas.UUCP (Doug Walker) writes: >In article <8X635hd38k-041lzFc@andrew.cmu.edu> bader+@andrew.cmu.edu (Miles Bader) writes: >>Is it true that in the new graphic chips, the 400-line non-interlaced >>output will only be able to use colors from a total palette of 64? >>If so, is there a good reason? > >Of course there's no good reason. As everybody who reads this group knows, >Commodore screws up decisions like this on purpose just to piss Amiga owners >off. He goes on to say that because of the higher resolution, we of course have fewer bitplanes. You have missed the point. Fine, there are only two bitplanes in this new higher-resolution mode. The original problem was, WHY ONLY 64 COLORS? That is, does the new mode use only 6 bits of the 12 bits output from the color table? This is insane. I'm sure that the video D to A's are not being driven too fast, such that 4 bits is too high accuracy for that speed. After all, they have MUCH higher video rates that give 8 bits/D to A. So, the question is, will it only be 4 colors out of a palette of 64, or will it be 4 colors out of a palette of 4096? The latter is the obvious answer, and there is no reason for Commodore to have made it the former. But who knows?
daveh@cbmvax.UUCP (Dave Haynie) (08/31/88)
in article <8X635hd38k-041lzFc@andrew.cmu.edu>, bader+@andrew.cmu.edu (Miles Bader) says: > > Is it true that in the new graphic chips, the 400-line non-interlaced > output will only be able to use colors from a total palette of 64? Yes... > If so, is there a good reason? Yup. It has to do basically with the way the CLUT is multiplexed in Denise. While you never probably know this, color registers only run at the 320 dot pixel rate. When you shift into hires, the 32 color registers basically get Muxed into 16 fast color registers. 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. > -Miles -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy "I can't relax, 'cause I'm a Boinger!"
bader@spice.cs.cmu.edu (Miles Bader) (08/31/88)
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
walker@sas.UUCP (Doug Walker) (08/31/88)
In article <5308@pasteur.Berkeley.EDU> koster@cory.Berkeley.EDU.UUCP (David Ashley) writes: >>>output will only be able to use colors from a total palette of 64? > >You have missed the point. Fine, there are only two bitplanes in this new >higher-resolution mode. The original problem was, WHY ONLY 64 COLORS? Touche, I did miss your point. John Toebes came up with a guess as to why. The new mode requires an EGA or MultiSync monitor; perhaps it puts out digital RGB instead of analog, and the 64-color limitation is in the monitor?
king@client2.DRETOR.UUCP (Stephen King) (09/01/88)
In article <2838@pt.cs.cmu.edu> bader@spice.cs.cmu.edu (Miles Bader) writes: >My understanding of how interlaced output works must be wrong. Must be. :-) >I would have thought that the horizontal rates would be the same, To de-interlace normal Amiga video, the horizontal scan rate must double. >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, True. >the slower rate of the interlaced mode letting the beam drift farther >vertically (and so leaving the gap between lines). The beam should never drift - it is always driven. The vertical gap between scan lines is a product of the vertical integrater within the monitor. The width of the gap is a function of both horizontal and vertical scan frequencies. Remember, each field is 262.5 lines. It is the half-line that is responsible for the interlace. > >Is this right? > Sort of. TV signals are notoriously difficult to understand. In fact, until the building of the space shuttle, colour TV was considered the most technologically advanced equipment in existance. TV signal processing is going to get even more sophisticated with HDTV. (high definition TV) I won't be buying another Amiga until it supports HDTV :-) -- Stephen J King ...{utzoo|mnetor}!dciem!dretor!king
daveh@cbmvax.UUCP (Dave Haynie) (09/01/88)
in article <2838@pt.cs.cmu.edu>, bader@spice.cs.cmu.edu (Miles Bader) says: > > 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... > 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). Nope. With a 60Hz refresh rate, and the 15.6-something kHz rate of the NTSC standard horizontal line, you only have enough time to display about 200 lines (or whatever you get with appropropriate overscan). Interlacing is a way to get twice the number of lines by interleaving two separate 60Hz frames, you get twice the resolution, but it takes twice as long to refresh the full frame, so you drop to 30Hz per frame and get flicker. When you go to the new non-interlaced mode, you're displaying at about 31kHz per horizontal line, so obviously, within a 60Hz frame, twice the normal information can be displayed. > 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). You only get gap between lines in standard non-interlaced modes. That's because the display device is designed to allow interlacing, but you're only supplying 1/2 of the possible frame, at twice the rate. There are really two limiting factors here; display rates and memory bandwidth. Simply put, the reason that the new Denise allows only 64 colors in noninterlaced hires is a display rate limitation, the reason that the new Denise/Agnus only allow 2 bitplanes in noninterlaced hires is a memory bandwidth limitation. In the former case, you're switching from 70ns pixels to 35ns pixels. The Denise color registers only run at 140ns, so they must be quadplexed. Normal 640 pixel modes mux the registers before the CLUT; in order to be fast enough, noninterlaced hires must do it's second MUX after the CLUT. So instead of turning 16 registers into 8, it turns 12 color bits into 6. In the latter case, nothing about the Agnus memory bus has changed. In normal 640 line modes is was possible to fetch 2 bitplanes without any CPU contention or 4 bitplanes with heavy CPU contention, at the nominal rate of 200 lines in 1/60th of a second. Now in non-interlaced 640 line hires it's possible to fetch 1 bitplane without any CPU contention or 2 bitplanes with heavy CPU contention, at the nominal rate of 400 lines in 1/60th of a second. Add 'em up, and you see it's exactly the same about of memory transfer in each case, it's just that Denise is doing different visual things with the raw data Agnus provides. > -Miles -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy "I can't relax, 'cause I'm a Boinger!"
bader+@andrew.cmu.edu (Miles Bader) (09/16/88)
> *Excerpts from ext.nn.comp.sys.amiga: 1-Sep-88 Re: new chips questions Dave* > *Haynie@cbmvax.UUCP (3131)* > In the former case, you're switching from 70ns pixels to 35ns pixels. The > Denise color registers only run at 140ns, so they must be quadplexed. > Normal 640 pixel modes mux the registers before the CLUT; in order to be > fast enough, noninterlaced hires must do it's second MUX after the CLUT. > So instead of turning 16 registers into 8, it turns 12 color bits into 6. Maybe you should have made 24 bit registers, & used the post-clut multiplexing for every mode.