DECTape based software development

[Steve Tockey]

It all kinda got rolling in the Facebook DEC PDP-8 group. Someone asked if it were possible to do FORTRAN IV development on a PDP-8 with DECTapes. I had previously set up tapes for PAL-8, BASIC, and FORTRAN II so I thought it should be easy to just set up another one for FORTRAN IV. I won't bore you with the gory details, but it wasn't quite as trivial as I thought it would (or should) have been. Regardless, success, so it seemed like a good idea to share in case anyone else happens to be interested.

To be clear, these are simulated DECTapes that target Oscar Vermuelen's SIMH based PiDP-8/I (https://obsolescence.wixsite.com/obsolescence/pidp-8). You should be able to use these same simulated tapes in any SIMH based PDP-8 emulator, it should require no more than tweaking boot scripts. I've also heard it is possible to transfer between simulated DECTape images and real DECTapes but I can't provide any detail on that.

You can find everything on DropBox here:

https://www.dropbox.com/sh/0426m8pjzffe3s7/AADjf9KOSIC8IqAaj3Nbl4LMa?dl=0

Start with README.txt.

Tapes are available for the following languages:
BASIC
COBOL
FORTRAN II
FORTRAN IV
PAL-8

Each language has a SYS: (DTA0:) tape with OS/8, the compiler/linker, and useful ancillary tools (like CREF and BITMAP for PAL-8). There is also a DSK: (DTA1:) tape that's been pre-populated with one or more sample programs in that language.

One thing you may need to know, however, is that FORTRAN IV and COBOL are only able to run on TC01/TU55 DECTapes. If you have a real PDP-8 with TD8E/TU56, neither of these will work. I know why FORTRAN IV won't work on TU56s, I don't have an explanation for why COBOL doesn't work (yet).

BASIC, FORTRAN II, and PAL-8 are on TD8E/TU56 system tapes.

Have fun . . .

[Martin Eberhard]

Hi Steve,

> I've also heard it is possible to transfer between simulated DECTape images and real DECTapes but I can't provide any detail on that.

Funny that you say that - I just earlier this evening posted on this same group my new MEMON-8 PDP8 monitor program. One its main purposes is to take .TU56 files and write them to a real DECtape. (It can also rip a real DECtape and produce a .TU56 file.)

I'm going to write some DECtapes from your files and try running them. It has been a really long time since I last wrote Fortran :-)

Thanks!

Best,

Martin E.

[vher...@me.com]

I think you will know this, you can restore TU-56 files with dumprest from David Gesswein. With this you can dump and restore from different devices, not only TU-56.
You can compose images with simh and then write them back with dumprest.

So it's an interesting approch to write an own program for this, I will have a look at this.

With the COBOL thing, I realized that if you copy it (and the runtime) to SYS on an RK05 it will not write to DSK. But it writes to SYS.
Maybe that is the same with TU-56 on TD8E? I will give it a try.

I saw the COBOL handbook in your dropbox, I just scanned it last week, hey thats fast!

Have fun...

[Martin Eberhard]

> I think you will know this, you can restore TU-56 files with dumprest from David Gesswein. With this you can dump and restore from different devices, not only TU-56.

:-) Yes of course. I studied his code before writing Memon-8, and credited him in my comments.

I wanted to be able to create DECtapes from TU56 files without a custom program on the PC side. You need *something* on the PC side to do flow control, and xmodem will do the job with a variety of off-the-shelf terminal emulator programs.

David's approach has the advantage of being about 33% faster on the serial port (due to his byte packing), which makes a big difference if you are transferring at 9600 baud or below. But at 38400 baud, it's not such a big deal.

Plus I now understand the TD8-E pretty well, and my PDP8 assembly language skills are getting better from this exercise :-)

[Steve Tockey]

> With the COBOL thing, I realized that if you copy it (and the runtime) to SYS on an RK05 it will not write to DSK. But it writes to SYS.
> Maybe that is the same with TU-56 on TD8E? I will give it a try.

