jb10320@uxa.cso.uiuc.edu (Jawaid Bazyar) (09/05/89)
A big hello to the communications world. I've decided I'm going to take it upon myself to rid the Apple // world of its ProTerm infestation once and for all. While ProTerm is an OK program, the author I believe has decided to NOT make any newer versions. ProTerm has many bugs and user-interface problems, and its transfer protocols are lazy interpretations of the standards. What I've got in mind right now will be GS-specific, mainly because it will be 100 times easier to develop a good application (the tools available for GS/OS are far superior to the 8-bit ones). As soon as the GS version is done, I will see what will fit nicely into a 48K or 64K package for use on older ]['s, and implement it probably entirely in 6502. What I'm looking for is suggestions. What you want, what you don't want, what kind of user interface it should have (I'm looking at a text implementation of mac-like menus), anything at all you like and don't about the current generation of communications programs. Given enough input from users, I should be able to make a truly great program (given enough time, too). So, let's hear it. Tired of ProTerm? Speak Up! =============================================================================== jawaid bazyar jb10320@uxa.cso.uiuc.edu Junior/Computer Engineering UIUC Seepage from deep,black,brittle experiments which failed and transformations too hard to find. "I was overcome and turned to Red." Duster's dust became the sale. Lucifer the light. A restless motion came to move and then subside. In endless knocking at the door- it's time. TYRANNY & MVTATION. TYRANNY & MVTATION.
shatara@memit.dec.com (Chris Shatara) (09/06/89)
> > What I'm looking for is suggestions. What you want, what you don't want, >what kind of user interface it should have (I'm looking at a text implementation >of mac-like menus), anything at all you like and don't about the current >generation of communications programs. Given enough input from users, I >should be able to make a truly great program (given enough time, too). A program I use daily on an MSDos machine (no boo's please :-) is a program called LCterm. It is a full bodied comm program which among others has the following very useful features: 1) VT100 emulation 2) Kermit is available through it. 3) Has the ability to run scripts. Very important as this feature allows me to automatically dial in to work and log me in. 4) The ability to create (and turn on/off) a log file. These are the key features I would want. You asked! /chris ============================================================================= | Chris Shatara | Internet: shatara@memit.dec.com | | | shatara@memit.enet.dec.com | | Opinions expressed are | DEC Easynet: memit::shatara | | mine and mine only! | UUCP: ...!decwrl!memit!shatara | =============================================================================
RXBROWN@UALR.BITNET ("MR.FANTASTIC") (09/06/89)
To Jawaid Bazyar.... Lets start with Xmodem, Ymodem, Kermit (batch), Zmodem. What about ansi graphics? And nice windows. If you can I would like to know the file size comming or going across. And emulation for everything, capable of using any modem. Let me get into the directory that I want to send from or receive to. I don't want to have to have the program disk in my (one) drive at all times. If you are really nice you can let me view and edit text files, create subdirectories, delete files, and of course print files. Thats all I can think of right now, but I may have more later. Robert Brown BITNET: RXBROWN@UALR ALPE: ROBPHD Users are losers and losers are users......
dseah@wpi.wpi.edu (David I Seah) (09/06/89)
> What I'm looking for is suggestions. What you want, what you don't >want, what kind of user interface it should have (I'm looking at a >text implementation of mac-like menus), anything at all you like and >don't about the current generation of communications programs. Given >enough input from users, I should be able to make a truly great >program (given enough time, too). Some of the great things about ProTERM: 1) Boots up fast 2) Gigantic scroll-back buffer 3) flexible cut/capture/paste/edit 4) Paged Text File dump What I'd like: 1) Better transfer protocol handling 2) More informative transfer stats. Most IBM comm programs tell you all kinds of things while transfers are going on. 3) Character editing LANGUAGE for the editor, so you can custom process funny downloads 4) Gigantic Copy/Edit buffer 5) Built in macros 6) ProTERM Special Emulation built in 7) Key/Screen code remapping for custom terminal emulation 8) Auto-wrap 9) Command Line Interpreter for ProDOS 10) Hooks for users to patch into the telecomm routines directly 11) SPEED and KEYBOARD equivalents for these menus you are talking about...I hate slogging through menus to find options. 12) Special Character support Dave Seah (dseah@wpi.wpi.edu)
SEWALL@UCONNVM.BITNET (Murph Sewall) (09/06/89)
On Tue, 5 Sep 89 16:42:20 GMT you said: > What I've got in mind right now will be GS-specific, mainly because it >will be 100 times easier to develop a good application (the tools available >for GS/OS are far superior to the 8-bit ones). As soon as the GS version is >done, I will see what will fit nicely into a 48K or 64K package for use >on older ]['s, and implement it probably entirely in 6502. Reinventing wheels is okay if you wish to amuse yourself. I'm of the impression that ZLink already is a pretty good alternative to ProTerm (I'm wedded to using Kermit myself). There would be a lot of happy campers out in netland if you could find a way to convert/imbed/hack(?) Kermit-65 into a SYS file (how about reducing it to a desk accessory ;-) Or, how about 1) Tektronics emulation, 2) Dec 240 (is that the number of the full color graphics terminal?) emulation, 3) APL font set... How about file transfer in background (the easy stuff's been done; how about something truly *unusual*)? Murph Sewall Vaporware? ---> [Gary Larson returns 1/1/90] Prof. of Marketing Sewall@UConnVM.BITNET Business School sewall%uconnvm.bitnet@cunyvm.cuny.edu [INTERNET] U of Connecticut {psuvax1 or mcvax }!UCONNVM.BITNET!SEWALL [UUCP] (203) 486-5246 [FAX] (203) 486-2489 [PHONE] 41 49N 72 15W [ICBM] The opposite of artificial intelligence is genuine stupidity! -+- I don't speak for my employer, though I frequently wish that I could (subject to change without notice; void where prohibited)
SPLECRONE@UALR.BITNET (Psychedelia) (09/06/89)
I would like to see a terminal program that does this-
(1) Emulates ansi, vt102, vt 220 terminals (in color)
(2) Supports XModem batch, REAL Y-Modem, ZModem and Zmodem batch,
Sea-Link...
(3) Has an alarm for time....
(4) Turns up the volume of the speaker for just this program.
(5) Has a split screen option...
(6) Supports some type of function keys and macros.
Too much?? Well, you asked for it!! ;>SEWALL@UCONNVM.BITNET (Murph Sewall) (09/06/89)
On Tue, 5 Sep 89 23:50:35 GMT you said: >A program I use daily on an MSDos machine (no boo's please :-) is a >program called LCterm. It is a full bodied comm program which among >others has the following very useful features: > > 1) VT100 emulation > > 2) Kermit is available through it. > > 3) Has the ability to run scripts. Very important as this feature > allows me to automatically dial in to work and log me in. > > 4) The ability to create (and turn on/off) a log file. Oddly enough, a program which I use daily on my Apple //e (and //c) ALSO has ALL (100%) of those features! The only thing you may not like about it is that, so far, it only runs under ol' DOS 3.3. It's Dick Atlee's Kermit-A2 (also p.d. but I seem to have buried the documentation on a desk that looks like the the 'Perfesser's in Shoe) - ask Dick <Atlee@UMDC.BITNET> (he's alledged to be working on a port to ProDOS). Dick's script language is VERY easy to learn and use, and it gets me though a multiplexer, and a minicomputer interface on the way to connecting with the host. Dick also provides for redefinition of keys, which I find very nice. The Kermit transfers allow for "wildcard" characters (transfer a whole disk full of files at once) - it's the code that Ted Medin adapted for Kermit-65. Murph Sewall Vaporware? ---> [Gary Larson returns 1/1/90] Prof. of Marketing Sewall@UConnVM.BITNET Business School sewall%uconnvm.bitnet@cunyvm.cuny.edu [INTERNET] U of Connecticut {psuvax1 or mcvax }!UCONNVM.BITNET!SEWALL [UUCP] (203) 486-5246 [FAX] (203) 486-2489 [PHONE] 41 49N 72 15W [ICBM] The opposite of artificial intelligence is genuine stupidity! -+- I don't speak for my employer, though I frequently wish that I could (subject to change without notice; void where prohibited)
aragorn@blake.acs.washington.edu (Michael Owen) (09/06/89)
In article <1945@garcon.cso.uiuc.edu> jb10320@uxa.cso.uiuc.edu (Jawaid Bazyar) writes: > > I've decided I'm going to take it upon myself to rid the Apple // world >of its ProTerm infestation once and for all. While ProTerm is an OK program, >the author I believe has decided to NOT make any newer versions. ProTerm >has many bugs and user-interface problems, and its transfer protocols are >lazy interpretations of the standards. I use ProTERM daily. It has just about all of the features I want in a term program, although many of them are clumsily implemented. Examples: * ProTERM walks all over any RAM you have. A friend using Glen Bredon's CACHE program with ProTERM found some *serious* problems with the combination. The volume bitmap and blocks 0 and 1 of his hard drive were wiped out with scrollback information one time! * Non-configurable editor/scrollback buffers. It's been mentioned before. I've got a 45k editor and a 960k scrollback buffer. A little overkill, if you ask me. * Miscellaneous scrollback bugs. I have hung/crashed/frozen ProTERM by hitting a weird combination of keys in scrollback too many times to mention. One time I was dropped to the monitor, and after I entered a CTRL-C to get to BASIC, a CALL-1403 brought ProTERM back online--and I did this repeatedly during the same call! * More drivers. Where's the Datalink 2400? I'm stuck using the USRobotics 2400 driver. * Smarter file interface. When I want to switch to my 3.5" disk, I hate getting a couple of grinding sounds from my DuoDisk as they're scanned. > What I've got in mind right now will be GS-specific [...] Alas, very bad for us IIe/IIc owners! >jawaid bazyar jb10320@uxa.cso.uiuc.edu Junior/Computer Engineering UIUC ______________________________________________________________________________ /> The Broken Blade Aragorn III (Michael Owen) /< ________ ______________ Inet: aragorn@blake.acs.washington.edu C=====[*>_______/|______________> ProLine: aragorn@pro-ruby \< Starfleet HQ: (206) 783-5589 3/12/24 _______\>_____"Ai na vedui!"__________________________________________________
lhaider@pro-sol.cts.com (Lawrence Haider) (09/07/89)
Network Comment: to #10749 by garcon!uxa.cso.uiuc.edu!jb10320@uxc.cso.uiuc.edu
> So, let's hear it. Tired of ProTerm? Speak Up!
Give it the ease of set-up of ProTerm and the ease of use of EasyLink and
you've got a buyer right here. Throw in some bells and wistles, like Kermit,
Sealink, R-Modem file transfers; add flexible dialing abilities; a dash of
good file handling capabilities, ad infinitum... I've got my credit card
ready! How's your program coming along? :)
Laer
lhaider@pro-solSPLECRONE@UALR.BITNET (Psychedelia) (09/07/89)
And another thing on file transfers--an estimation of time to u/l or d/l.
lhaider@pro-sol.cts.com (Lawrence Haider) (09/07/89)
Network Comment: to #10769 by mailrus!ulowell!m2c!wpi!dseah@ames.arc.nasa.gov > What I'm looking for is suggestions. What you want, what you don't >want, what kind of user interface it should have (I'm looking at a >text implementation of mac-like menus), anything at all you like and >don't about the current generation of communications programs. Given >enough input from users, I should be able to make a truly great >program (given enough time, too). One other thing I'd like to see added, although you couldn't do it in text mode on the Apple. ANSI color graphics are somewhat of a standard on MS-DOS machines, and a lot of their BBSs support it. It is more functional than ProTerm Special and allows more freedom than what we Apple user's currently have. If done in graphics mode, it would be slower; but it sure would be nice to have! Laer
emerrill@tippy.uucp (09/07/89)
/* Written 11:42 am Sep 5, 1989 by jb10320@uxa.cso.uiuc.edu in tippy:apple */ >I've decided I'm going to take it upon myself to rid the Apple // >world of its ProTerm infestation once and for all. Since it's going to be GS specific, how about making a ProTERM-like program in a desk accessory? Something that would be _completely_ able to function in the background. But we still want TEXT only...graphics are just too slow for telecommunications. :-) _________________________________________________________ | | | Eric Merrill tippy!emerrill@newton.physics.purdue.edu | | | | Disclaimer: | | If you think I'm serious, that's your problem! | |_________________________________________________________|
kreme@netcom.UUCP (Kreme The Immortal) (09/07/89)
In article <766@mountn.dec.com> shatara@memit.dec.com (Chris Shatara) writes: >> >> What I'm looking for is suggestions. What you want, what you don't want, >>what kind of user interface it should have (I'm looking at a text >>implementation >>of mac-like menus), anything at all you like and don't about the current >>generation of communications programs. Given enough input from users, I >>should be able to make a truly great program (given enough time, too). > >A program I use daily on an MSDos machine (no boo's please :-) is a >program called LCterm. It is a full bodied comm program which among >others has the following very useful features: > > 1) VT100 emulation > > 2) Kermit is available through it. > > 3) Has the ability to run scripts. Very important as this feature > allows me to automatically dial in to work and log me in. > > 4) The ability to create (and turn on/off) a log file. > >These are the key features I would want. You asked! > But these are ALL available with Proterm, and all but vt100 are available with Talk is Cheap. I would like to see full vt emulation, including 220. i would also like th ability to create new terminal emulations easily. I like the scripting abilities of Talk is Cheap more than Proterm, but I like Proterm's menus. I like the way Proterm handels scrollback vs. copy buffer, but I don't like that they are noit adjustable. Proterm is also too expensive. -- | apple!netcom!kreme |All the towns in America and I have to move to | |The real cycle you're |the Bermuda Triangle. Nightmare on Elm Street | |working on is a cycle |Why do they fear the sunless lands? It is as | |called yourself. |natural to die as it is to be born. Sandman | | Robert Pirsig |WARNING:THESE OPINIONS ARE HARMFUL IF SWALLOWED|
WPW100@PSUVM.BITNET (Will Wong) (09/08/89)
One thing I'd definitely like to see is the support of KERMIT extended packets. Will
blochowi@rt20.cs.wisc.edu (Jason Blochowiak) (09/08/89)
In article <8909070021.AA03717@trout.nosc.mil> lhaider@pro-sol.cts.com (Lawrence Haider) writes: >Network Comment: to #10769 by mailrus!ulowell!m2c!wpi!dseah@ames.arc.nasa.gov >> What I'm looking for is suggestions. What you want, what you don't >>want, what kind of user interface it should have [...] >One other thing I'd like to see added, although you couldn't do it in text >mode on the Apple. ANSI color graphics are somewhat of a standard on MS-DOS >machines, and a lot of their BBSs support it. It is more functional than >ProTerm Special and allows more freedom than what we Apple user's currently >have. If done in graphics mode, it would be slower; but it sure would be nice >to have! I wrote a terminal program awhile back called "WimpyTerm" - it allowed me (as a ][+ owner) to type/view 40 column lowercase (yeah, I know, there are hardware mods, but that's too easy!) using the HGR screen. I'm sure it wasn't as efficient as possible, but I doubt it was all that bad either, and it had trouble keeping up with 1200 baud. However, it didn't use interrupts (which would've helped). So, I doubt that a double-high-res (which would be necessary for 80 columns) terminal program could sustain a fairly long burst of text without losing stuff, which can be particularly dangerous considering that color commands could be lost (look, ma, it's bright green text, from now 'till I logout!). On the other hand, that was on a 1Mhz ][+ with a 6502 - perhaps it would work out well if it were written as a //gs program that just used the DHR screen. As far as suggestions for a terminal program go: The one thing I haven't seen yet is a transfer protocol that lets you continue with other things normally. As in, while the term program & BBS are (bi-directionally?) exchanging files, you can go on with viewing posts. Basically, the whole thing would just be packeted, with the file data packets length being variable (so that when a key was pressed, the term program could terminate the current file data packet, send the key, and then send the next file data packet). Of course, the whole protocol should be windowed. Granted, this'd be pretty much of a bitch to write, but if it was, it'd be damn nice! Of course, the BBS would need a packet interpreter as a front end to keep the BBS itself from having to deal with the nasty details. Think about it, though - go to the file transfer section first, pick out the files that you want, start sending them, go back to the boards, and start reading. Considering that a fair amount of time is spent reading the posts (I'm a fairly quick reader, and at 2400 bps, I can't keep up with the modem), the posts could be sent in a burst (simple buffering technique - buffer until 1) the buffer is full, or 2) the BBS makes an input request). Well, looks like I went off on a sidetrack there... For a nice terminal program you need: Scripts, macros, file transfers with a continously updated estimated time of transfer (well, not continously, but not "well, we'll guess, and use the guess throughout", but "well, we'll guess, but then we'll modify the original guess by what actually happens"), things like automatic on-line charge billing (x for first minute, y for each additional) calculation, with a possible alarm for going past a certain amount. It seems that there are only a few terminal emulation types that you HAVE to support (perhaps Datamedia 1500 or ProTERM special for backwards compatibility, VT-52, VT-100 or ANSI, there are some others, but...). Inclusion in the scripts of something to allow for scheduled calling. I think that's really all you need, and the rest is implementing it smoothly. Jason
shankar@damavand.SRC.Honeywell.COM (Subash Shankar) (09/08/89)
Well, for my contribution to the wishlist, I'd like to see the following
- scrollback like Proterm, but better integrated with the editor, and
OS, in the sense that you can trivially move stuff back and forth
between these sources.
- background processing for everything. This includes background Dloads,
being able to edit a file while the normal screen output is proceeding
(though you wouldn't be able to see that stuff until you get out of the
editor off course), etc. Ideally, I'd like multiple windows for each
of these in a desktop environment (I think 5.0 and TWGS make that env.
fast enough), but you asked for a text environment so you'd have
all the screens being updated in background, though you wouldn't see
the results except for the active screen.
- Emulation of VT100, VT52, and Proterm Special at least, more advanced
VTxx graphics modes if hardware allows for it (even if it means needing
horizontal and/or vertical scrolling). At least one standard graphics
terminal supported by CAD software (even if the GS's resolution isn't
enough without scrolling).
- Kermit, XModem, YModem, ZModem
- Macros including "learn" feature
---
Subash Shankar Honeywell Systems & Research Center
voice: (612) 782 7558 US Snail: 3660 Technology Dr., Minneapolis, MN 55418
shankar@src.honeywell.com srcsip!shankardseah@wpi.wpi.edu (David I Seah) (09/08/89)
In article <89250.151500WPW100@PSUVM.BITNET> WPW100@PSUVM.BITNET (Will Wong) writes: >One thing I'd definitely like to see is the support of KERMIT >extended packets. What are KERMIT extended packets?
nuglaesk@ndsuvax.UUCP (Brian Glaeske) (09/08/89)
In article <3838@wpi.wpi.edu> dseah@wpi.wpi.edu (David I Seah) writes: > > What I'm looking for is suggestions. What you want, what you don't >want, what kind of user interface it should have (I'm looking at a >text implementation of mac-like menus), anything at all you like and >don't about the current generation of communications programs. Given >enough input from users, I should be able to make a truly great >program (given enough time, too). I would like to see Zmodem transfer implemented. \ nuglaesk@plains.NoDak.edu [Internet] \\ ____ nuglaesk@ndsuvax [BITNET ] \ \\\ / \ __----// uunet!ndsuvax!nuglaesk [UUCP ] \ \\| o \' ` _/ \ | | o |/ Bill for Prez \ \ \____( )__/ in `--_ -,' \' 1992 \_ | . | .|----\ Brian Glaeske | . | .| ------ P.O. Box 5764 _ _-| . /\___/ \ Fargo, ND 58105 | `----' | \ / | | \ HECN BBS! (701) 237-7790 choose class 20 _ / --
rat@madnix.UUCP (David Douthitt) (09/08/89)
| What I'm looking for is suggestions. What you want, what you don't | want, what kind of user interface it should have (I'm looking at a | text implementation of mac-like menus), For starters, DON'T use a menu... at least, have the ability to use a command line or an interface like Ascii Express (in my opinion, STILL the best program for the Apple series... *ALL* Apples!) | anything at all you like and | don't about the current generation of communications programs. Given | enough input from users, I should be able to make a truly great | program (given enough time, too). What Ascii Express has that I like - o Emulations o Direct Access and Control of External Modems o Macros o Help o Support for the AppleCat External Port o MINIMAL editor o Uploads/Downloads o Apple II+ Support What I wish it had - o VT100 Emulation o Macro command for "Run at time xxxx" o Support of YMODEM, RMODEM, ZMODEM... and many other protocols o "Rotation" dialing of marked numbers - - like the MSDOS ProComm and Telix o Fewer "overlays" and more code memory-resident o More expansive host mode - possibly a whole new program here.. - with programming capability (Applesoft? Assembly? other?) - extended commands, messaging, bulletins, etc. - ... this could be an add-on module That's all I can think of off-hand. Just my 2c worth. [david] -- !======= David Douthitt :::: Madison, WI =======!== The Stainless Steel Rat ==! ! ArpaNet: madnix!rat@cs.wisc.edu ! ! ! UseNet: ...uwvax!astroatc!nicmad!madnix!rat ! Mad Apple Forth: ! ! {decvax!att}! ! The Madness starts here. !
lbotez@pnet02.gryphon.com (Lynda Botez) (09/08/89)
I really like Proterm; it's easy to use and does almost everything I need to
do with a telecommunications program. However, that doesn't mean there isn't
room for improvement.
Is ANSI emulation feasible on an Apple GS? If so, why hasn't anyone written a
com program that would handle it? It looks great on an IBM.
I'd like to be able to access the editor and scrollback while downloading or
uploading. From what I recall, you can do this with Appleworks GS; however
their com program has so many negatives that that feature isn't all that much
of a plus.
The copy buffer could be larger.
I'd like to be able to set defaults for sending uploads and receiving
downloads. I almost always use y-modem batch and I find it extremely annoying
to have to reset them every time I boot up Proterm.
Why not incorporate a mouse function? It's already been done by some
energetic bulletin board people already. However, what I like about the way
it's been done is that you can either use the mouse or not use it... Proterm
still looks the same.
Another innovation done to Proterm is a C1 send graphics viewer (for those
with GS's). When you log on a BBS that has this feature installed, you can
view SHR graphics. Pretty neat.
I'd like to see the Y-modem-G protocal available to GS users (Andy?).
Also, a good z-modem would be nice (especially one that could pick up in the
middle of a file that wasn't completely sent, for one reason or another).
I'd like to see a telecommunications program that was MORE than just a
telecommunications program. For instance, why not let it access all the NDA's
on the desktop? I also find myself using the editor built into Proterm to
type letters and almost anything else. How about an "all purpose" program?
Make it simple, and intuitive to use. Don't use pull-down menus (I'm tired of
all these term programs that look like Mousetalk).
Lynda
UUCP: {ames!elroy, <routing site>}!gryphon!pnet02!lbotez
INET: lbotez@pnet02.gryphon.commarc@lakesys.UUCP (Marc Rassbach) (09/08/89)
In article <8909070021.AA03717@trout.nosc.mil> lhaider@pro-sol.cts.com (Lawrence Haider) writes: >Network Comment: to #10769 by mailrus!ulowell!m2c!wpi!dseah@ames.arc.nasa.gov > >> What I'm looking for is suggestions. What you want, what you don't >>want, what kind of user interface it should have (I'm looking at a >>text implementation of mac-like menus), anything at all you like and Ok, you want input..... you got input. 1) Works on a almost stock ][+. If one were to add a 16 bit internal 6502 (6518???) or a 65C02. Prefer the 65C02. 2) Has all the nice features of ProTERM. (scrollback, cut-n-paste scrollback, built-in editor, etc) The IBM world has nothing like ProTERM. (and one of these days real soon now, I may get around to writing one......:-) ) Good luck in your quest. -- Marc Rassbach marc@lakesys If you take my advice, that "I can't C with my AI closed" is your problem, not mine! If it was said on UseNet, it must be true.
greyelf@wpi.wpi.edu (Michael J Pender) (09/08/89)
I would like to see kermit server mode implemented, where a person can pick what files to receive from the user end. If you haven't seen this mode as its implemented on an IBM or kermit-65, its not the same as proterm.
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/09/89)
In article <19626@gryphon.COM> lbotez@pnet02.gryphon.com (Lynda Botez) writes: >Is ANSI emulation feasible on an Apple GS? If so, why hasn't anyone written a >com program that would handle it? It looks great on an IBM. ANSI is the American National Standards Institute, and cannot be emulated on an Apple IIGS or an IBM PC. ANSI X3.64 is a standard for use of escape sequences on ASCII terminals; DEC's VT100 terminal was one of the first to support a subset of these sequences (plus an additional standard-conforming set of DEC-specific extensions). There are Apple II communication programs that emulate the VT100. There may be an ANSI standard for color extensions to X3.64, but if so I haven't heard about it. (If anybody knows for sure, I'd like to be informed.) I don't know why this is generally being called "ANSI" in the IBM PC world, because it sure is confusing.
emerrill@tippy.uucp (09/09/89)
/* Written 8:38 pm Sep 8, 1989 by gwyn@smoke in tippy:apple */ >In article <19626@gryphon.COM> lbotez@pnet02.gryphon.com (Lynda Botez) writes: >>Is ANSI emulation feasible on an Apple GS? If so, why hasn't anyone >>written a com program that would handle it? It looks great on an IBM. > >ANSI is the American National Standards Institute, and cannot be emulated >on an Apple IIGS or an IBM PC. ANSI is also used (or misused, depending on your point of view) to talk about "text" graphics on the IBMs. There are a few programs which substitute the closest text characters for ANSI graphics, but the reason not everybody has written a graphics-based IIgs program is simple: even at 1200 baud, the graphics interface is too slow. The has improved a lot since SD 5.0 came out, but it is still nowhere in the acceptability range for 2400 baud. _________________________________________________________ | | | Eric Merrill tippy!emerrill@newton.physics.purdue.edu | | | | Disclaimer: | | If you think I'm serious, that's your problem! | |_________________________________________________________|
lhaider@pro-sol.cts.com (Lawrence Haider) (09/10/89)
Network Comment: to #10835 by puff!rt20.cs.wisc.edu!blochowi%speedy.wisc.edu@BRL.MIL
What's your point Jason? The person that said he'd write this "Telecom
Program of the Gods" (what's his name), said that it was to be a program for
the //gs. So, of course SHR graphics is what I am talking about using, even
though I believe he stated he wished to use text mode operation for increased
speed. I feel the new Quick Draw can handle screen updates fairly well at
2400 bps and don't really feel a //gs terminal program needs to support 1 MHz
II+ emulation using a DHR screen. Do you?
Laerblochowi@rt5.cs.wisc.edu (Jason Blochowiak) (09/10/89)
In article <8909092140.AA18968@trout.nosc.mil> lhaider@pro-sol.cts.com (Lawrence Haider) writes: >Network Comment: to #10835 by puff!rt20.cs.wisc.edu!blochowi%speedy.wisc.edu@BRL.MIL >What's your point Jason? The person that said he'd write this "Telecom >Program of the Gods" (what's his name), said that it was to be a program for >the //gs. So, of course SHR graphics is what I am talking about using, even >though I believe he stated he wished to use text mode operation for increased >speed. I feel the new Quick Draw can handle screen updates fairly well at >2400 bps and don't really feel a //gs terminal program needs to support 1 MHz >II+ emulation using a DHR screen. Do you? First of all, ][+'es don't have DHR, that came with a certain revision of the //e motherboard. You "feel" the new QD can handle updates fairly well? What, if we all think real hard, it'll be able to support multi-window 19.2kbps? Do you have any "live" examples to support this feeling? My point was: On a 1Mhz machine, 1200 baud on an 8k screen was too much for it to handle. Perhaps, using interrupts, a 2.8Mhz machine could handle a 16k screen for speeds above 300 baud. However, a 32k screen at 2400 or (gods forbid) 9600 would probably be too much for a 2.8Mhz machine - from playing around with SnowTerm a little bit, I found it could handle 2400 comfortably @7Mhz, but (from what I've gathered from what the author says) he's going direct to video memory, so QD's overhead isn't even involved. So, since in my (vaguely qualified) opinion, using SHR would be too slow for most people's machines, using DHR would provide for a middle road - it wouldn't be quite as nice looking, but would still provide for color graphics. My apologies if the original wasn't clear enough - sometimes I'm trying to say too many things at once, and it comes out a bit garbled... > Laer -- Jason Blochowiak - back at school (again). blochowi@garfield.cs.wisc.edu or jason@madnix.UUCP "What's up pruneface?" - Bugs Bunny in the year 2000
greyelf@wpi.wpi.edu (Michael J Pender) (09/11/89)
In article <8909092140.AA18968@trout.nosc.mil> lhaider@pro-sol.cts.com (Lawrence Haider) writes: > >What's your point Jason? The person that said he'd write this "Telecom >Program of the Gods" (what's his name), said that it was to be a program for >the //gs. So, of course SHR graphics is what I am talking about using, even >though I believe he stated he wished to use text mode operation for increased >speed. ... >don't really feel a //gs terminal program needs to support 1 MHz >II+ emulation using a DHR screen. Do you? > > Laer It would be nice if the program ran on the DHR screen to support other machines like the IIe/IIc/Laser 128. After all it would still work on the IIgs. Besides, how many II+ computers have DHR? It would be nice if the minimum requirements were 64K, a 65C02 or better, and could run from a 5 1/4 inch drive. For a new telecom program to be the "program of the gods," let alone replace proterm, it has to be compatible with more than just GS machines, there are a lot of apple owners that don't own IIGs's.
lhaider@pro-sol.cts.com (Lawrence Haider) (09/11/89)
Network Comment: to #10937 by puff!rt5.cs.wisc.edu!blochowi%speedy.wisc.edu@BRL.MIL
Ok Ok Jason, I'm using a TransWarp too and didn't think about it when posting
my last message. 2400 baud does come across fair in AWGS tcom module, and no
I don't think I'd like to try it at 2.8MHz.
Laerprl3546@tahoma.UUCP (Philip R. Lindberg) (09/12/89)
> ... >>don't really feel a //gs terminal program needs to support 1 MHz >>II+ emulation using a DHR screen. Do you? >> >> Laer > > It would be nice if the program ran on the DHR screen to support other > machines like the IIe/IIc/Laser 128. After all it would still work on > the IIgs. Besides, how many II+ computers have DHR? > Yes, it would be nice: BUT the point is everybody else is writing term. programs for the "generic Apple user" and the end result is of course, the lowest common denominator. What's wrong with somebody wanting to write something that really makes the GS !!SHINE!! Is it really so bad that everybody can't use it? What about those of us that are tired of generic comm. programs? I think it would be neat to see one that really used the GS and did the stuff we know it could do.... > It would be nice if the minimum requirements were 64K, a 65C02 or better, > and could run from a 5 1/4 inch drive. Here we go again. How can one make the GS shine within only 64K? And what about the 2.5 meg. of RAM sitting idle in my machine while I struggle with a miniscule buffer or no buffer at all! > [...] let alone replace proterm, it has to be compatible > with more than just GS machines, there are a lot of apple owners > that don't own IIGs's. So use ProTerm, it covers all the II's. And don't discourage the guy from wanting to REALLY USE his machine. ^^^^^^^^^^ <flame off> Phil
markl@pro-generic.cts.com (Mark Leumanne) (09/14/89)
Network Comment: to #4781 by garcon!uxa.cso.uiuc.edu!jb10320@uxc.cso.uiuc.edu NO WAY! Keep Upgrading ProTERM, get rid of those bugs (I haven't experienced any) and keep producing ProTERM... ==========::Mark::Leumanne::============ ======::Toronto::Ontario::===== = == = = UUCP: crash!pro-generic!markl == "Apple ][ forever." = = ARPA: crash!pro-generic!markl@nosc.mil == "Beatles forever." = = INET: markl@pro-generic.cts.com == "Networking forever." = = == = ======================================== =============================== = CD 61 72 6B : CC 65 75 6D 61 6E 6E 65 : CC 6F 76 65 73 : C1 D0 D0 CC C5 = =========================================================================
markl@pro-generic.cts.com (Mark Leumanne) (09/16/89)
Network Comment: to #4803 by ogccse!blake!aragorn@ucsd.edu I think the main reason why ProTERM writes over RAM is because of the Scroll Back and Copy Buffer...Otherwise, you wouldn't have any of these IMPORTANT uses, although it would be nice if along in the configuration, People with rather LARGE RAM cards could specify 1) How much Blocks ProTERM should use in RAM...That way, everything wouls suit quite a few needs, for example, if someone wants to leave PT.XFER up, in their RAM, and a Blank disk in Drive one, then everything would be good...Well, comments etc? ==========::Mark::Leumanne::============ ======::Toronto::Ontario::===== = == = = UUCP: crash!pro-generic!markl == "Apple ][ forever." = = ARPA: crash!pro-generic!markl@nosc.mil == "Beatles forever." = = INET: markl@pro-generic.cts.com == "Networking forever." = = == = ======================================== =============================== = CD 61 72 6B : CC 65 75 6D 61 6E 6E 65 : CC 6F 76 65 73 : C1 D0 D0 CC C5 = =========================================================================
ST802148@BROWNVM.BITNET (Evan) (09/17/89)
Regarding the statement that proterm destroys any RAM disks, that is not true i f they have been initialized. There is a difference between setting RAM aside for RAM disks and actually initing the RAM drive. I have a Ramworks III with 57 6K and if I don't make a RAM disk with it, Proterm uses it all for scroll back annd transfers. However, if I make the /ram, it (Proterm) will only use 45K fo r scrollback. It happens. Maybe you are using a diff. version than me. I have 2.1
paul@pro-europa.cts.com (Paul Hutmacher) (09/22/89)
Comment to message from: markl@pro-generic.cts.com (Mark Leumanne) > I think the main reason why ProTERM writes over RAM is because of the Scroll > Back and Copy Buffer...Otherwise, you wouldn't have any of these IMPORTANT > uses, although it would be nice if along in the configuration, People with > rather LARGE RAM cards could specify 1) How much Blocks ProTERM should use in > RAM...That way, everything wouls suit quite a few needs, for example, if > someone wants to leave PT.XFER up, in their RAM, and a Blank disk in Drive > one, then everything would be good...Well, comments etc? Actually, in the ProTERM manual on page 113-115 it discusses how to use a ram disk with ProTERM. Although this is not foolproof on the //c it does work well on the IIgs. By the way, if you've misplaced your manual I sell them for reasonable prices. I will also include a registration card and two disks with ProTERM on them in a nice colorful box. Paul Hutmacher UUCP: [ucsd, nosc] ..!crash!pro-europa!paul INET: paul@pro-europa.cts.com ARPA: crash!pro-europa!paul@nosc.mil
greyelf@wpi.wpi.edu (Michael J Pender) (09/22/89)
In article <632@tahoma.UUCP> prl3546@tahoma.UUCP (Philip R. Lindberg) writes: >> It would be nice if the program ran on the DHR screen to support other >> machines like the IIe/IIc/Laser 128. After all it would still work on >> the IIgs. Besides, how many II+ computers have DHR? >> >Yes, it would be nice: BUT the point is everybody else is writing term. >programs for the "generic Apple user" and the end result is of course, the >lowest common denominator... DHR graphics have NEVER been implemented in ANY Apple comm. program I have seen, and SHR graphics have already been described as too slow for anything above 1200 baud. >something that really makes the GS !!SHINE!! Is it really so bad that >everybody can't use it? If you want SHR graphics and speeds above 1200 baud you're leaving out all GS owners without a Transwarp. And yes, it is bad that everybody can't use it. I'm not saying it shouldn't take advantage of the ample memory available in a GS. Hell, I have 448K RAM and an 800K Unidisk in my Laser 128ex, and I love to use the RAMdisks. But the program will NEVER, EVER, EVER replace Proterm unless it has a greater market appeal. >What about those of us that are tired of generic >comm. programs? I think it would be neat to see one that really used the >GS and did the stuff we know it could do.... Other than SHR graphics and an Ensoniq chip what other GS specific features do you want? SHR graphics are too slow on a stock GS, and I don't really see how an Ensoniq chip will help a comm program out. > >> It would be nice if the minimum requirements were 64K, a 65C02 or better, >> and could run from a 5 1/4 inch drive. > >Here we go again. How can one make the GS shine within only 64K? And what >about the 2.5 meg. of RAM sitting idle in my machine while I struggle with a >miniscule buffer or no buffer at all! I agree that Proterm's buffering setup stinks, but just for a program to be able to access your 2.5 megs doesn't mean it can't run in less, an excellent example is Copy II plus. It can take advantage off ALL your memory, but only needs 64K for most functions. >> [...] let alone replace proterm, it has to be compatible >> with more than just GS machines, there are a lot of apple owners >> that don't own IIGs's. > >So use ProTerm, it covers all the II's. And don't discourage the guy from >wanting to REALLY USE his machine. > ^^^^^^^^^^ Sorry Phil, but the rest of us out here have exactly the same feeling about our machines. > <flame off> Phil --- Michael J Pender Jr Box 1942 c/o W.P.I. I wrote SHELL and Daemon, greyelf@wpi.bitnet 100 Institute Rd. send bug reports, suggestions, greyelf@wpi.wpi.edu Worcester, Ma 01609 checks to me.
samt@pro-europa.cts.com (Sam Theis) (09/23/89)
Comment to message from: m2c!wpi!greyelf@husc6.harvard.edu (Michael J Pender) Micheal J Pender writes in a message: > DHR graphics have NEVER been implemented in ANY Apple comm. program I have > seen, and SHR graphics have already been described as too slow for anything > above 1200 baud. Gee Michael. Guess since you are stuck with a Laser that you haven't seen SnowTerm 1.07. It provides a very good VT100 emulation using the GS SHR graphics and certainly keeps up with 2400 baud under GS/OS 3.0 without any problems. I haven't tried it at 9600, but messaging traffic at 9600 isn't a major problem since I have yet to find anyone that can read at 9600 speeds. Messages would be buffered and displayed at reasonable speeds. File transfers can be at any speed, since they aren't concerned with what method is used to write to the screen. So I think that an effective modem program could be written using SHR graphics for the GS with or without a TransWarp GS. Certainly a TransWarp would help push the frontier. Sam UUCP: crash!pro-europa!samt ARPA: crash!pro-europa!samt@nosc.mil INET: samt@pro-europa.cts.com