User talk:TArntsen - Revision history

Roger at 14:01, 12 August 2016

2016-08-12T14:01:19Z

← Older revision		Revision as of 14:01, 12 August 2016
Line 6:		Line 6:
	--[[User:Mike\|Mike]] 09:11, 2 August 2009 (UTC)		--[[User:Mike\|Mike]] 09:11, 2 August 2009 (UTC)

	: Just wanted to say thanks for dropping the disassembler and ndfs tools. [[User:Roger\|Roger]] ([[User talk:Roger\|talk]]) 14:00, 12 August 2016 (UTC)		: Just wanted to say thanks for dropping in the disassembler and ndfs tools. [[User:Roger\|Roger]] ([[User talk:Roger\|talk]]) 14:00, 12 August 2016 (UTC)
	==Emulators==		==Emulators==
	Hi,		Hi,

Roger at 14:00, 12 August 2016

2016-08-12T14:00:46Z

← Older revision		Revision as of 14:00, 12 August 2016
Line 6:		Line 6:
	--[[User:Mike\|Mike]] 09:11, 2 August 2009 (UTC)		--[[User:Mike\|Mike]] 09:11, 2 August 2009 (UTC)

			: Just wanted to say thanks for dropping the disassembler and ndfs tools. [[User:Roger\|Roger]] ([[User talk:Roger\|talk]]) 14:00, 12 August 2016 (UTC)
	==Emulators==		==Emulators==
	Hi,		Hi,

TArntsen: Re: Power user

2012-08-14T13:09:20Z

Re: Power user

← Older revision		Revision as of 13:09, 14 August 2012
Line 65:		Line 65:

	Hi! I made you a [[NDWiki:Power users\|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. /[[User:Mike\|Mike]] 17:05, 13 August 2012 (UTC)		Hi! I made you a [[NDWiki:Power users\|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. /[[User:Mike\|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. --[[User:TArntsen\|TArntsen]] 13:09, 14 August 2012 (UTC)

Mike: /* Power user */ new section

2012-08-13T17:05:57Z

Power user: new section

← Older revision		Revision as of 17:05, 13 August 2012
Line 61:		Line 61:
	::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.. ;-).		::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.. ;-).
	::--[[User:TArntsen\|TArntsen]] 14:39, 15 July 2011 (CEST)		::--[[User:TArntsen\|TArntsen]] 14:39, 15 July 2011 (CEST)

			== Power user ==

			Hi! I made you a [[NDWiki:Power users\|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. /[[User:Mike\|Mike]] 17:05, 13 August 2012 (UTC)

TArntsen: more typos

2011-07-15T12:48:48Z

more typos

← Older revision		Revision as of 12:48, 15 July 2011
Line 59:		Line 59:
	:-- [[User:Roger\|Roger]] 06:28, 14 July 2011 (CEST)		:-- [[User:Roger\|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).		::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, ~~even though~~ 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 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.. ;-).		::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.. ;-).
	::--[[User:TArntsen\|TArntsen]] 14:39, 15 July 2011 (CEST)		::--[[User:TArntsen\|TArntsen]] 14:39, 15 July 2011 (CEST)

TArntsen: typo

2011-07-15T12:45:01Z

typo

← Older revision		Revision as of 12:45, 15 July 2011
Line 58:		Line 58:
	: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'.		: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)		:-- [[User:Roger\|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 ~~disassmbly~~ function, for example, and anything else I wish to do for every instruction. 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).		::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, even though 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 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.. ;-).		::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, even though 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 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.. ;-).
	::--[[User:TArntsen\|TArntsen]] 14:39, 15 July 2011 (CEST)		::--[[User:TArntsen\|TArntsen]] 14:39, 15 July 2011 (CEST)

TArntsen at 12:39, 15 July 2011

2011-07-15T12:39:48Z

← Older revision		Revision as of 12:39, 15 July 2011
Line 58:		Line 58:
	: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'.		: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)		:-- [[User:Roger\|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 disassmbly function, for example, and anything else I wish to do for every instruction. 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, even though 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 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.. ;-).
			::--[[User:TArntsen\|TArntsen]] 14:39, 15 July 2011 (CEST)

Roger: Reverted edits by Lu (talk) to last revision by Roger

2011-07-15T02:58:15Z

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

Lu at 01:51, 15 July 2011

2011-07-15T01:51:35Z

@@ Line 1: / Line 1: @@
-Hi, and welcome to the NDWiki!
+If you're thinking about a treat					http://www.comprarembts.com/mbt-scarpe-italia.html	of jewellery for somebody specific
+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
-I see that you are very familiar with the wiki technology and you have already contributed with valuable information. That's great!
+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
-If you have any idea on how to improve this wiki, don't hesitate to bring that up on the [[NDWiki:Community Portal]].
+Natural gemstones are found in nature					http://www.comprarembts.com/mbt-scarpe-vendita.html	Laboratory-created stones are made within of a laboratory
+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

Roger: /* Disassembler */

2011-07-14T04:28:15Z

Disassembler

← Older revision		Revision as of 04:28, 14 July 2011
Line 45:		Line 45:
	: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.		: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)		:-- [[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)