Talk:ND100 emulator project

Progress? Has this project stopped? Or is there progress somewhere? Torfinn 16:00, 25 October 2010 (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? Torfinn 19:36, 13 April 2011 (CEST)

Mailinglist will be resurrected sometime during the next few weeks, also links to updated code will be fixed. The latest git code has some more bugfixes, so now almost runs INSTRUCTION-B testprogram. Roger 17:29, 24 April 2011 (AWST)

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

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. -- Roger 18:05, 2 May 2011 (AWST)

Great! Good work!  :) /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:

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

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. -- Roger 18:30, 8 May 2011 (AWST)

Re. Wanted Information

I see "PROG file format" still listed as wanted information.. the format is documented 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).
As for test programs, there should be something newer. 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.
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

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? 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:

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

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

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

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

*** ERROR ***  ILLEGAL OVERLAP IN MOVBF GAVE SKIP RETURN

Might take a break from this one for a short while... 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. -- 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. --TArntsen 13:26, 30 May 2011 (CEST)

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:

• 040006 100000 000000
• 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... 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^^{(16390-16384)}*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 Norsk Data Document ND–05.009.03 NORD-500 REFERENCE MANUAL 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). --TArntsen 21:39, 12 June 2011 (CEST)

Mailinglist down again

Ok, it looks like the mailinglist is down again. Unfortunately I don't have an alternate email address for Roger. --Torfinn 08:49, 14 February 2012 (CET)