User talk:TArntsen

Hi, and welcome to the NDWiki!

I see that you are very familiar with the wiki technology and you have already contributed with valuable information. That's great! If you have any idea on how to improve this wiki, don't hesitate to bring that up on the NDWiki:Community Portal.

--Mike 09:11, 2 August 2009 (UTC)

Just wanted to say thanks for dropping the disassembler and ndfs tools. Roger (talk) 14:00, 12 August 2016 (UTC)

Emulators

Hi, Any chance that you will share your ND-100 and ND-500(0) emulators? Perhaps it is open source? Such a thing would be cool to have. Torfinn 12:45, 25 October 2010 (UTC)

I will probably release them as GPL at one point. I haven't tried to share the development with anyone because the development itself was as much a point as the end result - I wanted to have a personal project to work on, as I don't get enough "proper" programming projects back at work anymore. So I've been spending many nice deep-flow hours with a laptop in coffee shops during (in particular) vacations (and some weekends).

The ND-100 emulator is in reasonably good shape, there's only one bug I'm aware of and it affects almost nothing. There are parts missing, it cannot handle applications using segments (those would have to be read from e.g. SEGFIL0:DATA from a real Sintran filesystem), so no Notis-WP. There are also many missing monitor calls, e.g. mon xmsg (which I will probably implement first, when I get to the next vacation). Working applications are Fortran-100, ftn, PED, brf-linker, nrl, assembler-500, vtm-assemble, mac, and some more. Plus some of my own old applications. And I can write new Fortran programs, link them, and they run. Oh, and this is user-level only, as mentioned elsewehere this emulator isn't like the ND100_emulator_project with its goal of running Sintran.

The ND-500 emulator isn't really there yet. The ND-500 instruction set is huge, and there are some subtle bugs that I haven't resolved yet (for this one I really suffer from not having access to a real ND-500(0) to check some stuff out. The docu isn't entirely complete.). Unlike the ND-100 emulator I'm not bootstrapped to the point where I can compile and link new applications. The Fortran-500 compiler runs, but there are parsing errors when compiling legitimate programs, for example. The linker also has some problems. Some of my own old applications work though, including a ported Pascal-to-C translator by Samuel H. Smith, and, most importantly, my old 'unzip' program which I wrote back in 1990/1991 - it's a zip/unzip package which could handle ND domain files and :prog files with holes. With that tool I could extract some of my old stuff, like the Fortran compiler and the linker (I have lots of backup tapes but I don't get access to them - lost my 9-track CCT drive. But some stuff is in .zip files). But in any case the ND-500 emulator wouldn't be very useful for anyone else yet.

I also have some tools, debuggers and disassemblers for both architectures. I was actually planning to release the ND-100 disassembler a while ago, but then I got ambitious and wanted to add support for all the privileged instructions (so it could be used to directly disassemble the Sintran part of e.g. Gandalf's Sintran backup image), but the privileged instructions are a mess and the disassembler turned into a mess to at that point. So I stalled it. TArntsen 12:06, 26 October 2010 (UTC)

Disassembler

Tested it, and saw that it seems to cover a few more opcodes as well as do disassembly. I also basically develop nd100em just for fun and to keep whatever programming skills I once had somewhat alive. Anyway, the disassembler works fine as I can see, but have you considered dumping things like an ascii text representation of things say as % comments to the right of the code? that way it would be easy to pick out text strings etc. Also to solve * and ,I references as %LABELNOXXXX. (Solving for ,B and ,X would require a lot more code analysis I think) Hope you release the code someday... :) Roger 02:15, 12 July 2011 (CEST)

TArntsen 20:21, 13 July 2011 (CEST):

As it is, the disassembler cannot resolve labels etc. because the disassembler function itself is a single function:

disasm100 (const unsigned short instruction);

The whole header file looks as this:

#ifndef _DISASM100_H
#define _DISASM100_H

typedef int (*disasm_printf_function)(const char *format, ...);

/*
 * Change the default printf to something else:
 */
extern void
disasm100_set_printf (disasm_printf_function function);

/*
 * Disassemble instruction. Default output to stdout (printf),
 * may be changed with disasm_printf_function().
 */
extern void
disasm100 (const unsigned short instruction);

#endif /* _DECODE100_H */

So to disassemble, just pass it the instruction. ND-100 code is easy to disassemble because it's all in that single instruction. The stand-alone disassembler just loads the :PROG or :BPUN file (or any part of a file pointed to by -r and -o), and then feeds that function the instructions one by one. It would be easy though to add another alternative function which passes the current program counter (i.e. a two-parameter function), then it could at least calculate the relative addressing and put the absolute address in a comment, for example. Labels could presumably be done as well. For more advanced options either a full multi-pass disassembler or a post-processor wrapper would have to be added I presume.

