Hi,
I'm running TOPS-10 V7.03 on SIMH KL10. I cannot for the life of me get saved executables to run. Here is some console output.

..type hello.for
PROGRAM HELLO
TYPE 10
STOP
10 FORMAT(13H HELLO WORLD!)
END

..compile hello
FORTRAN: HELLO
HELLO

..dir

HELLO FOR 1 <057> 19-Mar-86 DSKB: [12,1]
HELLO REL 1 <057> 19-Mar-86
Total of 2 blocks in 2 files on DSKB: [12,1]

..load hello
LINK: Loading

EXIT

..save hello
HELLO saved

..run hello

?No start adr

..

This also happens on version 7.04 as well as with MACRO programs. Any advice would be appreciated.

On 2023-09-02 20:46, Zach Z wrote:
> Hi,
> I'm running TOPS-10 V7.03 on SIMH KL10. I cannot for the life of me get saved executables to run. Here is some console output.
>
> .type hello.for
> PROGRAM HELLO
> TYPE 10
> STOP
> 10 FORMAT(13H HELLO WORLD!)
> END
>
> .compile hello
> FORTRAN: HELLO
> HELLO
>
> .dir
>
>
> HELLO FOR 1 <057> 19-Mar-86 DSKB: [12,1]
> HELLO REL 1 <057> 19-Mar-86
> Total of 2 blocks in 2 files on DSKB: [12,1]
>
> .load hello
> LINK: Loading
>
> EXIT
>
> .save hello
> HELLO saved
>
> .run hello
>
>
> ?No start adr
>
>
> .
>
> This also happens on version 7.04 as well as with MACRO programs. Any advice would be appreciated.

So it sounds like no start address have been defined.
With FORTRAN I would expect that you would need to link with some
libraries containing the runtime system, which also have the startup bits.

With MACRO - did you give a starting address in the macro sources that
you compiled?

Johnny

On Tuesday, September 5, 2023 at 10:30:47 AM UTC-4, Johnny Billquist wrote:
> On 2023-09-02 20:46, Zach Z wrote:
> > Hi,
> > I'm running TOPS-10 V7.03 on SIMH KL10. I cannot for the life of me get saved executables to run. Here is some console output.
> >
> > .type hello.for
> > PROGRAM HELLO
> > TYPE 10
> > STOP
> > 10 FORMAT(13H HELLO WORLD!)
> > END
> >
> > .compile hello
> > FORTRAN: HELLO
> > HELLO
> >
> > .dir
> >
> >
> > HELLO FOR 1 <057> 19-Mar-86 DSKB: [12,1]
> > HELLO REL 1 <057> 19-Mar-86
> > Total of 2 blocks in 2 files on DSKB: [12,1]
> >
> > .load hello
> > LINK: Loading
> >
> > EXIT
> >
> > .save hello
> > HELLO saved
> >
> > .run hello
> >
> >
> > ?No start adr
> >
> >
> > .
> >
> > This also happens on version 7.04 as well as with MACRO programs. Any advice would be appreciated.
> So it sounds like no start address have been defined.
> With FORTRAN I would expect that you would need to link with some
> libraries containing the runtime system, which also have the startup bits..
>
> With MACRO - did you give a starting address in the macro sources that
> you compiled?
>
> Johnny
probably by now, someone more knowledgeable has probably already answered, but
for macro, just have a label on the start address, then the end statement, give that the label:

title foo

foo: exit
end foo

should work.

i would expect the fortran sample to work as is. not necessary to force link to load libraries a simple fortran program, except in relatively rare instances, like fitting more than one hiseg into the program (perhaps linking 1022 and fortran both?, i forget).

i'm probably being pretty dense (it is something more obvious?)...
just to rule out unlikely things, i'd make sure that there is a start address in the exe file; use filddt to check 120. in fact, start looking at 140 and line feed through a few lines of code - you should see the f10 start up code. if the .exe file ISN'T an .exe file, i think filddt would mention that.

there is a directory switch that shows a field which has the segments labeled (at least our direct did), ie: like LOW+HGH or LOW or LOW+SHR, etc. might be interesting if the core image is not as expected. (forgot the switch name (but remembered for the putty log below)).

just to rule out, do a .SET WATCH ALL to see fortran compiling, and link loading - and to see the program not being overloaded after link exits.

you could also run link and use the save switches if the core image is somehow being corrupt prior to the save command.

not sure everyone's link looks at switch ini, but ours does(but .set watch all would help that become obvious). make sure there are no conflicting switches there for link or f10, etc.

IFF link left the image intact but somehow missing .jbsa, then
..LOAD HELLO
..START 140
and/or
..GET HELLO
..START 140
should work.

i'm probably over/under thinking -- JB is probably more correct - possibly there is no start address in the first place.

-jfg

p.s.: of course this all assumes there is no bug/problem with simh. i use klh10.

p.p.s:
sorry, a bit hard to read with .set watch all set, but shows what it should show, roughly.

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2023.09.05 12:35:06 =~=~=~=~=~=~=~=~=~=~=~..set watch all

..make foo.mac
[16:43:14]
[S:COMPIL 22D(431030)-3 + ]
[]
[S:TECO 124A(355024)-2 + ]
[L11: SOFT0:TECO.INI[10,2004] PC:403532]

[L3: DSK:FOO.MAC[10,2004] PC:405337, error 0]
*[E3: SOFT0:FOO.MAC[10,2004] PC:405355]
title foo
foo: exit
end foo
$$
*exq$$
[R3: SOFT0:FOO.MAC[10,2004] PC:405550]
[0.01 1 15.43 1 10]

..load foo.mac
[16:43:39]
[S:COMPIL 22D(431030)-3 + ]
[L0: SOFT0:FOO.MAC[10,2004] PC:405042]
[L0: SOFT0:FOO.REL[10,2004] PC:403652]
[]
[S:MACRO 53C(257004)-4 + ]
[L3: SOFT0:FOO.MAC[10,2004] PC:420156]
MACRO: foo
[E2: SOFT0:FOO.REL[10,2004] PC:420076]
[L3: SOFT0:FOO.MAC[10,2004] PC:420156]
[R2: SOFT0:FOO.REL[10,2004] PC:417665]
LINK: Loading
[]
[S:LINK 6(404066)-4 + ]
[]
[ + LNKSCN 6(404066)-4]
[L0: SOFT0:SWITCH.INI[10,2004] PC:617753]
[L0: SOFT0:SWITCH.INI[10,2004] PC:617753]
[]
[ + LNKLOD 6(404066)-4]
[L1: SOFT0:FOO.REL[10,2004] PC:630067]
[]
[ + LNKXIT 6(404066)-4]
[]
[:FOO ]

