js@uw-june (Joe Meadows) (03/20/86)
Hi, I've been playing with a terminal program using a borderless backdrop window with no gadgets and all to get a full 80 x 25 line display, (also used the Query function on the Serial read function, it helps quite a bit) Anyway, I thought the next step would be to use a SuperBitMap structure that I could scroll around and have a sizeable, draggable window. However, using the Console device, if I size the window the console device restricts itself to the current size of the window, i.e. it wraps lines and such. Is there any way to force the console device to use the full size of the Bitmap? I'd like not to go to the effort of writing an Ansi emulator.. By the way, any chance of adding Scrollable regions to the Console devices repertoire of escape codes? That seems to be the only thing standing between me and my VAX (VMS) editors (EDT, TPU). Thanks for any pointers. Cheers
js@uw-june (Joe Meadows) (03/20/86)
Well, I found the answer to the question I just posted regarding forcing the console to use specific sizes for determining output to a window (needed for a SUPER_BITMAP window). Theres a couple of escape sequences to do the trick. But I have one more problem, There's no Cursor in my window! What magic do I need to get the console device to work correctly with a super_bitmap ? <esc>c doesn't seem to re-init anything and I have no cursor... Also, why doesn't the call to AllocRaster clear the memory that it allocates? I like the pretty little patterns I get sometimes, but jeez, one more line of code? Oh well. Perhaps the AllocRaster call could allow you to specify a pattern for each layer? Well, sorry to clutter the net.. Cheers.
daveb@cbmvax.cbm.UUCP (Dave Berezowski) (03/23/86)
> By the way, any chance of adding Scrollable regions to the Console devices > repertoire of escape codes? That seems to be the only thing standing between > me and my VAX (VMS) editors (EDT, TPU). > Thanks for any pointers. > Cheers *** REPLACE THIS LINE WITH YOUR MESSAGE *** The console device already has set scrollable region commands (sort of). They can be found in the Amiga DOS Deveoper's Manual on page A-7 (old white book). The commands are: CSI Ps t - set page length CSI Ps u - set line length CSI Ps x - set left offset CSI Ps y - set top offset I've used set top offset and set page length to emulate the scrollable window regions of a VT100; a code segment follows. set_windows(top_row,bottom_row) UBYTE top_row, bottom_row; { WRITE (CSI); /* control sequence introducer $9b */ WRITE ('H'); /* home cursor THIS IS IMPORTANT */ digits(--top_row * 8); /* convert top_row argument to pixels and then to ascii digits */ WRITE (CSI); WRITE (huns); WRITE (tens); WRITE (ones); WRITE ('y'); /* set top offset */ digits (bottom_row - top_row); /* comp length and conv to ascii */ WRITE (CSI); WRITE (tens); WRITE (ones); WRITE ('t'); /* set page length */ The above really isn't a code segment, but I imagine that you get the idea. Some notes: a) WRITE - outputs a char to the console device b) digits - converts a # to its ascii digits in huns, tens, & ones. c) YOU ABSOLUTELY HAVE TO HOME THE CURSOR FIRST d) The ('* 8') is there as I am working with a font that is eight pixels high; you may want to use a variable instead. Have fun! Regards, David Berezowksi (daveb@cbmvax)
dale@amiga.UUCP (Dale Luck) (03/26/86)
In article <568@uw-june> js@uw-june (Joe Meadows) writes: > > Also, why doesn't the call to AllocRaster clear the memory > that it allocates? I like the pretty little patterns I get sometimes, > but jeez, one more line of code? Oh well. > That's right, why don't you put that extra line of code in your routine. Not much trouble is it? The reason we don't clear the raster is so that those people who are interested more in speed than comfort do not have to write there own routines to achieve the speed they need. Dale Luck