31-Oct-82 18:49:00,261;000000000000
Date: 31 October 1982 20:49-EST
From: Paul L. Kelley <PLK at MIT-MC>
Subject:  AUG newsletters
To: CSL.JLH.Celoni at SU-SCORE
cc: AMETHYST-USERS at MIT-MC


Dear Father Celoni,

The AUG users group disk is in AR0:JCAF; on MIT-MC if that is a help.

23-Apr-85 14:02:57-MST,630;000000000000
Return-Path: <@MIT-MC:[email protected]>
Received: from MIT-MC by SIMTEL20.ARPA with TCP; Tue 23 Apr 85 14:02:29-MST
Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA; 23 APR 85 15:54:40 EST
Date:  Mon, 22 Apr 85 20:47 EST
From:  [email protected]
Subject:  Oops...
To:  [email protected]
Message-ID:  <[email protected]>

I forgot to tell you all that MINCE is up and running on the Atari ST
series under Gem DOS.  We have tested it on the 520 but not the smaller
one (130?)  yet.  Usual price, but source won't be supplied until the
compiler/library/ROMs settle.

Brian

Automated style fixes for #26, created by Restyled.

The following restylers made fixes:

• prettier-markdown

To incorporate these changes, merge this Pull Request into the original. We recommend using the Squash or Rebase strategies.

NOTE: As work continues on the original Pull Request, this process will re-run and update (force-push) this Pull Request with updated style fixes as necessary. If the style is fixed manually at any point (i.e. this process finds no fixes to make), this Pull Request will be closed automatically.

Sorry if this was unexpected. To disable it, see our documentation.

16-Jan-84 11:01:55-MST,699;000000000000
Return-Path: <@MIT-MC:CAL%[email protected]>
Received: from MIT-MC by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 11:01:35-MST
Date: Sun, 15 Jan 1984  15:08 EST
Message-ID: <[email protected]>
From: Cliff Lasser <CAL%[email protected]>
To:   Info-cpm @SIMTEL20.ARPA
Cc:   [email protected], Cliff Lasser <CAL%[email protected]>
Subject: Mince keyboard macros
In-reply-to: Msg of 13 Jan 1984  18:52-EST from Rich $alz <DCB.TECH%MIT-OZ at MIT-MC.ARPA>

I have put the sources for my mince keyboard macros in MIT-MC:FJW;MMODS
TXT.  They will be there until FJW moves the file over to the Simtel20.  If
you have any problems with it, don't hesitate to let me know.

	-Cliff

Automated style fixes for #100, created by Restyled.

The following restylers made fixes:

• prettier-markdown

To incorporate these changes, merge this Pull Request into the original. We recommend using the Squash or Rebase strategies.

NOTE: As work continues on the original Pull Request, this process will re-run and update (force-push) this Pull Request with updated style fixes as necessary. If the style is fixed manually at any point (i.e. this process finds no fixes to make), this Pull Request will be closed automatically.

Sorry if this was unexpected. To disable it, see our documentation.

Automated style fixes for #96, created by Restyled.

The following restylers made fixes:

• prettier-markdown

To incorporate these changes, merge this Pull Request into the original. We recommend using the Squash or Rebase strategies.

NOTE: As work continues on the original Pull Request, this process will re-run and update (force-push) this Pull Request with updated style fixes as necessary. If the style is fixed manually at any point (i.e. this process finds no fixes to make), this Pull Request will be closed automatically.

Sorry if this was unexpected. To disable it, see our documentation.

Automated style fixes for #94, created by Restyled.

The following restylers made fixes:

• prettier-markdown

To incorporate these changes, merge this Pull Request into the original. We recommend using the Squash or Rebase strategies.

NOTE: As work continues on the original Pull Request, this process will re-run and update (force-push) this Pull Request with updated style fixes as necessary. If the style is fixed manually at any point (i.e. this process finds no fixes to make), this Pull Request will be closed automatically.

Sorry if this was unexpected. To disable it, see our documentation.

Automated style fixes for #91, created by Restyled.

The following restylers made fixes:

• prettier-markdown

To incorporate these changes, merge this Pull Request into the original. We recommend using the Squash or Rebase strategies.

NOTE: As work continues on the original Pull Request, this process will re-run and update (force-push) this Pull Request with updated style fixes as necessary. If the style is fixed manually at any point (i.e. this process finds no fixes to make), this Pull Request will be closed automatically.

Sorry if this was unexpected. To disable it, see our documentation.

Automated style fixes for #89, created by Restyled.

The following restylers made fixes:

• prettier-markdown

To incorporate these changes, merge this Pull Request into the original. We recommend using the Squash or Rebase strategies.

NOTE: As work continues on the original Pull Request, this process will re-run and update (force-push) this Pull Request with updated style fixes as necessary. If the style is fixed manually at any point (i.e. this process finds no fixes to make), this Pull Request will be closed automatically.

Sorry if this was unexpected. To disable it, see our documentation.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

This repository currently has no open or pending branches.

