Oops, meant to say the first byte sent is 0x05. > -----Original Message----- > From: Robert Jarratt [mailto:[email protected]] > Sent: 19 May 2013 21:01 > To: 'Timothe Litt'; '[email protected]' > Subject: RE: [Simh] TOPS-20 Source with KMC11 Driver Code? > > Thanks! There was a bug in my interrupt acknowledge routine. With that > fixed the interrupts now seem to be working OK. I have made progress, with > the two clones talking to each other I get this now: > > > ******************** > *BUGCHK "BADHDR" AT 19-MAY-2013 20:40:52 > *BAD DDCMP HEADER > *ADDITIONAL DATA: 746314746314, 746314777777 > ******************** > > I am going to have to re-learn MACRO to work out why it is failing. The code I > see has two jumps to BUMHDR, I can't work out what the first one means, > the second seems to be checking the first byte, which being 0x06 should be > OK, so it is probably the first condition that is failing. > > Regards > > Rob > > > > -----Original Message----- > > From: [email protected] [mailto:simh-bounces@trailing- > > edge.com] On Behalf Of Timothe Litt > > Sent: 19 May 2013 18:01 > > To: [email protected] > > Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > > > That's the code that emitted the bugcheck. BUG(KMCIII) => BUGHLT > > "KMCIII". > > > > You need to tell simh what vector to use when you tell it about the > > pending interrupt. Most devices have only one vector. The KMC (and > > DMC/DMR) have 2. A is the (numerically) first; B is the second. So in > > the interrupt ack routine, you need to return VEC_KDP * kmcnumber or > > VEC_KDP * kmcnumber +4, depending on which interrupt is being granted. > > (Or whatever symbol you used.) A should be generated by RDI; B by RDO. > > > > That will tell simh how to find the right service routine. > > > > IIRC, if both happen to be pending at the same time, A takes precedence. > > > > Without seeing the code, I can't be more explicit... > > > > Oh, be careful when you talk about bit numbers. The unibus is > > little-endian (lsb = bit 0); the -10 is big-endian (MSB -0 bit 0). > > > > This communication may not represent my employer's views, if any, on > > the matters discussed. > > > > On 19-May-13 12:36, Robert Jarratt wrote: > > > Hmmm.... I do have RDYO set, but it is supposed to be a B interrupt, > > > not an A, so that would make sense. I have A vectored at bit 8, and > > > B at bit > > 9. > > > > > > Are you referring to this code: > > > > > > ;HERE FOR INPUT INTERRUPTS > > > KMCVCA: MOVEM 17,KMCACS+17 ;SAVE REG > > > MOVEI 17,KMCACS ;BUILD BLT POINTER > > > BLT 17,KMCACS+16 ;SAVE REST OF REGS > > > MOVE P,[-40,,KMCIPL] ;SET UP STACK > > > MOVE T4,[KMCADR] ;GET ADDRESS OF THE KMC11 HDW > > > RDIO T2,BSEL2(T4) ;GET RDI FLAG > > > MOVE T1,KMCINQ+1 ;GET INPUT QUEUE TAKER > > > CAME T1,KMCINQ ;ARE PUTTER AND TAKE DIFFERENT ? > > > TRNN T2,KMCRDI ;AND IS IT READY ? > > > BUG (KMCIII,<<T1,D>,<T2,D>>) << A interrupt with nothing in the > > driver queue, or RDI not set > > > CAIN T1,KMCINQ+KMCQLN-1 ;TIME TO WRAP AROUND AGAIN ? > > > MOVEI T1,KMCINQ+1 ;YES SO POINT TO BEGINING OF QUEUE > > > ADDI T1,2 ;ADVANCE POINTER FOR THIS ENTRY > > > MOVEM T1,KMCINQ+1 ;SAVE UPDATED TAKER > > > MOVEI T2,KMCRQI ;WANT TO CLEAR RQUEST INPUT > > FLAG << CSR BIT requesting an A interrupt > > > CAMN T1,KMCINQ ;IS QUEUE EMPTY NOW ? > > > BCIO T2,BSEL0(T4) ;THIS IS LAST OF DATA << Clears request > > when driver queue empty > > > MOVE T2,(T1) ;GET 2ND WORD IN QUEUE ENTRY > > > MOVE T1,-1(T1) ;GET 1ST WORD IN QUEUE ENTRY > > > << the command is then removed from the driver queue and written to > > > the KMC. The KMC > > << must clear RDI until it is ready to take the next command. (Note > > that otherwise if the queue depth >1, the << A interrupt will happen > > immediately. > > > If so, then despite the fact that I am setting bit 9 in the > > > interrupt request, it seems to be going to the A interrupt handler. > > > > > > Regards > > > > > > Rob > > > > > >> -----Original Message----- > > >> From: [email protected] [mailto:simh-bounces@trailing- > > >> edge.com] On Behalf Of Timothe Litt > > >> Sent: 19 May 2013 17:01 > > >> Cc: [email protected] > > >> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > >> > > >> The bugcheck is saying that the RDYO is set, but not RDYI on an A > > > interrupt. > > >> (KMCRDI is 20; RDO is 200) > > >> > > >> RDYO should always go to IVB; RDYI to IVA. > > >> > > >> Since we took an IVA interrupt, the driver thinks its trying to > > >> give the > > > KMC a > > >> command, but the interrupt is going to the wrong vector since RDYI > > >> is not > > > set. > > >> So either you're generating an IVA but setting the wrong status > > >> bit, or generating an Ivb event but not to the right vector. Or > > >> perhaps you have > > > an > > >> overrun - the interrupt has to be cleared when the drive clears the > > >> RDx > > > bit. > > >> The data looks like a DDCMP start, less the CRCs. That indicates > > >> that a > > > fair bit > > >> of stuff is working; this is the data that the -10 provides to the KMC. > > >> > > >> Yes, the KMC is supposed to add (and check) the CRC-16s. (Header > > >> and > > >> data) - unless CRC inhibit (1000) is set in BSEL6 by a control in. > > >> CRC errors are reported by control out bits. Since the KMC both > > >> adds on transmit and removes/checks on receive, and you are running > > >> over an error- checked transport, you can get away with not > > >> simulating this - unless you want to interoperate with an interface > > >> that does add the > > CRCs. > > >> > > >> Even if the systems are cloned, the DDCMP layer should come up; > > >> you'll die later when transport detects a duplicate DECnet node number. > > >> > > >> > > >> This communication may not represent my employer's views, if any, > > >> on the matters discussed. > > >> > > >> On 19-May-13 11:01, Robert Jarratt wrote: > > >>> What is curious now is that I have two instances (identical > > >>> clones) > > > running > > >>> attempting to talk to each other. The first message one sends to > > >>> the > > > other > > >>> crashes the OS: > > >>> > > >>> ********** > > >>> *BUGHLT "KMCIII" AT 19-May-2013 15: > > >>> *ADDITIONAL DATA: 000000172507, 000000000200 > > >>> ********** > > >>> > > >>> The odd thing is that I have delivered the same data that was sent > > >>> from > > > the > > >>> other end, so it should be valid data. > > >>> > > >>> The data is: 05 06 C0 00 00 01 > > >>> > > >>> That data does not seem to completely match the DDCMP spec I have, > > >>> I > > >> think > > >>> some checksum is supposed to follow. Is that supposed to be added > > >>> by the > > >> KMC > > >>> perhaps? > > >>> > > >>> I don't fully expect it to work because they are clones so would > > >>> expect > > >> some > > >>> kind of error, but would not expect a crash, or am I wrong? > > >>> > > >>> Regards > > >>> > > >>> Rob > > >>> > > >>>> -----Original Message----- > > >>>> From: [email protected] [mailto:simh- > > bounces@trailing- > > >>>> edge.com] On Behalf Of Robert Jarratt > > >>>> Sent: 19 May 2013 15:21 > > >>>> To: 'Timothe Litt'; [email protected] > > >>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > >>>> > > >>>> I have made some progress. I realised that I did not have the > > >>>> interrupt acknowledgement routines set up in the DIB. It is > > >>>> working a bit better > > >>> now. > > >>>> I have indeed seen some commands to read the ram and verify the > > >>>> microcode, it does all this to check the KMC is working before > > >>>> enabling > > >>> it. > > >>>> This particular code has never (as far as I know) worked for the > > >>>> 11 or > > > the > > >>>> VAX. I wrote the DMC11 code for those. This code I am working > > >>>> with now came from someone else and was written for the PDP1) for > > >>>> a > > much > > >>>> older version of SIMH. > > >>>> > > >>>> Regards > > >>>> > > >>>> Rob > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: [email protected] > > >>>>> [mailto:simh-bounces@trailing- edge.com] On Behalf Of Timothe > > >>>>> Litt > > >>>>> Sent: 19 May 2013 14:54 > > >>>>> To: [email protected] > > >>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > >>>>> > > >>>>>> I am pretty sure I am doing all the things you mention already > > >>>>> Then I need a trace of what's happening to the registers, and > > >>>>> what > > > simh > > >>>>> thinks it's doing with the interrupts. (It would be easiest to > > > follow > > >>>>> if you output both octal and decode the register names/fields, > > >>>>> though I > > >>>> can > > >>>>> still think - slowly- in octal.) > > >>>>> > > >>>>> Also, I thought this code was working for the -11/VAX. If so, > > >>>>> the basics > > >>>> must > > >>>>> be OK, though the drivers may well take a different approach to > > >>>>> the > > >>>> device. > > >>>>> Received data should produce either a control-out (error, e.g. > > >>>>> no buffer available or DSR change or NXM...) or a buffer-out B > interrupt. > > >>>>> The > > >>>> message > > >>>>> must fit in 1 buffer. Errors may implicitly free a BDL... > > >>>>> > > >>>>> Transmit done - also note that we ignore interrupts unless the > > >>>>> 'last > > >>>> buffer' bit > > >>>>> is set. (The DDCMP header and data are in two BDL segments, and > > >>>>> require two interrupts.) > > >>>>> > > >>>>> Finally, I'm not sure if you'll see it used, but there is code > > >>>>> in the > > >>>>> TOPS-20 driver that uses KMCRMI (1000 in BSEL0) & step (KMCSUP > > >>>>> 400) > > >> to > > >>>>> force the microcontroller to execute several known instructions > > >>>>> - to > > >>>> access its > > >>>>> data ram, registers & PC. This is primarily used to dump a KMC > > >>>>> that halts > > >>>> - it > > >>>>> doesn't seem to be used when the built-in ucode is loaded. But > > >>>>> some of these are also used to verify data ram at initialization. > > >>>>> Failure to > > >>>> verify will > > >>>>> cause the device to be disabled. We can go down that path if > > >>>>> you see > > >>>> those > > >>>>> bits being set in a trace. > > >>>>> > > >>>>> Look for KMCXCT calls in > > >>>>> http://pdp-10.trailing-edge.com/BB-Y393K-SM/01/monitor- > > >>>>> sources/kdpsrv.mac.html > > >>>>> TOPS-10 doesn't do this. The microinstructions are defined in > > >>>>> http://bitsavers.trailing- > > >>>>> edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11-OP- > > >>>>> > > >> > > > PRE%20KMC11%20General%20Purpose%20Microprocessor%20User's%20Ma > > >>>>> nual.pdf > > >>>>> <http://bitsavers.trailing- > > >>>>> edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11-OP- > > >>>>> > > >> > > > PRE%20KMC11%20General%20Purpose%20Microprocessor%20User%27s%2 > > >>>>> 0Manual.pdf> > > >>>>> The subset is pretty small - load address register, load/store > > >>>>> indirect > > >>>> (with > > >>>>> increment), & branch. I think you ought to be able to crash > > >>>>> simh if an unknown instruction is forced, including a branch to > > >>>>> an address other than > > >>>> 0. > > >>>>> Ugly device, ugly driver. Sigh. > > >>>>> > > >>>>> > > >>>>> This communication may not represent my employer's views, if > > >>>>> any, on the matters discussed. > > >>>>> > > >>>>> On 19-May-13 07:42, Robert Jarratt wrote: > > >>>>>> Thanks Timothe, > > >>>>>> > > >>>>>> I am pretty sure I am doing all the things you mention already > > >>>>>> (sorry I didn't make that clear), but I will check through > > >>>>>> everything you have said, just in case I have missed something. > > >>>>>> > > >>>>>> Regards > > >>>>>> > > >>>>>> Rob > > >>>>>> > > >>>>>>> -----Original Message----- > > >>>>>>> From: [email protected] [mailto:simh- > > >> bounces@trailing- > > >>>>>>> edge.com] On Behalf Of Timothe Litt > > >>>>>>> Sent: 19 May 2013 11:26 > > >>>>>>> To: [email protected] > > >>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > >>>>>>> > > >>>>>>> A couple of other things come to mind (naturally, after > > >>>>>>> pushing > > >>>> 'send'): > > >>>>>>> Initialization will load/verify the microcode. That has to work. > > >>>>>>> > > >>>>>>> After setting RUN and the interrupt enables, expect base-in > > >>>>>>> and control-in command to establish the DUP CSR address, > > >>>>>>> buffers, line > > >>>>> mode/enable. > > >>>>>>> These require that the KMC respond to KMCRQI by initiating an > > >>>>>>> A vector interrupt. > > >>>>>>> > > >>>>>>> Besides RDIO and WRIO, there are bit test (TIOx) , bit set > > >>>>>>> (BSIO) and bit > > >>>>>> clear > > >>>>>>> (BCIO) instructions that also touch the KMC. > > >>>>>>> > > >>>>>>> For better directed hints, I'd need more detail on what is and > > >>>>>>> isn't > > >>>>>> happening. > > >>>>>>> This communication may not represent my employer's views, if > > >>>>>>> any, on the matters discussed. > > >>>>>>> > > >>>>>>> On 19-May-13 04:53, Robert Jarratt wrote: > > >>>>>>>>> -----Original Message----- > > >>>>>>>>> From: [email protected] [mailto:simh- > > >>>>> bounces@trailing- > > >>>>>>>>> edge.com] On Behalf Of Rich Alderson > > >>>>>>>>> Sent: 08 May 2013 01:02 > > >>>>>>>>> To: [email protected]; [email protected] > > >>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > >>>>>>>>> > > >>>>>>>>>> From: "Robert Jarratt" <[email protected]> > > >>>>>>>>>> Date: Tue, 7 May 2013 23:33:36 +0100 Can anyone point me at > > >>>>>>>>>> the right place to look at TOPS-20 driver code for the KMC11? > > >>>>>>>>>> I can see that it is trying to get the Microprocessor to do > > >>>>>>>>>> something and read back some values, but I don't know what > > >>>>>>>>>> values it wants to get and so it reports: > > >>>>>>>>> Hi, Rob, > > >>>>>>>>> > > >>>>>>>>> http://pdp-10.trailing- > > >>>>> edge.com/tops20v41_monitor_sources/index.htm > > >>>>>>>>> l > > >>>>>>>>> > > >>>>>>>>> You want the file KDPSRV.MAC in that directory. > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> Rich > > _______________________________________________ > > >>>>>>>>> Simh mailing list > > >>>>>>>>> [email protected] > > >>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > > >>>>>>>> I am making some progress with getting the KMC/DUP > emulation > > >>>>> working > > >>>>>>>> in SIMH for TOPS-20. At the moment I am stuck on one thing, > > >>>>>>>> which is the interrupts to tell the OS that the KMC has > > >>>>>>>> processed a > > >>> buffer. > > >>>>>>>> The OS sets the interrupt enable bit and when I have > > >>>>>>>> something to report to the OS I set the relevant interrupt > > >>>>>>>> bit. However, nothing happens when I do that. I am wondering > > >>>>>>>> if I have the right interrupt bit? I am using bits 8 and 9 (decimal). > > >>>>>>>> > > >>>>>>>> I am not sure how to find out which bit I should be setting. > > >>>>>>>> > > >>>>>>>> Can anyone help? > > >>>>>>>> > > >>>>>>>> Regards > > >>>>>>>> > > >>>>>>>> Rob > > >>>>>>>> > > >>>>>>>> _______________________________________________ > > >>>>>>>> Simh mailing list > > >>>>>>>> [email protected] > > >>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > > >>>> _______________________________________________ > > >>>> Simh mailing list > > >>>> [email protected] > > >>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > >
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
