User talk:TArntsen: Difference between revisions

From NDWiki
Jump to navigation Jump to search
No edit summary
m (Reverted edits by Lu (talk) to last revision by Roger)
Line 1: Line 1:
If you're thinking about a treat http://www.comprarembts.com/mbt-scarpe-italia.html of jewellery for somebody specific
Hi, and welcome to the NDWiki!
Gold suggests all gold or 24 karat (24K) gold http://www.comprarembts.com/mbt-uomo.html for that reason that 24K gold is soft, it's frequently mixed with other
 
Platinum is frequently a beneficial material http://www.comprarembts.com/mbt-scarpe.html that fees additional than gold. It is frequently mixed with other comparable metals
I see that you are very familiar with the wiki technology and you have already contributed with valuable information. That's great!
Natural gemstones are found in nature http://www.comprarembts.com/mbt-scarpe-vendita.html Laboratory-created stones are made within of a laboratory
If you have any idea on how to improve this wiki, don't hesitate to bring that up on the [[NDWiki:Community Portal]].
A diamond's worth is dependent on 4 criteria http://www.comprarembts.com/mbt-delle-donne.html color, cut, clarity, and carat. The clarity and color of the diamond frequently
 
--[[User:Mike|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. [[User:Tingo|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. [[User:Gandalf|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. [[User:TArntsen|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... :) [[User:Roger|Roger]] 02:15, 12 July 2011 (CEST)
:[[User:TArntsen|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:
<pre>
#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 */
</pre>
: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.
:-- [[User:TArntsen|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:
<pre>
/* OpToStr
* IN: pointer to string ,raw operand
* OUT: Sets the string with the dissassembled operand and values
*/
void OpToStr(char *opstr, ushort operand);
</pre>
: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'.
:-- [[User:Roger|Roger]] 06:28, 14 July 2011 (CEST)

Revision as of 02:58, 15 July 2011

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)
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)