Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!ames!elroy!peregrine!skywest!brenes
From: brenes@skywest.UUCP (Erasmo Brenes)
Newsgroups: comp.sys.atari.st
Subject: Questions about ST Video Ram
Message-ID: <535@skywest.UUCP>
Date: 2 Aug 88 17:44:25 GMT
Reply-To: brenes@skywest.UUCP (Erasmo Brenes)
Organization: Sky Computers, Irvine, CA
Lines: 26

Hello, this is a question to the ST graphic 'gurus':

I've written a program which is capable of generating a full screen (640 x 200)
at a high rate (approx. refresh rate). Thus I have a NextScreen[32k] buffer
which I use as a secondary video buffer. The idea behind it is to ping-pong
between this NextScreen[] buffer and the one that the ST assigns for the
Video, by changing the physical address from which the Shifter expects to
find the video information. In this way I save the time consuming operation
of moving data from NextScreen[] to the video buffer for display.

The problem that I have is that every time I call the XBIOS routine
SetScreen(logadr,phyadr,rez), where phyadr = &NextScreen[0], the screen jumps 
horizontally left to right. The information displayed on the screen is
correct but is skewed to the right 3/4 of the screen (BTW, the program
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?

Any suggestions will be welcomed.

Erasmo.