Thanks, that sounds likely, I will check how I am writing to memory. Regards
Rob > -----Original Message----- > From: Timothe Litt [mailto:l...@ieee.org] > Sent: 19 May 2013 21:41 > To: Robert Jarratt > Cc: simh@trailing-edge.com > Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > This is progress. Looks to me like the data isn't being stored properly. > > The ADDITIONAL DATA is the first 8 bytes of the data buffer. The SKIPL > says the sign bit is set (which it is in 7463...). > That's not possible. > > So I suspect you're not writing the data thru the UBA map correctly. > > Data from the UBA in -10 memory is in PDP-11 byte order, with 16 bit > words packed into 18-bit 1/2 words. > This looks like: > > /-- Bit 0 - the sign bit tested by the SKIPL & SKIPGE > / /-- The ENQ goes here > / / -- The START goes here > ! 00 ! byte 1 ! byte 0 ! 00 ! byte 3 ! byte 2 ! < PDP-10 word 0 > ! 00 ! byte 5 ! byte 4 ! 00 ! byte 7 ! byte 6 ! < PDP-10 word 1 > > Since 00 is constant, the first digit can't be > 1. 7 mumble is. > > Thus for 05 06 (ENQ START), we should see something like 3005,,... in > the first word. > (5 + 6 << 8) > > Also, you need to map the UBA address to PDP-10 memory (which you seem > to be doing for reads). > > > This communication may not represent my employer's views, > if any, on the matters discussed. > > On 19-May-13 16:06, Robert Jarratt wrote: > > Oops, meant to say the first byte sent is 0x05. > > > >> -----Original Message----- > >> From: Robert Jarratt [mailto:robert.jarr...@ntlworld.com] > >> Sent: 19 May 2013 21:01 > >> To: 'Timothe Litt'; 'simh@trailing-edge.com' > >> 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: simh-boun...@trailing-edge.com [mailto:simh-bounces@trailing- > >>> edge.com] On Behalf Of Timothe Litt > >>> Sent: 19 May 2013 18:01 > >>> To: simh@trailing-edge.com > >>> 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: simh-boun...@trailing-edge.com [mailto:simh- > bounces@trailing- > >>>>> edge.com] On Behalf Of Timothe Litt > >>>>> Sent: 19 May 2013 17:01 > >>>>> Cc: simh@trailing-edge.com > >>>>> 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: simh-boun...@trailing-edge.com [mailto:simh- > >>> bounces@trailing- > >>>>>>> edge.com] On Behalf Of Robert Jarratt > >>>>>>> Sent: 19 May 2013 15:21 > >>>>>>> To: 'Timothe Litt'; simh@trailing-edge.com > >>>>>>> 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: simh-boun...@trailing-edge.com > >>>>>>>> [mailto:simh-bounces@trailing- edge.com] On Behalf Of Timothe > >>>>>>>> Litt > >>>>>>>> Sent: 19 May 2013 14:54 > >>>>>>>> To: simh@trailing-edge.com > >>>>>>>> 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: simh-boun...@trailing-edge.com [mailto:simh- > >>>>> bounces@trailing- > >>>>>>>>>> edge.com] On Behalf Of Timothe Litt > >>>>>>>>>> Sent: 19 May 2013 11:26 > >>>>>>>>>> To: simh@trailing-edge.com > >>>>>>>>>> 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: simh-boun...@trailing-edge.com [mailto:simh- > >>>>>>>> bounces@trailing- > >>>>>>>>>>>> edge.com] On Behalf Of Rich Alderson > >>>>>>>>>>>> Sent: 08 May 2013 01:02 > >>>>>>>>>>>> To: hec...@update.uu.se; simh@trailing-edge.com > >>>>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver > Code? > >>>>>>>>>>>> > >>>>>>>>>>>>> From: "Robert Jarratt" <robert.jarr...@ntlworld.com> > >>>>>>>>>>>>> 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 > >>>>>>>>>>>> Simh@trailing-edge.com > >>>>>>>>>>>> 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 > >>>>>>>>>>> Simh@trailing-edge.com > >>>>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > >>>>>>> _______________________________________________ > >>>>>>> Simh mailing list > >>>>>>> Simh@trailing-edge.com > >>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > _______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh