Get KL ITS running.

[larsbrinkhoff]

Insert mad ramblings about running ITS on @rcornwell's upcoming KL10 simulator. Until it's available, I'll test things on a KA10.

There is some info here: #744

[larsbrinkhoff]

LISTF and CHKR works fine now, when started from DDT.

I tried loading ITS and start it from the GO entry point:

$L KL ITS

GO$G'
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=1 p=0 rgr 
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=0 p=0 rgw prev 
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=1 p=0 rgr 
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=0 p=0 rgw prev 
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=1 p=0 rgr 
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=0 p=0 rgw prev 
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=1 p=0 rgr 
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=0 p=0 rgw prev 
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=1 p=0 rgr 
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=0 p=0 rgw prev 
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=1 p=0 rgr 
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=0 p=0 rgw prev 
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=1 p=0 rgr 
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=0 p=0 rgw prev 
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=1 p=0 rgr 
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=0 p=0 rgw prev 
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=1 p=0 rgr 
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=0 p=0 rgw prev 
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=1 p=0 rgr 
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=0 p=0 rgw prev 
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=1 p=0 rgr 
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=0 p=0 rgw prev 
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=1 p=0 rgr 
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=0 p=0 rgw prev 
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=1 p=0 rgr 
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=0 p=0 rgw prev 
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=1 p=0 rgr 
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=0 p=0 rgw prev 
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=1 p=0 rgr 
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=0 p=0 rgw prev 
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=1 p=0 rgr 
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=0 p=0 rgw prev 
Page fault 172132 a=1 wr=0 w=1 000000
Page fault 172133 001000172132 300000
Page fault 170503 a=1 wr=0 w=1 000000
Page fault 170504 001000170503 1700040

[larsbrinkhoff]

It's the XCTR XBW,[BLT T,17] at GO+14 that is responsible for the PXCT messages. It's the last line here:

        CONSO PAG,600000
         SWPIA                  ;IF CACHE OFF, FLUSH CRUFT THAT MAY BE IN IT
        CONSZ PAG,600000
         SWPUA                  ;IF CACHE ON, UPDATE CORE SO DDT IS GOOD
        CONSZ 200000
         JRST .-1
        SPCCTX 0,1,USRSTG,DISABLE       ;SET UP UPT ADDR, BUT NO ACCTING TILL
        MOVEI T,0                       ;MORE INIT IS DONE.
        XCTR XBW,[BLT T,17]             ;CLEAR BLK 1 TO AVOID RANDOM PARITY
                                        ; ERRORS

[larsbrinkhoff]

Note that a KL10 XCTR is not quite the same as the KA10 XCTR.

