8 Apr
2026
8 Apr
'26
10:23 p.m.
Hey folks, before I start digging into this, I figured I'd ask here.
A simple "hello world" program in F77 on RSX-11M-PLUS fails to start thusly:
$ run hello
TT3 -- Exiting due to ERROR 2
Task initialization failure
I was trying to move a larger FORTRAN program to this system (the
11/70 at LSSM) and it was dying with this message, so I wrote a quickie
test case to narrow it down. It's just a write to unit 5:
WRITE(5,10)
10 FORMAT(' Hello World!')
END
...compiled with "FORTRAN HELLO", and linked with:
L HELLO,LB:[1,1]F77FCS/LIB
No warnings or errors. It runs fine on my 11/83 at home with a very
similar config. Before I dig in, can anyone quickly point me to what
I'm missing?
Thanks,
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
8 Apr
8 Apr
11:29 p.m.
Not much value added in this, but just in case it was a 70 -vs- 83 oddity:
it works on my 11/70 with Johnny's f77 RPM install just as you entered it.
So maybe OS or ForTran install issues?
```
*ex
DU0:[RITORTO]HW.FOR;2 3 lines
$ fortran hw
$ l hw,lb:[1,1]f77fcs/lib
$ run hw
Hello World!
On Wed, 8 Apr 2026 at 16:24, Dave McGuire <mcguire(a)neurotica.com> wrote:
Hey folks, before I start digging into this, I figured I'd ask here.
A simple "hello world" program in F77 on RSX-11M-PLUS fails to start
thusly:
$ run hello
TT3 -- Exiting due to ERROR 2
Task initialization failure
I was trying to move a larger FORTRAN program to this system (the
11/70 at LSSM) and it was dying with this message, so I wrote a quickie
test case to narrow it down. It's just a write to unit 5:
WRITE(5,10)
10 FORMAT(' Hello World!')
END
...compiled with "FORTRAN HELLO", and linked with:
L HELLO,LB:[1,1]F77FCS/LIB
No warnings or errors. It runs fine on my 11/83 at home with a very
similar config. Before I dig in, can anyone quickly point me to what
I'm missing?
Thanks,
-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
11:32 p.m.
BTW this is just sitting there on CHOIPN::, which is powered on at the
moment, if you want to COPY my .TSK and see if it runs on your machine to
further eliminate compiler issues, etc .
11:34 p.m.
On 4/8/26 17:32, Jacob Ritorto wrote:
BTW this is just sitting there on CHOIPN::, which is
powered on at the
moment, if you want to COPY my .TSK and see if it runs on your machine
to further eliminate compiler issues, etc .
Thanks, but I've already cross-tested the executables.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
9 Apr
9 Apr
1:46 a.m.
On 2026-04-08 23:34, Dave McGuire wrote:
On 4/8/26 17:32, Jacob Ritorto wrote:
And the image that works on your 11/83 don't on the 11/70? The exact
same binary?
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
BTW this is just sitting there on CHOIPN::, which
is powered on at the
moment, if you want to COPY my .TSK and see if it runs on your machine
to further eliminate compiler issues, etc .
Thanks, but I've already cross-tested the executables.
8 Apr
8 Apr
11:33 p.m.
I don't see how it could be processor-dependent. It must be an
install issue, something broke at some point. We've run FORTRAN code on
this machine before.
-Dave
On 4/8/26 17:29, Jacob Ritorto wrote:
Not much value added in this, but just in case it was
a 70 -vs- 83 oddity:
it works on my 11/70 with Johnny's f77 RPM install just as you entered it.
So maybe OS or ForTran install issues?
```
*ex
DU0:[RITORTO]HW.FOR;2 3 lines
$ fortran hw
$ l hw,lb:[1,1]f77fcs/lib
$ run hw
Hello World!
On Wed, 8 Apr 2026 at 16:24, Dave McGuire <mcguire(a)neurotica.com
<mailto:mcguire@neurotica.com>> wrote:
Hey folks, before I start digging into this, I figured I'd ask
here.
A simple "hello world" program in F77 on RSX-11M-PLUS fails to start
thusly:
$ run hello
TT3 -- Exiting due to ERROR 2
Task initialization failure
I was trying to move a larger FORTRAN program to this system (the
11/70 at LSSM) and it was dying with this message, so I wrote a quickie
test case to narrow it down. It's just a write to unit 5:
WRITE(5,10)
10 FORMAT(' Hello World!')
END
...compiled with "FORTRAN HELLO", and linked with:
L HELLO,LB:[1,1]F77FCS/LIB
No warnings or errors. It runs fine on my 11/83 at home with a
very
similar config. Before I dig in, can anyone quickly point me to what
I'm missing?
Thanks,
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
_______________________________________________
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>
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
--
Dave McGuire, AK4HZ
New Kensington, PA
9 Apr
9 Apr
1:59 a.m.
Error 2, by the way is usually for one of three reasons:
1. Task failed at the SVTK$S call (not able to install trap catching for
various traps)
2. Task uses FP instructions, but task was build without /FP, or system
lacks FP hardware support.
3. FCS initialization failure.
Most likely problem would be #2.
Johnny
On 2026-04-08 22:23, Dave McGuire wrote:
Hey folks, before I start digging into this, I figured I'd ask here.
A simple "hello world" program in F77 on RSX-11M-PLUS fails to start
thusly:
$ run hello
TT3 -- Exiting due to ERROR 2
Task initialization failure
I was trying to move a larger FORTRAN program to this system (the
11/70 at LSSM) and it was dying with this message, so I wrote a quickie
test case to narrow it down. It's just a write to unit 5:
WRITE(5,10)
10 FORMAT(' Hello World!')
END
...compiled with "FORTRAN HELLO", and linked with:
L HELLO,LB:[1,1]F77FCS/LIB
No warnings or errors. It runs fine on my 11/83 at home with a very
similar config. Before I dig in, can anyone quickly point me to what
I'm missing?
Thanks,
-Dave
--
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
3:24 p.m.
/me slaps forehead
The 11/70's FP board set is flaky, and it has been removed pending
repair. I had forgotten about that. But the "hello world" program
shouldn't use any FP instructions..?
I don't think I can get over to LSSM today, but I will be working
there tomorrow.
-Dave
On 4/8/26 19:59, Johnny Billquist wrote:
Error 2, by the way is usually for one of three
reasons:
1. Task failed at the SVTK$S call (not able to install trap catching for
various traps)
2. Task uses FP instructions, but task was build without /FP, or system
lacks FP hardware support.
3. FCS initialization failure.
Most likely problem would be #2.
Johnny
On 2026-04-08 22:23, Dave McGuire wrote:
--
Dave McGuire, AK4HZ
New Kensington, PA
Hey folks, before I start digging into this, I figured I'd ask
here. A simple "hello world" program in F77 on RSX-11M-PLUS fails to
start thusly:
$ run hello
TT3 -- Exiting due to ERROR 2
Task initialization failure
I was trying to move a larger FORTRAN program to this system (the
11/70 at LSSM) and it was dying with this message, so I wrote a
quickie test case to narrow it down. It's just a write to unit 5:
WRITE(5,10)
10 FORMAT(' Hello World!')
END
...compiled with "FORTRAN HELLO", and linked with:
L HELLO,LB:[1,1]F77FCS/LIB
No warnings or errors. It runs fine on my 11/83 at home with a
very similar config. Before I dig in, can anyone quickly point me to
what I'm missing?
Thanks,
-Dave
3:32 p.m.
Don't matter if any FP instructions are in the code or not. A couple of
setup instructions are in the RTS initialization, unless you link with a
version of the F77 library intended for code without FP.
The information on how to create a library that don't use FP is in the
F77 manuals...
Johnny
On 09/04/2026 15.24, Dave McGuire wrote:
/me slaps forehead
The 11/70's FP board set is flaky, and it has been removed pending
repair. I had forgotten about that. But the "hello world" program
shouldn't use any FP instructions..?
I don't think I can get over to LSSM today, but I will be working
there tomorrow.
-Dave
On 4/8/26 19:59, Johnny Billquist wrote:
Error 2, by the way is usually for one of three
reasons:
1. Task failed at the SVTK$S call (not able to install trap catching
for various traps)
2. Task uses FP instructions, but task was build without /FP, or
system lacks FP hardware support.
3. FCS initialization failure.
Most likely problem would be #2.
Johnny
On 2026-04-08 22:23, Dave McGuire wrote:
Hey folks, before I start digging into this, I figured I'd ask
here. A simple "hello world" program in F77 on RSX-11M-PLUS fails to
start thusly:
$ run hello
TT3 -- Exiting due to ERROR 2
Task initialization failure
I was trying to move a larger FORTRAN program to this system (the
11/70 at LSSM) and it was dying with this message, so I wrote a
quickie test case to narrow it down. It's just a write to unit 5:
WRITE(5,10)
10 FORMAT(' Hello World!')
END
...compiled with "FORTRAN HELLO", and linked with:
L HELLO,LB:[1,1]F77FCS/LIB
No warnings or errors. It runs fine on my 11/83 athome with a
very similar config. Before I dig in, can anyone quickly point me to
what I'm missing?
Thanks,
-Dave
4:29 p.m.
Damn, I was unaware of that. Hitting the docs now. Thank you Johnny.
-Dave
On 4/9/26 09:32, Johnny Billquist wrote:
Don't matter if any FP instructions are in the
code or not. A couple of
setup instructions are in the RTS initialization, unless you link with a
version of the F77 library intended for code without FP.
The information on how to create a library that don't use FP is in the
F77 manuals...
Johnny
On 09/04/2026 15.24, Dave McGuire wrote:
--
Dave McGuire, AK4HZ
New Kensington, PA
/me slaps forehead
The 11/70's FP board set is flaky, and it has been removed pending
repair. I had forgotten about that. But the "hello world" program
shouldn't use any FP instructions..?
I don't think I can get over to LSSM today, but I will be working
there tomorrow.
-Dave
On 4/8/26 19:59, Johnny Billquist wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se Error 2, by the way is usually for one of three
reasons:
1. Task failed at the SVTK$S call (not able to install trap catching
for various traps)
2. Task uses FP instructions, but task was build without /FP, or
system lacks FP hardware support.
3. FCS initialization failure.
Most likely problem would be #2.
Johnny
On 2026-04-08 22:23, Dave McGuire wrote:
Hey folks, before I start digging into this, I figured I'd ask
here. A simple "hello world" program in F77 on RSX-11M-PLUS fails to
start thusly:
$ run hello
TT3 -- Exiting due to ERROR 2
Task initialization failure
I was trying to move a larger FORTRAN program to this system (the
11/70 at LSSM) and it was dying with this message, so I wrote a
quickie test case to narrow it down. It's just a write to unit 5:
WRITE(5,10)
10 FORMAT(' Hello World!')
END
...compiled with "FORTRAN HELLO", and linked with:
L HELLO,LB:[1,1]F77FCS/LIB
No warnings or errors. It runs fine on my 11/83 athome with a
very similar config. Before I dig in, can anyone quickly point me
to what I'm missing?
Thanks,
-Dave
4:31 p.m.
OTS manual, chapter 12.
Johnny
On 09/04/2026 16.29, Dave McGuire wrote:
Damn, I was unaware of that. Hitting the docs now. Thank you Johnny.
-Dave
On 4/9/26 09:32, Johnny Billquist wrote:
Don't matter if any FP instructions are in
the code or not. A couple
of setup instructions are in the RTS initialization, unless you link
with a version of the F77 library intended for code without FP.
The information on how to create a library that don't use FP is in the
F77 manuals...
Johnny
On 09/04/2026 15.24, Dave McGuire wrote:
/me slaps forehead
The 11/70's FP board set is flaky, and it has been removed pending
repair. I had forgotten about that. But the "hello world"program
shouldn't use any FP instructions..?
I don't think I can get over to LSSM today, but I will be working
there tomorrow.
-Dave
On 4/8/26 19:59, Johnny Billquist wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se Error 2, by the way is usually for one of three
reasons:
1. Task failed at the SVTK$S call (not able to install trap catching
for various traps)
2. Task uses FP instructions, but task was build without /FP, or
system lacks FP hardware support.
3. FCS initialization failure.
Most likely problem would be #2.
Johnny
On 2026-04-08 22:23, Dave McGuire wrote:
>
> Hey folks, before I start digging into this, I figuredI'd ask
> here. A simple "hello world" program in F77 on RSX-11M-PLUS fails
> to start thusly:
>
> $ run hello
> TT3 -- Exiting due to ERROR 2
> Task initialization failure
>
> I was trying to move a larger FORTRAN program to this system
> (the 11/70 at LSSM) and it was dying with this message, so I wrote
> a quickie test case to narrow it down. It's just a write to unit 5:
>
> WRITE(5,10)
> 10 FORMAT(' Hello World!')
> END
>
> ...compiled with "FORTRAN HELLO", and linked with:
>
> L HELLO,LB:[1,1]F77FCS/LIB
>
> No warnings or errors. It runs fine on my 11/83 athome with a
> very similar config. Before I dig in, can anyone quickly point me
> to what I'm missing?
>
> Thanks,
> -Dave
>
4:32 p.m.
Reading it now. Thanks!
-Dave
On 4/9/26 10:31, Johnny Billquist wrote:
OTS manual, chapter 12.
Johnny
On 09/04/2026 16.29, Dave McGuire wrote:
--
Dave McGuire, AK4HZ
New Kensington, PA
Damn, I was unaware of that. Hitting the docs now. Thank you Johnny.
-Dave
On 4/9/26 09:32, Johnny Billquist wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se Don't matter if any FP instructions are in
the code or not. A couple
of setup instructions are in the RTS initialization, unless you link
with a version of the F77 library intended for code without FP.
The information on how to create a library that don't use FP is in
the F77 manuals...
Johnny
On 09/04/2026 15.24, Dave McGuire wrote:
/me slaps forehead
The 11/70's FP board set is flaky, and it has been removed
pending repair. I had forgotten about that. But the "hello
world"program shouldn't use any FP instructions..?
I don't think I can get over to LSSM today, but I will be working
there tomorrow.
-Dave
On 4/8/26 19:59, Johnny Billquist wrote:
> Error 2, by the way is usually for one of three reasons:
>
> 1. Task failed at the SVTK$S call (not able to install trap
> catching for various traps)
> 2. Task uses FP instructions, but task was build without /FP, or
> system lacks FP hardware support.
> 3. FCS initialization failure.
>
>
> Most likely problem would be #2.
>
> Johnny
>
> On 2026-04-08 22:23, Dave McGuire wrote:
>>
>> Hey folks, before I start digging into this, I figuredI'd ask
>> here. A simple "hello world" program in F77 on RSX-11M-PLUS fails
>> to start thusly:
>>
>> $ run hello
>> TT3 -- Exiting due to ERROR 2
>> Task initialization failure
>>
>> I was trying to move a larger FORTRAN program to this system
>> (the 11/70 at LSSM) and it was dying with this message, so I wrote
>> a quickie test case to narrow it down. It's just a write to unit 5:
>>
>> WRITE(5,10)
>> 10 FORMAT(' Hello World!')
>> END
>>
>> ...compiled with "FORTRAN HELLO", and linked with:
>>
>> L HELLO,LB:[1,1]F77FCS/LIB
>>
>> No warnings or errors. It runs fine on my 11/83 athome with a
>> very similar config. Before I dig in, can anyone quickly point me
>> to what I'm missing?
>>
>> Thanks,
>> -Dave
>>
>
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se 
5:34 p.m.
Dave,
Since Fortran 77 is not much fun without floating point, you may want to try the RSX
Floating Point Emulator.
Glenn Everhart released this floating point emulator on the Fall 82 RSX SIG tape in
[312,315]. In 1984, my lab acquired a PDP-11/44 but it did not have a FPP. We used this
FPEM software to be able to use Fortran 77 floating point operations. At that time we were
running RSX11M+ V2.1 or maybe V3.0 It continued to be used until at least 1993 or so.
It works by putting a vector to its code which it partially locates in pool to trap
illegal instructions. If the instruction was a FP instruction then it does the work in
software and returns to the user code. It should be FIXed in memory, if it is checkpoint
or moved by a shuffle to a different location after it runs, it will crash RSX. I’d fix it
in memory early in STARTUP.CMD.
I did verify that the FPEM.MAC compiles & links clean on RSX11M+ V4.6, but I didn’t
have an easy way to test it. Below is a bit more info on it that is also in FPEM.DOC
Best Regards,
Mark Matlock
FPEM.MAC- The famous Floating Point Emulator for RSX11M.
I have added support for RSX11M+ in this version and also added some logic for
RSX11M V4 to let it work with headers in new locat- ions. The test site has
not told me how it works in M+ as yet though I believe it will work correctly.
This version needs no system generation (the exec must NOT think there's any
floating point). See the initial part of the source for assembly conditionals
to set for M+ or RSX V4 operation. Assemble and build as any /PR:5 task and
link with RSX11M.STB and run in its own partition (or noncheckpointable, non-
shuffleable in GEN). If it shuffles, the system crashes! To use with F4P or
F77 include F4PEIS in your OTS (replace it into your library). This was
developed from the Los Alamos floating point emulator which was a great start
but didn't work. This does. Under RSX11M+ V2 I have not tested this version,
though I hope it will work. Under M V4 it will work. Note however that it
grabs and does not return some pool when run, so only fix it, and run it in
your system's startup.cmd file. Unstopping it will get it to replace the
system's vectors and exit.
Assembly:
MAC FPEM=LB:[1,1]EXEMC.MLB/ML,LB:[200,200]RSXMC,DU1:[312,315]FPEM
TASK BUILD:
TKB FPEM/-FP/-CP/PR=FPEM,LB:[1,54]RSX11M.STB

