KG11 emulation probably defective -->diagnostic ZKGAB0 for KG11 runs without complaints.
30 Jan
2022
30 Jan
'22
4:33 p.m.
L.S.
The diagnostics in XXDP for KG11 completes without problems, so far, so
good.
It limits the scope to interface problems between Decnet11MP and Simh KG11.
Reindert
-----Original Message-----
From: R. Voorhorst [mailto:R.Voorhorst@swabhawat.com]
Sent: Sunday, 30 January, 2022 16:18
To: 'The Hobbyist DECnet mailing list' <hecnet(a)lists.dfupdate.se>
Subject: [HECnet] Re: native Dup sync line revisited --> KG11 emulation
probably defective --> initial exploration
L.S.
Reviewing the code from J. Dundas reveals it passed a diagnostic ZKGAB0
which is a xxdp component. There are listings of maindecs, no sources and
the microfiche listing quality is quite low, so restoration of source code
is laborious at best. It also happens to be a component of Anf10 for Tops10
and any image has a quick check for the KG11 if configured to be present.
I think for now the chance that the KG11 itself is somehow corrupt is low
regarding the well specified design path followed in creation, so probably a
mismatch between Rsx11 software and the current KG11 implementation is more
probable cause. It also appears the KG11 was used in the Rsts corner for
Dup, Dp and Du and the Ibm 2780 interfaces.
The docs in simh KG11 does not reveal whether it was tested in a simulated
actual software system.
Lacking the diagnostics sources except Chk11.P11 which is very limited in
scope, XXDP might be the ultimate quickest way to test it.
Reindert
-----Original Message-----
From: R. Voorhorst [mailto:R.Voorhorst@swabhawat.com]
Sent: Sunday, 30 January, 2022 09:53
To: 'The Hobbyist DECnet mailing list' <hecnet(a)lists.dfupdate.se>
Subject: [HECnet] Re: native Dup sync line revisited --> revisited Dup test
on pdp11 --> KG11 emulation probably defective
Apart from morons with an incurable inclination to the complex difficult
thereby shooting in the own feet like me .... ?
I do not know, but I suppose on Rsx11 the serial async Decnet lines might
use KG11 assisted crc16 generation/checking as well and the problem might be
in Rsx11M software itself, less likely, or more likely in KG11 simulation.
Johnny might know this.
As I have done the KG8 I think I am more predisposed to look at the KG11
excepting the writer of the KG11 simulation, so I will check for the
existence of a diagnostic, will see what goes wrong and propose a fix.
KG11 is not a complex device.
Best regards,
Reindert
-----Original Message-----
From: Mark Pizzolato - Info Comm [mailto:Mark@infocomm.com]
Sent: Sunday, 30 January, 2022 01:26
To: R. Voorhorst <R.Voorhorst(a)swabhawat.com>om>; hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: native Dup sync line revisited --> revisited Dup test
on pdp11 --> problem solved: Simh KG11 emulation probably defective
On Saturday, January 29, 2022 at 4:04 PM, R. Voorhorst wrote:
L.S.
With a bit time on hand and the standstill after Paul's initial test
from dup to pydecnet which appeared to be successful, I now undertook
a test as Mark liked to have it preferably.
So I did a fresh netgen on a simple configuration from simple basic
install Rsx11MP system for only a Decnet end-node with one single Dup
line communicating to a known working Pdp11 Rsx11MP Dmc circuit.
I saw no difference from what I reported initially and later with
logging, as was to be expected; my complex setup behaves exactly the
same in this respect as it does for years in a complex network setup
for Rsx and Rsts, and
RT11 without network.
This is on a Windows-2008R2 server and I suspect Paul did his test on
unix/linux , however although it differs, that should be moot as far
as Simh is concerned.
There could be another difference though. Paul would probably have
taken the default route and used Ddcmp withouth KG11 support: Dup
without Kdp is the only sync line to use it, though async Decnet
DL/DZ/VH might use it as well.
As I prefer the most complex configs possible (any two of a kind where
possible as Dec used to have them), I do also employ the KG11, so for
Dup support it will be used when configured so in Decnet11MP.
On a sim it is not that effective, but in hardware in the past it did
make a difference for fast crc computing.
So I retested with no KG11 support and indeed, now the Dup works as
expected.
What appears to be strange is, that small packets up to 8 bytes are
not corrupted but the larger ones do. Maybe in Decnet11MP, the small
packets are totally preconfigured in the software program with crc
inclusive and the
KG11 is then bypassed effectively, bu, that should have to be
verified. At least the combination KG11 and Decnet11MP KG11 support is
defective.
So Simh Dup works in software Ddcmp packet generation, but the Simh
KG11 seem to generate bad checksums and/or checks.
For the Pdp8A, I have a functioning KG8 simulation that works in
Rts-8, so there is a test reference to fall back on.
So I admit and confirm that basic Dup in simh software wise between
Pdp11's and with various counterparts (DMC) indeed works, which would
make it serve as a base for other sync line implementations like DP8-E(A).
So, you've proven to yourself that the KG11 is at least somewhat broken.
Looking back at the change history for this device, I've made changes
relating to how it glues into the PDP11 I/O space, but nothing at all about
how the device actually functions.
What else uses this device?
Is there a diagnostic?
- Mark
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email
to hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email
to hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email
to hecnet-leave(a)lists.dfupdate.se
30 Jan
30 Jan
6:21 p.m.
New subject: KG11 emulation probably defective -->diagnostic ZKGAB0 for KG11 runs without complaints.
On Sunday, January 30, 2022 at 5:34 AM, Reindert wrote:
The diagnostics in XXDP for KG11 completes without
problems, so far, so good.
It limits the scope to interface problems between Decnet11MP and Simh KG11.
We really don't know how robust the diagnostic is and if it exercises the same
details that are used by the DDCMP implementation.
You could run the DDCMP case with KG11 debugging enabled and identify what it is doing
precisely and then go back and see if the diagnostic is doing the same stuff...
- Mark
-----Original Message-----
From: R. Voorhorst [mailto:R.Voorhorst@swabhawat.com]
Sent: Sunday, 30 January, 2022 16:18
To: 'The Hobbyist DECnet mailing list' <hecnet(a)lists.dfupdate.se>
Subject: [HECnet] Re: native Dup sync line revisited --> KG11 emulation probably
defective --> initial exploration
L.S.
Reviewing the code from J. Dundas reveals it passed a diagnostic ZKGAB0 which
is a xxdp component. There are listings of maindecs, no sources and the
microfiche listing quality is quite low, so restoration of source code is laborious
at best. It also happens to be a component of Anf10 for Tops10 and any image
has a quick check for the KG11 if configured to be present.
I think for now the chance that the KG11 itself is somehow corrupt is low
regarding the well specified design path followed in creation, so probably a
mismatch between Rsx11 software and the current KG11 implementation is
more probable cause. It also appears the KG11 was used in the Rsts corner for
Dup, Dp and Du and the Ibm 2780 interfaces.
The docs in simh KG11 does not reveal whether it was tested in a simulated
actual software system.
Lacking the diagnostics sources except Chk11.P11 which is very limited in scope,
XXDP might be the ultimate quickest way to test it.
Reindert
-----Original Message-----
From: R. Voorhorst [mailto:R.Voorhorst@swabhawat.com]
Sent: Sunday, 30 January, 2022 09:53
To: 'The Hobbyist DECnet mailing list' <hecnet(a)lists.dfupdate.se>
Subject: [HECnet] Re: native Dup sync line revisited --> revisited Dup test on
pdp11 --> KG11 emulation probably defective
Apart from morons with an incurable inclination to the complex difficult thereby
shooting in the own feet like me .... ?
I do not know, but I suppose on Rsx11 the serial async Decnet lines might use
KG11 assisted crc16 generation/checking as well and the problem might be in
Rsx11M software itself, less likely, or more likely in KG11 simulation.
Johnny might know this.
As I have done the KG8 I think I am more predisposed to look at the KG11
excepting the writer of the KG11 simulation, so I will check for the existence of a
diagnostic, will see what goes wrong and propose a fix.
KG11 is not a complex device.
Best regards,
Reindert
-----Original Message-----
From: Mark Pizzolato - Info Comm [mailto:Mark@infocomm.com]
Sent: Sunday, 30 January, 2022 01:26
To: R. Voorhorst <R.Voorhorst(a)swabhawat.com>om>; hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: native Dup sync line revisited --> revisited Dup test on
pdp11 --> problem solved: Simh KG11 emulation probably defective
On Saturday, January 29, 2022 at 4:04 PM, R. Voorhorst wrote:
L.S.
With a bit time on hand and the standstill after Paul's initial test
from dup to pydecnet which appeared to be successful, I now undertook
a test as Mark liked to have it preferably.
So I did a fresh netgen on a simple configuration from simple basic
install Rsx11MP system for only a Decnet end-node with one single Dup
line communicating to a known working Pdp11 Rsx11MP Dmc circuit.
I saw no difference from what I reported initially and later with
logging, as was to be expected; my complex setup behaves exactly the
same in this respect as it does for years in a complex network setup
for Rsx and Rsts, and
RT11 without network.
This is on a Windows-2008R2 server and I suspect Paul did his test on
unix/linux , however although it differs, that should be moot as far
as Simh is concerned.
There could be another difference though. Paul would probably have
taken the default route and used Ddcmp withouth KG11 support: Dup
without Kdp is the only sync line to use it, though async Decnet
DL/DZ/VH might use it as well.
As I prefer the most complex configs possible (any two of a kind where
possible as Dec used to have them), I do also employ the KG11, so for
Dup support it will be used when configured so in Decnet11MP.
On a sim it is not that effective, but in hardware in the past it did
make a difference for fast crc computing.
So I retested with no KG11 support and indeed, now the Dup works as
expected.
What appears to be strange is, that small packets up to 8 bytes are
not corrupted but the larger ones do. Maybe in Decnet11MP, the small
packets are totally preconfigured in the software program with crc
inclusive and the
KG11 is then bypassed effectively, bu, that should have to be
verified. At least the combination KG11 and Decnet11MP KG11 support is
defective.
So Simh Dup works in software Ddcmp packet generation, but the Simh
KG11 seem to generate bad checksums and/or checks.
For the Pdp8A, I have a functioning KG8 simulation that works in
Rts-8, so there is a test reference to fall back on.
So I admit and confirm that basic Dup in simh software wise between
Pdp11's and with various counterparts (DMC) indeed works, which would
make it serve as a base for other sync line implementations like DP8-E(A).
So, you've proven to yourself that the KG11 is at least somewhat broken.
Looking back at the change history for this device, I've made changes relating to
how it glues into the PDP11 I/O space, but nothing at all about how the device
actually functions.
What else uses this device?
Is there a diagnostic?
- Mark
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to
hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to
hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to
hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to
hecnet-leave(a)lists.dfupdate.se 
6:24 p.m.
On 1/30/22 12:21 PM, Mark Pizzolato - Info Comm wrote:
On Sunday, January 30, 2022 at 5:34 AM, Reindert
wrote:
I have a KG11-A board; if it would be helpful, I can install it in a
PDP-11 at LSSM perhaps this week.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
The diagnostics in XXDP for KG11 completes
without problems, so far, so good.
It limits the scope to interface problems between Decnet11MP and Simh KG11.
We really don't know how robust the diagnostic is and if it exercises the same
details that are used by the DDCMP implementation.
You could run the DDCMP case with KG11 debugging enabled and identify what it is doing
precisely and then go back and see if the diagnostic is doing the same stuff...
31 Jan
31 Jan
1:51 a.m.
@Dave:
It would only be worth the time and energy to prove if current Decnet11MP in
combination with KG11 would work in a Dup to Dup or Dmc connection, which in
hardware take a serious effort.
In virtual reality it is far more easy to arrange such things.
Unless I cannot find a bug quickly enough, then it could be helpful to
request you to check on it.
Thanks though for the time being.
Reindert
-----Original Message-----
From: Dave McGuire [mailto:mcguire@neurotica.com]
Sent: Sunday, 30 January, 2022 18:25
To: The Hobbyist DECnet mailing list <hecnet(a)lists.dfupdate.se>
Subject: [HECnet] Re: KG11 emulation probably defective -->diagnostic ZKGAB0
for KG11 runs without complaints.
On 1/30/22 12:21 PM, Mark Pizzolato - Info Comm wrote:
On Sunday, January 30, 2022 at 5:34 AM, Reindert
wrote:
> The diagnostics in XXDP for KG11 completes without problems, so far, so
good.
> It limits the scope to interface problems between
Decnet11MP and Simh
KG11.
We really don't know how robust the diagnostic is and if it exercises
the same details that are used by the DDCMP implementation.
You could run the DDCMP case with KG11 debugging enabled and identify what
it is
doing precisely and then go back and see if the diagnostic is doing
the same stuff...
I have a KG11-A board; if it would be helpful, I can install it in a
PDP-11 at LSSM perhaps this week.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email
to hecnet-leave(a)lists.dfupdate.se
2:25 a.m.
Yes, I was thinking that, if you got stuck, you could write a program
that I could run on a machine with a KG11 and send you back the results,
or arrange for remote access to the machine. The option is available
should you need it, just let me know.
-Dave
On 1/30/22 7:51 PM, R. Voorhorst wrote:
@Dave:
It would only be worth the time and energy to prove if current Decnet11MP in
combination with KG11 would work in a Dup to Dup or Dmc connection, which in
hardware take a serious effort.
In virtual reality it is far more easy to arrange such things.
Unless I cannot find a bug quickly enough, then it could be helpful to
request you to check on it.
Thanks though for the time being.
Reindert
-----Original Message-----
From: Dave McGuire [mailto:mcguire@neurotica.com]
Sent: Sunday, 30 January, 2022 18:25
To: The Hobbyist DECnet mailing list <hecnet(a)lists.dfupdate.se>
Subject: [HECnet] Re: KG11 emulation probably defective -->diagnostic ZKGAB0
for KG11 runs without complaints.
On 1/30/22 12:21 PM, Mark Pizzolato - Info Comm wrote:
--
Dave McGuire, AK4HZ
New Kensington, PA
On Sunday, January 30, 2022 at 5:34 AM, Reindert
wrote:
> The diagnostics in XXDP for KG11 completes without problems, so far, so
good.
> It limits the scope to interface problems
between Decnet11MP and Simh
KG11.
We really don't know how robust the diagnostic is and if it exercises
the same details that are used by the DDCMP implementation.
You could run the DDCMP case with KG11 debugging enabled and identify what
it is
doing precisely and then go back and see if the diagnostic is doing
the same stuff...
I have a KG11-A board; if it would be helpful, I can install it in a
PDP-11 at LSSM perhaps this week.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email
to hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
8:14 a.m.
I agree that it would be nice to confirm that this works in real
hardware, but I also find it unlikely that it wouldn't.
While DEC was not perfect, I would expect that they actually had tested
this before releasing the software.
Johnny
On 2022-01-31 01:51, R. Voorhorst wrote:
@Dave:
It would only be worth the time and energy to prove if current Decnet11MP in
combination with KG11 would work in a Dup to Dup or Dmc connection, which in
hardware take a serious effort.
In virtual reality it is far more easy to arrange such things.
Unless I cannot find a bug quickly enough, then it could be helpful to
request you to check on it.
Thanks though for the time being.
Reindert
-----Original Message-----
From: Dave McGuire [mailto:mcguire@neurotica.com]
Sent: Sunday, 30 January, 2022 18:25
To: The Hobbyist DECnet mailing list <hecnet(a)lists.dfupdate.se>
Subject: [HECnet] Re: KG11 emulation probably defective -->diagnostic ZKGAB0
for KG11 runs without complaints.
On 1/30/22 12:21 PM, Mark Pizzolato - Info Comm wrote:
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Sunday, January 30, 2022 at 5:34 AM, Reindert
wrote:
> The diagnostics in XXDP for KG11 completes without problems, so far, so
good.
> It limits the scope to interface problems
between Decnet11MP and Simh
KG11.
We really don't know how robust the diagnostic is and if it exercises
the same details that are used by the DDCMP implementation.
You could run the DDCMP case with KG11 debugging enabled and identify what
it is
doing precisely and then go back and see if the diagnostic is doing
the same stuff...
I have a KG11-A board; if it would be helpful, I can install it in a
PDP-11 at LSSM perhaps this week.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email
to hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
4:14 p.m.
By offering to set up real KG11 hardware, my intention was not to
verify that the DEC software works. I think we all know that it works.
My intention was to offer a testbed for "poking and prodding" to debug
the KG11 emulation that seems to be causing difficulty.
-Dave
On 1/31/22 2:14 AM, Johnny Billquist wrote:
I agree that it would be nice to confirm that this
works in real
hardware, but I also find it unlikely that it wouldn't.
While DEC was not perfect, I would expect that they actually had tested
this before releasing the software.
Johnny
On 2022-01-31 01:51, R. Voorhorst wrote:
--
Dave McGuire, AK4HZ
New Kensington, PA
@Dave:
It would only be worth the time and energy to prove if current
Decnet11MP in
combination with KG11 would work in a Dup to Dup or Dmc connection,
which in
hardware take a serious effort.
In virtual reality it is far more easy to arrange such things.
Unless I cannot find a bug quickly enough, then it could be helpful to
request you to check on it.
Thanks though for the time being.
Reindert
-----Original Message-----
From: Dave McGuire [mailto:mcguire@neurotica.com]
Sent: Sunday, 30 January, 2022 18:25
To: The Hobbyist DECnet mailing list <hecnet(a)lists.dfupdate.se>
Subject: [HECnet] Re: KG11 emulation probably defective -->diagnostic
ZKGAB0
for KG11 runs without complaints.
On 1/30/22 12:21 PM, Mark Pizzolato - Info Comm wrote:
On Sunday, January 30, 2022 at 5:34 AM, Reindert
wrote:
> The diagnostics in XXDP for KG11 completes without problems, so far, so
good.
> It limits the scope to interface problems
between Decnet11MP and Simh
KG11.
We really don't know how robust the diagnostic is and if it exercises
the same details that are used by the DDCMP implementation.
You could run the DDCMP case with KG11 debugging enabled and identify
what
it is doing precisely and then go back and see if the diagnostic is doing
the same stuff...
I have a KG11-A board; if it would be helpful, I can install it in a
PDP-11 at LSSM perhaps this week.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an
email
to hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se 
6:57 p.m.
On Jan 31, 2022, at 10:14 AM, Dave McGuire
<mcguire(a)neurotica.com> wrote:
By offering to set up real KG11 hardware, my intention was not to verify that the DEC
software works. I think we all know that it works. My intention was to offer a testbed
for "poking and prodding" to debug the KG11 emulation that seems to be causing
difficulty.
-Dave
Certainly a good idea. I think the starting point is a SIMH debug trace of a situation
where the wrong answer is produced. As I understand it Reindert has a setup that will do
this. The KG-11 is a simple enough device that the mistake may well be obvious by
inspection given a trace that shows a broken case.
Another possibility if it's not so obvious is to convert the schematics into a VHDL
model. It could even be coupled to SIMH if one were to run it in GHDL.
paul
6:49 p.m.
I think you're probably right, but I have had some experience that maybe
indicates otherwise. Possibly.
When I was working on my extended mode FTP server, I used a string
instruction (MOVLJ) to move some data between sections. Since I was
moving a rather large 256KW buffer, it made sense to do this instead of
sitting in an ILDB/IDPB loop (assuming I couldn't win big with an XBLT).
The eventual goal was to do some automatic nice things by using a
translate table to compute parity via an MOVST with different size bytes.
It worked fine under KLH10 yet when I ran it on a Toad, it blew up.
What I mean is that parts of the address space got destroyed. For days
I couldn't figure it out. Finally, I signed on to a real KL and
executed the same code, which worked. This indicated a bug in the XKL
firmware, which R. Gorin acknowledge. Had it not worked on the KL, the
problem would have been in either the KLH10 micro-engine or my code.
Perhaps this is the exception that proves the rule?
On 1/31/22 2:14 AM, Johnny Billquist wrote:
I agree that it would be nice to confirm that this
works in real
hardware, but I also find it unlikely that it wouldn't.
While DEC was not perfect, I would expect that they actually had
tested this before releasing the software.
Johnny
On 2022-01-31 01:51, R. Voorhorst wrote:
@Dave:
It would only be worth the time and energy to prove if current
Decnet11MP in
combination with KG11 would work in a Dup to Dup or Dmc connection,
which in
hardware take a serious effort.
In virtual reality it is far more easy to arrange such things.
Unless I cannot find a bug quickly enough, then it could be helpful to
request you to check on it.
Thanks though for the time being.
Reindert
-----Original Message-----
From: Dave McGuire [mailto:mcguire@neurotica.com]
Sent: Sunday, 30 January, 2022 18:25
To: The Hobbyist DECnet mailing list <hecnet(a)lists.dfupdate.se>
Subject: [HECnet] Re: KG11 emulation probably defective -->diagnostic
ZKGAB0
for KG11 runs without complaints.
On 1/30/22 12:21 PM, Mark Pizzolato - Info Comm wrote:
On Sunday, January 30, 2022 at 5:34 AM, Reindert
wrote:
> The diagnostics in XXDP for KG11 completes without problems, so
> far, so
good.
> It limits the scope to interface problems
between Decnet11MP and Simh
KG11.
We really don't know how robust the diagnostic is and if it exercises
the same details that are used by the DDCMP implementation.
You could run the DDCMP case with KG11 debugging enabled and
identify what
it is doing precisely and then go back and see if the diagnostic is
doing
the same stuff...
I have a KG11-A board; if it would be helpful, I can install it in a
PDP-11 at LSSM perhaps this week.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send
an email
to hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
7:10 p.m.
Well, in this case it's a piece of hardware that have existed since
(almost) forever, and have not changed since, and if enabled, is used a
lot. I have a hard time believing it wouldn't work without it being noticed.
But yeah, the kind of error you mentioned are fun. There is a weird
microcode bug in the 11/60 CPU, which force the OS do so some silly
things in general, in order to run correctly one that one CPU. Things
that are just wasting a few cycles on all other CPUs. I bet DEC had fun
figuring that one out...
(I don't remember the exact details now, but I could go in and read the
code to find out again, if needed, unless someone else remember the
specifics.)
Johnny
On 2022-01-31 18:49, Thomas DeBellis wrote:
I think you're probably right, but I have had some
experience that maybe
indicates otherwise. Possibly.
When I was working on my extended mode FTP server, I used a string
instruction (MOVLJ) to move some data between sections. Since I was
moving a rather large 256KW buffer, it made sense to do this instead of
sitting in an ILDB/IDPB loop (assuming I couldn't win big with an XBLT).
The eventual goal was to do some automatic nice things by using a
translate table to compute parity via an MOVST with different size bytes.
It worked fine under KLH10 yet when I ran it on a Toad, it blew up.
What I mean is that parts of the address space got destroyed. For days
I couldn't figure it out. Finally, I signed on to a real KL and
executed the same code, which worked. This indicated a bug in the XKL
firmware, which R. Gorin acknowledge. Had it not worked on the KL, the
problem would have been in either the KLH10 micro-engine or my code.
Perhaps this is the exception that proves the rule?
On 1/31/22 2:14 AM, Johnny Billquist wrote:
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
I agree that it would be nice to confirm that
this works in real
hardware, but I also find it unlikely that it wouldn't.
While DEC was not perfect, I would expect that they actually had
tested this before releasing the software.
Johnny
On 2022-01-31 01:51, R. Voorhorst wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se @Dave:
It would only be worth the time and energy to prove if current
Decnet11MP in
combination with KG11 would work in a Dup to Dup or Dmc connection,
which in
hardware take a serious effort.
In virtual reality it is far more easy to arrange such things.
Unless I cannot find a bug quickly enough, then it could be helpful to
request you to check on it.
Thanks though for the time being.
Reindert
-----Original Message-----
From: Dave McGuire [mailto:mcguire@neurotica.com]
Sent: Sunday, 30 January, 2022 18:25
To: The Hobbyist DECnet mailing list <hecnet(a)lists.dfupdate.se>
Subject: [HECnet] Re: KG11 emulation probably defective -->diagnostic
ZKGAB0
for KG11 runs without complaints.
On 1/30/22 12:21 PM, Mark Pizzolato - Info Comm wrote:
On Sunday, January 30, 2022 at 5:34 AM, Reindert
wrote:
> The diagnostics in XXDP for KG11 completes without problems, so
> far, so
good.
> It limits the scope to interface problems
between Decnet11MP and Simh
KG11.
We really don't know how robust the diagnostic is and if it exercises
the same details that are used by the DDCMP implementation.
You could run the DDCMP case with KG11 debugging enabled and
identify what
it is doing precisely and then go back and see if the diagnostic is
doing
the same stuff...
I have a KG11-A board; if it would be helpful, I can install it in a
PDP-11 at LSSM perhaps this week.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send
an email
to hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
7:34 p.m.
On Jan 31, 2022, at 1:10 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
Well, in this case it's a piece of hardware that have existed since (almost) forever,
and have not changed since, and if enabled, is used a lot. I have a hard time believing it
wouldn't work without it being noticed.
But yeah, the kind of error you mentioned are fun. There is a weird microcode bug in the
11/60 CPU, which force the OS do so some silly things in general, in order to run
correctly one that one CPU. Things that are just wasting a few cycles on all other CPUs. I
bet DEC had fun figuring that one out...
(I don't remember the exact details now, but I could go in and read the code to find
out again, if needed, unless someone else remember the specifics.)
The RSTS initialization code has a check for an 11/60 bug where, judging from the test,
writing to the CPU Error Register would cause the next word to be skipped. If your 11/60
does that you get a message reporting missing ECOs:
This PDP-11/60 is missing the following ECO's:
Module M7872: ECO #7 Module M7873: ECO #6
There's also a check somewhat earlier that says a "cache sweep" is needed
before enabling the cache on an 11/60, but not on any other machine. That seems to be
what is commonly called a "cache invalidate"; it appears in the memory parity
handler.
RSTS actually has a bunch of checks like the one above, looking for various bugs in
assorted processors and peripherals. Sometimes it would work around a missing ECO; in
other cases it would reject the device entirely, or refuse to run at all. In any case it
would identify precisely what ECO was missing, so the fix would be easy to apply.
paul
30 Jan
30 Jan
7:55 p.m.
New subject: KG11 emulation probably defective -->diagnostic ZKGAB0 for KG11 runs without complaints.
On Jan 30, 2022, at 12:21 PM, Mark Pizzolato - Info
Comm <Mark(a)infocomm.com> wrote:
On Sunday, January 30, 2022 at 5:34 AM, Reindert wrote:
CRC is both straightforward and tricky, so it would not be too strange to have bugs here.
Capturing a SIMH debug trace for the KG device would potentially be informative. The
diagnostic might be the easiest one to capture.
FWIW, PyDECnet has a universal CRC implementation that can be useful as a reference
implementation. The unit test script (tests/test_crc.py) shows test runs for every CRC I
have seen described, including lots of extremely obscure ones.
paul
The diagnostics in XXDP for KG11 completes
without problems, so far, so good.
It limits the scope to interface problems between Decnet11MP and Simh KG11.
We really don't know how robust the diagnostic is and if it exercises the same
details that are used by the DDCMP implementation.
You could run the DDCMP case with KG11 debugging enabled and identify what it is doing
precisely and then go back and see if the diagnostic is doing the same stuff...
8:51 p.m.
New subject: KG11 emulation probably defective -->diagnostic ZKGAB0 for KG11 runs without complaints.
The diagnostic may indeed be easy to capture, but it doesn’t demonstrate the failure. ☹
From: Paul Koning <paulkoning(a)comcast.net>
Sent: Sunday, January 30, 2022 8:55 AM
To: HECnet <hecnet(a)lists.dfupdate.se>
Subject: [HECnet] Re: KG11 emulation probably defective -->diagnostic ZKGAB0 for KG11
runs without complaints.
On Jan 30, 2022, at 12:21 PM, Mark Pizzolato - Info Comm
<Mark@infocomm.com<mailto:Mark@infocomm.com>> wrote:
On Sunday, January 30, 2022 at 5:34 AM, Reindert wrote:
The diagnostics in XXDP for KG11 completes without problems, so far, so good.
It limits the scope to interface problems between Decnet11MP and Simh KG11.
We really don't know how robust the diagnostic is and if it exercises the same
details that are used by the DDCMP implementation.
You could run the DDCMP case with KG11 debugging enabled and identify what it is doing
precisely and then go back and see if the diagnostic is doing the same stuff...
CRC is both straightforward and tricky, so it would not be too strange to have bugs here.
Capturing a SIMH debug trace for the KG device would potentially be informative. The
diagnostic might be the easiest one to capture.
FWIW, PyDECnet has a universal CRC implementation that can be useful as a reference
implementation. The unit test script (tests/test_crc.py) shows test runs for every CRC I
have seen described, including lots of extremely obscure ones.
paul
11:18 p.m.
New subject: KG11 emulation probably defective -->diagnostic ZKGAB0 for KG11 runs without complaints.
☹ or :) , whatever … we’ll find something
From: Mark Pizzolato - Info Comm [mailto:Mark@infocomm.com]
Sent: Sunday, 30 January, 2022 20:51
To: The Hobbyist DECnet mailing list <hecnet(a)lists.dfupdate.se>
Subject: [HECnet] Re: KG11 emulation probably defective -->diagnostic ZKGAB0 for KG11
runs without complaints.
The diagnostic may indeed be easy to capture, but it doesn’t demonstrate the failure. ☹
From: Paul Koning <paulkoning(a)comcast.net <mailto:paulkoning@comcast.net> >
Sent: Sunday, January 30, 2022 8:55 AM
To: HECnet <hecnet(a)lists.dfupdate.se <mailto:hecnet@lists.dfupdate.se> >
Subject: [HECnet] Re: KG11 emulation probably defective -->diagnostic ZKGAB0 for KG11
runs without complaints.
On Jan 30, 2022, at 12:21 PM, Mark Pizzolato - Info Comm <Mark(a)infocomm.com
<mailto:Mark@infocomm.com> > wrote:
On Sunday, January 30, 2022 at 5:34 AM, Reindert wrote:
The diagnostics in XXDP for KG11 completes without problems, so far, so good.
It limits the scope to interface problems between Decnet11MP and Simh KG11.
We really don't know how robust the diagnostic is and if it exercises the same
details that are used by the DDCMP implementation.
You could run the DDCMP case with KG11 debugging enabled and identify what it is doing
precisely and then go back and see if the diagnostic is doing the same stuff...
CRC is both straightforward and tricky, so it would not be too strange to have bugs here.
Capturing a SIMH debug trace for the KG device would potentially be informative. The
diagnostic might be the easiest one to capture.
FWIW, PyDECnet has a universal CRC implementation that can be useful as a reference
implementation. The unit test script (tests/test_crc.py) shows test runs for every CRC I
have seen described, including lots of extremely obscure ones.
paul
819
days inactive
820
days old
13 comments
6 participants
participants (6)
-
Dave McGuire -
Johnny Billquist -
Mark Pizzolato - Info Comm -
Paul Koning -
R. Voorhorst -
Thomas DeBellis