First, I couldn't get the COBOL compiler to work with SYS: on TD8E/TU56. After giving the Command Decoder file specification input it always goes into some kind of infinite loop. It compiles successfully on TC01/TU55.

Second, many OS/8 installations, RK05-based included, have SYS: and DSK: refer to the same place. People either don't know about using ASSIGN, and/or they forget to do ASSIGN every time they boot up, and/or they don't know how to make a permanent assignment in BUILD. When I successfully ran COBOL on TC01/TU55 with DTA0: being SYS: and DTA1: being DSK:, it definitely put the .SV output on DSK:. So if your .SV file is ending up on SYS:, make sure it's not because SYS: and DSK: refer to the same place on your system. It would be illogical to have the COBOL compiler know enough about the SYS: drive being DECTape vs. RK05 and be able to behave differently. You need to jump through quite a lot of hoops to figure out what kind of hardware is really behind your SYS: device handler. The far safer bet would be simply that on your RK05 system, SYS: and DSK: are both referring to RKA0:

> I saw the COBOL handbook in your dropbox, I just scanned it last week, hey thats fast!

So you were the one who scanned it? Thanks. Without that, I don't see how anybody could get it to run successfully.

[vher...@me.com]

I got one pdp8/e with TC08, TU56 and RK05s from a school. Together with tapes, disks and some paper documentation. After I was at the point to have the 8/e running with TD8E and TU-56 I dumped the tapes. David Gesswein was so friendly to take them on his site. Some days later I was asked about details for the Cobol, that is on one tape, so I had a look in the basement and found the paper I scanned.
There seems to be more interest in this old stuff, than I expected.
Now i'm curious what to find on the disks....

If you have a close look to the document you will miss page 37. I don't find it.

Have fun
Volker

[Steve Tockey]

> If you have a close look to the document you will miss page 37. I don't find it.

Another minor problem is that the second page in the .PDF is about section 6 on the CALL verb. The real second page of the document is on page 3 of the PDF.

I am not complaining, I'm just pointing out that if you happen to eventually re-scan it (because maybe you found the missing page 37?) also please put the CALL verb page in the right place?

[vher...@me.com]

You see I did't read it before scanning. But page 37 is really missing. Are you able to OCR that?

[Steve Tockey]

> You see I did't read it before scanning. But page 37 is really missing. Are you able to OCR that?

Unfortunately no, OCR is not working for me.

[Steve Tockey]

On Tuesday, April 14, 2020 at 2:34:27 PM UTC-7, vher...@me.com wrote:
> You see I did't read it before scanning. But page 37 is really missing. Are you able to OCR that?

Volker,
Page 37 is not missing after all. I looked in the Index of the manual. Page 37 is for the CALL verb. So page 2 in the PDF is simply in the wrong place.

[Steve Tockey]

All,
The COBOL tapes have been updated. There are now five sample programs--that all run--on the DSK: (DTA1:) tape. Four of those sample programs are copied from the user manual.

Also, page 6 of the user manual explains why the COBOL run time system is incompatible with TD8E/TU56.

[Robert]

On Mon, 13 Apr 2020 13:01:15 -0700 (PDT), Steve Tockey
<steve...@gmail.com> wrote:
>Tapes are available for the following languages:

> COBOL

Thanks for that. I'd never noticed the Decus COBOL stuff before (and
without the manual it wouldn't have been much use anyway).
Over 50 years since I first learned it and probably over 30 since I
last used it.

By the way it might be worth producing a similar (Rog)ALGOL tape. It's
an interesting language historically and Roger Abbott's implementation
works very well although like most 3rd party stuff both it and it's
documentation is a bit 'original'.

[Steve Tockey]

Robert,
Can you give me a pointer to where I can find the Algol stuff? Compiler, documentation (such as it might be), possible sample code? it's not difficult to set up a new tape image around those kinds of resources.

[vher...@me.com]

Maybe you find it here, but there might be other places also:
http://www.bitsavers.org/bits/DEC/pdp8/papertapeImages/russ.ucs.indiana.edu/Langs/

In the documentation I got with my school hardware I also found a handbook for ALGOL. I will have to scan it. But there was no Algol on the tapes. Maybe I find it on the disk when I have the RK05 running.

