Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!ucbcad!ucbvax!WALKER-EMH.ARPA!InfoMail-Mailer From: InfoMail-Mailer@WALKER-EMH.ARPA Newsgroups: comp.sys.atari.8bit Subject: Undeliverable Mail Message-ID: <8709300415.AA06872@ucbvax.Berkeley.EDU> Date: Tue, 29-Sep-87 23:50:00 EDT Article-I.D.: ucbvax.8709300415.AA06872 Posted: Tue Sep 29 23:50:00 1987 Date-Received: Sun, 4-Oct-87 19:42:44 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 435 Mail was not delivered to the following users because there were bad address(es) in TO and/or CC field(s): info-atari UNDELIVERED-MESSAGE: ---------------------------------------------------------------- Received: from BBN.COM by WALKER-EMH.ARPA ; 30 Sep 87 03:21:38 GMT Received-2: from score.stanford.edu by BBN.COM id aa26271; 29 Sep 87 22:55 EDT Date: Tue 29 Sep 87 17:11:26 PDT Subject: Info-Atari8 Digest V87 #85 From: Info-Atari8 @ SCORE.STANFORD.EDU Errors-to: Info-Atari8-request@Score.Stanford.EDU Maint-Path: Info-Atari8-request@Score.Stanford.EDU To: Info-Atari8 Distribution List: Reply-to: Info-Atari8@SCORE.STANFORD.EDU Text: Info-Atari8 Digest Tuesday, September 29, 1987 Volume 87 : Issue 85 This weeks Editor: Bill Westfield Today's Topics: Re: ARC file format? VT52B: Yet Another Terminal Emulator (Part 2 of 3) VT52B: Yet Another Terminal Emulator (Part 1 of 3) Re: reasons for upgrade! Sorry, but bad reply path Re: Info-Atari8 Digest V87 #84 ---------------------------------------------------------------------- Date: 27 Sep 87 00:05:11 GMT From: aramis.rutgers.edu!knutsen@rutgers.edu (Mark Knutsen) Subject: Re: ARC file format? To: info-atari8@score.stanford.edu In article <870925172005.1.JRD@GRACKLE.SCRC.Symbolics.COM> jrd@STONY-BROOK.SCRC.SYMBOLICS.COM (John R. Dunning) writes: > Does anyone know the format of .ARC files, as hacked by the ARCX and ARC > that were posted a while ago? > Failing that, does anyone know how to contact the authors? I've read articles on the format of .ARC files, but none were in-depth enough for your purposes. In a nutshell, however, ARC determines which of four compression techniques to use on each file it's asked to archive, compresses them, and sticks them together. The 8-bit version of ARC never uses the 4th technique ("crunching") due to memory restrictions, but the 8-bit ARCX can unARC files compressed with all four techniques. I believe that the 8-bit ARC and ARCX were written in Lightspeed C by the authors of that language, who frequent the GEnie Atari Roundtable. I can recall reading a message by one of the authors explaining that it's pointless to attempt to improve on the speed of the 8-bit ARC. It's a very calculation-intensive application, and the Atari is only so fast at these things. Still, if you're willing to tackle the task in assembler, you may be able to speed it up a bit... On another note: I have discovered by much experimentation that ARC 1.2 tends to compress text files such that they contain an extra copy of their last byte when unARCed. This causes ARCX to generate checksum errors, which can safely be ignored. Regardless, I find it safest to ARC things with ARC 1.1 and deARC them with ARCX 1.2. -- _________________________________ Jersey ||| _____________________________ ARPA: knutsen@rutgers.edu | Atari / | \ | GEnie GE Mail: M.KNUTSEN UUCP: {...}!rutgers.edu!knutsen | ||| Computer | The JACG BBS: (201)298-0161 --------------------------------- / | \ Group ----------------------------- ------------------------------ Date: 28 Sep 87 16:32:37 GMT From: jumbo!ehs@decwrl.dec.com (Ed Satterthwaite) Subject: VT52B: Yet Another Terminal Emulator (Part 2 of 3) To: info-atari8@score.stanford.edu ------------------------------------------------------------------------------ VT52B Documentation Overview -------- VT52B consists of two modules. One is a fairly general handler for an "A:" device that manages a 24 x 80 screen. It provides a character-oriented output device that recognizes embedded escape sequences. These escape sequences perform various display control functions. They support a subset of the VT52 terminal capabilities plus a few extensions needed for incremental display updates. The other module is a very simple (perhaps too simple) terminal protocol manager that attempts to coordinate the K:, R: and A: devices to emulate an extended VT52 terminal. The A: handler uses techniques of display list management that are by now fairly standard and well-known. I hope that most of the code will be fairly scrutable to an experienced ACTION! programmer. I will not attempt to explain it here but I will try to answer any specific questions that arise. The A: Handler -------------- The following VT52 escape sequences are supported: esc-A moves cursor up one line esc-B moves cursor down one line esc-C moves cursor right one column esc-D moves cursor left one column esc-H homes cursor esc-I reverse line feed esc-J clears from cursor to end of screen esc-K clears from cursor to end of line esc-Y positions cursor (see VT52 specs for X,Y encoding) The following extensions are also supported: esc-F enters 'stand-out' (inverse video) mode esc-G exits 'stand-out' mode esc-L inserts blank character space at the cursor esc-M deletes character at the cursor esc-N inserts blank line at the cursor esc-O deletes line containing the cursor A suitable UNIX termcap entry appears at the end of this file. The extension codes have been chosen to be compatible with the "VT-52XL" terminal supported by Chameleon, and the same termcap should be suitable for both. The support for 'stand-out' mode has not been extensively tested, but it is good enough to do Emacs mode lines and the like. Its use is a mixed blessing, however, since the inverted video can be much less readable. To disable it, remove the next-to-last line from the suggested termcap. The code could easily be modified to support 'insert' and 'delete' modes directly, and the corresponding incremental updates would be considerably faster. I have not done this because such modality can be disastrous over a noisy or unreliable line. When the A: device is opened, it allocates space for its display bit maps and custom display lists from the top of available memory as recorded in MEMTOP (location $2E5) and updates MEMTOP. These data structures require approximately 8200 bytes. If sufficient space is not available, the open fails and MEMTOP is not changed. Terminal Emulation ------------------ ASCII characters not on the Atari keyboard can be entered as follows: { ctrl-< or shift-< } ctrl-> or shift-> ~ ctrl-backS or shift-backS ` ctrl-. The emulator does not provide flow control; buffer overruns drop characters. In my experience, this is never a problem at 1200 baud and is not a problem at 2400 for screen-at-a-time output. The program cannot keep up with continuous output at 2400 baud. The ASCII bell character (^G) produces no visible or audible output. Installation ------------ You will need an ACTION! cartridge to compile and run this program. You might also have to edit the source to select the options you require, since there is no provision for changing these at runtime. The configuration of the 850 interface (or similar R: interface) is controlled by the following variables, which are declared and initialized at the beginning of the main program module: speed, wsize, sbits, lf, iparity, oparity See the 850 manual for tables of possible values and their meanings. Note that the value of 'speed' is 7 less than the tabulated value, e.g., speed baud rate 1 300 2 600 3 1200 5 2400 Alternatively, you can modify the calls of XIO_R in the procedure init_R; these variables are not used elsewhere. As it stands, VT52B supports a 1200 baud modem with 8-bit words, 2 stop bits and no parity. Many monitors will actually display 25 or 26 lines of text. You can take advantage of this by changing the following definitions at the beginning of the module for the A: handler: NL number of screen lines (normally 24) NB number of skip lines in top border (normally 3) LL *must* equal NL-1 DLSize *must* equal NB + 10*NL + 3 I have had good results with NL=25 and NB=2. If you change NL, be sure to change your termcap entry to agree. I experimented with several background colors for the display. I eventually settled on a pale blue that seemed to be the best compromise between contrast and flicker on my particular monitor. See the procedure init_A if you want to change this. The emulator module contains a procedure load_R. This is a machine-code insert essentially similar to the code in the autorun file that downloads the R: handlers from the 850. I added it when I was having some trouble with 850 (re)initialization. I left it in because it makes the object file somewhat smaller and easier to build. If you have a different interface unit or prefer a different handler, delete init_R and prepend your handler to the object file in the usual way. You must compile this program with lower case enabled. You must also compile it with space for the R: handlers reserved in low memory. The simplest way to do this is to load the handler you intend to use (by executing the AUTORUN.SYS file, for example) before compiling VT52B.ACT. You can then execute the compiled program directly or save it for later execution using the DOS "L" command or equivalent. If you deleted init_R, you must prepend an appropriate R: handler. Alternatively, you can set the code origin to reserve space for your handler as described on page 144 of the ACTION! manual. You are in terminal emulation mode as soon as execution begins. Note: At least some versions of the 850 will not download the R: handlers a second time until the power has been cycled on either the console computer or the 850. Thus if you load the handlers (e.g., with the standard AUTORUN.SYS file), do something that destroys them (e.g., going to DOS without a MEM.SAV file) and then attempt to reload them, you will be left without warning with bad handlers. Suggested Termcap Entry ----------------------- Here's one that has worked for me: dw|vt52|decvt52:\ :cr=^M:do=^J:nl=^J:bl=^G:le=^H:bs:cd=\EJ:ce=\EK:\ :cl=\EH\EJ:cm=\EY%+ %+ :co#80:li#24:nd=\EC:ta=^I:pt:sr=\EI:\ :up=\EA:ku=\EA:kd=\EB:kr=\EC:kl=\ED:kb=^H: a1|atari|atari vt52 emulator:\ :am:pt:tc=vt52: a2|atari+|vt52xl|atari vt52+ emulator:\ :al=\EN:dl=\EO:im=:ei=:ic=\EL:dm=:ed=:dc=\EM:\ :so=\EF:se=\EG:\ :tc=atari: Note that it can take some extra work to get your favorite program to notice changes in the terminal type and capabilities. If the program is able to use the escape sequences, you should notice a definite difference between vt52 and atari+ termcap entries. Here's a script from our system administrator that works for Emacs: #! /bin/csh -f # # vt52b-mode - setup terminal for vt52b mode. # stty dec new cr0 set noglob setenv TERMCAP atari.termcap setenv TERM atari+ eval `tset -s -I -Q` set term = atari+ unset noglob Replace "atari.termcap" with the name of the file containing a termcap entry similar to the one above. ----------------------------------------------------------------------------- Ed Satterthwaite Arpa: ehs@src.DEC.COM Uucp: {...}!decwrl!ehs ------------------------------ Date: 28 Sep 87 16:29:27 GMT From: jumbo!ehs@decwrl.dec.com (Ed Satterthwaite) Subject: VT52B: Yet Another Terminal Emulator (Part 1 of 3) To: info-atari8@score.stanford.edu Hardly what the 8-bit Atari world needs most right now, but here's why I often use this one when I just want a Unix terminal (no file transfers): - It uses the character set I find most legible on my particular monitor (Commodore 1702, composite color). This is a very subjective call, and I make no claims at all about results on a good monochrome monitor. - It has relatively fast implementations of most escape sequences. These provide the terminal capabilities needed to make the use of a screen-oriented editor (Emacs) bearable. - The program is small and simple; it loads and initializes quickly. - Source (in ACTION!) is available for customization and adaptation. I'm posting VT52B in case anyone else has similar requirements. It is an upgrade of the ACTION! program VT52A posted by Michael Jenkin about a year ago. Michael's font looks bolder and more blocky than the ones used by the other 80 column programs that I've tried. In addition, the proportions of some characters are exaggerated a bit to make the corresponding shapes more distinctive. This is a good trade-off for my eyes and monitor; your mileage may differ. I have modified VT52A by reworking the display management, adding a few new escape sequences, and generally trying to streamline what seemed to be the critical loops. My thanks to Michael for permission to use his character set as well as the general framework of his program. I am posting the sources for three reasons. First, I don't have a copy of the ACTION! runtime library to link with the object code. Second, this is an edit-and-compile project; there are no runtime menus, and some customization of the source will probably be necessary. Finally, 80-column screen management is done by an "A:" handler that is comparable to the standard "S:" handler. It might be of some interest for other applications, even if you don't care about a terminal emulator. Most of the revision of VT52A was done as a Sunday afternoon hack, with some further additions and changes suggested by experience with the program. It now does what I need, but there is plenty of room for further development. All my testing has been done with an Atari 800, an Atari 850 interface, and Hayes-incompatible modems at 1200 and 2400 baud. The mainframes have been VAXen running various versions of Ultrix (essentially similar to BSD 4.2 and 4.3 Unix) with Unipress (Gosling) Emacs as the primary editor. I've had considerable trouble getting other terminal emulators to work in this environment. If you have similar problems getting VT52B to work for you, I'd be interested in hearing about it. Some documentation and a suggested Unix termcap entry appear in the next message. The message following that contains the ACTION! source code for VT52B.ACT. Ed Satterthwaite DEC Systems Research Center, Palo Alto, CA Arpa: ehs@src.DEC.COM Uucp: {...}!decwrl!ehs ------------------------------ Date: 27 Sep 87 00:09:35 GMT From: hp-pcd!uoregon!omepd!hah@hplabs.hp.com (Hans Hansen) Subject: Re: reasons for upgrade! To: info-atari8@score.stanford.edu In article <8709242218.AA05629@ucbvax.Berkeley.EDU> DFLINT02@ULKYVX.BITNET writes: >Did someone on the net ask for reasons on why an upgrade for the atari 6502 >should be attempted. > > >The main reason i would want a 65816 in my machine would be to embarrass >TRAMIAL. He has bumbled with a great machine. The handling of the 8-bit as >compared for the ST has been unexcusable. Atari should realize by now that the >whole 1.5 million active atari 8-bit users are not going to upgrade to the ST. >When IBM is backing a new comparable machine in the same price range. > >The botton line is Any upgrade to the moderately useful XE/XLs line would be >appriciated. > >William M Buford The 16/32 bit upgrade to the Atari 800 line has been on the dealers shelves sinse September 1985 !! The problem that most Atari 800 owners have is one of idenity -- they fail to see what has been placed in front of their faces. I of course am talking about the Amiga 1000. I bought my Atari 800 for its great graphics, sound, and FRIENDLY user interface, BTW its SN is 00232 ! The Amiga 1000 IS the NEXT generation Atari 800 ! The chief H/W architect for the Atari 2600, Atari 800 and the Amiga 1000 is Jay Miner ! The Amiga's great MULTITASKING OS is just a super bonus to an already super computer. BTW my Amiga's SN is D605 - its a preproduction box ! BTW I have worked for Atari (pre JT), Commodore (during the JT reign), and Amiga (1984-5). Am I jaded ? YES I will not purchase a JT product ever again ! I am no longer connected with either Atari or Commodore except that I own their products. Amiga 1000 Simply the best computer for 3X the price Atari 800 Best 8 bit computer built. Atari 400 Expanded to 48K. Same as above. C64 Used only to play games on. OS sucks cow sn@t. VIC20 Same as the C64. Atari 2600 Great little game machine. Hans These comments are mine, mine, mine... however all may share them. ------------------------------ Date: 29 Sep 87 04:44:01 GMT From: sunybcs!bingvaxu!leah!uwmcsd1!csd4.milw.wisc.edu!pirc2499@rutgers.edu (James Franc Pirc) Subject: Sorry, but bad reply path To: info-atari8@score.stanford.edu Sorry about posting this on the net but I couldn't reply via mail. Jon A. Tankersley: Please leave a way of getting hold of you. I tried replying to your mail but it came back returned saying bad system (cr1a) I think... James True : James Pirc ARPA : pirc2499@csd4.milw.wisc.edu GEnie: JIM.PIRC ------------------------------ Date: Tue, 29 Sep 87 09:16 EDT From: Cothrell@DOCKMASTER.ARPA Subject: Re: Info-Atari8 Digest V87 #84 To: Info-Atari8@SCORE.STANFORD.EDU In-Reply-To: Message of 27 Sep 87 00:27 EDT from "Info-Atari8 Digest" Mr. Buford (DFLINT) made a speech on why to upgrade the ATARI 8 bit CPU's. one of his points was to embarrase Tramile (sorry if its spelled wrong). I must say, that as one of those working on an upgrade, embarrasing ANYBODY is not in my mind. As a matter of fact, I would even consider signing over the upgrade to Atari if it could be used to make the Atari machines a better product. I see supporting Atari as an investment in my computer...the returns being more support from Atari and the Software industry. Scott Cothrell Cothrell -at Dockmaster.arpa PS. no Atari did not pay me for this...Although I wouldn't mind working for them! ------------------------------ End of Info-Atari8 Digest ************************** ------- -------------------END OF UNDELIVERED MESSAGE-------------------