Re: Problems with FORT and ALGOL in TSS/8

[Josh Dersch via cctalk]

On Thu, Dec 3, 2020 at 6:13 PM Kevin Jordan via cctalk <
cctalk@classiccmp.org> wrote:

> Hi everyone,
>
> The Nostalgic Computing Center  has a
> virtual PDP-8 running TSS/8
> <
> http://www.nostalgiccomputing.org:8080/aterm.html?m=pdp8&t=PDP-8&r=24&c=80
> >
> in its collection. We use the SIMH PDP-8e emulator to support the machine,
> and we recently updated the machine to run the TSS/8 distribution created
> by LCM+L, found here on GitHub
> . The LCM+L
> distribution
> is slightly different from other TSS/8 distributions available on the web
> in that it provides some additional goodies such as ALGOL and LISP.
>
> The NCC demonstrates how various classic computers worked by providing
> automated scripts that interact with the machines in the collection.
> For example, to demonstrate each of the programming languages supported by
> a machine, scripts are provided to create, compile, and run a simple
> Fibonacci sequence generator. We've done this for the TSS/8 system, but the
> scripts aren't working for FORTRAN or ALGOL, and we're wondering if anyone
> on this list might know why.
>
> Specifically, in the case of FORTRAN, the compiler exits with an error code
> 6204. This occurs even when trying to compile trivial "hello world"
> programs, and it appears to occur in all other TSS/8 distributions we've
> tried as well (i.e., this particular problem is not unique to the LCM+L
> distribution). We haven't found error code 6204 specifically documented in
> the TSS/8 user/admin manuals, but the manuals do document other error codes
> in the 62xx range. Documented error codes in the 62xx range appear to
> reflect file I/O errors, so we're wondering if perhaps one of the files
> supporting the FORTRAN compiler is corrupt in all of these distributions.
>

The LCM+L variant is built starting from the same disk image as all the
other TSS/8 systems out there (which was originally taken from John
Wilson's TSS/8 system).  I extended the filesystem to a full megaword (the
maximum supported by TSS/8) for the RK05 image.

I suspect you may be right that FORTRAN is corrupted, I'll take a look this
weekend.  I'll admit to not having played with it; though I did test out
everything else.


>
> For example, here is a transcription of a simple session demonstrating the
> problem:
>
>



>
> Note that BASIC, FOCAL, and LISP all seem to run very nicely on the
> machine.
>
> The problem we're experiencing with ALGOL appears to be a glaring compiler
> bug, but the compiler was distributed widely through DECUS, and it is
> difficult to imagine that it would have been released with an obvious bug,
>

I don't know if that's an accurate statement.  Have you looked at Appendix
E of the manual?  There are a ton of errata there.  For example, on page
E-2:

"Boolean operator 'AND' does not function properly at all times for example:
 T = true
 F = false
 T 'AND' T -> T Correct
 T 'AND' F -> T Wrong, should be F
 F 'AND' T -> T Wrong, should be F"

The TSS/8 version of ALGOL fixes this bug but there are others.  A friend
of mine recently spent an evening trying to get a small ALGOL program to
compile and run on my online TSS/8 system and failed utterly; after a lot
of effort it finally compiles, but produces no output when run and we're
both pretty stumped about it.  We suspect that this compiler just has a lot
of bugs.

Note also that Appendix E (page E-1) suggests that ALL 'END' statements be
followed by a ";".  This seemed to help at least with getting the compiler
to stop giving us errors.  Note that despite this suggestion, the examples
in Appendix E fail to follow this guideline.

- Josh

Re: WTD - Jupiter Ace plastic rivets

[Tony Duell via cctalk]

On Fri, Dec 4, 2020 at 2:21 AM Philip Pemberton via cctalk
 wrote:
>
> Has anyone got a couple of the white plastic rivets which are used to
> hold the Jupiter Ace case together?
>
> They consist of a 4-point clawed rivet of about 5mm long, and a pin
> which pushes down the centre to open it out.
>
> I need five of them ideally - but even two or three would get the case
> buttoned up, if not perfectly.
>
> I've checked the local plastic supplier catalogues and haven't found
> anything which quite matches up.

Not identical, in the the pin has  head on it, but

https://uk.rs-online.com/web/p/rivets/0280903/

or similar might work.

-tony

WTD - Jupiter Ace plastic rivets

[Philip Pemberton via cctalk]

Has anyone got a couple of the white plastic rivets which are used to
hold the Jupiter Ace case together?

They consist of a 4-point clawed rivet of about 5mm long, and a pin
which pushes down the centre to open it out.

I need five of them ideally - but even two or three would get the case
buttoned up, if not perfectly.

I've checked the local plastic supplier catalogues and haven't found
anything which quite matches up.

Cheers,
-- 
Phil.
phil...@philpem.me.uk
https://www.philpem.me.uk/

Problems with FORT and ALGOL in TSS/8

[Kevin Jordan via cctalk]

Hi everyone,

The Nostalgic Computing Center  has a
virtual PDP-8 running TSS/8

in its collection. We use the SIMH PDP-8e emulator to support the machine,
and we recently updated the machine to run the TSS/8 distribution created
by LCM+L, found here on GitHub
. The LCM+L distribution
is slightly different from other TSS/8 distributions available on the web
in that it provides some additional goodies such as ALGOL and LISP.

The NCC demonstrates how various classic computers worked by providing
automated scripts that interact with the machines in the collection.
For example, to demonstrate each of the programming languages supported by
a machine, scripts are provided to create, compile, and run a simple
Fibonacci sequence generator. We've done this for the TSS/8 system, but the
scripts aren't working for FORTRAN or ALGOL, and we're wondering if anyone
on this list might know why.

Specifically, in the case of FORTRAN, the compiler exits with an error code
6204. This occurs even when trying to compile trivial "hello world"
programs, and it appears to occur in all other TSS/8 distributions we've
tried as well (i.e., this particular problem is not unique to the LCM+L
distribution). We haven't found error code 6204 specifically documented in
the TSS/8 user/admin manuals, but the manuals do document other error codes
in the 62xx range. Documented error codes in the 62xx range appear to
reflect file I/O errors, so we're wondering if perhaps one of the files
supporting the FORTRAN compiler is corrupt in all of these distributions.

For example, here is a transcription of a simple session demonstrating the
problem:

.R EDIT

 INPUT:
OUTPUT:FTEST
A
  WRITE(1,10)
10FORMAT(5HHELLO,/)
  END

E
^BS
.R FORT

 INPUT:FTEST
OUTPUT:
6204^BS

.


We tried enabling the floating point processor to see if lack of FPP might
cause FORT to abort, but enabling the FPP did not solve the problem. The
SIMH configuration file for the machine currently looks like:

set throttle 800K
set df disabled
set rf disabled
set rk enabled
set dt enabled
att rk0 tss8_rk_lcm.dsk

set cpu 32k
attach ttix 4000

load boot.bin
run 200


Note that BASIC, FOCAL, and LISP all seem to run very nicely on the machine.

The problem we're experiencing with ALGOL appears to be a glaring compiler
bug, but the compiler was distributed widely through DECUS, and it is
difficult to imagine that it would have been released with an obvious bug,
so we are wondering if perhaps we're not interpreting the user manual

correctly. Here is a transcription of a session that exhibits the problem:

.R EDIT

 INPUT:
OUTPUT:ATEST
A

'BEGIN'

  'INTEGER' I;

  I := 1;

  WRITE(1, I); SKIP

'END'
$


E
^BS
.R ALGOL

 INPUT:ATEST
OUTPUT:

*TOO MANY UNDEFINED [UEXPRESSION*

^BS
.


The compiler seems to be complaining that the simple assignment statement
on line 3 of the program is somehow incorrect. If we change the statement
to "I := 1 + 0;", the error message goes away,  and the program runs, but
it prints "0" instead of the expected "1".  Also, if we change the program
to:

'BEGIN'
  'INTEGER' I;

  'FOR' I := 1 'STEP' 1 'UNTIL' 10 'DO'
  'BEGIN'

WRITE(1, I); SKIP
  'END'
'END'

$


it compiles successfully and it prints what is expected, the numbers 1
through 10.

Does anyone have experience with the ALGOL/8 compiler? If so, does this
behavior make sense, and can you let us know what we're doing wrong?

Note that the same ALGOL60 program compiles and runs as expected on the CDC
mainframes and the TOPS-20 system at the NCC.

thanks!
Kevin

Re: Anyone want some LMI Lisp Machine tapes?

[Chris Hanson via cctalk]

On Dec 2, 2020, at 7:58 PM, Al Kossow via cctalk  wrote:
> 
> On 12/2/20 7:37 PM, r.stricklin via cctech wrote:
>> On Dec 2, 2020, at 12:48 PM, Chris Hanson via cctech wrote:
>>> I’m bidding on these tapes with the intent to get them into the hands of 
>>> someone like Josh and/or Al who has the skill and equipment to read and 
>>> archive them.
>> Then I hope you're not making it harder by bidding against them.
> 
> I'm not bidding, it's just Josh

Josh and I coordinated, it’s just me. :)

  — Chris