d88-mbe@sm.luth.se (Michael Bergman) (05/02/90)
space@ncc1701.sub.org (Lars Soltau) writes: >why does the stupid thing only run on a 80*25 window/screen? Hm? I have a >704*282 pixels big Workbench screen and I bloody well expect any professional >software to not stuff me into any NTSC frame. >(minor flame off) >Sorry for the harsh words, but I've been pissed about this a lot of times with >quite a lot of different programs. It can't be that difficult to make use of >big screens, can it now? Come on, US programmers, show that you're >professional. Lots of you have proven it is possible. Well, I for one am convinced that JRComm 1.0 will be great. It's fast and has *lots* of options and modes. However, just like Lars, I'm getting very tired of all these NTSC frames that US programs use all the time. I know it's easy to check if the machine is PAL or NTSC. I don't want to have an unused stripe at the bottom of my screen... So come on guys: when you write a program, make the screen 255 high if it's a PAL machine and leave the 200-line screens for the inferior NTCS mode. Mike -- Michael Bergman Internet: d88-mbe@sm.luth.se // Dept. of Comp. Eng. BITNET: d88-mbe%sm.luth.se@kth.se \X/ U of Lulea, SWEDEN ARPA: d88-mbe%sm.luth.se@ucbvax.berkeley.edu UUCP: {uunet,mcvax}!sunic.se!sm.luth.se!d88-mbe
space@ncc1701.sub.org (Lars Soltau) (05/03/90)
In article <1352@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes: > Well, JR-Comm 1.0 will now inherit the size of the Workbench screen for > determining row and column sizes. Glad to hear that. Since that was the only thing that bothered me, I am now looking forward to the 1.0 release. > Well, the problem here is that ANSI (VT100 & IBM) "know" only 80*25. If > there's some sort of bent variation to take advantage of a PAL display, I've > yet to hear about it. Well, I took the vt100 definition file of a PC running ix/386 (I think it was /usr/lib/termlib/v/vt100 or so) and searched for $50 (80). This byte I changed into $54 (84). Then I looked for $19 (25) and changed it to 33 or so. Voila, I had a Unix system with 33*84 characters. MicroEmacs 3.10, vi, elm, more, nethack all used the additional rows and columns. >>BTW, if I were you, I'd even give the user the choice whether or not the >>terminal window should be borderless. > > Just like MicroEMACS on the Extras disk, JR-Comm was "meant" to be run in > it's own screen. Borders are useless in that instance... Yes, that's true. But an option to run it in a window would be nice. This Amiga habit of opening new screens for everything (even editors!) reflects that the Amiga screen is way to small for a real GUI. Nevertheless, I hope I'll see 1.0 soon. -- Lars Soltau bang: <insert ridiculously long path here> BIX: --no bucks-- smart: space@ncc1701.stgt.sub.org
bjornk@bula.se (Bjorn Knutsson) (05/03/90)
In article <892@tau.sm.luth.se> d88-mbe@sm.luth.se (Michael Bergman) writes: >[Stuff deleted] > >However, just like Lars, I'm getting very tired of all these NTSC frames that >US programs use all the time. I know it's easy to check if the machine is PAL >or NTSC. I don't want to have an unused stripe at the bottom of my screen... >So come on guys: when you write a program, make the screen 255 high if it's >a PAL machine and leave the 200-line screens for the inferior NTCS mode. Just do what I do, keep bugging the authors until they fix it. (Right, Marco? :-) Not adapting to PAL screens where appropriate is a bug. Actually, I belive software should adapt to whatever resolution the user has selected as default for his system, regardless if this is a 640*200 NTSC screen or something like the 704*568 I often use. >-- > Michael Bergman Internet: d88-mbe@sm.luth.se > // Dept. of Comp. Eng. BITNET: d88-mbe%sm.luth.se@kth.se >\X/ U of Lulea, SWEDEN ARPA: d88-mbe%sm.luth.se@ucbvax.berkeley.edu > UUCP: {uunet,mcvax}!sunic.se!sm.luth.se!d88-mbe --- Bjorn Knutsson / USENET: bjornk@bula.se or sunic!sics!bula!bjornk Stangholmsbacken 44 / Phone : +46-8-710 7223 S-127 40 SKARHOLMEN / "Oh dear, I think you'll find reality's on the S W E D E N / blink again." -- Marvin The Paranoid Android
papa@pollux.usc.edu (Marco Papa) (05/03/90)
In article <6781@bula.se> Bjorn Knutsson <bjornk@bula.se> writes: >In article <892@tau.sm.luth.se> d88-mbe@sm.luth.se (Michael Bergman) writes: >>[Stuff deleted] >>So come on guys: when you write a program, make the screen 255 high if it's >>a PAL machine and leave the 200-line screens for the inferior NTCS mode. > >Just do what I do, keep bugging the authors until they fix it. (Right, >Marco? :-) Not adapting to PAL screens where appropriate is a bug. Right, right! OK, OK :-) [from a repented NTSC developer] >Actually, I belive software should adapt to whatever resolution the >user has selected as default for his system, regardless if this is a >640*200 NTSC screen or something like the 704*568 I often use. That is quite true, especially when you consider that we can now have NTSC, PAL, morerows, A2024/Viking1, plus all the new ECS screen sizes. I still see a lot of programs that "limit" the size of the window on workbench to 640x400. Not good. Bjorn still hasn't convinced me that I should fill the bottom area with some more features (like in the A-Talk III phonebook) in the PAL version, though :-) -- Marco -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Xerox sues somebody for copying?" -- David Letterman -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
d88-mbe@sm.luth.se (Michael Bergman) (05/03/90)
bjornk@bula.se (Bjorn Knutsson) writes: >Just do what I do, keep bugging the authors until they fix it. (Right, >Marco? :-) Not adapting to PAL screens where appropriate is a bug. >Actually, I belive software should adapt to whatever resolution the >user has selected as default for his system, regardless if this is a >640*200 NTSC screen or something like the 704*568 I often use. There is one small(?) problem here, which Dave Mc Mahan pointed out to me, namely that there aren't really any PAL machines in the US to test the programs on. To write the code is easy. To debug it is difficult. But, basically I agree with Bjorn - especially programs that display graphics (like MandelVroom and all the other Mandelbrot programs) should detect PAL machines and use all scan lines avalible! In this case I too think that not doing so is a bug. Mike -- Michael Bergman Internet: d88-mbe@sm.luth.se // Dept. of Comp. Eng. BITNET: d88-mbe%sm.luth.se@kth.se \X/ U of Lulea, SWEDEN ARPA: d88-mbe%sm.luth.se@ucbvax.berkeley.edu UUCP: {uunet,mcvax}!sunic.se!sm.luth.se!d88-mbe
papa@pollux.usc.edu (Marco Papa) (05/04/90)
In article <895@tau.sm.luth.se> d88-mbe@sm.luth.se (Michael Bergman) writes: >bjornk@bula.se (Bjorn Knutsson) writes: ||Just do what I do, keep bugging the authors until they fix it. (Right, ||Marco? :-) Not adapting to PAL screens where appropriate is a bug. ||Actually, I belive software should adapt to whatever resolution the ||user has selected as default for his system, regardless if this is a ||640*200 NTSC screen or something like the 704*568 I often use. | |There is one small(?) problem here, which Dave Mc Mahan pointed out to me, |namely that there aren't really any PAL machines in the US to test the programs |on. To write the code is easy. To debug it is difficult. Not difficult at all. I did it and debugging it was trivial. How did I do it? I run "morerows" . If you can get it to run with morerows, and properly recompute rows and cols, it'll work with any size. -- Marco -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Xerox sues somebody for copying?" -- David Letterman -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
ridder@elvira.enet.dec.com (Hans Ridder) (05/04/90)
In article <1352@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes: > Well, the problem here is that ANSI (VT100 & IBM) "know" only 80*25. If > there's some sort of bent variation to take advantage of a PAL display, I've > yet to hear about it. You're confusing the ANSI *standard* with the VT100 and IBM *implementation*. The ANSI standards (X3.41 and X3.64) make no mention of display size. It is prefectly legal (standards wise) to have a screen 80x25, 80x66, 132x66, 132x24, 8x10, or any other size you like. However, most software is too lame to understand that terminal screens come in different sizes, so it is best to have a screen at least 80x24 in size. In summary, it is possible to have a "PAL" size display (whatever that works out to be), but it *may* not be very usefull. > -jack- -hans ======================================================================== Hans-Gabriel Ridder Digital Equipment Corporation ridder@elvira.enet.dec.com Customer Support Center ...decwrl!elvira.enet!ridder Colorado Springs, CO
bjornk@bula.se (Bjorn Knutsson) (05/04/90)
In article <895@tau.sm.luth.se> d88-mbe@sm.luth.se (Michael Bergman) writes: >bjornk@bula.se (Bjorn Knutsson) writes: > >>Just do what I do, keep bugging the authors until they fix it. (Right, >>Marco? :-) Not adapting to PAL screens where appropriate is a bug. >>Actually, I belive software should adapt to whatever resolution the >>user has selected as default for his system, regardless if this is a >>640*200 NTSC screen or something like the 704*568 I often use. > >There is one small(?) problem here, which Dave Mc Mahan pointed out to me, >namely that there aren't really any PAL machines in the US to test the programs >on. To write the code is easy. To debug it is difficult. Well, that shouldn't be a problem since the SFA allows you to switch between PAL and NTSC on any machine. And if you are developing commercial software that does anything related to keyboard, screen etc you should get yourself a European beta-tester. It's painful to see products that really seems to be useful fail because they didn't think about the differences in resolutions, keymaps and handling of national characters. >-- > Michael Bergman Internet: d88-mbe@sm.luth.se > // Dept. of Comp. Eng. BITNET: d88-mbe%sm.luth.se@kth.se >\X/ U of Lulea, SWEDEN ARPA: d88-mbe%sm.luth.se@ucbvax.berkeley.edu > UUCP: {uunet,mcvax}!sunic.se!sm.luth.se!d88-mbe --- Bjorn Knutsson / USENET: bjornk@bula.se or sunic!sics!bula!bjornk Stangholmsbacken 44 / Phone : +46-8-710 7223 S-127 40 SKARHOLMEN / "Oh dear, I think you'll find reality's on the S W E D E N / blink again." -- Marvin The Paranoid Android
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (05/04/90)
In <1362@faatcrl.UUCP>, jprad@faatcrl.UUCP (Jack Radigan) writes: > >I'm not confusing anything. Although VT100 and IBM are implementations, >they're standards in their own right due to widespread use. > >What I'm refering to is that fact that these two emulations are based on a >video display system that uses a fixed format of 80*25 and is non-standard >with respect to NTSC and PAL. > >Taking it a bit further, the CUP and HVP ANSI sequences for cursor position >denote 25 lines when talking about a VT100 and an IBM screen. A PAL Amiga >allows for more than 25 lines, so this sequence is effectively broke in this >situation. > >Now, my question is what sort of work around is there for the case where the >system you connect with can't deal with a VT100 or and IBm that has more than >25 lines? > >Is there a _right_ way to handle this sort of situation? There are probably several. If you allow the screen to be as big as possible, you will usually find that either the system you connect with will use it or it won't. If it won't, it will just use whatever portion of the screen that is handled by the host. To put it another way, if it thinks the cursor can't go beyond line 25, it will never try to put it there, and if it does, the program putting it there is broken. For the safest operation, in order to handle hosts that mess up by assuming the fixed size, my approach would be to allow any sized screen, but with a 'detent' settting at 80*25 (shouldn't that be 24?). -larry -- NeXT. The hardware makes it a PC. The software makes it a workstation. The units shipped makes it a mainframe. -=stolen from Hazy=- +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
jprad@faatcrl.UUCP (Jack Radigan) (05/05/90)
space@ncc1701.sub.org (Lars Soltau) writes: >Well, I took the vt100 definition file of a PC running ix/386 (I think it was >/usr/lib/termlib/v/vt100 or so) and searched for $50 (80). This byte I changed >into $54 (84). Then I looked for $19 (25) and changed it to 33 or so. Voila, >I had a Unix system with 33*84 characters. MicroEmacs 3.10, vi, elm, more, >nethack all used the additional rows and columns. I've already been reminded (painfully :-)) about using the termcap entry to modify it. Anyways, as mentioned before, JR-Comm now uses the Workbench size for all its screens. ^^^ |-- (It's not as late this time John... <grin>) -jack-
jprad@faatcrl.UUCP (Jack Radigan) (05/05/90)
ridder@elvira.enet.dec.com (Hans Ridder) writes: >In article <1352@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes: >> Well, the problem here is that ANSI (VT100 & IBM) "know" only 80*25. If >> there's some sort of bent variation to take advantage of a PAL display, I've >> yet to hear about it. >You're confusing the ANSI *standard* with the VT100 and IBM >*implementation*. The ANSI standards (X3.41 and X3.64) make no >mention of display size. It is prefectly legal (standards wise) to >have a screen 80x25, 80x66, 132x66, 132x24, 8x10, or any other size >you like. However, most software is too lame to understand that >terminal screens come in different sizes, so it is best to have a >screen at least 80x24 in size. I'm not confusing anything. Although VT100 and IBM are implementations, they're standards in their own right due to widespread use. What I'm refering to is that fact that these two emulations are based on a video display system that uses a fixed format of 80*25 and is non-standard with respect to NTSC and PAL. Taking it a bit further, the CUP and HVP ANSI sequences for cursor position denote 25 lines when talking about a VT100 and an IBM screen. A PAL Amiga allows for more than 25 lines, so this sequence is effectively broke in this situation. Now, my question is what sort of work around is there for the case where the system you connect with can't deal with a VT100 or and IBm that has more than 25 lines? Is there a _right_ way to handle this sort of situation? -jack-
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (05/05/90)
In <1366@faatcrl.UUCP>, jprad@faatcrl.UUCP (Jack Radigan) writes: >lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: > >>For the safest operation, in order to handle hosts that mess up by assuming the >>fixed size, my approach would be to allow any sized screen, but with a 'detent' >>settting at 80*25 (shouldn't that be 24?). > > Hmmm, hadn't thought of it that way before. 24? You're fogetting the status >line.... Is the status line part of the normal screen as seen by the host? ie. does the host explicitly write out the status line itself in the same way that it writes out the rest of the lines? If not, I would not consider it part of the 'screen'. You will, of course, have to have room for it there, but for communication purposes, it doesn't exist, so you only allow the host to muck with a 24 line screen. If it is treated as a normal line by the host, then ignore the above comments. -larry -- NeXT. The hardware makes it a PC. The software makes it a workstation. The units shipped makes it a mainframe. -=stolen from Hazy=- +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
jimb@faatcrl.UUCP (Jim Burwell) (05/06/90)
space@ncc1701.sub.org (Lars Soltau) writes: >Well, I took the vt100 definition file of a PC running ix/386 (I think it was >/usr/lib/termlib/v/vt100 or so) and searched for $50 (80). This byte I changed >into $54 (84). Then I looked for $19 (25) and changed it to 33 or so. Voila, >I had a Unix system with 33*84 characters. MicroEmacs 3.10, vi, elm, more, >nethack all used the additional rows and columns. Not that it really matters, but I've found a much easier way to do that under SunOS via the stty command. Simply: stty rows <#rows> columns <#columns> And "voila", you've just set your screen to whatever size you want.. I don't know if that applies to other flavors of Unix, but it works under SunOS. Much cleaner than modifying the termcap... C'ya, Jim -- James S. Burwell UUCP: ...!rutgers!faatcrl!jimb Internet: jimb@faatcrl.UUCP "The Maker is the one who is part of what he makes." - The Redbird, from _The Tales of Alvin Maker_
jprad@faatcrl.UUCP (Jack Radigan) (05/06/90)
lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >There are probably several. If you allow the screen to be as big as possible, >you will usually find that either the system you connect with will use it or >it won't. If it won't, it will just use whatever portion of the screen that is >handled by the host. To put it another way, if it thinks the cursor can't go >beyond line 25, it will never try to put it there, and if it does, the program >putting it there is broken. That part's obvious. What happens more often than not though is that you probably will have a few screen scrolls in there (more so with IBM ANSI than VT100), so what you end up with is some garbage along the bottom and right sides after a few cursor repositioning sequences have occured. >For the safest operation, in order to handle hosts that mess up by assuming the >fixed size, my approach would be to allow any sized screen, but with a 'detent' >settting at 80*25 (shouldn't that be 24?). Hmmm, hadn't thought of it that way before. 24? You're fogetting the status line.... -jack-
papa@pollux.usc.edu (Marco Papa) (05/08/90)
In article <1494@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >In <1366@faatcrl.UUCP>, jprad@faatcrl.UUCP (Jack Radigan) writes: >> Hmmm, hadn't thought of it that way before. 24? You're fogetting the status >>line.... > >Is the status line part of the normal screen as seen by the host? ie. does the >host explicitly write out the status line itself in the same way that it writes >out the rest of the lines? If not, I would not consider it part of the >'screen'. You will, of course, have to have room for it there, but for >communication purposes, it doesn't exist, so you only allow the host to muck >with a 24 line screen. If it is treated as a normal line by the host, then >ignore the above comments. Of course Larry is the one that's right. VT100s do not have a status line that is addressable from the host. Therefore they are simply 80x24 or 132x24 terminals. Same for VT52. The H19, though has a status line, but it has its own private sequences to write on it. Termcap and Terminfo have no concept of a status line. As such, 'status lines' are NOT part of a screen. They CAN'T be scrolled with the rest of the screen. ANSI doesn't have a concept of status line AT ALL, so forget about status lines in general. -- Marco -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Xerox sues somebody for copying?" -- David Letterman -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
new@udel.EDU (Darren New) (05/08/90)
In article <24552@usc.edu> papa@pollux.usc.edu (Marco Papa) writes: >Termcap and Terminfo have no concept of a status line. Check your man pages. Both have status-line parameters, including has-status, enable-status, disable-status, escapes-ok-on-status, etc. >ANSI doesn't have a concept of status line AT ALL, so forget about status lines >in general. I would find this hard to believe, since terminals with status lines were out before ANSI standardized the escape sequences. I would go back to the original ANSI doc to check, myself. -- Darren
papa@pollux.usc.edu (Marco Papa) (05/08/90)
In article <18781@estelle.udel.EDU> new@ee.udel.edu (Darren New) writes: >In article <24552@usc.edu> papa@pollux.usc.edu (Marco Papa) writes: >>Termcap and Terminfo have no concept of a status line. > >Check your man pages. Both have status-line parameters, including >has-status, enable-status, disable-status, escapes-ok-on-status, etc. Go back to the context: VT100 and ANSI (both Amiga and IBM PC ANSI.SYS, which is what terminal emulators emulate). VT100 termcaps and erminfos do not use the status line features. >>ANSI doesn't have a concept of status line AT ALL, so forget about status lines >>in general. > >I would find this hard to believe, since terminals with status lines were out >before ANSI standardized the escape sequences. I would go back to the >original ANSI doc to check, myself. -- Darren Again, the original posting by Jack mentioned VT100 and ANSI as implemented by the Amiga ISO/ANSI and the IBM PC ANSI.SYS devices. Neither one has a concept of status line. So I'll repeat, as far as terminal emulators that do VT100 or emulate the features of the Amiga ISO/ANSI or IBM ANSI.SYS drivers, 'status lines' do not apply. For all practical applications, status lines have hardly ANY use whatsoever in the above contexts. -- Marco -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Xerox sues somebody for copying?" -- David Letterman -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (05/08/90)
In <1370@faatcrl.UUCP>, jprad@faatcrl.UUCP (Jack Radigan) writes: > >More to the point with regards to cursor positioning, I *do* range checking >based on the legal (from JR-Comm's standpoint) size of the display. What >I'm still fuzzy on is if I should allow a non-standard display (morerow'd or >PAL) go past the *normal* size since that allows the possibility of garbage >accumulating along the outter edges of the legal (from the remotes standpoint) >display size. Absolutely! To do otherwise is unAmiga. Why, it's positively.... <shudder> Apple-ish. :-) Seriously, not all sessions will leave crud along the edge, or even make use of the various capabilities of the emulator. When I dial in to work, I use a VT100 emulator only when I think I am going to need its capabilities for the one or two programs that actually require it. When it comes time to do other thngs, I can enable a larger (in rows/columns) screen with impunity, and get the use of it. It is not the software author's job to decide for the user what is acceptable in this regard. Limiting a program needlessly because of a possibility of unsightliness when the program is misused takes away a degree of freedom of choice, and doing so when there exists the possibility (on some systems) of using the oversized screen with full VT100 functionality is even worse. All of the above is IMHO, of course. -larry -- NeXT. The hardware makes it a PC. The software makes it a workstation. The units shipped makes it a mainframe. -=stolen from Hazy=- +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
jprad@faatcrl.UUCP (Jack Radigan) (05/09/90)
lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >Is the status line part of the normal screen as seen by the host? ie. does the >host explicitly write out the status line itself in the same way that it writes >out the rest of the lines? If not, I would not consider it part of the >'screen'. You will, of course, have to have room for it there, but for >communication purposes, it doesn't exist, so you only allow the host to muck >with a 24 line screen. If it is treated as a normal line by the host, then >ignore the above comments. I've heard of a few systems that use the status line for their own use, but they're certainly in the minority. What I *was* trying to say that in both cases you have a 25 line display, with the 25th line being optional, either part of the display or the (as you pointed out) *local* status line. More to the point with regards to cursor positioning, I *do* range checking based on the legal (from JR-Comm's standpoint) size of the display. What I'm still fuzzy on is if I should allow a non-standard display (morerow'd or PAL) go past the *normal* size since that allows the possibility of garbage accumulating along the outter edges of the legal (from the remotes standpoint) display size. I hope I'm being a bit more clear on this. -jack-