EXIT
[0.03 2 0.18 3 10]

..save
[16:43:42]
[E0: SOFT0:FOO.EXE[10,2004] PC:465036]
FOO saved
[0.00 0 0.06 0 14]

..run foo
[16:43:44]

[FOO ]

EXIT
[0.00 0 0.00 8 0]

..make bar.f10
[16:44:19]
[S:COMPIL 22D(431030)-3 + ]
[]
[S:TECO 124A(355024)-2 + ]

*[L11: SOFT0:TECO.INI[10,2004] PC:403532]
[L3: DSK:BAR.F10[10,2004] PC:405337, error 0]
[E3: SOFT0:BAR.F10[10,2004] PC:405355]
program bar
write(5,10)
10 format(13H Hello World!)
end
$$
*exq$$
[R3: SOFT0:BAR.F10[10,2004] PC:405550]
[0.01 1 50.00 1 10]

..loa bar.f10
[16:45:14]
[S:COMPIL 22D(431030)-3 + ]
[L0: SOFT0:BAR.F10[10,2004] PC:405042]
[L0: DSK:BAR.REL PC:403652, error 0]
[]
[S:FORTRA 11(604004) + from D08B0:FORTRA.EXE[1,4]]
FORTRAN: BAR
[L0: SOFT0:SWITCH.INI[10,2004] PC:414532]
[L0: SOFT0:SWITCH.INI[10,2004] PC:414532]
[L3: SOFT0:BAR.F10[10,2004] PC:402261]
[E1: SOFT0:BAR.REL[10,2004] PC:401651]
[]
[ + FORTB 11(604004)]
BAR
[]
[ + FORTC 11(604004)]
[]
[ + FORTF 11(604004)]
[]
[ + FORTG 11(604004)]
[]
[ + ]
LINK: Loading
[S:LINK 6(404066)-4 + ]
[]
[ + LNKSCN 6(404066)-4]
[L0: SOFT0:SWITCH.INI[10,2004] PC:617753]
[L0: SOFT0:SWITCH.INI[10,2004] PC:617753]
[]
[ + LNKLOD 6(404066)-4]
[L1: SOFT0:BAR.REL[10,2004] PC:630067]
[L1: D08B0:FORLIB.REL[1,4] PC:630067]
[]
[ + LNKXIT 6(404066)-4]
[]
[:BAR ]

EXIT
[0.03 4 0.93 165 6]

..sav
[16:45:18]
[E0: SOFT0:BAR.EXE[10,2004] PC:465036]
BAR saved
[0.01 1 0.18 0 18]

..run bar
[16:45:20]

[BAR ]
[ + FORO11 11(40002)]
Hello World!
CPU time 0.01 Elapsed time 0.03

EXIT
[0.00 0 0.11 12 0]

..r filddt
[16:45:25]

[S:FILDDT 45A(715053)-2]
File: bar
[FL1: SOFT0:BAR.EXE[10,2004] PC:013053]
[Looking at file SOFT:BAR.EXE[10,2004]]
[0 symbols loaded from file]

120/ 1605,,147
140/ 0
141/ 5
142/ 4
143/ ROT 10,@344100(6)
144/ ANDCBB 2,@466336(15)
145/ MOVEM 13,@771330(15)
146/ TLZ @100000(5)
147/ JFCL 0
150/ JSP 16,172
151/ 0
152/ XMOVEI 16,162
153/ PUSHJ 17,1440
154/ PUSHJ 17,1460
155/ XMOVEI 16,160
156/ PUSHJ 17,1466

141/ 5
142/ 4
143/ ROT 10,@344100(6) =$241426,,344100 $6t;$4,6<A $7t;(13H
144/ Hello
145/ Worl
146/ d!)
147/ +
../ JFCL 0

^C
[0.01 3 55.90 81 1]

..dir/examine foo.bar, bar.exe
[16:47:01]
[S:DIRECT 6A(450034)-2 + ]
[L0: SOFT0:SWITCH.INI[10,2004] PC:422475]
[L0: SOFT0:SWITCH.INI[10,2004] PC:422475]
[L1: SOFT0:FOO.EXE[10,2004] PC:400735]

FOO EXE 8 <057> 5-Sep-23 SAV SOFT: [10,2004]
[L1: SOFT0:BAR.EXE[10,2004] PC:400735]
BAR EXE 12 <057> 5-Sep-23 SAV
Total of 20 blocks in 2 files
[0.03 1 0.06 18 0]

