heimir@hafro.is (Heimir Sverrisson) (07/25/90)
I've just got a copy of The Norton Utilities for SystemV up and running on my Interactive Unix 386 2.2. The programs look very useful and fast -- but there is one thing that prevents me from using them at all. I can find no way to change the characters it uses for line drawing :-) I'm using the ISO 8859/1 character set on my machine (because it's the only one that has all Ice- landic characters). The programs seem to assume that all terminals have the line drawing characters of the infamous IBM Code Page 437 :-( I found no mention of this problem in the manuals, but they say that the programs use the TERMINFO database. I've been trying to change the 'acsc' parameter that does work fine for line drawing in my own curses-based programs -- but without luck. Does anyone know if I can change the behaviour of these programs -- either with configuration or even patches ?? -- Heimir Thor Sverrisson heimir@hafro.is -- --- Heimir Thor Sverrisson Uucp: mcsun!isgate!hafro!heimir Internet: heimir@hafro.is
johnl@esegue.segue.boston.ma.us (John R. Levine) (07/26/90)
In article <175@hafro.is> heimir@hafro.is (Heimir Sverrisson) writes: >The programs seem to assume that all terminals have the line drawing >characters of the infamous IBM Code Page 437 :-( In the current version of the Utilities, if a full-screen program sees that it's running on a mappable screen, it goes into a special high-performance mode that writes directly to the screen and has the line-drawing characters hard-coded in. For people not using code page 437, this can produce some rather peculiar looking screens. It's a limitation of the current product that we expect to fix in a future version. In the meantime, you might try the "-term" flag which tells it to run through terminfo and curses even though it's on the console, and give it a terminfo entry that better reflects your screen characters. It's not quite as fast as direct writes, but might look nicer. -- John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650 johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl Marlon Brando and Doris Day were born on the same day.
richard@pegasus.com (Richard Foulk) (07/27/90)
>In the current version of the Utilities, if a full-screen program sees that >it's running on a mappable screen, it goes into a special high-performance >mode that writes directly to the screen and has the line-drawing characters >hard-coded in. For people not using code page 437, this can produce some >rather peculiar looking screens. It's a limitation of the current product >that we expect to fix in a future version. > >In the meantime, you might try the "-term" flag which tells it to run through >terminfo and curses even though it's on the console, and give it a terminfo >entry that better reflects your screen characters. It's not quite as fast as >direct writes, but might look nicer. > What in the world did you gain by talking directly to the screen? A little speed?! Or was the idea to make the package non-portable? Unsophisticated developers have been tying text-display based (non-graphic) utilities to specific hardware for years now, on pc's and mac's and others. They often get burnt later. And the utility gains basically nothing; perhaps enough additional speed to almost notice, or it looks a little prettier, but the desired function isn't noticeably enhanced. The bugs tend to be a little more interesting I guess. There's certainly more opportunity for them to be created. Maybe I missed something here, what in the world does a Norton Utilities clone have to gain from direct video? -- Richard Foulk richard@pegasus.com
johnl@esegue.segue.boston.ma.us (John R. Levine) (07/27/90)
In article <1990Jul27.104059.12955@pegasus.com> richard@pegasus.com (Richard Foulk) writes: >Maybe I missed something here, what in the world does a Norton Utilities >clone have to gain from direct video? When we're repainting large amounts of the screen, as when scrolling something, direct writes are a whole lot faster. If you hold down an arrow key to make it scrolll, terminfo/curses has trouble keeping up but direct writes have no problem. There's also complete terminfo/curses support for people not using a console. By the way, it's not a Norton Utilities clone, it's really the Norton Utilities. It even shares a certain amount of source code with the DOS version. -- John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650 johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl Marlon Brando and Doris Day were born on the same day.
peter@ficc.ferranti.com (Peter da Silva) (07/28/90)
In article <1990Jul27.165315.13531@esegue.segue.boston.ma.us> johnl@esegue.segue.boston.ma.us (John R. Levine) writes: > When we're repainting large amounts of the screen, as when scrolling > something, direct writes are a whole lot faster. Yes, and direct writes to the disk are a lot faster too, but people tend to prefer going through the file system. Funny thing, that. > If you hold down an > arrow key to make it scrolll, terminfo/curses has trouble keeping up > but direct writes have no problem. So detect that and jump-scroll. That way people on terminals (or using X, or using a console you don't know about, or whatever) will benefit as well. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` <peter@ficc.ferranti.com>
rick@pcrat.uucp (Rick Richardson) (07/30/90)
In article <1OY4DT3@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >In article <1990Jul27.165315.13531@esegue.segue.boston.ma.us> johnl@esegue.segue.boston.ma.us (John R. Levine) writes: >> If you hold down an >> arrow key to make it scrolll, terminfo/curses has trouble keeping up >> but direct writes have no problem. >So detect that and jump-scroll. That way people on terminals (or using X, >or using a console you don't know about, or whatever) will benefit as well. I don't want to get into this argument proper, but the SVR3.2 ETI already has the capability to detect that it is falling behind and to start jump scrolling to catch up. Its actually a little bit uglier to look at than that, but it does accomplish the task. Maybe I will jump in. As long as the application still fully supports ETI on things other than the console, I really can't see anything wrong with making console response as snappy as console response under, say, DOS. Modulo the fact that the necessary console ioctl's are totally non-portable between the various UNIXes. I'm going to post a programmers summary of this situation in a few days. -Rick -- Rick Richardson | Looking for FAX software for UNIX/386 ??? Ask About: |Mention PC Research,Inc.| FaxiX - UNIX Facsimile System (tm) |FAX# for uunet!pcrat!rick| FaxJet - HP LJ PCL to FAX (Send WP,Word,Pagemaker...)|Sample (201) 389-8963 | JetRoff - troff postprocessor for HP LaserJet and FAX|Output
johnl@esegue.segue.boston.ma.us (John R. Levine) (07/30/90)
In article <1990Jul29.235310.6138@pcrat.uucp> rick@pcrat.UUCP (Rick Richardson) writes: >Maybe I will jump in. As long as the application still fully supports ETI on >things other than the console, I really can't see anything wrong with making >console response as snappy as console response under, say, DOS. Modulo the >fact that the necessary console ioctl's are totally non-portable between the >various UNIXes. I'm going to post a programmers summary of this situation in >a few days. Thanks. We do indeed fully support ETI, and the Utilities work perfectly well on any terminal describable by terminfo. By the way, the ioctl's for ISC Unix at AT&T screen control are pretty much compatible, it's SCO that, because of bugs and interface changes, is so different. -- John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650 johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl Marlon Brando and Doris Day were born on the same day.
richard@pegasus.com (Richard Foulk) (07/31/90)
>>Maybe I missed something here, what in the world does a Norton Utilities >>clone have to gain from direct video? > >When we're repainting large amounts of the screen, as when scrolling >something, direct writes are a whole lot faster. If you hold down an >arrow key to make it scroll, terminfo/curses has trouble keeping up >but direct writes have no problem. There's also complete terminfo/curses >support for people not using a console. I certainly hope other developers don't follow suite. This sort of gratuitous, DOS-style, system dependency is what the "open-systems" movement has been seeking to avoid. What Unix seeks to avoid. There is too little to gain and too much to lose. -- Richard Foulk richard@pegasus.com
peter@ficc.ferranti.com (Peter da Silva) (07/31/90)
In article <1990Jul29.235310.6138@pcrat.uucp> rick@pcrat.UUCP (Rick Richardson) writes: > see anything wrong with making console response as snappy as > console response under, say, DOS. Modulo the fact that the > necessary console ioctl's are totally non-portable between > the various UNIXes. Plus, it'll break on a console driver that isn't quite what you're expecting (such as the font problem that started this discussion, or an unknown graphic card (say, IBM's new "XGA" standard). The biggest problem with DOS is that it encourages programs to do this sort of thing... and they break on the next generation, or on imperfect clones, or whatever. Applications should not have to replace the O/S, and on UNIX they don't. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` <peter@ficc.ferranti.com>
tneff@bfmny0.BFM.COM (Tom Neff) (07/31/90)
In article <1990Jul27.104059.12955@pegasus.com> richard@pegasus.com (Richard Foulk) writes: >>In the current version of the Utilities, if a full-screen program sees that >>it's running on a mappable screen, it goes into a special high-performance >>mode that writes directly to the screen and has the line-drawing characters >>hard-coded in ... > >What in the world did you gain by talking directly to the screen? A little >speed?! Or was the idea to make the package non-portable? No big mystery here. It's called PC-ITIS. A generation of spoiled PC software vendors has staked its product value and market share on the ability to twiddle the hardware for pretty pictures and funny sounds. Now with the rise of UNIX 386 they have this dream segment of users running on PC-"like" machines with UNIX class budgets. Finally, they figure, they can "move up" without sacrificing the all important window dressing and gingerbread. Result: little smiley faces and maps of New Jersey boop-ing and queep-ing all over the place, instead of straightforward portable functionality. And blank screens on otherwise compatible UNIX boxes nationwide. It's the silly phenomenon of the "full screen graphics CHDIR command" all over again. -- I'm a Leo. Leos don't believe * * * Tom Neff in this astrology stuff. * * * tneff@bfmny0.BFM.COM
wilber@nunki.usc.edu (John Wilber) (07/31/90)
In article <1990Jul30.181330.3855@pegasus.com> richard@pegasus.com (Richard Foulk) writes: >I certainly hope other developers don't follow suite. This sort of >gratuitous, DOS-style, system dependency is what the "open-systems" >movement has been seeking to avoid. What Unix seeks to avoid. Perhaps you are under a misconception. Norton Utilities for System V doesn't JUST use direct I/O, it speaks curses/terminfo too. We just do the best with the equipment available. If you are on a terminal things work just fine, if you are on the console, things work even finer. It's plenty open as far as I am concerned.
rick@pcrat.uucp (Rick Richardson) (07/31/90)
In article <T:_47-2@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >In article <1990Jul29.235310.6138@pcrat.uucp> rick@pcrat.UUCP (Rick Richardson) writes: >The biggest problem with DOS is that it encourages programs to do this >sort of thing... and they break on the next generation, or on imperfect >clones, or whatever. Applications should not have to replace the O/S, and >on UNIX they don't. Remember that a pre-condition was that ETI was fully supported, and John said it was. So, there is no chance this application will break. Just that you may not be able to get the additional performance. My point was that I see nothing wrong with making the display performance available as an option. -Rick -- Rick Richardson | Looking for FAX software for UNIX/386 ??? Ask About: |Mention PC Research,Inc.| FaxiX - UNIX Facsimile System (tm) |FAX# for uunet!pcrat!rick| FaxJet - HP LJ PCL to FAX (Send WP,Word,Pagemaker...)|Sample (201) 389-8963 | JetRoff - troff postprocessor for HP LaserJet and FAX|Output
karl@ficc.ferranti.com (Karl Lehenbauer) (08/01/90)
Programs that directly went to display memory rather than through the BIOS are the number one reason why the capabilities of MS-DOS have been so slow to evolve. Yes, on the original PC because the BIOS was poorly written, display I/O was very slow. But because of this crufty hack, tens of millions of people sit running one task at a time on machines perfectly capable of useful multitasking. Now people who have cut their eyeteeth in the environment-of-the-crufty-hack bring their malodorous workarounds to Unix, an OS that, having evolved in an environment where memory mapping and protection were omnipresent, never really provided people with much incentive to do weird hacks that boosted performance of specific programs while encumbering the OS developers with the need to provide backward compatibility to their funky kludges, and we are to bless it? No way. If you want to make display update faster, do it at the driver level so every program can take advantage of it. Otherwise, stick to the problem at hand, namely, your application, and do not gratuitously bypass the OS. -- -- uunet!ficc!karl "I am here by the will of the people and I won't leave uunet!sugar!karl until I get my raincoat back." -- Metrophage
peter@ficc.ferranti.com (Peter da Silva) (08/01/90)
In article <1990Jul31.101937.9157@pcrat.uucp> rick@pcrat.UUCP (Rick Richardson) writes: > In article <T:_47-2@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > >The biggest problem with DOS is that it encourages programs to do this > >sort of thing... and they break on the next generation, or on imperfect > >clones, or whatever. > Remember that a pre-condition was that ETI was fully supported, and > John said it was. So, there is no chance this application will break. But it already broke! This whole discussion started because someone's system was set up slightly differently (in this case an alternate character set) and it went ahead anyway with the (now) non-working direct screen writer. Can you guarantee that nobody's extended VGA, or IBM's new XGA cards, or whatever won't fool it into thinking that it can do direct screen I/O and have it do something worse than print gibberish? Obviously not. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` <peter@ficc.ferranti.com>
rick@pcrat.uucp (Rick Richardson) (08/03/90)
In article <8Y-48O9@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >In article <1990Jul31.101937.9157@pcrat.uucp> rick@pcrat.UUCP (Rick Richardson) writes: >> Remember that a pre-condition was that ETI was fully supported, and >> John said it was. So, there is no chance this application will break. >But it already broke! This whole discussion started because someone's >system was set up slightly differently (in this case an alternate character >set) and it went ahead anyway with the (now) non-working direct screen >writer. Can you guarantee that nobody's extended VGA, or IBM's new XGA >cards, or whatever won't fool it into thinking that it can do direct >screen I/O and have it do something worse than print gibberish? I agree that if the user can't control what mode the software operates in, then the software is at fault, and should be fixed. I don't think that condemns the whole idea of providing direct screen write as an option. In some cases, it simply must be done. Anything that wants to do graphics is going to have to go directly to the screen. (Lets leave X windows, another user mode application, out of this for now; many don't need or want it at this point). In other cases, direct screen writes are of tremendous value. People find it convenient to lean on the arrow keys to move around, and expect to stop on a dime when they see where they want to be. For many screen layouts, this requires the use of scrolling regions to do it in an eye pleasing manner. Perhaps we can agree that the console driver should have scrolling regions, and return to the favorite activity of this group -- UNIX vendor bashing. Anyway, I enclose for the curious, a benchmark that shows the difference in speed for the ANSI console driver vs. direct screen writes. For those that don't care to run it, I got a maximum of 12 scrolls per second using ANSI, and 140 scrolls per second using direct screen writes. The test simulates an application where only a portion of the screen (horizontally and vertically) is expected to scroll. -Rick #! /bin/sh # This is a shell archive. Remove anything before this line, then unpack # it by saving it into a file and typing "sh file". To overwrite existing # files, type "sh file -c". You can also feed this as standard input via # unshar, or by typing "sh <file", e.g.. If this archive is complete, you # will see the following message at the end: # "End of shell archive." # Contents: sw.c # Wrapped by rick@pcroe on Thu Aug 2 19:54:26 1990 PATH=/bin:/usr/bin:/usr/ucb ; export PATH if test -f 'sw.c' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'sw.c'\" else echo shar: Extracting \"'sw.c'\" \(5463 characters\) sed "s/^X//" >'sw.c' <<'END_OF_FILE' X X/* X * Test program to demonstrate scrolling speed X * X * cc sw.c -o sw X */ X#include <stdio.h> X X#include <sys/types.h> X#include <sys/times.h> X#include <termio.h> X#include <limits.h> /* for CLK_TCK (100) */ X X#include <sys/at_ansi.h> X#include <sys/kd.h> X Xlong times(); X Xchar *taddr; Xchar *paddr; Xint start; X X#define TESTSECS 10 /* seconds */ X X#define LINES 25 X#define COLS 80 X#define XOFF 8 X#define YOFF 4 X#define SLINES (LINES-YOFF) X#define SCOLS (COLS-XOFF) X Xchar *strings[SLINES] = X{ X"Line 01 Line 01 Line 01 Line 01 Line 01 Line 01 Line 01 Line 01 Line 01", X"Line 02 Line 02 Line 02 Line 02 Line 02 Line 02 Line 02 Line 02 Line 02", X"Line 03 Line 03 Line 03 Line 03 Line 03 Line 03 Line 03 Line 03 Line 03", X"Line 04 Line 04 Line 04 Line 04 Line 04 Line 04 Line 04 Line 04 Line 04", X"Line 05 Line 05 Line 05 Line 05 Line 05 Line 05 Line 05 Line 05 Line 05", X"Line 06 Line 06 Line 06 Line 06 Line 06 Line 06 Line 06 Line 06 Line 06", X"Line 07 Line 07 Line 07 Line 07 Line 07 Line 07 Line 07 Line 07 Line 07", X"Line 08 Line 08 Line 08 Line 08 Line 08 Line 08 Line 08 Line 08 Line 08", X"Line 09 Line 09 Line 09 Line 09 Line 09 Line 09 Line 09 Line 09 Line 09", X"Line 10 Line 10 Line 10 Line 10 Line 10 Line 10 Line 10 Line 10 Line 10", X"Line 11 Line 11 Line 11 Line 11 Line 11 Line 11 Line 11 Line 11 Line 11", X"Line 12 Line 12 Line 12 Line 12 Line 12 Line 12 Line 12 Line 12 Line 12", X"Line 13 Line 13 Line 13 Line 13 Line 13 Line 13 Line 13 Line 13 Line 13", X"Line 14 Line 14 Line 14 Line 14 Line 14 Line 14 Line 14 Line 14 Line 14", X"Line 15 Line 15 Line 15 Line 15 Line 15 Line 15 Line 15 Line 15 Line 15", X"Line 16 Line 16 Line 16 Line 16 Line 16 Line 16 Line 16 Line 16 Line 16", X"Line 17 Line 17 Line 17 Line 17 Line 17 Line 17 Line 17 Line 17 Line 17", X"Line 18 Line 18 Line 18 Line 18 Line 18 Line 18 Line 18 Line 18 Line 18", X"Line 19 Line 19 Line 19 Line 19 Line 19 Line 19 Line 19 Line 19 Line 19", X"Line 20 Line 20 Line 20 Line 20 Line 20 Line 20 Line 20 Line 20 Line 20", X"Line 21 Line 21 Line 21 Line 21 Line 21 Line 21 Line 21 Line 21 Line 21", X}; X Xmain() X{ X double do_mapping(); X double do_ansi(); X double a, m; X X init_mapping(); X X raw(); X (void) do_ansi(1); X (void) do_mapping(1); X noraw(); X X a = do_ansi(0); X m = do_mapping(0); X X printf("\n"); X printf("Ansi: %f scrolls/second\n", a); X printf("Mapped: %f scrolls/second\n", m); X} X Xdouble Xdo_mapping(man) X{ X int r; X long start, end; X struct tms tms; X int n; X char buf[256]; X X /* Put up 'static' area */ X if (man) X write_screen(1, 1, 0x70, X " Mapped: Manual test - hold <cr> down, 'q' to exit"); X else X write_screen(1, 1, 0x70, X " Mapped: Automatic test "); X for (r = 0; r < SLINES; ++r) X { X write_screen(YOFF+r, XOFF, 0x07, strings[ (r+n) % SLINES ] ); X sprintf(buf, "%*s ", XOFF-3, (r&1) ? "Stuff" : "Fixed"); X write_screen(YOFF+r, 1, 0x70, buf); X write_screen(YOFF+r, XOFF-1, 0x07, " "); X } X X /* Start scrolling the data region */ X if (!man) start = times(&tms); X n = 0; X for (;;) X { X if (man) X { X buf[0] = 0; X read(0, buf, 1); X if (buf[0] == 'q') X break; X } X ++n; X /* Just rewrite the entire scrolling region */ X for (r = 0; r < SLINES; ++r) X { X write_screen(YOFF+r, XOFF, 0x07, X strings[ (r+n) % SLINES ] ); X } X if (!man) X { X end = times(&tms); X if ( end >= (start + CLK_TCK*TESTSECS) ) X break; X } X } X if (man) X return 0; X else X return (double) n / ( ((double)(end-start)) / CLK_TCK); X} X Xdouble do_ansi(man) X{ X int r; X long start, end; X struct tms tms; X int n; X char buf[256]; X X /* Put up 'static' area */ X printf("\033[2J\033[H\033[7m"); X if (man) X printf( X " Ansi: Manual test - hold <cr> down, 'q' to exit"); X else X printf( X " Ansi: Automatic speed test "); X printf("\033[m"); X for (r = 0; r < SLINES; ++r) X { X printf("\033[%d;%dH%s", X YOFF+r, XOFF, strings[ (r+n) % SLINES ] ); X printf("\033[%d;1H\033[7m%*s \033[m ", YOFF+r, XOFF-3, X (r&1) ? "Stuff" : "Fixed"); X } X X /* Start scrolling the data region */ X if (!man) start = times(&tms); X n = 0; X for (;;) X { X if (man) X { X buf[0] = 0; X fflush(stdout); X read(0, buf, 1); X if (buf[0] == 'q') X break; X } X ++n; X /* Delete top line, rewrite fixed stuff */ X printf("\033[%d;1H\033[1M", YOFF); X for (r = 0; r < SLINES; ++r) X printf("\033[%d;1H\033[7m%*s \033[m ", X YOFF+r, XOFF-3, (r&1) ? "Stuff" : "Fixed"); X /* Add new line to bottom, completing region scroll */ X printf("\033[%d;%dH%s", YOFF+SLINES-1, XOFF, X strings[n%SLINES]); X if (!man) X { X end = times(&tms); X if ( end >= (start + CLK_TCK*TESTSECS) ) X break; X } X } X if (man) X return 0; X else X return (double) n / ( ((double)(end-start)) / CLK_TCK); X} X Xinit_mapping() X{ X paddr = (char *) ioctl(0, MAPCONS, 0); X start = (get_crtc(0x0c)<<8) | get_crtc(0x0d); X taddr = paddr + start*2; X} X Xwrite_screen(y, x, a, s) Xchar *s; X{ X register char *p = taddr + (y-1)*160 + ((x-1)<<1); X while (*s) X { X *p++= *s++; X *p++ = a; X } X} X Xget_crtc(n) X{ X struct port_io_arg io; X register int rc; X X io.args[0].dir = OUT_ON_PORT; X io.args[0].port = 0x3d4; X io.args[0].data = n; X io.args[1].dir = IN_ON_PORT; X io.args[1].port = 0x3d5; X io.args[2].port = 0; X io.args[3].port = 0; X rc = ioctl(0, EGAIO, &io); X return (io.args[1].data & 0xff); X} X Xstruct termio old; Xraw() X{ X struct termio new; X ioctl(0, TCGETA, &old); X new = old; X new.c_lflag &= ~(ECHO|ICANON); X new.c_cc[VMIN] = 1; X new.c_cc[VTIME] = 0; X ioctl(0, TCSETA, &new); X} Xnoraw() X{ X ioctl(0, TCSETA, &old); X} END_OF_FILE if test 5463 -ne `wc -c <'sw.c'`; then echo shar: \"'sw.c'\" unpacked with wrong size! fi # end of 'sw.c' fi echo shar: End of shell archive. exit 0 -- Rick Richardson - PC Research, Inc., uunet!pcrat!rick, (201) 389-8963