[Robert]

On Mon, 20 Apr 2020 12:22:23 -0700 (PDT), Steve Tockey
<steve...@gmail.com> wrote:

>Robert,
>Can you give me a pointer to where I can find the Algol stuff? Compiler, documentation (such as it might be), possible sample code? it's not difficult to set up a new tape image around those kinds of resources.
>

You can get the source files here:
http://http://www.dbit.com/pub/pdp8/nickel/langs/algol/ascii/
And a (quite adequate!) manual here:
http://ccgi.theadamsons.force9.co.uk/pdp8software/docs/ROGAlgol_Algol60_Compiler.pdf
The instructions are a bit mixed up because the original system was
papertape only later extended to OS/8.
There are some references on the www to Roger Abbott's original DECUS
paper.

Compiling and Running RogAlgol under OS/8:
1. Assemble (PAL) the *.pa files, you can ignore the rather cryptic
*.al ones.
2. Make the Compiler image:
Load (ABSLDR) INTRUN.BN,ALGCOM.BN,COMOS8.BN
Save as ALGCOM.SV
3. Make the runtime image:
Load (ABSLDR) FPP.BN,ALGRUN.BN,RUNOS8.BN
Save as RALGOL.SV

RTFM for some pointers on the EAE/FPP options

eg to run the following program, TRIAL.AL:

'BEGIN'
'INTEGER' I;
SKIP(1);
TEXT(1,"TEST OF ROGALGOL SYSTEM, LIST OF SQUARES AND ROOTS");
SKIP(1);SKIP(1);
'FOR' I:=1 'STEP' 1 'UNTIL' 20 'DO' 'BEGIN'
TEXT(1,"THE SQUARE OF ");
WRITE(1,I);
TEXT(1, " IS ");
WRITE(1,I*I);
TEXT (1," AND THE ROOT IS ");
RWRITE(1,SQRT(I));
SKIP(1);
'END';
SKIP(1);
TEXT(1,"DONE");
'END'
$

(NOTE THE TRAILING '$' - essential!)

.R ALGCOM

ROGALGOL MK40
OUT<IN*TRIAL<TRIAL

SIZE 91

.R RALGOL

ROGALGOLOADER
INPUT FILENAME ?*TRIAL.AC

ENDS 0335
^ (^P typed here)
TEST OF ROGALGOL SYSTEM, LIST OF SQUARES AND ROOTS

THE SQUARE OF 1 IS 1 AND THE ROOT IS +0.100000E+001
THE SQUARE OF 2 IS 4 AND THE ROOT IS +0.141421E+001
THE SQUARE OF 3 IS 9 AND THE ROOT IS +0.173205E+001
THE SQUARE OF 4 IS 16 AND THE ROOT IS +0.200000E+001
THE SQUARE OF 5 IS 25 AND THE ROOT IS +0.223607E+001
THE SQUARE OF 6 IS 36 AND THE ROOT IS +0.244949E+001
THE SQUARE OF 7 IS 49 AND THE ROOT IS +0.264575E+001
THE SQUARE OF 8 IS 64 AND THE ROOT IS +0.282843E+001
THE SQUARE OF 9 IS 81 AND THE ROOT IS +0.300000E+001
THE SQUARE OF 10 IS 100 AND THE ROOT IS +0.316228E+001
THE SQUARE OF 11 IS 121 AND THE ROOT IS +0.331662E+001
THE SQUARE OF 12 IS 144 AND THE ROOT IS +0.346410E+001
THE SQUARE OF 13 IS 169 AND THE ROOT IS +0.360555E+001
THE SQUARE OF 14 IS 196 AND THE ROOT IS +0.374166E+001
THE SQUARE OF 15 IS 225 AND THE ROOT IS +0.387298E+001
THE SQUARE OF 16 IS 256 AND THE ROOT IS +0.400000E+001
THE SQUARE OF 17 IS 289 AND THE ROOT IS +0.412310E+001
THE SQUARE OF 18 IS 324 AND THE ROOT IS +0.424264E+001
THE SQUARE OF 19 IS 361 AND THE ROOT IS +0.435890E+001
THE SQUARE OF 20 IS 400 AND THE ROOT IS +0.447214E+001