On Tuesday, September 5, 2023 at 2:03:08 PM UTC-4, whis292 wrote:
> On Tuesday, September 5, 2023 at 10:30:47 AM UTC-4, Johnny Billquist wrote:
> > On 2023-09-02 20:46, Zach Z wrote:
> > > Hi,
> > > I'm running TOPS-10 V7.03 on SIMH KL10. I cannot for the life of me get saved executables to run. Here is some console output.
> > >
> > > .type hello.for
> > > PROGRAM HELLO
> > > TYPE 10
> > > STOP
> > > 10 FORMAT(13H HELLO WORLD!)
> > > END
> > >
> > > .compile hello
> > > FORTRAN: HELLO
> > > HELLO
> > >
> > > .dir
> > >
> > >
> > > HELLO FOR 1 <057> 19-Mar-86 DSKB: [12,1]
> > > HELLO REL 1 <057> 19-Mar-86
> > > Total of 2 blocks in 2 files on DSKB: [12,1]
> > >
> > > .load hello
> > > LINK: Loading
> > >
> > > EXIT
> > >
> > > .save hello
> > > HELLO saved
> > >
> > > .run hello
> > >
> > >
> > > ?No start adr
> > >
> > >
> > > .
> > >
> > > This also happens on version 7.04 as well as with MACRO programs. Any advice would be appreciated.
> > So it sounds like no start address have been defined.
> > With FORTRAN I would expect that you would need to link with some
> > libraries containing the runtime system, which also have the startup bits.
> >
> > With MACRO - did you give a starting address in the macro sources that
> > you compiled?
> >
> > Johnny
> probably by now, someone more knowledgeable has probably already answered, but
> for macro, just have a label on the start address, then the end statement, give that the label:
>
> title foo
>
> foo: exit
> end foo
>
> should work.
>
> i would expect the fortran sample to work as is. not necessary to force link to load libraries a simple fortran program, except in relatively rare instances, like fitting more than one hiseg into the program (perhaps linking 1022 and fortran both?, i forget).
>
> i'm probably being pretty dense (it is something more obvious?)...
> just to rule out unlikely things, i'd make sure that there is a start address in the exe file; use filddt to check 120. in fact, start looking at 140 and line feed through a few lines of code - you should see the f10 start up code. if the .exe file ISN'T an .exe file, i think filddt would mention that.
>
> there is a directory switch that shows a field which has the segments labeled (at least our direct did), ie: like LOW+HGH or LOW or LOW+SHR, etc. might be interesting if the core image is not as expected. (forgot the switch name (but remembered for the putty log below)).
>
> just to rule out, do a .SET WATCH ALL to see fortran compiling, and link loading - and to see the program not being overloaded after link exits.
>
> you could also run link and use the save switches if the core image is somehow being corrupt prior to the save command.
>
> not sure everyone's link looks at switch ini, but ours does(but .set watch all would help that become obvious). make sure there are no conflicting switches there for link or f10, etc.
>
> IFF link left the image intact but somehow missing .jbsa, then
> .LOAD HELLO
> .START 140
> and/or
> .GET HELLO
> .START 140
> should work.
>
>
>
> i'm probably over/under thinking -- JB is probably more correct - possibly there is no start address in the first place.
>
> -jfg
>
> p.s.: of course this all assumes there is no bug/problem with simh. i use klh10.
>
> p.p.s:
> sorry, a bit hard to read with .set watch all set, but shows what it should show, roughly.
>
> =~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2023.09.05 12:35:06 =~=~=~=~=~=~=~=~=~=~=~=
> .set watch all
>
> .make foo.mac
> [16:43:14]
> [S:COMPIL 22D(431030)-3 + ]
> []
> [S:TECO 124A(355024)-2 + ]
> [L11: SOFT0:TECO.INI[10,2004] PC:403532]
>
> [L3: DSK:FOO.MAC[10,2004] PC:405337, error 0]
> *[E3: SOFT0:FOO.MAC[10,2004] PC:405355]
> title foo
> foo: exit
> end foo
> $$
> *exq$$
> [R3: SOFT0:FOO.MAC[10,2004] PC:405550]
> [0.01 1 15.43 1 10]
>
> .load foo.mac
> [16:43:39]
> [S:COMPIL 22D(431030)-3 + ]
> [L0: SOFT0:FOO.MAC[10,2004] PC:405042]
> [L0: SOFT0:FOO.REL[10,2004] PC:403652]
> []
> [S:MACRO 53C(257004)-4 + ]
> [L3: SOFT0:FOO.MAC[10,2004] PC:420156]
> MACRO: foo
> [E2: SOFT0:FOO.REL[10,2004] PC:420076]
> [L3: SOFT0:FOO.MAC[10,2004] PC:420156]
> [R2: SOFT0:FOO.REL[10,2004] PC:417665]
> LINK: Loading
> []
> [S:LINK 6(404066)-4 + ]
> []
> [ + LNKSCN 6(404066)-4]
> [L0: SOFT0:SWITCH.INI[10,2004] PC:617753]
> [L0: SOFT0:SWITCH.INI[10,2004] PC:617753]
> []
> [ + LNKLOD 6(404066)-4]
> [L1: SOFT0:FOO.REL[10,2004] PC:630067]
> []
> [ + LNKXIT 6(404066)-4]
> []
> [:FOO ]
>
> EXIT
> [0.03 2 0.18 3 10]
>
> .save
> [16:43:42]
> [E0: SOFT0:FOO.EXE[10,2004] PC:465036]
> FOO saved
> [0.00 0 0.06 0 14]
>
> .run foo
> [16:43:44]
>
> [FOO ]
>
> EXIT
> [0.00 0 0.00 8 0]
>
> .make bar.f10
> [16:44:19]
> [S:COMPIL 22D(431030)-3 + ]
> []
> [S:TECO 124A(355024)-2 + ]
>
> *[L11: SOFT0:TECO.INI[10,2004] PC:403532]
> [L3: DSK:BAR.F10[10,2004] PC:405337, error 0]
> [E3: SOFT0:BAR.F10[10,2004] PC:405355]
> program bar
> write(5,10)
> 10 format(13H Hello World!)
> end
> $$
> *exq$$
> [R3: SOFT0:BAR.F10[10,2004] PC:405550]
> [0.01 1 50.00 1 10]
>
> .loa bar.f10
> [16:45:14]
> [S:COMPIL 22D(431030)-3 + ]
> [L0: SOFT0:BAR.F10[10,2004] PC:405042]
> [L0: DSK:BAR.REL PC:403652, error 0]
> []
> [S:FORTRA 11(604004) + from D08B0:FORTRA.EXE[1,4]]
> FORTRAN: BAR
> [L0: SOFT0:SWITCH.INI[10,2004] PC:414532]
> [L0: SOFT0:SWITCH.INI[10,2004] PC:414532]
> [L3: SOFT0:BAR.F10[10,2004] PC:402261]
> [E1: SOFT0:BAR.REL[10,2004] PC:401651]
> []
> [ + FORTB 11(604004)]
> BAR
> []
> [ + FORTC 11(604004)]
> []
> [ + FORTF 11(604004)]
> []
> [ + FORTG 11(604004)]
> []
> [ + ]
> LINK: Loading
> [S:LINK 6(404066)-4 + ]
> []
> [ + LNKSCN 6(404066)-4]
> [L0: SOFT0:SWITCH.INI[10,2004] PC:617753]
> [L0: SOFT0:SWITCH.INI[10,2004] PC:617753]
> []
> [ + LNKLOD 6(404066)-4]
> [L1: SOFT0:BAR.REL[10,2004] PC:630067]
> [L1: D08B0:FORLIB.REL[1,4] PC:630067]
> []
> [ + LNKXIT 6(404066)-4]
> []
> [:BAR ]
>
> EXIT
> [0.03 4 0.93 165 6]
>
> .sav
> [16:45:18]
> [E0: SOFT0:BAR.EXE[10,2004] PC:465036]
> BAR saved
> [0.01 1 0.18 0 18]
>
> .run bar
> [16:45:20]
>
> [BAR ]
> [ + FORO11 11(40002)]
> Hello World!
> CPU time 0.01 Elapsed time 0.03
>
> EXIT
> [0.00 0 0.11 12 0]
>
> .r filddt
> [16:45:25]
>
> [S:FILDDT 45A(715053)-2]
> File: bar
> [FL1: SOFT0:BAR.EXE[10,2004] PC:013053]
> [Looking at file SOFT:BAR.EXE[10,2004]]
> [0 symbols loaded from file]
>
>
> 120/ 1605,,147
> 140/ 0
> 141/ 5
> 142/ 4
> 143/ ROT 10,@344100(6)
> 144/ ANDCBB 2,@466336(15)
> 145/ MOVEM 13,@771330(15)
> 146/ TLZ @100000(5)
> 147/ JFCL 0
> 150/ JSP 16,172
> 151/ 0
> 152/ XMOVEI 16,162
> 153/ PUSHJ 17,1440
> 154/ PUSHJ 17,1460
> 155/ XMOVEI 16,160
> 156/ PUSHJ 17,1466
>
> 141/ 5
> 142/ 4
> 143/ ROT 10,@344100(6) =$241426,,344100 $6t;$4,6<A $7t;(13H
> 144/ Hello
> 145/ Worl
> 146/ d!)
> 147/ +
> ./ JFCL 0
>
> ^C
> [0.01 3 55.90 81 1]
>
>
> .dir/examine foo.bar, bar.exe
> [16:47:01]
> [S:DIRECT 6A(450034)-2 + ]
> [L0: SOFT0:SWITCH.INI[10,2004] PC:422475]
> [L0: SOFT0:SWITCH.INI[10,2004] PC:422475]
> [L1: SOFT0:FOO.EXE[10,2004] PC:400735]
>
>
> FOO EXE 8 <057> 5-Sep-23 SAV SOFT: [10,2004]
> [L1: SOFT0:BAR.EXE[10,2004] PC:400735]
> BAR EXE 12 <057> 5-Sep-23 SAV
> Total of 20 blocks in 2 files
> [0.03 1 0.06 18 0]
as anyone can clearly see, my claims of being able to start at 140 are wrong. so load/start 140 and get/start140 won't work in the fortran example.

