Matlab code from 1983 was found on the Internet.

The source code for Matlab from 1983 was recently found on the internet, this is very nice code to find. It is amazing to find such old technology from a bygone age. I am not sure how to compile this source code, but this would be very useful if someone wants to try and build a Linux package of it. Apparently, this code still compiles on a modern Linux system.

Download it here: https://www.tuhs.org/Archive/Distributions/Research/Dan_Cross_v10/.

I found therein some other source code. This is a fortune game from 1981, code by a developer from Lucasfilm.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58

/*% cc -go # %
 * too-complex fortune program.
 * Tom Duff at Lucasfilm, Ltd. 81.11.23
 */
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
char line[512], choice[512];
char index[]="/usr/games/lib/fortunes.index";
char fortunes[]="/usr/games/lib/fortunes";
main(argc, argv)
char *argv[];
{
	int i;
	long offs;
	register FILE *f, *ix;
	int newindex=0, oldindex=0;
	struct stat fbuf, ixbuf;
	if(argc==1){
		if(stat(fortunes, &fbuf)>=0
		&& (stat(index, &ixbuf)<0 || fbuf.st_mtime>=ixbuf.st_mtime)
		&& (ix=fopen(index, "w"))!=NULL)
			newindex++;
		else if((ix=fopen(index, "r"))==NULL){
			if((ix=fopen(index, "w"))!=NULL)
				newindex++;
		}
		else
			oldindex++;
	}
	if((f=fopen(argc>1?argv[1]:fortunes, "r"))==NULL){
		printf("Misfortune!\n");
		exit(1);
	}
	srand((int)(time((long)0)+getpid()*getpid()));
	if(oldindex){
		fseek(ix, 0L, 2);
		fseek(ix, nrand(ftell(ix)/sizeof(offs))*sizeof(offs), 0);
		fread(&offs, sizeof(offs), 1, ix);
		fseek(f, offs, 0);
		fgets(choice, 512, f);
	}
	else{
		for(i=1;;i++){
			if(newindex)
				offs=ftell(f);
			fgets(line, 512, f);
			if(feof(f))
				break;
			if(newindex)
				fwrite(&offs, sizeof(offs), 1, ix);
			if(nrand(i)==0)
				strcpy(choice, line);
		}
	}
	printf("%s", choice);
	return 0;
}

I also found an awesome Japanese terminal font. Compile and install this to use it in the terminal.

./configure --with-fontdir=/usr/share/fonts/bitmap/japanese --with-pcf=yes  --with-bdf=yes
make install

Download the font here: http://openlab.ring.gr.jp/efont/japanese/.

Here are some historical mailing list messages from 1985 discussing Matlab.

From research!mcvax!ukc!eagle.ukc.ac.uk!cheviot.newcastle.ac.uk!andy  Thu Sep  5 21:18:15 1985
Received: by mcvax.UUCP; Thu, 5 Sep 85 21:18:15 +0200 (MET)
Message-Id: <[email protected]>
Received: from [nedaftp] by ukc.AC.UK id a029579; 5 Sep 85 17:00 BST
From: Andy Linton ([email protected]) 
Date: Thu, 5 Sep 85 17:00:13 bst
To: research!v8news
Subject: Conversion of Blits to 250 volts

Here is a message from the keyboard of the first Blit we have converted.

It was not as straightforward as the data sheet would have one believe.
There is an additional jumper which needs changed to complete the job.
This one is on the power supply behind the screen and on the left as you 
face the screen. On some of the models we got there are two plugs which
can be interchanged - one is marked 120 and the other is marked 220.

Needless to say we chose one of the Blits which did not have this  to
commence conversions with. For this one we needed to change the
male connector plug as shown below:

Original setup
**************
	O--+
	   |  
	   |
	O--|--+------------ Blackto logic Power supply
	   |  |
	   |  |
	O--+--------------- White to logic Power supply
	      |
	      |
	O-----+


220V setup
**********

	O------------------ White to logic Power supply


	O--+
	   |  
	   |
	   |
	O--+
	
	
	O------------------ Black to logic Power supply


We have not yet received our V8 tape and I am using the Blit as a
dumb terminal. Is there a proper termcap entry for it - I am using
oblit from the Berkeley termcap file but it doesn't clear the screen
properly. Any hints?
Thanks.
andy
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SENDER 	: Andy Linton		PHONE	: +44 632 329233
POST	: Computing Lab, University of Newcastle upon Tyne, UK, NE1 7RU
ARPA	: andy%[email protected])
JANET	: [email protected]
UUCP	: !ukc!cheviot!andy

***  Ni fui moran beagan d'aon rud, ach is fui moran beagan ceille.  ***





From research!acsnet!basser!boyd Sat Sep  7 21:29:36 1985
To: v8news@research
Cc: v8
Subject: 4.1 chroot bug etc...
Full-name: Boyd Roberts