DONE
^ (^C typed here)
.

HTH
Bob

[Robert]

On Thu, 23 Apr 2020 20:40:25 +0100, Robert <n...@displaying.it> wrote:

Oops - pardon my obvious typo:

>You can get the source files here:

>http://www.dbit.com/pub/pdp8/nickel/langs/algol/ascii/

There are some options (eg Field 2 extension) but RTFM

[Steve Tockey]

Robert,
I'm having no luck with ALGOL at all. Several issues:

1) The source code at http://www.dbit.com/pub/pdp8/nickel/langs/algol/ascii/ does include algcom.al, but that is the Algol source code for the compiler. There is no PAL-8 *.PA file for the compiler. So, right out of the starting gate your instructions to assemble all of the *.PA files and the use ABSLDR to load INTRUN.BN,ALGCOM.BN,COMOS8.BN then save as ALGCOM.SV doesn't work because ALGCOM.BN doesn't exist.

2) There is an ALGCOM.BN file at http://www.dbit.com/pub/pdp8/nickel/langs/algol/os8/ but despite having tried several different ways to get that file into OS/8 it always comes in as a corrupt *.BN image that ABSLDR refuses to handle.

3) There is an ALGCOM.SV file at http://www.dbit.com/pub/pdp8/nickel/langs/algol/os8/ but, again, in OS/8 all I get after ".R ALGCOM" is "CORE IMAGE ERROR".

It does look like you were able to get it to run, but I haven't been able to. Sorry.


-- steve

[William Cattey]

A .BN file will need "-b" to the os8-cp command.
PIP is what's used to get these files in, and it's too damned clever for its own good.

-Bill

[Robert]

On Sat, 25 Apr 2020 15:15:32 -0700 (PDT), Steve Tockey
<steve...@gmail.com> wrote:

>Robert,
>I'm having no luck with ALGOL at all. Several issues:
>
>1) The source code at http://www.dbit.com/pub/pdp8/nickel/langs/algol/ascii/ does include algcom.al, but that is the Algol source code for the compiler. There is no PAL-8 *.PA file for the compiler. So, right out of the starting gate your instructions to assemble all of the *.PA files and the use ABSLDR to load INTRUN.BN,ALGCOM.BN,COMOS8.BN then save as ALGCOM.SV doesn't work because ALGCOM.BN doesn't exist.
>
>2) There is an ALGCOM.BN file at http://www.dbit.com/pub/pdp8/nickel/langs/algol/os8/ but despite having tried several different ways to get that file into OS/8 it always comes in as a corrupt *.BN image that ABSLDR refuses to handle.
>
>3) There is an ALGCOM.SV file at http://www.dbit.com/pub/pdp8/nickel/langs/algol/os8/ but, again, in OS/8 all I get after ".R ALGCOM" is "CORE IMAGE ERROR".
>
>It does look like you were able to get it to run, but I haven't been able to. Sorry.
>
>
>-- steve
>

Sorry about that Steve, its a while since I downloaded and played with
this stuff and some brain bit rot has crept in I'm afraid.

So I've uploaded ALGCOM.BN here:
http://ccgi.theadamsons.force9.co.uk/pdp8software/rogalgol/algcom.bn
(you need PIP/B to load it of course)
and a working RK05 image with the RogALGOL stuff on it here:
http://ccgi.theadamsons.force9.co.uk/pdp8software/rogalgol/rogalgol.rk05
which works fine on simH.

This all works fine for me so fingers crossed. Always good to keep
this old stuff alive.

Bob

[Steve Tockey]

Robert,
Thanks. The TU56 DECTape images for ALGOL have been added to the collection. Sample programs TRIAL.AL and HW.AL (Hello World) both compile and run.


-- steve

[Steve Tockey]

Pascal is also available although the compiler is painfully slow when run on DECTapes. I also cleaned up the "INIT NOT FOUND" message on all of the remaining tapes.