Re: [Simh] Strange PDP-11 behavior

[Mattis Lind]

2015-12-30 0:12 GMT+01:00 Bob Supnik :

> Regarding Mark Lind's post:
>

Mattis Lind, not Mark Lind.


>
> It's a simple detective problem. Where does an 11/23 differ from an 11/23+?
>
> If you look in pdp11_defs.h, F-11 based systems are grouped together, and
> CPUT_F is used in most feature definitions.
>
> #define CPUT_F  (CPUT_23|CPUT_23P|CPUT_24)  /* all F11's */
>
> There is only ONE place where an 11/23+ is called out as something other
> than a generic F-11 CPU:
>
> #define HAS_LTCR(CPUT_04|CPUT_05|CPUT_20|CPUT_23P|CPUT_24| \
>  CPUT_34|CPUT_40|CPUT_44|CPUT_45|CPUT_60| \
>  CPUT_70|CPUT_J)
>
> That is, the 11/23+ and 11/24 have a line time clock register. The 11/23
> DOES NOT.
>
> When the TST @#172540 occurs, the PSW is set to 350 (IPL 6), locking out
> any clock interrupts. The interrupt vector for NXM, however, sets the PSW
> to 0. That means any pending line-time clock interrupt will occur
> immediately.
>
> On an 11/23+, the line time clock register initializes to interrupts
> disabled. On the 11/23, though, there IS NO line time clock register, and a
> clock interrupt is pending. As soon as the NXM trap completes, an interrupt
> occurs through vector 100, which is set up as follows:
>
> 100/102
> 102/0
>
> So the PC is set to 102, which is a HALT instruction, and the simulator
> halts, with the PC pointing at the next instruction.
>
> Everything is behaving as it should. This version of XXDP was not designed
> to run on an 11/23, and it runs on an 11/23+ by coincidence.
>

This is interesting. I have yet to find a comprehensive document that tells
what version of XXDP that run on what model.
This document http://www.dmv.net/dec/pdf/xxdpum.pdf on page  2-2 (26) says
11/23 family is supported. This document seems to relate to V2.4

Now testing SimH with a (compressed) XXDP 2.5 and XXDP 2.2 image give
exactly the same result. Halt.
http://www.ibiblio.org/pub/academic/computer-science/history/pdp-11/xxdp/

I really think that it should be possible to run XXDP V2.2 and V2.2 on a
KDF11-A CPU.
Testing on real hardware shows that both KDF11-A and KDF11-B boots up fine.
If I enable LTC on a KDF11-A (have not tested on KDF11-B yet) it will halt
at the very same location.

So it has to do with LTC rather than model in my opinion. So how can I
disable LTC in SimH so that it acts like the LTC switch on the front panel?
"set clk disabled" give "Command not allowed"


>
> Moral: don't run software on hardware models that it doesn't support. And
> compress your disk images before posting them.
>

Please point me to some document that clearly states that XXDP 2.2 (and
2.5) is not possible to run on 11/23 and 11/23+. Second. Sorry about the
uncompressed image.

BTW: I have also tested this very same image on a real 11/04 and it does
boot to XXDP prompt (it does have DL11-W so LTC registers are there) . But
then it is unable to read the disk. Maybe the DU driver is not happy with
the CMD SCSI card. Booting RT11 on the same setup works fine.

Testing on a real 11/03 boots but hangs in a loop somewhere around 150100
and never prints a prompt. (LTC disabled)

But for the two latter it is highly unsure if they are at all supported by
XXDP v2.2

/Mattis


> /Bob Supnik
>
> ___
> 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

Re: [Simh] Strange PDP-11 behavior

[Mattis Lind]

onsdag 30 december 2015 skrev Johnny Billquist :

> Ah... And I need to correct myself.
>
> Bob didn't say that the 11/23 didn't have an LTC. He said it didn't have a
> LTCR... So, in short, you cannot disable the LTC interrupt on the 11/23.
> Interesting. Weird. Oh well. I can't find any reference to an LTCR in the
> documentation, so it would appear that this really is the case.
> So, in order to run XXDP on an 11/23, you need to disable the LTC signal
> then.


That was my question in the previous post to the list. On the real hardware
it is a matter of toggling a switch on the front panel to disable the LTC
signal. How is this performed in SimH?

/Mattis
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Strange PDP-11 behavior

[Johnny Billquist]

Ah... And I need to correct myself.

Bob didn't say that the 11/23 didn't have an LTC. He said it didn't have 
a LTCR... So, in short, you cannot disable the LTC interrupt on the 
11/23. Interesting. Weird. Oh well. I can't find any reference to an 
LTCR in the documentation, so it would appear that this really is the case.
So, in order to run XXDP on an 11/23, you need to disable the LTC signal 
then.


So I correct myself - seems as if simh is doing it right.

Johnny

On 2015-12-30 13:50, Johnny Billquist wrote:

Well, Bob definitely nailed why it was halting when set to PDP-11/23
mode. The LTC is the problem, obviously.

However, I think simh is wrong in doing it this way. The KDF11-AA manual
clearly documents that the CPU do handle the BEVENT signal, and traps to
100, unless you remove W4, so why simh pretends that an 11/23 do not
have an LTC is beyond me.
(See
http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/dec/pdp11/1123/EK-KDF11-UG-PR2_Mar79.pdf,
page 2-2)

So, that has been cleared up. I'd say that simh is wrong in not having
an LTC for the 11/23, and once that is changed, XXDP will run fine on
the 11/23 both in real life and in simh.

