I thought some of the HECnet crowd might find this interesting
https://groups.google.com/g/alt.sys.pdp10/c/WnsETCDyTmc
"TOPS-20 Boot Camp for VMS Users 05-Mar-2022" (that's this Saturday), and
they'll even give you an account on a real (not simulated!) 36 bit machine,
an XKL Toad.
Bob
Seems to not work anymore. Not sure if it is permanent. But anyway, for
anyone wanting to reach Mim, as has been announced before, she's still
available as Mim.Stupi.NET.
Johnny
--
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
Hello Everyone,
Are there any Mailman experts here?
The way I use my email addresses is that I have an email address provided by
my ISP (Robert.jarratt(a)ntlworld.com <mailto:Robert.jarratt@ntlworld.com> ),
but I use an email forwarding service to forward rob(a)jarratt.me.uk
<mailto:rob@jarratt.me.uk> to my ISP mailbox. This means that I can receive
email sent to rob(a)jarratt.me.uk <mailto:rob@jarratt.me.uk> , but any email I
send comes from Robert.jarratt(a)ntlworld.com
<mailto:Robert.jarratt@ntlworld.com> . I do put rob(a)jarratt.me.uk
<mailto:rob@jarratt.me.uk> in the reply-to. Can Mailman be configured to
accept emails from my outbound address, but send them to my forwarding
address? I would like to do this for my subscription to the HECnet list, if
possible. If I can't then so be it, but I thought it worth asking.
Thanks
Rob
Hello Johnny,
I am not sure if I did get two copies of this email so I don't know if I am
on the new system. I don't remember what email I would be registered under,
it will either be rob(a)jarratt.me.uk (preferred) or
Robert.jarratt(a)ntlworld.com. I don't want to create an account to manage
myself until I know which email (if any) I am registered with in the new
system.
Would you mind checking for me please?
Thanks
Rob
> -----Original Message-----
> From: Johnny Billquist <bqt(a)softjar.se>
> Sent: 21 January 2022 01:10
> To: hecnet(a)lists.dfupdate.se; hecnet(a)Update.UU.SE
> Subject: [Hecnet] HECnet mail list move
>
> Ok. Since I'm a busy (and lazy) bum, this have taken way more time that it
> should have.
>
> But here it is. The HECnet mailing list is moving. It has to.
> First of all, hats off, thanks, and apologies to Bob Armstrong and Dave
> McGuire. They both offered to help move the mailing list, and put time
into
> it. Unfortunately, I've not had time to really work on it, and in the end
the
> people at Update also worked on migrating all other stuff that was running
> there, which included various other mailing lists as well, so the HECnet
> mailing list was more or less able to be moved without any work on my
part,
> except for some tweaks to settings.
>
> So while much of Update is, for the time being, turned off, the mailing
list can
> live on.
>
> The address do change, however. As you can see. The new address is:
>
> hecnet(a)lists.dfupdate.se
>
> This is now running under mailman, which do mean that there is a web
> interface for people to control their subscriptions, as well as the
possibility of
> digests and archives going forward.
>
> All current subscribers are already subscribed at the new address. If
anyone
> disagrees with that, they can unsubscribe, or let me know and I'll
unsubscribe
> them.
>
> I'm sending this mail to both the old and new list, so everyone should get
two
> copies of this mail. If you are not, check possible spam boxes, and let me
> know if I should investigate something on my side.
>
> The web page for the list is:
> https://lists.dfupdate.se/postorius/lists/hecnet.lists.dfupdate.se/
> (I think I got that right, let me know otherwise)
>
> Johnny
>
> --
> 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
> _______________________________________________
> Hecnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an
email
> to hecnet-leave(a)lists.dfupdate.se
Johnny;
I would be interested in hearing more about this (or any) 11/60 microcode
bug :->! And how the OS (which?) worked around it.
>>> Subject: [HECnet] Re: KG11 emulation probably defective
-->diagnosticZKGAB0for KG11 runs without complaints.
.....
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
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se <mailto:bqt@softjar.se> || Reading
murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
<mailto:hecnet@lists.dfupdate.se> To unsubscribe send an email to
hecnet-leave(a)lists.dfupdate.se <mailto:hecnet-leave@lists.dfupdate.se>
A friend of mine has a bunch of hardware that needs a new home. No charge,
but it has to be picked up in Zoetermeer, The Netherlands.
He asked me to post it here, if you are interested I will get him to contact
you.
Rgds,
Wilm
Servers
* AlphaServer 1000A
* Power supply defect, stops 1 sec after sdtartup
* Status unknown
* DEC 2000 Model 300 AXP, aka DECpcAXP150, aka Jensen
* working (front panel damaged)
* Internal disk RZ28B (2.1 G)
* Internal disk RZ26L (1.05 G)
* RRD44 CD drive
* RX26 floppy drive, not working
Storage Shelves
* 2x BA356-RC (blue)
* 1x BA356-SB (beige)
* 5x Power supply
* 2x I/O module BA35X-MH (70-31490-01)
* 1x I/O module BA35X-MG
* 1x BN21W-0B Y-connector
Disks
* 6x RZ1FC-VW (36.4 G)
* 4x RZ1ED/EF-VW (18.2 G)
* 3x RZ1DA/DB-VW (9.1 G)
* 11x RZ1CB/CF-VW (4.3 G)
* 4x RZ29B-VA/VW (4.3 G)
* 2x RZ28-VA (2.1 G)
Tape Drives
* 1x TZ89, rack mount
* 2x TZ88 rack mount
Actually, the wiring is slightly more complex as the counter is reset by the
bus init signal on the clr inputs, however the load signal presets the
counter to a value depending on the selected polynomial.
The counting in hardware is even more complex as the counter is a 1 bit
binary counter combined with a 3 bit binary counter to cover the range from
8 to 12 to 16 steps clocking and varying between 10 Mhz and single stepping
to develop the Done flag setting which freezes the clock generator which is
a gated oscillator.
But since the implementation of Simh does not follow the hardware but only
replaces it with a functional equivalent, the software counting is
implemented differently and then it suffices to clear the pulsecnt variable
per the second proposed solution.
Reindert
-----Original Message-----
From: Paul Koning [mailto:paulkoning@comcast.net]
Sent: Wednesday, 02 February, 2022 15:44
To: Reindert Voorhorst <R.Voorhorst(a)swabhawat.com>
Cc: HECnet <hecnet(a)lists.dfupdate.se>
Subject: Re: [HECnet] KG11 emulation probably defective -->solved (by Paul
as it is)
> On Feb 2, 2022, at 4:09 AM, R. Voorhorst <R.Voorhorst(a)swabhawat.com>
wrote:
>
> L.S.
>
> So in the end I had little to do J (thanks Paul and Johnny), and the
updated code by Paul fixes the problem and yes, the diagnostics still
complete without complaint. A check of the engineering drawings should
verify/confirm how the pulse count is actually terminated/reset in hardware.
From the manual (which reproduces a bit of the schematic in support) the
more precise definition is that the counter is reset by a data register
load. That would make a difference in observable behavior if single step
mode is used: DONE would come on after the correct number of single step
operations.
I'll submit a PR with that version. Thanks Reindert for verifying the fix.
paul
I've put the beta PyDECnet T1.1 up on area router PYTHON. That will make a more interesting test than the previous one (which was to have it running on 28NH, the HECnet mapper).
It seems to be working ok, but if anyone sees strange behavior that might be connected to this node, please let me know.
The code should be faster, significantly so in a few spots. I suspect that won't be all that noticeable in practice. It should also have some bugs fixed. Among them are some NICE protocol issues: there were problems with reporting adjacent node information some of the time, those should be gone in this code.
paul
L.S.
As the proposed fix by Paul is now in line with the hardware in the
drawings, but differs from the initial one he proposed and I tested, I
retested it with diagnostics XXDP:ZKGAB0 and real time behaviour and that
works as well.
Reindert
-----Original Message-----
From: Paul Koning [mailto:paulkoning@comcast.net]
Sent: Wednesday, 02 February, 2022 15:44
To: Reindert Voorhorst <R.Voorhorst(a)swabhawat.com>
Cc: HECnet <hecnet(a)lists.dfupdate.se>
Subject: [HECnet] Re: KG11 emulation probably defective -->solved (by Paul
as it is)
> On Feb 2, 2022, at 4:09 AM, R. Voorhorst <R.Voorhorst(a)swabhawat.com>
wrote:
>
> L.S.
>
> So in the end I had little to do J (thanks Paul and Johnny), and the
updated code by Paul fixes the problem and yes, the diagnostics still
complete without complaint. A check of the engineering drawings should
verify/confirm how the pulse count is actually terminated/reset in hardware.
From the manual (which reproduces a bit of the schematic in support) the
more precise definition is that the counter is reset by a data register
load. That would make a difference in observable behavior if single step
mode is used: DONE would come on after the correct number of single step
operations.
I'll submit a PR with that version. Thanks Reindert for verifying the fix.
paul
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email
to hecnet-leave(a)lists.dfupdate.se
L.S.
So in the end I had little to do :) (thanks Paul and Johnny), and the
updated code by Paul fixes the problem and yes, the diagnostics still
complete without complaint. A check of the engineering drawings should
verify/confirm how the pulse count is actually terminated/reset in hardware.
Johnny confirmed with the code analysis the suspicion that KG11 was
sparingly used and the bulk crc processing was probably offloaded to either
Decnet11MP software or even the Dup11 hardware crc processing capabilities,.
That makes the use of the one KG11 needed quite superfluous. It is only used
for transmission header checking so it is interesting to see how it
functions with async Decnet lines.
Second is how this error in the header check propagates to a crc check of
the data-body processed elsewhere, but both crc errors disappear with the
fix.
@Mark: do you need the another serving of the solution by Paul:
static void do_poly (int unit, t_bool step) {
if (kg_unit[unit].SR & KGSR_M_DONE)
return;
if (step)
cycleOneBit (unit);
else {
while (!(kg_unit[unit].SR & KGSR_M_DONE))
cycleOneBit (unit);
kg_unit[unit].PULSCNT = 0; /* *** ADDED *** */
}
}
You can attribute the solution to Paul if attribution is in order as he
ultimately found it.
Best regards,
Reindert
-----Original Message-----
From: Paul Koning [mailto:paulkoning@comcast.net]
Sent: Wednesday, 02 February, 2022 02:26
To: HECnet <hecnet(a)lists.dfupdate.se>
Subject: [HECnet] Re: KG11 emulation probably defective -->some first
results
> On Feb 1, 2022, at 7:27 PM, Johnny Billquist < <mailto:bqt@softjar.se>
bqt(a)softjar.se> wrote:
>
> By the way, I do agree that it looks like you spotted the problem, in
> that the KG11 seems to just do a single cycle when it should process a
> word. Now you just need to figure out why it goes wrong in that way.
> :-)
>
> Johnny
I think I see the problem, but how the KG11 diagnostic can pass at all is
quite beyond comprehension.
In the data register write, the emulation clears the DONE flag, then if SEN
(shift enable) is set, it begins the checksum update. In normal mode (not
single step) it loops on the "do a step" operation until DONE is set again.
So far so good.
How does DONE get set? In function cycleOneBit, an internal counter PULSCNT
is compared with the count that belongs to the currently configured mode: 6,
8, 12 or 16 depending on the polynomial. When PULSCNT reaches the limit
(more precisely, when it is >= the limit) DONE is set.
The trouble is that PULSCNT is cleared only by reset and by status register
write. It is NOT reset at the end of a normal byte or word operation. That
means that every operation after the first one will only do one bit, unless
the host writes SR after each byte or word.
The solution seems to be to add a clear of PULSCNT after a byte or word has
been consumed:
static void do_poly (int unit, t_bool step) {
if (kg_unit[unit].SR & KGSR_M_DONE)
return;
if (step)
cycleOneBit (unit);
else {
while (!(kg_unit[unit].SR & KGSR_M_DONE))
cycleOneBit (unit);
kg_unit[unit].PULSCNT = 0; /* *** ADDED *** */
}
}
paul
_______________________________________________
HECnet mailing list -- <mailto:hecnet@lists.dfupdate.se>
hecnet(a)lists.dfupdate.se To unsubscribe send an email to
<mailto:hecnet-leave@lists.dfupdate.se> hecnet-leave(a)lists.dfupdate.se