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.

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)