George Coulouris of Queen Mary College wrote an editor called em (editor for mortals, as opposed to ed, “the standard editor”), which was eventually mutated and evolved into an editor called ex or indeed vi, by Bill Joy.
Em is a QMC variant of the standard Unix text editor - ed. It includes all of ed, so the documentation for ed is fully applicable to em. Em also has a number of new commands and facilities designed to improve its interaction and increase its usefulness to users at fast vdu terminals (such as the ITT’s at QMC).
via this article in The Register:
where Bill Joy is quoted on the process of writing ex:
It took a long time. It was really hard to do because you’ve got to remember that I was trying to make it usable over a 300 baud modem. That’s also the reason you have all these funny commands. It just barely worked to use a screen editor over a modem. It was just barely fast enough. A 1200 baud modem was an upgrade. 1200 baud now is pretty slow.
9600 baud is faster than you can read. 1200 baud is way slower. So the editor was optimized so that you could edit and feel productive when it was painting slower than you could think. Now that computers are so much faster than you can think, nobody understands this anymore.
The people doing Emacs were sitting in labs at MIT with what were essentially fibre-channel links to the host, in contemporary terms. They were working on a PDP-10, which was a huge machine by comparison, with infinitely fast screens.
So they could have funny commands with the screen shimmering and all that, and meanwhile, I’m sitting at home in sort of World War II surplus housing at Berkeley with a modem and a terminal that can just barely get the cursor off the bottom line.
I think the wonderful thing about vi is that it has such a good market share because we gave it away. Everybody has it now. So it actually had a chance to become part of what is perceived as basic UNIX. EMACS is a nice editor too, but because it costs hundreds of dollars, there will always be people who won’t buy it.
The EMACS at hundreds of dollars must be the commercialised one which kicked Stallman into his Free software crusade… starting with his free and gratis version of EMACS.
As for vi vs EMACS I still use vi for /etc/fstab, micro-emacs for small text files, and (x)emacs for the rest
A little anecdote of editors and maybe a shade OT and not that retro, but c1989 I was tasked with porting emacs and some other utilities to a new unix-like OS that we were developing on a 32-bit micro…
At that time there was little in the open source world - and hard to get in the UK too, but I quickly found myself in an almost recursive spiral death trap of writing stuff from scratch… So emacs. No editor, so see what else I can find - A vi look-a-like called STeVIe (Atari ST Editor for VI Enthusiasts!) That needed adapting and manual pages written.
Write man
man needs more
Write more
more needs termcap (pre curses days IIRC)
Write termcap
back to man. man needs ?roff and friends
Write troff, or at least something good enough to process man pages (vow to never look at text processing again)
finish writing more.
finish porting STeVIe.
Use the new vi to port emacs. Target only has 8MB of RAM. Emacs would not work (also other architectural limitations - emacs then built itself in-core, then ‘un-exec’ the core image - I’ve no idea if this is still the case) Failed to port emacs, find micro emacs. port that. spend ages fixing memory leaks and other issues (target system had no MMU)
And at that point abandon the project as we moved to Sun sparc boards…
Fun times - for some value of fun and I don’t think I’ve looked at emacs since… But years later after what seems like a lifetime of using the pine and alpine email clients with pico and now the nano editor, I have my own little version of nano written in C which I’m currently porting to a properly retro BCPL!
And ifnally - for now - I’ve just downloaded and tried to build em. Failed - mostly because a modern C compiler rejects old K&R style C.
Now, I do have an old retro Unix system, an Altos 386 which has a K&R compiler, but I’m not sure I have the enthusiasm right now to copy it over. (nor the enthusiasm to convert em to ANSI C either).
Ed fixed it this morning (after my post), the original link didn’t go to archive.org
(I’m thinking of trying to build it with the K&R C compiler of my 16-bit mini. Even though it’s got a very good GUI editor already.)
Update: This isn’t K&R C, it’s T&R C (Ken Thompson + Ritchie C)… it’s old enough to still use “=+” instead of “+=”, and initial assignments can be done without using “=”.
I was glancing through the code and saw that =+ and I basically stopped as I didn’t quite know what they meant (I didn’t know that it was originally this way vs +=).
There are a couple of V6 unixes you can run in your browser (as PDP-11 emulations) which just might possibly have an old enough C compiler. But maybe not…
The problem with the original notation is that “a=-2;” could mean either assign negative two to “a” or decrement “a” by two. Moving the operator before the equal sign eliminated the ambiguity.
Or add a space. I suspect K&R C was more portable
than todays C because you had fewer types of data
that fit the hardware, rather than today with the data ‘thousands’ of different types. long long type on a 8080 cpu?
Did any one ever make a portable editor like say the
PDP 8 editor - just basic editing and a small footprint?
Havng just finished desiging on a FPGA card a 20 bit cpu from 1970’ era 74181 4K dram 256x8 proms,I am looking for a editor easy to port,and other basic software. The hardware having just immedate and index addressing modes makes porting software tricky since has no push or pop off the stack, that everybody expects to have.
Assembly is not portable, you need to have a high level language of some kind. Then things like pushing and popping are hidden by the compiler and runtime.
You don’t necessarily need first class support for pushing and popping in the CPU.
Create an assembler and then port one of the Small-C’s and then you can cross-compile from there.
And remember, it’s ok for an early compiler to produce crummy code. The beauty of a compiler that creates crummy code is that it can be fixed and recompiled to make less crummy code, then all of your other source code become less crummy “for free”.
The hard part about an editor isn’t the editor, it’s the file system and console interface the editor has to interact with. That’s where all the work is.
You can always port a Fig-Forth – it has an editor in 3 or 4 screens of code
I said like the pdp 8 editor, not the the PDP 8 editor source. Well written and documented assembler (not me) is as portable as high level code providing you don’t have macros and other weird defines.
I have ported but not tested the original tiny C by Ron Cain, but you can’t bootstrap version 1 to version 2.
The real limiting factor with C most useful programing requires structures, and that small C has not.
My cpu has no MMU so porting OS software is rather limited.
I don’t think the em sources are written in what we call K&R-C today. For me it looks like one of the early “proto-C” dialects between B and “real” C. Like B plus types.
Limited, bu not impossible… A couple of examples of OSs without an MMU:
ucLinux
And in the late 80’s/early 90’s I worked on a system which was based on Minix and ran on a 32-bit Transputer which didn’t have an MMU.
My current hobby SBC project (16Mhz 65c816, 512KB RAM) doesn’t have an MMU either and my plans are for a single-user, multi tasking OS for it.
The usual caveats apply - no memory protection, so any program can “see” any other program (and data) and of-course overwrite another program, the OS, everything, so you really do need to be careful!
Yea, you don’t need an MMU. You need a loader, or the ability to write position independent code.
Pretty sure early OS/9 on the 6809 relied on PIC code. Sure makes things easier.
The two primary benefits of the MMU are the virtual address space (“everything runs at address XXXX”), and memory protection. A loader/PIC code fixes the first problem, careful coding fixes the second problem.
I used to work on Alpha Micro machines, and they offered a “RSTS/E” like experience, but am confident that these machine had no MMU. They used fixed memory allocations for processes, which I think were bound to the serial ports for the terminals (honestly it’s hard to say quite how that worked because of our setup). But there was certainly no memory protection.
Which was fine for us, as we did all our work in BASIC, which (without POKE) is a memory safe language. But it was not unheard of for us, sometime, somewhere, to do something that inevitably crashed the machine. I never did any very low level work on the machine.
All in all it was a completely usable, stable, capable machine, capable of running 100’s of users (with the proper hardware). The machines were quite successful, and AFAIK never used an MMU, even up to the models running 68030 and 68040 CPUs.
I forgot to add one detail, in 1975 16 bit adressing was large address space as this is a retro design. Finding small O/S are few.
“Small tools” from small C has a editor I might be able to port to version 1 of small c.
To keep a simple computer, the word size is 20 bits (5 4 bit slices) and 10 bit bytes.2 large 9x11 inch pcb’s are planned for the ALU and Control cards.A good size for homebew computer.
So, right up your alley. 8K for the base Forth system. Maybe 2K for the multi-tasking parts, leaves over 50K of RAM to allocate out to users and tasks. Pretty readily support 4 users with this me thinks, and/or a couple dozen simple processes.
Talking about timesharing reminded me, you can run a real PDP8 online here.Have to share it with the cat however. https://www.pdp8.net/index.shtml
A pdp 8 can time share too,but only at TTY speeds.
(Put your $5 pie to real use :))
