ajy2208@ultb.isc.rit.edu (A.J. Yarusso) (03/07/90)
Hi everyone,
I need to know how to create region(s) on the screen that are
independent from normal screen i/o (mainly, scrolling..). Most terminal
programs have a line or two somewhere on the screen that doesn't scroll.
Usually these are status displays to show useful information (baud rate,
system connected to, various toggles, etc..).
I've searched my wonderful MWC manual, but there's no mention on how
to create something to this effect. If I had $250 to plunk down for
developer docs, I'd do that. If Atari was more leniant with disclosure
of USEFUL information for the ST, I might be able to buy books that
describe just what I want to do. In that respect, the 8-bit was much
more enjoyable to program than the ST. Hmm, it seems that my request
for help is becoming a flame, so I'll cool my jets now..
Hopefully I won't have to write custom screen i/o routines to do
this.. Ahh, I wish the ST had a display list.. :-)
_____________________________________________________________________________
Albert Yarusso, Rochester ajy2208@ritvax.bitnet
Institute of Tech. _________________________________________________________
Computer Science /___ / {rutgers, ames}!rochester!ultb!ajy2208
______________________/ / ajy2208@ultb.cs.rit.edu GEnie: A.Yarussosteve@thelake.mn.org (Steve Yelvington) (03/08/90)
[In article <2344@ultb.isc.rit.edu>,
ajy2208@ultb.isc.rit.edu (A.J. Yarusso) writes ... ]
> I need to know how to create region(s) on the screen that are
> independent from normal screen i/o (mainly, scrolling..). Most terminal
> programs have a line or two somewhere on the screen that doesn't scroll.
> Usually these are status displays to show useful information (baud rate,
> system connected to, various toggles, etc..).
Of course, you can do all that (and more) with GEM, but GEM is difficult
and slow. The fast way is to use Line A.
> I've searched my wonderful MWC manual, but there's no mention on how
> to create something to this effect.
To translate the following for MWC, you'll need to look at the linea.h
file in your \include\ directory. It's coded for Sozobon C and Sozobon
assembler.
=cut here===========================
* LINEA.S -- assemble this function with jas.ttp; don't optimize it
.text
.globl _getlinea
_getlinea:
.dc.w $a000
rts
=cut here===========================
/*
* STATBAR.C
* cc -O -DTEST statbar.c linea.o
*/
#include <stdio.h>
#define XP -28 /* where the current cursor X value is stored */
#define YP -26 /* where the current cursor Y value is stored */
#define LINES -42 /* where screen's size in lines is stored */
#define COLS -44 /* where screen's size in columns is stored */
#define IP(x) ((int*)(linea+(x))) /* isn't C a pretty sight? */
static long linea;
extern long getlinea();
lkbar()
{
linea = getlinea();
(*IP(LINES))--;
}
unlkbar()
{
(*IP(LINES))++;
}
clrbar()
{
statmsg("\033K",0);
}
statmsg(msg, x)
char *msg;
int x;
{
int xp, yp;
xp = *IP(XP); /* Save cursor's row */
yp = *IP(YP); /* and column */
unlkbar(); /* unlock the status bar */
printf("\033Y%c%c%s\033Y%c%c",
32 + *IP(LINES), /* Go to the bottom line */
32+x, /* and column x */
msg, /* write the message */
32+yp, /* go back to where */
32+xp); /* we came from */
lkbar(); /* lock the status bar */
}
#ifdef TEST
/*
* A little demo of the status bar
*/
main()
{
int i;
printf("\033E"); /* clear screen, home cursor */
printf("This is a demonstration of a status bar\n");
lkbar();
clrbar();
/*
* note that you should not end a status msg with a newline!
*/
statmsg("\033pThis is printed on the status line\033q",3);
for (i=1; i<101; i++)
{
printf("This is line number %d\n", i);
}
clrbar();
statmsg("\033pPress any key to exit\033q",3);
getch();
unlkbar();
}
#endif
--
Steve Yelvington at the lake in Minnesota
UUCP path: ... umn-cs.cs.umn.edu!thelake!stevegl8f@astsun9.astro.Virginia.EDU (Greg Lindahl) (03/08/90)
In article <2344@ultb.isc.rit.edu> ajy2208@ultb.isc.rit.edu (A.J. Yarusso) writes: >Hi everyone, > > I need to know how to create region(s) on the screen that are >independent from normal screen i/o (mainly, scrolling..). Most terminal >programs have a line or two somewhere on the screen that doesn't scroll. >Usually these are status displays to show useful information (baud rate, >system connected to, various toggles, etc..). If you want to do this in a totally general fashion (i.e. do more than just keep N lines at the bottom of the screen from scrolling) you need to use the vdi functions to write on the screen, and use blitting operations to scroll sections of the screen. This is a lot more complex than getting to treat the screen as an almost-dumb terminal, but sometimes it's worth it. If you want to make this go very fast, you should be sure you avoid clipping, blit to byte boundaries, and use a software accellerator such as TurboST or Quick ST. > I've searched my wonderful MWC manual, but there's no mention on how >to create something to this effect. The stuff I talked about above is in your MWC manual. It's not the easiest way to do it, but it's the most general one. Greg Lindahl gl8f@virginia.edu Astrophysicists for Choice.
bammi@curie.ces.cwru.edu (Jwahar R. Bammi) (03/08/90)
In article <2344@ultb.isc.rit.edu> ajy2208@ultb.isc.rit.edu (A.J. Yarusso) writes: > Hopefully I won't have to write custom screen i/o routines to do No you wont have to! there is an advertised lineA variable (V_CEL_MY) just to do this: the short (16 bit) at offset -0x2a (-42 decimal) bytes from the lineA base can be set to a number N to get effectively a N+1 line scrolling region vt52. For instance if you want the N'th line to be a status line, and have a (N-1)x80 vt52, you would set char *linea_base = (base of lineA from linea0 (0xA000)); short *V_CEL_MY = (short *)(linea_base - 42L); short save; save = *V_CEL_MY; *V_CEL_MY = save - 1; .... and before terminating: *V_CEL_MY = save; its probably not a good idea to assume that the screen is 25 lines high (or even 80 wide (with can be determined from V_CEL_MX at offset -44)). To write to the bottom line(s): - you can use something like v_gtext() - or you can change *V_CEL_Y, write to the line using Bcon/Ccon traps, and change *V_CEL_Y back, and so on.. Some of this stuff is documented in <line.h> that i posted here a while back, or in the more current version of that file that comes with the Gnu C library (available via FTP from dsrgsun.ces.crwu.edu). -- -- bang: {any internet host}!dsrgsun.CES.CWRU.Edu!bammi jwahar r. bammi domain: bammi@dsrgsun.ces.CWRU.edu GEnie: J.Bammi
neil@cs.hw.ac.uk (Neil Forsyth) (03/08/90)
In article <2344@ultb.isc.rit.edu> ajy2208@ultb.isc.rit.edu (A.J. Yarusso) writes: >Hi everyone, > > I need to know how to create region(s) on the screen that are >independent from normal screen i/o (mainly, scrolling..). Most terminal >programs have a line or two somewhere on the screen that doesn't scroll. >Usually these are status displays to show useful information (baud rate, >system connected to, various toggles, etc..). Well I've never needed to do this but if I did I'd go about it like this. Example: Say I want a status line at the bottom of the screen but I want the other 24 line to scroll about like normal. Allocate a 256 byte alligned chunk of screen RAM that is 26 lines high. (26 * 0x500 + allignment) Use Setscreen (XBIOS #5) to set the logical screen RAM pointer to the start of this RAM but set the physical pointer 0x500 bytes further on. This makes the screen output and scrolling not affect the last visible line on the screen. When you want to change the status line set the logical screen base to match the physical one position the cursor on the last line and do your stuff. Restore the logical screen pointer then rinse and repeat ... Similar nonsense can be performend for upper syslines. Hope this helps. Enjoy the bombs :-) >_____________________________________________________________________________ > Albert Yarusso, Rochester ajy2208@ritvax.bitnet > Institute of Tech. _________________________________________________________ > Computer Science /___ / {rutgers, ames}!rochester!ultb!ajy2208 >______________________/ / ajy2208@ultb.cs.rit.edu GEnie: A.Yarusso +-----------------------------------------------------------------------------+ ! DISCLAIMER: Unless otherwise stated, the above comments are entirely my own ! ! ! ! Neil Forsyth JANET: neil@uk.ac.hw.cs ! ! Dept. of Computer Science ARPA: neil@cs.hw.ac.uk ! ! Heriot-Watt University UUCP: ..!ukc!cs.hw.ac.uk!neil ! ! Edinburgh, Scotland, UK "it's pronounced Throatgobbler Mangrove" ! +-----------------------------------------------------------------------------+
t68@nikhefh.nikhef.nl (Jos Vermaseren) (03/09/90)
In article <2344@ultb.isc.rit.edu>, ajy2208@ultb.isc.rit.edu (A.J. Yarusso) writes: > Hi everyone, > > I need to know how to create region(s) on the screen that are > independent from normal screen i/o (mainly, scrolling..). Most terminal > programs have a line or two somewhere on the screen that doesn't scroll. > Usually these are status displays to show useful information (baud rate, > system connected to, various toggles, etc..). > > I've searched my wonderful MWC manual, but there's no mention on how > to create something to this effect. If I had $250 to plunk down for > developer docs, I'd do that. If Atari was more leniant with disclosure The docs wouldn't help you, because the trick is very simple. 1: Compute how meny bytes there are in the region you want to keep fixed (like two lines in monochrome = 80*16*2 bytes) 2: Ask via the XBIOS for the Logbase pointer. Keep it for later. 3: Subtract the computed amount 4: Set the new Logbase via the XBIOS 5: Insert and delete lines to your hearts content, but never put the cursor in the top lines (the two lines of the example don't really exist. Don't use a clear screen or any other code that would affect the non existing lines. 6: After scrolling, put the Logbase back to its old value. If you start with asking for the resolution you can make this fully portable. If you want this to work also for non standard fonts you have to determine the font height first. This height can be found at the negative Line-A variables. They are described in a book by Katherine Peel (in one of the appendices). Alternative way of finding: play around with some standard fonts and a debugger. The bytes with a negative offset of at most 46 from what dc.w $A000 returns in a0 have been fixed by Atari. (it is amazing how many programs get confused by a 8*12 font. Even GEM shows a few bugs). Jos Vermaseren