Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!pasteur!ucbvax!UCONNVM.BITNET!SEWALL From: SEWALL@UCONNVM.BITNET Newsgroups: comp.sys.apple Subject: TIC Message-ID: <8801181057.aa00304@SMOKE.BRL.ARPA> Date: 16 Jan 88 19:17:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 89 Don Elton writes: >It would not that big a deal to support non-interrupt driven communication >cards though performance will obviously not be as good, particularly at >higher baud rates (Note that TIC's baud rate range is from 300-19,200 baud). >I'll have to think about this some more as a possible feature for TIC. A >feature like this may just cause more tech support headaches when users >wonder why they're losing data. At least now when they don't receive any >data at all they know that they're at fault but if they receive some data >they'll possibly assume TIC's at fault and give me grief. I appreciate the problem, but if "interrupts on" is the default and a deliberate parameter change is required to alter it, then problems should be far fewer. Have you thought about an "undocumented feature" (a term I learned from an Apple spokesperson responding to complaints that Appleworks lost data if entries were made into too many columns on a single row)? Suppose there were a changeable parameter (or even a "patch" that could be EXEC'd and then the program BSAVE'd) that you only documented for (registered) owners who asked (I gather I'm the primary invidivdual that keeps harping on the subject). If you do install non-interrupt, I hope you do so in the 8-bit version as I've analyzed my long term needs and it appears that my next system will be 68030 based (Mac II+?) rather than a IIgs. In spite of its limitations, the //e (or //c) in conjuntion with the mainframe is adequate for my needs at the moment. I expect I'll need to scrape together the price of a modest sized auto for the system I'll want next - no surplus to expend on a IIgs 8-( A thought: The earliest version of SOFTERM (the old copy protected one) automatically looked for a file named "patch" (as it TIC.PATCH) when it loaded. If it found such a file it 'bloaded' the patches into the appropriate memory locations. That procedure made it possible to distribute many program updates and fixes without having to send out whole new copies of the program. You might find that approach useful - especially after you begin distributing TIC Pro to only registered owners because you'd still be able to send them updates by bbs and email. >I'll have a kermit in TIC Pro more than likely. I think emulations without >kermit are frequently useful as not everyone has a need to transfer files >from a mainframe to their micro -- perhaps only a minority of users are >sofisticated enough to even consider the possibility of file transfers in >fact. I suspect that most users just use the mainframe's editors/programs >etc to manipulate their data where it sits since most users wouldn't know >what to do with the data once they got it on their apple anyway. Gee what a pessimistic view you have of run-of-the-mill users. Most of the kids (and even the grownups who know what a modem is) around here transfer programs like crazy from their own systems to bbs's. File transfer is hardly an unknown idea. Yes, I'll still use the mainframe's editor over the phone line for short things (about the size of this note for instance), but then I started using a 33-KSR TTY at 110 baud; so 2400 baud looks REALLY quick! Judging from both the faculty, students, and secretaries I have contact with, transfer of text files from micro to mainframe (for printing or shipping by net) is common to far more than not. If you've used a mainframe for typing a 5 or more page manuscript compared to even a rudimentary micro wordprocessor, you know why using the host to enter drafts is getting rare. Many of us who program prefer to code on a micro upload and debug (if necessary ;-) on the host. Transfer is also the common means of getting text files from Apple to IBM-PC, Commodore, Atari (what-have-you) and vice-versa. If you author a 30 page manuscript for a journal that requires submission of 5 copies, the most sensible way to produce the hard copy is the mainframe printer (ours is a laser printer that runs 300 pages a minute which is MUCH faster than the combination of Diablo and plain paper copier!). It's hard to tell what fraction of comp.sys.apple readers regularly transfer files from micro to host (or verse-vica), because there are evidently many readers who "read only," but it surely seems from comments about APPLE2-L, Kermit, and "apple.binaries" that more than two-thirds of those who chose to post also transfer. VT100 seems to be the "standard" (for today) ASCII terminal for most hosts (even though it appears the majority also support VT-52 and some others such as ADM3 series and Televideo 9xx series). If someone only wants to emulate a dumb terminal without file transfer, I don't think they'd be a good prospect for your toil. There are simply too many copies of too much software (Both Ted Medin's and Dick Atlee's Kermit's are legitimate public domain) already out there that will do that job. --------------------- ARPA: sewall%uconnvm.bitnet@cunyvm.cuny.edu Murphy A. Sewall BITNET: SEWALL@UCONNVM School of Business Admin. UUCP: ...ihnp4!psuvax1!UCONNVM.BITNET!SEWALL University of Connecticut