Path: utzoo!utgpu!attcan!uunet!husc6!mailrus!uwmcsd1!lakesys!jason
From: jason@lakesys.UUCP (Jason)
Newsgroups: comp.sys.atari.st
Subject: Re: Questions about ST Video Ram
Summary: The video address has to be on a page boundary
Message-ID: <930@lakesys.UUCP>
Date: 3 Aug 88 12:58:47 GMT
References: <535@skywest.UUCP>
Organization: Lake Systems, Milwaukee Wisconsin
Lines: 35

In article <535@skywest.UUCP>, brenes@skywest.UUCP (Erasmo Brenes) writes:
> is written using MWC 2.x). What I've noticed is that the video buffer that
> the ST starts with is located in a 32K boundary, 0xf8000, while the starting
> location of NextScreen[] is not. It also seems that if a take &NextScreen[0]
> mod 32K, the remainder is the offset that I see on the screen. So, the
> question is: If the Shifter expects the video ram to start at 32K boundaries,
> then how do I get MWC, or any C program to allocate a 32Kb buffer starting in
> a 32Kb boundary in an efficient manner?  An initial thought was to use Malloc()
> to allocate 64Kb and then only use the 32Kb which start in a 32Kb boundary,
> but this method is too wasteful. There's got to be a better way, isn't there?
> 

	Like the summary says, the address needs to be evenly divisible by
0x100 (some people claim 0x200, but I've never had problems with 0x100). The
method for this fairly simple:

char	NextScreen[32256],*NSPtr;

somewhere down the line:

	NSPtr = (NextScreen & (~0xff)) + (((NextScreen & 0xff) > 0) * 0x100);

	This code flat won't work, as MWC doesn't allow anding an address
(last time I checked, anyways), so you just cast NextScreen to a long in the
line above (or use a temporary variable, or whatever toggles your fancy).

	The second half of the line takes care of the problem of just using
the &. However, if I remember correctly, the line will be faster than using
a mod - this should probably be checked out via diassembly...

> Erasmo.

-- 

Jason - Not your average iconoclast  |	UUCP: uwvax!uwmcsd1!lakesys!jason