I'm still having the same trouble. Here is some terminal output.

..dir

HELLO MAC 1 <057> 5-Sep-23 DSKB: [12,1]
HELLO REL 1 <057> 5-Sep-23
HELLO EXE 8 <057> 5-Sep-23
Total of 10 blocks in 3 files on DSKB: [12,1]

..type hello.mac
TITLE HELLO WORLD
SEARCH UUOSYM
LAB: ASCIZ /Hello World!
/ START: RESET
OUTSTR LAB
MONRT.
END START

..run hello

?No start adr

..

On Tuesday, September 5, 2023 at 6:37:31 PM UTC-4, Zach Z wrote:
> I'm still having the same trouble. Here is some terminal output.
>
> .dir
>
>
> HELLO MAC 1 <057> 5-Sep-23 DSKB: [12,1]
> HELLO REL 1 <057> 5-Sep-23
> HELLO EXE 8 <057> 5-Sep-23
> Total of 10 blocks in 3 files on DSKB: [12,1]
>
> .type hello.mac
> TITLE HELLO WORLD
> SEARCH UUOSYM
> LAB: ASCIZ /Hello World!
> /
> START: RESET
> OUTSTR LAB
> MONRT.
> END START
> .run hello
>
>
> ?No start adr
>
>
> .
the macro and fortran samples in my reply worked for me. research whether ..jbsa is setup or was ever set up, or if perhaps simh somehow lost the contents, or if the image that was saved was something else. or that there is no other type of damaged hello image file closer than the path you're showing. .SET WATCH ALL might help with some of that.

-jfg

> the macro and fortran samples in my reply worked for me. research whether .jbsa is setup or was ever set up, or if perhaps simh somehow lost the contents, or if the image that was saved was something else. or that there is no other type of damaged hello image file closer than the path you're showing. .SET WATCH ALL might help with some of that.
>
> -jfg

I typed "run hello" from the same directory as I saved the .exe to. What ever the TOPS-10 equivalent to a home directory is.

On Tuesday, September 5, 2023 at 8:24:41 PM UTC-4, Zach Z wrote:
> > the macro and fortran samples in my reply worked for me. research whether .jbsa is setup or was ever set up, or if perhaps simh somehow lost the contents, or if the image that was saved was something else. or that there is no other type of damaged hello image file closer than the path you're showing. .SET WATCH ALL might help with some of that.
> >
> > -jfg
> I typed "run hello" from the same directory as I saved the .exe to. What ever the TOPS-10 equivalent to a home directory is.
maybe someone knows if simh has a problem.

to me, both the fortran you showed and the macro you showed seems like they ought to work. to the best of my knowledge, you don't ordinarily need to specify the fortran run time library to link for a simple fortran program. this might depend on what version of compil, fortran, and link you are running. "set watch all" might help there.

the examples i showed were the output of a real run on my klh10 system today.

i'm going to bow out because i don't have the brains of most of the other people here, who will have superior debugging expertise; my advice was just to verify along each step of the way, and my own easiest (but excessively wordy) method of starting to do that is to grab a bunch of environmental info via .SET WATCH ALL, then using filddt check the resulting core-image/exe file, etc. check the exe file's core image with filddt; it will verify it is finding a valid exe file, and you can use "filename" to see the generated code (or to possibly spot something else instead of your code), and "filename/d" to examine the exe file header to make sure it looks ok.

