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