Article View: comp.sys.atari.st
Article #33465Re: Questions about ST Video Ram
From: Greg Wageman
Date: Wed, 03 Aug 1988 16:45
Date: Wed, 03 Aug 1988 16:45
55 lines
2852 bytes
2852 bytes
In article <535@skywest.UUCP> brenes@skywest.UUCP (Erasmo Brenes) writes:
>Hello, this is a question to the ST graphic 'gurus':
>
>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).
The documentation states that the display buffer must be aligned on a
256-byte boundry. There is an example in the MWC manual that shows
how to do this. I believe it is the example for Setscreen, but I do
not recall for certain. Essentially, you must allocate a 32K-plus-
256-byte buffer, then round the screen base address up to the nearest
256-byte boundry, like this:
long alt_screen; /* Alternate screen address */
long mem_block; /* Place to keep original address of
buffer, in case we want to Free() it */
/* Allocate memory for an alternate screen buffer */
if ((mem_block = (long)Malloc((unsigned)0x8100)) == NULL) {
/* Handle out-of-memory error here */
}
/* Round the address up past the next 256-byte boundry, then
zero the low-order 8 bits. This guarantees that the
address is both within the block we allocated, and at the
proper alignment. This can waste 256-bytes, worst case. */
alt_screen = (mem_block + 0x100L) & (~0xFFL);
If the returned address from Malloc() was already properly aligned,
then the wasted 256 bytes will all be at the start of the block. In all
other cases, the wasted space will be split between the beginning of
the block and the start of the screen, and the end of the screen and
the end of the block. If you are that desparate for memory,
alt_screen - mem_block
is the number of bytes wasted before the start of the screen and
256 - (alt_screen - mem_block)
is the number of bytes wasted past the end of the screen.
Greg Wageman ARPA: greg%sentry@spar.slb.com
Schlumberger Technologies BIX: gwage
1601 Technology Drive CIS: 74016,352
San Jose, CA 95110 GEnie: GWAGEMAN
(408) 437-5198 UUCP: ...!decwrl!spar!sentry!greg
------------------
The opinions expressed herein are solely the responsibility of the
author.
Technical Details
Message-ID:
<350@snjsn1.SJ.ATE.SLB.COM>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!ucsd!ucbvax!decwrl!spar!snjsn1!bilbo!gregReferences:
<535@skywest.UUCP>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!ucsd!ucbvax!decwrl!spar!snjsn1!bilbo!greg From: greg@bilbo (Greg Wageman) Newsgroups: comp.sys.atari.st Subject: Re: Questions about ST Video Ram Message-ID: <350@snjsn1.SJ.ATE.SLB.COM> Date: 3 Aug 88 16:45:11 GMT References: <535@skywest.UUCP> Sender: news@SJ.ATE.SLB.COM Reply-To: greg%sentry@spar.slb.com (Greg Wageman) Followup-To: comp.sys.atari.st Organization: Schlumberger ATE, San Jose, CA Lines: 55