it is remotely possible your run/get is grabbing a different file than you are expecting. .set watch all and/or path/list:all might help there. so possibly would the simple expedient of making a brand new exe file; try "garp71" as a hopefully unique file name (no, it means nothing to me and isn't any of my passwords).

set watch all might give more details if you are on a 1,2 job, something i wouldn't ordinarily recommend.

let me/us know what the final resolution is, as i would like to learn something.

'luck
-jfg

On Saturday, September 2, 2023 at 11:46:42 AM UTC-7, Zach Z wrote:
> Hi,
> I'm running TOPS-10 V7.03 on SIMH KL10. I cannot for the life of me get saved executables to run. Here is some console output.
>
> .type hello.for
> PROGRAM HELLO
> TYPE 10
> STOP
> 10 FORMAT(13H HELLO WORLD!)
> END
>
> .compile hello
> FORTRAN: HELLO
> HELLO
>
> .dir
>
>
> HELLO FOR 1 <057> 19-Mar-86 DSKB: [12,1]
> HELLO REL 1 <057> 19-Mar-86
> Total of 2 blocks in 2 files on DSKB: [12,1]
>
> .load hello
> LINK: Loading
>
> EXIT
>
> .save hello
> HELLO saved
I haven't thought about this in a lot of years, and remember the transition from SAV to EXE.

I don't remember which command made which one, though.

One is that I wonder what happens if you just RUN the program without SAVing it first.

On 2023-09-06 01:34, whis292 wrote:
> On Tuesday, September 5, 2023 at 6:37:31 PM UTC-4, Zach Z wrote:
>> I'm still having the same trouble. Here is some terminal output.
>>
>> .dir
>>
>>
>> HELLO MAC 1 <057> 5-Sep-23 DSKB: [12,1]
>> HELLO REL 1 <057> 5-Sep-23
>> HELLO EXE 8 <057> 5-Sep-23
>> Total of 10 blocks in 3 files on DSKB: [12,1]
>>
>> .type hello.mac
>> TITLE HELLO WORLD
>> SEARCH UUOSYM
>> LAB: ASCIZ /Hello World!
>> /
>> START: RESET
>> OUTSTR LAB
>> MONRT.
>> END START
>> .run hello
>>
>>
>> ?No start adr
>>
>>
>> .
> the macro and fortran samples in my reply worked for me. research whether .jbsa is setup or was ever set up, or if perhaps simh somehow lost the contents, or if the image that was saved was something else. or that there is no other type of damaged hello image file closer than the path you're showing. .SET WATCH ALL might help with some of that.

Note that you made clever use of LOAD, giving it the fortran source
file, which means that the monitor did both the compilation and linking,
and included the forlib.

Zach was separately invoking compile and link, which means that link
don't know that the .REL file came from a fortran source...

Johnny

On Wednesday, September 6, 2023 at 11:24:33 AM UTC-4, Johnny Billquist wrote:
> On 2023-09-06 01:34, whis292 wrote:
> > On Tuesday, September 5, 2023 at 6:37:31 PM UTC-4, Zach Z wrote:
> >> I'm still having the same trouble. Here is some terminal output.
> >>
> >> .dir
> >>
> >>
> >> HELLO MAC 1 <057> 5-Sep-23 DSKB: [12,1]
> >> HELLO REL 1 <057> 5-Sep-23
> >> HELLO EXE 8 <057> 5-Sep-23
> >> Total of 10 blocks in 3 files on DSKB: [12,1]
> >>
> >> .type hello.mac
> >> TITLE HELLO WORLD
> >> SEARCH UUOSYM
> >> LAB: ASCIZ /Hello World!
> >> /
> >> START: RESET
> >> OUTSTR LAB
> >> MONRT.
> >> END START
> >> .run hello
> >>
> >>
> >> ?No start adr
> >>
> >>
> >> .
> > the macro and fortran samples in my reply worked for me. research whether .jbsa is setup or was ever set up, or if perhaps simh somehow lost the contents, or if the image that was saved was something else. or that there is no other type of damaged hello image file closer than the path you're showing. .SET WATCH ALL might help with some of that.
> Note that you made clever use of LOAD, giving it the fortran source
> file, which means that the monitor did both the compilation and linking,
> and included the forlib.
>
> Zach was separately invoking compile and link, which means that link
> don't know that the .REL file came from a fortran source...
>
> Johnny
i stand corrected, guess that makes the difference. i'm a bit of a newbie to this whole tops10 thing.

not sure how *I* am instructing link to load forlib, as it doesn't appear on the surface to be a human added switch or file that i am adding - rather had thought it was something included in the .rel file fortran generated - an external or something ... , or an imbedded command to link?

..type bar.for
program bar
write(5,10)
10 format(13H Hello World!)
end
[L3: SOFT0:BAR.FOR[10,2004] PC:400655]

..r fortra

*bar=bar
[L0: DSK:SWITCH.INI[1,2] PC:414532, error 0]
[L3: SOFT0:BAR.FOR[10,2004] PC:402261]
[E1: SOFT0:BAR.REL[10,2004] PC:401651]
BAR
*^C

..r link

*bar/go
[L0: DSK:SWITCH.INI[1,2] PC:617753, error 0]
[L1: SOFT0:BAR.REL[10,2004] PC:630067]
[L1: D08B0:FORLIB.REL[1,4] PC:630067]

EXIT

..save
[E0: SOFT0:BAR.EXE[10,2004] PC:465036]
BAR saved

..run bar

Hello World!
CPU time 0.01 Elapsed time 0.02

EXIT

..
now, i will keep the promise i just broke, and stay out of it, as i just don't understand it the way you guys do-i'll stick to lurking from now on, and try to learn more.

-jfg

On Wednesday, September 6, 2023 at 8:24:33 AM UTC-7, Johnny Billquist wrote:

(snip)

> Note that you made clever use of LOAD, giving it the fortran source
> file, which means that the monitor did both the compilation and linking,
> and included the forlib.

I think that is something I knew 45 years ago, and forgot by now.

I do remember one time figuring out how FOROTS loads the
high segment. I then wrote my own FOROTS. Well, all it did
was initialize itself and load the high segment. Nothing else,
but that was enough to see how it worked.

> Zach was separately invoking compile and link, which means that link
> don't know that the .REL file came from a fortran source...

Even more, that the entry point isn't into the Fortran MAIN.

I also forgot that from 45 years ago.

Zach Z <zzwergel@gmail.com> writes:

> I'm still having the same trouble. Here is some terminal output.

> .dir

> HELLO MAC 1 <057> 5-Sep-23 DSKB: [12,1]
> HELLO REL 1 <057> 5-Sep-23
> HELLO EXE 8 <057> 5-Sep-23
> Total of 10 blocks in 3 files on DSKB: [12,1]

Delete the .rel and .exe files, please.

> .type hello.mac
> TITLE HELLO WORLD
> SEARCH UUOSYM
> LAB: ASCIZ /Hello World!
> /
> START: RESET
> OUTSTR LAB
> MONRT.
> END START

> .run hello

> ?No start adr

We're going to start from scratch, on the emulated system at Living Computers.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| *
| * Visit https://wiki.livingcomputers.org for documentation.
| *
| * Use ssh kl2065@tty.livingcomputers.org to connect.
| *
| * Guest access is available:
| *
| * LOGIN NOACCOUNT (password is 'unguessablewords')
| * LOGOUT using 'KJOB' and CTRL-] quit
| *
| * CTRL-] quit to return to the menu
| *
| PDPplanet DECsystem-10 #3530 TOPS-10 v7.04
|
| .
|
| Connected to the KL-10 simulator TTY device, line 0
|
|
| PDPplanet DECsystem-10 00:32:02 TTY4 system 1025
| Connected to Node KLAD10(66) Line # 4
| TYPE:VT100 MODEL:VT100 CLASS:VT100 APC:HARDWIRED
| RCVSPEED:9600 XMTSPEED:9600 ECHO WIDTH:80
| LENGTH:100 NOSTOP FILL:0 LC
| TABS NOFORM CRLF GAG
| SBELL NOTAPE BLANKS NOALTMOD
| NORTCOMP REMOTE XONXOF NOUNPAUS
| NOESCAPE NOQUOTE IDLEDI:0 NOSLAVE
| ANSLEVEL:1 DECLEVEL:1 NOEIGHTBIT NO8BITARCH
| DISPLAY NOOVERSTRIKE NOCOLOR NOSTATUSLINE
| NOISO NONRC NODRCS NOUDKEYS
| AVO NOPRINTERPORT NOIDCHAR NOIDLINE
| NOREGIS NOSIXEL NOTEKEMULATION VT52EMULATION
| SREGION NOHSCROLL NOVLENGTH VWIDTH
| NOUSERWINDOWS NOBLOCKMODE NOGUARDEDAREA NOSELECTERASE
| NOKATAKANA NOSESSIONS NODECTCS NOINTERROGATION
| NOLOCATOR KEYBOARD
|
| Please note that closing a terminal window or program does not log off
| the session (job). Use the KJOB command at the . prompt before ending
| the terminal program to log out of the system.
|
| Please LOGIN
|
| .login alderson
| Job 3 PDPplanet DECsystem-10 TTY4
| Password:
| [LGNLAS Last access to [20,20] succeeded on 18-Nov-121:12:07:40]
^^^^^^^^^^^^^^^^^^^
Guess I haven't logged in in a while...
| 00:32 3-Sep-123 Sunday
^^^^^^^^^^^^^^^^^^^^^^^^^^^
Clock is a little off...
|
| .r amis
An Emacs clone, so the following is really fullscreen:
| title hello world
| search uuosym
|
| lab: asciz/hello world!
| /
|
| start: reset
| outstr lab
| monrt.
|
| end start
|
| AMIS 00:38 (Fundamental) Main: DSKB:HELLO.MAC[20,20]<055>
| ^X^Whello.mac^Z^Z
|
| .dir hello.mac
|
| HELLO MAC 1 <055> 3-Sep-23 DSKB: [20,20]
|
| .type hello.mac
| title hello world
| search uuosym
|
| lab: asciz/hello world!
| /
|
| start: reset
| outstr lab
| monrt.
|
| end start
|
| .debug hello.mac
| MACRO: hello
| LINK: Loading
| [LNKDEB DDT execution]
| DDT
| .jbsa/ PAT..+342,,START# =20304,,17737 start$b $g
| $1B>>START#/ RESET $x
| 0/ 0 0
| START#+1/ OUTSTR DDTEND $x
| hello world!
| DDTEND/ TLCE 2,@466336(15)
| START#+2/ MONRT. $x
|
| .dir hello.*
|
| HELLO MAC 1 <055> 3-Sep-23 DSKB: [20,20]
| HELLO REL 1 <055> 3-Sep-23
| Total of 2 blocks in 2 files on DSKB: [20,20]
|
| .load hello
| LINK: Loading
|
| EXIT
|
| .start
|
| hello world!
|
| .load
| LINK: Loading
|
| EXIT
|
| .save
| HELLO saved
|
| .dir hello.*
|
| HELLO MAC 1 <055> 3-Sep-23 DSKB: [20,20]
| HELLO REL 1 <055> 3-Sep-23
| HELLO EXE 8 <055> 3-Sep-23
| Total of 10 blocks in 3 files on DSKB: [20,20]
|
| .run hello
|
| ?No start address
|
| .r filddt
|
| File: hello.exe/data
| [Looking at file DSKB:HELLO.EXE[20,20]]
|
| 0/ 1776,,3
| 1/ 100000,,1
| 2/ 0
| 3/ 1777,,1
| 4/ 0 1000/ 0
| 1001/ 0
| 1002/ 0
| 1003/ 0
| 1004/ 0
| 1005/ 0 0$n
| 0/ 1776,,3
| 1/ 100000,,1
| 3/ 1777,,1
|
| ^Z
|
| .
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

