Talk:ND100 emulator project: Difference between revisions

From NDWiki
Jump to navigation Jump to search
(→‎INSTRUCTION-C: new section)
(→‎Current status: update status)
 
(15 intermediate revisions by 3 users not shown)
Line 1: Line 1:
Progress?
=== Current status ===
Has this project stopped? Or is there progress somewhere? [[User:Tingo|Torfinn]] 16:00, 25 October 2010 (UTC)
* Unfortunately, there hasn't been any activity here (or on the dead mailing list) since Roger's post in 2016. [[User:Tingo|Torfinn]] ([[User talk:Tingo|talk]]) 19:53, 10 October 2023 (UTC)


Ok, I see that there has been some progress - nice. The file  (v0.1.7) doesn't exist at the URL provided. Will the mailinglist be resurrected? [[User:Tingo|Torfinn]] 19:36, 13 April 2011 (CEST)
* Revived, and active. /[[User:Roger|Roger]] ([[User talk:Roger|talk]]) 20:52, 29 July 2016 (UTC)
* Possibly thinking of putting it on github or somewhere public with issue tracker functionality etc. Will look into it.
* ATM working on floppy code, trying to get that to pass tests, once that is done floppy boot. [[User:Roger|Roger]] ([[User talk:Roger|talk]]) 23:22, 12 August 2016 (UTC)


Mailinglist will be resurrected sometime during the next few weeks, also links to updated code will be fixed.
[[Talk:ND100_emulator_project/Archived1|Archived]] old version of talk page to remove clutter, mostly about stuff that
The latest git code has some more bugfixes, so now almost runs INSTRUCTION-B testprogram.
is already solved or irrelevant at the moment.
[[User:Roger|Roger]] 17:29, 24 April 2011 (AWST)


=== Re. Known Bugs ===
=== Re. Known Bugs ===
About the ** ERROR **. WRONG VALUE OF P-REG AFTER TEST. LEVEL: ' messages. (btw. it should have said 'LEVEL 1', not just LEVEL..)<br>
I have not looked at how you do this in your emulator, but when I added some support to my user-level emulator for running "bare-bone", i.e. with levels and interrupt support (I developed an interest in looking into IOX and drivers), I ran into that same problem when running INSTRUCTION-B. To fix it you have to be careful about how the P register is left behind when you switch levels. Ref. e.g. page 23 in ND-06.26.1, and what's written about WAIT elsewhere. Basically as follows:
* Every instruction should finish with the P-register set to the correct next value (usually P+1, but sometimes P+2, or something else after jump istructions)
* The EXR instruction must not increment/change P by itself, the instruction it executes should do this.
* Now check for external interrupts, and do any level switching caused by this.
* If a WAIT was just performed then this may also cause a level switch
* At this point, fetch next instruction from current P. If a level switch was performed it will be the saved P from that level.
The level switch basically just have to switch register sets, and save previous level no. in the pvl register.
(This is fairly well documented, also in the older RM-100 manual.) Everything goes by itself after that: Just fetch a fresh instruction as usual and process. When level switch is performed the P in the saved register set will already point to the instruction to execute when coming back to that level, if you follow the procedure above.
INSTRUCTION-B runs pretty well in my emulator after I carefully looked at what I did with P (I had some snags related to WAIT and level switching), at least in NORD-10 mode - I have too many missing instructions for running in ND-100 mode. Oh, and I found a couple of non-documented ones, 142700 is one of them.
[[User:TArntsen|TArntsen]] 19:53, 1 May 2011 (CEST)
===Re. LEVEL Bugs ===
Thanks, will look into that. I do mostly as you said, but need to check WAIT if thats run through EXR...
* Every instruction itselt does the P register changing, when depending on how itself uses P.
* EXR does not, it just calls the main operand function recursively with the operand to do.
* If EXR is EXR is executed, it will not do that however, it will just set Z=1, and do a lvl 14 trap.
* Finish operand function, and if we have a pending interrupt, do the changes of PIL/PVL and thus switch interrupt level.
* Start next instruction cycle.
However think the bug might be something else completely, as it wont print LEVEL 1 for me, it prints "LEVEL '". So going through all add,sub,set and shift instructions currently.
Also think I got a bug in the handling of paging and alternate page tables, but thats turned off when this happen so shouldnt affect it.


