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.

-----