SAVE is the correct command to save an .exe file, but it's saving crap: 8
blocks (2 pages) of mostly zeroes. I also tried SSAVE (sharable SAVE), with
the same results.

I only administered the 2065; I didn't try to program on it, because I had too
many other things to take care of when the museum was open. I don't know
what's going on here.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

On Wednesday, September 6, 2023 at 8:24:33 AM UTC-7, Johnny Billquist wrote:

(snip)

> Note that you made clever use of LOAD, giving it the fortran source
> file, which means that the monitor did both the compilation and linking,
> and included the forlib.

> Zach was separately invoking compile and link, which means that link
> don't know that the .REL file came from a fortran source...
The END line in Macro-10 has an optional start address.

That goes into a type 7 REL block in the object program.

It would be usual for a linker to complain about unresolved external
references if the appropriate libraries are not linked. I don't know why
it doesn't do that.

On Thursday, September 7, 2023 at 12:02:14 AM UTC-4, gah4 wrote:
> On Wednesday, September 6, 2023 at 8:24:33 AM UTC-7, Johnny Billquist wrote:
>
> (snip)
> > Note that you made clever use of LOAD, giving it the fortran source
> > file, which means that the monitor did both the compilation and linking,
> > and included the forlib.
>
> > Zach was separately invoking compile and link, which means that link
> > don't know that the .REL file came from a fortran source...
> The END line in Macro-10 has an optional start address.
>
> That goes into a type 7 REL block in the object program.
>
> It would be usual for a linker to complain about unresolved external
> references if the appropriate libraries are not linked. I don't know why
> it doesn't do that.
it doesn't complain because the link always goes fine both on other platforms (klh10) [as well as Zach and Richards] and either language, since RA is able to do a START after the load. $.02, the issue is either a simulator bug or a SAVE bug.

