Path: utzoo!attcan!uunet!portal!atari!apratt From: apratt@atari.UUCP (Allan Pratt) Newsgroups: comp.sys.atari.st Subject: Re: Questions about ST Video Ram Message-ID: <1142@atari.UUCP> Date: 29 Aug 88 21:24:09 GMT References: <535@skywest.UUCP> <2884@bath63.ux63.bath.ac.uk> <12@usl-pc.usl.edu> <657@uhnix2.uh.edu> Reply-To: apratt@atari.UUCP (Allan Pratt) Organization: Atari (US) Corporation, Sunnyvale, California Lines: 36 In article <657@uhnix2.uh.edu> uace0@uhnix2.UUCP writes: > In article <12@usl-pc.usl.edu> jpdres13@usl-pc.UUCP (John Joubert) writes: > > In article <535@skywest.UUCP> brenes@skywest.UUCP (Erasmo Brenes) writes: > > >... If the Shifter expects the video ram to start at 32K boundaries, > > > > [Code sample for getting a screen block] > > There is really one little problem with the code you have written, that being if > the block you Malloc is just one byte past a 256 byte boundary, then you will > be wasting 255 bytes, therefore you will need to Malloc at least (32K+255) to > insure that you have at least enough memory to draw a full screen in. The continuing misunderstanding here is that people think the screen takes up 32K bytes, and (in Erasmo Brenes' case) that the screen memory must start on a 32K boundary. The screen takes up 32000 bytes, not 32K (which is 32768 bytes), and needs to start on a 256-byte boundary. The upshot of this is that you only need to allocate 32256 bytes to be sure that there is a 32000-byte block on a 256-byte boundary in there somewhere. Since John Joubert's code allocated 32768 bytes, it worked fine. I appreciate this discussion because it shows that people care about doing The Right Thing about allocating memory. The Wrong Thing which some people do is assume that consecutive Malloc calls allocate contiguous memory. This is accidentally and unfortunately true in current ROMs, and part of what I had to keep doing because people came to rely on it, but it is not correct to assume it will go on being that way. Moreover, you have to watch out for future Atari video modes which use more than 32000 bytes for a screen, and/or have different (probably more relaxed) restrictions on the screen-memory base address. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt