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)

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)