Do you have any more info on the undocumented instructions?? I seem to have hit an undocumented IOX as well (IOX 3).
Do you have any more info on the undocumented instructions?? I seem to have hit an undocumented IOX as well (IOX 3).
[[User:Roger|Roger]] 07:29, 2 May 2011 (AWST)
[[User:Roger|Roger]] 07:29, 2 May 2011 (AWST)
:No success yet with the undocumented instructions. I tried to run 142700 through the disassembler in BRF-LINKER and BRF-EDITOR, but they didn't know it (I used that method successfully to get on the right track for the undocumented [[IOT]], for example). Did you hit IOX 3 in the test program? Devices below 4 are the only ones which shouldn't ever exist, so maybe that IOX 3 is a test by iteself, to trigger an IOX error interrupt on level 14? -- [[User:TArntsen|TArntsen]] 09:10, 2 May 2011 (CEST)
:No success yet with the undocumented instructions. I tried to run 142700 through the disassembler in BRF-LINKER and BRF-EDITOR, but they didn't know it (I used that method successfully to get on the right track for the undocumented [[IOT]], for example). Did you hit IOX 3 in the test program? Devices below 4 are the only ones which shouldn't ever exist, so maybe that IOX 3 is a test by iteself, to trigger an IOX error interrupt on level 14? -- [[User:TArntsen|TArntsen]] 09:10, 2 May 2011 (CEST)


Line 41: Line 20:
Well, its tested very early, as the first try with 142700. I have implemented both Illegal instruction and IOX error, so that is not a problem, but the way it's called very early in the test program sort of hints that it's checking if somethings available. I was also thinking of either things on NORD1/NORD10 or ND120.
Well, its tested very early, as the first try with 142700. I have implemented both Illegal instruction and IOX error, so that is not a problem, but the way it's called very early in the test program sort of hints that it's checking if somethings available. I was also thinking of either things on NORD1/NORD10 or ND120.


Anyway, the bughunt is still on, your post put me on track of bugs in the IRQ handling code, so right now trying to fix that without totally breaking something else. -- [[User:Roger|Roger]] 18:05, 2 May 2011 (AWST)
::Great! Good work!  :)  /[[User:Mike|Mike]] 16:31, 2 May 2011 (CEST)