-- TArntsen 20:21, 13 July 2011 (CEST)

Ok pretty much how tracing output then is done in the nd100em.

Basically the function prototype there is:

/* OpToStr
 * IN: pointer to string ,raw operand
 * OUT: Sets the string with the dissassembled operand and values
 */
void OpToStr(char *opstr, ushort operand);

Was using this when doing tracing, but not done a separate disassembler out of it sofar. Basically seems our work overlap quite a bit.. :) One annoying thing I realised with your disassembler is how easy it would have been to do tracing slighly different and get a pretty complete disassembly output as well. Oh well, one always supposed to learn by ones mistakes I think they say. :)

How is your emulator coming otherwise? Have gotten nd100em to the stage now I am trying to implement floppy and hdd functionality. Once thats in, it's time to start trying to 'boot'.

-- Roger 06:28, 14 July 2011 (CEST)

What I do in my emulator is that I have a callback inside the internal main loop that will be called only if set (which I do from my debugger, or from the runtime executer if I want a (disassembly) trace). So I can tell my debugger to ask the emulator to call back for every instruction, and in the debugger I call the disassembly function, for example, and anything else I wish to do for every instruction, e.g. register dumps. As for the emulator itself I've had it basically fully functional for nearly a year, in the sense that it runs anything that is feasible to run. With the exception of Notis WP, because the ND-100 version of Notis is divided into segments that are loaded as needed by a monitor call. And I haven't figured out how I can find the segments in the segment file, there doesn't seem to be sufficient documentation anywhere. There are other limitations to the emulator which are caused by the fact that I run it outside an ND filesystem, the applications believe they see an ND filesytem but in reality it's just a *nix filesystem. I have a simple remapping system in place (configuration file) for those cases where an application asks for e.g. (PACK-ONE:SYSTEM)SOME-FILE:DATA, but if not mapped that way it just uses those ND filesystem naming conventions directly. This creates some problems because some ND filesystem operations can't be mapped to *nix FS I/O, e.g. where an application uses a moncall to find the object entry of an open file, then closes the file, then updates and writes the object entry. For open files I keep a cache/mapping where I can handle it, but not for closed files. So I have been working a little bit on two different approaches, I will implement both of them at some point: One is to use a tool to analyze a *nix filesystem tree and create a little database which maps all the files there and includes an image with object entries for each of them, the other approach is to work with a complete ND filesystem image. But I have little time at the moment so I haven't finished any of them yet. Both approaches will make it possible to implement the filesystem monitor calls that can't easily be mapped directly to a *nix filesystem (at least not in a clean way).

My emulator is, as mentioned before, a user-level emulator: It executes one application directly. So it doesn't have memory mapping/page handling, it simply allocates two banks of 64 kw memory (or one, for one-bank programs) and that's it. It doesn't need any privileged instructions either, although I did implement a bunch of them (in a separate branch) so that I could do some limited instruction testing with INSTRUCTION-B. I will need to add some device I/O support though, starting with floppy support, so that I can run all of my old programs some of which work with low-level floppy (or tape) functions (and maybe low-level terminal functions as well - I wrote a full remote login/file serial line file transfer application back when I travelled everywhere to update software and found that it was difficult to be in 4 places at the same time. With X.25 and my program it was possible to do things remotely, also where point-to-point ND connections wasn't possible). So I thought I could as well implement the floppy handler with the proper driver API, that would make it easier to map to mon magtp (DeviceFunction) or, later, mon abstr/exabs. That led me down to supporting IOX(T) and starting with those privileged instructions. At this point I won't do memory management though, it'll probably slow down the emulator and I would only need it for running stand-alone test programs in full mode (would be fun however) or booting Sintran. So it's a different beast than your emulator. (when you get it to boot Sintran it should be possible to figure out some of the monitor call corner cases which aren't documented.. ;-).

--TArntsen 14:39, 15 July 2011 (CEST)

Power user

Hi! I made you a power user so you have some extra tools, since you do such a good job keeping the spammers away. I would be happy to know if some permissions is wrong or missing, or something else should be fixed. /Mike 17:05, 13 August 2012 (UTC)

Ah, OK! I'll continue to keep an eye out for spammers and when they show up I'll exercise the tools and we'll see how it works out. --TArntsen 13:09, 14 August 2012 (UTC)