to me, seems more likely to be a simulator bug, as surely so severe a save bug would not exist, particularly across monitor versions.

-jfg

On 2023-09-07 13:15, whis292 wrote:
> On Thursday, September 7, 2023 at 12:02:14 AM UTC-4, gah4 wrote:
>> On Wednesday, September 6, 2023 at 8:24:33 AM UTC-7, Johnny Billquist wrote:
>>
>> (snip)
>>> Note that you made clever use of LOAD, giving it the fortran source
>>> file, which means that the monitor did both the compilation and linking,
>>> and included the forlib.
>>
>>> Zach was separately invoking compile and link, which means that link
>>> don't know that the .REL file came from a fortran source...
>> The END line in Macro-10 has an optional start address.
>>
>> That goes into a type 7 REL block in the object program.
>>
>> It would be usual for a linker to complain about unresolved external
>> references if the appropriate libraries are not linked. I don't know why
>> it doesn't do that.
> it doesn't complain because the link always goes fine both on other platforms (klh10) [as well as Zach and Richards] and either language, since RA is able to do a START after the load. $.02, the issue is either a simulator bug or a SAVE bug.
>
> to me, seems more likely to be a simulator bug, as surely so severe a save bug would not exist, particularly across monitor versions.

You were using klh, I think I saw. So the quesiton is, what is Zach (and
PDPplanet) running on?

Johnny

On Thursday, September 7, 2023 at 9:15:41 AM UTC-4, Johnny Billquist wrote:
> On 2023-09-07 13:15, whis292 wrote:
> > On Thursday, September 7, 2023 at 12:02:14 AM UTC-4, gah4 wrote:
> >> On Wednesday, September 6, 2023 at 8:24:33 AM UTC-7, Johnny Billquist wrote:
> >>
> >> (snip)
> >>> Note that you made clever use of LOAD, giving it the fortran source
> >>> file, which means that the monitor did both the compilation and linking,
> >>> and included the forlib.
> >>
> >>> Zach was separately invoking compile and link, which means that link
> >>> don't know that the .REL file came from a fortran source...
> >> The END line in Macro-10 has an optional start address.
> >>
> >> That goes into a type 7 REL block in the object program.
> >>
> >> It would be usual for a linker to complain about unresolved external
> >> references if the appropriate libraries are not linked. I don't know why
> >> it doesn't do that.
> > it doesn't complain because the link always goes fine both on other platforms (klh10) [as well as Zach and Richards] and either language, since RA is able to do a START after the load. $.02, the issue is either a simulator bug or a SAVE bug.
> >
> > to me, seems more likely to be a simulator bug, as surely so severe a save bug would not exist, particularly across monitor versions.
> You were using klh, I think I saw. So the quesiton is, what is Zach (and
> PDPplanet) running on?
>
> Johnny
Zach states simh, altho Not what tree/ver (might not be many that handle kl10 well yet); don't know what living computers is running on.

i think someone, Fred Wright maybe, had a small code fragment that expanded on the macro manual's "what cpu am i ?", that included i think at least klh10 and one "other" (not sure whether it was toad, simh, etc). didn't notice any specifics in the public billboard at lc, but haven't looked real hard.

-jfg

gah4 <gah4@u.washington.edu> writes:
> It would be usual for a linker to complain about unresolved external
> references if the appropriate libraries are not linked. I don't know why
> it doesn't do that.=20

Oddly (and almost certainly a pure coincidence), RSX280 will also quietly
build an executable with missing symbols.

https://github.com/hperaza/RSX280

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html

I tried the MACRO-10 and FORTRAN programs on the two TOPS-10 systems at
the Living Computer Museum (One running 6.03a on a simulated KA10 1050,
the other running 7.04 on a simulated KL10 2065).

The result were that the SAVE command followed by running the HELLO.EXE
worked correctly on the 6.03a system, but got the "?No start address" on
the 7.04 system.

Doing a start of the program immediately after LINK completed the load
worked correctly on both.

As another check on the 7.04 system, I did a GET of an existing EXE file
and did a SAVE to a new name. A FILCOM of the two files shows a number
of word in JOBDAT that are non-zero in the original file but zero in the
results of the SAVE command. This results in there being a zero in
..JBSA, so no start address.

It seems likely that the SAVE command is broken in 7.04. I suspect it
didn't get much use after 7.04 came out, since most software builds
would have LINK write the EXE file directly (which also worked on the
7.04 system).

- Nick

On Thursday, September 7, 2023 at 7:38:06 PM UTC-4, Nick Bush wrote:
> I tried the MACRO-10 and FORTRAN programs on the two TOPS-10 systems at
> the Living Computer Museum (One running 6.03a on a simulated KA10 1050,
> the other running 7.04 on a simulated KL10 2065).
>
> The result were that the SAVE command followed by running the HELLO.EXE
> worked correctly on the 6.03a system, but got the "?No start address" on
> the 7.04 system.
>
> Doing a start of the program immediately after LINK completed the load
> worked correctly on both.
>
> As another check on the 7.04 system, I did a GET of an existing EXE file
> and did a SAVE to a new name. A FILCOM of the two files shows a number
> of word in JOBDAT that are non-zero in the original file but zero in the
> results of the SAVE command. This results in there being a zero in
> .JBSA, so no start address.
>
> It seems likely that the SAVE command is broken in 7.04. I suspect it
> didn't get much use after 7.04 came out, since most software builds
> would have LINK write the EXE file directly (which also worked on the
> 7.04 system).
>
> - Nick
i notice zach said it failed on both 703 and 704 for him. did it get fixed during 703 after release, and then get broken again just in time for 704 release?

