Path: utzoo!attcan!uunet!munnari.oz.au!brolga!bunyip.cc.uq.oz.au!oat!qut.edu.au!lunnon From: lunnon@qut.edu.au Newsgroups: comp.sys.atari.st.tech Subject: Re: Fast Raster Routines Needed. Message-ID: <1991Feb2.001154.23303@qut.edu.au> Date: 2 Feb 91 05:11:54 GMT References: <1991Jan23.005852.28904@sbcs.sunysb.edu> <1991Jan31.183155.8948@ataritx.uucp> <7125@uqcspe.cs.uq.oz.au> Organization: Queensland University of Technology Lines: 76 In article <7125@uqcspe.cs.uq.oz.au>, warwick@batserver.cs.uq.oz.au (Warwick Allison) writes: > In <1991Jan31.183155.8948@ataritx.uucp> dwh@ataritx.uucp (Dave Hanna) writes: > >>In article <1991Jan23.005852.28904@sbcs.sunysb.edu> mrose@libserv1.ic.sunysb.edu (Michael Rose) writes: >>> Also, does anyone know how the bit planes are set up in the new >>>TT specific graphics modes? In the 320x480x8 mode, does one byte equal >>>one pixel? > >> NO! The 320x480x8 mode is merely an extension of the X 2 and X 4 >>planar modes: 2 bytes hold plane 1 data for the first 16 pixels, followed >>by 2 bytes for plane 2 for the first 16 pixels... > > Which is just as well ! Who wants 256 colour sprites???? Can you imagine > how SLOW it would be to draw up a sprite if you HAD to set all bitplanes? Arrrgh, Warwick !! The Bitplane arrangement in the ST is lousy for software ops there is no reason to set up more than one plane for some operations whether the planes are interleaved or not. The arrangement in the ST is the result of some very simple DMA hardware which is used to read the video memory. > > One common way for Fast Raster Routines (ie. the subject line), is not to > draw on all bitplanes. That is why we have them that way. See above: The ST way is slow for software no matter how many planes you want to draw on. Only the IBM PC is worse. > > Perhaps Michael has too many fond memories of 8 bit Ataris, when you only > had 2 bits per colour index anyway, so it didn't matter. > > I imagine there is also a hardware concern that places bitplanes as they > are too, if anyone could expound? > -- Ok. Ill have a go ( Did you expect anything less ? ) This is guess work but from an engineering point of view this is probably what happens. The Video memory is arranged in words, the same pixel from one two or four successive words are used to form the index into the clut ( Colour lookup table ). The reason for doing this is pretty obvious, since we have 3 modes it is simpler to read n words and always combine the bits in the same way than to combine successive 1 2 or 4 bits within words differently between modes as on a PC thus in low rez the state machine loads 4 registers with memory values. At each video clock interval each of the location is shifted once (left I think ) and a bit falls of the end of each register which are combined in a 1,2,4,8 type way and used to index the clut. In Med then only two fetches are done to register val one and 2 and 4 and 8 are left cleared (twice as fast of course ) the lower two bits of the 4 bit index then is only significant. In high rez only one register is loaded 4 times as fast (well thats the theory although mono timing is different ) All this makes mode switching little more than a counter and a couple of decoders, pretty trivial really. Note that the DMA machine then is not required to permutate its counting in order to access different memory regions ( Which is all that would really be required to have logically distinct planes ) In fact separate bitplanes probably would be trivial al that would be required is to use ( Programably ) the 2 highest bits b15 and b14 in the dma counter as the LSBs on the bus and just b15 in med (of couse this means shifting all the address lines down by a bit to change modes :-) Of course now somebody at Atari will probably send me a big flame and tell me that things are actually different, but do I care ??? No This fits the model and will do for me :-) BOB R.Lunnon@qut.edu.au > ________________________________________________________ > > This .signature intentionally left blank > ________________________________________________________