rbraun@spdcc.COM (Rich Braun) (05/29/91)
I'm in the midst of porting a DOS application to SCO Unix, and have run into a design issue which might have been solved already. The application uses 16 colors (I think; maybe only 8) for character- oriented displays. It handles character colors by simply setting values in the high byte of each element of the display memory (which is a 80 x 25 x 2-byte array). I want this thing to be portable across Unix platforms, and am therefore using terminfo routine calls. But I'd like to duplicate the "look and feel" from DOS, at least for the console terminal of an SCO system. It appears to me that terminfo isn't powerful enough to handle this without adding extra attributes, and I don't have any example applications which try to do this (the source code to 'ecu' does some of this but doesn't try to go crazy with multiple colors). SCO documentation doesn't even tell you that the escape sequences to set colors are <ESC>[=H, <ESC>[=F, etc. On a semi-related point, I'd like to be able to set attributes in the character map without having to fetch the characters out and put them back. (For highlighting menu items, etc.) The DOS code uses functions like "set_attr (x,y,numchars,attrbits)" to do this, and I don't see an equivalent in terminfo. Yet I'm pretty sure the internals of terminfo should easily allow this. Any suggestions or sample code? Thanks, -rich
staceyc@sco.COM (Stacey Campbell) (05/30/91)
In article <7667@spdcc.SPDCC.COM> rbraun@spdcc.COM (Rich Braun) writes: >I'm in the midst of porting a DOS application to SCO Unix, and have >run into a design issue which might have been solved already. The >application uses 16 colors (I think; maybe only 8) for character- >oriented displays. It handles character colors by simply setting >values in the high byte of each element of the display memory >(which is a 80 x 25 x 2-byte array). You might consider using curses level routines instead of the lower level terminfo routines. It sounds like your DOS app does its own screen handling and you are hoping to plug in terminfo calls for the output. In the long run you will probably get better screen optimizations using curses. curses also knows how to deal with terminals that don't have certain attributes or features, using curses would mean not duplicating that (very tedious) work in your own app. SCO Unix offers the standard System V 3.2 color curses library. Both curses and terminfo deal with color. Check the setf, setb, op, ccc, (et. al.) terminfo capabilities. At the curses level check start_color(), COLOR_PAIR(), init_pair(), A_COLOR, etc. routines and macros. The current shipping SCO console terminfo file implements the 8 defined ANSI colors in foreground and background, this gives you 64 defined color pairs. If you are willing to alter the terminfo file setf and setb caps then you can implement 16 foreground and background colors, though that will move your terminfo file and application(s) away from the "standard" that the curses COLOR_[whatever] macros seem to be creating (which I personally stuck to when doing the SCO Professional 2.1 color work). >SCO documentation doesn't even tell you that the escape sequences >to set colors are <ESC>[=H, <ESC>[=F, etc. Check your terminfo file to see how the standard ANSI colors are used, my personal setf and setb entries have been changed because I don't like the ANSI dark yellow, I change it to bright yellow; setb=\E[=0G\E[%?%p1%{3}%=%t=14G%e4%p1%dm%;, setf=\E[=7F\E[%?%p1%{3}%=%t=14F%e3%p1%dm%;, Simply checking the output of setcolor is a straightforward way of determining the other non-ANSI SCO console color sequences. >On a semi-related point, I'd like to be able to set attributes in >the character map without having to fetch the characters out and >put them back. (For highlighting menu items, etc.) The DOS code >uses functions like "set_attr (x,y,numchars,attrbits)" to do this, >and I don't see an equivalent in terminfo. Yet I'm pretty sure >the internals of terminfo should easily allow this. The terminfo level of routines has no idea of what your screen looks like, the calls simply output characters, parameterizing and turning on screen attributes where required. Terminals cannot be accessed as memory mapped devices via terminfo or curses; that is, you cannot directly tweak some bit in memory that the video hardware will recognize as "standout mode" for that screen character. Most terminals require you to move the cursor to a position, output the sequence to switch on the attribute, output everything, turn off the attribute. There are many special cases in the above sequence, nearly all dealt with by curses, but not terminfo. As far as terminfo and curses are concerned, the console is just another terminal attached to a /dev/tty. >Any suggestions or sample code? I can send some demo color curses code. I have never written a terminal-generalized color terminfo application, that is potentially a very painful task. -- Stacey Campbell Internet: staceyc@sco.com UUCP: {uunet,ucscc,att,sq,altos,lotus,sun,microsoft}!sco!staceyc
vic@grep.co.uk (Victor Gavin) (05/30/91)
In article <7667@spdcc.SPDCC.COM> rbraun@spdcc.COM (Rich Braun) writes: >I want this thing to be portable across Unix platforms, and am >therefore using terminfo routine calls. But I'd like to duplicate >the "look and feel" from DOS, at least for the console terminal of >an SCO system. It appears to me that terminfo isn't powerful enough >to handle this without adding extra attributes, and I don't have >any example applications which try to do this (the source code to >'ecu' does some of this but doesn't try to go crazy with multiple >colors). I have version of CURSES for PC's which is sort-of-like System V CURSES. It definitely handles colour in a portable way, which might be a better way to go if you want proper unix/dos portability. Mail me if you're interested -- I can supply some example code which uses CURSES colour stuff if you want to have a look... vic -- Victor Gavin <vic@grep.co.uk||..!ukc!logitek!grep!vic||..!ukc!vision!grep!vic>
rbraun@spdcc.COM (Rich Braun) (05/31/91)
staceyc@sco.COM (Stacey Campbell) writes: >You might consider using curses level routines instead of the >lower level terminfo routines. It sounds like your DOS app does >its own screen handling and you are hoping to plug in terminfo >calls for the output. In the long run you will probably get >better screen optimizations using curses. curses also knows >how to deal with terminals that don't have certain attributes >or features, using curses would mean not duplicating that (very >tedious) work in your own app. I could use some better doc on the distinction between curses and terminfo. I immediately saw that terminfo would be superior to just termcap (which an older port of some Kronos software used, to the detriment of the guys handling service calls {-;), but I'm not too up on curses. >Both curses and terminfo deal with color. Check the setf, setb, op, >ccc, (et. al.) terminfo capabilities. At the curses level check >start_color(), COLOR_PAIR(), init_pair(), A_COLOR, etc. routines >and macros. A co-worker pointed me at these routines, and I'm happy to say I got my application running reasonably well on the console (a VGA card). Nowhere near as fast as the direct-video output under DOS, but probably good enough. > Terminals cannot be accessed >as memory mapped devices via terminfo or curses; that is, you cannot >directly tweak some bit in memory that the video hardware... As a first approximation, I implemented my "set_attr" function by fetching characters out of terminfo's screen image via the winch() function and tacking on the new attribute bits. Slow but it works. >>Any suggestions or sample code? > >I can send some demo color curses code. I have never written a >terminal-generalized color terminfo application, that is potentially >a very painful task. Would appreciate the demo code (by e-mail). I'm especially interested in figuring out reasonable ways of mapping color attributes to "traditional" attributes like underscore, blink, bold, and inverse, so the application looks like it does under DOS if you're on a color terminal but also looks OK if you're on a VT100-class terminal (which is probably what a lot of our customers have). By the way, someone pointed me to the screen(HW) man page provided by SCO. This describes some (not all) of the ANSI-style escape sequences provided by the ANSI interpreter, and also tells how to do direct memory-mapped I/O to graphics cards under UNIX. Since I've already got functional DOS code for managing the hardware memory map, it shouldn't be too difficult to put run-time conditionals into similar Unix code for making VGA console output run really well. (I'd encourage other 386- Unix developers to take advantage of this feature, which may very well be implemented as a standard V.3 feature and not just SCO.) -rich
john@jwt.UUCP (John Temples) (06/02/91)
In article <1991May30.095028.15797@grep.co.uk> vic@grep.co.uk (Victor Gavin) writes: >I have version of CURSES for PC's which is sort-of-like System V >CURSES. It definitely handles colour in a portable way, which might be >a better way to go if you want proper unix/dos portability. I'd like to see a curses-compatible library which writes directly to the video memory if you're at the console. Curses applications at the console are far too sluggish. -- John W. Temples -- john@jwt.UUCP (uunet!jwt!john)
rick@digibd.com (Rick Richardson) (06/05/91)
>In article <7667@spdcc.SPDCC.COM> rbraun@spdcc.COM (Rich Braun) writes: >>I want this thing to be portable across Unix platforms, and am >>therefore using terminfo routine calls. You can do colors with SVR3.2 and later ETI (was curses). The code is source code portable across various 386 SVR3.2's, but not binary portable, unless you are willing to tolerate arbitrary changes to the color scheme. This is because SCO changed the COLOR_XXX #define values from the *documented* set in the ETI Programmers Guide to a set that matches some ISO color numbering scheme. This also means that terminfo entries for color terminals are different for SCO. -Rick -- Rick Richardson Email: rick@digibd.com Senior MTS Fax: (612) 943-0803 DigiBoard, Inc. Tel: (612) 943-5383