IFN KA10P,[
XCTR=103000,,   ;EXECUTE INSTRUCTION WITH MAPPING CONTROLLED BY AC FIELD
                ;VIOLATION CAUSES USER MEM PROTECT INTERRUPT UNLESS INHIBITED
                ;VIOLATION ALSO SKIPS BUT THIS IS OF NO CONSEQUENCE UNLESS
                ;INTERRUPT IS INHIBITED SINCE PC WILL BE RESET FROM OPC
XCTRI= XCTR 4,  ;XCTR WITH PAGE FAULT INHIBITED (SKIPS ON FAULT)
                ; AC FIELD VALUES FOR XCTR AND XCTRI
        XR==1   ;MAP READ MAIN OPERAND OF SIMPLE INSTRUCTION (MOVE, SKIPL, HLL)
        XW==2   ;MAP WRITE MAIN OPERAND OF SIMPLE INSTRUCTION (MOVEM)
        XRW==3  ;MAP READ/WRITE OPERAND OF SIMPLE INSTRUCTION (E.G. IORM)
        XBYTE==3;MAP BYTE DATA AND BYTE POINTER (ILDB, IDPB)
        XBR==1  ;MAP BLT READ
        XBW==2  ;MAP BLT WRITE
        XBRW==3 ;MAP BOTH OPERANDS OF BLT
                ;KA10 PAGING BOX GOES BY WHETHER IT'S A READ OR WRITE (OR RW) CYCLE
                ;KL10 PAGING BOX WORKS DIFFERENTLY (SEE BELOW)
                ;DO NOT USE MULTI-OPERAND INSTRUCTIONS (DMOVE, PUSH, ETC.) WITH XCTR

IFN KL10P,[
XCTR=074000,,   ;EXECUTE INSTRUCTION WITH MAPPING, PAGE FAILS ENABLED
XCTRI=075000,,  ;SAME BUT SKIPS IF THERE IS PAGE FAIL (DONE SNEAKILY BY SOFTWARE)
                ;AC FIELD VALUES FOR XCTR AND XCTRI
        XR==4   ;MAP MAIN OPERAND OF SIMPLE INSTRUCTION (FOR READING)
        XW==4   ;MAP MAIN OPERAND OF SIMPLE INSTRUCTION (FOR WRITING)
        XRW==4  ;MAP MAIN OPERAND OF SIMPLE INSTRUCTION (FOR READING AND WRITING)
        XBYTE==5;MAP BYTE DATA AND BYTE POINTER
        XBR==1  ;MAP BLT SOURCE
        XBW==4  ;MAP BLT DESTINATION
        XBRW==5 ;MAP BOTH BLT OPERANDS
        XEA==16 ;MAP EFFECTIVE ADDRESS COMPUTATION
                ;IN KL10 BITS ARE:  14 INDIRECT WORDS
                ;                   10 XR UNDER SOME RANDOM WIERD CONDITIONS (?)
                ;                    4 MAIN OPERAND "  "  " ALSO BYTE WRITE
                ;                    2 INDEX REGISTER, @ AND XR IN BYTE PTRS
                ;                    1 2ND OPND - BLT SOURCE, BYTE READ, STACK DATA

[rcornwell]

The bits are the same as the KL10, they made no change. The pxct messages are debugging messages.

[larsbrinkhoff]

KL10 page table entries:

DEFSYM PMRCM==7777      ;12 BIT REAL CORE ADDR
DEFSYM PMCSHM==10000    ;CACHE ENABLE BIT
DEFSYM PMAGEM==160000   ;3 BIT AGE
DEFSYM PMUNSD==0        ;NO UNUSED BITS

[eswenson1]

Lars, might be good to comment out the PXCT and Page fault messages (or redirect to stderr) and then do some SIMH breaks and stepping to see where ITS hangs. Kiteguy said there is nothing necessarily wrong with all those page fault messages. So rather than spending time looking at page faults, better to see what ITS is doing when it hangs.

By the way, I did redirect those messages, and ITS hung. I think it was in some UUO handler when I interrupted it to get to SIMH command level.

[larsbrinkhoff]

I don't know if this makes sense. When I run ITS, I get to a 0 at 170503 (in my particular binary). When I set a breakpoint there and print out the instruction history, I get this:

172114  000000000376  000377    000000000377  777777777777   300000  305200000377  CAIGE 4,377
172115  000000000376  172105    000000000376  000000000377   300000  344200172105  AOJA 4,172105
172105  000000610376  000001    000000000001  002200170177   300000  134700000001  ILDB 16,1
172105  000000610376  170177    000000170177  000000610377   320000  
172106  000000777777  777777    000000777777  000000777777   300000  201240777777  MOVEI 5,777777
172107  000000610377  172113    000000610377  000000610377   300000  326700172113  JUMPN 16,172113
172113  000000777777  000002    000000000002  002200170377   300000  136240000002  IDPB 5,2
172113  000000777777  170377    000000170377  777777777777   320000  
172114  000000000377  000377    000000000377  000000000000   300000  305200000377  CAIGE 4,377
172116  000000000377  327740    000000327740  000000327740   300000  700200327740  CONO APR,327740
172117  000000000000  000001    000000000001  420764002001   300000  700000000001  BLKI APR,1
172120  420764002001  020000    000000020000  020000000000   300000  607040020000  TLNN 1,20000
172122  000000610401  172711    000000172711  606600400000   300000  701140172711  DATAO PAG,172711
172123  000000000000  170100    000000170100  000000170100   300006  201140170100  MOVEI 3,170100
172124  000000000000  170000    000000170000  000000170000   300006  201200170000  MOVEI 4,170000
172125  000000000000  160000    000000160000  160000000000   300006  205240160000  MOVSI 5,160000
172126  000000000000  160000    000000160000  000000160000   300006  201300160000  MOVEI 6,160000
172127  000000000000  001000    000000001000  000000001000   300006  201340001000  MOVEI 7,1000
172130  000000000000  000100    000000000100  000000000100   300006  201400000100  MOVEI 10,100
172131  000000170000  660001    000000660001  000000660001   300006  701200660001  CONO PAG,660001

Is there a way CONO PAG, can cause a jump to 170503?

[larsbrinkhoff]

The corresponding place in ITS sources:

;SET UP SYS JOB'S CIRCULAR POINTERS SO ALL THE PAGES IT HAS ARE ABSOLUTE

        MOVE A,[442200,,UPGMP]
        MOVE B,[442200,,UPGCP]
        MOVEI D,0
BEG6:   ILDB T,A
        MOVEI E,-1
        JUMPN T,BEG7
        CAIL D,200+MMP0 ;ALLOW USERS TO COPY MMP EXEC PGS
         CAILE D,200+NEXPGS
          MOVEI E,0     ;PG IT DOESN'T HAVE, AND NOT COPYABLE EXEC PG
BEG7:   IDPB E,B
        CAIGE D,377
         AOJA D,BEG6

;EXEC MAP PREPARED, NOW TURN ON PAGING

IFN KL10P,[
        CONO 327740     ;ENABLE AND CLEAR ALL FLAGS EXCEPT SWEEP DONE
        APRID A
        TLNN A,%UCITS
         BUG AWFUL,[ITS WON'T RUN WITH THE DEC MICROCODE]
        SPCCTX 6,6      ;LOAD MICROCODE CONSTANTS NEEDED BY PAGEING INTO
                        ; BLOCK 6.
        MOVEI 3,EXEUMP  ;DBR3
        MOVEI 4,EXELMP  ;DBR4
        MOVSI 5,PMAGEM  ;LH.AGE
        MOVEI 6,PMAGEM  ;RH.AGE
        MOVEI 7,1000    ;CN1000
        MOVEI 10,100    ;CN100
        CONO PAG,660000+<EPT/1000>      ;CACHE ON, ITS PAGER, TRAP ENB, EPT ADDR

[larsbrinkhoff]

So what we're seeing here is ITS setting up some page table data. Then it installs some paging data in the accumulator context 6. Finally it turns on paging, and bam.

[larsbrinkhoff]

SIMH stepping says it goes one more instruction:

$L KL ITS

BEG7+16/   CONO PAG,660001   .=172131   
Simulation stopped, PC: 773536 (JRST 0,773535)
sim> break 172131
sim> c
GO$G
Breakpoint, PC: 172131 (CONO PAG,660001)
sim> s
Step expired, PC: 172132 (DATAO PAG,172712)
sim> s
Step expired, PC: 170503 (LUUO00 0,0)
sim> 

[larsbrinkhoff]

The DATAO PAG, is this:

SPCCTX 1,1,USRSTG,DISABLE

And USRSTG is this:

USRSTG:: KLUPT 0,;USER PAGE MAP

@rcornwell, is this enough for you to make progress?

[rcornwell]

It looks like the page table for executive space lower DBR0 is not set up correctly. What might be wrong is that I have the location of DBR0 and DBR1 wrong.

[larsbrinkhoff]

I think the layout of SPM/LDM data is encoded at the UPGML label in ITS. According to this, KL10 would have it be these five words in this order:

                UPJPC:  0       ;JPC.  KA HAS FAULT ADDRESS IN LH.
                UPMAR:  0,,0    ;MAR ADDRESS AND CONDITION
IFN KL10P,      UPFW:   0                       ;PAGE FAIL WORD
                UPDBR1: DBL,,UPGMP              ;DBR1
                UPDBR2: DBL,,UPGMP+100          ;DBR2

I'm using the ITS terminology here, which says DBR1-4 rather than using base 0. So I think these are your DBR0 and DBR1.

Also note the precense of a page fail word here which doesn't exist in the KA10 version.

[rcornwell]

I don't see DBR3 and DBR4... was the monitor unpaged?

[larsbrinkhoff]

I think DBR3 and 4 were loaded by storing directly into AC3 and 4 in context 6. See code snippet above, below BEG7.

[larsbrinkhoff]

ITS is paged, but most of it is identify mapped. There are some pages for 10-11 mapping etc.

[larsbrinkhoff]

Note the funny order:

DBR1    DBR FOR USER LOW HALF
DBR2    DBR FOR USER HIGH HALF
DBR3    DBR FOR EXEC HIGH HALF
DBR4    DBR FOR EXEC LOW HALF

[larsbrinkhoff]

The microcode seems to map DBR1-4 to FM#/141-144.

[larsbrinkhoff]

Looking at the latest update. Maybe this should be dbr4 : dbr3 instead. Because https://github.com/PDP-10/its/issues/1632#issuecomment-529129094

-        dbr = (uf)?
-                     ((page & 0400)?FM[(06<<4)|4]:FM[(06<<4)|3]) :
-                     ((page & 0400)?FM[(06<<4)|2]:FM[(06<<4)|1]);
+        dbr = (uf)? ((page & 0400) ? dbr1 : dbr2) :
+                    ((page & 0400) ? dbr3 : dbr4) ;

[rcornwell]

Page & 0400 selects High Seg vs Low seg. DBR3 is Exec High and DBR4 is Exec Low. DBR1 is User Low and DBR2 is User High.

[larsbrinkhoff]

Right... but then shouldn't it be dbr2 : dbr1?

[rcornwell]

Your right... can try that.

[larsbrinkhoff]

I get the same crash with both my own and @eswenson1's ITS and the latest pdp10-kl. Here's exactly how I start ITS. As you can see, I bypass SALV by starting from GO. However, I get to the same point by loading both ITS KLBIN and SALV KLBIN together and starting with $G.

$L ITS KLBIN

GO$G'

Simulation stopped, PC: 170503 (LUUO00 0,0)

[eswenson1]

Why are you bypassing SALV? I mean, why bother? SALV runs fine, so why exclude it?

[larsbrinkhoff]

It's kind of a habit since some binaries doesn't have SALV built in. ITS KLBIN doesn't, and I didn't see a file that seemed to have it.

[eswenson1]

Ok. With @rcornwell's latest, I have slightly different behavior in my ITS. And I believe that behavior corresponds to what @rcornwell said he was seeing. ITS stops on a halt:

KL-10A simulator V4.0-0 Current        git commit id: 3553ba52

$L ITS KLBIN

$$L  SALV KLBIN

$G
SALVAGER.319

PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=1 p=0 rgr
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=0 p=0 rgw prev
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=1 p=0 rgr
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=0 p=0 rgw prev
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=1 p=0 rgr
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=0 p=0 rgw prev
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=1 p=0 rgr
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=0 p=0 rgw prev
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=1 p=0 rgr
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=0 p=0 rgw prev
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=1 p=0 rgr
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=0 p=0 rgw prev
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=1 p=0 rgr
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=0 p=0 rgw prev
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=1 p=0 rgr
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=0 p=0 rgw prev
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=1 p=0 rgr
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=0 p=0 rgw prev
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=1 p=0 rgr
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=0 p=0 rgw prev
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=1 p=0 rgr
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=0 p=0 rgw prev
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=1 p=0 rgr
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=0 p=0 rgw prev
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=1 p=0 rgr
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=0 p=0 rgw prev
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=1 p=0 rgr
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=0 p=0 rgw prev
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=1 p=0 rgr
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=0 p=0 rgw prev
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=1 p=0 rgr
PXCT ir=251 pc=172016 ad=000000 x=04 c=0 b=0 p=0 rgw prev

HALT instruction, PC: 125611 (HALT 125611)
sim> q
Goodbye

This version includes a fix to the DBR3/4 swap.

[larsbrinkhoff]

I think I recognize that halt address. So I wonder why I don't see it?

[eswenson1]

It corresponds to:

125606  261640 000002   CIMEMR: PUSH P,B    ;ENTER HERE IF OK TO HACK WITH MEM FROZEN
125607  135100 154200       LDB B,[MUR,,MEMBLT(A)]  ;I E CALLING FROM CORE ALLOCATOR
125610  306100 000004       CAIN B,MUFR
125611  254200 125611        JRST 4,.   ;ALREADY FREE, LOSSAGE

[eswenson1]

The error you are seeing -- the "Simulation stopped, PC: 170503 (LUUO00 0,0)" was what I was seeing before the DBR3/4 swap (user high/low) fix. As far as I remember, all I did was pull the latest pdp10-kl sources and rebuild clean. Now I get the mem-free-already-free halt.

[larsbrinkhoff]

Thanks, I see it now. I must have compiled the simulator in the wrong directory, or typed make pdp10-ka, or something.

[larsbrinkhoff]

Our latest HALT is in CIMEMR. CIMEMR is called from the loop at BEGF0:

        MOVEI A,1       ;A PG NO - NOTE: DON'T DO PAGE ZERO
BEGF0:  CAML A,FTUTPG   ;IF THIS ISN'T A DDT OR TUT PAGE, THEN
        CAIL A,400
         PUSHJ P,CIMEMR ;PUT THIS PAGE ON THE RIGHT FREE LIST
        CAIGE A,TSYSM-1
         AOJA A,BEGF0

I put a breakpoint at the first MOVEI:

Breakpoint, PC: 172135 (MOVEI 1,1)
sim> ex 1
1:      420764002001
sim> s

Step expired, PC: 172136 (CAML 1,172612)
sim> ex 1
1:      420764002001

What's this, am I not getting the contents of accumulator 1 here?

[eswenson1]

I'm glad you brought this up. I was seeing the same thing -- "ex 1" was definitely not showing me the contents of register 1. I thought I was going crazy.

[rcornwell]

Current patch is getting closer. Let me know where it is getting stuck.

[eswenson1]

I see the SYS and CORE jobs running, as well as the NULL job. When I interrupt the system, I always seem to end up in the NULL job — which makes sense.

Next thing to do is find the SYS job in memory and put breakpoints in it to find out why it is not writing to the console. And control z on the console does some page I/o, but doesn’t create a new job and load a HACTRN.

Should put a breakpoint there too and see whether we get an interrupt when control-z is typed.

[larsbrinkhoff]

We have MX set PDCLKP=1. So according to this, ITS is expecting interrupts from the PD clock, and not the FE. However, my PD clock device doesn't implement the interrupt anyway, because it wasn't there on the KA10 board.

So... I think the quickest solution is to make an ITS with PDCLKP=0. I will also want to add the clock interrupt to the PD device.

IFN KL10P,[
IFN PDCLKP, CONO CLK,APRCHN
.ELSE [ MOVEI A,%DTCLN  ;TURN ON 60-CYCLE CLOCK
        MOVEM A,DTECMD
        SETZM DTEFLG
        CONO DTE,%DBL11
        SKIPN DTEFLG
         JRST .-1
]

[larsbrinkhoff]

Eric and I reassembled MX ITS with PDCLKP=0. CLKBRK will now be called exactly four times, and then no more.

[rcornwell]

I added IRQ to PD device, it is halting while trying to extract performance data which I have not yet implemented. Actually getting IDIVI error and halting.

[larsbrinkhoff]

Latest news is that some hard-won bug fixes later, @rcornwell can now get to HACTRN.

[larsbrinkhoff]

I'll jot down some notes from IRC conversations.

• We want to build an MC system image for the real MC. But this is a long-term goal since the hardware will need a lot of TLC. -> @SMJ

• We'll use the name KL for a new KL10 configuration. It will be adapted to available emulated hardware: 4M memory, CH10 Chaosnet, no DL10, no T300s, R06 disks, AAA terminals. Etc, as we see fit.

[eswenson1]

Now that the ejs/pdp10-kl-build branch is building a usable KL ITS, we have a few cleanup items to do:

• [x] Remove expect hack to get around pdp10-kl's not echoing correctly (fixed in pdp10-kl now) -- in progress now by eswenson
• [x] Switch from using MX ITS (built on pdp10-ka system) to bootstrap to using KL ITS from a previous build -- in progress now by eswenson
• [x] Switch from using SALV and DDT built on pdp10-ka to ones built on pdp10-kl. -- in progress now by eswenson
• [x] Debug issues with DDT ^N (one-proceed)
• [x] Debug issues with ^C not working in DECUUO programs (e.g. MACRO)
• [x] Debug issues with MAINT not building and running tests on KL
• [ ] Get chaosnet working on pdp10-kl
• [ ] Debug issue with intermittent MUUO IN EXEC MODE, caused by bashing user context. Maybe the MOVEM T,CLCXSV near label SCHDN2. Or possibly the BLT T,UEXND-1 5 instructions before CLKB5.
• [ ] Figure out why Exec DDT can't do a ^F

@larsbrinkhoff adds: Some items for future consideration:

• [ ] Expand the "KL" configuration to the maximum 4096K words of memory.
• [ ] Use RP06 rather than RP04.

[eswenson1]

I updated my branch to get rid of the tcl/respond workaround for pdp10-kl echoing issue (no longer needed). I also update the bootstrap ITS, SALV, and DDT to use those built by the KL build, so these are no longer from a pdp10-ka build of the "fake" KL.

@larsbrinkhoff Can you update the tools/sims submodule in this branch to point to the current HEAD of the kl10 branch of rcornwell's repo? I don't don't know how to do that correctly.

[eswenson1]

We can't merge this branch to master yet because of the ^C issue and the commented out MAINT build -- we could choose to conditionalize all this based on pdp10-kl, or we could just wait until we resolve these. What would you like to do?

[larsbrinkhoff]

I would like us to try to fix ^C and MAINT before merging. I started looking into the ^C thing a little bit. As for MAINT, we just have to check which files runs on KL10 and which don't. No need to update them or anything.

[larsbrinkhoff]

For the sims submodule, we have some options to consider. The submodule points to my GitHub fork "larsbrinkhoff/ka10-simh", and its "ITS" branch. This is because we sometimes want to add a few patches on top of @rcornwell's simulator. Currently, it's nothing important.

The "kl10" branch isn't near merging, so we'll have to manage this somehow until it is. We may want to also track changes from the "master" branch.

One option I'm considering is to move Rich' "kl10" changes to the "ITS" branch. Maybe squash them into a single commit. As soon as possible, we'll reset "ITS" back to track "master".

[eswenson1]

Sounds good -- I agree.

However, now we have another issue. Either this patch:

diff --git a/PDP10/kx10_cpu.c b/PDP10/kx10_cpu.c
index e737a40..93c57e4 100644
--- a/PDP10/kx10_cpu.c
+++ b/PDP10/kx10_cpu.c
@@ -4052,7 +4052,7 @@ no_fetch:
     /* Handle page fault and traps */
     if (page_enable && trap_flag == 0 && (FLAGS & (TRP1|TRP2))) {
 #if KL_ITS
-        if (QITS && (FLAGS & ADRFLT) != 0) {
+        if (QITS && (FLAGS & ADRFLT|BYTI) != 0) {^M
            FLAGS &= ~ADRFLT;
         } else {
 #endif

Or the last commit to the kl10 branch of rcornwell's sims repo (kl10 branch) has caused the build to fail while building EXTMAC (a LISP source). We get an MPV during the build.

  *complr^K!

  LISP COMPILER 1999 [in LISP 2154]

  _lisp;_lspsrc;extmac
  MPV; 162656>>PUSH 14,1
  The last command timed out.
  Makefile:100: recipe for target 'out/pdp10-kl/rp04.1' failed
  make: *** [out/pdp10-kl/rp04.1] Error 1

[larsbrinkhoff]

I think I did a full build yesteray with ce62798 "KA10: Fixed bug in ADJBP." So either the one-proceed patch, or something random.

[eswenson1]

Yeah, that’s what I thought. I’m hoping it is the patch, rather than the last commit that did it.

I think I did a full build yesteray with ce62798 "KA10: Fixed bug in ADJBP." So either the one-proceed patch, or something random.

[larsbrinkhoff]

@kcr wrote:

Ran into cent and bawden at the sipb thing,. Showed em recent pictures of mc, they oohd and awwd Confirmed that mc didn't arrive with tops 20 paging

[larsbrinkhoff]

MAINT was easy. Just load without translations.

[larsbrinkhoff]

@rcornwell, for what it's worth, ITS' MAINT; PART * diagnostics pass your KL10 using the same files that works for KS10. I suspect they were updated for KL10 in the first place. The "OLD" versions are for KA10.