• Please review our updated Terms and Rules here

SIMH/os8diskserver/PDP-8

Mike_Z said:
Does anyone have any experience with the PSP8 Fortran program or information on a document explaining the use of this language, particularly how to load, compile and what the output looks like? I'd appreciate any help Thanks, Mike.
Click to expand...

FRTS.SV is the Fortran IV runtime system. It doesn't understand source code.

This is just far too big a topic to cover in a forum such as this. The OS/8 manual covers the BASIC, FORTRAN II and FORTRAN IV languages and systems amongst almost everything else. There are other supporting manuals on Bitsavers which go into the fine detail of DEC's implementations. You'll have to do more reading I'm afraid ;). This is what all of the original OS/8 users had to do - DEC delivered a set of software and manuals and the rest was up to you.
 
Yup! Reading is no problem. I have scanned the OS8 Handbook and at first I thought, this is the stuff. But, After looking at the files on my system, I do not have F4 or FORT. I have something labeled, FOTP.SV and FUTIL.SV. Are these Fortran files?

I see that that F4 converts the source to RALF assembly code and then FRTS will convert that to an exe file of some sort.

I've found a copy of F4 for download, but am unsure of how to actually get it onto my system. Have to think about it and try a few things. Continuing to read, thanks Mike
 
You might as well add John Wilson's PUTR utility to your arsenal - http://www.dbit.com/putr/putr.doc. While John's mainline product is the Ersatz-11 PDP emulator, he has contributed a tremendous amount of work to the public domain, including PUTR which allows you to manipulate emulated disks, creating, deleting and editing their content in both physical and emulated environments.

Jack
 
Hi Mike,

I suggest you visit David Gesswein's page at https://www.pdp8online.com/images/images/os8.shtml where he has probably the largest on-line collection of OS/8 images. Various different formats, but a fair number are in rk05 format which suits os8diskserver.

Download as many of these as you feel able to deal with. There is a fair amount of redundancy amongst their files. You can then either repeat the BUILDing process on them to make them all system disks for your server, or else just use them as disk2 (SDA1, SDB1). You'll definitely find everything you need there.

The system disk you've made has almost no spare space on it, so it would probably be easiest to make a new system out of one of these files (have a look using them as disk2 to find a convenient one) and then, using the other ones as disk2 in different sessions, copy whatever other files takes your fancy. After a bit you'll have a comprehensive system disk with all the languages etc. you need.

HTH, Bob.
 
Thanks Jack for the link to PUTR. I downloaded the Document and the file. After doing a little reading I thought I'd try the program out. The program opens a DOS box with drive:directory line. The first item I had to change to make this work is, all the directories and filenames have to be in a DOS format 8 by 3. Otherwise the program will not see the files.

Next I had to MOUNT one of the drives. I decided to look at SDB1: My mount command line looks like this.

MOUNT SB1: c:\os8\diskserv\serialdk\disks\diapack1.rk5 /rk05 /os8 /partition:1

The partition switch grabs the 2nd partition of the RK05 drive. If you make a mistake there will be an error message.

Next I did a DIR of SB1:

DIR SB1:

This showed all the files that are on SDB1: I checked them against what OS/8 says are there and everything checked out.

Next I shut down PUTR and then used OS8 to delete some files on SDB1:

.DEL *.SV

The OS8 DIR command showed that all the .SV files were gone.

Next, I restarted PUTR, mounted SB1: as before, then did a DIR SB1:

This displayed an odd file for the first file, then a bunch (many) .EMPTY. files and finally finished with ?CORRUPT DIRECTORY. Not sure what went wrong.

So then I made a new copy of the disk image. Both OS8 and PUTR then reported that same files again. This time I thought I'd try for FORMAT SDB1: in PUTR. After SDB1: was mounted as SB1: I entered

FORMAT SB1: c:\os8\diskserv\serialdk\disks\diapack1.rk5 /rk05 /os8 /partition:1

There was a question asked in this process,

Number of info words per directory [1]:

I didn't know what to respond here, so I entered 1. It seemed to work. There were no errors and a DIR SB1: in PUTR showed that there was only one .EMPTY. file.

BUT, OS8 responded to it's DIR with BAD DIRECTORY. I'm doing something wrong. Don't see what it is, yet. I sure would like to get this utility to work, Thanks Mike
 
Today, I continued to work with the PUTR program. Some how I screwed up my main build. So, nothing worked. I thought I had a good backup copy, but that was not there either. So, I spent most of my time today redoing the build. Fortunately, it seems to get easier the more I do it. This time the build worked flawlessly and I got back to square one.

Since then I have had some minor successes with PUTR. Most of my initial trouble was with formatting, especially with the 2nd partition. So I stayed away from that for the time being. I wanted more space on SDA0:. There are 6 larger files labeled *.X8. I read some where that these are Custom DEC X8 files. Not sure what those are, but I figured I didn't need them and it cleared out more than 600 blocks on the system drive. I did a DIR on OS8 to make sure that these files were there and they were. Then using PUTR, I mounted that drive, did a DIR here