Detected dependencies

• [ ] Check this box to trigger a request for Renovate to run again on this repository

It worked with Haiku Walter (rolling) at the time of committing the functionality, but changes in Haiku since then have broken things.

The build itself works fine, the error is related only to packaging.

Example: Motorola SYSTEM V/68, Release 2, Version 1.0, VME/10 68010:

$ cc -c -O -DSYSV -DRUNOPTS -DUSEDIRENT ccpu.c
"ccpu.c", line 2142: compiler error: switch table overflow

Other systems using AT&T System V SGS compiler derivatives have the same trouble (e.g. Multics C).

On these compilers, the maximum switch table size is a preprocessor defintion set at compile time, so not trivial to patch.

Possible solutions (besides updating the compiler):

1. Add #ifdef to leave out undocumented instructions.
2. Convert switch/case to if/else.

Need to figure out what's wrong here, and, hopefully, a fix will increase compatibility generally.

• Cray (VSMP)
  • UNICOS (SV1) 10.0.1.2, Cray Standard C Version 6.6.0.3
  • UNICOS (J98) 10.0.0.2, Cray Standard C Version 6.4.0.0

Good news, all the 8080 and CP/M functionality otherwise checks out.

(A fix is likely trivial once I decide to figure out TotalView.)

14-Sep-82 11:04:00,849;000000000000
Date: Tuesday, 14 Sep 1982 10:04-PDT
To: Amethyst-Users at MIT-MC
From: bridger at RAND-UNIX
Cc: bridger at RAND-UNIX
Subject: Some Window commands

Here are several commands I've come to enjoy:

	1. M-, ==> point to start-of-window

	2. M-. ==> point to end-of-window
	
	The bindings follow the Gosling EMACS; M-, and M-. conveniently
	mimic the start-of-buffer, end-of buffer pair:  M-< and M->.

	3. M-! ==> line-to-start-of-window & point to beginning-of-line

	The trick here is to temporarily reset the preferred row to the top
	row.


MBeginWind()	/* on  M-, */	
{
	BPntToMrk(sstart);
	TForce();
	}
MEndWind()	/* on M-. */
{
	BPntToMrk(send);
	BMove(-1);
	TForce();
	}
MMoveToTop()	/* 'M-!' ==> line to top of buffer */
{
 	tmp=prefrow;
	prefrow=0;
	ScrnRange();
	prefrow=tmp;
	ToBegLine();
	}

2-Sep-82 10:26:00,3244;000000000000
Date:     2 September 1982 1226-edt
From:     Brian N. Hess              <Hess.Unicorn at MIT-MULTICS>
Subject:  Mince globals
To:       amethyst-users at MIT-MC

Mike --

A quote from the Amethyst Users Group newsletter, September, 1981:
There is one question I would like to answer that everyone keeps asking.
There are in fact several ways for people to get more global space in
Mince for use with personal extensions.

First a little background.  We use the "-e" option in the C compiler to
save space in the resulting programs.  This forces the global address to
appear at the specified address regardless of the size of the code.  L2
and CLINK both get this address, along with the size of the global data
area from the first .CRL file linked.  Mince does dynamic storage
allocation in the region between the global data and the stack, thus the
size of the global data must be accurate.  Further, there is more global
data than there might appear to be -- MINCE.CRL is compiled with a
different version of MINCE.GBL than is distributed, and has extra global
data for the buffer abstraction.

The simplest way to add storage is to have this storage be in the form
of string constants.  The compiler allocates string constants in such a
way that you can write over them so long as you don't exceed their
allocated length.  This is a fair although uncomfortable programming
practice which all of the compilers I know of (...) support.  This can
be done as follows:

Create a function such as:

          Storage()
          {
          return("This returns a string of exactly fifty characters    ");
          }

This function can now be used in another place to get a pointer to use
for storage as in:

          Munge(arg)                    /* Store arg in storage */
          char *arg
          {
          if (strlen(arg) > 50) Error("String too long");
          else strcpy(Storage(),arg);
          Echo("String now is: ");
          TNLPrnt(Storage());
          }

Another way to get extra storage is to create some room between the end
of the code and the start of the global data area by elimination of some
code or use of the L*.CRL files.  The routines can simply KNOW that this
space is there and use it.  This can get tricky to maintain since the
end of the code is likely to change every time you work on the program.
One good thing to do is to have your routine check the location of the
end of the code with the BDS-C function codend().

The final way to ge more storage is a little-known feature of L2.  L2,
unlike CLINK, does not require the first function linked to be the main
function.  Thus, you can compile BINDINGS.C with extra global
definitions and link BINDINGS first and then MINCE.  The trick is that
you have to leave extra space (more than 1000 and less than 1100 bytes;
1100 works [and I counted once and got 1086 -- bnh]) for the globals
that you cannot see.  The only way to know this number exactly is to put
a function in Mince that prints the address of the last visible global
and also the value returned by the BDS-C function that gives the address
of the end of the global area.
                            
Good luck,
Brian