Inline. This communication may not represent my employer's views, if any, on the matters discussed.
On 27-May-13 05:48, Robert Jarratt wrote:
-----Original Message----- From: Timothe Litt [mailto:[email protected]] Sent: 26 May 2013 11:25 To: Robert Jarratt Cc: [email protected] Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? Rob, Thanks for the log. Looks like both simh and you have some bugs. But you're close to working... First nit: the KMC CMD & DUP QUEUE debug messaged looks like they are trying to print hex as well as octal - missing a % in the printf() format? (Assuming the data is passed twice...)Oops! Missed that, thanks.The descriptors look reasonable. Second: The Map_WriteW routine (in pdp10_ksio.c) is preserving bits 0,1, 18 & 19, but this is a 16-bit device. The real UBA would clear them in this case. This is a bug in simh.Changing ksio from this if (ba & 2) M[pa10] = (M[pa10] & INT64_C(0777777600000)) | val; else M[pa10] = (M[pa10] & INT64_C(0600000777777)) | (val << 18); To this if (ba & 2) M[pa10] = (M[pa10] & INT64_C(0777777000000)) | val; else M[pa10] = (M[pa10] & INT64_C(0000000777777)) | (val << 18); Seemed to cure the immediate problem
You must be the first user of these routines... Map_WriteB() isn't clearing the 4 MBZ bits either. M[pa10] = (M[pa10] & ~(mask << ubashf[ba & 3])) | (((d10) *buf++) << ubashf[ba & 3]; should be: M[pa10] = ((M[pa10] & ~(mask << ubashf[ba & 3])) | (((d10) *buf++) << ubashf[ba & 3]) & ~INT64_C(0600000600000));Looks like Map_WriteW() cloned it. Ideally, Map_WriteW() should take a (16-bit) word count rather than a byte count. That would simplify life for the code and callers alike. But the VAX UBA routines have the same prototype, so I guess we're stuck with it.
A more correct fix would be something like the following (but they still should only check the map on page boundaries, which I'm too lazy to code right now). I haven't compiled this, but I think the logic is correct.
# Here we optionally allow return of the map entry
a10 Map_Addr10 (a10 ba, int32 ub, int32 *ubm)
{
a10 pa10;
int32 vpn = PAG_GETVPN (ba >> 2); /* get PDP-10 page number */
if ((vpn >= UMAP_MEMSIZE) || (ba & XBA_MBZ) || /* invalid map? */
((ubmap[ub][vpn] & UMAP_VLD) == 0))
return -1;
pa10 = (ubmap[ub][vpn] + PAG_GETOFF (ba >> 2)) & PAMASK;
if (ubm)
*ubm = ubmap[ub][vpn]; /* Return map entry if requested */
return pa10;
}
/* The next 5 routines would be more efficient if they only called
Map_Addr10 for the first transfer & when crossing a page. */
# pass NULL to Map_addr10. No other changes.
int32 Map_ReadB (uint32 ba, int32 bc, uint8 *buf)
...
pa10 = Map_Addr10 (ba, 1, NULL);
...
int32 Map_ReadW (uint32 ba, int32 bc, uint8 *buf)
...
pa10 = Map_Addr10 (ba, 1, NULL);
...
#replace existing routines - these should correctly handle UB<17:16>
/* Byte-mode writes */
int32 Map_WriteB (uint32 ba, int32 bc, uint8 *buf)
{
uint32 lim;
a10 pa10;
d10 mask;
lim = ba + bc;
for ( ; ba < lim; ba++) { /* by bytes */
pa10 = Map_Addr10 (ba, 1, NULL); /* map addr */
if ((pa10 < 0) || MEM_ADDR_NXM (pa10)) { /* inv map or NXM? */
ubcs[1] = ubcs[1] | UBCS_TMO; /* UBA times out */
return (lim - ba); /* return bc */
}
if( (ba&3) == 0 ) { /* byte 0 writes memory; other bytes &
<0:1,18:19> of M[] are undefined. */
M[pa10] = ((d10) *buf++) << 18; /* Clears undefined bits */
} else { /* RPW - clear byte position, and UB<17:16> of correct 1/2
word when writing high byte */
mask = 0377<< ubashf[ba & 3];
if (ba & 1)
mask |= INT64_C(0000000600000) << ((ba & 2)? 0 : 18);
M[pa10] = (M[pa10] & ~mask) |
(((d10) *buf++) << ubashf[ba & 3]);
}
}
return 0;
}
/* Word mode writes; 16-bit data */
int32 Map_WriteW (uint32 ba, int32 bc, uint16 *buf)
{
uint32 lim;
uint32 ubm;
a10 pa10;
d10 val;
ba = ba & ~01; /* align start */
lim = ba + (bc & ~01);
for ( ; ba < lim; ba+= 2) { /* by words */
pa10 = Map_Addr10 (ba, 1, &ubm); /* map addr */
if ((pa10 < 0) || MEM_ADDR_NXM (pa10)) { /* inv map or NXM? */
ubcs[1] = ubcs[1] | UBCS_TMO; /* UBA times out */
return (lim - ba); /* return bc */
}
val = *buf++; /* get 16-bit data, clearing <17:16> */
if (ubm & UMAP_RRV ) { /* Read reverse preserves even word */
if (ba & 2)
M[pa10] = (M[pa10] & INT64_C(0777777000000)) | val;
else M[pa10] = (M[pa10] & INT64_C(0000000777777)) | (val << 18);
} else {
if (ba & 2) /* Write odd preserves even word */
M[pa10] = (M[pa10] & INT64_C(0777777000000)) | val;
else M[pa10] = val << 18; /* Write even clears odd *
}
return 0;
}
# new (unused) routine for 18-bit devices. Identical, except input is
18 bits (in 32 bits).
/* Word mode writes; 18-bit data */
int32 Map_WriteW18 (uint32 ba, int32 bc, uint32 *buf)
{
uint32 lim;
uint32 ubm;
a10 pa10;
d10 val;
ba = ba & ~01; /* align start */
lim = ba + (bc & ~01);
for ( ; ba < lim; ba+= 2) { /* by words */
pa10 = Map_Addr10 (ba, 1, &ubm); /* map addr */
if ((pa10 < 0) || MEM_ADDR_NXM (pa10)) { /* inv map or NXM? */
ubcs[1] = ubcs[1] | UBCS_TMO; /* UBA times out */
return (lim - ba); /* return bc */
}
val = *buf++; /* get 18-bit data */
if (ubm & UMAP_RRV ) { /* Read reverse preserves even word */
if (ba & 2)
M[pa10] = (M[pa10] & INT64_C(0777777000000)) | val;
else M[pa10] = (M[pa10] & INT64_C(0000000777777)) | (val << 18);
} else { /* Write odd preserves even word */
if (ba & 2)
M[pa10] = (M[pa10] & INT64_C(0777777000000)) | val;
else M[pa10] = val << 18; /* Write even clears odd */
}
return 0;
}
This I'd need to debug on the -10 side. I suspect it's a JSYS failure. Wild guess: NETCON isn't running with correct privileges?TOPS-20's KDPSRV has set the buffer data to -1 (36-bits) before queuing the buffer to the KMC. The BUGCHK is complaining that bit 0 is set when the buffer is received. This is a paranoia check to see if the KMC is returning a buffer that it didn't write to. Also, the real UBA wouldn't do a read-modify-write on the first 16-bit write (unless read-reverse was set in the UBA map entry). It would simply write the first word. The odd word is also done as a simple write because the UBA saves the even word's data - that's roughly equivalent to RMW. (See http://bitsavers.trailing-edge.com/pdf/dec/pdp10/KS10/EK-OKS10-TM- 002_tech_Sep79.pdf around page 5-119 for the gory details, including other transfer modes.) Third: The additional data in the bugchk is the 10-side view of the buffer's first two 36-bit words. This is not the correct data. Note that 3 16-bit words are written, which corresponds to your 6 bytes. But the data is the same (0746314) in each word. The unwritten word is 0777777, which is a good sign that the mapping is correct (though not what a real UBA would do). If we clear the two high bits of the data, we get 0146314, which is 0xCCcc. 0xcc happens to be the low byte of the last DMA UB WRITE's address. Perhaps the address and data arguments to your unibus_write routine are swapped?This bit had me stumped until I really checked what was going on in Map_WriteW. I think there is a bug in it on this line: for ( ; ba < lim; ba++) { /* by bytes */ It should be for ( ; ba < lim; ba += 2) { /* by bytes */ That is why 0xCCCC was getting written to the memory. Now I can see that the right data gets into the OS because I temporarily provoked the bugchk again by not clearing the bits, the additional data looked correct this time. However, I still see one end repeatedly sending the first DDCMP message (05 06 C0 00 00 01), but nothing else happens, no response going the other way, no messages on the console etc. I notice that I do get this message on bootup though: SJ 3: $RUN SYS:NETCON SJ 2: ?ILLEGAL INSTRUCTION 0 AT 236246 SJ 2: ?UNDEFINED OPERATION CODE SJ 3: SJ 3: % NETCON: COULD NOT OBTAIN NETWORK TOPOLOGY Could it be that I still don't have the right version of DECnet on this virtual machine? Thanks! Rob
You might want to look at pdp10_tu.c for a more efficient way of doing large unibus transfers. It (FNC_READF and FNC_WRITE) does the expensive unibus mapping only once per page, and writes directly to -10 memory - bypassing the bug in Map_WriteW. It also handles NXM reporting, which hopefully the caller to your interface code is doing...It looks like rather than patch Map_WriteW above it would be better to write a couple of general DMA routines for transferring large buffers. I will try to do that, let's see if I understand everything you and Rob Doyle have said....
Probably can take what I supplied above and simply call Map_Addr10 before the for loops, then update when ba crosses a page boundary. The existing routines should handle large buffers if you do that.
Note, though, that the tu works thru a RH11, which is an 18-bit device and the tape is packing bytes into 36-bit words in odd ways. Don't let that confuse you. Yes, KDPSRV will always return the same buffers; that's expected. It has statically allocated buffers for each line's transmit and receive and copies data in and out. This is partly due to byte re-ordering and partly a matter of simplifying UBA mapping register management. This communication may not represent my employer's views, if any, on the matters discussed. On 26-May-13 04:09, Robert Jarratt wrote: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=111710sel6=020000DBG(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=112530sel6=020000DBG(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).Descriptoris: 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 toaddress=0x93D8(111730octal), 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.Ithen transfer the buffer out to the OS using an output command (nodetailedtrace for that), this is immediately followed by me receiving a newreceivebuffer (the very one I just sent, so I think the output transfer musthaveworked) and the error from the OS: DBG(582051478)> KMC CMD: Input command: sel2=000004 sel4=111710sel6=020000DBG(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 istheunibus_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: [email protected] [mailto:simh-bounces@trailing- edge.com] On Behalf Of Robert Jarratt Sent: 19 May 2013 22:47 To: 'Timothe Litt' Cc: [email protected] 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:[email protected]] Sent: 19 May 2013 21:41 To: Robert Jarratt Cc: [email protected] Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? This is progress. Looks to me like the data isn't being storedproperly.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 youseemto 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:[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,withthe 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. Thecode Isee 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 shouldbeOK, 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(andDMC/DMR) have 2. A is the (numerically) first; B is the second.Sointhe interrupt ack routine, you need to return VEC_KDP *kmcnumberor VEC_KDP * kmcnumber +4, depending on which interrupt is beinggranted.(Or whatever symbol you used.) A should be generated by RDI; B byRDO.That will tell simh how to find the right service routine. IIRC, if both happen to be pending at the same time, A takesprecedence.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 bit9.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 TAKEDIFFERENT ?TRNN T2,KMCRDI ;AND IS IT READY ? BUG (KMCIII,<<T1,D>,<T2,D>>) << A interrupt with nothinginthedriver queue, or RDI not setCAIN T1,KMCINQ+KMCQLN-1 ;TIME TO WRAP AROUNDAGAIN ?MOVEI T1,KMCINQ+1 ;YES SO POINT TO BEGINING OFQUEUEADDI T1,2 ;ADVANCE POINTER FOR THIS ENTRY MOVEM T1,KMCINQ+1 ;SAVE UPDATED TAKER MOVEI T2,KMCRQI ;WANT TO CLEAR RQUESTINPUTFLAG << CSR BIT requesting an A interruptCAMN T1,KMCINQ ;IS QUEUE EMPTY NOW ? BCIO T2,BSEL0(T4) ;THIS IS LAST OF DATA << Clearsrequestwhen driver queue emptyMOVE T2,(T1) ;GET 2ND WORD IN QUEUE ENTRY MOVE T1,-1(T1) ;GET 1ST WORD IN QUEUEENTRY<< the command is then removed from the driver queue andwrittentothe 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 interrupthandler.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 Ainterrupt.(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 theKMC acommand, but the interrupt is going to the wrong vector since RDYI is notset.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 haveanoverrun - the interrupt has to be cleared when the drive clears the RDxbit.The data looks like a DDCMP start, less the CRCs. That indicates that afair bitof stuff is working; this is the data that the -10 provides to theKMC.Yes, the KMC is supposed to add (and check) the CRC-16s.(Headerand data) - unless CRC inhibit (1000) is set in BSEL6 by a controlin.CRC errors are reported by control out bits. Since the KMC both adds on transmit and removes/checks on receive, and you arerunningover an error- checked transport, you can get away with not simulating this - unless you want to interoperate with an interface that does add theCRCs.Even if the systems are cloned, the DDCMP layer should come up; you'll die later when transport detects a duplicate DECnet nodenumber.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)runningattempting to talk to each other. The first message one sends to theothercrashes 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 fromtheother 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 Ihave,Ithinksome checksum is supposed to follow. Is that supposed to be added by theKMCperhaps? I don't fully expect it to work because they are clones so would expectsomekind 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 betternow.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 enablingit.This particular code has never (as far as I know) worked for the 11 ortheVAX. I wrote the DMC11 code for those. This code I am working with now came from someone else and was written for thePDP1)foramucholder version of SIMH. Regards Rob-----Original Message----- From: [email protected] [mailto:simh-bounces@trailing- edge.com] On Behalf OfTimotheLitt 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 alreadyThen I need a trace of what's happening to the registers, and whatsimhthinks it's doing with the interrupts. (It would be easiesttofollowif you output both octal and decode the register names/fields, though Icanstill think - slowly- in octal.) Also, I thought this code was working for the -11/VAX. If so, the basicsmustbe OK, though the drivers may well take a different approach to thedevice.Received data should produce either a control-out (error, e.g. no buffer available or DSR change or NXM...) or a buffer-out Binterrupt.Themessagemust fit in 1 buffer. Errors may implicitly free a BDL... Transmit done - also note that we ignore interrupts unless the 'lastbuffer' bitis 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(KMCSUP400)toforce the microcontroller to execute several known instructions - toaccess itsdata ram, registers & PC. This is primarily used to dump a KMC that halts- itdoesn't seem to be used when the built-in ucode is loaded. But some of these are also used to verify data ram atinitialization.Failure toverify willcause the device to be disabled. We can go down that path if you seethosebits 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%20Manual.pdf <http://bitsavers.trailing- edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11-OP-PRE%20KMC11%20General%20Purpose%20Microprocessor%20User%27s%20Manual.pdf> The subset is pretty small - load address register, load/store indirect(withincrement), & branch. I think you ought to be able to crash simh if an unknown instruction is forced, including a branch to an address other than0.Ugly device, ugly driver. Sigh. This communication may not represent my employer's views,ifany, 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 missedsomething.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 DriverCode?A couple of other things come to mind (naturally, after pushing'send'):Initialization will load/verify the microcode. That has towork.After setting RUN and the interrupt enables, expect base-inand control-in command to establish the DUP CSR address, buffers, linemode/enable.These require that the KMC respond to KMCRQI byinitiatingan A vector interrupt. Besides RDIO and WRIO, there are bit test (TIOx) , bit set (BSIO) and bitclear(BCIO) instructions that also touch the KMC. For better directed hints, I'd need more detail on what is and isn'thappening.This communication may not represent my employer'sviews,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 DriverCode?From: "Robert Jarratt" <[email protected]> Date: Tue, 7 May 2013 23:33:36 +0100 Can anyone pointmeatthe right place to look at TOPS-20 driver code for theKMC11?I can see that it is trying to get the Microprocessor to do something and read back some values, but I don'tknowwhatvalues it wants to get and so it reports:Hi, Rob, http://pdp-10.trailing-edge.com/tops20v41_monitor_sources/index.html You want the file KDPSRV.MAC in that directory. Rich_______________________________________________Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simhI am making some progress with getting the KMC/DUPemulationworkingin 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 abuffer.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 amwonderingif 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 besetting.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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