At Sydney Uni we also had the 4.1 chroot bug.  If you chroot,
your system crashes.  Yuk.  To get around it we just took our
4.1 pack, read in our V8 root file-system onto another partition.
We made a V8 kernel on our standard system (ie. non 4.1)
and put it in the soon to be V8 /.

THe V8 / was dumped it to tape (using 4.1 dump) and was restored the
on top of the 4.1 root file-system.  Now we had a clean V8 root file-system.
>From there we made our /usr file-system.  We then had a minimal V8 system.

Without a clean (ie. no 4.1 crud on it) V8 root file-system life
is very interesting.  We tried a different approach at one stage
and it was a nightmare.

But, we have some more difficult problems.  As we run a system
(for the sake of argument we'll call it 32V) that has a 512 byte
block file-system.  Nothing on V8 understands it, and nothing on
32V understands V8.  We were facing the prospect of dumping and
restoring our existing file-systems with tar.  But, our
calculations showed that we may run out of disk space.

Our solution was to implement a new file-system type.  We could then
use all our 32V file-system things to manipulate our old file-systems.
The true beauty of the idea was that we could always return to 32V.
Should we convert all our file-systems to V8, we were then stuck with it.
We hoped to bring up V8 with minimal disruption as our machine
is very heavily relied on.

One other major problem was that we couldn't backup the V8 file-systems
as there wasn't a dump that really understood them.  One of our programmers
is working on a dump that will understand all three file-systems.  Other minor
problems included what to do with our ``special'' files (i.e. named pipes,
locking and autolocking files).  The new file-system type solved all of
the problems.

I've implemented the new file-system type.  It is not really
a ``type'' in it's own right, but is more like a type 0 file system
with a different block size.  pjw's 4k file system code made it easy.
It's slow, but it works!  Slowly we will convert to 1k or 4k.

I'll just add a few lines on some of the minor V8 bugs we've found.

    dev/ht.c:
		> hpattach() should return 1
		> change all mba device register to 16 bit assignments
		  to assign to 32 bit quantities

    dev/hp.c:
		> hpread() and hpwrite() should be fixed to
		  correctly select the unit number out of the
		  ``dev'' argument.  otherwise you can't read
		  or write 4k file-system devices except through
		  the block device interface.

    sys/machdep.c:
    sys/prf.c:
    sys/locore.s:
		> the printf message buffer allocation and use
		  should be fixed.  currently it is allocated
		  via pte's.  if you get a trap that causes
		  a printf, before the pte's are valid, then
		  a trap loop will ensue until a stack invalid
		  halt stops it.  yuk.  soon i will fix it here.


Boyd Roberts

From acsnet!basser!john Sat Sep 21 10:34:42 1985
>From john Sat Sep 21 10:34:42 1985 remote from acsnet!basser
Message-ID: <15958.221.496110881.basser@Basser>
To: v8news@research
Subject: device drivers

There comes a time when you want to drive some devices.  I've
written a DMF32 (asynch part only) driver; it has been tested
on Able VMZ's and Emulex CS32's and works fine on both.  Piers
has done a stream driver using QBIGB for the LP11 line printer
interface (we were surprised to find the distributed one was
still a 4.1 driver).  It has been lightly exercised and looks OK.

I am going to do a DZ11 driver that uses a KMC to do dma output.
At the moment I am trying to get the ht driver not to give lots
of hard errors with our SI tape controller (it works fine with
a real DEC TM03).  If anyone thinks they might know something
about that, or wants anything I've mentioned, please mail me.

John Mackin	seismo!munnari!basser.oz!john	john%[email protected]

From dmr Sat Sep 21 02:34 EDT 1985
Subject: new source
To: v8news

Ah, some action!  We would be happy to distribute source for drivers
or other things that people develop, such as the DMF32 and LP11 code
that John and Piers did.  However, it might be best to avoid dumping
it in people's mailboxes, so I have set up an alternate distribution
channel,
 	research!v8source
Right now it is a copy of v8news, and goes to the same places.
If you might want a DMF32 driver, but not one tossed in your lap,
send me another address to direct it to.

	Dennis

From mcvax!ukc!mmdf  Fri Oct 18 16:18:21 1985
>From ukc!mmdf  Fri Oct 18 16:18:21 1985 remote from mcvax
Received: by mcvax.UUCP; Fri, 18 Oct 85 16:18:21 +0100 (MET)
Message-Id: <[email protected]>
Received: from [nedaftp] by ukc.AC.UK id a022127; 18 Oct 85 14:24 BST
From: Andy Linton , [email protected]
Mmdf-Warning:  Parse error in original version of preceding line at Ukc.AC.UK
Date: Fri, 18 Oct 85 14:25:03 bst
To: research!v8news
Subject: Lack of traffic across the Atlantic.


We may have lost some items addressed to v8news.
Apart from one from Newcastle the headers of those
we hjave received are below. Have we missed much?
Can we have what we  missed? Have there been any
articles for v8sources?
Thanks
andy