On 21 April 2016 at 14:43, Mattis Lind <mattislind at gmail.com> wrote: 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 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