Path: utzoo!utgpu!attcan!uunet!mcvax!philmds!leo
From: leo@philmds.UUCP (Leo de Wit)
Newsgroups: comp.sys.atari.st
Subject: Re: Questions about ST Video Ram
Message-ID: <573@philmds.UUCP>
Date: 3 Aug 88 17:09:00 GMT
References: <535@skywest.UUCP>
Reply-To: leo@philmds.UUCP (Leo de Wit)
Organization: Philips I&E DTS Eindhoven
Lines: 45

In article <535@skywest.UUCP> brenes@skywest.UUCP (Erasmo Brenes) writes:
 [some lines deleted]...
|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?

The shifter does not expect the video ram to start at 32K boundaries.
The restriction for the start address is that it has to be a 256 byte boundary.
The top byte of the long that contains the start address (the least
significant one, bits 0-7) is ignored, as is the low byte (the most
significant one, bits 24-31) of course because of 24 bit wide
addresses. top -1 goes to 0xffff8201, top -2 to 0xffff8203.

If you use Malloc():

    long memptr;
    extern long Malloc();

    memptr = (Malloc(32000 + 256) + 255) & ~255;

should do the trick (can fancy it by checking whether Malloc returns
out of memory, and/or by saving the return value for a possible
Mfree()). Note that a screen fits in 32000 bytes, that's less than
32K.  The overhead is the extra 256 bytes.
Adding 255 and dropping the lower 8 bits with & ~255 will ensure that
memptr will have a value between that returned by Malloc and 256 more
than that value, and that the LSB of it is 0.

|Any suggestions will be welcomed.  
| 
|Erasmo.

Hope this helped.

Leo.