Re: [Simh] TOPS-20 Source with KMC11 Driver Code?

Sun, 19 May 2013 13:43:41 -0700 

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:[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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh

Reply via email to