my home notes don't mention problems in the save command for the releases, and it works on my klh10 "machine". otoh, it is true if we _had_ noticed a problem we certainly would have fixed it, even if i failed to note it, and any fixes we made we circulated back to DEC.

i seem to recall that the hardware memory control is a little different between the ka and kl, so i suppose it's possible the pdp10 tops10 monitor code might be too, and maybe the simulator's code.

i wonder if there is a slim possibility that the simulator LCM+L is using has a problem? i created a macro program on my klh10 once and didn't encounter any problems. didn't use the save switches in link, used the save monitor command.

if i knew a way to grab system.exe from the "g" system just using the noaccount account, i could run it here on klh10 and see what happens using that monitor.

-jfg

After posting earlier about seeing the failure on 7.04 on the living
computer museum (LCM) system, I built klh10 on a Raspberry PI and booted
7.04 (from the twonky disks). A quick test showed the save command
worked properly: GET an existing EXE file, followed by a SAVE to a new
file resulted in an identical file. On the LCM 7.04 system the SAVE
resulted in many locations in JOBDAT being zeroed.

So, this might be a simulator specific issue, although it is hard to see
what type of simulator bug would cause this type of result without also
causing various other failures.

- Nick

I'm as mystified as everyone else by the lack of a starting address in
the SAVEd image. A bug in TOPS-10 or the PDP-10 emulator both sound
unlikely, but if KLH10 works then I suppose the latter something to look
into.

Now, if all you want is to play with various PDP-10 programming
languages, I'd like to point to the ITS repository which now has hello
world examples for C, CLU, FAIL, Fortran 40, Maclisp, MACRO-10, MIDAS,
Muddle (MDL), and PALX.

https://github.com/PDP-10/its/tree/master/src/hello

On Thursday, September 7, 2023 at 9:38:05 PM UTC-4, Nick Bush wrote:
> After posting earlier about seeing the failure on 7.04 on the living
> computer museum (LCM) system, I built klh10 on a Raspberry PI and booted
> 7.04 (from the twonky disks). A quick test showed the save command
> worked properly: GET an existing EXE file, followed by a SAVE to a new
> file resulted in an identical file. On the LCM 7.04 system the SAVE
> resulted in many locations in JOBDAT being zeroed.
>
> So, this might be a simulator specific issue, although it is hard to see
> what type of simulator bug would cause this type of result without also
> causing various other failures.
>
> - Nick
Maybe this should be posted as a bug in the Simh GitHub?

On Saturday, September 9, 2023 at 12:37:54 AM UTC-4, Zach Z wrote:
> On Thursday, September 7, 2023 at 9:38:05 PM UTC-4, Nick Bush wrote:
> > After posting earlier about seeing the failure on 7.04 on the living
> > computer museum (LCM) system, I built klh10 on a Raspberry PI and booted
> > 7.04 (from the twonky disks). A quick test showed the save command
> > worked properly: GET an existing EXE file, followed by a SAVE to a new
> > file resulted in an identical file. On the LCM 7.04 system the SAVE
> > resulted in many locations in JOBDAT being zeroed.
> >
> > So, this might be a simulator specific issue, although it is hard to see
> > what type of simulator bug would cause this type of result without also
> > causing various other failures.
> >
> > - Nick
> Maybe this should be posted as a bug in the Simh GitHub?
that seems pretty reasonable, but it might be nice if someone with the necessarily facilities were to take the system.exe that you and LCM+L are running and verify that it works properly on a klh10 system, and fails on a simh system from whatever tree(s) you and/or LCM are using, to simplify the work of the simh team. if the testing were done, you might conceivably find it is a .SAVE bug after all (but my bet is simh). they'd appreciate details of exactly what goes awry during the save too, if someone knew that.

if i knew how to get your or LCM+L's system.exe (maybe a backup /TAPE file?) onto my klh10 system, or if i knew how to get my simh to boot tops10 (a LOADable boot file, or a .DSK file that is BOOTable), i'd help (well, i'd *try* anyway).

-jfg

whis292 <jeffgunter@usa.net> writes:

> On Saturday, September 9, 2023 at 12:37:54=E2=80=AFAM UTC-4, Zach Z wrote:

>> On Thursday, September 7, 2023 at 9:38:05=E2=80=AFPM UTC-4, Nick Bush wrote:

>>> After posting earlier about seeing the failure on 7.04 on the living
>>> computer museum (LCM) system, I built klh10 on a Raspberry PI and booted
>>> 7.04 (from the twonky disks). A quick test showed the save command worked
>>> properly: GET an existing EXE file, followed by a SAVE to a new file
>>> resulted in an identical file. On the LCM 7.04 system the SAVE resulted in
>>> many locations in JOBDAT being zeroed.

>>> So, this might be a simulator specific issue, although it is hard to see
>>> what type of simulator bug would cause this type of result without also
>>> causing various other failures.

>>> - Nick

>> Maybe this should be posted as a bug in the Simh GitHub?

> that seems pretty reasonable, but it might be nice if someone with the
> necessarily facilities were to take the system.exe that you and LCM+L are
> running and verify that it works properly on a klh10 system, and fails on a
> simh system from whatever tree(s) you and/or LCM are using, to simplify the
> work of the simh team. if the testing were done, you might conceivably find
> it is a .SAVE bug after all (but my bet is simh). they'd appreciate details
> of exactly what goes awry during the save too, if someone knew that.

I've looked at the LCM+L menu, and it appears that they are running Rich
Cornwell's SimH KL-10 instead of KLH10. I've asked the remaining staff member
to confirm that, and to test against KLH10.

> if i knew how to get your or LCM+L's system.exe (maybe a backup /TAPE file?)
> onto my klh10 system, or if i knew how to get my simh to boot tops10 (a
> LOADable boot file, or a .DSK file that is BOOTable), i'd help (well, i'd
> *try* anyway).

Hold off until I hear back from LCM+L.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen