Dave Dyer <davedyer829@gmail.com> writes:

>> It seems that some programs load instructions into registers for a loop.
>> Those programs, and it might have been TECO, wouldn't run on that one.

> The two programs that I recall ran in the ACs are Teco, which had a BLT loop
> to shuffle memory that ran in the ACs. And the Rim10B loader which was used
> to boot load programs from paper tape.

The RIM10B loader is marvel of hackery in 15 words.

> Also, fun fact, there were low end versions of PDP10 hardware that didn't
> have hardware accumulators; programs in locations 0-15 ran from core memory.
> That might have been the case for all PDP-6's

The "fast memory" accumulators were an option on the PDP-6 and the KA-10; I
have heard that very few systems were ordered without them, and most if not all
of those were upgraded later.

--
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 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