mount s0: daipack2.rk5 /rk05 /os8
DIR s0:*.X8

Saw the same six files, and then deleted them.

Del s0:*.X8 and it worked.

I then did a OS8 DIR SDA0:*.X8 and the files were gone and the system and drive were still working.

Next I tried to copy, using PUTR, files I figured I needed to run Fortran. I did 9 copy's like this

copy s1:f4.sv s0:f4.sv

and it worked. I don't know what I was doing wrong with the 2nd partition or the format command. I want to make some more saves for a better restart if I need to before trying these some more. I've read up on Fortran and want to attempt to compile a small program next. Mike
 
I tried the Fortran IV compiler etal. I found that they need to be on the system disk to work properly, no sure why. I wrote a short Fortran program that accepts a few numbers from the TTY calculates an area and then types the answers back out to the TTY. I have a DEC Fortran document that says it supports the key words ACCEPT and TYPE. These statements directly support the TTY and do not need a I/O unit number, like read and write do. So I tried it and on the first pass of F4 I was issued two MK errors. One for the ACCEPT and one for the TYPE. Which mean there are key words that are mis-spelled. I didn't mis-spell them so I figured that they were not supported in this Fortran. So I changed them to READ and WRITE, which worked, but I don't know what unit designation numbers to use. I seem to remember that the standard I/O numbers were 5 for read and 6 for write. But how are they really determined? The addresses on my TTY card are 03 and 04. The addresses for the SerialDisk are 40 and 41. How are these values converted to the unit number of a READ (5,100) or WRITE (6, 110) statement? Mike
 
Better check which FORTRAN documentation you're using. ACCEPT and TYPE work in RT-11 F77 - I know because I was exercising my QBUS system tonight. Taking a quick look at the 8K FORTRAN section of "Programming Languages" seems to indicate (p15-28) that you'll need to use formatted READ and WRITE statements as you've noted. The standard device code for teletype and low speed reader/punch is given as 1 but I've never tried to use this version of FORTRAN so I can't tell you for sure.

Jack
 
Jack, thanks for the reference. I found 'Programming Languages' on bitsavers. It's amazing how much stuff is saved there. Looks like you are correct in that the for a formatted READ/WRITE statement, the TTY is 1. On page 15-61, they talk about special I/O devices. This section makes reference to how to change the device designation code in Utility Library subroutine, defining the entry points in HSIN and HSOUT. And it also talks about adding other devices that can use the READ/WRITE statement. So apparently if you have two M8650 cards and you want them both to be consoles, you can do that also. I want to be sure that the code #1 works with my code. Then when I have time I'd like to investigate how these changes could be made.

Not knowing that much about the DEC programs, I'm having some trouble correlating what documents go with what programs, but that will work out, Thanks again Mike.
 
Jack, the DEC Document I was looking at that suggested the usage if ACCEPT/TYPE was

DEC-08-AFAC-D PDP-8 Fortran Programming Manual, October 1967

Although I have not found any reference in this manual to 4k, 8k Fortran, F4, FORT; it only mentions in the intro that it will work with the PDP8 and the PDP5. Mike
 
Yeah, you've got me scratching my head a bit. I find the same reference in the slightly earlier 4K FORTRAN Programmer's Reference Manual (DEC-08-AFCO-D) as well. After digging around on the web a bit and not finding the ACCEPT/TYPE commands anywhere else, I'm thinking that maybe they were DEC extensions in the early programs that don't reflect the FORTRAN IV standard and were dropped to be compliant. Not sure about their reappearance in RT11 F77, but that's a search for another time. Right now, it's honeydew Saturday.

OK - one last bit - see here for a brief history of these non-standard extensions - http://fortranwiki.org/fortran/show/Modernizing+Old+Fortran .

The subject is near and dear to me because "back in the day", I used the RATFOR "precompiler" so FORTRAN is always a topic of interest.

Jack
 
Last edited:
Well..... do what you have to. If Mama ain't happy, nobody is happy. In the late 60's while in college, I was taught FORTRAN IV and we used a Burroughs 5500. All I really remember is how difficult it was to get a card deck that worked. We had to submit the deck by 6PM and then pick them up in the morning. Most times to see the works SYNTAX ERROR printed on the output.

I tried F4 this morning. Remember that I copied it over using PUTR. F4 failed, I was told of a CORE IMAGE ERR. I also found that PUTR only copied 1 block where F4 on the original image was 20 blocks. Maybe this is a clue. Still trying. Mike
 
I wrote a short 8 line FORTRAN program that compiles OK with F4. I'm having trouble with RALF. Seems with 7 lines it works but with 8 lines it doesn't. I get a TF error which means the line is longer than 127 characters, but I don't have on that long. So, I've been reading whatever I can find. I read that the RTPS FORTRAN, the F4, needs a floating point CPU. How do I know whether or not my PDP8E has a floating point CPU, betcha not. I've been looking for the RTPS FORTRAN User's Manual DEC-08-LRTPA-A-D but can't find it. I figure tomorrow I have to try using FORT instead of F4, maybe that will work. Mike
 
