🚀 go-pugleaf

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