Oakland CPM Archive

home *** CD-ROM | disk | FTP | other *** search

/ Oakland CPM Archive / oakcpm.iso / cpm / amethyst / augarch.txt < prev next >

Wrap

Text File | 1984-01-16 | 69.9 KB | 1,802 lines

Date: 5 January 1982 1826-est From: Brian N. Hess <Hess.Unicorn at MIT-Multics> Subject: Mince/Scribble/IBM P.C. To: Marvin Sirbu <SIRBU at MIT-MC> Cc: AMETHYST-USERS at MIT-MC In-Reply-To: Your message of December 19th Yes, we're planning to support the IBM P.C. Currently, we're waiting for a C compiler to be written for us. Expecting to be able to ship a Mince and Scribble on June 1. (Currently we have a hack Mince written in BASIC(!) for the P.C. while we download things onto it.) Yes, Scribble is enough like Scribe (tm DEC or Unilogic Ltd.) to be able to go from the P.C. to the 20, but not vice-versa -- Scribble does not support the various technical publication formats and such (i.e. no @make command) and lacks some other features of Scribe. And of course Scribe is general enough that any environments which Scribble may have in the future which are not in base-level Scribe can be easily fashioned with an @make or other short-term hacking on the 20, and then used thereafter. Brian Date: 19 December 1981 16:31-EST From: "Marvin A. Sirbu, Jr." <SIRBU at MIT-MC> Subject: IBM PC To: AMETHYST-USERS at MIT-MC I am about to acquire an IBM personal computer to do text editing at home (I'm tired of 1200 baud display refresh). The ideal mode of working will be to prepare text with an emacs-like (Mince?) editor on my home computer with scribe formatting commands. When i want to see the final result on a laser printer, I will upload the file to the DEC-20 and run it through scribe. It would be nice of course to be able to print drafts locally using a mini-scribe that ran on my PC (Scribble?). I have several questions. Does Mince/Scribble run on the IBM PC? Is Scribble enough like Unilogic Scribe that I can upload a file to the 20 and run it through Scribe without significant changes? What is the best file transfer program for uploading/downloading to a DEC 20? Does anyone have any experience with this type of operation? Any help in answering these questions would be appreciated. Marvin Sirbu Date: 16 November 1981 23:28-EST From: Paul L. Kelley <PLK at MIT-MC> Subject: AG1 on RCP/M To: AMETHYST-USERS at MIT-MC Thanks to Barry most of the files from the first AUG disk are available on my remote CP/M. By "most" I mean the ones that are not standard RCP/M or CPMUG software. The files are stored in a passworded USER area. The password is available to AUG members from Barry (BADOB@MIT-AI). As of now the files will be available Monday nights unless a special request is made. Mark of the Unicorn may also be leaving notes, fixes, etc. there. You are also free to leave useful material. The number of the remote CP/M is: (617) 862-0781. Date: 6 October 1981 03:14-EDT From: Barry A. Dobyns <BADOB at MIT-AI> To: MARK-OF-THE-UNICORN at MIT-AI cc: BADOB at MIT-AI, amethyst-users at MIT-MC The ad in October byte for SuperSoft's Star-Edit is how mince ads should have appeared. (scribble ads too.) The current ad may be flashy, but doesn't say anything about Mince or Scribble themselves. -toodles! Date: 5 Oct 1981 21:50:39-PDT From: Cory.conde at Berkeley To: v:AMETHYST-USERS@MIT-AI Subject: user's group Mr.'Unicorn', Scott Layson advised me to mail to this account to get info on the Amethyst User's group, which I am willing to join! If this is Scott reading this letter, thanks for the diskette with the corrections, if you're not Scott, please say thanks to him... Incidentally, do you happen to know how one may use the ftp program to 'borrow' CP/M programs that I hear of in your system? Thanks, Dan Conde (of the Unix-Corn) <y:conde@Berkeley> Date: 27 September 1981 23:56-EDT From: Frank J. Wancho <FJW at MIT-MC> Subject: Soon.. from Mark... To: AMETHYST-USERS at MIT-MC Now that most of you have managed to bring up 2.6 and 1.3, I thought you'd might like to know what to look forward to in 4.0 (3.x is the equivalent of 2.x for the 16-bitters) and 1.4, according to Mark: -------------------- The big new feature will be "state save" and built-in crash recovery. "State save" is their name for what happens automatically on ITS (for example): exiting to CP/M, then returning to Mince, you will find the state of Mince essentially unchanged: all your buffers will still exist, and contain the same text (whether modified or not), etc. A couple of random things, like the previous search string, may get lost in the process, but "nothing important". Also, if your hardware or Mince should crash while you're editing, you can run the "recover" program, which grovels over your old swap file and salvages what it can (probably everything except the most recently typed text). State save is quite definite, but there are some other ideas they are tossing around. One is overlays -- are they worth the trouble? Another is an interpreted command language, to make Mince interactively extensible. [Any other ideas? Comments to the list, please. -fjw] No projected release date yet -- probably 5-6 months at least. Also in the works is Scribble 1.4, which will have greatly improved widow/orphan behavior, more flexible commands, and overlays for running in less memory. -------------------- Date: 30 August 1981 19:03-EDT From: Frank J. Wancho <FJW at MIT-MC> To: AMETHYST-USERS at MIT-MC I have allocated an area in the MC:CPM; directory for Public Domain ONLY code which anyone may wish to contribute. When uploading or FTPing a file (from a non-ITS site), simply specify AR9;CPM;fn1 fn2, where fn1 and fn2 may each be up to six characters. Then send a msg to this list telling us what the name of the file is and its function. Do NOT include whole pieces of code already available on the Amethyst distribution disks. Rather send directions for updating or modifying the code, OR original code. In other words, don't leave entire files around that are already available on the disks. --Frank Date: 30 August 1981 09:42-EDT From: gai@ai (Glenn Iba) Sender: GAI at MIT-AI Subject: Call for advice and info on the Apple/CPM/Amethyst connection To: INFO-APPLE at MIT-AI, AMETHYST-USERS at MIT-AI, INFO-CPM at MIT-AI, INFO-MICRO at MIT-AI Dear Apple users, Amethyst users, and CPM people, I am a new owner of an Apple II plus, and would appreciate help and advice from more experienced users. My questions break down into 2 groups: (1) questions concerning the system I hope to build around my Apple, and (2) general questions about things I don't understand yet. My sincere apologies for both the length of this inquiry, and the redundancy to many of you who are on more than one of the mailing lists. My thanks for your patience and your help. BACKGROUND: Things I would like to do with my Apple: Text editing (writing papers, reports, and student evaluations) Programming (my previous experience is with LISP and LOGO) Teach my wife programming in LOGO Games and Puzzles (Sargon chess, backgammon, various "arcade games") Graphics hacking / art work Terminal dial up to larger systems (Cyber and Vax in Amherst area, and MIT-AI if I can obtain an inexpensive connection from Northampton-- this latter would be especially helpful to me) LISP programming and perhaps even some of my thesis research (AI) (i am unsure as to the feasibility of some of these things and would appreciate your disabusing me of any unrealistic fantasies) My current system consists of: 48k Apple II plus Apple disk drive (5.25 in.) with DOS 3.3 Epson MX-80 printer Home color TV (19" with SupRMod modulator) FANTASY SYSTEM: The following is the tentative plan I have for expanding my system. It is driven largely by my desire to run the AMETHYST software (MINCE and SCRIBBLE). SOFTCARD Z80 with CPM (so as to be able to run MINCE, etc.) 80 column, upper/lower case display 2nd disk drive (5.25 in.) 16k RAMCARD (to extend to 64k) modem (color monitor?) QUESTIONS ON SYSTEM EXPANSION: 0. Is my "fantasy system" feasible? That is, WILL IT WORK?? I am especially anxious to learn of any interaction effects or incompatibilities of pieces of the system I am considering. Are there components or angles I've overlooked? 1. Will there be enough slots to put it all together (i count 6)? Will some of them be wanting to go in the same slot? Will the Apple heat up and/or explode with all those boards plugged in?? If so, is it a solution to remove the power supply to outside the Apple casing? Would a good fan be adequate to do the job? 2. Is it worth the bother (and expense). I think I can scrounge up the money, but will I be reasonably satisfied with the final result or will I have only an expensive kludge? 3. Has anyone already tried a similar system? I would be EXTREMELY INTERESTED in corresponding with you to learn how it worked out!! 4. Are people happy with the Amethyst package? What are peoples' experiences with MINCE and SCRIBBLE on the Apple? How does SCRIBBLE fare when combined with the Epson MX-80? 5. Are there radical alternatives I should consider before committing myself further to this project? (eg. selling the Apple and building or acquiring an alternative system?) How serious a constraint is the 8 bit processor and 64k address space?? 6. Any specific recommendations or warnings regarding alternative hardware (such as 80 column boards, 16k ram cards, and modems)? In particular I am curious as to which (if any) of the 80 column boards would impose the least drain on the power supply? 7. Will a home tv provide adequate resolution for 80 column upper/lower case display? How much additional resolution would I get from a color monitor (for both text and graphics)? 8. Do ALL the 80 column boards automatically provide upper/lower case display? (I'm currently inclined toward the Videx Videoterm) 9. Is the Videx Keyboard Enhancer redundant with the Videoterm board? (if not, is it a reasonable way to upgrade the keyboard?) What is the best way for me to obtain keyboard entry of upper/lower case and other ascii characters (preferably using the shift key)?? 10. What should I look for in a modem? Is the Hayes Micromodem II everything its cracked up to be? Are there reasonable 1200 baud modems for the Apple? 11. Will Apple Pascal software run on the alternative 16k ram boards (Andromeda, Microsoft RAMCARD, etc.)? Would I really want Apple Pascal anyway? 12. Does anyone have experience with any of the "friction feed" add-ons for the MX-80 (such as Orange Micro's, or the one advertised for $15)? What about the dot graphics updrade (do I correctly recall they claimed this will also provide italic fonts?)? 13. How can I get the best prices on equipment I purchase? Are mail order houses generally reliable, or are some of them fly-by-nighters that may take my money and run? Are there ways I can get wholesale prices on single quantity (I expect I'm dreaming, but it can't hurt to ask). 14. Is service a big issue with micro-computer ownership? (I've only had my system for 3 weeks now). Should I be wary of Mail Order houses on this account? GENERAL INFORMATIONAL QUESTIONS: 1. Could some kind and patient soul please explain to me what is involved in Up and Down Loading? I understand (i think) that they have to do with shipping files (or is it just programs? -- please clarify) back and forth between micros and mainframes. Are the problems primarily due to differences in word size? or are there other more subtle issues that I can't imagine? 2. Has anyone developed a central catalog of software purchased or written by various people who would be willing to share their resources? 3. Any suggestions as to my best means for hooking into MIT-AI from the Northampton/Amherst area? Can I do network hopping through any commercial networks at reasonable prices? Are long distance phone lines reliable for transmitting information, or are they too noisy? Any and all suggestions will be gratefully accepted (and shared with our own Dave McDonald (DDM) who is also located in Amherst). 4. Can one get away with "turning over" diskettes and using the other side? One can cut out a second "write enable" hole, and store things on both sides of a diskette. Is there any danger of information bleed-through from using both sides simultaneously for storage?? Does the risk become greater as the disk surfaces wear away?? Thank you again for your patience and help. My apologies for this inordinately long message. I'm very anxious to get on as quickly as possible to expanding my system, but I'd like to benefit from all your prior experiences. Apologies also for the redundancy entailed in my sending this to the several "micro" mailing lists. Date: 29 August 1981 0823-EDT (Saturday) From: Bill Sholar <William.Sholar at CMU-10A> To: Brian N. Hess <BNH at MIT-ML> Subject: Bug Fixed CC: Amethyst-Users at MIT-MC Sender: William.Sholar at CMU-10A In-Reply-To: Brian N. Hess's message of 27 Aug 81 17:05-EST Message-Id: <29Aug81 082338 WS70@CMU-10A> The bug I reported was squashed when MOU released their revised MINCE accompanying their SCRIBBLE 1.3 -- change sheet dated 8/24/81. The version number of MINCE remained 2.6, however. For those who care, Keith Peterson's CRCK program indicates that these .CRL files were new: ATERM, CTERM, and LATERM. Bill Sholar Date: 25 August 1981 2249-EDT (Tuesday) From: Bill Sholar <William.Sholar at CMU-10A> To: Amethyst-Users at MIT-MC Subject: a bug? Sender: William.Sholar at CMU-10A Message-Id: <25Aug81 224949 WS70@CMU-10A> I have found that when I recompile and relink MINCE or LMINCE, even without changing anything, I encounter the following problem: MINCE filename seems to occasionally crash the system upon execution; C-X C-R filename seems to work if MINCE is entered without a filename as an argument, but the system crashes as soon as a TAB character needs to be displayed. As a test, I recompiled and relinked both MINCE and LMINCE using the unchanged sources and .CRL files, and using MC.SUB/LMC.SUB. Then I entered the editor, and tried to load BINDINGS.C. It appeared to load, but when I tried to move to the next page, the system crashed. I reset the system and tried again, using COMM1.C, and the system crashed after the first words of the first line. This occurred a bunch of times, with different compilations. The only thing that seems significant is that the crash always occurred when a TAB should have been displayed on the console. Has anyone else had this problem Comments Suggestions I'll contact MOU next . . . Bill Sholar <SHOLAR @ CMUA> Gyro@MIT-AI 07/05/81 13:40:28 Re: Missing(?) Commands To: AMETHYST-USERS at MIT-MC You are correct: there are no Insert File nor Write Region commands. But they're not hard to write, if you're willing to accept the kluge of secretly reading into and writing from the kill buffer (the kill buffer is available to code as a real buffer; you just can't get it onto the screen). So if you want them, write them! -- Scott Date: 1 July 1981 23:48-EDT From: Frank J. Wancho <FJW at MIT-MC> Subject: Missing(?) Commands To: AMETHYST-USERS at MIT-MC Did I miss something, or is there not an equivalent to M-X Insert File and M-X Write Region commands? (Yes, I know you can read a file into another buffer and kill and yank it into where you want it, and vice-versa, but that's kludgey.) As for being able to use my Edit Key, I stand corrected. By defining the console input to be direct port I/O, you are allowed 8-bit input... --Frank Date: 28 June 1981 14:27-EDT From: Scott W. Layson <Gyro at MIT-AI> Subject: Screen scrolling To: KENNER at RUTGERS cc: amethyst-users at MIT-MC At the very least, you have to: -- move the screen marks (in the "scrnmarks") array so that the i-th mark still corresponds to the i-th screen row. -- increment or decrement a variable, which I think is called "tlrow", that tells which screen row is in the current-row buffer. -- move the "sstart" mark, that tells where in the buffer the screen begins, up or down a line as appropriate. -- Set the modified flags on the lines that are being left blank, so they will be displayed at the next opportunity. There may be more, but this is all I can think of offhand. Good luck! -- Scott Date: 25 Jun 1981 0904-EDT From: Richard Kenner <KENNER at RUTGERS> Subject: Screen scrolling To: amethyst-users at MIT-MC Has anyone looked into what would be involved in doing the following: I would like to have KbWait perform the following function in addition to writing out modified pages: If the cursor is too close too either the top or bottom of the screen, send a "insert line" or "delete line" to the terminal (a H19 in this case) as appropriate to keep the cursor in the "center area" (say lines 5-15) of the screen. My question is: Does anyone know exactly what modifications I have to make to the screen status variables when I do this in order to have refresh correctly maintain the screen (and write the one line that remains to be written)? ------- Date: 24 June 1981 23:11-EDT From: Steven T. Kirsch <SK at MIT-MC> Subject: Commands to match parens, brackets, braces ... To: DWS at LLL-MFE cc: Amethyst-Users at MIT-AI Yes, bruce roberts at BBN has written display matching paren on ). He may also have indent for lisp and forward s-expr. I dunno if the display matching paren is as slick as the one done at SRI for Gosling's Emacs. Date: 24 Jun 1981 (Wednesday) 1511-PST From: DWS at LLL-MFE Subject: Commands to match parens, brackets, braces ... To: Amethyst-Users at MIT-AI Has anyone written commands to fine matching open and closed parens, brackets and braces? (e.g. Meta-( & co. in EMACS). If not I'll sit down this weekend and give them a try, then supply the code. Looks pretty easy, which in itself tells me that there is bound to be some trick required. -- Dave Smith --------- Date: 19 June 1981 15:04-EDT From: Devon S. McCullough <devon at MIT-AI> Subject: mince To: BUG-EMACS at MIT-AI, AMETHYST-USERS at MIT-AI MINCE is not Cthulhu's EMACS TECO...TECO...HAHA...TECO...... Date: 19 June 1981 04:33-EDT From: Barry A. Dobyns <BADOB at MIT-AI> To: AMETHYST-USERS at MIT-AI the AUG monthly newsletter will not be electronically transmitted to this mailing list by myself in the future. proccedings of this mailing list will not appear in any form in the monthly AUG newsletter. -barry Date: 6 Jun 1981 19:22:02-PDT From: Cory.conde at Berkeley To: amethyst-users@MIT-AI Subject: Query about MINCE,AMETHYST, etc.... To the caretaker of the Unicorn Guild, Hello, I have been told that this account could be used to direct queries on the Unicorn line of editors, and formatters. ( Brian Hess at MIT told me.. ) After hearing rave reviews of your software, I am seriously considering the purchase of the Amethyst package, but I want to know if it is compatible with my system. The ads claim that you must have a cursor addressable terminal, but the review in Doctor Dobbs said that it may be customized for memory mapped systems. I have an Exidy Sorcerer, with its brain damaged 64 by 30 memory mapped screen without cursor addressing, but with screen clear, and cursor movement. ( up, down, left, right only. ) Could MINCE run on that ? ( also, the keyboard polling is rather slow... ) Also, is SCRIBBLE an 'nroff' style formatter with codes like .ce for centering ? ( I hope so... ) Lastly, what really lured me was the inclusion of the BDS C compiler ( RAH! ) with the purchase of Amethyst.. Do I get the real stuff, with the stdio library package and the privilege to join the Users' Group ?? Well, sorry to bother you right before summer, but I would like some info , and if an 'on-line' brochure is available,I would love it. If not, you could send stuff to Daniel Conde 1145 Pine St., #15 San Francisco, CA 94109 Thanks, Daniel Conde1 y.conde @ BERKELEY Date: 28 May 1981 04:45-EDT From: Barry A. Dobyns <BADOB at MIT-AI> Subject: as if i hadn't said enough already... To: AMETHYST-USERS at MIT-AI It seems to me that Tabs are NOT conserved in a @VERBATIM[] environment. someone else want to check that out? how about a title page environment? Or a @Citation environment that has a separate counter from Note, and puts its contents into the bibliography? -overly verbose Date: 28 May 1981 04:15-EDT From: Barry A. Dobyns <BADOB at MIT-AI> Subject: local modes; verbosity; and indentation To: SK at MIT-MC cc: AMETHYST-USERS at MIT-AI 1. explain more verbosely 2. Sorry. I will try to be more brief. 3. Too late to do anything about this month's. I could send a ready-for-scribble-or-scribe file out every month, or just take all the indent out, as you wish. Geez, We're just beginning, so i can't be expected to be perfect (yet). -BADOB Date: 27 May 1981 22:18-EDT From: Steven T. Kirsch <SK at MIT-MC> Subject: local modes; verbosity; and indentation To: BADOB at MIT-MC cc: amethyst-users at MIT-AI 1. Using a Local Modes list at the end of a file is the "right" way to do local modes in emacs. -*- Teco-*- is historical. 2. The newsletter is too verbose. 3. Can you cut the indentation out of the on-line copy? Date: 27 May 1981 at 1938-CDT From: awd at UTEXAS-11 Subject: This is the June Newsletter for AUG, which just got into the Snail today. -BADOB (Barry Dobyns) To: amethyst-users at ai Amethyst Users Group Newsletter No.1 Amethyst Users Group The First Newsletter This is the first newsletter for the Amethyst Users Group. I had not expected to have anything to say so soon, but as it turns out there are a lot of things that everyone seems to be interested in. In addition to this users group, there is a mailing list on the MIT-AI, which I administrate (ARPANET is the Advanced Research Projects Agency NETwork, a DOD run computer network linking some 150 university, DOD, and industry machines). I urge all of you who are users of the ARPANET to have me put you on this mailing list. There will be abstracts of the discussions that the AMETHYST-USERS generate in each monthly newsletter, but the discussion-like forum of the mailing list will make it a real plus if you have access. If enough folk request it, I will include complete transcripts of AMETHYST-USERS mail in this newsletter each month, instead of abstracting it (fine with me, since it saves me work). The reason that I am initially abstracting it is that I suspect it will run to great length, and it will get very bulky (and expensive to mail). This mailing list is free (not that I would charge, but it has to be, since any profit generating activities are strictly forbidden on the ARPANET, and although the users group is non profit, I have already had my knuckles rapped for trying to drum up support for the users group). As I worked on this, our first newsletter, I saw that there are going to be a lot of very verbose (of necessity) comments and suggestions that I am going to receive here. I guess I will publish in full, or at least as much as I can, any relevant info, tips, or ideas that are sent me. If you are an ARPANET user, mail AI as I can read it with my machine, and save time and errors. I would like to request that all correspondence intended for Amethyst Users Group be sent to: Amethyst Users Group University Station Post Office Box 8173 Austin TX 78741 All hate mail to me personally can be sent to the old address: (my home address) - 1 - Amethyst Users Group Newsletter No.1 Barry A. Dobyns 1633 Royal Crest #1128 Austin Texas 78741 Hate mail sent to the P.O. Box will be included in subsequent issues of the newsletter (subject to edit, naturally). My telephone number is (512)441-9466, and feel free to call me anytime, i am usually up until all hours of the night. Something that will no doubt take up a lot of space in the first few issues of this news letter will be simple suggestions. I am not the wizard at C hackery that some Amethyst owners are, so this issue is full of ideas I have had kicking about, and have not had the time to begin to implement. I throw them out as germs of ideas that someone else may also like, perhaps enough to do the work, or work with me to realize some of these things. Your suggestions for extensions are also welcome as much work can be avoided by properly defining the task at hand, and this letter can be a forum for defining and determining the shape of extensions yet unborn. I offer without apology some suggestions here that are blatantly EMACS-like, even to the point of lifting descriptions from the EMACS manual. This may seem snobbish to non-EMACS users, but it is just that I have experience with EMACS. It is probably true that EMACS and PL/1 share the fact that both are too large for any one user to ever expect to use all the features of the language. I am pointing out those features of EMACS that I tend to use that are not included in the standard MINCE. Feel free to tell me that you don't need them or that you think my MINCE will grow to over a megabyte. Modes One of the things that is of interest is how automatic mode switching in MINCE is to be implemented. I have seen several basic ways, and each have their good points and their bad points. 1. The first is one that many people support as 'natural' to a CP/M environment. This is to have MINCE set the mode for the buffer based on the extent of the file in that buffer. This technique is one that requires no additional information to be included in the text file itself. In other words, a file with the extent .PL1 would set the - 2 - Amethyst Users Group Newsletter No.1 (nonexistent) PL1 mode, and a file with the extent .C would set the (nonexistent) C mode. This is a very clean implementation, and one that poses few problems, at least when one is only dealing with source code of one sort or another. 2. If your extent names are not of a nature to provide useful information to MINCE, fear not. I often use extents that are just numbers, increasing as those inevitable revisions occur. I want my MINCE to automatically increment my extent numbers on C-X C-S operations. Unfortunately, the extent is not going to provide useful information for SetModes in this case. A solution to the problem is to include on te first line of a file a command of the form -*-MODENAME-*- or something like that. This will horrify some of you no doubt. It can be included in your source files as a comment, and is a relatively benign way to do things. This is one of the ways that EMACS does it, and i suggest it as something to mull over. Lots of poeple are vehemently opposed to this because they see it as 'messy'. 3. Another option is to have an 'init' file someplace. For example, my 'system' diskette, in the A drive might contain MINCE, a compiler, a linker, and whatever else I use all the time. My work disk in the B drive might contain copies of whatever it is I am doing, and file that has default settings in it. A TEXT.INI file might contain information concerning the mode I normally like to edit text in, how I usually set my tabs, where the indent and fill columns are, and of course room for expansion. Mince would look for a 'filename.INI' on the logged drive first (so I would have to enter MINCE from B:), and load these parameters, superceding any values set in the .SWP file. Maybe this is too much of a kludge too, and the more I think about it, the worse it gets. It may also be possible to put default modes in the .SWP files, but .SWP files are awfully big, and I don't relish having a lot of them around, whereas an .INI file only need be a few pages long, if that. This has fundamental problems with hard disk that is not split up into numerous logical drives, since MINCE would just pick up on the first .INI file it found. It would work well with MARC or any **NIX, where your working directory would have the .INI file and just a link to MINCE in another directory. 4. Personally I support a system that first checks to see if the extent corresponds to a valid mode, or if it does not, looks in the first line for a modename, or failing all of the above sets the default mode (from the .SWP file, which means that CONFIG now has to set this sort of thing up, 65K CONFIG here we come....). - 3 - Amethyst Users Group Newsletter No.1 There is another fundamental problem in just what one expects out of a Mode. I think everyone expects for a mode to redefine basic syntactic movement units (paragraph, sentence and word) to be more useful (e.g. function, statement, atom) in the new context. Many folks expect balancing of certain syntactic delimiters (parentheses in LISP, or curly braces in C). Matching of Scribble delimiters in .MSS mode would be nice. Some expect indentation to be automatic, others are content to merely have a pretty printer bound to M-G (Grind Text, I find it more mnemonic than M-Q), most want both. Should there be a rudimentary parser in the mode to check for correct syntax (and help put those semicolons in the right place in ALGOL)? Remember that the more we add the bigger this thing gets, and the farther out of hand it goes. As soon as Mark of the Unicorn adds overlays, we can do some nf these more exotic things. Macros Another thing folks seem to be interested in is macros. Some have suggested that macros be only a single line long (and displayed in the echo line), and others have suggested editing macros in a buffer, and then executing them out of the buffer, (shades of Minibuffers full of TECO code). I would be happy with an 80 character macro buffer (better yet three or four different macro buffers) to which I could give a repeat count, as i'm hard pressed to think of many sequences that will require more than 80 characters. The advantage I see in having them in regular buffers is that they can be saved like any old file. I haven't thought much about macros or macro buffers, so i'm ready to hear some input from you about the topic. There is a problem in that I can't think of a good place to put macros. I don't want them in my terminal support but since the low level character I/O gets called from everywhere I can't think of many other really good places. Once again, I haven't thought on this one much longer than it took to write this. Command Line Options Another good suggestion is loading more than one file into separate buffers from the original command line. It doesn't sound too hard to me, except that I could easily see the .SWP file overflow if you use this one much with those files that seem to grow to excess. - 4 - Amethyst Users Group Newsletter No.1 Marks and Kills on a Ring I would like to see more than one mark available. Perhaps we could have a ring buffer (circular array) of marks, and a command that rotated the ring. Kill rings would be even nicer, of course. Inspiration for this comes from tinkering with EMACS, but I haven't the slightest idea how to begin implementation. M-' Fix up omitted shift key on digit Quoted from the EMACS Manual for TWENEX Users: Another common error is to type a special character and miss the shift key, producing a digit instead. There is a special command for fixing this: M-' (^R Upcase Digit), which fixes the last digit before point in this way (but only if that digit appears on the current line or the previous line. Otherwise, to minimize random effects of accidental use, M-' does nothing). Once again, the cursor does not move, so you can use M-' when you notice the error and immediately continue typing. Because M-' needs to know the arrangement of your keyboard, the first time you use it you must supply the information by typing the row of digits 1,2,...,9,0 but holding down the shift key. This tells M-' the correspondence between digits and special characters, which is remembered for the duration of the EMACS. This command is called M-' because its main use is to replace "7" with a single-quote. The correspondence between digits and characters could be stored in a .SWP file or a .INI file (above). Of course, it could be implemented just as described here with the initialization code existing as an overlay to save space. Bugs and Quirks Here are some bugs/quirks I have noted in Scribble/Crayon in preparing this letter. - 5 - Amethyst Users Group Newsletter No.1 1. The -p option in Crayon causes the pause to occur before the newline at the end of the page. This causes problems if your printer waits to print a line until it recieves the newline at the end of the line, as mine does, since you will not get a page number at the bottom of the page, but at the top of the next one instead. PageHeading directive can only appear once, or Scribble tells you that you lose, I didn't see any note in the manual about this. CDOS Compatibility I have done work getting MINCE, SCRIBBLE, and MARC (more on MARC later...) up on various versions of CROMEMCO CDOS (TM). The verdict is that MINCE and SCRIBBLE choke (do not run at all) on all versions of CDOS before 2.12, which includes but is not limited to 0.17, 0.20 and 1.07 CDOSii. MINCE and SCRIBBLE (and compiling and linking with BDS C 1.43 and the L2 linker) seem to be fully functional in CDOS 2.12 and 2.17. It seems that there is an incompatibility in early CDOS versions in that two of the locations in the BIOS jump table (or two of the BDOS commands, I forget which) are reversed. I have forgotten just how much slower CDOS is than CP/M. I am getting the CP/MUG #49 which has a CP/M 2.2 BIOS for the 4FDC on it, and I will report on how AMETHYST fares in this environment. MINCE should be incredible on PerSci drives. If you seem to have incredible problems getting anything to work under your CDOS, and there is no local CDOS wizard who can wave his magic software patch wand, I recommend the following man whom I have never met personally but who has commanded the respect of a lot of my friends and whose coding can only be described as incredible. He specializes in CDOS systems, and so can probably help you out. Robert Gunn Gunn Software 6200 Stillman Houston, Texas 77027 (713) 861-4766 - 6 - Amethyst Users Group Newsletter No.1 Mr. Gunn doesn't have a AMETHYST yet, but I'm going to go to work on him as soon as I can. In any event his knowledge of CDOS is probably indespensible. MARC is an operating system soon to be marketed by BDS Software, which appears to the user to be a single task UNIX (in other words, many users, but only one at a time). There were plans at one time to include MINCE as the system editor for MARC. As I understand it, MARC will come with BDS C, and assembler, an editor that looks a lot like the UNIX ED, MINCE, a handful of utilities, and (possibly) a CP/M <--> MARC transfer utility, and a CP/M emulator for MARC. I have gotten MARC (Boot Version B.7, Root Version B.1) up on CDOS 2.12 and 2.17, but in order for MARC not to choke to death, the -R option MUST be specified. It seems that the parasitic booter can't tell which drive is the logged one when it's run under CDOS. Comparison Chart One of the members of the mailing list is interested in seeing a MINCE to EMACS difference/comparison chart. If anyone is interested it seems to me that the task could be done up very nicely, and easily. Since most EMACS installations have the manual online someplace, and near the end is a wall chart that is very similar to the MINCE short command list, and we have SCOMM.DOC online, so that one only needs to hack the two files into one. A double column command comparison (or better yet, three column: ITS EMACS, TWENEX EMACS, MINCE) should only waste about half a day of someone's time. It probably wouldn't take much work other than a lot of cut and paste in the editor. The First Submission Of course, I have submitted it: it's called MLIST.C. It's basically a very simple mailing label printer, the one I am using to keep track of the AUG membership. There are no fields, no record sizes, only record marks in the data file. Mince is used for updating (since it has all the features I need in such a program). Most mailing list systems I have seen either limit you in the information you can include, or waste lots of empty space with half full records of fixed length. Besides, all the ones I have seen seem to cost more than I think they are worth. I include MLIST in the AUG library since it depends on MINCE to make it go. - 7 - Amethyst Users Group Newsletter No.1 The file format is as follows: anything up to the first delimiter DEL1 is ignored. I include information on how the file is formatted, and what the file is full of before the first DEL1 delimiter. Everything between DEL1 and DEL2 is printed (CP/M list device) and are followed by enough newlines generated by the program to get to the next label. Everything between DEL2 and DEL1 is ignored. I can keep telephone numbers, dates of valid membership, net addresses, whatever between DEL2 and DEL1. I also include a line with about a dozen hyphens as the last line before DEL1 so that the breaks between entries is easier to see. Here it is: #include bdscio.h #define DEL1 0x1f /* C-<underbar> */ #define DEL2 0x1e /* C-<caret> */ main(argc,argv) char **argv; { char ibuf[BUFSIZ]; char line[132]; int ifd, on, lcount, i; on = i = lcount = 0; if (argc != 2) { printf("Usage:\nMlist infile "); exit(); } if (fopen(argv[1],ibuf) == -1){ printf ("File open error on %s",argv[1]); exit(); } printf ("%s",argv[1]); while (fgets(line,ibuf) != 0){ lcount++; if (DEL2 == line[0]){ if (on) do { lcount++; fputs(" \n",2); }while (lcount <= 12); /*label length*/ on = 0; }else if (DEL1 == line[0]) { on = 1; lcount = 0; }else if (on){ fputs(line,2); } } fclose (ibuf); } - 8 - Amethyst Users Group Newsletter No.1 Miscellaneous I am charging $6.00 annually for membership in the Amethyst Users Group in North America (USA, Canada, Mexico and California). I will charge $14 for annual membership for members in distant lands. Membership privileges include getting your name and suggestions in print, having this newsletter delivered to your doorstep by your friendly mailman, and access to the users group library. Initially, disks, should they ever become available, will be $6.00 each. I have no idea how much Disks will cost to ship to anyplace outside of the USA, so you will have to wait until I go to the post office with a packed diskette box and weigh it. If it turns out that I lose money on the users group (I can't afford to pay out of my pocket) I will raise the cost of diskettes, and not the cost of the membership. I will ship you diskettes in diskette mailers that should protect them from the worst ravages of the USPS. These mailers cost me a little more, but are well worth the price, since disks arrive in one piece, and unfolded. I will not be able to personally reply to every inquiry that will be made, although I will include it in the next newsletter. If you expect an immediate response, enclose a self-addressed stamped envelope, it may not seem like much to you, but if I have to buy twice as many stamps and envelopes each month, this poor boy will be in the lurch. If you wrote to me asking to join and forgot to enclose your membership fee (or plain didn't know that there was one, which is probably my fault), you get one (and only one) free copy of the next newsletter, to pique your interest, and oil your wallet bone. In other words, if you haven't paid your membership fee, this is your free copy. This newsletter will be mailed over the ARPANET to AMETHYST-USERS also. Please specify the format that you want (or if you're sending, write the the format on the label). I can distribute in Single Side Single Density IBM 8" format, Tarbell 8" 51 Sector Double Density, Ohio Scientific CP/M 8", and Cromemco CDOS 5 1/4" Single Density, and eventually, in N* single density (I just recently got a N* controller board without docs or software, and am trying to scrounge up enough info to get it to fly). Please, if you send me a IBM 8" diskette, do not send me one that you have reformatted with your single density controller, since I use a controller that has a 1791 on it and it cannot read the gap information that the 1771 writes onto the disk when formatting. If I am to read it it must either be on a disk that is still using the factory format, or if you have a Tarbell Single Density controller, I can give you a format program that you should - 9 - Amethyst Users Group Newsletter No.1 replace your current one with, that will format disks so that we both can read them. I will also offer a transfer service from one of the above formats to another at about $2.00 per disk, plus diskette and shipping, (i.e. provide your own diskettes for me to copy to and save). I should be able to distribute in RT-11 format also, that is, I have an RT to CPM transfer utility that seems to function properly, but I don't have an 11 to run the resultant copies on, so caveat emptor for RT. Also the RT to CP/M utility asks some questions (about how the directory should be arranged) that i'm not quite sure i can answer correctly, never having used an RT. Please pack any disks you send me properly (i.e. in one of those nice boxes from INMAC that I will be using). This point was brought home some days ago when some disks that had been improperly packed (but were sent special delivery) were FOLDED into my mailbox (special huh?). Any disk you send me with useful things on it, I will you one for, hopefully with something neat on it (your choice, once there is something to choose from). Proofreading this, I see that I have tended to use a lot of 'computerese' and have favored terse technical terms to verbose plain-text circumlocutions. I sincerely apologize to those who are lost. The directions for getting there (as they were given to me...) go like this: Go to San Diego and take a left, and keep going until the water is up around your hubcaps. Get out of your car and get a suntan. Play Frisbee. Use the nearest pay phone to call AAA and your lawyer, who will send you a travel guide and tell you how your divorce proceedings are going, respectively. Enjoy. Happy Coding! -Barry - 10 - ------- Date: 25 May 1981 00:08-EDT From: Scott W. Layson <GYRO at MIT-AI> Subject: ^X ^S write to temp file and rename To: SK at MIT-AI, Tappan at BBNG cc: AMETHYST-USERS at MIT-AI One reason that we gave ^X ^S its current behavior is just what SK mentions: if your disk is very small, you can't afford to keep free space sufficient to hold your largest file. Another is that we expected by now to have incremental state save working, that would make it possible to use the information in the swap file to recover from hardware errors. Unfortunately, we ran out of memory before we got there. Sigh. -- Scott Date: 22 May 1981 02:03-EDT From: Steven T. Kirsch <SK at MIT-MC> Subject: FJW's nits To: GYRO at MIT-AI cc: AMETHYST-USERS at MIT-AI In addition to sending those enhancements to BADOB, can you also put them on-line somewhere? Date: 22 May 1981 01:57-EDT From: Steven T. Kirsch <SK at MIT-MC> Subject: ^X^S writing to a temp file and rename To: Tappan at BBNG cc: AMETHYST-USERS at MIT-AI, GYRO at MIT-AI Making this standard would meet with some objection as some of us only have a single 5.25" disk. Date: 21 May 1981 0825-EDT From: Dan Tappan <Tappan at BBNG> Subject: Re: FJW's nits To: GYRO at MIT-AI cc: AMETHYST-USERS at MIT-AI, Tappan at BBNG In-Reply-To: Your message of 21-May-81 0018-EDT Why would someone use ^X^W? Actually thats my major gripe about MINCE, ^X^S does an immediate overwrite of the old file. I lost a fairly large file once through a freak disk accident (MINCE started writing the file, clobbering the old one, then a disk error occured on the swapping disk, making CPM decide it was read-only, which crashed MINCE and lost all copies of the file) Using ^X^W would have prevented that (as would a slightly more intelligent ^X^S). As soon as I have time I'm going to fix ^X^S to write to a temp file and then rename. Dan ------- Date: 21 May 1981 00:18-EDT From: Scott W. Layson <GYRO at MIT-AI> Subject: FJW's nits To: AMETHYST-USERS at MIT-AI We consider it a feature that Mince recovers well from a full swap file. What else should it do? There are several opinions as to what should be in the other window after a ^X 2; the only one we really like would take too much space to implement. Why can't you use your Meta key? We use ours... Just like you said, change the I/O to do direct port access with 8 bit characters. It works fine (if your hardware cooperates). Why does anyone use ^X ^W? I mean, sure, I use it a couple of times a week, but ^X ^S is much more convenient for the usual case... (And safer if the ^X gets lost!) I have code to make meta-<digits> work. I will send it to Barry. It's not very big, but takes just enough space that the redundant functionality was considered wasteful for the standard version. Other people have complained about ^W/^Y to move text. We don't have q-regs, but a command to move or copy the region to or from a specified buffer in one operation would be easy enough. Somebody write it! Yeah, we know, framing (choosing exactly what text shall appear on the screen) is one of Mince's weak points. I have code, which I will also send to Barry, to scroll the screen up or down by a specified number of lines without moving the point. This helps somewhat. The @BlankSpace bug has been fixed. Is ^S insufficient for controlling the -c output? It seemed fine to me, especially since Scribble pauses for a moment to set up between pages. Scribble itself doesn't know about XON/XOFF for the printer; in fact, it doesn't pay attention to the direct I/O either, it just does bios(5,c) to get characters out. Crayon, however, should do the right thing for you. The latest Scribble (1.1) is much happier in 56K; 1.0 is truly a memory hog. Cutting Scribble's memory requirements is currently a top-priority project. I think Craig is working on something to let you turn off higher levels of sectioning, so you can just have plain numbered paragraphs. There are a couple of bug fixes in the C compiler since 1.42. Other versions around 1.43 have different bugs; there is in fact only one version of the compiler that will successfully compile Scribble, and Lifeboat never shipped it. But it had another bug... Keep those cards and letters coming, folks! -- Scott -------- Date: 21 May 1981 00:33-EDT From: Christopher C. Stacy <CSTACY at MIT-AI> Subject: FJW's nits To: GYRO at MIT-AI cc: AMETHYST-USERS at MIT-AI Date: 21 May 1981 00:18-EDT From: Scott W. Layson <GYRO> To: AMETHYST-USERS Re: FJW's nits Why does anyone use ^X ^W? I mean, sure, I use it a couple of times a week, but ^X ^S is much more convenient for the usual case... (And safer if the ^X gets lost!) I use C-X C-W to write into a file which has another name in Emacs, I assume it works the same way in Mince. What do you mean by "safer"? Yeah, we know, framing (choosing exactly what text shall appear on the screen) is one of Mince's weak points. I have code, which I will also send to Barry, to scroll the screen up or down by a specified number of lines without moving the point. This helps somewhat. This should be standard in Mince, I think. Date: 20 May 1981 05:09-EDT From: Frank J. Wancho <FJW at MIT-MC> Subject: Random Bugs (nits) and Feature Requests To: AMETHYST-USERS at MIT-AI cc: FJW at MIT-MC I have asked Scott if he wanted these "privately" or to the list. Although he hasn't seen these items, he said to the list. So here it is. Bear in mind that I really do like Mince for the reasons I gave in a previous msg, but I find some things annoying... As for Scribble, I will acknowledge that it is a preliminary release. <NIT MODE ON> On Mince 2.5: With a 64K SWP file, trying to read in a second file (both about 37K) in the other window gives a "Swap file full" message, if you're watching at the time and lucky enough to catch it, and then proceeds as if nothing happened - that is, until you try to read past a certain point in the second file and see the wraparound. The second window ought to be empty when you first invoke it with ^X2. Since I have a terminal with a META key, why can I not define it and change the I/O to do direct port access and preserve the parity bit for this purpose? Random msgs, like "Unknown command" ought to return the cursor to where it was. Deliberate displays, like from ^X^B ought to gobble up the next character and return the display to normal rather than taking whatever the next character is as input. ^G works, though... If a swap happens to occur just as you typed ^X^W and it comes back to see just the ^W... also, if you type just a CR to the ^X^W prompt, the current filename is very briefly displayed with no chance to confirm! The "Swapping" msg writes over a previous "Unknown command" msg and leave part of it there. I miss being able to type <ESC>n or <ESC>nn, etc., instead of the rather painful ^Un or ^Unn as a multiplier. I dearly miss ^Xx<qreg> and ^Xg<qreg> as a neat way to move text around as an alternate to ^W/^Y. If you choose the cursor position for redisplay as 0 (or any number, I guess), it *ALWAYS* puts the cursor at that line, even for M-> (an empty screen for 0) and ^S/^R. (Will there ever be an Incremental Search???) I would much prefer being able to specify, say, line 8 for ^L, and have the equivalent of 90fs%end for things like adding text to the end or M->, and also have <ESC>0^L for scooting the current line up to the top of the screen... With a line 0 for any redisplay, things are really strange with repetitive ^S's when you are on the bottom of the screen and it scoots up one line for the next occurance instead of presenting a new screenful... On Scribble 1.0: You can't seem to type: @BlankSpace(2 lines) wherever you want - just once it seems. When you use the -c feature for previewing, it ought to optionally wait for any character input before proceeding to the next screenful. (Maybe -c for continuous with short pause, and -t for wait???) I set up a Direct Pin and Direct Pout and set for Diablo10 and changed the sync for XON/XOFF and SCRIBBLE ignored it for a XEROX 1750 (Diablo 1650) and overran the printer's buffer. (I know it works ok with WS at 1200 baud... because that's what I had to revert to...). I never got to CRAYON because I tried to generate the FIN file and ran out of memory in a 56K machine with a 5K document!!! (I was able to generate a FIN file on a 58K machine earlier for Spin10...) How can I tell SCRIBBLE that I just want plain numbered paragraphs? (Not @Enumerate, since I may want unnumbered paragraphs in between. "0.0.0.1" from just having @Paragraph w/o any higher level numbering isn't exactly what I had in mind...) On documentation: If you buy AMETHYST, should you also get instructions on how to use BDS-C to create whatever - a sample session would greatly help there. How different is this BDS-C from 1.42 which we also recently got as an update from Lifeboat separately? <NIT MODE OFF> --Frank Date: 13 MAY 1981 0954-PDT From: BHUBER at USC-ECL Subject: Amethyst vs Apple CP/M To: Amethyst-Users at MIT-AI cc: BHuber Is Amethyst et al available now for the Apple Softcard CP/M world? BHuber ------- Date: 12 May 1981 21:26-EDT From: Scott W. Layson <GYRO at MIT-AI> Subject: Z-80 optimizations To: AMETHYST-USERS at MIT-AI Leor's compiler currently does no Z-80 optimizations; the only thing that can happen differently on a Z-80 is that the 'movmem' library routine uses the Z-80 block move instruction. And if you look closely at the problem, it turns out that the compiler really has little to gain by using the special Z-80 instructions -- the index registers are nearly useless, though admittedly, relative jumps would save a few bytes here and there. Even if the compiler was intelligent about Z-80s, recompilling the command set would do little good. The place where optimizations would really make a difference is in the buffer management and redisplay code (i.e., the parts for which we don't supply the source), as these account for about 2/3 of the final code size and are written in such a way that any optimizations in register usage (for example) will make a considerable difference. The command-set code is mostly subroutine calls, while the buffer and redisplay code is heavy on repetitive pointer-to-structure references and the like. So don't ask about Z-80 optimization -- Leor has no plans to do it anyway. Sometime in the next few months we may hand-compile the buffer and redisplay code into assembler, and THAT will make a difference. Besides, there are plenty of very useful optimizations Leor could do that would also make a difference in 8080 code; these, I think, would be more worthwhile. -- Scott Layson Mark of the Unicorn ------------------- Date: 11 May 1981 07:29-EDT From: Barry A. Dobyns <BADOB at MIT-AI> Subject: Amethyst Users Group To: mbarnes at BBNA, devon at MIT-MC cc: "(FILE [JCAF;MC:AUG ARCH])" at MIT-AI congratulations, you are on. archives in mc: jcaf; aug arch please read mc: jcaf; aug let -barry Date: 10 May 1981 13:20-EDT From: Frank J. Wancho <FJW at MIT-MC> Subject: Z80 Only Version? To: AMETHYST-USERS at MIT-AI cc: FJW at MIT-MC I am really quite impressed with MINCE, especially in that it uses the LRU algorithm - it appears that I can directly access any part of the file without paging the file through memory (unlike WS, WM, and others). What I'd like to know is if I can recompile the command set as is and use the Z80 option to gain some optimization for my particular environment? As far as that goes, has it been determined whether or not an entire MINCE (and SCRIBBLE) completely compiled with that option is any smaller or runs any faster than the regular version? In particular, I am interested in the relative speeds of the searches in both cases. (I sure do miss the Incremental Search commands...and the q-regs... - has anyone generated a list of the differences between MINCE and EMACS??) --Frank Date: 6 May 1981 04:39-EDT From: Barry A. Dobyns <BADOB at MIT-AI> Subject: archiving, and a query To: AMETHYST-USERS at MIT-AI we are now archived in mc:jcaf;aug arch special thanks to plk@mc for generously providing us space. someone wanted to know a bit more about amethyst... for those of you who are not actual owners of the package here it goes: amethyst is an ersatz emacs and an ersatz scribe for the 8080 and z80. both are extensible, and are written in bds c. the source for thecommand set is provided with amethyst, so that users can hack up extensions to fulfill their every desire. it is hoped that this mailing list, and the actual user's group (which is a discrete entity) will create a forum and community in which valuable extensions andddevelopments will be shared by all, and no one will spend time reinventing the wheel, (provided someone invents it in the forst place). both mince and scribble (the components of amethyst) can run and compile in a 48k cp/m. a cpm compatible operating system is nominally required for operation. cdos, sdos, imdos, tpm, oasis, and marc all should fit the bill. also one needs a cursor addressable terminal but i suspect that one could accomplish some magic in the terminal support routines that would do very nicely for a memory mapped video board. mark of the unicorn, the authors, are ambitiously working on getting amethyst onto other machines that support c. i am given to understand that the entire package is very portable, and running under one of the new **nix breed of operating systems is not a difficult task. bds c can run on a modified cpm (org=4300) but i do not know if work has been done to get amethyst onto such a system. my personal reccomendation is to have a 64k system, with double density drives (persci's since they're so fast) or a hard disk, and marc or a similar 'new age' os. the amethyst users group is a non-profit organization, dedicated to the furtherance of the amethyst system. aug is not directly connected with, or sponsored by mark of the unicorn, the authors of amethyst.mark of the unicorn, however, does retain a membership in the amethyst users group, so that no one is groping in the dark, so to speak. any fees, dues, or charges levied by the amethyst users group for membership, publications, or programs & associated media reflect the actual cost incurred in the production therof, and do not result in the generation of profits. the amethyst users group is not connected with this mailing list, except in that there may be an overlap in membership & membership in one does not imply membership in the other, however it may appear. -barry Date: 5 May 1981 05:10-EDT From: Christopher C. Stacy <CSTACY at MIT-AI> Subject: mailing list To: AMETHYST-USERS at MIT-AI Please remember that any use of the ARPAnet for commercial purposes is strictly forbidden. This will save us all alot of headaches. Cheers, Chris Date: 5 May 1981 03:24-EDT From: Barry A. Dobyns <BADOB at MIT-AI> Subject: A Letter To: AMETHYST-USERS at MIT-AI 4 May 1981 Dear Amethyst Owner; You have by now heard of the Amethyst Users Group, of which I am head. It is the nature of things that everyone eventually gets what he wants, and for my sins I was rewarded with charge of the users group. Your ideas are by all means welcome, as this is just as much your users group. EMACS has benifitted greatly from a healthy interaction of its users, and it is hoped that MINCE will be able to follow this tradition. I will put out a written newsletter. I suppose that I will have to have something to say first, or else you will be subjected to my incessant ramblings (unpleasant at best). The solution is for you to contribute things to the cause. If you are working on some project in particular, like a C mode, I can publish a note in the news letter about it (as verbose as you wish). Between news letters, if more than one person or group appears to be working on the same thing, I will try to put them in touch with each other, to speed the process. I cannot eat the cost of publishing and mailing newsletters and disks, so I will be forced to charge a bit for membership, primarily to subsidize mailing you newsletters & such. For the nonce, I will charge $6.00 for membership (an annual fee). Disks, when and as they become available, will also run $6.00 each. These are North American prices, Botswana costs more. If i start to lose money, i will raise the cost of diskettes, but i don't expect to start losing any soon. There is an ARPANET mailing list, which is is free, and is called AMETHYST-USERS at AI. You can send net mail to me, BADOB at AI, and i will put you on. If you have access to the net, i urge you to get on this mailing list, as there will no doubt be much more action here that i can account for in the monthly letter. I can distribute in Single Side Single Density IBM 8" format, Tarbell 8" 51 Sector Double Density, Ohio Scientific CP/M 8", and pending the return of my 4FDC from the factory (next week, I'm told) I should be able to distribute in Cromemco CDOS 5 1/4" Single Density . I will also offer a transfer service from one of the above formats to another at about $2.00 per disk, plus diskette and shipping, (i.e. provide your own diskettes for me to copy to and save). I should be able to distribute in RT-11 format also, that is, I have an RT to CPM transfer utility that seems to function properly, but I don't have an 11 to run the resultant copies on, so caveat emptor for RT. Please pack any disks you send me properly (i.e. in one of those nice boxes from INMAC). This point was brought home a few weeks ago when some disks that had been improperly packed (but were sent special delivery) were FOLDED into my mailbox (special huh?). I should have a post office box now, which may or may not help matters. Any disk you send me I will send back, hopefully with something neat on it (your choice, once there is something to choose from). As of right now, there is nothing in the library, and while a few people are interested in geting something, i haven't heard of any projects to write anything. Also, there is no archive (per se) for the AMETHYST-USERS, so if you have an account on an ITS amchine, and have some space to spare, perhaps you could let us archive there. Amethyst Users Group Barry A. Dobyns P.O. Box 8173 University Station Austin, Texas 78741 (512) 441-9466 Date: 5 May 1981 02:49-EDT From: badob@ai Sender: SLB0 at MIT-ML Subject: Amethyst-Users at AI To: lauren at UCLA-SECURITY, tappan at BBNG, clements at BBNA, jp at SU-AI, mmd at SU-AI, dws at LLL-MFE, BHuber at USC-ECL, blue at MIT-MC, plk at MIT-MC, moore at USC-ISIB, white at SUMEX-AIM, kenner at NYU cc: badob at MIT-AI Congratulations !! You are now on the list. BADOB@MIT-AI 05/03/81 02:31:50 Re: Amethyst Users Group Mail list To: EPZ at MIT-AI, GUMBY at MIT-AI, pga at MIT-ML, bnh at MIT-ML To: sk at MIT-ML, leor at MIT-MC, fjw at MIT-MC CC: BADOB at MIT-AI you are all now on it. Amethyst-users@ai -barry Date: 3 May 1981 02:41-EDT From: Barry A. Dobyns <BADOB at MIT-AI> Subject: info-micro@ai To: info-cpm at MIT-MC cc: BADOB at MIT-AI There is now a users group for Amethyst users. Plans include a monthly newsletter, and distribution of submitted user extentions. Amethyst (for those who don't recall) is a EMACS-ish extensible text editor and a SCRIBE-ish extensible formatter all in C. Amethyst Users Group P.O. Box 8173 Austin, Texas 78712 (512) 441-9466 Also it exists as a mailing list, AMETHYST-USERS@AI. if you are interested in either mail to me, or snail to the above address. -barry Date: 3 May 1981 02:45-EDT From: Steven T. Kirsch <SK at MIT-MC> Subject: mince crash To: amethyst-users at MIT-AI My second day using mince, I gave a demo to my boss. About 75% through the demo, mince (or my H89) crashed (it stopped listening to the keyboard so I rebooted). On restarting Mince, I discovered it was hung (cursor stopped to the right of the modeline; keys had no effect). I did a filecopy of a backup swap file to my disk and the world was safe for humans. Has anyone else encountered a similar problem? (Oh, I haven't read any of the documentation yet, so it might be in there). Date: 3 May 1981 03:09-EDT From: Barry A. Dobyns <BADOB at MIT-AI> Subject: crash! boom! munge! To: SK at MIT-MC cc: AMETHYST-USERS at MIT-AI I have problems with my (perkin elmer fox 1100) hanging from time to time, and so i have to twiddle the switches under the access plate to reset the machine, but mince hasn't really died on me but for one time... I had told it C-X C-S, and the lights on my front panel said that things were progressing ok, and then it hung. Before the 'File Written' prompt. I could tell by the lights that it wasn't in cp/m at all, it was down below 0x0fff someplace. (i diddled with the switches under the access plate, force of habit, but nothing...) Reset. look at the disk, and the file, which should have been around 25K or so is 1K long. use disk.c to reconstruct the file from the fragmented remains. I was assured that my problem was a random accident related to the tides & other similar phenomena. I am inclined to agree with that prognosis, as my system often hangs when i run my 'slightly crufty' memory boards instead of my 'not as crufty' board. still, i would be curious to know what it was thet you were doing when the loss occured. -----