ND-10 software - Re: Harris H800 Computer

[Tor Arntsen]

On 21 April 2016 at 14:43, Mattis Lind <mattislind at gmail.com> wrote:

> PED2.DMK and DISK8.IMD is the same disk, but different ways of reading it
> off the disk. I used both the standard PC-floppy and then also the
> catweasel card. I tried the catweasel for some floppies that I had reading
> trouble with.
>
> I am really interested in hearing more about your emulator!
>
> /Mattis

Notis-calc (from floppy NDDISK33) runs fine, at least. I just had to
install a version of ddbtables-d which has support for VT100 (the one
which is on the floppy doesn't). I never got around to write a
Tandberg terminal emulator.. but vt100 works fine in an xterm.
As with every ND GUI program the help system is intuitive, fast, and
useful. That spreadsheet is easy to use. I have never used notis-calc
before, but it's so easy that I could as well use it instead of
gnumeric.

Screenshot: http://picpaste.com/notis-calc.png
(trying an image service I haven't used before)

Well then, the emulator.. it's a limited ND-1x0 emulator.
First, I haven't made this available anywhere. The only parts I've
"published" is the disassembler, and 'ndfs' which is a tool to read ND
(or SINTRAN) filesystems (which I use to extract files from those
floppy images, after converting from IMD to raw images).

The only thing my emulator has for it is the unfortunate fact that ND
emulators are few and far between.. they're as close to non-existing
as can be. I know of only two other efforts other than my own, and one
(the 'Haldens' emulator, a Windows-only version, with a couple of bugs
but otherwise quite good) dropped off the net years ago I think (I
have a copy of that one if someone wants it). My emulator isn't
Windows, I wrote it on Linux and tested on AIX, Solaris, IRIX, Tru64
(and Maemo, so it actually runs on my Nokia N900 mobile phone). It's
not something streamlined and github'able.

My emulator is not a full emulator, as it cannot execute SINTRAN-III
(the operating system, for those non-ND'ers out there). It's somewhat
like COM, the old CP/M emulator which doesn't run CP/M, as such, it
just runs CP/M applications. My ND emulator is the same. It can run
:PROG and :BPUN 1- or 2-bank executables from a Unix (and Linux)
command line. The monitor calls (system calls) are implemented as a
simulation of what SINTRAN would do. It tries to re-map the SINTRAN
file system into *nix, which isn't always straight forward, so there's
some clumsy mapping done with a resource file ($HOME/.s3rc), so that
when notis-calc tries to open 'DDBTABLES-D:VTM' it's directed to a
*nix file like so (cut from the .s3rc file):

DDBTABLES-D:VTM         /home/tor/vtm/DDBTABLES-D10.VTM
Another example:
UE-ERMSG-EN-C:ERR   /home/tor/sintran/fs/ue-ermsg-en-c09.err

(it's perfectly possible to have filenames with ':' in *nix of course,
but as I also need to map to specific versions I sometimes use normal
*nix format. SINTRAN has some interesting file name handling, e.g.
FILE--ABC: maps to FILE-X-ABC: and FILE-SYZ-ABC: and so on. So it's
not always a simple mapping.)

I haven't done anything with my emulator since around 2011. By then it
executed nearly[*] everything I have, until now, including PED
(Programmer's Editor), Fortran, Planc, BRF-linker etc. The only
"normal" (i.e. not stand-alone, non-OS, bare-metal test programs)
application it can't execute is NOTIS-WP (Word Processor Suite),
because WP "overlays" parts of itself with segments. I have never
figured out how the segment file is laid out for this, I couldn't find
any documentation and I never investigated that when I had physical
machines available (up to around 1995), although I peeked and poked
inside nearly everything else.. in any case, I couldn't implement the
monitor calls necessary to support NOTIS-WP. So NOTIS-CALC is an
exception to the NOTIS suite, as it doesn't use segments. It's nice to
have something new to execute.
I tried the Simula compiler too (from another of Mattis' floppies),
had to add a new monitor call (mon 222), but it doesn't actually run.
A new challenge then..

( [*] There's something else the emulator doesn't handle well, and
that's 'chained' applications which execute one after another by
calling SINTRAN command-line functions to load the next program - the
CAT-Pascal compiler for ND-100 is one of those, as it consists of a
set of programs to run the various compilation stages. I don't have
support for SINTRAN command line calls.)

Because the Unix-SINTRAN filesystem mapping is awkward, and makes for
a not very streamlined, user-friendly emulator, I wanted to implement
a real SINTRAN filesystem environment/layer, and run the programs from
inside there. That would make things better. Particularly because it
was so easy and useful to write tools that manipulated the filesystem
directly, I wrote many such tools back in the day. That's tricky to
handle properly in my current emulator.  (It works, but.. it's not
nice.)
But I never got around to write that one either.

One thing I noticed while implementing this thing is that the original
NORD-10 instruction set is very elegant, and simple to decode.
RISC-like, in a way. The ND-100 variants added more and more 'special'
instructions, many of them meant to support later SINTRAN-III
versions, and they did, but also some rather complex instructions to
support compilers. But, as compiler writers know, it's better if the
output of the compiler runs on all the hardware.. and none of the
compilers ever started using those fancy instructions in the generated
code. Not one. As the compilers are implemented in (for the most part)
PLANC, which is just another compiler, the compilers themselves don't
execute fancy instructions either.

The problem with the new instructions is that they're not elegant
anymore, decoding adds a lot of testing and branching. But, they're
mostly not needed... the special SINTRAN instructions are necessary
though, for later versions of SINTRAN-III. Some instructions are not
documented (e.g. the GECO instruction, named after one main customer:
The Geophysical Company of Norway, an oil/seismic survey company). I
eventually figured out that the GECO instruction was used by SINTRAN
itself, to deduce which version of the CPU was running.
But these instructions are messing up my emulator. So I tired of the
effort to write a full emulator. It would be nice to run SINTRAN, at
least those undocumented moncalls would be available then. But I doubt
it happens. Maybe when I retire.. or, if I could get my hands on a
real, working ND computer again, then I could figure out the tricky
parts. I used to delve deep into the system back in the day, I loved
ND computers - you could get as close to the metal as you wanted, and
you could walk through the operating system. The only problem with ND
was the flat filesystem. I liked everything else. Heck, I liked the
filesystem too.. not as a *filesystem* for storing files, I much
prefer *nix, but the design and layout was so easy and well-documented
and easy to write tools for.

We (a few of us, including at least one more member of this list) used
to document everything ND we could figure out on the 'ndwiki.org'
site, but for unknown reasons (to me at least) it started going
offline more and more a couple of years back, and then never came
back. I didn't manage to get archive.org to copy everything before it
went, although I got quite a few pages archived before it went for
good. Without that site there's not much available on the net. Another
reason my work on this stopped.

Lastly I should add that my emulator started as an ad-hoc thing, as I
had originally started writing an ND-500/5000 emulator. That's a
32-bit system, it uses an ND-100 (or in practice an ND-110 or ND-120)
16-bit mini as a front-end processor. The '100 runs SINTRAN-III, the
500(0) runs 32-bit applications. Harvard design.  At one point I
wanted to write some assembly programs as part of the testing, and the
ND-500(0) assembler is a cross-assembler which executes in the ND-100.
So I started writing an emulator for the '100, one instruction at the
time, running the assembler until it hit an instruction or a monitor
call my emulator didn't know. Implement that, and repeat. So it grew
organically from there. Later I managed to retrieve some backup images
from my old CCTs, and was given another image from elsewhere, and I
also imaged my old 5 1/4" floppies. With all of that I suddenly had
PED and some compilers, so I continued with those: Run, hit something
unknown, implement, repeat. No big overall plan behind it.

-Tor