On Apr 9, 2026, at 9:32 AM, Dave McGuire
<mcguire(a)neurotica.com> wrote:
Reading it now. Thanks!
-Dave
On 4/9/26 10:31, Johnny Billquist wrote:
OTS manual, chapter 12.
Johnny
On 09/04/2026 16.29, Dave McGuire wrote:
--
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
Damn, I was unaware of that. Hitting the docs now. Thank you Johnny.
-Dave
On 4/9/26 09:32, Johnny Billquist wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se Don't matter if any FP instructions are in
the code or not. A couple of setup instructions are in the RTS initialization, unless you
link with a version of the F77 library intended for code without FP.
The information on how to create a library that don't use FP is in the F77
manuals...
Johnny
On 09/04/2026 15.24, Dave McGuire wrote:
>
> /me slaps forehead
>
> The 11/70's FP board set is flaky, and it has been removed pending repair. I
had forgotten about that. But the "hello world"program shouldn't use any FP
instructions..?
>
> I don't think I can get over to LSSM today, but I will be working there
tomorrow.
>
> -Dave
>
> On 4/8/26 19:59, Johnny Billquist wrote:
>> Error 2, by the way is usually for one of three reasons:
>>
>> 1. Task failed at the SVTK$S call (not able to install trap catching for various
traps)
>> 2. Task uses FP instructions, but task was build without /FP, or system lacks FP
hardware support.
>> 3. FCS initialization failure.
>>
>>
>> Most likely problem would be #2.
>>
>> Johnny
>>
>> On 2026-04-08 22:23, Dave McGuire wrote:
>>>
>>> Hey folks, before I start digging into this, I figuredI'd ask here. A
simple "hello world" program in F77 on RSX-11M-PLUS fails to start thusly:
>>>
>>> $ run hello
>>> TT3 -- Exiting due to ERROR 2
>>> Task initialization failure
>>>
>>> I was trying to move a larger FORTRAN program to this system (the 11/70 at
LSSM) and it was dying with this message, so I wrote a quickie test case to narrow it
down. It's just a write to unit 5:
>>>
>>> WRITE(5,10)
>>> 10 FORMAT(' Hello World!')
>>> END
>>>
>>> ...compiled with "FORTRAN HELLO", and linked with:
>>>
>>> L HELLO,LB:[1,1]F77FCS/LIB
>>>
>>> No warnings or errors. It runs fine on my 11/83 athome with a very
similar config. Before I dig in, can anyone quickly point me to what I'm missing?
>>>
>>> Thanks,
>>> -Dave
>>>
>>
>
>
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
10 Apr
10 Apr
2:47 p.m.
On 4/9/26 11:34, Mark Matlock wrote:
Since Fortran 77 is not much fun without floating
point, you may
want to try the RSX Floating Point Emulator.
Glenn Everhart released this floating point emulator on the Fall 82
RSX SIG tape in [312,315]. In 1984, my lab acquired a PDP-11/44 but it
did not have a FPP. We used this FPEM software to be able to use Fortran
77 floating point operations. At that time we were running RSX11M+ V2.1
or maybe V3.0 It continued to be used until at least 1993 or so.
It works by putting a vector to its code which it partially locates
in pool to trap illegal instructions. If the instruction was a FP
instruction then it does the work in software and returns to the user
code. It should be FIXed in memory, if it is checkpoint or moved by a
shuffle to a different location after it runs, it will crash RSX. I’d
fix it in memory early in STARTUP.CMD.
I did verify that the FPEM.MAC compiles & links clean on RSX11M+
V4.6, but I didn’t have an easy way to test it. Below is a bit more info
on it that is also in FPEM.DOC
Thanks Mark! That would seem to be the perfect solution, lacking a
functional FP11-C board set. I was able to build and install it, but I
wasn't able to get it to actually work, so there may be a 4.6
compatibility issue. I'll be over there tomorrow (or today if I can get
there) to try again and take better notes. And then it's...sysgen time!
I was able to get a non-FP program (just a "hello world") to run
using F77EIS, though, so that was a start.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
3:14 p.m.
On 10/04/2026 14.47, Dave McGuire wrote:
On 4/9/26 11:34, Mark Matlock wrote:
I was reading through that code and I'm not sure it will work that well
with M+. But if someone makes it work, that would be interesting to hear.
But even more so, when reading through that, I got a feeling that it
would be really nice to implement a full FPP emulation if the hardware
isn't there, and I think it could be done. Of course, it would be pretty
slow, but still much nicer than not being able to run programs that
depend on the FPP.
If anyone would be interested in working on this, I'd be happy to
provide some assistance, but I don't really have the time to dive into
this fully myself.
I did verify that the FPEM.MAC compiles &
links clean on RSX11M+
V4.6, but I didn’t have an easy way to test it. Below is a bitmore
info on it that is also in FPEM.DOC
Thanks Mark! That would seem to be the perfect solution, lacking a
functional FP11-C board set. I was able to build and install it, but I
wasn't able to get it to actually work, so there may be a 4.6
compatibility issue. I'll be over there tomorrow (or today if I can get
there) to try again and take better notes. And then it's...sysgentime! I was able to get a non-FP program (just a
"hello world") to run
using F77EIS, though, so that was a start.
Excellent.
Johnny
4:13 p.m.
Dave,
Johnny reminded me about a limitation of this FPEM, specifically it does not work with
tasks that have external headers. When you TKB your F77 program add the /-XH switch to
make a task that does not have an external header. RSX11M+ by default would have /XH on by
default.
As I recall (maybe wrongly), you don’t have to specify F77EIS when building the task,
as long as FPEM is running. Also, if you need FPEM to remove itself, I think you can
UNStop it and it will change the vectors back. I am interested in whether this will work
on RSX11M+ V4.6
Good Luck,
Mark
On Apr 10, 2026, at 7:47 AM, Dave McGuire
<mcguire(a)neurotica.com> wrote:
On 4/9/26 11:34, Mark Matlock wrote:
Since Fortran 77 is not much fun without
floating point, you may want to try the RSX Floating Point Emulator.
Glenn Everhart released this floating point emulator on the Fall 82 RSX SIG tape in
[312,315]. In 1984, my lab acquired a PDP-11/44 but it did not have a FPP. We used this
FPEM software to be able to use Fortran 77 floating point operations. At that time we were
running RSX11M+ V2.1 or maybe V3.0 It continued to be used until at least 1993 or so.
It works by putting a vector to its code which it partially locates in pool to trap
illegal instructions. If the instruction was a FP instruction then it does the work in
software and returns to the user code. It should be FIXed in memory, if it is checkpoint
or moved by a shuffle to a different location after it runs, it will crash RSX. I’d fix it
in memory early in STARTUP.CMD.
I did verify that the FPEM.MAC compiles & links clean on RSX11M+ V4.6, but I
didn’t have an easy way to test it. Below is a bit more info on it that is also in
FPEM.DOC
Thanks Mark! That would seem to be the perfect solution, lacking a functional FP11-C
board set. I was able to build and install it, but I wasn't able to get it to
actually work, so there may be a 4.6 compatibility issue. I'll be over there tomorrow
(or today if I can get there) to try again and take better notes. And then
it's...sysgen time!
I was able to get a non-FP program (just a "hello world") to run using F77EIS,
though, so that was a start.
-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
4:19 p.m.
On 10/04/2026 16.13, Mark Matlock wrote:
Dave,
Johnny reminded me about a limitation of this FPEM, specifically it does not work
with tasks that have external headers. When you TKB your F77 program add the /-XH switch
to make a task that does not have an external header. RSX11M+ by default would have /XH on
by default.
That's what I found in the code. There was also some conditional about
external headers, so it's a little confusing. But I didn't see it having
any proper handling of external headers, so I would probably say don't
use them.
As I recall (maybe wrongly), you don’t have to
specify F77EIS when building the task, as long as FPEM is running. Also, if you needFPEM
to remove itself, I think you can UNStop it and it will change the vectors back. I am
interested in whether this will work on RSX11M+ V4.6
No. You also need F77EIS when using FPEM. The reason is that otherwise
the initialization tries to setup an FPP AST, which RSX gives an error
about if you don't have an FPP.
You should also build a kernel without FPP support, since FPEM will not
handle traps for FPP instructions in the kernel, and will completely
crash you out then. And finally, you do need to build the tasks with
/FP, so that the task header contains the storage for the FPP information.
These are some of the reasons I think it would be interesting to develop
another FP emulation, but one that is more complete and which would work
with a FP-enabled kernel.
Johnny
4:54 p.m.
Johnny, Dave,
I did find some old floating point bench mark info in one of my Saturn Calc
spreadsheets (that I can now read once again). The floating point bench mark was a tight
loop in F77 with a REAL*4 multiplication. The Sieve prime number test computed primes unto
8192 with F77 code.
System Sieve Flops Sieve Float Dhrystones
VUPS VUPS
PDP 11/23 2.027900 9693 .11 .05 (microcode FP)
PDP 11/24 11500 .06 (this 11/24 had the clock
potentiometer cranked up as fast as it could go)
PDP 11/44 .568600 61473 .39 .33 (using FPEM)
PDP 11/73 .319948 38837 .69 .21 833 (15 Mhz, microcode FP)
PDP 11/83 .241563 359416 .92 1.92 1153. (15 Mhz, FPP chip)
PDP 11/84 .388500 363774 .57 1.94 (18 Mhz, FPP chip)
M100-04 .218359 382592 1.02 2.04 1250. (20 Mhz, FPP)
VAX 11/780 .222200 187135 1.00 1.00 1500
uVAX II .259100 144829 .86 .77
VAX 8600 .059300 1035673 3.75 5.53
VAX 8700 .044920 885201 4.95 4.73
VAX 6420 .032160 1412804 6.91 7.55 17141
VAX 6610 .007305 9230000 30.42 49.32 66578
VAX 3500 .084370 525590 2.63 2.81 5612
MV3100 10e .057030 766470 3.90 4.10 8834
MV3100 30 .038906 1132743 5.71 6.05 15974
MV3100 80 .022187 1987578 10.01 10.62 22727
VS4000 90A .007289 9270000 30.48 49.54 66578
Alpha 666Mhz .000340 204000000 653.53 1090 2783964 (Alpha 666Mhz, EV67)
Best,
Mark
On Apr 10, 2026, at 9:19 AM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 10/04/2026 16.13, Mark Matlock wrote:
Oh, I see. I didn’t realize that RSX used any FP instructions in the kernel.
Dave,
Johnny reminded me about a limitation of this FPEM, specifically it does not work
with tasks that have external headers. When you TKB your F77 program add the /-XH switch
to make a task that does not have an external header. RSX11M+ by default would have /XH on
by default.
That's what I found in the code. There was also some conditional about external
headers, so it's a little confusing. But I didn't see it having any proper
handling of external headers, so I would probably say don't use them.
As I recall (maybe wrongly), you don’t have
to specify F77EIS when building the task, as long as FPEM is running. Also, if you
needFPEM to remove itself, I think you can UNStop it and it will change the vectors back.
I am interested in whether this will work on RSX11M+ V4.6
No. You also need F77EIS when using FPEM. The reason is that otherwise the initialization
tries to setup an FPP AST, which RSX gives an error about if you don't have an FPP.
You should also build a kernel without FPP support, since FPEM will not handle traps for
FPP instructions in the kernel, and will completely crash you out then. And finally, you
do need to build the tasks with /FP, so that the task header contains the storage for the
FPP information. These are some of the reasons I think it would be
interesting to develop another FP emulation, but one that is more complete and which would
work with a FP-enabled kernel.
Johnny
10:23 p.m.
On Apr 10, 2026, at 10:54 AM, Mark Matlock
<mark(a)matlockfamily.com> wrote:
Johnny, Dave,
I did find some old floating point bench mark info in one of my Saturn Calc
spreadsheets (that I can now read once again). The floating point bench mark was a tight
loop in F77 with a REAL*4 multiplication. The Sieve prime number test computed primes unto
8192 with F77 code.
System Sieve Flops Sieve Float Dhrystones
VUPS VUPS
PDP 11/23 2.027900 9693 .11 .05 (microcode FP)
PDP 11/24 11500 .06 (this 11/24 had the clock
potentiometer cranked up as fast as it could go)
PDP 11/44 .568600 61473 .39 .33 (using FPEM)
PDP 11/73 .319948 38837 .69 .21 833 (15 Mhz, microcode FP)
PDP 11/83 .241563 359416 .92 1.92 1153. (15 Mhz, FPP chip)
PDP 11/84 .388500 363774 .57 1.94 (18 Mhz, FPP chip)
M100-04 .218359 382592 1.02 2.04 1250. (20 Mhz, FPP)
VAX 11/780 .222200 187135 1.00 1.00 1500
uVAX II .259100 144829 .86 .77
VAX 8600 .059300 1035673 3.75 5.53
VAX 8700 .044920 885201 4.95 4.73
VAX 6420 .032160 1412804 6.91 7.55 17141
VAX 6610 .007305 9230000 30.42 49.32 66578
VAX 3500 .084370 525590 2.63 2.81 5612
MV3100 10e .057030 766470 3.90 4.10 8834
MV3100 30 .038906 1132743 5.71 6.05 15974
MV3100 80 .022187 1987578 10.01 10.62 22727
VS4000 90A .007289 9270000 30.48 49.54 66578
Alpha 666Mhz .000340 204000000 653.53 1090 2783964 (Alpha 666Mhz, EV67)
Best,
Mark
Wow, that Alpha number is amazing. Funny that the VAX 780 was half the speed of an 11/83.
Did the 780 have an optional separate FPP? I forget. I wonder what an Aridus (VAX 9000)
would produce.
It would be interesting to see numbers for the 11/45, 11/70, and 11/60 with FPP, since
those were supposedly pretty fast at least for the time. One interesting property (great
to give headaches to compiler writers) is that a PDP-11 with FFP is basically a dual
pipeline machine, with an integer and a float pipe. But they are not fully separate; FPP
instructions take some time in the integer pipe for addressing mode handling, then the
actual execution is handed off to the floating operation pipe. I thought a bit about an
instruction scheduler description for GCC, but it made my head hurt. :-)
paul
10:35 p.m.
On 4/10/26 16:23, Paul Koning wrote:
Wow, that Alpha number is amazing. Funny that the VAX
780 was half the speed of an 11/83. Did the 780 have an optional separate FPP? I forget.
I wonder what an Aridus (VAX 9000) would produce.
Yes, the FP780.
We at LSSM have a 9000 in the warehouse. I doubt we will try to get
it running, but you never know.
One interesting thing about the 9000 is that it's one of only two
implementations of the VAXvector that I'm aware of. We have the other,
which is an add-in board for a VAX-6400. I got that up and running
about two years ago; it's a great deal of fun, but only for FORTRAN.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
10:42 p.m.
On Apr 10, 2026, at 4:35 PM, Dave McGuire
<mcguire(a)neurotica.com> wrote:
On 4/10/26 16:23, Paul Koning wrote:
Does a 9000 need 3-phase power?
I did not know there were VAX vector instructions. I wonder if GCC knows about them (for
the VAX back end). It has really extensive vector support, so if the back end handles
that you'd end up with vectors probably for any language GCC knows about -- or
minimally for C and C++ as well as FORTRAN.
paul
Wow, that Alpha number is amazing. Funny that
the VAX 780 was half the speed of an 11/83. Did the 780 have an optional separate FPP? I
forget. I wonder what an Aridus (VAX 9000) would produce.
Yes, the FP780.
We at LSSM have a 9000 in the warehouse. I doubt we will try to get it running, but you
never know.
One interesting thing about the 9000 is that it's one of only two implementations of
the VAXvector that I'm aware of. We have the other, which is an add-in board for a
VAX-6400. I got that up and running about two years ago; it's a great deal of fun,
but only for FORTRAN.
10:54 p.m.
On 4/10/26 16:42, Paul Koning wrote:
Very much so, yes. It takes two people to move *the power cable* for
that machine.
We at LSSM
have a 9000 in the warehouse. I doubt we will try to get it running, but you never know.
One interesting thing about the 9000 is that it's one of only two implementations
of the VAXvector that I'm aware of. We have the other, which is an add-in board for a
VAX-6400. I got that up and running about two years ago; it's a great deal of fun,
but only for FORTRAN.
Does a 9000 need 3-phase power? I did not know there were VAX vector instructions.
Yes, but only those two implementations.
The XMI board, called FV64A, will only work with 6000-400 and -500
processors, though a box can take one VAXvector XMI board per processor.
It has 16 64-bit- vector registers, vectors can be up to 64 elements
long. It crunches about 90 MFLOPS peak.
I wonder if GCC knows about them (for the VAX back
end). It has really extensive vector support, so if the back end handles that you'd
end up with vectors probably for any language GCC knows about -- or minimally for C and
C++ as well as FORTRAN.
That would be a nice extension, but sadly we can count the number of
places that can take advantage of it on one hand. And the number of
machines that implement it that are actually functional on one finger.
The VAX FORTRAN compiler will emit the vector instructions, and that
works well. Actually it works amazingly well; it autovectorizes code
every bit as well as Cray's compiler, which is really the gold standard.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
11 Apr
11 Apr
1:16 a.m.
Dave McGuire <mcguire(a)neurotica.com> wrote:
It takes two people to move *the power cable* for that machine.
It was ECL (lots and lots of ECL) after all...
The VAX-9000 is arguably the machine that finally killed DEC. They spent
over $1 billion on its development, killed several other architectures in
the process (like Dave Cutler's PRISM - that's why he left for Microsoft),
and only ever shipped a couple dozen machines. And by the time the VAX-9000
actually did ship (around 1990-91, I think) the NVAX chip ran nearly as fast
and was waaayyy cheaper and smaller.
Bob
2:03 a.m.
On 2026-04-10 19:16, Robert Armstrong wrote:
Yup. It and the 86x0 (originally to be the 11/79x) were the
only two VAX processors by the LSG/LCG (home of the TWO Jupiter
projects, the Dolphin - I think that was the one supposed to
run both VAX and PDP-10 code, selected at boot time, etc.)
The 8600 was late and slow. By the time they figured out the
issues that caused the slowness, the 8600 -> 8650 upgrade was a
2-board swap and a new console pack. But we never got the 8670 -
if the 8600 had met its speed target, the 8670 would have been
the "mid-life kicker", like the 785 was to the 780.
The 86x0 shipped with a Russell-Stoll 60A 3-phase connector,
but that was part of "The VAX Mainframe" shtick and it would run
happily on 30A 3-phase, same as a 78x (I actually ran one of my
8650s at SPC that way). The plug was so you could roll out your
IBM 370 and roll in your 86x0 and plug it into the same power
connector. Of course, peripherals and instruction set differ-
ences were just a handwave by Marketing, to be sorted out by the
customer).
Dave McGuire
<mcguire(a)neurotica.com> wrote:
It takes two people to move *the power cable* for that machine.
It was ECL (lots and lots of ECL) after all... The VAX-9000 is arguably the machine that finally
killed DEC. They
spent
over $1 billion on its development, killed several other architectures
in
the process (like Dave Cutler's PRISM - that's why he left for
Microsoft),
and only ever shipped a couple dozen machines.
And about 2 dozen of them came back. I gave Dave a sealed FCO
kit for one of the reliability fixes for the 9000 - a new MCM -
and the FCO said it was to "Fix problems from Alpha particles",
which was funny because the Alpha processor (no relation to the
particles) rapidly took over most VAX applications. Dave said he
wasn't sure if he should worship it or crack open the factory
seal on the FCO ESD carrier, but he eventually decided to open it
(and then worship it 8-).
And by the time the VAX-9000
actually did ship (around 1990-91, I think) the NVAX chip ran nearly as
fast
and was waaayyy cheaper and smaller.
And eventually surpassed it - the 4000-705A was slightly faster
than a uniprocessor 9000. The LSSM has one I painstakingly built
from parts to be 100% authentic - and it runs!
DEC intentionally crippled the 4000 - no CI cluster support,
no Fast Ethernet support. MTI did two spins of a CI adapter, and
the adapter, its S-box panel and the software licenses are find-
able, but the driver is lost. And they stopped supporting it at
VMS V7.2 - it won't run on V7.3. But V7.3 on VAX was really only
half-finished. They should have released -1 and -2 updates for it
like they did for Alpha. Anyway, the MTI CI board was limited by
the slow Q-bus.
Nemonix had a card that offered either fast/wide SCSI, Fast
Ethernet, or both. They were smart and used the KFDDB bus (where
additional SHACs for two more DSSI buses would have plugged in)
for speed. I've never seen one, only the marketing materials.
I guess DEC felt that since they were third-party products (al-
though DEC and Nemonix were VERY cozy) it didn't matter to the
9000.
1:03 p.m.
The VAX vector process was also a great deal of fun for an implementation of Algol 68 we
were working on.
We had access to a VAX 9000 for some testing but from what I remember, we used DEC's
vector emulation software mostly.
We had "great fun" with the attribution for implicit vectorisation of array
processing and collateral clauses and we almost actually got into trouble for including
the RS extensions for loops, the FOR identifier IN (unit delivering [] of some mode) DO
... OD.
Trouble = exceeding our remit.
Anyway, it's all effectively lost. Nobody remembers where any of the project materials
actually went. I hate that.
Also just paged into my memory, we wrote prediction code - part of the code generator
which would output a profile. Along with the runtime profiling, it could (and did
accurately) predict how fast the code would run on the real hardware. We also got into
trouble for that too - disassembling the vector processor emulator code. Did we use Xdelta
for parts of that?
K
-----Original Message-----
From: Dave McGuire [mailto:mcguire@neurotica.com]
Sent: 10 April 2026 21:54
To: The Hobbyist DECnet mailing list <hecnet(a)lists.dfupdate.se>
Subject: [HECnet] Re: quick help on RSX FORTRAN problem?
On 4/10/26 16:42, Paul Koning wrote:
Very much so, yes. It takes two people to move *the power cable* for that machine.
We at LSSM
have a 9000 in the warehouse. I doubt we will try to get it running, but you never know.
One interesting thing about the 9000 is that it's one of only two implementations
of the VAXvector that I'm aware of. We have the other, which is an add-in board for a
VAX-6400. I got that up and running about two years ago; it's a great deal of fun,
but only for FORTRAN.
Does a 9000 need 3-phase power? I did not know there were VAX vector instructions.
Yes, but only those two implementations.
The XMI board, called FV64A, will only work with 6000-400 and -500 processors, though a
box can take one VAXvector XMI board per processor.
It has 16 64-bit- vector registers, vectors can be up to 64 elements long. It crunches
about 90 MFLOPS peak.
I wonder if GCC knows about them (for the VAX back
end). It has really extensive vector support, so if the back end handles that you'd
end up with vectors probably for any language GCC knows about -- or minimally for C and
C++ as well as FORTRAN.
That would be a nice extension, but sadly we can count the number of places that can
take advantage of it on one hand. And the number of machines that implement it that are
actually functional on one finger.
The VAX FORTRAN compiler will emit the vector instructions, and that works well.
Actually it works amazingly well; it autovectorizes code every bit as well as Cray's
compiler, which is really the gold standard.
-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
4:15 p.m.
On 4/11/26 07:03, Keith Halewood wrote:
The VAX vector process was also a great deal of fun
for an implementation of Algol 68 we were working on.
We had access to a VAX 9000 for some testing but from what I remember, we used DEC's
vector emulation software mostly.
We had "great fun" with the attribution for implicit vectorisation of array
processing and collateral clauses and we almost actually got into trouble for including
the RS extensions for loops, the FOR identifier IN (unit delivering [] of some mode) DO
... OD.
Trouble = exceeding our remit.
Anyway, it's all effectively lost. Nobody remembers where any of the project
materials actually went. I hate that.
That's infuriating. I just cannot fathom that there are programmers
out there who don't take copies of their stuff home.
Also just paged into my memory, we wrote prediction
code - part of the code generator which would output a profile. Along with the runtime
profiling, it could (and did accurately) predict how fast the code would run on the real
hardware. We also got into trouble for that too - disassembling the vector processor
emulator code. Did we use Xdelta for parts of that?
Does that emulator code itself survive anywhere? It doesn't come
with VMS, does it?
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
4:58 p.m.
The annoying thing is that I do remember taking copies of stuff.... and even copying them
over the course of years from tape to tape cartridge (tk50/tk70) to cd, etc.. and then
stopped for no reason I can recall.
As for the emulation, I don't remember the product.
If I remember rightly, VMS when it was installed on the likes of MicroVAX (2 ?) included
emulation for G and H floating and various other instructions - the decimal string stuff?
- but I'm pretty sure the vector emulation was extra.
K
-----Original Message-----
From: Dave McGuire [mailto:mcguire@neurotica.com]
Sent: 11 April 2026 15:16
To: The Hobbyist DECnet mailing list <hecnet(a)lists.dfupdate.se>
Subject: [HECnet] Re: quick help on RSX FORTRAN problem?
On 4/11/26 07:03, Keith Halewood wrote:
The VAX vector process was also a great deal of fun
for an implementation of Algol 68 we were working on.
We had access to a VAX 9000 for some testing but from what I remember, we used DEC's
vector emulation software mostly.
We had "great fun" with the attribution for implicit vectorisation of array
processing and collateral clauses and we almost actually got into trouble for including
the RS extensions for loops, the FOR identifier IN (unit delivering [] of some mode) DO
... OD.
Trouble = exceeding our remit.
Anyway, it's all effectively lost. Nobody remembers where any of the project
materials actually went. I hate that.
That's infuriating. I just cannot fathom that there are programmers out there who
don't take copies of their stuff home.
Also just paged into my memory, we wrote prediction
code - part of the code generator which would output a profile. Along with the runtime
profiling, it could (and did accurately) predict how fast the code would run on the real
hardware. We also got into trouble for that too - disassembling the vector processor
emulator code. Did we use Xdelta for parts of that?
Does that emulator code itself survive anywhere? It doesn't come with VMS, does
it?
-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
5:02 p.m.
Well, what do you know:
"The VAX Vector Instruction Emulation Facility (VVIEF) is a standard, built-in
feature of the VAX/VMS (OpenVMS VAX) operating system designed to emulate the VAX Vector
Architecture.
Installation: It is loaded by invoking the command procedure SYS$UPDATE:VVIEF$INSTAL.COM
and unloaded via SYS$UPDATE:VVIEF$DEINSTAL.COM.
Activation Check: You can verify its presence using the DCL command
F$GETSYI("VECTOR_EMULATOR"). A return value of 1 indicates VVIEF is active.
Availability: VVIEF is part of the VMS operating system software, not a separate,
third-party commercial product. It was relevant for VAX/VMS versions supporting vector
operations, such as VMS 5.5 and later, through OpenVMS VAX Version 7.1. "
Just checked, it's there in 7.3.
Wow. I think I may need to sit down.
K
-----Original Message-----
From: Keith Halewood [mailto:Keith.Halewood@pitbulluk.org]
Sent: 11 April 2026 15:59
To: The Hobbyist DECnet mailing list <hecnet(a)lists.dfupdate.se>
Subject: [HECnet] Re: quick help on RSX FORTRAN problem?
The annoying thing is that I do remember taking copies of stuff.... and even copying them
over the course of years from tape to tape cartridge (tk50/tk70) to cd, etc.. and then
stopped for no reason I can recall.
As for the emulation, I don't remember the product.
If I remember rightly, VMS when it was installed on the likes of MicroVAX (2 ?) included
emulation for G and H floating and various other instructions - the decimal string stuff?
- but I'm pretty sure the vector emulation was extra.
K
-----Original Message-----
From: Dave McGuire [mailto:mcguire@neurotica.com]
Sent: 11 April 2026 15:16
To: The Hobbyist DECnet mailing list <hecnet(a)lists.dfupdate.se>
Subject: [HECnet] Re: quick help on RSX FORTRAN problem?
On 4/11/26 07:03, Keith Halewood wrote:
The VAX vector process was also a great deal of fun
for an implementation of Algol 68 we were working on.
We had access to a VAX 9000 for some testing but from what I remember, we used DEC's
vector emulation software mostly.
We had "great fun" with the attribution for implicit vectorisation of array
processing and collateral clauses and we almost actually got into trouble for including
the RS extensions for loops, the FOR identifier IN (unit delivering [] of some mode) DO
... OD.
Trouble = exceeding our remit.
Anyway, it's all effectively lost. Nobody remembers where any of the project
materials actually went. I hate that.
That's infuriating. I just cannot fathom that there are programmers out there who
don't take copies of their stuff home.
Also just paged into my memory, we wrote prediction
code - part of the code generator which would output a profile. Along with the runtime
profiling, it could (and did accurately) predict how fast the code would run on the real
hardware. We also got into trouble for that too - disassembling the vector processor
emulator code. Did we use Xdelta for parts of that?
Does that emulator code itself survive anywhere? It doesn't come with VMS, does
it?
-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
5:50 p.m.
Keith Halewood <Keith.Halewood(a)pitbulluk.org>
wrote:
... The VAX Vector Instruction Emulation Facility (VVIEF) is a standard
...
That's kind of neat. Thanks for checking this out. Is the option to
generate the vector instructions standard in the VMS FORTRAN compiler?
That's the only thing DEC ever produced that used the vector processor,
right?
The emulator would be fun for playing with the compiler, but it's probably
not very useful otherwise. I imagine emulating vector instructions without
the hardware is probably slower than just letting the compiler generate code
the normal, non-vector, way.
Bob
6:02 p.m.
On 4/11/26 11:50, Robert Armstrong wrote:
Seconded, thanks Keith. Very neat indeed.
Keith Halewood
<Keith.Halewood(a)pitbulluk.org> wrote:
... The VAX Vector Instruction Emulation Facility (VVIEF) is a standard
...
That's kind of neat. Thanks for checking this out. Is the option to
generate the vector instructions standard in the VMS FORTRAN compiler?
The capability is built into the standard FORTRAN compiler. Try this:
fortran/vector/list/show-loops <file>
...and the resulting listing file will tell you about, for example,
loops that the compiler was able to vectorize.
That's the only thing DEC ever produced that used
the vector processor,
right?
As far as I've been able to find. I'd love to be proven wrong on that.
The emulator would be fun for playing with the
compiler, but it's probably
not very useful otherwise. I imagine emulating vector instructions without
the hardware is probably slower than just letting the compiler generate code
the normal, non-vector, way.
I'd bet on that, yes.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
10:06 p.m.
On Apr 11, 2026, at 7:03 AM, Keith Halewood
<Keith.Halewood(a)pitbulluk.org> wrote:
The VAX vector process was also a great deal of fun for an implementation of Algol 68 we
were working on.
Neat. I'm a fan of that language, though opportunities to use it have not been
common.
Did you know that the GCC suite now contains an Algol 68 front end? That would imply that
in theory (give or take any needed machine-dependent bits) you can now compile Algol 68
programs for a whole lot of different machines, possibly including the VAX. Hm, I wonder
about PDP-11. That would be wild. Will have to try that.
paul
10:20 p.m.
I have the VAX/VMS version of Algol 68 RS - an implementation lacking only PAR, with
extensions for modules and better low level programming. You can even interface with
system services because it uses the calling standard. Even the debugger works with it.
It’s available from DUNE:: decnet default directory.
On 11 Apr 2026, at 21:07, Paul Koning
<paulkoning(a)comcast.net> wrote:
On Apr 11, 2026, at 7:03 AM, Keith Halewood
<Keith.Halewood(a)pitbulluk.org> wrote:
The VAX vector process was also a great deal of fun for an implementation of Algol 68 we
were working on.
Neat. I'm a fan of that language, though opportunities to use it have not been
common.
Did you know that the GCC suite now contains an Algol 68 front end? That would imply
that in theory (give or take any needed machine-dependent bits) you can now compile Algol
68 programs for a whole lot of different machines, possibly including the VAX. Hm, I
wonder about PDP-11. That would be wild. Will have to try that.
paul
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
7:47 p.m.
New subject: Alpha Chip performance
I posted some old benchmark data I found on various PDP-11s and VAXes that I collected
down through the years. Johnny mentioned he thought the 11/84 numbers looked off and I
thought so too. So I reran the 11/84 tests as well as the 11/83 tests and the results are
below. Also, the VAXes did not have Floating Point accelerators since they belonged to our
corporate I.T. group who preferred to compute with integers.
System Sieve Flops Sieve Float Dhrystones
(Sec) VUPS. VUPS
PDP 11/23 2.027900 9693 .11 .05
PDP 11/24 11500 .06
PDP 11/44 .568600 61473 .39 .33
PDP 11/73 .319948 38837 .69 .21 833
PDP 11/83 .241563 359416 .92 1.92 1153
PDP 11/84 .236615 365645 .94 1.95 1200
M100-04 .218359 382592 1.02 2.04 1250
VAX 11/780 .222200 187135 1.00 1.00 1500
uVAX II .259100 144829 .86 .77
VAX 8600 .059300 1035673 3.75 5.53
VAX 8700 .044920 885201 4.95 4.73
VAX 6420 .032160 1412804 6.91 7.55 17141
VAX 6610 .007305 9230000 30.42 49.32 66578
VAX 3500 .084370 525590 2.63 2.81 5612
MV3100 10e .057030 766470 3.90 4.10 8834
MV3100 30 .038906 1132743 5.71 6.05 15974
MV3100 80 .022187 1987578 10.01 10.62 22727
VS4000 90A .007289 9270000 30.48 49.54 66578
Alpha 666Mhz .000340 204000000 653.53 1090 2783964
Paul commented on the Alpha’s performance that came from my XP1000 (BLISH on HECnet)
workstation. It reminded me of a couple passages in the book “A Life Decoded” by Craig
Venter who led the private effort to sequence the human genome. I thought this group might
enjoy a couple passages from the book. I had lunch with Craig Venter at my lab when we
licensed some technology from one of his companies, Synthetic Genomics, where I first
learned about the role of Alphas in the Human Genome Project.
Best,
Mark
On Apr 10, 2026, at 3:35 PM, Dave McGuire
<mcguire(a)neurotica.com> wrote:
On 4/10/26 16:23, Paul Koning wrote:
To make sense of the claims and counterclaims by the competing computer manufacturers, I
decided to do an experiment with the assembler that was being used routinely for
sequencing at TIGR. With the Sun computers that we ran it on, a simple (relative to human)
genome such as Haemophilus required several days to assemble. By extrapolation, it would
require years for it to assemble the 3 billion base pairs of the human genome. How would
our various suitors do in coming up with more efficient hardware?
Only Compaq and IBM agreed to the challenge. In the first run of Compaq’s Alpha chip, we
went from taking days to nineteen hours, and then finally nine hours. The best that IBM
could manage was thirty-six hours. My programmers wanted the Alpha chip and the results of
the challenge left no doubt that was the one to go with. IBM knew it had not done well and
asked me what it would take to get the contract. I bluntly told them that IBM would have
to provide the system for free and include a development team to get it up and running.
While IBM was contemplating my reply, it dawned on me that I might not have made a
particularly good proposal: I had no leverage if the system was free, and I could hardly
withhold a payment for poor performance. I realized that I had to pay for what I really
wanted, for what had the best chance to work in an area that no one had ever been before.
The CEO of Compaq flew out to meet with me and to pledge his commitment to make every
effort to guarantee the success of our effort. He wanted his computers to be the ones that
carried out the largest calculation in the history of biology and medicine to date. After
a few days I signed the Compaq contract and called the CEO to tell him that I had accepted
his offer. A half an hour later I was about to phone Nick at IBM to give him my decision
when he called me instead. He had just met Lou Gerstner, the IBM CEO, who authorized him
to provide the entire system gratis. I responded that I would have been interested thirty
minutes earlier but had just signed the deal with Compaq. He wished me well and said that
when the Compaq computers failed, they would be waiting. But I could not let his offer
even enter my head, for I could not countenance failure: For this project there were no
second chances.
….
With its Compaq Alpha chip the Celera computer could top around 1.2 teraflops (teraops),
equivalent to 1.2 trillion calculations per second. The computer also had 4 gigabytes of
RAM and around 10 terabytes, or ten thousand gigabytes, of hard disk storage space.
Peterson’s team would come to be incredibly proud of what they had built and the speed
with which they accomplished it, an unprecedented achievement in the computer world of the
day. In 1999 our computer was rated by Compaq engineers as the third largest in the world
and the largest computer in civilian hands. (Today it would not be in the top few hundred,
and even PCs can accommodate 64 gigabytes of RAM.) Overseeing all this would be a Star
Trek–style control room where giant wall screens and dozens of smaller computer displays
tracked the CPU utilization, the computer room temperature, who was in the facility, CNN,
the weather, the state of Internet traffic, the 300 ABI 3700 DNA sequencers, the power
grid, the extent of database use by each subscriber, and, for the sake of Tony White, the
Celera stock price.
Venter, J. Craig. A Life Decoded: My Genome: My Life (Function). Kindle Edition.
Wow, that Alpha number is amazing. Funny that
the VAX 780 was half the speed of an 11/83. Did the 780 have an optional separate FPP? I
forget. I wonder what an Aridus (VAX 9000) would produce.
13 Apr
13 Apr
12:56 p.m.
New subject: Alpha Chip performance
I have a rack mount DEC Alpha that was used as part of the genome mapping project, picked
up from one of the ex-employees from the Cambridge area. I had two, but gifted one to
Pete. It’s been in the garage for a long time, so not sure what state it is in, I think
they are rack mount 3000/600s or a close model.
Mark.
On 11 Apr 2026, at 18:47, Mark Matlock
<mark(a)matlockfamily.com> wrote:
I posted some old benchmark data I found on various PDP-11s and VAXes that I collected
down through the years. Johnny mentioned he thought the 11/84 numbers looked off and I
thought so too. So I reran the 11/84 tests as well as the 11/83 tests and the results are
below. Also, the VAXes did not have Floating Point accelerators since they belonged to our
corporate I.T. group who preferred to compute with integers.
System Sieve Flops Sieve Float Dhrystones
(Sec) VUPS. VUPS
PDP 11/23 2.027900 9693 .11 .05
PDP 11/24 11500 .06
PDP 11/44 .568600 61473 .39 .33
PDP 11/73 .319948 38837 .69 .21 833
PDP 11/83 .241563 359416 .92 1.92 1153
PDP 11/84 .236615 365645 .94 1.95 1200
M100-04 .218359 382592 1.02 2.04 1250
VAX 11/780 .222200 187135 1.00 1.00 1500
uVAX II .259100 144829 .86 .77
VAX 8600 .059300 1035673 3.75 5.53
VAX 8700 .044920 885201 4.95 4.73
VAX 6420 .032160 1412804 6.91 7.55 17141
VAX 6610 .007305 9230000 30.42 49.32 66578
VAX 3500 .084370 525590 2.63 2.81 5612
MV3100 10e .057030 766470 3.90 4.10 8834
MV3100 30 .038906 1132743 5.71 6.05 15974
MV3100 80 .022187 1987578 10.01 10.62 22727
VS4000 90A .007289 9270000 30.48 49.54 66578
Alpha 666Mhz .000340 204000000 653.53 1090 2783964
Paul commented on the Alpha’s performance that came from my XP1000 (BLISH on HECnet)
workstation. It reminded me of a couple passages in the book “A Life Decoded” by Craig
Venter who led the private effort to sequence the human genome. I thought this group might
enjoy a couple passages from the book. I had lunch with Craig Venter at my lab when we
licensed some technology from one of his companies, Synthetic Genomics, where I first
learned about the role of Alphas in the Human Genome Project.
Best,
Mark
On Apr 10, 2026, at 3:35 PM, Dave McGuire
<mcguire(a)neurotica.com> wrote:
On 4/10/26 16:23, Paul Koning wrote:
To make sense of the claims and counterclaims by the competing computer manufacturers, I
decided to do an experiment with the assembler that was being used routinely for
sequencing at TIGR. With the Sun computers that we ran it on, a simple (relative to human)
genome such as Haemophilus required several days to assemble. By extrapolation, it would
require years for it to assemble the 3 billion base pairs of the human genome. How would
our various suitors do in coming up with more efficient hardware?
Only Compaq and IBM agreed to the challenge. In the first run of Compaq’s Alpha chip, we
went from taking days to nineteen hours, and then finally nine hours. The best that IBM
could manage was thirty-six hours. My programmers wanted the Alpha chip and the results of
the challenge left no doubt that was the one to go with. IBM knew it had not done well and
asked me what it would take to get the contract. I bluntly told them that IBM would have
to provide the system for free and include a development team to get it up and running.
While IBM was contemplating my reply, it dawned on me that I might not have made a
particularly good proposal: I had no leverage if the system was free, and I could hardly
withhold a payment for poor performance. I realized that I had to pay for what I really
wanted, for what had the best chance to work in an area that no one had ever been before.
The CEO of Compaq flew out to meet with me and to pledge his commitment to make every
effort to guarantee the success of our effort. He wanted his computers to be the ones that
carried out the largest calculation in the history of biology and medicine to date. After
a few days I signed the Compaq contract and called the CEO to tell him that I had accepted
his offer. A half an hour later I was about to phone Nick at IBM to give him my decision
when he called me instead. He had just met Lou Gerstner, the IBM CEO, who authorized him
to provide the entire system gratis. I responded that I would have been interested thirty
minutes earlier but had just signed the deal with Compaq. He wished me well and said that
when the Compaq computers failed, they would be waiting. But I could not let his offer
even enter my head, for I could not countenance failure: For this project there were no
second chances.
….
With its Compaq Alpha chip the Celera computer could top around 1.2 teraflops (teraops),
equivalent to 1.2 trillion calculations per second. The computer also had 4 gigabytes of
RAM and around 10 terabytes, or ten thousand gigabytes, of hard disk storage space.
Peterson’s team would come to be incredibly proud of what they had built and the speed
with which they accomplished it, an unprecedented achievement in the computer world of the
day. In 1999 our computer was rated by Compaq engineers as the third largest in the world
and the largest computer in civilian hands. (Today it would not be in the top few hundred,
and even PCs can accommodate 64 gigabytes of RAM.) Overseeing all this would be a Star
Trek–style control room where giant wall screens and dozens of smaller computer displays
tracked the CPU utilization, the computer room temperature, who was in the facility, CNN,
the weather, the state of Internet traffic, the 300 ABI 3700 DNA sequencers, the power
grid, the extent of database use by each subscriber, and, for the sake of Tony White, the
Celera stock price.
Venter, J. Craig. A Life Decoded: My Genome: My Life (Function). Kindle Edition.
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se Wow, that Alpha number is amazing. Funny that
the VAX 780 was half the speed of an 11/83. Did the 780 have an optional separate FPP? I
forget. I wonder what an Aridus (VAX 9000) would produce.
2:38 p.m.
New subject: Alpha Chip performance
Mark,
I think that the genome mapping effort may have used the Tru64 Unix as the OS. In
1998, my company had an outside firm sequence two of the micro-organisms they used to
produce lysine and a vitamin C precursor. At the time each shotgun assembly based genome
project cost $1 million each. The resulting data was delivered on a Tru64 Unix Alpha. The
software they used at the time was written mostly in PERL with some C code.
Best,
Mark
On Apr 13, 2026, at 5:56 AM, Mark Wickens
<mark(a)wickensonline.co.uk> wrote:
I have a rack mount DEC Alpha that was used as part of the genome mapping project, picked
up from one of the ex-employees from the Cambridge area. I had two, but gifted one to
Pete. It’s been in the garage for a long time, so not sure what state it is in, I think
they are rack mount 3000/600s or a close model.
Mark.
On 11 Apr 2026, at 18:47, Mark Matlock
<mark(a)matlockfamily.com> wrote:
I posted some old benchmark data I found on various PDP-11s and VAXes that I collected
down through the years. Johnny mentioned he thought the 11/84 numbers looked off and I
thought so too. So I reran the 11/84 tests as well as the 11/83 tests and the results are
below. Also, the VAXes did not have Floating Point accelerators since they belonged to our
corporate I.T. group who preferred to compute with integers.
System Sieve Flops Sieve Float Dhrystones
(Sec) VUPS. VUPS
PDP 11/23 2.027900 9693 .11 .05
PDP 11/24 11500 .06
PDP 11/44 .568600 61473 .39 .33
PDP 11/73 .319948 38837 .69 .21 833
PDP 11/83 .241563 359416 .92 1.92 1153
PDP 11/84 .236615 365645 .94 1.95 1200
M100-04 .218359 382592 1.02 2.04 1250
VAX 11/780 .222200 187135 1.00 1.00 1500
uVAX II .259100 144829 .86 .77
VAX 8600 .059300 1035673 3.75 5.53
VAX 8700 .044920 885201 4.95 4.73
VAX 6420 .032160 1412804 6.91 7.55 17141
VAX 6610 .007305 9230000 30.42 49.32 66578
VAX 3500 .084370 525590 2.63 2.81 5612
MV3100 10e .057030 766470 3.90 4.10 8834
MV3100 30 .038906 1132743 5.71 6.05 15974
MV3100 80 .022187 1987578 10.01 10.62 22727
VS4000 90A .007289 9270000 30.48 49.54 66578
Alpha 666Mhz .000340 204000000 653.53 1090 2783964
Paul commented on the Alpha’s performance that came from my XP1000 (BLISH on HECnet)
workstation. It reminded me of a couple passages in the book “A Life Decoded” by Craig
Venter who led the private effort to sequence the human genome. I thought this group might
enjoy a couple passages from the book. I had lunch with Craig Venter at my lab when we
licensed some technology from one of his companies, Synthetic Genomics, where I first
learned about the role of Alphas in the Human Genome Project.
Best,
Mark
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se On Apr 10, 2026, at 3:35 PM, Dave McGuire
<mcguire(a)neurotica.com> wrote:
On 4/10/26 16:23, Paul Koning wrote:
To make sense of the claims and counterclaims by the competing computer manufacturers, I
decided to do an experiment with the assembler that was being used routinely for
sequencing at TIGR. With the Sun computers that we ran it on, a simple (relative to human)
genome such as Haemophilus required several days to assemble. By extrapolation, it would
require years for it to assemble the 3 billion base pairs of the human genome. How would
our various suitors do in coming up with more efficient hardware?
Only Compaq and IBM agreed to the challenge. In the first run of Compaq’s Alpha chip, we
went from taking days to nineteen hours, and then finally nine hours. The best that IBM
could manage was thirty-six hours. My programmers wanted the Alpha chip and the results of
the challenge left no doubt that was the one to go with. IBM knew it had not done well and
asked me what it would take to get the contract. I bluntly told them that IBM would have
to provide the system for free and include a development team to get it up and running.
While IBM was contemplating my reply, it dawned on me that I might not have made a
particularly good proposal: I had no leverage if the system was free, and I could hardly
withhold a payment for poor performance. I realized that I had to pay for what I really
wanted, for what had the best chance to work in an area that no one had ever been before.
The CEO of Compaq flew out to meet with me and to pledge his commitment to make every
effort to guarantee the success of our effort. He wanted his computers to be the ones that
carried out the largest calculation in the history of biology and medicine to date. After
a few days I signed the Compaq contract and called the CEO to tell him that I had accepted
his offer. A half an hour later I was about to phone Nick at IBM to give him my decision
when he called me instead. He had just met Lou Gerstner, the IBM CEO, who authorized him
to provide the entire system gratis. I responded that I would have been interested thirty
minutes earlier but had just signed the deal with Compaq. He wished me well and said that
when the Compaq computers failed, they would be waiting. But I could not let his offer
even enter my head, for I could not countenance failure: For this project there were no
second chances.
….
With its Compaq Alpha chip the Celera computer could top around 1.2 teraflops (teraops),
equivalent to 1.2 trillion calculations per second. The computer also had 4 gigabytes of
RAM and around 10 terabytes, or ten thousand gigabytes, of hard disk storage space.
Peterson’s team would come to be incredibly proud of what they had built and the speed
with which they accomplished it, an unprecedented achievement in the computer world of the
day. In 1999 our computer was rated by Compaq engineers as the third largest in the world
and the largest computer in civilian hands. (Today it would not be in the top few hundred,
and even PCs can accommodate 64 gigabytes of RAM.) Overseeing all this would be a Star
Trek–style control room where giant wall screens and dozens of smaller computer displays
tracked the CPU utilization, the computer room temperature, who was in the facility, CNN,
the weather, the state of Internet traffic, the 300 ABI 3700 DNA sequencers, the power
grid, the extent of database use by each subscriber, and, for the sake of Tony White, the
Celera stock price.
Venter, J. Craig. A Life Decoded: My Genome: My Life (Function). Kindle Edition.
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se Wow, that Alpha number is amazing. Funny that
the VAX 780 was half the speed of an 11/83. Did the 780 have an optional separate FPP? I
forget. I wonder what an Aridus (VAX 9000) would produce.
11 Apr
11 Apr
1:58 a.m.
New subject: Ooh, Saturn!? (Was: Re: Re: quick help on RSX FORTRAN problem?
On Fri, Apr 10, 2026, 7:55 AM Mark Matlock <mark(a)matlockfamily.com> in one
of my Saturn Calc spreadsheets (that I can now read once again).
Mark! I've been wanting Saturn so long! What's the news that enables you to
read your old sheets again? And may I have a copy? :)
Thx
jake
9:54 p.m.
New subject: Ooh, Saturn!? (Was: Re: Re: quick help on RSX FORTRAN problem?
Jacob,
I have also been waiting a long time to be able to use Saturn Calc and Graph. Over the
years, I’ve collected various distributions but the licenses that I had for the RSX
version no longer seemed to work. It was distributed as task images, instead of object
libraries which would have been easier to hack. The Saturn Calc task would check for a
couple files and it is had not been modified by the license key program it just exited.
A good friend, Lee Gleason developed some fantastic tools (see
https://rsx11.blogspot.com/2026/02/ ) to be able to get a t-bit trace of the executing
Saturn Calc task that recorded the PC and the first word of the instruction being
executed. However RSX works very hard not to allow a task to run with the t-bit trap set.
Lee had to modify both INS and FIX in multiple places to NOT clear the t-bit trap in the
task header PSW if it is set. When the program exited since the license had not activated
it, we would look at the last instruction, an EMT 377, to call RSX EXIT$ directive. Then
we would work backward to the conditional branch that could have skipped over the exit and
make it unconditional.
These tasks are heavily overlaid so one also has to find which overlay has a EMT 377
in the correct PC value, then find the location of that overlay in the task image. This
involved a lot of octal decoding to PDP-11 instructions with ZAP. Each of the many Saturn
tasks had to be hacked and they had a couple spots that had to be ZAPped. But now we have
working versions of Saturn Calc, Graph and WP and are just finishing checking to see if
anything is broke.
So far it looks good, but there are a couple caveats. First, the RSX Saturn software
doesn’t understand named directories so you should be in a UIC based directory when you
use it. Second, there is an obscure bug that I have not been able to solve and don’t know
if it was always there or was somehow introduced by our hacks and zaps. It involves SUM or
AVG calculations across a range when the range of input values are calculated. If they
input cells have standard numbers, it works fine. I came up with a work around that can be
used if one really needs that functionality.
Saturn Graph is working very well. I can create a line, bar or pie chart either in SIG
or from a Calc spreadsheet, then display it on a VT240, VT330 or VT340 Regis terminal,
then when I’m ready to make a hard copy send it to a (HPGL) HP7550 plotter or even a LA50
(sixel) printer. The VT340 mouse even works with the drawing program.
I’ve created a command file that will install everything and I would be interested in a
beta tester or two who are somewhat familiar with Saturn to see if there are any issues
remaining. Saturn provided many example files and I’m including them as well. There are in
total about 7500 blocks in 190 files.
If you have an RSX system on HECnet, I can put them where you could NFT them back to
your system. If not let me know and I can package things in a disk image for ftp or wget.
Ultimately, Johnny said he might be interested in creating an RPM package.
Best,
Mark Matlock
On Apr 10, 2026, at 6:58 PM, Jacob Ritorto
<jacob.ritorto(a)gmail.com> wrote:
On Fri, Apr 10, 2026, 7:55 AM Mark Matlock <mark(a)matlockfamily.com
<mailto:mark@matlockfamily.com>> in one of my Saturn Calc spreadsheets (that I
can now read once again).
Mark! I've been wanting Saturn so long! What's the news that enables you to read
your old sheets again? And may I have a copy? :)
Thx
jake
15 Apr
15 Apr
2:26 a.m.
New subject: Ooh, Saturn!? (Was: Re: Re: quick help on RSX FORTRAN problem?
5:13 a.m.
New subject: Ooh, Saturn!? (Was: Re: Re: quick help on RSX FORTRAN problem?
Jacob,
I’m currently working on a README.1ST type of overview document which I can send you
tomorrow as I am just adding a new section on the use of Saturn Graph with Rene Richarz
TEK4010 emulator. If you have a VT240, VT330 or VT340 you can use the Regis graphics on
them. Saturn Calc and WP will work with any VT or VT emulation as long as the PF1-PF4 keys
are mapped.
I have a disk image I’m also working on that will make the distribution easier, but
it’s not ready yet so the quickest way to take a look at it is to start transferring the
individual files from RDP1::DU1:[DECNET] I’ve put the ~190 files, ~7500 blocks (lots of
examples) in the default DECnet directory. I’d suggest transferring with the NFT /BK block
mode transfer switch since we are going from RSX to RSX. NFT is much faster that way.
In the files INSAT.CMD is a command file that will copy the needed .SAT and .HLP files,
set the global logical needed and install the various tasks. I just checked and it does
expect the Saturn distribution to be at LB:[10,3] so if that works ok for you good,
otherwise you can make a quick edit to INSAT.CMD
I have the most documentation for Saturn Calc, a bit on Graph, but little on WP so I’m
looking for that. Fortunately, all of these programs are quite easy to learn. I’ll also
send what documentation I have tomorrow and I know Johnny has some Saturn manuals on MIM.
I’d love to hear about any discoveries or problems you run into with the software.
Also, its great to hear you have a running real 11/70 !
Best Regards,
Mark
On Apr 14, 2026, at 7:26 PM, Jacob Ritorto
<jacob.ritorto(a)gmail.com> wrote:
Mark, This is really wonderful news, I am so appreciative of your and Lee’s work!
I’ll help with anything you say - I have CHOIPN:: and THNITH::, real RSX 11/70 and ‘83 on
HECnet and would be very happy to grab the kit and test at the very least. Just let me
know what to do and what you think needs exercise. I’m most interested in WP and maybe
Graph.
Thank you!
—jake
On Apr 11, 2026, at 15:54, Mark Matlock
<mark(a)matlockfamily.com> wrote:
Jacob,
I have also been waiting a long time to be able to use Saturn Calc and Graph. Over
the years, I’ve collected various distributions but the licenses that I had for the RSX
version no longer seemed to work. It was distributed as task images, instead of object
libraries which would have been easier to hack. The Saturn Calc task would check for a
couple files and it is had not been modified by the license key program it just exited.
A good friend, Lee Gleason developed some fantastic tools (see
https://rsx11.blogspot.com/2026/02/ ) to be able to get a t-bit trace of the executing
Saturn Calc task that recorded the PC and the first word of the instruction being
executed. However RSX works very hard not to allow a task to run with the t-bit trap set.
Lee had to modify both INS and FIX in multiple places to NOT clear the t-bit trap in the
task header PSW if it is set. When the program exited since the license had not activated
it, we would look at the last instruction, an EMT 377, to call RSX EXIT$ directive. Then
we would work backward to the conditional branch that could have skipped over the exit and
make it unconditional.
These tasks are heavily overlaid so one also has to find which overlay has a EMT 377
in the correct PC value, then find the location of that overlay in the task image. This
involved a lot of octal decoding to PDP-11 instructions with ZAP. Each of the many Saturn
tasks had to be hacked and they had a couple spots that had to be ZAPped. But now we have
working versions of Saturn Calc, Graph and WP and are just finishing checking to see if
anything is broke.
So far it looks good, but there are a couple caveats. First, the RSX Saturn software
doesn’t understand named directories so you should be in a UIC based directory when you
use it. Second, there is an obscure bug that I have not been able to solve and don’t know
if it was always there or was somehow introduced by our hacks and zaps. It involves SUM or
AVG calculations across a range when the range of input values are calculated. If they
input cells have standard numbers, it works fine. I came up with a work around that can be
used if one really needs that functionality.
Saturn Graph is working very well. I can create a line, bar or pie chart either in SIG
or from a Calc spreadsheet, then display it on a VT240, VT330 or VT340 Regis terminal,
then when I’m ready to make a hard copy send it to a (HPGL) HP7550 plotter or even a LA50
(sixel) printer. The VT340 mouse even works with the drawing program.
I’ve created a command file that will install everything and I would be interested in
a beta tester or two who are somewhat familiar with Saturn to see if there are any issues
remaining. Saturn provided many example files and I’m including them as well. There are in
total about 7500 blocks in 190 files.
If you have an RSX system on HECnet, I can put them where you could NFT them back to
your system. If not let me know and I can package things in a disk image for ftp or wget.
Ultimately, Johnny said he might be interested in creating an RPM package.
Best,
Mark Matlock
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se On Apr 10, 2026, at 6:58 PM, Jacob Ritorto
<jacob.ritorto(a)gmail.com> wrote:
On Fri, Apr 10, 2026, 7:55 AM Mark Matlock <mark(a)matlockfamily.com
<mailto:mark@matlockfamily.com>> in one of my Saturn Calc spreadsheets (that I
can now read once again).
Mark! I've been wanting Saturn so long! What's the news that enables you to read
your old sheets again? And may I have a copy? :)
Thx
jake
11:22 a.m.
New subject: Ooh, Saturn!? (Was: Re: Re: quick help on RSX FORTRAN problem?
NFT should default to block mode if you don't say anything, and it's
between two RSX systems. But if possible, use FTP instead, since it will
be much faster.
The only sad thing about the Saturn software, so far, seems to be that
it don't deal with named directories. Which is annoying. Not trivial to
fix, but maybe someone will feel enthusiastic enough to maybe work on
that one day...
Johnny
On 15/04/2026 05.13, Mark Matlock wrote:
Jacob,
I’m currently working on a README.1ST type of overview document
which I can send you tomorrow as I am just adding a new section on the
use of Saturn Graph with Rene Richarz TEK4010 emulator. If you have a
VT240, VT330 or VT340 you can use the Regis graphics on them. Saturn
Calc and WP will work with any VT or VT emulation as long as the PF1-PF4
keys are mapped.
I have a disk image I’m also working on that willmake the
distribution easier, but it’s not ready yet so the quickest wayto take
a look at it is to start transferring the individual files from
RDP1::DU1:[DECNET] I’ve put the ~190 files, ~7500 blocks (lots of
examples) in the default DECnet directory. I’d suggest transferring with
the NFT /BK block mode transfer switch since we are going from RSX to
RSX. NFT is much faster that way.
In the files INSAT.CMD is a command file that will copy the
needed .SAT and .HLP files, set the global logical needed and install
the various tasks. I just checked and it does expect the Saturn
distribution to be at LB:[10,3] so if that works ok for you good,
otherwise you can make a quick edit to INSAT.CMD
I have the most documentation for Saturn Calc, a bit on Graph, but
little on WP so I’m looking for that. Fortunately, all of theseprograms
are quite easy to learn. I’ll also send what documentation I have
tomorrow and I know Johnny has some Saturn manuals on MIM.
I’d love to hear about any discoveries or problems you run into with
the software. Also, its great to hear you have a running real 11/70 !
Best Regards,
Mark
On Apr 14, 2026, at 7:26 PM, Jacob Ritorto
<jacob.ritorto(a)gmail.com>
wrote:
Mark, This is really wonderful news, I am so appreciative of your and
Lee’s work!
I’ll help with anything you say - I have CHOIPN:: and THNITH::, real
RSX 11/70 and ‘83 on HECnet and would be very happy to grab the kit
and test at the very least. Just let me know what to do and whatyou
think needs exercise. I’m most interested in WP and maybe Graph.
Thank you!
—jake
On Apr 11, 2026, at 15:54, Mark Matlock
<mark(a)matlockfamily.com> wrote:
Jacob,
I have also been waiting a long time to be able to use Saturn
Calc and Graph. Over the years, I’ve collected various distributions
but the licenses that I had for the RSX version no longer seemed to
work. It was distributed as task images, instead of object libraries
which would have been easier to hack. The Saturn Calc task would
check for a couple files and it is had not been modified by the
license key program it just exited.
A good friend, Lee Gleason developed some fantastic tools (see
https://rsx11.blogspot.com/2026/02/ <https://
rsx11.blogspot.com/2026/02/> ) to be able to get a t-bit trace of the
executing Saturn Calc task that recorded the PC and the first word of
the instruction being executed. However RSX works very hard not to
allow a task to run with the t-bit trap set. Lee had to modify both
INS and FIX in multiple places to NOT clear the t-bit trap in the
task header PSW if it is set. When the program exited since the
license had not activated it, we would look at the last instruction,
an EMT 377, to call RSX EXIT$ directive. Then we would work backward
to the conditional branch that could have skipped over the exit and
make it unconditional.
These tasks are heavily overlaid so one also has to find which
overlay has a EMT 377 in the correct PC value, then find the location
of that overlay in the task image. This involved a lot of octal
decoding to PDP-11 instructions with ZAP. Each of the many Saturn
tasks had to be hacked and they had a couple spots that had to be
ZAPped. But now we have working versions of Saturn Calc, Graph and WP
and are just finishing checking to see if anything is broke.
So far it looks good, but there are a couple caveats. First, the
RSX Saturn software doesn’t understand named directories so you
should be in a UIC based directory when you use it. Second, there is
an obscure bug that I have not been able to solve and don’t know if
it was always there or was somehow introduced by our hacks and zaps.
It involves SUM or AVG calculations across a range when the range of
input values are calculated. If they input cells have standard
numbers, it works fine. I came up with a work around that can be used
if one really needs that functionality.
Saturn Graph is working very well. I can create a line, bar orpie
chart either in SIG or from a Calc spreadsheet, then display it on a
VT240, VT330 or VT340 Regis terminal, then when I’m ready to make a
hard copy send it to a (HPGL) HP7550 plotter or even a LA50 (sixel)
printer. The VT340 mouse even works with the drawing program.
I’ve created a command file that will install everything and I
would be interested in a beta tester or two who are somewhat familiar
with Saturn to see if there are any issues remaining. Saturn provided
many example files and I’m including them as well. There are in total
about 7500 blocks in 190 files.
If you have an RSX system on HECnet, I can put them where you could
NFT them back to your system. If not let me know and I can package
things in a disk image for ftp or wget. Ultimately, Johnny said he
might be interested in creating an RPM package.
Best,
Mark Matlock
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se On Apr 10, 2026, at 6:58 PM, Jacob Ritorto
<jacob.ritorto(a)gmail.com>
wrote:
On Fri, Apr 10, 2026, 7:55 AM Mark Matlock <mark(a)matlockfamily.com
<mailto:mark@matlockfamily.com>> in one of my Saturn Calc
spreadsheets (that I can now read once again).
Mark! I've been wanting Saturn so long! What's the news that enables
you to read your old sheets again? And may I have a copy? :)
Thx
jake
1:15 p.m.
New subject: Ooh, Saturn!? (Was: Re: Re: quick help on RSX FORTRAN problem?
I’m working on finalizing a zipped, RL02 disk image with everything once I finish the
README.1ST doc and I’ll put it at a system that can be reached with FTP or WGET.
It is sad that named directories are not supported. The code base was designed to run
on RT-11 / TSX, RSTS/E and RSX11M/M+ so named directories were not a priority for Saturn
at the time. Later, they migrated it to VAX and the VMS version does support named
directories. Without source code or even object code, it is very difficult to do much. I’m
in communication with the original programmer for Saturn Calc who thinks he might have a
CDROM with the source code in a storage unit in Indiana, but he lives in the Caribbean.
If/when he ever makes it up there to look for it, we might lucky. Just finding all the
user manuals has been a challenge. If we did have the source code, I think it would be
possible to make a number of improvements.
Best,
Mark
On Apr 15, 2026, at 4:23 AM, Johnny Billquist
<bqt(a)softjar.se> wrote:
NFT should default to block mode if you don't say anything, and it's between two
RSX systems. But if possible, use FTP instead, since it will be much faster.
The only sad thing about the Saturn software, so far, seems to be that it don't deal
with named directories. Which is annoying. Not trivial to fix, but maybe someone will feel
enthusiastic enough to maybe work on that one day...
Johnny
On 15/04/2026 05.13, Mark Matlock wrote:
Jacob,
I’m currently working on a README.1ST type of overview document which I can send you
tomorrow as I am just adding a new section on the use of Saturn Graph with Rene Richarz
TEK4010 emulator. If you have a VT240, VT330 or VT340 you can use the Regis graphics on
them. Saturn Calc and WP will work with any VT or VT emulation as long as the PF1-PF4 keys
are mapped.
I have a disk image I’m also working on that willmake the distribution easier, but
it’s not ready yet so the quickest wayto take a look at it is to start transferring the
individual files from RDP1::DU1:[DECNET] I’ve put the ~190 files, ~7500 blocks (lots of
examples) in the default DECnet directory. I’d suggest transferring with the NFT /BK block
mode transfer switch since we are going from RSX to RSX. NFT is much faster that way.
In the files INSAT.CMD is a command file that will copy the needed .SAT and .HLP files,
set the global logical needed and install the various tasks. I just checked and it does
expect the Saturn distribution to be at LB:[10,3] so if that works ok for you good,
otherwise you can make a quick edit to INSAT.CMD
I have the most documentation for Saturn Calc, a bit on Graph, but little on WP so I’m
looking for that. Fortunately, all of theseprograms are quite easy to learn. I’ll also
send what documentation I have tomorrow and I know Johnny has some Saturn manuals on MIM.
I’d love to hear about any discoveries or problems you run into with the software.
Also, its great to hear you have a running real 11/70 !
Best Regards,
Mark
>> On Apr 14, 2026, at 7:26 PM, Jacob Ritorto <jacob.ritorto(a)gmail.com>
wrote:
>
> Mark, This is really wonderful news, I am so appreciative of your and Lee’s work!
> I’ll help with anything you say - I have CHOIPN:: and THNITH::, real RSX 11/70 and
‘83 on HECnet and would be very happy to grab the kit and test at the very least. Just
let me know what to do and whatyou think needs exercise. I’m most interested in WP and
maybe Graph.
>
> Thank you!
> —jake
>
>> On Apr 11, 2026, at 15:54, Mark Matlock <mark(a)matlockfamily.com> wrote:
>>
>> Jacob,
>> I have also been waiting a long time to be able to use Saturn Calc and Graph.
Over the years, I’ve collected various distributions but the licenses that I had for the
RSX version no longer seemed to work. It was distributed as task images, instead of object
libraries which would have been easier to hack. The Saturn Calc task would check for a
couple files and it is had not been modified by the license key program it just exited.
>>
>> A good friend, Lee Gleason developed some fantastic tools (see
https://rsx11.blogspot.com/2026/02/ <https:// rsx11.blogspot.com/2026/02/> ) to be
able to get a t-bit trace of the executing Saturn Calc task that recorded the PC and the
first word of the instruction being executed. However RSX works very hard not to allow a
task to run with the t-bit trap set. Lee had to modify both INS and FIX in multiple places
to NOT clear the t-bit trap in the task header PSW if it is set. When the program exited
since the license had not activated it, we would look at the last instruction, an EMT 377,
to call RSX EXIT$ directive. Then we would work backward to the conditional branch that
could have skipped over the exit and make it unconditional.
>>
>> These tasks are heavily overlaid so one also has to find which overlay has a
EMT 377 in the correct PC value, then find the location of that overlay in the task image.
This involved a lot of octal decoding to PDP-11 instructions with ZAP. Each of the many
Saturn tasks had to be hacked and they had a couple spots that had to be ZAPped. But now
we have working versions of Saturn Calc, Graph and WP and are just finishing checking to
see if anything is broke.
>>
>> So far it looks good, but there are a couple caveats. First, the RSX Saturn
software doesn’t understand named directories so you should be in a UIC based directory
when you use it. Second, there is an obscure bug that I have not been able to solve and
don’t know if it was always there or was somehow introduced by our hacks and zaps. It
involves SUM or AVG calculations across a range when the range of input values are
calculated. If they input cells have standard numbers, it works fine. I came up with a
work around that can be used if one really needs that functionality.
>>
>> Saturn Graph is working very well. I can create a line, bar orpie chart either
in SIG or from a Calc spreadsheet, then display it on a VT240, VT330 or VT340 Regis
terminal, then when I’m ready to make a hard copy send it to a (HPGL) HP7550 plotter or
even a LA50 (sixel) printer. The VT340 mouse even works with the drawing program.
>>
>> I’ve created a command file that will install everything and I would be
interested in a beta tester or two who are somewhat familiar with Saturn to see if there
are any issues remaining. Saturn provided many example files and I’m including them as
well. There are in total about 7500 blocks in 190 files.
>>
>> If you have an RSX system on HECnet, I can put them where you could NFT them
back to your system. If not let me know and I can package things in a disk image for ftp
or wget. Ultimately, Johnny said he might be interested in creating an RPM package.
>>
>> Best,
>> Mark Matlock
>>
>>> On Apr 10, 2026, at 6:58 PM, Jacob Ritorto <jacob.ritorto(a)gmail.com>
wrote:
>>>
>>>
>>>
>>> On Fri, Apr 10, 2026, 7:55 AM Mark Matlock <mark(a)matlockfamily.com
<mailto:mark@matlockfamily.com>> in one of my Saturn Calc spreadsheets (that I
can now read once again).
>>>
>>>
>>> Mark! I've been wanting Saturn so long! What's the news that enables
you to read your old sheets again? And may I have a copy? :)
>>>
>>> Thx
>>> jake
>>
> _______________________________________________
> HECnet mailing list -- hecnet(a)lists.dfupdate.se
> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
9 Apr
9 Apr
3:51 p.m.
IIRC The FORTRAN runtime is common to all linked programs and I could
easily envision it trying to set something up at startup. I’d have to ask
Dr. Fortran to be sure (whom I’ll be seeing tomorrow if you want me to ask
- while I was never part of TLG, my original Intel office was in back in
ZK02, with them - they never moved when DEC sold them to HP, then Intel -
so I’ve eaten lunch with them for about 20 years now, and the Friday TLG
lunch lives on even after we all have retired).
Clem
Sent from a handheld expect more typos than usual
On Thu, Apr 9, 2026 at 9:25 AM Dave McGuire <mcguire(a)neurotica.com> wrote:
/me slaps forehead
The 11/70's FP board set is flaky, and it has been removed pending
repair. I had forgotten about that. But the "hello world" program
shouldn't use any FP instructions..?
I don't think I can get over to LSSM today, but I will be working
there tomorrow.
-Dave
On 4/8/26 19:59, Johnny Billquist wrote:
Error 2, by the way is usually for one of three
reasons:
1. Task failed at the SVTK$S call (not able to install trap catching for
various traps)
2. Task uses FP instructions, but task was build without /FP, or system
lacks FP hardware support.
3. FCS initialization failure.
Most likely problem would be #2.
Johnny
On 2026-04-08 22:23, Dave McGuire wrote:
--
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
Hey folks, before I start digging into this, I figured I'd ask
here. A simple "hello world" program in F77 on RSX-11M-PLUS fails to
start thusly:
$ run hello
TT3 -- Exiting due to ERROR 2
Task initialization failure
I was trying to move a larger FORTRAN program to this system (the
11/70 at LSSM) and it was dying with this message, so I wrote a
quickie test case to narrow it down. It's just a write to unit 5:
WRITE(5,10)
10 FORMAT(' Hello World!')
END
...compiled with "FORTRAN HELLO", and linked with:
L HELLO,LB:[1,1]F77FCS/LIB
No warnings or errors. It runs fine on my 11/83 at home with a
very similar config. Before I dig in, can anyone quickly point me to
what I'm missing?
Thanks,
-Dave
10 Apr
10 Apr
5:30 a.m.
On 2026-04-09 09:24, Dave McGuire wrote:
/me slaps forehead
The 11/70's FP board set is flaky, and it has been removed pending
repair. I had forgotten about that. But the "hello world" program
shouldn't use any FP instructions..?
Be careful with bad FP and modern(ish) RSTS/E. It will use FP
(and CIS, for that matter) in the monitor, and if your boards are
returning garbage, you can scarfle* your system disk.
* Bonus points for anyone who knows what scarfle means. It's ac-
tually SCRFLE and is a boot command on MAI Basic-4 systems which
erases the system disk you booted from.
2:50 p.m.
On 4/9/26 23:30, Terri Kennedy wrote:
We've pulled it, so there's no further risk at this point.
/me slaps
forehead
The 11/70's FP board set is flaky, and it has been removed pending
repair. I had forgotten about that. But the "hello world" program
shouldn't use any FP instructions..?
Be careful with bad FP and modern(ish) RSTS/E. It will use FP
(and CIS, for that matter) in the monitor, and if your boards are
returning garbage, you can scarfle* your system disk. * Bonus points for anyone who knows what scarfle
means. It's ac-
tually SCRFLE and is a boot command on MAI Basic-4 systems which
erases the system disk you booted from.
Well then. Talk about boot security! ;)
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
3:18 p.m.
On 10/04/2026 05.30, Terri Kennedy wrote:
On 2026-04-09 09:24, Dave McGuire wrote:
I know (heard) that CIS would be used for copying memory around, but
what in the kernel would depend on FPP?
(A little surprising is that RSX don't, however, it will use the block
move instruction of the Mentec processors that have that one.)
In RSX, it only is a topic for context switching and trap handling. The
kernel don't depend on the actual behavior more than in the most basic
sense otherwise (auto increment/decrement being done with the right
amounts, and only the actual registers referred to being changed when
expected, and so on.
/me slaps forehead
The 11/70's FP board set is flaky, and it has been removed pending
repair. I had forgotten about that. But the "hello world" program
shouldn't use any FP instructions..?
Be careful with bad FP and modern(ish) RSTS/E. It will use FP
(and CIS, for that matter) in the monitor, and if your boards are
returning garbage, you can scarfle* your system disk. * Bonus points for anyone who knows what scarfle
means. It's ac-
tually SCRFLE and is a boot command on MAI Basic-4 systems which
erases the system disk you booted from.
Never heard that one. :-)
Johnny
3:46 p.m.
On Apr 10, 2026, at 9:18 AM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 10/04/2026 05.30, Terri Kennedy wrote:
Same in RSTS. If FPP exists the kernel will context switch the FP state, if the currently
executing program has set the flag to ask the kernel to do that. Apart from that, nothing
uses it and the kernel itself doesn't care about the FPP. The only OS I can think of
that actually using floating point in the kernel is TOPS-10; I was told DECnet-10 uses it
in the NSP delay estimation algorithm.
CIS is used for memory copy, which happens in the file system cache code so a
malfunctioning MOVC3 will potentially mess up the file system.
paul
On 2026-04-09 09:24, Dave McGuire wrote:
I know (heard) that CIS would be used for copying memory around, but what in the kernel
would depend on FPP?
(A little surprising is that RSX don't, however, it will use the block move
instruction of the Mentec processors that have that one.)
In RSX, it only is a topic for context switching and trap handling. The kernel don't
depend on the actual behavior more than in the most basic sense otherwise (auto
increment/decrement being done with the right amounts, and only the actual registers
referred to being changed when expected, and so on. /me slaps forehead
The 11/70's FP board set is flaky, and it has been removed pending
repair. I had forgotten about that. But the "hello world" program
shouldn't use any FP instructions..?
Be careful with bad FP and modern(ish)
RSTS/E. It will use FP
(and CIS, for that matter) in the monitor, and if your boards are
returning garbage, you can scarfle* your system disk.
3:51 p.m.
On 10/04/2026 15.46, Paul Koning wrote:
Thanks. That makes sense. About Tops-10 and NSP - a bit surprising,
considering that all other implementations manage to do it without FP.
On Apr 10, 2026, at 9:18 AM, Johnny Billquist
<bqt(a)softjar.se>wrote;wrote:
On 10/04/2026 05.30, Terri Kennedy wrote:
Same in RSTS. If FPP exists the kernel will context switch the FP state, if the
currently executing program has set the flag to ask the kernel to do that. Apart from
that, nothing uses it and the kernel itself doesn't care about the FPP. The only OS I
can think of that actually using floating point in the kernel is TOPS-10; I was told
DECnet-10 uses it in the NSP delay estimation algorithm. On 2026-04-09 09:24, Dave McGuire wrote:
I know (heard) that CIS would be used for copying memory around, but what in the kernel
would depend on FPP?
(A little surprising is that RSX don't, however, it will use the blockmove
instruction of the Mentec processors that have that one.)
In RSX, it only is a topic for context switching and trap handling. The kernel don't
depend on the actual behavior more than in the most basic sense otherwise (auto
increment/decrement being done with the right amounts, and only the actual registers
referred to being changed when expected, and so on. /me slaps forehead
The 11/70's FP board set is flaky, and it has been removed pending
repair. I had forgotten about that. But the "hello world" program
shouldn't use any FP instructions..?
Be careful with bad FP and modern(ish)
RSTS/E. It will use FP
(and CIS, for that matter) in the monitor, and if your boards are
returning garbage, you can scarfle* your system disk. CIS is used for memory copy, which happens in the file
system cache code so a malfunctioning MOVC3 will potentially mess up the file system.
Thanks for confirming. I thought I'd heard something along those lines.
And I do find it a little interesting that RSX don't, especially since
it does check, and use the Mentec instruction that does the same thing,
if it exists.
Johnny
3:58 p.m.
On Apr 10, 2026, at 9:51 AM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 10/04/2026 15.46, Paul Koning wrote:
Thanks. That makes sense. About Tops-10 and NSP - a bit surprising, considering that all
other implementations manage to do it without FP.
I heard it from the guy who did that, their rep on the DECnet review committee, not having
any luck remembering his name right now. My impression is that he did it because he
could, sort of for hack value, rather than because it was necessary. The NSP spec
actually hints pretty well at ways to do it in integer arithmetic, a moving average with
weight 2^n - 1 is an easy shift and add type of thing.
paul
On Apr
10, 2026, at 9:18 AM, Johnny Billquist <bqt(a)softjar.se>wrote;wrote:
On 10/04/2026 05.30, Terri Kennedy wrote:
Same in RSTS. If FPP exists
the kernel will context switch the FP state, if the currently executing program has set
the flag to ask the kernel to do that. Apart from that, nothing uses it and the kernel
itself doesn't care about the FPP. The only OS I can think of that actually using
floating point in the kernel is TOPS-10; I was told DECnet-10 uses it in the NSP delay
estimation algorithm. On 2026-04-09 09:24, Dave McGuire wrote:
> /me slaps forehead
>
> The 11/70's FP board set is flaky, and it has been removed pending
> repair. I had forgotten about that. But the "hello world" program
> shouldn't use any FP instructions..?
Be careful with bad FP and modern(ish) RSTS/E. It will use FP
(and CIS, for that matter) in the monitor, and if your boards are
returning garbage, you can scarfle* your system disk.
I know (heard) that CIS would be used for copying memory around, but what in the kernel
would depend on FPP?
(A little surprising is that RSX don't, however, it will use the blockmove
instruction of the Mentec processors that have that one.)
In RSX, it only is a topic for context switching and trap handling. The kernel don't
depend on the actual behavior more than in the most basic sense otherwise (auto
increment/decrement being done with the right amounts, and only the actual registers
referred to being changed when expected, and so on.
4:13 p.m.
Paul Koning <paulkoning(a)comcast.net> wrote:
... My impression is that he did it [floating point in TOPS10 for NSP] because he could
...
FWIW, unlike the -11, floating point hardware was standard on all the 36 bit machines.
So there's no reason not to use it. Even the KA had floating point, albeit in a
somewhat different format.
Bob
4:21 p.m.
On 10/04/2026 16.13, Robert Armstrong wrote:
Yeah. And I suspect that might have been a bit of the reasoning.
However, performance wise I would still expect it to be much worse, and
for no really good reason in this case.
But I guess it's not in any critical path anyway. :-)
Johnny
Paul Koning
<paulkoning(a)comcast.net> wrote:
... My impression is that he did it [floating point in TOPS10 for NSP] because he could
...
FWIW, unlike the -11, floating point hardware was standard on all the 36 bit machines.
So there's no reason not to use it. Even the KA had floating point, albeit in a
somewhat different format.
9:39 p.m.
On 2026-04-10 09:46, Paul Koning wrote:
Same in RSTS. If FPP exists the kernel will context
switch the FP
state, if the currently executing program has set the flag to ask the
kernel to do that. Apart from that, nothing uses it and the kernel
itself doesn't care about the FPP.
I definitely had disk block addressing go wonky* in a late V9.x
release. Diagnostics detected a bad FPP and after I replaced it,
RSTS/E (the OS and utilities part, not just user apps) was happy
again.
Did the change from CSPCOM to actual BP2 for CUSPs drag in some
FP stuff? That shouldn't have affected the monitor, though. I'll
need to go look in the FIP source code...
* For other folks, RSTS/E goes out of its way to keep most file-
system stuff in 16-bit ints or smaller. This does result in very
large pack cluster sizes on "big" (for the time) disks like the
RP07, to keep the total number of clusters below 65536**. Of
course, when you talk about absolute disk blocks they exceed 16
bits pretty quickly.
** If I were ever going to do a RDS 2, these fields would all be
made larger so that tiny files don't take up a whole 64 blocks.
CIS is used for memory copy, which happens in the file
system cache
code so a malfunctioning MOVC3 will potentially mess up the file
system.
I wonder if that was added in anticipation of the PDP-11/74
(the CIS one, not the renamed 11/70MP). It certainly isn't much
of a win over a processor move loop on an 11/23 or 11/24, and
the only other PDP-11 that had CIS was the 11/44 (where it was
pretty good, but nowhere the screamer the 11/74 was***). Or may-
be DEC thought the J11 would still be available with CIS. In-
stead the J11 limped out the door without ever meeting its 20MHz
clock goal, and was the subject of multiple recalls (along with
its FPA, and PMI memory that corrupted memory contents during
some block mode DMA operations).
*** The 11/44's CIS chomps through data 16 bits at a time inter-
nally. The KE74 (11/70 CIS) chomped more bits at a time and also
had a completely separate packed/zoned decimal datapath that
also handled the character move instructions and also prefetched
characters directly via the 32-bit memory bus. It was a minimum
of 5x the 11/44's KE44 and could run up to 10x faster for some
operations. This is per someone who developed the microcode and
ran it on actual boards - things had gotten to the point that
the boards were assigned M-numbers (2x M8165 control store, 1 x
M8166-M8168) and a Field Maintenance Print Set was created.
Then the project was killed due to it wildly outperforming the
VAX-11/780 on industry-standard COBOL benchmarks. Since "VAX
was the future", the KB11-E 11/74 never saw the light of day.
Then the 11/70MP project (multiprocessor 11/70) took over the
11/74 name (which is why extant photographs show a mishmash of
11/74 and 11/70MP on the front panels and cabinetry). That one
was cancelled due to maintenance complexity as well as every
order needing to be sent to the engineering team (not just the
project management) for configuration validation. Those two
different stories got combined by rumor and hearsay into one
single reason DEC cancelled the 11/70 improvements, although
they were two separate projects with separate reasons for can-
cellation.
10:36 p.m.
On Apr 10, 2026, at 3:39 PM, Terri Kennedy
<terri-hecnet(a)glaver.org> wrote:
On 2026-04-10 09:46, Paul Koning wrote:
You mean file system troubles with a bad FPP that went away when the FPP was fixed?
That's very curious, because I know for certain that there are no FPP instructions
anywhere except context switching.
Same in RSTS. If FPP exists the kernel will
context switch the FP
state, if the currently executing program has set the flag to ask the
kernel to do that. Apart from that, nothing uses it and the kernel
itself doesn't care about the FPP.
I definitely had disk block addressing go wonky* in a late V9.x
release. Diagnostics detected a bad FPP and after I replaced it,
RSTS/E (the OS and utilities part, not just user apps) was happy
again. Did the change from CSPCOM to actual BP2 for CUSPs
drag in some
FP stuff? That shouldn't have affected the monitor, though. I'll
need to go look in the FIP source code...
Probably not because those CUSPs had to run on no-float machines.
* For other folks, RSTS/E goes out of its way to keep
most file-
system stuff in 16-bit ints or smaller. This does result in very
large pack cluster sizes on "big" (for the time) disks like the
RP07, to keep the total number of clusters below 65536**. Of
course, when you talk about absolute disk blocks they exceed 16
bits pretty quickly.
** If I were ever going to do a RDS 2, these fields would all be
made larger so that tiny files don't take up a whole 64 blocks.
RSTS addresses file system elements by 16 bit "device cluster" numbers. The
device cluster size for a given disk is the smallest power of two such that the number of
device clusters fits in 16 bits. The largest DCS is 64 for reasons having to do with how
this stuff is encoded in various places (it could allow 128 if someone really wanted it)
so the max device size is 2^22 blocks. That means an RA73 just barely fits within the
limit, and anything larger would not work.
The disk drivers actually take 24 bit block numbers, and file I/O also uses 24 block
numbers just in case you have a crazy large file. RSTS got "large file"
support, meaning more than 64k blocks, quite early on, I'm not quite sure when. Not
in V4 I think, even though it supported the RP03, but probably soon after.
CIS is used
for memory copy, which happens in the file system cache
code so a malfunctioning MOVC3 will potentially mess up the file
system.
I wonder if that was added in anticipation of the PDP-11/74
(the CIS one, not the renamed 11/70MP).
11 Apr
11 Apr
5:22 a.m.
On 2026-04-10 16:36, Paul Koning wrote:
Yup. In fact, Fred Knight was down here at the time on other
RSTS/E business with me and saw it too.
Yup. And unlike Ultrix-11 (if you've been following the VCFED
thread) it doesn't do stuff like install a mishmash of I&D and
non-I&D binaries on an 11/40 without I&D, and apparently there's
an assumption about Supervisor Mode somewhere in the Ultrix-11
kernel as well. Bob Supnik wrote a small treatise "Bug, Feature,
or Code Rot? Adventures in OS Debugging" where he mentions that
late-era DEC operating systems may never have been tested on
"supported" hardware that was no longer available to the devel-
opers, nor clean installs being done as customers just did up-
grades. One of the reasons Fred would visit is I could put to-
gether just about any bizarre combination of hardware. The "swap
a unit plug between drives on different MSCP controllers causes
a crash" was diagnosed at my place, because I was willing to
put four UDA50s in an 11/44 with 16 RA81s, four on each con-
troller.
True for the most part. Better to say "the _minimum_ cluster
size", as you can initialize an RL02 with cluster size 64 if
you want.
I agree. There was no point in using CIS on the 11/23 and
/24.
Did they have the automated "lights off" when you were there?
I remember many an evening phone call with RSTS folks which
would be interrupted by "bleep-it, I have to go turn the lights
back on".
On Apr 10,
2026, at 3:39 PM, Terri Kennedy <terri-hecnet(a)glaver.org>
wrote:
I definitely had disk block addressing go wonky* in a late V9.x
release. Diagnostics detected a bad FPP and after I replaced it,
RSTS/E (the OS and utilities part, not just user apps) was happy
again.
You mean file system troubles with a bad FPP that went away when the
FPP was fixed? That's very curious, because I know for certain that
there are no FPP instructions anywhere except context switching. Did the
change from CSPCOM to actual BP2 for CUSPs drag in some
FP stuff? That shouldn't have affected the monitor, though. I'll
need to go look in the FIP source code...
Probably not because those CUSPs had to run on no-float machines. ** If I were
ever going to do a RDS 2, these fields would all be
made larger so that tiny files don't take up a whole 64 blocks.
RSTS addresses file system elements by 16 bit "device cluster"
numbers. The device cluster size for a given disk is the smallest
power of two such that the number of device clusters fits in 16 bits. The largest DCS is 64 for reasons having to do with
how this stuff is
encoded in various places (it could allow 128 if someone really wanted
it) so the max device size is 2^22 blocks. That means an RA73 just
barely fits within the limit, and anything larger would not work.
Let's not do the stuff like RT-11 did with putting extension
bits in unrelated parts of a data structure because that's where
the unused space was. Although RT-11 finally did give up and
added .DATE4 rather than trying to shoehorn post-Y2K dates into
the existing .DATE.
The trick with a hypothetical RDS 2 is it still has to look
enough like classic RDS 1.x to not break things with assumptions
about cluster size (or even the cluster concept entirely). User
applications "shouldn't" notice (but might require re-linking,
which would imply dealing with things like the Fortran-11 OTS)
but a bunch of stuff in the RSTS/E kit would need to be re-done.
Not just stuff like $DSKINT but even BACKUP. Though I do need
to get into that anyway, as multi-volume tape support is wonky.
BACKUP will tell you "Some data is missing for file xxxxxx.xxx"
at the end of one tape, but that file and several prior files
are on the next tape. And you can't just copy a saveset (with
the default 28K block size) to disk because RMS will refuse to
create a record with a block size that big. So currently it's a
trip through VMS to copy the individual volumes to disk (which
results in one large file containing the individual volumes),
then copy that back to tape and restore it on the RSTS/E system.
But you still get the "Missing data" error on the volume breaks.
OTOH, the saveset I have that exhibits this behavior was writ-
ten on an RQZX1, and that board was never fully debugged before
it shipped (I tried, but got overruled, as did Vernon - at least
they used my re-worded menu code and not the horribly botched
German->English translation ROI gave them). Which reminds me,
I have the source for the PDP-11 code the RQXZ1 gives you when
you boot from the phantom unit for setup. It's on a DSP3105 w/
a bad logic board, but there are enough other goodies on there
that I should try to resurrect it - I just need to get Dave a
replacement logic board from somewhere.
The disk drivers actually take 24 bit block numbers,
and file I/O also
uses 24 block numbers just in case you have a crazy large file. RSTS
got "large file" support, meaning more than 64k blocks, quite early
on, I'm not quite sure when. Not in V4 I think, even though it
supported the RP03, but probably soon after.
There's a bunch of mappings which will go from 512-byte LBN
to the appropriate C/H/S for a "classic" drive, or just pass
the LBN in the case of MSCP. I don't know why RSTS/E would use
the FPP if present to do 24-bit math - it isn't _that_ hard to
do math when treating two 16-bit words as a 32-bit value, as
long as you have enough free general registers or are willing
to PUSH/POP to get them.
It is certainly possible that the FPP problem also triggered
issues with non-FP instructions, even though the basic diagnos-
tics for the 11/70 all passed. As they say, "Never test for a
condition you don't know how to handle" (or never expected).
Also, "passes diagnostics" or "fails diagnostics" is no in-
dication if an operating system will fail (or work) - SIMH
(at least the version used for the PiDP-11) fails just about
every 11/70 diagnostic, but still runs operating systems just
fine.
The FP11-C is an interesting beast as it is asynchronous to
the CPU, unlike the FP11-B which ran in lock-step.
I wonder if
that was added in anticipation of the PDP-11/74
(the CIS one, not the renamed 11/70MP).
Probably. I remember that machine sitting just across the lab from
ARK, the main RSTS development machine, and I believe the COBOL-11
team was just down the hall from the RSTS cubicles.
10:16 p.m.
On Apr 10, 2026, at 11:22 PM, Terri Kennedy
<terri-hecnet(a)glaver.org> wrote:
On 2026-04-10 16:36, Paul Koning wrote:
Yup. In fact, Fred Knight was down here at the time on other
RSTS/E business with me and saw it too.
Very curious. The only explanation I can think of is a hardware defect that breaks the
integrity of the integer data path.
On Apr
10, 2026, at 3:39 PM, Terri Kennedy <terri-hecnet(a)glaver.org> wrote:
I definitely had disk block addressing go wonky* in a late V9.x
release. Diagnostics detected a bad FPP and after I replaced it,
RSTS/E (the OS and utilities part, not just user apps) was happy
again.
You mean file system troubles with a bad FPP that went away when the
FPP was fixed? That's very curious, because I know for certain that
there are no FPP instructions anywhere except context switching. ...
True for the most part. Better to say "the _minimum_ cluster
size", as you can initialize an RL02 with cluster size 64 if
you want.
DCS is fixed for a given device type. You're thinking of PCS, the Pack Cluster Size,
which is chosen at file system initialization. The rule is that DCS <= PCS <= 64.
Finally, there is the file cluster size, chosen when the file is created. It defaults to
PCS and is subject to PCS <= FCS <= 128. Directory cluster size is also selectable
as PCS <= DirCS <= 64, except that the MFS (on RDS 1) and GFDs have a minimum
cluster size of 4 because of how the lookup tables are stored.
** If I
were ever going to do a RDS 2, these fields would all be
made larger so that tiny files don't take up a whole 64 blocks.
RSTS addresses
file system elements by 16 bit "device cluster"
numbers. The device cluster size for a given disk is the smallest
power of two such that the number of device clusters fits in 16 bits. The largest
DCS is 64 for reasons having to do with how this stuff is
encoded in various places (it could allow 128 if someone really wanted
it) so the max device size is 2^22 blocks. That means an RA73 just
barely fits within the limit, and anything larger would not work.
Let's not do the stuff like RT-11 did with putting extension
bits in unrelated parts of a data structure because that's where
the unused space was. Although RT-11 finally did give up and
added .DATE4 rather than trying to shoehorn post-Y2K dates into
the existing .DATE.
The trick with a hypothetical RDS 2 is it still has to look
enough like classic RDS 1.x to not break things with assumptions
about cluster size (or even the cluster concept entirely). User
applications "shouldn't" notice (but might require re-linking,
which would imply dealing with things like the Fortran-11 OTS)
but a bunch of stuff in the RSTS/E kit would need to be re-done. The disk
drivers actually take 24 bit block numbers, and file I/O also
uses 24 block numbers just in case you have a crazy large file. RSTS
got "large file" support, meaning more than 64k blocks, quite early
on, I'm not quite sure when. Not in V4 I think, even though it
supported the RP03, but probably soon after.
There's a bunch of mappings which will go from 512-byte LBN
to the appropriate C/H/S for a "classic" drive, or just pass
the LBN in the case of MSCP. I don't know why RSTS/E would use
the FPP if present to do 24-bit math - it isn't _that_ hard to
do math when treating two 16-bit words as a 32-bit value, as
long as you have enough free general registers or are willing
to PUSH/POP to get them. It is certainly possible that the FPP problem also
triggered
issues with non-FP instructions, even though the basic diagnos-
tics for the 11/70 all passed. As they say, "Never test for a
condition you don't know how to handle" (or never expected).
Yes, that would be my guess.
Also, "passes diagnostics" or "fails
diagnostics" is no in-
dication if an operating system will fail (or work) - SIMH
(at least the version used for the PiDP-11) fails just about
every 11/70 diagnostic, but still runs operating systems just
fine.
:-)
Conversely, it was well known that RSTS was a better tool for stress-testing a PDP-11 than
the diagnostics. That's why it was used, configuration permitting, for final test of
about to be shipped customer systems.
...
Did they have the automated "lights off" when you were there?
I remember many an evening phone call with RSTS folks which
would be interrupted by "bleep-it, I have to go turn the lights
back on".
No, I left in 1994 and it wasn't done yet, at least not in Littleton MA. I do
remember that chicanery at ZKO circa 2005 (when EqualLogic moved into that space, by then
repurposed into individual sections for multiple companies).
paul
4
days inactive
11
days old
53 comments
10 participants
participants (10)
-
Clem Cole -
Dave McGuire -
Jacob Ritorto -
Johnny Billquist -
Keith Halewood -
Mark Matlock -
Mark Wickens -
Paul Koning -
Robert Armstrong -
Terri Kennedy