I believe I made some progress with PUTR today. I need to use the /BINARY switch to copy the entire file.

copy s1:RALF.sv s0:ralf.sv

this will only copy the first block, whereas

copy /binary s1:RALF.sv s0:ralf.sv

will copy the entire file. Tomorrow I'll load this new image and see if OS8 will work with it. Mike
 
It might help you to isolate your problem points by working with SIMH first to get a working tool chain (editor, compiler, assembler, linker, etc.) before worrying about transferring all the bits and pieces from one medium to another. That binary flag is always lurking, ready to bi(y)te, during file transfers.

Jack
 
Jack, etal, I have been working through the Fortran process. Although I run into problems and have to let it lay for a while to get my head on straight again. Sometimes I need just to do something else for a while, work on the car, walk the dog or try to get PUTR to work. It's all in my own personal programming or as my daughter says it's in the genes.

I've been getting through making a TEST.FT with the editor and have not had any problems with editor at all.

Using F4 also seems to be working. I was wondering about the statement I read somewhere that F4 needs a floating point CPU, mine must have one, because it seems to work. I've been using the /A switch so F$ will not chain to RALF. I'm a controller type.

.R F4
*SDA0:TEST.RA<SDA0:TEST.FT/A

I can add a list file as an addition output file and I get a nice display on that.

Next I run the assembler RALF

.R RALF
*SDA0:TEST.RL<SDA0:TEST.RA

Here is where some odd thing can happen. Some times this works fine, no errors and others there will be errors. I kinda suspect that maybe I still have some machine trouble. These errors only show up after the PDP8E has been powered up for more than 4 hours. AND the only trouble that I can see, so far is with RALF. It apparently has trouble reading the TEST.FT file. The TEST.FT is OK. I can TYPE it or look at it with EDITOR and it's fine. Yet RALF thinks that there are at least 4 errors in it. The next odd thing is that I shut the PDP8E down over night and in the morning RALF works again, for 3-4 hours, with no changes made at all. This has happened twice.

BUT when RALF does work, I can then link it with LOAD,

.R LOAD
*SDA0:TEST.LD<SDA0:TEST.RL
*$

The '$' is escape. This program is a stand alone and is not linked with other RALF modules.

Then I can use FRTS

.R FRTS
*SDA0:TEST.LD$

I haven't gotten this far too many times. I read that the '$' (escape) should load the file and run it. This seems to happen, but the program hangs the machine. I can reboot it by restarting it at 7600. I suspect my code, particularly the READ, unit designation number, statement, because I can not enter anything. This is my Fortran Program. Mike

Code: 
C       TEST
C       3/20/2016
5       READ (1, 10) A, B, C
10     FORMAT (3E6.3)
15     S=A+B+C
20     AREA=SQRT(S*(S-A)*(S-B)*(S-C))
25     WRITE (1, 30) A, B, C, AREA
30     FORMAT (4E6.3)
35     END
 
Mike,

You could always try the "Hello World" program. If you use the '*' in the WRITE statement it generally means the 'default output device' which (in this case) we can hope is the console. The second '*' being 'free format' as opposed to a statement number for a FORMAT statement.

C FORTRAN IV HELLO WORLD
WRITE (*,*) "HELLO WORLD"
STOP
END

Your problems do sound temperature related now you have described them.

Dave
 
The PDP8E started up this morning and worked fine, although last night, after maybe 6 hours of being powered up, RALF was generating errors which could not be corrected. Maybe there is a heat problem. I suppose that I'll just keep running the machine and wait for this problem to grow. Today the PDP8E ran for more than 4 hours with no RALF failures.

I want to thank Dave for making the suggestion of trying the HELLO WORLD program. It didn't work, but got me on the track to find out what does work. I entered the HELLO WORLD code and the F4 compiler would generate MO and RW errors pointing at the WRITE statement. This would occur if I had
WRITE (*,*) or
WRITE (1,*) or
WRITE (*,10) including the proper FORMAT statement. Apparently this application of '*' does not work with this compiler.

BUT, when I used WRITE (1, 10), this would compile and would run under FRTS, but generated a run time error of I/O error. This error was ID'ed as trouble read/write a file or writing to a input device or vice versa. So, something worked, maybe not correctly but.... So I figured that I'd try a different unit designation number until I found one that worked. Turned out that 4 is the number and the TTY punched out HELLO WORLD.

I then tried my AREA program and it also seemed to work. It would wait for my data to be entered, but would then display an error of

USER ERROR MAIN 0005

This turned out to be the square root statement. I'm guessing that SQRT is either not the correct spelling or it must be linked from a library. So I removed the SQRT and wrote something else, I got the READ/WRITE statements to work and a FORTRAN program to compile and execute. One area of work I have is becoming familiar with the Format for input and output.

Thanks Dave for the help, Mike
 
You must log in or register to reply here.
Back
Top