29 May
2016
29 May
'16
7:31 p.m.
Not sure if anyone really cares, but I figure it don't hurt to tell
anyway...
I have for many years used a very old version of MicroEMACS for RSX. I
eventually started searching around for alternatives, but realized
during that search that most Emacs clones are horribly huge (including
MicroEMACS), not portable at all (even if they claim to be), and
generally also expects to just allocate gobs of memory to keep all data
in ram.
Now, RSX, being a PDP-11 OS, have a 16-bit address space limitation. So
just allocating memory is never going to be a solution. There is a C
compiler, which is pretty much ANSI C. But it is not Unix, and gives you
the C standard IO library, but not low level Unix calls.
On the plus side, most of the library can sit in supervisor space, and
not consume any memory in your process space.
Clones I've looked at:
MicroEMACS - Huge and difficult to port. Use lots of memory.
JOVE - Small (runs on 2.11BSD), but horribly difficult to port.
mg - Huge and difficult. Use lots of memory.
AMIS - Huge, and written in Pascal. Not necessarily bad, but adapting
the code to a new system requires mucking around some, made worse by the
small differences in different Pascal compilers, and the lack of any
preprocessor, as well as the bonehead type system in Pascal. Also use
lots of memory, but it has been made to run on small machines (including
PDP-11 with RSTS/E) in the past, so it is a solveable problem.
Atto - Hard to port.
JED - Huge.
I looked at dozens more, which were not even worth looking deeper into,
or to list here.
The long and short of it was that, even though there are numerous
implementations out there, they all suck, from my point of view.
With all that in mind, I decided to write my own Emacs clone instead
(yes, I got horribly upset with the lousy quality of most code I looked
at, if someone wants to hear some rants, contact me privately).
I started about a month ago, and at this point, it's working, and quite
useful. And I guess if other people are in a similar situation, they
might be interested in looking into this, and possibly make use of it.
Quick run through:
. ANSI C sources.
. Mostly uses the C standard IO library. Exception is terminal I/O,
which requires some small pieces reimplemented if you want to port it.
So, if you have an ANSI C compiler, porting should be very low effort.
. Only works on ANSI terminals today. It would be doable to extend with
other terminal support, but I don't have any need, and since I do not
have, nor want to depend on curses, it will require coding to either
have a module to uses curses, if that is wanted, or handling of specific
terminals.
. The compiled code, using PDP-11 C, ends (at the moment) up at around
36 Kbytes of binary. The C library and RMS sits mostly in supervisor
mode, and is not accounted for in this.
. Data usage is about 8K for various storage and strings.
. Code dependecies are very much in a tree, so overlaying is easy, if
wanted/needed, and that capability exists on the host.
. Since I compile with split I/D space, this means than about 56K of
dataspace can be used for buffering of various sorts.
. File buffers are kept in a temporary file, and read/written to memory
as needed (pretty much a demand-paging virtual memory implementation in
the application).
. The virtual, paged memory is about 4G, which is an absolute limit on
memory usage. Practical file limit is (I would guesstimate) around 1G.
. Most basic EMACS editing functions are implemented, including split
windows, multiple buffers, kill buffer, moving around in various ways,
and some semi-stupid automatic indentation handling for C code. Also
incremental searching in a proper fashion.
. Speed, tested on a real PDP-11/93 is pretty acceptable. Testing on a
file about 1000 lines takes a couple of second to open, and a couple of
seconds if you try to search from the start to the end. Most other
things move faster.
. The program is not suitable for editing binary data. The C standard
I/O library don't really lend itself to binary I/O, and this code have
to live within those constraints.
There are still lots of functionality that I'm working on adding, such
as repeats (almost done) and macros (only started thinking about it).
If people have functions they consider extra important, let me know, and
I'll see if I can add them. If people want to contribute code, I'll be
happy to incorporate changes as well, as long as they make sense.
The sources, as well as a compiled RSX-11M-PLUS binary for PDP-11 C
V1.2, can be found at HECnet: MIM::DU:[NEMA], or
ftp:://nema at mim.update.uu.se/.
This editor is now installed as ...EMA on MIM::, so if you type "EMA
filename", you can see how it works there.
It is now my tool for doing further development. I have ditched
MicroEMACS. So I'm constantly testing the thing, as I am developing
it... :-)
Maybe someone will find it useful...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
30 May
30 May
4:10 a.m.
I think this is fantastic. Is there any chance of this running on
non-PLUS RSX? I'm running it on several non-22-bit systems (real iron)
at LSSM. I'd love to have an emacs-style editor available on those systems.
-Dave
On 05/29/2016 01:31 PM, Johnny Billquist wrote:
Not sure if anyone really cares, but I figure it
don't hurt to tell
anyway...
I have for many years used a very old version of MicroEMACS for RSX. I
eventually started searching around for alternatives, but realized
during that search that most Emacs clones are horribly huge (including
MicroEMACS), not portable at all (even if they claim to be), and
generally also expects to just allocate gobs of memory to keep all data
in ram.
Now, RSX, being a PDP-11 OS, have a 16-bit address space limitation. So
just allocating memory is never going to be a solution. There is a C
compiler, which is pretty much ANSI C. But it is not Unix, and gives you
the C standard IO library, but not low level Unix calls.
On the plus side, most of the library can sit in supervisor space, and
not consume any memory in your process space.
Clones I've looked at:
MicroEMACS - Huge and difficult to port. Use lots of memory.
JOVE - Small (runs on 2.11BSD), but horribly difficult to port.
mg - Huge and difficult. Use lots of memory.
AMIS - Huge, and written in Pascal. Not necessarily bad, but adapting
the code to a new system requires mucking around some, made worse by the
small differences in different Pascal compilers, and the lack of any
preprocessor, as well as the bonehead type system in Pascal. Also use
lots of memory, but it has been made to run on small machines (including
PDP-11 with RSTS/E) in the past, so it is a solveable problem.
Atto - Hard to port.
JED - Huge.
I looked at dozens more, which were not even worth looking deeper into,
or to list here.
The long and short of it was that, even though there are numerous
implementations out there, they all suck, from my point of view.
With all that in mind, I decided to write my own Emacs clone instead
(yes, I got horribly upset with the lousy quality of most code I looked
at, if someone wants to hear some rants, contact me privately).
I started about a month ago, and at this point, it's working, and quite
useful. And I guess if other people are in a similar situation, they
might be interested in looking into this, and possibly make use of it.
Quick run through:
. ANSI C sources.
. Mostly uses the C standard IO library. Exception is terminal I/O,
which requires some small pieces reimplemented if you want to port it.
So, if you have an ANSI C compiler, porting should be very low effort.
. Only works on ANSI terminals today. It would be doable to extend with
other terminal support, but I don't have any need, and since I do not
have, nor want to depend on curses, it will require coding to either
have a module to uses curses, if that is wanted, or handling of specific
terminals.
. The compiled code, using PDP-11 C, ends (at the moment) up at around
36 Kbytes of binary. The C library and RMS sits mostly in supervisor
mode, and is not accounted for in this.
. Data usage is about 8K for various storage and strings.
. Code dependecies are very much in a tree, so overlaying is easy, if
wanted/needed, and that capability exists on the host.
. Since I compile with split I/D space, this means than about 56K of
dataspace can be used for buffering of various sorts.
. File buffers are kept in a temporary file, and read/written to memory
as needed (pretty much a demand-paging virtual memory implementation in
the application).
. The virtual, paged memory is about 4G, which is an absolute limit on
memory usage. Practical file limit is (I would guesstimate) around 1G.
. Most basic EMACS editing functions are implemented, including split
windows, multiple buffers, kill buffer, moving around in various ways,
and some semi-stupid automatic indentation handling for C code. Also
incremental searching in a proper fashion.
. Speed, tested on a real PDP-11/93 is pretty acceptable. Testing on a
file about 1000 lines takes a couple of second to open, and a couple of
seconds if you try to search from the start to the end. Most other
things move faster.
. The program is not suitable for editing binary data. The C standard
I/O library don't really lend itself to binary I/O, and this code have
to live within those constraints.
There are still lots of functionality that I'm working on adding, such
as repeats (almost done) and macros (only started thinking about it).
If people have functions they consider extra important, let me know, and
I'll see if I can add them. If people want to contribute code, I'll be
happy to incorporate changes as well, as long as they make sense.
The sources, as well as a compiled RSX-11M-PLUS binary for PDP-11 C
V1.2, can be found at HECnet: MIM::DU:[NEMA], or
ftp:://nema at mim.update.uu.se/.
This editor is now installed as ...EMA on MIM::, so if you type "EMA
filename", you can see how it works there.
It is now my tool for doing further development. I have ditched
MicroEMACS. So I'm constantly testing the thing, as I am developing
it... :-)
Maybe someone will find it useful...
Johnny
--
Dave McGuire, AK4HZ
New Kensington, PA
10:26 a.m.
It might be possible but you will have to work hard on finding ways to
overlay it.
If you can do that, and just have a couple of K of space left, you'll be
good. It might be rather slow, but it would still have the same
capabilities.
Johnny
On 2016-05-30 04:10, Dave McGuire wrote:
I think this is fantastic. Is there any chance of this running on
non-PLUS RSX? I'm running it on several non-22-bit systems (real iron)
at LSSM. I'd love to have an emacs-style editor available on those systems.
-Dave
On 05/29/2016 01:31 PM, Johnny Billquist wrote:
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Not sure if anyone really cares, but I figure it
don't hurt to tell
anyway...
I have for many years used a very old version of MicroEMACS for RSX. I
eventually started searching around for alternatives, but realized
during that search that most Emacs clones are horribly huge (including
MicroEMACS), not portable at all (even if they claim to be), and
generally also expects to just allocate gobs of memory to keep all data
in ram.
Now, RSX, being a PDP-11 OS, have a 16-bit address space limitation. So
just allocating memory is never going to be a solution. There is a C
compiler, which is pretty much ANSI C. But it is not Unix, and gives you
the C standard IO library, but not low level Unix calls.
On the plus side, most of the library can sit in supervisor space, and
not consume any memory in your process space.
Clones I've looked at:
MicroEMACS - Huge and difficult to port. Use lots of memory.
JOVE - Small (runs on 2.11BSD), but horribly difficult to port.
mg - Huge and difficult. Use lots of memory.
AMIS - Huge, and written in Pascal. Not necessarily bad, but adapting
the code to a new system requires mucking around some, made worse by the
small differences in different Pascal compilers, and the lack of any
preprocessor, as well as the bonehead type system in Pascal. Also use
lots of memory, but it has been made to run on small machines (including
PDP-11 with RSTS/E) in the past, so it is a solveable problem.
Atto - Hard to port.
JED - Huge.
I looked at dozens more, which were not even worth looking deeper into,
or to list here.
The long and short of it was that, even though there are numerous
implementations out there, they all suck, from my point of view.
With all that in mind, I decided to write my own Emacs clone instead
(yes, I got horribly upset with the lousy quality of most code I looked
at, if someone wants to hear some rants, contact me privately).
I started about a month ago, and at this point, it's working, and quite
useful. And I guess if other people are in a similar situation, they
might be interested in looking into this, and possibly make use of it.
Quick run through:
. ANSI C sources.
. Mostly uses the C standard IO library. Exception is terminal I/O,
which requires some small pieces reimplemented if you want to port it.
So, if you have an ANSI C compiler, porting should be very low effort.
. Only works on ANSI terminals today. It would be doable to extend with
other terminal support, but I don't have any need, and since I do not
have, nor want to depend on curses, it will require coding to either
have a module to uses curses, if that is wanted, or handling of specific
terminals.
. The compiled code, using PDP-11 C, ends (at the moment) up at around
36 Kbytes of binary. The C library and RMS sits mostly in supervisor
mode, and is not accounted for in this.
. Data usage is about 8K for various storage and strings.
. Code dependecies are very much in a tree, so overlaying is easy, if
wanted/needed, and that capability exists on the host.
. Since I compile with split I/D space, this means than about 56K of
dataspace can be used for buffering of various sorts.
. File buffers are kept in a temporary file, and read/written to memory
as needed (pretty much a demand-paging virtual memory implementation in
the application).
. The virtual, paged memory is about 4G, which is an absolute limit on
memory usage. Practical file limit is (I would guesstimate) around 1G.
. Most basic EMACS editing functions are implemented, including split
windows, multiple buffers, kill buffer, moving around in various ways,
and some semi-stupid automatic indentation handling for C code. Also
incremental searching in a proper fashion.
. Speed, tested on a real PDP-11/93 is pretty acceptable. Testing on a
file about 1000 lines takes a couple of second to open, and a couple of
seconds if you try to search from the start to the end. Most other
things move faster.
. The program is not suitable for editing binary data. The C standard
I/O library don't really lend itself to binary I/O, and this code have
to live within those constraints.
There are still lots of functionality that I'm working on adding, such
as repeats (almost done) and macros (only started thinking about it).
If people have functions they consider extra important, let me know, and
I'll see if I can add them. If people want to contribute code, I'll be
happy to incorporate changes as well, as long as they make sense.
The sources, as well as a compiled RSX-11M-PLUS binary for PDP-11 C
V1.2, can be found at HECnet: MIM::DU:[NEMA], or
ftp:://nema at mim.update.uu.se/.
This editor is now installed as ...EMA on MIM::, so if you type "EMA
filename", you can see how it works there.
It is now my tool for doing further development. I have ditched
MicroEMACS. So I'm constantly testing the thing, as I am developing
it... :-)
Maybe someone will find it useful...
Johnny
3:42 p.m.
This is fantastic news!
My 2 cents, if I may.
There's a simple reason why I stopped using MicroEMACS on my RSX
system and went back to TECO-11. Screen size. I didn't try too hard,
but I failed to hack MicroEMACS to display more than 80x24. It just
kept crashing. And as I nowadays mostly connect to my RSX system via
telnet, it's really not that pleasant to see those 80x24 symbols on a
pretty large terminal emulator screen.
My TECO startup script, on the other hand, asks the terminal about its
size and adjusts nicely.
NEMA seems to ignore both my real screen size and terminal height
setting (SET TERM/PAG:nnn). However it does use the terminal width
setting.
Please note that the source depends on STAT.H which, judging by a
modification time on MIM, is your own header file, but which is
missing from the [NEMA] directory.
And then what is CLIB.OLB that is needed for a task-building? Modules
that are needed seem to match CFPURSX.OLB, but if I task-build against
it, my NEMA.TSK crashes on startup.
--
Paul Anokhin
4:16 p.m.
Hi.
On 2016-05-30 15:42, Paul A. Anokhin wrote:
This is fantastic news!
My 2 cents, if I may.
Very happy to answer...
There's a simple reason why I stopped using
MicroEMACS on my RSX
system and went back to TECO-11. Screen size. I didn't try too hard,
but I failed to hack MicroEMACS to display more than 80x24. It just
kept crashing. And as I nowadays mostly connect to my RSX system via
telnet, it's really not that pleasant to see those 80x24 symbols on a
pretty large terminal emulator screen.
Fair enough. I also found MicroEMACS limiting in lots of ways. Size was
one of them.
My TECO startup script, on the other hand, asks the
terminal about its
size and adjusts nicely.
NEMA seems to ignore both my real screen size and terminal height
setting (SET TERM/PAG:nnn). However it does use the terminal width
setting.
It's actually simpler than that. The max sizes are in config.h, and I
just currently defined them as 24x132. :-) If your terminal is larger
than these defines, NEMA will use what's in the defines.
It's just a recompile with other values. It consumes a bit more memory,
but I've realized at this point that I'm not that short on memory in the
first place, so I can just raise those some.
At runtime, NEMA to check what the terminal setting is.
Note that the code will not properly handle if you suspend NEMA, resize
the screen, and then resume. The hook are in there to deal with this, I
just haven't had time to fix that one yet.
Please note that the source depends on STAT.H which,
judging by a
modification time on MIM, is your own header file, but which is
missing from the [NEMA] directory.
It's a file I wrote myself, along with the actual function. It is not a
part of PDP-11 C. You can find the file in MIM::DU:[BQTLIB], and it's
also at MIM::PDP11C$INCLUDE: where the PDP-11 C compiler searches for
system include files. Other functions I had to write were umask(),
getuid() and getgid(), since I wanted this to be generic enough to
easily port.
And then what is CLIB.OLB that is needed for a
task-building? Modules
that are needed seem to match CFPURSX.OLB, but if I task-build against
it, my NEMA.TSK crashes on startup.
CLIB.OLB, along with BQTLIB.OLB, are needed for the stat(), umask(),
getuid() and getgid() calls. There is some C code in there, which
requires that you have the C library in your final task as well, but it
shouldn't be an issue.
If things crash at startup, and not at task build, you might have been
task building with some wrong support modules?
Johnny
4:20 p.m.
Oh yeah. I forgot.
If you want to compile NEMA, the easiest is to grab the following files:
MIM::DU:[NEMA]*.C
MIM::DU:[NEMA]*.H
MIM::DU:[NEMA]*.MAC
MIM::DU:[NEMA]MAKEFILE.
MIM::DU:[NEMA]NEMA.CMD
MIM::DU:[NEMA]NEMA.ODL
MIM::PDP11C$INCLUDE:STAT.H
MIM::DU:[1,1]BQTC.OLB
MIM::DU:[1,1]BQTLIB.OLB
Johnny
On 2016-05-30 16:16, Johnny Billquist wrote:
Hi.
On 2016-05-30 15:42, Paul A. Anokhin wrote:
This is fantastic news!
My 2 cents, if I may.
Very happy to answer...
There's a simple reason why I stopped using
MicroEMACS on my RSX
system and went back to TECO-11. Screen size. I didn't try too hard,
but I failed to hack MicroEMACS to display more than 80x24. It just
kept crashing. And as I nowadays mostly connect to my RSX system via
telnet, it's really not that pleasant to see those 80x24 symbols on a
pretty large terminal emulator screen.
Fair enough. I also found MicroEMACS limiting in lots of ways. Size was
one of them.
My TECO startup script, on the other hand, asks
the terminal about its
size and adjusts nicely.
NEMA seems to ignore both my real screen size and terminal height
setting (SET TERM/PAG:nnn). However it does use the terminal width
setting.
It's actually simpler than that. The max sizes are in config.h, and I
just currently defined them as 24x132. :-) If your terminal is larger
than these defines, NEMA will use what's in the defines.
It's just a recompile with other values. It consumes a bit more memory,
but I've realized at this point that I'm not that short on memory in the
first place, so I can just raise those some.
At runtime, NEMA to check what the terminal setting is.
Note that the code will not properly handle if you suspend NEMA, resize
the screen, and then resume. The hook are in there to deal with this, I
just haven't had time to fix that one yet.
Please note that the source depends on STAT.H
which, judging by a
modification time on MIM, is your own header file, but which is
missing from the [NEMA] directory.
It's a file I wrote myself, along with the actual function. It is not a
part of PDP-11 C. You can find the file in MIM::DU:[BQTLIB], and it's
also at MIM::PDP11C$INCLUDE: where the PDP-11 C compiler searches for
system include files. Other functions I had to write were umask(),
getuid() and getgid(), since I wanted this to be generic enough to
easily port.
And then what is CLIB.OLB that is needed for a
task-building? Modules
that are needed seem to match CFPURSX.OLB, but if I task-build against
it, my NEMA.TSK crashes on startup.
CLIB.OLB, along with BQTLIB.OLB, are needed for the stat(), umask(),
getuid() and getgid() calls. There is some C code in there, which
requires that you have the C library in your final task as well, but it
shouldn't be an issue.
If things crash at startup, and not at task build, you might have been
task building with some wrong support modules?
Johnny
4:31 p.m.
One more comment...
On 2016-05-30 16:16, Johnny Billquist wrote:
Hi.
On 2016-05-30 15:42, Paul A. Anokhin wrote:
I'll probably rewrite this code a little, to instead just allocate a
chunk of memory, and then try to find a somewhat optimal size to use,
based on the terminal size, and the size of the memory. So that, if you
only have 80 columns, you should be able to have more rows than if you
have 132 columns... Later today maybe.
Johnny
This is fantastic news!
My 2 cents, if I may.
Very happy to answer...
There's a simple reason why I stopped using
MicroEMACS on my RSX
system and went back to TECO-11. Screen size. I didn't try too hard,
but I failed to hack MicroEMACS to display more than 80x24. It just
kept crashing. And as I nowadays mostly connect to my RSX system via
telnet, it's really not that pleasant to see those 80x24 symbols on a
pretty large terminal emulator screen.
Fair enough. I also found MicroEMACS limiting in lots of ways. Size was
one of them.
My TECO startup script, on the other hand, asks
the terminal about its
size and adjusts nicely.
NEMA seems to ignore both my real screen size and terminal height
setting (SET TERM/PAG:nnn). However it does use the terminal width
setting.
It's actually simpler than that. The max sizes are in config.h, and I
just currently defined them as 24x132. :-) If your terminal is larger
than these defines, NEMA will use what's in the defines.
It's just a recompile with other values. It consumes a bit more memory,
but I've realized at this point that I'm not that short on memory in the
first place, so I can just raise those some.
At runtime, NEMA to check what the terminal setting is.
Note that the code will not properly handle if you suspend NEMA, resize
the screen, and then resume. The hook are in there to deal with this, I
just haven't had time to fix that one yet. 
31 May
31 May
6:18 a.m.
Paul A. Anokhin wrote:
This is fantastic news!
My 2 cents, if I may.
There's a simple reason why I stopped using MicroEMACS on my RSX
system and went back to TECO-11. Screen size. I didn't try too hard,
but I failed to hack MicroEMACS to display more than 80x24. It just
kept crashing. And as I nowadays mostly connect to my RSX system via
telnet, it's really not that pleasant to see those 80x24 symbols on a
pretty large terminal emulator screen.
My TECO startup script, on the other hand, asks the terminal about its
size and adjusts nicely.
NEMA seems to ignore both my real screen size and terminal height
setting (SET TERM/PAG:nnn). However it does use the terminal width
setting.
Please note that the source depends on STAT.H which, judging by a
modification time on MIM, is your own header file, but which is
missing from the [NEMA] directory.
And then what is CLIB.OLB that is needed for a task-building? Modules
that are needed seem to match CFPURSX.OLB, but if I task-build against
it, my NEMA.TSK crashes on startup.
I realize that since I use RT-11 (and rarely RSTS/E) that my
experience probably will not help very much.
Under RT-11, DEC produced the KED editor which supports
the VT100, VT52 and VT62 terminals under both RT-11 and
RSTS/E. For the past decade, I have been using an emulator
which supports using a VT100 with all of:
(a) 24 lines by 80 columns / 24 lines by 132 columns
(b) 50 lines by 80 columns / 44 lines by 132 columns
(c) up to 79 lines by 80 columns / up to 79 lines by 132 columns
Since I write most of my code in MACRO-11, there
was a huge incentive to enhance KED to support both
(b) and (c) above. The enhanced code checks the size
of the screen immediately after the user specifies the first
file to be edited and allocates a screen buffer at that
point to hold all the characters. It seems doubtful that
the KED code changes would be helpful, but maybe.
Jerome Fine
2:24 p.m.
New subject: taking the first step
Hello,
May I request a node address and node number pair to try to connect
using the bridge program?
I am running OpenVMS 7.3 on SIMH on a dedicated virtualbox VM and have
compiled the bridge program on the VM host, wanting to take the next step.
Thanks in advance,
Supratim
---
Johnny,
I would like to connect to you first (the easy solution) - please send
me the two numbers I can use.
Note: You will probably hear back from me after around a week when I
return from a work-related travel assignment.
Thanks,
Supratim
On 5/14/2016 7:46 PM, Johnny Billquist wrote:
Hi, Supratim.
On 2016-05-14 19:33, Supratim Sanyal wrote:
Dear Johnny,
I am taking the first steps in building a useful hobbyist OpenVMS
7.3/VAX machine and am at a point where I
(a) have downloaded and compiled the bridge program on a linux gateway
box, and
(b) am starting to configure DECNet Plus with the goal of getting on
HECNet.
I would like the nodename to be QCOCAL if possible (historical reasons,
the first nodename when I joined DEC was QCOCAL). Also, can you help me
with choosing between LOCAL and DECdns, and assign me an area and a node
number?
Once I have this configured, the next step will be to get bridge to work
and test if I can reach other Vaxen over HECnet.
The following is a dump of what I did so far. Also copying Poolak
Banerjee, a fellow ex-DEC VAX enthusiast and my ex-boss at DEC, who is
closely following progress on this VAX.
Well, the obvious questions are (as always), where to connect you, and
what area and node number to use.
Since you mention that you are planning to use the bridge, the easy
solution is to connect to me, but if you have some other plan just let
me know.
The question of area and node number depends on your system. I do not
really know much about DECnet Plus. Can you have an area router with
this, and would you like to have your own area, or would you prefer to
be placed in an existing area?
As far as choosing how to handle node names, I cannot really comment.
Like I said, I do not really know DECnet Plus that well, and found it
just complicated for my needs, so I "downgraded" back to plain Phase IV
DECnet on whatever VMS I have. But I mostly run PDP-11s myself. And
there are also many other type of systems as well.
Johnny
Thank you very much,
Supratim Sanyal
Germantown, Maryland, USA
--
*DUA1:[RUMTUK]$ start/network decnet**
*Copyright 2000 Compaq Computer Corporation. All rights reserved.
%NET$STARTUP-W-NONETCONFIG, this node has not been configured to run
DECnet-Plus for OpenVMS
use SYS$MANAGER:NET$CONFIGURE.COM if you wish to configure
DECnet
%NET$STARTUP-I-OPERSTATUS, DECnet-Plus for OpenVMS operational status
is OFF
*DUA1:[RUMTUK]$ @SYS$MANAGER:NET$CONFIGURE.COM**
*Copyright Compaq Computer Corporation 2000. All rights reserved.
DECnet-Plus for OpenVMS network configuration procedure
This procedure will help you create or modify the management scripts
needed to operate DECnet on this machine. You may receive help about
most questions by answering with a question mark '?'.
%NET$CONFIGURE-I-SETUPNEW, setting up for new configuration
You have the option of choosing the following directory services
for
your system:
Local file (LOCAL) - A local namespace that uses flat naming.
DECdns - A distributed namespace.
Domain - A naming service that uses DNS/BIND.
The Local file has the capability to hold 100,000 nodes, and it
can even
scale beyond that number. The actual number of nodes that the
Local file
can hold depends on the space available on your system.
If you choose to enter more than one directory service for your
system,
the ordering of this list is *very important*, as the first
directory
service entered in this list will be considered the primary
directory
service to use on the system. The primary directory service is
considered
the first choice to use when looking up naming information for the
system.
If you are running a DNS Clerk on this system, or plan to run a
DNS Clerk
on this system, DECdns *must* be the first service in the list.
Enter an *ordered* list of the directory services you want to
use on
the system. If you enter more than one directory service,
separate them
by commas.
* Enter the directory services to use on the system
[DECdns,Local,Domain] : Local
Enter a node name for each directory service chosen.
For the directory service Domain, you will enter a fully qualified
host name for DNS/BIND. The fully qualified host name includes the
host name part and the domain name part. For example:
Domain - smilee.lkg.dec.com
For the directory services DECdns and Local file, you will enter a
node
full name. The node full name is the name of your system's node
object
in the directory service. It includes the namespace nickname,
and the
full list of directories leading to the node object name.
Examples of
node full names for the directory services DECdns and Local file
include:
Local file - LOCAL:.TomThumb
DECdns - XYZ_CORP:.sales.west_coast.WillyLoman
For the Local file, the namespace nickname LOCAL is prepended to
the
full name and is terminated with a colon (:). The namespace
nickname
"LOCAL" means that the Local file is used. The node object name
must
begin with a dot (.), and no element of the name (namespace name,
directory, or node object name) can be a null string. Please note
that
the namespace nickname "LOCAL" is reserved, and indicates that
the
Local file will be used on this system.
The Local file has the capability to hold 100,000 nodes, and it
can even
scale beyond that number. The actual number of nodes that the
Local file
can hold depends on the space available on your system.
** Enter the full name for directory service LOCAL :
**LOCAL:.QCOCAL**
*
The node synonym is an alphanumeric character string between 1
and 6
characters long that contains at least one alphabetic character.
If this
system had previously been running DECnet Phase IV software, then
the old
nodename should be used as the synonym. If this system is joining
a DECnet
network for the first time, any name can be used for the synonym,
as long
as it meets the criteria listed above, and is unique within the
network.
* What is the synonym name for this node? : QCOCAL
* What type of node (Endnode or Router)? [ENDNODE] :
A DECnet-Plus system may or may not use a DECnet Phase IV-style
node
address. A node address of 0.0 indicates that this DECnet-Plus
system
will be communicating with OSI systems only. If your network
contains
some systems running DECnet Phase IV, you may want to specify a
compatible
address in order to communicate with them. If your network
consists
solely of OSI systems, this is not required.
The DECnet Phase IV node address consists of an area number
(between 1
and 63), and a node number within the area (between 1 and 1023).
** Enter PhaseIV Address [1.1] :
**42.420**
*%NET$CONFIGURE-I-SCANCONFIG, scanning device configuration - please wait
Determining DTSS timezone rules from OpenVMS information...
%NET$CONFIGURE-I-CREDEFOSITEMPLATE, created default OSI templates
%NET$CONFIGURE-I-EVDDEFAULT, providing default Event Dispatcher
configuration
%NET$CONFIGURE-I-MAKEACCOUNT, this procedure creates user account
CML$SERVER
%NET$CONFIGURE-I-MAKEACCOUNT, this procedure creates user account
MAIL$SERVER
%NET$CONFIGURE-I-MAKEACCOUNT, this procedure creates user account
VPM$SERVER
%NET$CONFIGURE-I-MAKEACCOUNT, this procedure creates user account
MIRRO$SERVER
%NET$CONFIGURE-I-MAKEACCOUNT, this procedure creates user account
PHONE$SERVER
By default, MOP is not started by NET$STARTUP. In order to make
this system service MOP requests, NET$STARTUP_MOP must be
defined
to signal NET$STARTUP to load the MOP software. This symbol is
normally defined in SYS$STARTUP:NET$LOGICALS.COM.
Answering YES to the following question will modify
SYS$STARTUP:NET$LOGICALS.COM for you, to enable MOP service on
this system. Answering NO will remove the logical name
definition
from SYS$STARTUP:NET$LOGICALS.COM. Note that this will have no
effect if the NET$STARTUP_MOP is defined elsewhere.
* Load MOP on this system? [NO] :
Summary of Configuration
Node Information:
Node Type: ENDNODE
Directory Services Chosen: LOCAL
Primary Directory Service: LOCAL
Local Full name: LOCAL:.QCOCAL
Node Synonym: QCOCAL
Phase IV Address: 42.420
Phase IV Prefix: 49::
Autoconfiguration of Network Addresses: Enabled
Session Control Address Update Interval: 10
Routing ESHello Timer: 600
Routing ES Cache Size: 512
Device Information:
Device: XQA0 (DELQA):
Data Link name: CSMACD-0
Routing Circuit Name: CSMACD-0
Transport Information:
NSP Transport: Configured
Maximum number of logical links: 200
Maximum Transmit and Receive Window: 20
Maximum Receive Buffers: 4000
Flow Control Policy: Segment Flow Control
OSI Transport: Configured
Maximum number of logical links: 200
Maximum Transmit and Receive Window: 20
Maximum Receive Buffers: 4000
OSI applications over TCP/IP: Enabled
DECnet applications over TCP/IP: Enabled
Congestion Avoidance Disabled
Event Dispatcher Configuration:
Sinks: local_sink
Outbound Streams: local_stream
Phase IV Relay: Enabled
* Do you want to generate NCL configuration scripts? [YES] :
%NET$CONFIGURE-I-CHECKSUM, checksumming NCL management scripts
* Do you want to start the network? [YES] :
%STDRV-W-NOTSYSTEM, STARTUP is not running from the SYSTEM account.
-STDRV-W-UNPREDICT, Results are unpredictable.
Copyright 2000 Compaq Computer Corporation. All rights reserved.
%NET-I-LOADED, executive image LES$LES_V30.EXE loaded
%NET-I-LOADED, executive image NET$ALIAS.EXE loaded
%NET-I-LOADED, executive image NET$SESSION_CONTROL.EXE loaded
%NET$STARTUP-I-STARTPROCESS, starting process DNS
%NET-I-LOADED, executive image SYS$NAME_SERVICES.EXE loaded
%RUN-S-PROC_ID, identification of created process is 00000273
%NET$STARTUP-I-EXECUTESCRIPT, executing NCL script
SYS$SYSROOT:[SYSMGR]NET$NODE_STARTUP.NCL;
%NET-I-LOADED, executive image NET$CSMACD.EXE loaded
%NET$STARTUP-I-EXECUTESCRIPT, executing NCL script
SYS$SYSROOT:[SYSMGR]NET$CSMACD_STARTUP.NCL;
%NET$STARTUP-I-EXECUTESCRIPT, executing NCL script
SYS$SYSROOT:[SYSMGR]NET$SESSION_STARTUP.NCL;
%LES-S-PROC_ID, identification of created process is 00000274
%LES-I-LOADING, loading NET$ component NETMANPPI from
SYS$COMMON:[SYS$LDR]LES$NETMAN.EXE;1
%LES-I-LOADING, loading NET$ component NETMANLDR from
SYS$COMMON:[SYS$LDR]LES$NETMANLDR.EXE;1
%LES-I-LOADING, loading NET$ component LES$ROUTING from
SYS$COMMON:[SYS$LDR]NET$ROUTING_ES.EXE;1
%NET$STARTUP-I-EXECUTESCRIPT, executing NCL script
SYS$SYSROOT:[SYSMGR]NET$ROUTING_STARTUP.NCL;
%NET-I-LOADED, executive image NET$TRANSPORT_NSP.EXE loaded
%NET$STARTUP-I-EXECUTESCRIPT, executing NCL script
SYS$SYSROOT:[SYSMGR]NET$NSP_TRANSPORT_STARTUP.NCL;
%NET-I-LOADED, executive image NET$TPCONS.EXE loaded
%NET-I-LOADED, executive image NET$TRANSPORT_OSI.EXE loaded
%NET$STARTUP-I-EXECUTESCRIPT, executing NCL script
SYS$SYSROOT:[SYSMGR]NET$OSI_TRANSPORT_STARTUP.NCL;
%NET-I-LOADED, executive image NET$OSVCM.EXE loaded
%NET$STARTUP-I-STARTPROCESS, starting process ACP
%RUN-S-PROC_ID, identification of created process is 00000275
%RUN-S-PROC_ID, identification of created process is 00000276
%NET$STARTUP-I-EXECUTESCRIPT, executing NCL script
SYS$SYSROOT:[SYSMGR]NET$SEARCHPATH_STARTUP.NCL;
%NET$STARTUP-I-OPERSTATUS, DECnet-Plus for OpenVMS operational status is
RUNNING-MAJOR
%NET$CONFIGURE-I-FLUSHCACHE, flushing selected cache entries
Node 0
at 2016-05-14-17:20:28.850+00:00Iinf
%NET$CONFIGURE-I-NODERENAMED, node successfully renamed to LOCAL:.QCOCAL
Node 0 Session Control
at 2016-05-14-17:20:30.030+00:00Iinf
Node 0 Session Control
at 2016-05-14-17:20:30.040+00:00Iinf
Node 0 Session Control
at 2016-05-14-17:20:30.050+00:00Iinf
Node 0 Session Control
at 2016-05-14-17:20:30.060+00:00Iinf
Node 0 Session Control
at 2016-05-14-17:20:30.420+00:00Iinf
Characteristics
Maintain Backward Soft Links = True
Directory Service: Local name file
Error - Node name lookup failure
LOCAL:.QCOCAL
Number of nodes reported on: 0
%NET$CONFIGURE-W-NODENOTREG, node is not completely registered yet in
the LOCAL directory service
%NET$CONFIGURE-I-IMPORTFILECREATED, created the DECNET_REGISTER import
file
Directory Service: Local name file
Updating nodes listed in
SYS$MANAGER:DECNET_REGISTER_IMPORT_FILE_QCOCAL.TXT
Number of nodes registered: 1
Number of nodes modified: 0
%NET$CONFIGURE-I-REGSUCCESS, node has been successfully registered in
the LOCAL directory service
Node 0
at 2016-05-14-17:20:32.940+00:00Iinf
%NET$CONFIGURE-I-NODERENAMED, node successfully renamed to LOCAL:.QCOCAL
%STDRV-W-NOTSYSTEM, STARTUP is not running from the SYSTEM account.
-STDRV-W-UNPREDICT, Results are unpredictable.
Copyright 2000 Compaq Computer Corporation. All rights reserved.
%NET$STARTUP-I-STARTPROCESS, starting process EVD
%RUN-S-PROC_ID, identification of created process is 00000277
%NET$STARTUP-I-EXECUTESCRIPT, executing NCL script
SYS$SYSROOT:[SYSMGR]NET$EVENT_STARTUP.NCL;
%NET$STARTUP-I-STARTPROCESS, starting process DTSS
%RUN-S-PROC_ID, identification of created process is 00000278
%NET$STARTUP-I-EXECUTESCRIPT, executing NCL script
SYS$SYSROOT:[SYSMGR]NET$APPLICATION_STARTUP.NCL;
%NET-I-LOADED, executive image NET$LOOP_APPLICATION.EXE loaded
%NET$STARTUP-I-OPERSTATUS, DECnet-Plus for OpenVMS operational status is
RUNNING-ALL
%NET$CONFIGURE-I-CONFIGCOMPLETED, DECnet-Plus for OpenVMS configuration
completed
On 5/13/2016 8:38 AM, Majordomo at Update.UU.SE wrote:
> --
>
> Welcome to the hecnet mailing list!
>
> Please save this message for future reference. Thank you.
>
> If you ever want to remove yourself from this mailing list,
> you can send mail to<Majordomo at Update.UU.SE> with the following
> command in the body of your email message:
>
> unsubscribe hecnet
>
> or from another account, besidessupratim at riseup.net:
>
> unsubscribe hecnetsupratim at riseup.net
>
> If you ever need to get in contact with the owner of the list,
> (if you have trouble unsubscribing, or have questions about the
> list itself) send email to<owner-hecnet at Update.UU.SE> .
> This is the general rule for most mailing lists when you need
> to contact a human.
>
> [Last updated on: Sun Sep 2 2:33:13 2001]
> Welcome to the mailing list for HECnet, the Hobbyist DECnet.
> If you want to be removed from the list, send a mail to
> majordomo at update.uu.se with "unsubscribe hecnet" in the body.
> For some information about HECnet, visit
> http://www.update.uu.se/~bqt/hecnet.html
4 Jun
4 Jun
5:35 p.m.
Just wanted to give an update, as their have at least been some
interest, and this have already been ported to Unix and VMS by others.
Lots of changes, improvements and bugfixes have been done in the last
week. At this point, the editor is pretty stable, and working well.
I expect to implement more features and functionality over time, but
this is now a very usable editor, and I'll happily accept contributions,
if someone wants to hack on it. Just ping me, and I'll try and help and
support you getting started.
I've written a couple of documents on how to port this. Porting should
be very simple, I would hope, although there are always traps and issues
trying to really make something portable. So I'm also very happy to
receive bug reports and issues that people might discover in trying to
port this thing.
Of particular interest would be to get someone to port this to RSTS/E.
We have the same compiler, which means most things should just work.
However, there is a few OS dependent bits that needs to be written.
Nothing that I expect someone who knows how to program under RSTS/E
should find particularly hard. And on the plus side, you'll get an
editor that easily fits within the address space of a program under
RSTS/E, which can edit huge files, and many of them, at the same time,
at a reasonable speed, even on real hardware...
Johnny
On 2016-05-29 19:31, Johnny Billquist wrote:
Not sure if anyone really cares, but I figure it
don't hurt to tell
anyway...
I have for many years used a very old version of MicroEMACS for RSX. I
eventually started searching around for alternatives, but realized
during that search that most Emacs clones are horribly huge (including
MicroEMACS), not portable at all (even if they claim to be), and
generally also expects to just allocate gobs of memory to keep all data
in ram.
Now, RSX, being a PDP-11 OS, have a 16-bit address space limitation. So
just allocating memory is never going to be a solution. There is a C
compiler, which is pretty much ANSI C. But it is not Unix, and gives you
the C standard IO library, but not low level Unix calls.
On the plus side, most of the library can sit in supervisor space, and
not consume any memory in your process space.
Clones I've looked at:
MicroEMACS - Huge and difficult to port. Use lots of memory.
JOVE - Small (runs on 2.11BSD), but horribly difficult to port.
mg - Huge and difficult. Use lots of memory.
AMIS - Huge, and written in Pascal. Not necessarily bad, but adapting
the code to a new system requires mucking around some, made worse by the
small differences in different Pascal compilers, and the lack of any
preprocessor, as well as the bonehead type system in Pascal. Also use
lots of memory, but it has been made to run on small machines (including
PDP-11 with RSTS/E) in the past, so it is a solveable problem.
Atto - Hard to port.
JED - Huge.
I looked at dozens more, which were not even worth looking deeper into,
or to list here.
The long and short of it was that, even though there are numerous
implementations out there, they all suck, from my point of view.
With all that in mind, I decided to write my own Emacs clone instead
(yes, I got horribly upset with the lousy quality of most code I looked
at, if someone wants to hear some rants, contact me privately).
I started about a month ago, and at this point, it's working, and quite
useful. And I guess if other people are in a similar situation, they
might be interested in looking into this, and possibly make use of it.
Quick run through:
. ANSI C sources.
. Mostly uses the C standard IO library. Exception is terminal I/O,
which requires some small pieces reimplemented if you want to port it.
So, if you have an ANSI C compiler, porting should be very low effort.
. Only works on ANSI terminals today. It would be doable to extend with
other terminal support, but I don't have any need, and since I do not
have, nor want to depend on curses, it will require coding to either
have a module to uses curses, if that is wanted, or handling of specific
terminals.
. The compiled code, using PDP-11 C, ends (at the moment) up at around
36 Kbytes of binary. The C library and RMS sits mostly in supervisor
mode, and is not accounted for in this.
. Data usage is about 8K for various storage and strings.
. Code dependecies are very much in a tree, so overlaying is easy, if
wanted/needed, and that capability exists on the host.
. Since I compile with split I/D space, this means than about 56K of
dataspace can be used for buffering of various sorts.
. File buffers are kept in a temporary file, and read/written to memory
as needed (pretty much a demand-paging virtual memory implementation in
the application).
. The virtual, paged memory is about 4G, which is an absolute limit on
memory usage. Practical file limit is (I would guesstimate) around 1G.
. Most basic EMACS editing functions are implemented, including split
windows, multiple buffers, kill buffer, moving around in various ways,
and some semi-stupid automatic indentation handling for C code. Also
incremental searching in a proper fashion.
. Speed, tested on a real PDP-11/93 is pretty acceptable. Testing on a
file about 1000 lines takes a couple of second to open, and a couple of
seconds if you try to search from the start to the end. Most other
things move faster.
. The program is not suitable for editing binary data. The C standard
I/O library don't really lend itself to binary I/O, and this code have
to live within those constraints.
There are still lots of functionality that I'm working on adding, such
as repeats (almost done) and macros (only started thinking about it).
If people have functions they consider extra important, let me know, and
I'll see if I can add them. If people want to contribute code, I'll be
happy to incorporate changes as well, as long as they make sense.
The sources, as well as a compiled RSX-11M-PLUS binary for PDP-11 C
V1.2, can be found at HECnet: MIM::DU:[NEMA], or
ftp:://nema at mim.update.uu.se/.
This editor is now installed as ...EMA on MIM::, so if you type "EMA
filename", you can see how it works there.
It is now my tool for doing further development. I have ditched
MicroEMACS. So I'm constantly testing the thing, as I am developing
it... :-)
Maybe someone will find it useful...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
5 Jun
5 Jun
5:40 a.m.
Johnny,
I just got back from a trip today and got a chance to download both your latest
version of TCP/IP as well as the new EMAcs editor for RSX. I had never used emacs before
so I working up the learning curve, and so far I really like it a lot. for the first time
I'm able to use the 48 line mode of my terminal emulator on my iMac to edit files on
the PDP-11/83 in 48 line mode!
It took me a bit to understand that Prefix-1 (meta) is just the Escape key. Anyone who
has used emacs would have known this but I didn't. Also there is one typo in the
NEMA.HLP It says that the Quit command is C-C C-C and it should be C-X C-C. I'm still
learning about the various commands but this looks like an editor that I can really
benefit from with the multiple windows and large file capability.
The macro definition feature is useful for me, but I'm still learning how to use
it. Can a macro be executed a large number of times? I used to use the LEARN mode of KED
to quickly adjust field spacing in data files. You could see exactly what needed to be
done on 1 line then repeat the macro a few thousand times and it was quicker than writing
a debugging a program.
Thanks again for all the great enhancements to RSX!
Best Regards,
Mark
On Jun 4, 2016, at 10:35 AM, Johnny Billquist wrote:
Just wanted to give an update, as their have at least
been some interest, and this have already been ported to Unix and VMS by others.
Lots of changes, improvements and bugfixes have been done in the last week. At this
point, the editor is pretty stable, and working well.
I expect to implement more features and functionality over time, but this is now a very
usable editor, and I'll happily accept contributions, if someone wants to hack on it.
Just ping me, and I'll try and help and support you getting started.
I've written a couple of documents on how to port this. Porting should be very
simple, I would hope, although there are always traps and issues trying to really make
something portable. So I'm also very happy to receive bug reports and issues that
people might discover in trying to port this thing.
Of particular interest would be to get someone to port this to RSTS/E. We have the same
compiler, which means most things should just work. However, there is a few OS dependent
bits that needs to be written. Nothing that I expect someone who knows how to program
under RSTS/E should find particularly hard. And on the plus side, you'll get an editor
that easily fits within the address space of a program under RSTS/E, which can edit huge
files, and many of them, at the same time, at a reasonable speed, even on real
hardware...
Johnny
On 2016-05-29 19:31, Johnny Billquist wrote:
Not sure if anyone really cares, but I figure it
don't hurt to tell
anyway...
I have for many years used a very old version of MicroEMACS for RSX. I
eventually started searching around for alternatives, but realized
during that search that most Emacs clones are horribly huge (including
MicroEMACS), not portable at all (even if they claim to be), and
generally also expects to just allocate gobs of memory to keep all data
in ram.
Now, RSX, being a PDP-11 OS, have a 16-bit address space limitation. So
just allocating memory is never going to be a solution. There is a C
compiler, which is pretty much ANSI C. But it is not Unix, and gives you
the C standard IO library, but not low level Unix calls.
On the plus side, most of the library can sit in supervisor space, and
not consume any memory in your process space.
Clones I've looked at:
MicroEMACS - Huge and difficult to port. Use lots of memory.
JOVE - Small (runs on 2.11BSD), but horribly difficult to port.
mg - Huge and difficult. Use lots of memory.
AMIS - Huge, and written in Pascal. Not necessarily bad, but adapting
the code to a new system requires mucking around some, made worse by the
small differences in different Pascal compilers, and the lack of any
preprocessor, as well as the bonehead type system in Pascal. Also use
lots of memory, but it has been made to run on small machines (including
PDP-11 with RSTS/E) in the past, so it is a solveable problem.
Atto - Hard to port.
JED - Huge.
I looked at dozens more, which were not even worth looking deeper into,
or to list here.
The long and short of it was that, even though there are numerous
implementations out there, they all suck, from my point of view.
With all that in mind, I decided to write my own Emacs clone instead
(yes, I got horribly upset with the lousy quality of most code I looked
at, if someone wants to hear some rants, contact me privately).
I started about a month ago, and at this point, it's working, and quite
useful. And I guess if other people are in a similar situation, they
might be interested in looking into this, and possibly make use of it.
Quick run through:
. ANSI C sources.
. Mostly uses the C standard IO library. Exception is terminal I/O,
which requires some small pieces reimplemented if you want to port it.
So, if you have an ANSI C compiler, porting should be very low effort.
. Only works on ANSI terminals today. It would be doable to extend with
other terminal support, but I don't have any need, and since I do not
have, nor want to depend on curses, it will require coding to either
have a module to uses curses, if that is wanted, or handling of specific
terminals.
. The compiled code, using PDP-11 C, ends (at the moment) up at around
36 Kbytes of binary. The C library and RMS sits mostly in supervisor
mode, and is not accounted for in this.
. Data usage is about 8K for various storage and strings.
. Code dependecies are very much in a tree, so overlaying is easy, if
wanted/needed, and that capability exists on the host.
. Since I compile with split I/D space, this means than about 56K of
dataspace can be used for buffering of various sorts.
. File buffers are kept in a temporary file, and read/written to memory
as needed (pretty much a demand-paging virtual memory implementation in
the application).
. The virtual, paged memory is about 4G, which is an absolute limit on
memory usage. Practical file limit is (I would guesstimate) around 1G.
. Most basic EMACS editing functions are implemented, including split
windows, multiple buffers, kill buffer, moving around in various ways,
and some semi-stupid automatic indentation handling for C code. Also
incremental searching in a proper fashion.
. Speed, tested on a real PDP-11/93 is pretty acceptable. Testing on a
file about 1000 lines takes a couple of second to open, and a couple of
seconds if you try to search from the start to the end. Most other
things move faster.
. The program is not suitable for editing binary data. The C standard
I/O library don't really lend itself to binary I/O, and this code have
to live within those constraints.
There are still lots of functionality that I'm working on adding, such
as repeats (almost done) and macros (only started thinking about it).
If people have functions they consider extra important, let me know, and
I'll see if I can add them. If people want to contribute code, I'll be
happy to incorporate changes as well, as long as they make sense.
The sources, as well as a compiled RSX-11M-PLUS binary for PDP-11 C
V1.2, can be found at HECnet: MIM::DU:[NEMA], or
ftp:://nema at mim.update.uu.se/.
This editor is now installed as ...EMA on MIM::, so if you type "EMA
filename", you can see how it works there.
It is now my tool for doing further development. I have ditched
MicroEMACS. So I'm constantly testing the thing, as I am developing
it... :-)
Maybe someone will find it useful...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
8:12 a.m.
Hi, Mark.
Just a quick answer on the question of repeated runs of the keyboard
macro. Yes, check C-U, which you can use to give a count, which applies
to most commands.
I'll be back tonight, when I can comment more.
Johnny
On 2016-06-05 05:40, Mark Matlock wrote:
Johnny,
I just got back from a trip today and got a chance to download both your latest
version of TCP/IP as well as the new EMAcs editor for RSX. I had never used emacs before
so I working up the learning curve, and so far I really like it a lot. for the first time
I'm able to use the 48 line mode of my terminal emulator on my iMac to edit files on
the PDP-11/83 in 48 line mode!
It took me a bit to understand that Prefix-1 (meta) is just the Escape key. Anyone who
has used emacs would have known this but I didn't. Also there is one typo in the
NEMA.HLP It says that the Quit command is C-C C-C and it should be C-X C-C. I'm still
learning about the various commands but this looks like an editor that I can really
benefit from with the multiple windows and large file capability.
The macro definition feature is useful for me, but I'm still learning how to use
it. Can a macro be executed a large number of times? I used to use the LEARN mode of KED
to quickly adjust field spacing in data files. You could see exactly what needed to be
done on 1 line then repeat the macro a few thousand times and it was quicker than writing
a debugging a program.
Thanks again for all the great enhancements to RSX!
Best Regards,
Mark
On Jun 4, 2016, at 10:35 AM, Johnny Billquist wrote:
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Just wanted to give an update, as their have at
least been some interest, and this have already been ported to Unix and VMS by others.
Lots of changes, improvements and bugfixes have been done in the last week. At this
point, the editor is pretty stable, and working well.
I expect to implement more features and functionality over time, but this is now a very
usable editor, and I'll happily accept contributions, if someone wants to hack on it.
Just ping me, and I'll try and help and support you getting started.
I've written a couple of documents on how to port this. Porting should be very
simple, I would hope, although there are always traps and issues trying to really make
something portable. So I'm also very happy to receive bug reports and issues that
people might discover in trying to port this thing.
Of particular interest would be to get someone to port this to RSTS/E. We have the same
compiler, which means most things should just work. However, there is a few OS dependent
bits that needs to be written. Nothing that I expect someone who knows how to program
under RSTS/E should find particularly hard. And on the plus side, you'll get an editor
that easily fits within the address space of a program under RSTS/E, which can edit huge
files, and many of them, at the same time, at a reasonable speed, even on real
hardware...
Johnny
On 2016-05-29 19:31, Johnny Billquist wrote:
Not sure if anyone really cares, but I figure it
don't hurt to tell
anyway...
I have for many years used a very old version of MicroEMACS for RSX. I
eventually started searching around for alternatives, but realized
during that search that most Emacs clones are horribly huge (including
MicroEMACS), not portable at all (even if they claim to be), and
generally also expects to just allocate gobs of memory to keep all data
in ram.
Now, RSX, being a PDP-11 OS, have a 16-bit address space limitation. So
just allocating memory is never going to be a solution. There is a C
compiler, which is pretty much ANSI C. But it is not Unix, and gives you
the C standard IO library, but not low level Unix calls.
On the plus side, most of the library can sit in supervisor space, and
not consume any memory in your process space.
Clones I've looked at:
MicroEMACS - Huge and difficult to port. Use lots of memory.
JOVE - Small (runs on 2.11BSD), but horribly difficult to port.
mg - Huge and difficult. Use lots of memory.
AMIS - Huge, and written in Pascal. Not necessarily bad, but adapting
the code to a new system requires mucking around some, made worse by the
small differences in different Pascal compilers, and the lack of any
preprocessor, as well as the bonehead type system in Pascal. Also use
lots of memory, but it has been made to run on small machines (including
PDP-11 with RSTS/E) in the past, so it is a solveable problem.
Atto - Hard to port.
JED - Huge.
I looked at dozens more, which were not even worth looking deeper into,
or to list here.
The long and short of it was that, even though there are numerous
implementations out there, they all suck, from my point of view.
With all that in mind, I decided to write my own Emacs clone instead
(yes, I got horribly upset with the lousy quality of most code I looked
at, if someone wants to hear some rants, contact me privately).
I started about a month ago, and at this point, it's working, and quite
useful. And I guess if other people are in a similar situation, they
might be interested in looking into this, and possibly make use of it.
Quick run through:
. ANSI C sources.
. Mostly uses the C standard IO library. Exception is terminal I/O,
which requires some small pieces reimplemented if you want to port it.
So, if you have an ANSI C compiler, porting should be very low effort.
. Only works on ANSI terminals today. It would be doable to extend with
other terminal support, but I don't have any need, and since I do not
have, nor want to depend on curses, it will require coding to either
have a module to uses curses, if that is wanted, or handling of specific
terminals.
. The compiled code, using PDP-11 C, ends (at the moment) up at around
36 Kbytes of binary. The C library and RMS sits mostly in supervisor
mode, and is not accounted for in this.
. Data usage is about 8K for various storage and strings.
. Code dependecies are very much in a tree, so overlaying is easy, if
wanted/needed, and that capability exists on the host.
. Since I compile with split I/D space, this means than about 56K of
dataspace can be used for buffering of various sorts.
. File buffers are kept in a temporary file, and read/written to memory
as needed (pretty much a demand-paging virtual memory implementation in
the application).
. The virtual, paged memory is about 4G, which is an absolute limit on
memory usage. Practical file limit is (I would guesstimate) around 1G.
. Most basic EMACS editing functions are implemented, including split
windows, multiple buffers, kill buffer, moving around in various ways,
and some semi-stupid automatic indentation handling for C code. Also
incremental searching in a proper fashion.
. Speed, tested on a real PDP-11/93 is pretty acceptable. Testing on a
file about 1000 lines takes a couple of second to open, and a couple of
seconds if you try to search from the start to the end. Most other
things move faster.
. The program is not suitable for editing binary data. The C standard
I/O library don't really lend itself to binary I/O, and this code have
to live within those constraints.
There are still lots of functionality that I'm working on adding, such
as repeats (almost done) and macros (only started thinking about it).
If people have functions they consider extra important, let me know, and
I'll see if I can add them. If people want to contribute code, I'll be
happy to incorporate changes as well, as long as they make sense.
The sources, as well as a compiled RSX-11M-PLUS binary for PDP-11 C
V1.2, can be found at HECnet: MIM::DU:[NEMA], or
ftp:://nema at mim.update.uu.se/.
This editor is now installed as ...EMA on MIM::, so if you type "EMA
filename", you can see how it works there.
It is now my tool for doing further development. I have ditched
MicroEMACS. So I'm constantly testing the thing, as I am developing
it... :-)
Maybe someone will find it useful...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
7:41 p.m.
Mark, a little longer reply now...
On 2016-06-05 05:40, Mark Matlock wrote:
Johnny,
I just got back from a trip today and got a chance to download both your latest
version of TCP/IP as well as the new EMAcs editor for RSX. I had never used emacs before
so I working up the learning curve, and so far I really like it a lot. for the first time
I'm able to use the 48 line mode of my terminal emulator on my iMac to edit files on
the PDP-11/83 in 48 line mode!
Happy to hear that you find it useful. Yes, being able to use larger
screens is another good thing.
It took me a bit to understand that Prefix-1 (meta)
is just the Escape key. Anyone who has used emacs would have known this but I didn't.
Also there is one typo in the NEMA.HLP It says that the Quit command is C-C C-C and it
should be C-X C-C. I'm still learning about the various commands but this looks like
an editor that I can really benefit from with the multiple windows and large file
capability.
Yes, that Meta thingy would be well known to any Emacs user. To give a
bit more background on this, it comes from a time when there was only
ASCII, and ASCII is a 7-bit code. Since most serial ports, and terminals
could deal with 8 bits, some terminals decided that this 8th bit could
be used as a modifier. And that modifier was then tied to a key labelled
META. So, you had one more modifier key in addition to Control and
Shift. And this key set the 8th bit of a character. And the people who
did the original Emacs made use of this to get more functions on short
key sequences.
Now, not all terminals had Meta, so an alternative solution was
implemented, using ESC, where you first pressed ESC, and then the key
you wanted. But it was still called Meta in Emacs.
Now, as we got to 8-bit characters sets, the Meta key totally
disappeared, and only ESC was left (DEC tried to kill ESC too).
Fast forward to windowing systems like X11, and people once more wanted
more modifiers, and were not longer limited by the serial encoding used
by traditional terminals using serial communication. So in X11 (for
example) there is once more a Meta key. But this cannot be converted to
a serial line encoding as such. But, if you are using xterm, you can
actually tell xterm to sent ESC + key, if you hold down Meta and press a
key.
And thanks for the bug report on the help file. Fixed. I also updated it
with a couple of keys that I had not documented. As ^S/^Q if someones
used for flow control, I had implemented ^\ and ^_ as alternatives, but
actually ^S and ^Q are also bound, and if you turn off TTCYNC in RSX,
you can use those keys too. (And TTSYNC is not needed if you use telnet,
for example).
The macro definition feature is useful for me, but
I'm still learning how to use it. Can a macro be executed a large number of times? I
used to use the LEARN mode of KED to quickly adjust field spacing in data files. You could
see exactly what needed to be done on 1 line then repeat the macro a few thousand times
and it was quicker than writing a debugging a program.
I already answered about how to repeat commands in Emacs. I hope that
was clear enough, otherwise let me know, and I'll try to explain it better.
Johnny
Thanks again for all the great enhancements to RSX!
Best Regards,
Mark
On Jun 4, 2016, at 10:35 AM, Johnny Billquist wrote:
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Just wanted to give an update, as their have at
least been some interest, and this have already been ported to Unix and VMS by others.
Lots of changes, improvements and bugfixes have been done in the last week. At this
point, the editor is pretty stable, and working well.
I expect to implement more features and functionality over time, but this is now a very
usable editor, and I'll happily accept contributions, if someone wants to hack on it.
Just ping me, and I'll try and help and support you getting started.
I've written a couple of documents on how to port this. Porting should be very
simple, I would hope, although there are always traps and issues trying to really make
something portable. So I'm also very happy to receive bug reports and issues that
people might discover in trying to port this thing.
Of particular interest would be to get someone to port this to RSTS/E. We have the same
compiler, which means most things should just work. However, there is a few OS dependent
bits that needs to be written. Nothing that I expect someone who knows how to program
under RSTS/E should find particularly hard. And on the plus side, you'll get an editor
that easily fits within the address space of a program under RSTS/E, which can edit huge
files, and many of them, at the same time, at a reasonable speed, even on real
hardware...
Johnny
On 2016-05-29 19:31, Johnny Billquist wrote:
Not sure if anyone really cares, but I figure it
don't hurt to tell
anyway...
I have for many years used a very old version of MicroEMACS for RSX. I
eventually started searching around for alternatives, but realized
during that search that most Emacs clones are horribly huge (including
MicroEMACS), not portable at all (even if they claim to be), and
generally also expects to just allocate gobs of memory to keep all data
in ram.
Now, RSX, being a PDP-11 OS, have a 16-bit address space limitation. So
just allocating memory is never going to be a solution. There is a C
compiler, which is pretty much ANSI C. But it is not Unix, and gives you
the C standard IO library, but not low level Unix calls.
On the plus side, most of the library can sit in supervisor space, and
not consume any memory in your process space.
Clones I've looked at:
MicroEMACS - Huge and difficult to port. Use lots of memory.
JOVE - Small (runs on 2.11BSD), but horribly difficult to port.
mg - Huge and difficult. Use lots of memory.
AMIS - Huge, and written in Pascal. Not necessarily bad, but adapting
the code to a new system requires mucking around some, made worse by the
small differences in different Pascal compilers, and the lack of any
preprocessor, as well as the bonehead type system in Pascal. Also use
lots of memory, but it has been made to run on small machines (including
PDP-11 with RSTS/E) in the past, so it is a solveable problem.
Atto - Hard to port.
JED - Huge.
I looked at dozens more, which were not even worth looking deeper into,
or to list here.
The long and short of it was that, even though there are numerous
implementations out there, they all suck, from my point of view.
With all that in mind, I decided to write my own Emacs clone instead
(yes, I got horribly upset with the lousy quality of most code I looked
at, if someone wants to hear some rants, contact me privately).
I started about a month ago, and at this point, it's working, and quite
useful. And I guess if other people are in a similar situation, they
might be interested in looking into this, and possibly make use of it.
Quick run through:
. ANSI C sources.
. Mostly uses the C standard IO library. Exception is terminal I/O,
which requires some small pieces reimplemented if you want to port it.
So, if you have an ANSI C compiler, porting should be very low effort.
. Only works on ANSI terminals today. It would be doable to extend with
other terminal support, but I don't have any need, and since I do not
have, nor want to depend on curses, it will require coding to either
have a module to uses curses, if that is wanted, or handling of specific
terminals.
. The compiled code, using PDP-11 C, ends (at the moment) up at around
36 Kbytes of binary. The C library and RMS sits mostly in supervisor
mode, and is not accounted for in this.
. Data usage is about 8K for various storage and strings.
. Code dependecies are very much in a tree, so overlaying is easy, if
wanted/needed, and that capability exists on the host.
. Since I compile with split I/D space, this means than about 56K of
dataspace can be used for buffering of various sorts.
. File buffers are kept in a temporary file, and read/written to memory
as needed (pretty much a demand-paging virtual memory implementation in
the application).
. The virtual, paged memory is about 4G, which is an absolute limit on
memory usage. Practical file limit is (I would guesstimate) around 1G.
. Most basic EMACS editing functions are implemented, including split
windows, multiple buffers, kill buffer, moving around in various ways,
and some semi-stupid automatic indentation handling for C code. Also
incremental searching in a proper fashion.
. Speed, tested on a real PDP-11/93 is pretty acceptable. Testing on a
file about 1000 lines takes a couple of second to open, and a couple of
seconds if you try to search from the start to the end. Most other
things move faster.
. The program is not suitable for editing binary data. The C standard
I/O library don't really lend itself to binary I/O, and this code have
to live within those constraints.
There are still lots of functionality that I'm working on adding, such
as repeats (almost done) and macros (only started thinking about it).
If people have functions they consider extra important, let me know, and
I'll see if I can add them. If people want to contribute code, I'll be
happy to incorporate changes as well, as long as they make sense.
The sources, as well as a compiled RSX-11M-PLUS binary for PDP-11 C
V1.2, can be found at HECnet: MIM::DU:[NEMA], or
ftp:://nema at mim.update.uu.se/.
This editor is now installed as ...EMA on MIM::, so if you type "EMA
filename", you can see how it works there.
It is now my tool for doing further development. I have ditched
MicroEMACS. So I'm constantly testing the thing, as I am developing
it... :-)
Maybe someone will find it useful...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
6 Jun
6 Jun
3:49 a.m.
Johnny,
Thanks for the info on the Meta key and its role in Emacs. Also, thanks for the info on
^S/^Q I am used to them being used as flow control but did not know they could be disabled
with TTSYNC. The repeat Prefix works fine for me and will be very useful once I master the
Emacs commands. I do like not being tied to a VTxxx keyboard and still be able to full
screen edit files especially with the 48 lines capability.
I'll continue to experiment and if I run into anything that does seem right I'll
let you know. Being a novice at using Emacs I might encounter things that an experienced
user would not notice.
I did see what you meant about DEC trying to do away with Escape on my VT420 terminal
on my other 11/83 I had to enable the ~ key to be Escape in the VT setup.
Also, TCP/IP continues to be a great addition to RSX. It is great to be able to pull
files, disk images, and tape images down from various FTP sites directly into Files-11
disks. It is rock solid and is quite fast even on original hardware.
Thanks for everything,
Mark
On Jun 5, 2016, at 12:41 PM, Johnny Billquist wrote:
Mark, a little longer reply now...
On 2016-06-05 05:40, Mark Matlock wrote:
Johnny,
I just got back from a trip today and got a chance to download both your latest
version of TCP/IP as well as the new EMAcs editor for RSX. I had never used emacs before
so I working up the learning curve, and so far I really like it a lot. for the first time
I'm able to use the 48 line mode of my terminal emulator on my iMac to edit files on
the PDP-11/83 in 48 line mode!
Happy to hear that you find it useful. Yes, being able to use larger screens is another
good thing.
It took me a bit to understand that Prefix-1
(meta) is just the Escape key. Anyone who has used emacs would have known this but I
didn't. Also there is one typo in the NEMA.HLP It says that the Quit command is C-C
C-C and it should be C-X C-C. I'm still learning about the various commands but this
looks like an editor that I can really benefit from with the multiple windows and large
file capability.
Yes, that Meta thingy would be well known to any Emacs user. To give a bit more
background on this, it comes from a time when there was only ASCII, and ASCII is a 7-bit
code. Since most serial ports, and terminals could deal with 8 bits, some terminals
decided that this 8th bit could be used as a modifier. And that modifier was then tied to
a key labelled META. So, you had one more modifier key in addition to Control and Shift.
And this key set the 8th bit of a character. And the people who did the original Emacs
made use of this to get more functions on short key sequences.
Now, not all terminals had Meta, so an alternative solution was implemented, using ESC,
where you first pressed ESC, and then the key you wanted. But it was still called Meta in
Emacs.
Now, as we got to 8-bit characters sets, the Meta key totally disappeared, and only ESC
was left (DEC tried to kill ESC too).
Fast forward to windowing systems like X11, and people once more wanted more modifiers,
and were not longer limited by the serial encoding used by traditional terminals using
serial communication. So in X11 (for example) there is once more a Meta key. But this
cannot be converted to a serial line encoding as such. But, if you are using xterm, you
can actually tell xterm to sent ESC + key, if you hold down Meta and press a key.
And thanks for the bug report on the help file. Fixed. I also updated it with a couple of
keys that I had not documented. As ^S/^Q if someones used for flow control, I had
implemented ^\ and ^_ as alternatives, but actually ^S and ^Q are also bound, and if you
turn off TTCYNC in RSX, you can use those keys too. (And TTSYNC is not needed if you use
telnet, for example).
The macro definition feature is useful for me,
but I'm still learning how to use it. Can a macro be executed a large number of times?
I used to use the LEARN mode of KED to quickly adjust field spacing in data files. You
could see exactly what needed to be done on 1 line then repeat the macro a few thousand
times and it was quicker than writing a debugging a program.
I already answered about how to repeat commands in Emacs. I hope that was clear enough,
otherwise let me know, and I'll try to explain it better.
Johnny
Thanks again for all the great enhancements to RSX!
Best Regards,
Mark
On Jun 4, 2016, at 10:35 AM, Johnny Billquist wrote:
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol Just wanted to give an update, as their have at
least been some interest, and this have already been ported to Unix and VMS by others.
Lots of changes, improvements and bugfixes have been done in the last week. At this
point, the editor is pretty stable, and working well.
I expect to implement more features and functionality over time, but this is now a very
usable editor, and I'll happily accept contributions, if someone wants to hack on it.
Just ping me, and I'll try and help and support you getting started.
I've written a couple of documents on how to port this. Porting should be very
simple, I would hope, although there are always traps and issues trying to really make
something portable. So I'm also very happy to receive bug reports and issues that
people might discover in trying to port this thing.
Of particular interest would be to get someone to port this to RSTS/E. We have the same
compiler, which means most things should just work. However, there is a few OS dependent
bits that needs to be written. Nothing that I expect someone who knows how to program
under RSTS/E should find particularly hard. And on the plus side, you'll get an editor
that easily fits within the address space of a program under RSTS/E, which can edit huge
files, and many of them, at the same time, at a reasonable speed, even on real
hardware...
Johnny
On 2016-05-29 19:31, Johnny Billquist wrote:
Not sure if anyone really cares, but I figure it
don't hurt to tell
anyway...
I have for many years used a very old version of MicroEMACS for RSX. I
eventually started searching around for alternatives, but realized
during that search that most Emacs clones are horribly huge (including
MicroEMACS), not portable at all (even if they claim to be), and
generally also expects to just allocate gobs of memory to keep all data
in ram.
Now, RSX, being a PDP-11 OS, have a 16-bit address space limitation. So
just allocating memory is never going to be a solution. There is a C
compiler, which is pretty much ANSI C. But it is not Unix, and gives you
the C standard IO library, but not low level Unix calls.
On the plus side, most of the library can sit in supervisor space, and
not consume any memory in your process space.
Clones I've looked at:
MicroEMACS - Huge and difficult to port. Use lots of memory.
JOVE - Small (runs on 2.11BSD), but horribly difficult to port.
mg - Huge and difficult. Use lots of memory.
AMIS - Huge, and written in Pascal. Not necessarily bad, but adapting
the code to a new system requires mucking around some, made worse by the
small differences in different Pascal compilers, and the lack of any
preprocessor, as well as the bonehead type system in Pascal. Also use
lots of memory, but it has been made to run on small machines (including
PDP-11 with RSTS/E) in the past, so it is a solveable problem.
Atto - Hard to port.
JED - Huge.
I looked at dozens more, which were not even worth looking deeper into,
or to list here.
The long and short of it was that, even though there are numerous
implementations out there, they all suck, from my point of view.
With all that in mind, I decided to write my own Emacs clone instead
(yes, I got horribly upset with the lousy quality of most code I looked
at, if someone wants to hear some rants, contact me privately).
I started about a month ago, and at this point, it's working, and quite
useful. And I guess if other people are in a similar situation, they
might be interested in looking into this, and possibly make use of it.
Quick run through:
. ANSI C sources.
. Mostly uses the C standard IO library. Exception is terminal I/O,
which requires some small pieces reimplemented if you want to port it.
So, if you have an ANSI C compiler, porting should be very low effort.
. Only works on ANSI terminals today. It would be doable to extend with
other terminal support, but I don't have any need, and since I do not
have, nor want to depend on curses, it will require coding to either
have a module to uses curses, if that is wanted, or handling of specific
terminals.
. The compiled code, using PDP-11 C, ends (at the moment) up at around
36 Kbytes of binary. The C library and RMS sits mostly in supervisor
mode, and is not accounted for in this.
. Data usage is about 8K for various storage and strings.
. Code dependecies are very much in a tree, so overlaying is easy, if
wanted/needed, and that capability exists on the host.
. Since I compile with split I/D space, this means than about 56K of
dataspace can be used for buffering of various sorts.
. File buffers are kept in a temporary file, and read/written to memory
as needed (pretty much a demand-paging virtual memory implementation in
the application).
. The virtual, paged memory is about 4G, which is an absolute limit on
memory usage. Practical file limit is (I would guesstimate) around 1G.
. Most basic EMACS editing functions are implemented, including split
windows, multiple buffers, kill buffer, moving around in various ways,
and some semi-stupid automatic indentation handling for C code. Also
incremental searching in a proper fashion.
. Speed, tested on a real PDP-11/93 is pretty acceptable. Testing on a
file about 1000 lines takes a couple of second to open, and a couple of
seconds if you try to search from the start to the end. Most other
things move faster.
. The program is not suitable for editing binary data. The C standard
I/O library don't really lend itself to binary I/O, and this code have
to live within those constraints.
There are still lots of functionality that I'm working on adding, such
as repeats (almost done) and macros (only started thinking about it).
If people have functions they consider extra important, let me know, and
I'll see if I can add them. If people want to contribute code, I'll be
happy to incorporate changes as well, as long as they make sense.
The sources, as well as a compiled RSX-11M-PLUS binary for PDP-11 C
V1.2, can be found at HECnet: MIM::DU:[NEMA], or
ftp:://nema at mim.update.uu.se/.
This editor is now installed as ...EMA on MIM::, so if you type "EMA
filename", you can see how it works there.
It is now my tool for doing further development. I have ditched
MicroEMACS. So I'm constantly testing the thing, as I am developing
it... :-)
Maybe someone will find it useful...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
4:40 a.m.
Johnny,
One other great feature of your EMACS is that I can now cut text from my iMac and
paste it perfectly into my terminal emulator with no errors at all. I often want to move
a small section of code or some text into a file and EDT or PIP file.txt=TI: never worked
very well. Emacs works flawlessly. I use PowerTerm from Ericom which does the best
I've seen on a mac to map a VT keyboard (if you have the numeric keypad.
Thanks,
Mark
On Jun 5, 2016, at 12:41 PM, Johnny Billquist wrote:
Mark, a little longer reply now...
On 2016-06-05 05:40, Mark Matlock wrote:
Johnny,
I just got back from a trip today and got a chance to download both your latest
version of TCP/IP as well as the new EMAcs editor for RSX. I had never used emacs before
so I working up the learning curve, and so far I really like it a lot. for the first time
I'm able to use the 48 line mode of my terminal emulator on my iMac to edit files on
the PDP-11/83 in 48 line mode!
Happy to hear that you find it useful. Yes, being able to use larger screens is another
good thing.
It took me a bit to understand that Prefix-1
(meta) is just the Escape key. Anyone who has used emacs would have known this but I
didn't. Also there is one typo in the NEMA.HLP It says that the Quit command is C-C
C-C and it should be C-X C-C. I'm still learning about the various commands but this
looks like an editor that I can really benefit from with the multiple windows and large
file capability.
Yes, that Meta thingy would be well known to any Emacs user. To give a bit more
background on this, it comes from a time when there was only ASCII, and ASCII is a 7-bit
code. Since most serial ports, and terminals could deal with 8 bits, some terminals
decided that this 8th bit could be used as a modifier. And that modifier was then tied to
a key labelled META. So, you had one more modifier key in addition to Control and Shift.
And this key set the 8th bit of a character. And the people who did the original Emacs
made use of this to get more functions on short key sequences.
Now, not all terminals had Meta, so an alternative solution was implemented, using ESC,
where you first pressed ESC, and then the key you wanted. But it was still called Meta in
Emacs.
Now, as we got to 8-bit characters sets, the Meta key totally disappeared, and only ESC
was left (DEC tried to kill ESC too).
Fast forward to windowing systems like X11, and people once more wanted more modifiers,
and were not longer limited by the serial encoding used by traditional terminals using
serial communication. So in X11 (for example) there is once more a Meta key. But this
cannot be converted to a serial line encoding as such. But, if you are using xterm, you
can actually tell xterm to sent ESC + key, if you hold down Meta and press a key.
And thanks for the bug report on the help file. Fixed. I also updated it with a couple of
keys that I had not documented. As ^S/^Q if someones used for flow control, I had
implemented ^\ and ^_ as alternatives, but actually ^S and ^Q are also bound, and if you
turn off TTCYNC in RSX, you can use those keys too. (And TTSYNC is not needed if you use
telnet, for example).
The macro definition feature is useful for me,
but I'm still learning how to use it. Can a macro be executed a large number of times?
I used to use the LEARN mode of KED to quickly adjust field spacing in data files. You
could see exactly what needed to be done on 1 line then repeat the macro a few thousand
times and it was quicker than writing a debugging a program.
I already answered about how to repeat commands in Emacs. I hope that was clear enough,
otherwise let me know, and I'll try to explain it better.
Johnny
Thanks again for all the great enhancements to RSX!
Best Regards,
Mark
On Jun 4, 2016, at 10:35 AM, Johnny Billquist wrote:
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol Just wanted to give an update, as their have at
least been some interest, and this have already been ported to Unix and VMS by others.
Lots of changes, improvements and bugfixes have been done in the last week. At this
point, the editor is pretty stable, and working well.
I expect to implement more features and functionality over time, but this is now a very
usable editor, and I'll happily accept contributions, if someone wants to hack on it.
Just ping me, and I'll try and help and support you getting started.
I've written a couple of documents on how to port this. Porting should be very
simple, I would hope, although there are always traps and issues trying to really make
something portable. So I'm also very happy to receive bug reports and issues that
people might discover in trying to port this thing.
Of particular interest would be to get someone to port this to RSTS/E. We have the same
compiler, which means most things should just work. However, there is a few OS dependent
bits that needs to be written. Nothing that I expect someone who knows how to program
under RSTS/E should find particularly hard. And on the plus side, you'll get an editor
that easily fits within the address space of a program under RSTS/E, which can edit huge
files, and many of them, at the same time, at a reasonable speed, even on real
hardware...
Johnny
On 2016-05-29 19:31, Johnny Billquist wrote:
Not sure if anyone really cares, but I figure it
don't hurt to tell
anyway...
I have for many years used a very old version of MicroEMACS for RSX. I
eventually started searching around for alternatives, but realized
during that search that most Emacs clones are horribly huge (including
MicroEMACS), not portable at all (even if they claim to be), and
generally also expects to just allocate gobs of memory to keep all data
in ram.
Now, RSX, being a PDP-11 OS, have a 16-bit address space limitation. So
just allocating memory is never going to be a solution. There is a C
compiler, which is pretty much ANSI C. But it is not Unix, and gives you
the C standard IO library, but not low level Unix calls.
On the plus side, most of the library can sit in supervisor space, and
not consume any memory in your process space.
Clones I've looked at:
MicroEMACS - Huge and difficult to port. Use lots of memory.
JOVE - Small (runs on 2.11BSD), but horribly difficult to port.
mg - Huge and difficult. Use lots of memory.
AMIS - Huge, and written in Pascal. Not necessarily bad, but adapting
the code to a new system requires mucking around some, made worse by the
small differences in different Pascal compilers, and the lack of any
preprocessor, as well as the bonehead type system in Pascal. Also use
lots of memory, but it has been made to run on small machines (including
PDP-11 with RSTS/E) in the past, so it is a solveable problem.
Atto - Hard to port.
JED - Huge.
I looked at dozens more, which were not even worth looking deeper into,
or to list here.
The long and short of it was that, even though there are numerous
implementations out there, they all suck, from my point of view.
With all that in mind, I decided to write my own Emacs clone instead
(yes, I got horribly upset with the lousy quality of most code I looked
at, if someone wants to hear some rants, contact me privately).
I started about a month ago, and at this point, it's working, and quite
useful. And I guess if other people are in a similar situation, they
might be interested in looking into this, and possibly make use of it.
Quick run through:
. ANSI C sources.
. Mostly uses the C standard IO library. Exception is terminal I/O,
which requires some small pieces reimplemented if you want to port it.
So, if you have an ANSI C compiler, porting should be very low effort.
. Only works on ANSI terminals today. It would be doable to extend with
other terminal support, but I don't have any need, and since I do not
have, nor want to depend on curses, it will require coding to either
have a module to uses curses, if that is wanted, or handling of specific
terminals.
. The compiled code, using PDP-11 C, ends (at the moment) up at around
36 Kbytes of binary. The C library and RMS sits mostly in supervisor
mode, and is not accounted for in this.
. Data usage is about 8K for various storage and strings.
. Code dependecies are very much in a tree, so overlaying is easy, if
wanted/needed, and that capability exists on the host.
. Since I compile with split I/D space, this means than about 56K of
dataspace can be used for buffering of various sorts.
. File buffers are kept in a temporary file, and read/written to memory
as needed (pretty much a demand-paging virtual memory implementation in
the application).
. The virtual, paged memory is about 4G, which is an absolute limit on
memory usage. Practical file limit is (I would guesstimate) around 1G.
. Most basic EMACS editing functions are implemented, including split
windows, multiple buffers, kill buffer, moving around in various ways,
and some semi-stupid automatic indentation handling for C code. Also
incremental searching in a proper fashion.
. Speed, tested on a real PDP-11/93 is pretty acceptable. Testing on a
file about 1000 lines takes a couple of second to open, and a couple of
seconds if you try to search from the start to the end. Most other
things move faster.
. The program is not suitable for editing binary data. The C standard
I/O library don't really lend itself to binary I/O, and this code have
to live within those constraints.
There are still lots of functionality that I'm working on adding, such
as repeats (almost done) and macros (only started thinking about it).
If people have functions they consider extra important, let me know, and
I'll see if I can add them. If people want to contribute code, I'll be
happy to incorporate changes as well, as long as they make sense.
The sources, as well as a compiled RSX-11M-PLUS binary for PDP-11 C
V1.2, can be found at HECnet: MIM::DU:[NEMA], or
ftp:://nema at mim.update.uu.se/.
This editor is now installed as ...EMA on MIM::, so if you type "EMA
filename", you can see how it works there.
It is now my tool for doing further development. I have ditched
MicroEMACS. So I'm constantly testing the thing, as I am developing
it... :-)
Maybe someone will find it useful...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
2883
days inactive
2891
days old
14 comments
6 participants
participants (6)
-
bqt＠softjar.se -
jhfinedp3k＠compsys.to -
mark＠matlockfamily.com -
mcguire＠neurotica.com -
paul7＠paul7.net -
supratim＠riseup.net