[Simh] TOPS-20 Source with KMC11 Driver Code?
Robert Jarratt
robert.jarratt at ntlworld.com
Sun May 26 04:09:01 EDT 2013
Tim,
I have been looking very closely at how I am writing to the memory and I
cannot see anything obviously wrong. Let me run you through one receive
buffer transfer with some extracts from the log, see if you can spot any
flaws:
On startup I get two receive buffers as follows:
DBG(285632654)> KMC CMD: Input command: sel2=000004 sel4=111710 sel6=020000
DBG(285632654)> KMC CMD: Line 0 ba=0x93c8(111710 octal)
DBG(285632654)> KMC CMD: Descriptor for rx buffer:
DBG(285632654)> KMC CMD: Word 1 = 0x04X(111730 octal)
DBG(285632654)> KMC CMD: Word 2 = 0x04X(000600 octal)
DBG(285632654)> KMC CMD: Word 3 = 0x04X(100000 octal)
DBG(285632654)> DUP0 QUEUE: Queued rx buffer 0, descriptor
address=0x93C8(111710 octal)
DBG(285632752)> KMC CMD: Input command: sel2=000004 sel4=112530 sel6=020000
DBG(285632752)> KMC CMD: Line 0 ba=0x9558(112530 octal)
DBG(285632752)> KMC CMD: Descriptor for rx buffer:
DBG(285632752)> KMC CMD: Word 1 = 0x04X(112550 octal)
DBG(285632752)> KMC CMD: Word 2 = 0x04X(000600 octal)
DBG(285632752)> KMC CMD: Word 3 = 0x04X(100000 octal)
DBG(285632752)> DUP0 QUEUE: Queued rx buffer 1, descriptor
address=0x9558(112530 octal)
A little while later I receive the 6 bytes of data from the peer:
DBG(582050921)> DUP0 DATA: Read packet, length 6: 05 06 C0 00 00 01
DBG(582050921)> DUP0 QUEUE: dup_receive ba=0x93c8(111710 octal). Descriptor
is:
DBG(582050921)> DUP0 QUEUE: Word 1 = 0x04X(111730 octal)
DBG(582050921)> DUP0 QUEUE: Word 2 = 0x04X(000600 octal)
DBG(582050921)> DUP0 QUEUE: Word 3 = 0x04X(100000 octal)
DBG(582050921)> DUP0 QUEUE: Receive buf[0] writing to address=0x93D8(111730
octal), bytes=6
dma ub write 0x000093d8=003005(oct)
dma ub write 0x000093da=000300(oct)
dma ub write 0x000093dc=000400(oct)
dma ub write 0x000093cc=101400(oct)
So the memory appears to get written correctly to the correct location. I
then transfer the buffer out to the OS using an output command (no detailed
trace for that), this is immediately followed by me receiving a new receive
buffer (the very one I just sent, so I think the output transfer must have
worked) and the error from the OS:
DBG(582051478)> KMC CMD: Input command: sel2=000004 sel4=111710 sel6=020000
DBG(582051478)> KMC CMD: Line 0 ba=0x93c8(111710 octal)
DBG(582051478)> KMC CMD: Descriptor for rx buffer:
DBG(582051478)> KMC CMD: Word 1 = 0x04X(111730 octal)
DBG(582051478)> KMC CMD: Word 2 = 0x04X(000600 octal)
DBG(582051478)> KMC CMD: Word 3 = 0x04X(100000 octal)
DBG(582051478)> DUP0 QUEUE: Queued rx buffer 1, descriptor
address=0x93C8(111710 octal)
********************
*BUGCHK "BADHDR" AT 26-MAY-2013 08:46:24
*BAD DDCMP HEADER
*ADDITIONAL DATA: 746314746314, 746314777777
********************
My suspicion fell on the code to write the data to the memory, this is the
unibus_write code:
extern t_stat unibus_write(int32 data, int32 addr)
{
uint16 d;
d = data & 0xFFFF;
return Map_WriteW (addr, 2, &d);
}
Which looks OK to me.
Regards
Rob
> -----Original Message-----
> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-
> edge.com] On Behalf Of Robert Jarratt
> Sent: 19 May 2013 22:47
> To: 'Timothe Litt'
> Cc: simh at trailing-edge.com
> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code?
>
> Thanks, that sounds likely, I will check how I am writing to memory.
>
> Regards
>
> Rob
>
> > -----Original Message-----
> > From: Timothe Litt [mailto:litt at ieee.org]
> > Sent: 19 May 2013 21:41
> > To: Robert Jarratt
> > Cc: simh at 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.jarratt at ntlworld.com]
> > >> Sent: 19 May 2013 21:01
> > >> To: 'Timothe Litt'; 'simh at 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-bounces at trailing-edge.com
> > >>> [mailto:simh-bounces at trailing- edge.com] On Behalf Of Timothe Litt
> > >>> Sent: 19 May 2013 18:01
> > >>> To: simh at 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-bounces at trailing-edge.com [mailto:simh-
> > bounces at trailing-
> > >>>>> edge.com] On Behalf Of Timothe Litt
> > >>>>> Sent: 19 May 2013 17:01
> > >>>>> Cc: simh at 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-bounces at trailing-edge.com [mailto:simh-
> > >>> bounces at trailing-
> > >>>>>>> edge.com] On Behalf Of Robert Jarratt
> > >>>>>>> Sent: 19 May 2013 15:21
> > >>>>>>> To: 'Timothe Litt'; simh at 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-bounces at trailing-edge.com
> > >>>>>>>> [mailto:simh-bounces at trailing- edge.com] On Behalf Of
> Timothe
> > >>>>>>>> Litt
> > >>>>>>>> Sent: 19 May 2013 14:54
> > >>>>>>>> To: simh at 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-bounces at trailing-edge.com [mailto:simh-
> > >>>>> bounces at trailing-
> > >>>>>>>>>> edge.com] On Behalf Of Timothe Litt
> > >>>>>>>>>> Sent: 19 May 2013 11:26
> > >>>>>>>>>> To: simh at 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-bounces at trailing-edge.com [mailto:simh-
> > >>>>>>>> bounces at trailing-
> > >>>>>>>>>>>> edge.com] On Behalf Of Rich Alderson
> > >>>>>>>>>>>> Sent: 08 May 2013 01:02
> > >>>>>>>>>>>> To: hecnet at update.uu.se; simh at trailing-edge.com
> > >>>>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver
> > Code?
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> From: "Robert Jarratt" <robert.jarratt at 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 at 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 at trailing-edge.com
> > >>>>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh
> > >>>>>>> _______________________________________________
> > >>>>>>> Simh mailing list
> > >>>>>>> Simh at trailing-edge.com
> > >>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh
> >
>
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
More information about the Simh
mailing list