: '''Update: 142700 instruction:'''. 142700 is the [[GECO]] instruction! GECO, Geophysical Company of Norway (now it's been through a couple of mergers and is called something else) used to have lots of Norsk Data hardware for seismic processing. They also had ND computers on board (several friends and acquaintances of mine (including a former ND tech) used to work on those ships). They acquired a permanently assigned user-specified instruction. INSTRUCTION-B simply tests for its existence by doing a TRA IIC, then checks for value 4 which means 'illegal instruction'. I had forgotten about it, there's a writeup somewhere about the GECO instruction story but I don't have the reference handy. However, from what I can figure out from SINTRAN it looks like the instruction is part of the 'standard' CPU instruction set after some point, so checking for GECO is part of the code which tries to deduce exactly which CPU this is. The sequence (in SINTRAN) goes something like this:
: '''Update: 142700 instruction:'''. 142700 is the [[GECO]] instruction! GECO, Geophysical Company of Norway (now it's been through a couple of mergers and is called something else) used to have lots of Norsk Data hardware for seismic processing. They also had ND computers on board (several friends and acquaintances of mine (including a former ND tech) used to work on those ships). They acquired a permanently assigned user-specified instruction. INSTRUCTION-B simply tests for its existence by doing a TRA IIC, then checks for value 4 which means 'illegal instruction'. I had forgotten about it, there's a writeup somewhere about the GECO instruction story but I don't have the reference handy. However, from what I can figure out from SINTRAN it looks like the instruction is part of the 'standard' CPU instruction set after some point, so checking for GECO is part of the code which tries to deduce exactly which CPU this is. The sequence (in SINTRAN) goes something like this:
Line 64: Line 40:
::I love this GECO-story! I think it would fit well as a [[Main Page]] Did you know...  /[[User:Mike|Mike]] 01:57, 16 May 2011 (CEST)
::I love this GECO-story! I think it would fit well as a [[Main Page]] Did you know...  /[[User:Mike|Mike]] 01:57, 16 May 2011 (CEST)


===Update.===
Had a bug in the byte writing code that messed up a lot of things. Also fixed bugs in several other instructions, and known interrupt bugs fixed. Emulator runs a lot better now, and CONFIGURATIO-C08 is able to run completely through checking available memory and devices.
Now works to the degree that INSTRUCTION-B is usable to test instructions. Put up latest code as well. -- [[User:Roger|Roger]] 18:30, 8 May 2011 (AWST)


=== Re. Wanted Information ===
=== Re. Wanted Information ===
I see "PROG file format" still listed as wanted information.. the format is documented [[Talk:File_Formats|here]]. I believe it to be complete and correct, my own emulator has worked fine with :prog files since 2009. That description should be moved to an article, it's just that I'm not certain exactly where it should go (ref. my questions there). <br>
As for test programs, there should be something newer. [http://library.oddene.no/sintran/library/libhw/ND-830005-3-EN.pdf ND-830005.3 (1990) Test Program Description for ND-100/110] describes among others INSTRUCTION-VERIFY-C00 with a date of 1986-08-27. I have looked through all my floppies but I don't seem to have any copy, unfortunately. NB: Note that the document says that the test program execution monitor (TPE MONITOR) and all test programs are included in one single BPUN file. So TPE MONITOR is what we should look for, I assume.<br>
INSTRUCTION-B has a BCD test but it seems to be a dummy. I haven't implemented BCD tests in my emulator so it shouldn't have passed everything, but it does. And executing the BCD test individually just spits out 'BINARY CODED DECIMAL (ADDD...)  (NIY)  == END OF TEST ==' (plus levels) as with RUN. -- [[User:TArntsen|TArntsen]] 19:02, 14 May 2011 (CEST)
INSTRUCTION-B has a BCD test but it seems to be a dummy. I haven't implemented BCD tests in my emulator so it shouldn't have passed everything, but it does. And executing the BCD test individually just spits out 'BINARY CODED DECIMAL (ADDD...)  (NIY)  == END OF TEST ==' (plus levels) as with RUN. -- [[User:TArntsen|TArntsen]] 19:02, 14 May 2011 (CEST)
:Actually - scratch that. My emulator is in NORD-10 mode when it runs that BCD test, so it makes sense that INSTRUCTION-B handles it as dummy there at least. So, is it dummy also for ND-100/CE ? -- [[User:TArntsen|TArntsen]] 12:28, 15 May 2011 (CEST)
:Actually - scratch that. My emulator is in NORD-10 mode when it runs that BCD test, so it makes sense that INSTRUCTION-B handles it as dummy there at least. So, is it dummy also for ND-100/CE ? -- [[User:TArntsen|TArntsen]] 12:28, 15 May 2011 (CEST)
Line 86: Line 57:
</pre>
</pre>


=== MOVBF ===
Seems to have found an oddity??
MOVBF called with the following parameters in INSTRUCTION-B
*A:056121
*D:007776
*X:062121
*T:007776
Seems to be expected to fail with a non skip return as an overlap, but as far as I can tell
there is actually a 2 byte margin??? Am I missing something here?  [[User:Roger|Roger]] 14:37, 28 May 2011 (CEST)
:I agree it should do a skip return and there is no overlap. But are you sure that it expects no-skip return? It's a bit tricky to trace what happens, but this is what I usually get out of it when running the test:
<pre>
043646 : 140132 MOVBF
043650 : 151000 WAIT 0
022546 : 051005 LDT I * 5
022547 : 140660 EXR ST
022547 : 140660 IRR 10 DP
022550 : 146142 COPY SL DP
043626 : 050037 LDT * 37
043627 : 142065 SKP IF DA UEQ ST
043631 : 051036 LDT I * 36
043632 : 140660 EXR ST
043632 : 140660 IRR 10 DX
043633 : 146157 COPY SA DX
043634 : 051034 LDT I * 34
043635 : 140660 EXR ST
043635 : 140660 IRR 10 DT
043636 : 146154 COPY SA DL
043637 : 051032 LDT I * 32
043640 : 140660 EXR ST
043640 : 140660 IRR 10 DD
043641 : 146151 COPY SA DD
043642 : 051030 LDT I * 30
043643 : 140660 EXR ST
043643 : 140660 IRR 10 DA
043644 : 146146 COPY SL DT
043645 : 124036 JMP * 36
043703 : 004372 STA * - 6
</pre>
:It does a bunch of register comparisions and doesn't bail out, which kind of indicates it's not complaining about P in this case. Could it be another problem? I used to see P complaints until I got MOVBF working correctly in my emulator. As far as I can tell it shall work as described in ND–06.014.02 and not as in ND–06.029 (see footnote in [[MOVBF]]), i.e. both D and T decrements with the number of bytes moved and should in the example you provide both be 0 at the end. -- [[User:TArntsen|TArntsen]] 20:40, 28 May 2011 (CEST)
:: Haven't really traced that part, but it is called with 2 different parameter settings(debug output from my movbf routine):
<pre>
MOVBF(pre): gA:056122 gD:007776 gX:056121 gT:007776 gPC:043646 len:0
MOVBF(pre): distance=-2 overlap=1
MOVBF(post): gA:056122 gD:007776 gX:056121 gT:007776 gPC:043647 len:0
MOVBF(pre): gA:056121 gD:007776 gX:062121 gT:007776 gPC:043646 len:4094
MOVBF(pre): distance=4096 overlap=0
MOVBF(post): gA:062120 gD:000000 gX:066120 gT:000000 gPC:043650 len:4094
</pre>
::Interestingly enough, when I was fiddling around with this before I managed to sabotage A, and it caught that error spot on. So A is expected to be 62120 but still not be a skip return??
<pre>
*** ERROR ***  ILLEGAL OVERLAP IN MOVBF GAVE SKIP RETURN
</pre>
:: Might take a break from this one for a short while... [[User:Roger|Roger]] 09:10, 29 May 2011 (CEST)
::: Same here.. and keep in mind that my emulator isn't entirely trustworthy as ref. for how these instructions work, it's really a user-level emulator and I'm only faking the memory management necessary for running these multi-level standalone test programs. I'll puase my work on this and concentrate on adding the last remaining instructions to my disassembler so that I can release that component at least. -- [[User:TArntsen|TArntsen]] 17:55, 29 May 2011 (CEST)
:::: I'm writing a little user-level test program for MOVBF. In MAC.Quite simple, really. It can be run on a real ND-100 for testing (and in an emulator). Not finished yet, needs some free hours. Oh boy I need to implement support for mode files in my emulator.. using MAC interactively is a pain, even with file input. --[[User:TArntsen|TArntsen]] 13:26, 30 May 2011 (CEST)
=== ND100 floating point ===
=== ND100 floating point ===
Seems to have run into some inconsistencies here. Not sure if I am doing things wrong here, or the ND100 microcode. Adding the two floating point numbers:
Issue is solved in FAD, FDV has not been fixed, probably need to do long division myself to catch the loss of accuracy and thus setting of lsb.
* 040006 100000 000000
Note that ND-100 does this before final shifting adjustment if you get a carry, thus wiping it.
* 040001 100000 000001
seems to be expected to return the result:
*040006 102000 000001
But as far as I can tell that gives a mantissa of roughly 0.5156250002328306437 whereas the 80bit floating point routines of extended precision
on my host platform gives a mantissa of 0.5156250000072759576, so nd100em routine now gives
*040006 102000 000000
As far as I can tell this means emulator is more correct than real ND100 but... [[User:Roger|Roger]] 10:09, 11 June 2011 (CEST)
:I'm no floating point expert, but here's what I have. If I use my simplistic soft-float function it agrees with your result (040006 102000 000000). What I'm doing tthere is just to:
  * Shift the second mantissa by 5 bits (the difference between the exponents)
  * Add the result to the first mantissa
  * Use the largest exponent.
:That will obviously give 040006 102000 000000 (because the last 1 gets shifted outside the 32-bit mantissa size). But what they're doing here is probably testing a corner case. The first value is 32.0 (2^<sup><small>(16390-16384)</small></sup>*0.5) and the second is 1.0 + the last bit in the mantissa set, which calculates to approx. 1.0000000005 with the highest possible resolution of the 48-bit floating point format, which is 5 or no 5 in decimal digit 10 (this may be the rounding case discussed in {{ND-doc|05.009.03|page 74}}, although it talks only about the 32- and 64-bit formats used in the 500). So, the answer should have been approx. 33.0000000005 which is higher than 33.0 but can't be represented in the ND format, so instead the last bit is set to 1 (which gives 33.0000000149) which is too high but the only possibility if you want to be > 33.0). --[[User:TArntsen|TArntsen]] 21:39, 12 June 2011 (CEST)


I just found this on the ND-12 page....
I just found this on the ND-12 page....
Line 166: Line 68:
== Mailinglist down again ==
== Mailinglist down again ==


Ok, it looks like the mailinglist is down again. Unfortunately I don't have an alternate email address for Roger. --[[User:Tingo|Torfinn]] 08:49, 14 February 2012 (CET)
Will try and get sorted sometime in the next week and sit down and fix mailinglist IF there is any interest in its revival.
:I'll tell him to contact you. /[[User:Mike|Mike]] 09:17, 14 February 2012 (CET)
: Is the mailinglist working now? I don't get any error messages when posting to it (but I don't get any replies to my messages either...) --[[User:Tingo|Torfinn]] ([[User talk:Tingo|talk]]) 20:06, 20 September 2016 (UTC)
:Noted, will try and fix this weekend, need to reinstall the software for it. [[User:Roger|Roger]] 14:19, 17 February 2012 (CET)
: Still down, poke me in a week or so if I haven't fixed it by then... It's been on my low prio list.... [[User:Roger|Roger]] ([[User talk:Roger|talk]]) 03:31, 21 September 2016 (UTC)
:Should work now.. [[User:Roger|Roger]] 15:12, 17 February 2012 (CET)
 
::Confirmed - it works now. Thanks! -- [[User:Tingo|Torfinn]] 15:25, 17 February 2012 (CET)
== {{done}}INSTRUCTION-C ==
 
In case it is still needed, INSTRUCTION-C (INSTRUCTION-C03:TEST) is available on the image of the first floppy in [[ND-210523G]]. If ':TEST' is a new file format (as opposed to a renamed ':BPUN') I don't know anything about it. --[[User:Tingo|Torfinn]] ([[User talk:Tingo|talk]]) 18:47, 26 July 2016 (UTC)
 
Yes I have just  written a program that reads out files from the dd images, so I can testrun bpun files etc. Just started looking through the floppy images to see what I can use. /[[User:Roger|Roger]] ([[User talk:Roger|talk]]) 11:20, 27 July 2016 (UTC)


A couple of years later, and the mailing list is down again. --[[User:Tingo|Torfinn]] ([[User talk:Tingo|talk]]) 18:18, 15 April 2014 (CEST)
== "floppy.h" missing? ==
:I'll tell him this time, I think he had some problems with the server a couple of days ago. At least he had some problems with '''a mail server'''. --[[User:Gandalf|Gandalf]] ([[User talk:Gandalf|talk]]) 21:17, 17 April 2014 (CEST)
: Yes, the server who hosts it is now virtual, but managed to corrupt it's virtual hdd a couple of days ago. I have a backup, but it will be 2-3 days or so until I can get it up and running again. --[[User:Roger|Roger]] 06:15, 18 April 2014‎ {CEST}


== INSTRUCTION-C ==
It looks like a file "floppy.h" is missing from the tarballs (v0.2.2, v0.2.3 and v0.2.4) and the repository. Or am I wrong? v0.2.4 compiles if I comment it out in floppy.c --[[User:Tingo|Torfinn]] ([[User talk:Tingo|talk]]) 20:09, 20 September 2016 (UTC)


In case it is still needed, INSTRUCTION-C (INSTRUCTION-C03:TEST) is available on the image of the first floppy in [[ND-210523G]]. If ':TEST' is a new file format (as opposed to a renamed ':BPUN') I don't know anything about it. --[[User:Tingo|Torfinn]] ([[User talk:Tingo|talk]]) 18:47, 26 July 2016 (UTC)
Yes, just noted now when I downloaded the tarball separately and compiled. Missed to add that one to git, so it slipped through. Will be working on the emulator again later this week, so will try and get a new tarball up by the weekend. [[User:Roger|Roger]] ([[User talk:Roger|talk]]) 03:27, 21 September 2016 (UTC)
 
== git repository unavailable ==
 
The git repository is unavailable now. It looks like the domain expired. --[[User:Tingo|Torfinn]] ([[User talk:Tingo|talk]]) 07:32, 18 October 2016 (UTC)
: I put a copy of the last release (0.2.4) up on Github https://github.com/tingox/nd100em  At least then the code is available. --[[User:Tingo|Torfinn]] ([[User talk:Tingo|talk]]) 19:29, 27 February 2018 (UTC)

Latest revision as of 19:53, 10 October 2023

Current status

  • Unfortunately, there hasn't been any activity here (or on the dead mailing list) since Roger's post in 2016. Torfinn (talk) 19:53, 10 October 2023 (UTC)
  • Revived, and active. /Roger (talk) 20:52, 29 July 2016 (UTC)
  • Possibly thinking of putting it on github or somewhere public with issue tracker functionality etc. Will look into it.
  • ATM working on floppy code, trying to get that to pass tests, once that is done floppy boot. Roger (talk) 23:22, 12 August 2016 (UTC)

Archived old version of talk page to remove clutter, mostly about stuff that is already solved or irrelevant at the moment.

Re. Known Bugs

Do you have any more info on the undocumented instructions?? I seem to have hit an undocumented IOX as well (IOX 3). Roger 07:29, 2 May 2011 (AWST)

No success yet with the undocumented instructions. I tried to run 142700 through the disassembler in BRF-LINKER and BRF-EDITOR, but they didn't know it (I used that method successfully to get on the right track for the undocumented IOT, for example). Did you hit IOX 3 in the test program? Devices below 4 are the only ones which shouldn't ever exist, so maybe that IOX 3 is a test by iteself, to trigger an IOX error interrupt on level 14? -- TArntsen 09:10, 2 May 2011 (CEST)
Found it through running CONFIGURATIO-C08, it seems there is something called a Rack Controller. No more details yet though. -- Roger 01:10, 9 May 2011 (AWST)

Well, its tested very early, as the first try with 142700. I have implemented both Illegal instruction and IOX error, so that is not a problem, but the way it's called very early in the test program sort of hints that it's checking if somethings available. I was also thinking of either things on NORD1/NORD10 or ND120.


Update: 142700 instruction:. 142700 is the GECO instruction! GECO, Geophysical Company of Norway (now it's been through a couple of mergers and is called something else) used to have lots of Norsk Data hardware for seismic processing. They also had ND computers on board (several friends and acquaintances of mine (including a former ND tech) used to work on those ships). They acquired a permanently assigned user-specified instruction. INSTRUCTION-B simply tests for its existence by doing a TRA IIC, then checks for value 4 which means 'illegal instruction'. I had forgotten about it, there's a writeup somewhere about the GECO instruction story but I don't have the reference handy. However, from what I can figure out from SINTRAN it looks like the instruction is part of the 'standard' CPU instruction set after some point, so checking for GECO is part of the code which tries to deduce exactly which CPU this is. The sequence (in SINTRAN) goes something like this:
Check if 32-bit or 48-bit floating point (standard NLZ trick mentioned in docu) 
Check if NORD-10 or ND-100 (there's a bit for that)
(Now it tries to deduce if the commercial (CE) instruction set is there):
Here it does some trick with BFILL which I haven't figured out yet. NB: It _could_ affect the below.
 (Found it: BFILL simply installs a short level 14 illegal instruction catch handler.)
Then it checks for GECO.
  If GECO is not found, it skips the rest!
Else
  Check for 16 PITS (the alternative is 4 PITS, more common in older systems)
  Check if VERSN exists, if yes then it's at least an ND-110
  If yes, use VERSN to figure out if it's an ND-120
Endif
(This is where we end if no GECO).
Check if there's an ND-500.
Well, there may be more to come if I find out more. -- TArntsen 01:09, 15 May 2011 (CEST)
I love this GECO-story! I think it would fit well as a Main Page Did you know... /Mike 01:57, 16 May 2011 (CEST)


Re. Wanted Information

INSTRUCTION-B has a BCD test but it seems to be a dummy. I haven't implemented BCD tests in my emulator so it shouldn't have passed everything, but it does. And executing the BCD test individually just spits out 'BINARY CODED DECIMAL (ADDD...) (NIY) == END OF TEST ==' (plus levels) as with RUN. -- TArntsen 19:02, 14 May 2011 (CEST)

Actually - scratch that. My emulator is in NORD-10 mode when it runs that BCD test, so it makes sense that INSTRUCTION-B handles it as dummy there at least. So, is it dummy also for ND-100/CE ? -- TArntsen 12:28, 15 May 2011 (CEST)
Update: INSTRUCTION-B seems to use GECO (142700) to test for CPU version just like SINTRAN, so without the instruction it won't even try CX operations like CLEPT, or, presumably, CE instructions (my emulator doesn't have enough of these to be completely sure, but that's what it looks like). So, to conclude, implement a dummy 142700 (just increment P, fetch new instruction, no IIC update, and it'll pass through) and INSTRUCTION-B may start working through the CE/BCD tests. -- TArntsen 10:52, 16 May 2011 (CEST)

INSTRUCTION-B detects nd100em as ND100/CX with MMS I, and runs through some of the CE tests, like stack (INIT,ENTR,LEAVE,ELEAV). There seems to be something listed in the long documentation inside INSTRUCTION-B thats called ND100S4, and might be the GECO one. Will put in a stub for it anyway, and play around. Anyway, this is what nd100em is detected as currently, it is set as configurable though, although not quite handled that way fully yet.

COMPUTER: ND-100/CX  48 BIT FLOATING FORMAT WITH FAST CYCLE.
ALD     : 0
PAGING  : MEMORY MANAGEMENT I
CACHE   :  NO

ND100 floating point

Issue is solved in FAD, FDV has not been fixed, probably need to do long division myself to catch the loss of accuracy and thus setting of lsb. Note that ND-100 does this before final shifting adjustment if you get a carry, thus wiping it.

I just found this on the ND-12 page....

The rounding algorithm for floating point differs between NORD-10 and NORD-12. On NORD-12 there is no TG (Rounding) flip-flop in the Status Register (bit 1 in Status on NORD-1), and for NORD-12 all floating point results are truncated. On the NORD-10 the least significant bit in the result is forced to one if the result could not be exactly represented. For both the NORD-10 and NORD-12 all integers up to 232-1 will be exactly represented in floating point format, and all results to this limit will also be exact.
I wonder if this is the issue, I will be checking it as soon as I get back coding.... Roger (talk) 13:40, 15 July 2016 (UTC)
I also noticed that when I read the document some time ago, and yes I think that's exactly it. The rounding to 1 we discussed is, as far as I can see, perfectly explained by the "..forced to one if the result could not be exactly represented" mechanism. -- TArntsen (talk) 12:47, 17 July 2016 (UTC)

Mailinglist down again

Will try and get sorted sometime in the next week and sit down and fix mailinglist IF there is any interest in its revival.

Is the mailinglist working now? I don't get any error messages when posting to it (but I don't get any replies to my messages either...) --Torfinn (talk) 20:06, 20 September 2016 (UTC)
Still down, poke me in a week or so if I haven't fixed it by then... It's been on my low prio list.... Roger (talk) 03:31, 21 September 2016 (UTC)

DoneDoneINSTRUCTION-C

In case it is still needed, INSTRUCTION-C (INSTRUCTION-C03:TEST) is available on the image of the first floppy in ND-210523G. If ':TEST' is a new file format (as opposed to a renamed ':BPUN') I don't know anything about it. --Torfinn (talk) 18:47, 26 July 2016 (UTC)

Yes I have just written a program that reads out files from the dd images, so I can testrun bpun files etc. Just started looking through the floppy images to see what I can use. /Roger (talk) 11:20, 27 July 2016 (UTC)

"floppy.h" missing?

It looks like a file "floppy.h" is missing from the tarballs (v0.2.2, v0.2.3 and v0.2.4) and the repository. Or am I wrong? v0.2.4 compiles if I comment it out in floppy.c --Torfinn (talk) 20:09, 20 September 2016 (UTC)

Yes, just noted now when I downloaded the tarball separately and compiled. Missed to add that one to git, so it slipped through. Will be working on the emulator again later this week, so will try and get a new tarball up by the weekend. Roger (talk) 03:27, 21 September 2016 (UTC)

git repository unavailable

The git repository is unavailable now. It looks like the domain expired. --Torfinn (talk) 07:32, 18 October 2016 (UTC)

I put a copy of the last release (0.2.4) up on Github https://github.com/tingox/nd100em At least then the code is available. --Torfinn (talk) 19:29, 27 February 2018 (UTC)