Next, the question of supported versions - I do not have a list, and
tend to try and run the latest version. However, in this case I think we
can clearly say that the version of XXDP was not the issue. And in fact,
V2.2 did run fine on the real hardware (not sure if you mentioned that
on the list).

The problems you've seen with some other CPUs and controllers are a
separate issue. Not sure if we can easily figure that one out. Do you,
by any chance, have a real DEC MSCP controller and some disks, that you
could test with as well? It might be that there are some issues with
some CPUs related to MSCP that cause XXDP to fail, as well as bugs in
XXDP itself.

 Johnny

On 2015-12-30 11:42, Mattis Lind wrote:



2015-12-30 0:12 GMT+01:00 Bob Supnik >:

Regarding Mark Lind's post:


Mattis Lind, not Mark Lind.


It's a simple detective problem. Where does an 11/23 differ from an
11/23+?

If you look in pdp11_defs.h, F-11 based systems are grouped
together, and CPUT_F is used in most feature definitions.

#define CPUT_F  (CPUT_23|CPUT_23P|CPUT_24)  /* all
F11's */

There is only ONE place where an 11/23+ is called out as something
other than a generic F-11 CPU:

#define HAS_LTCR(CPUT_04|CPUT_05|CPUT_20|CPUT_23P|CPUT_24| \
  CPUT_34|CPUT_40|CPUT_44|CPUT_45|CPUT_60| \
  CPUT_70|CPUT_J)

That is, the 11/23+ and 11/24 have a line time clock register. The
11/23 DOES NOT.

When the TST @#172540 occurs, the PSW is set to 350 (IPL 6), locking
out any clock interrupts. The interrupt vector for NXM, however,
sets the PSW to 0. That means any pending line-time clock interrupt
will occur immediately.

On an 11/23+, the line time clock register initializes to interrupts
disabled. On the 11/23, though, there IS NO line time clock
register, and a clock interrupt is pending. As soon as the NXM trap
completes, an interrupt occurs through vector 100, which is set up
as follows:

100/102
102/0

So the PC is set to 102, which is a HALT instruction, and the
simulator halts, with the PC pointing at the next instruction.

Everything is behaving as it should. This version of XXDP was not
designed to run on an 11/23, and it runs on an 11/23+ by coincidence.


This is interesting. I have yet to find a comprehensive document that
tells what version of XXDP that run on what model.
This document http://www.dmv.net/dec/pdf/xxdpum.pdf on page  2-2 (26)
says 11/23 family is supported. This document seems to relate to V2.4

Now testing SimH with a (compressed) XXDP 2.5 and XXDP 2.2 image give
exactly the same result. Halt.
http://www.ibiblio.org/pub/academic/computer-science/history/pdp-11/xxdp/

I really think that it should be possible to run XXDP V2.2 and V2.2 on a
KDF11-A CPU.
Testing on real hardware shows that both KDF11-A and KDF11-B boots up
fine. If I enable LTC on a KDF11-A (have not tested on KDF11-B yet) it
will halt at the very same location.

So it has to do with LTC rather than model in my opinion. So how can I
disable LTC in SimH so that it acts like the LTC switch on the front
panel? "set clk disabled" give "Command not allowed"


Moral: don't run software on hardware models that it doesn't
support. And compress your disk images before posting them.


Please point me to some document that clearly states that XXDP 2.2 (and
2.5) is not possible to run on 11/23 and 11/23+. Second. Sorry about the
uncompressed image.

BTW: I have also tested this very same image on a real 11/04 and it does
boot to XXDP prompt (it does have DL11-W so LTC registers are there) .
But then it is unable to read the disk. Maybe the DU driver is not happy
with 

Re: [Simh] Strange PDP-11 behavior

[Bob Supnik]

Regarding Mark Lind's post:

It's a simple detective problem. Where does an 11/23 differ from an 11/23+?

If you look in pdp11_defs.h, F-11 based systems are grouped together, 
and CPUT_F is used in most feature definitions.


#define CPUT_F  (CPUT_23|CPUT_23P|CPUT_24)  /* all F11's */

There is only ONE place where an 11/23+ is called out as something other 
than a generic F-11 CPU:


#define HAS_LTCR(CPUT_04|CPUT_05|CPUT_20|CPUT_23P|CPUT_24| \
 CPUT_34|CPUT_40|CPUT_44|CPUT_45|CPUT_60| \
 CPUT_70|CPUT_J)

That is, the 11/23+ and 11/24 have a line time clock register. The 11/23 
DOES NOT.


When the TST @#172540 occurs, the PSW is set to 350 (IPL 6), locking out 
any clock interrupts. The interrupt vector for NXM, however, sets the 
PSW to 0. That means any pending line-time clock interrupt will occur 
immediately.


On an 11/23+, the line time clock register initializes to interrupts 
disabled. On the 11/23, though, there IS NO line time clock register, 
and a clock interrupt is pending. As soon as the NXM trap completes, an 
interrupt occurs through vector 100, which is set up as follows:


100/102
102/0

So the PC is set to 102, which is a HALT instruction, and the simulator 
halts, with the PC pointing at the next instruction.


Everything is behaving as it should. This version of XXDP was not 
designed to run on an 11/23, and it runs on an 11/23+ by coincidence.


Moral: don't run software on hardware models that it doesn't support. 
And compress your disk images before posting them.


/Bob Supnik

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh