• Please review our updated Terms and Rules here

SIMH/os8diskserver/PDP-8

Mike_Z said:
This morning I downloaded both the DECBIN and DNNBIN. I tried

D0GC, D0HC, D0IB, D0JC

And they all worked. The DECBIN halted at the finish of loading and DNNBIN would start the loaded program. I did have some trouble with D0IB, I think it over wrote some addresses in the bin and rim loaders. I tried it twice and had the same result, could have been my error, but....
Click to expand...

That is the standard behavior of the DEC BINARY loader. It halts at the end of a block, you are expected to check the AC contents to see if the tape loaded correctly (AC=0) or not (AC#0) by validating the checksum manually. My optimization to the DEC BIN loader in DNNBIN was to jump to 200 if the checksum was OK if SR<0>=0, else go back to the main BIN loader loop (waiting for the next download segment) if SR<0>=1. This facilitates download multi-part binary tapes (like some FOCAL tapes).

D0IB only uses locations 0-5500 or so in page 0, so it does not load anywhere near the BIN loader at 7600-7777. D0IB is like some of the earlier diags in that it only rings the bell on normal EOP. Did your running of D0IB halt at some address, or was it running at ringing the bell and you could not tell thru your terminal program?

So, I'm moving on to D0LB. I loaded D0LB, set the start address to 0200 and set SR=5000. The program ran and almost immediately HALTED at 5510. The program description says that a halt at 5010 is

SWAB failed to set mode B or DPSZ failed.
Click to expand...

Very likely means you don't have the EAE option present (board set M8340/M8341 and associated top blocks). Or it is very, very broken.

I looked up SWAB (I have very little information on these) and it says 'Switch from Mode A to Mode B'. I don't know what Mode A or B is.
Click to expand...

Modes 'A' and 'B' are two different operating modes of the EAE instruction set. Mode 'A' (default) is PDP-8I EAE compatibility mode; mode 'B' is the enhanced PDP-8E EAE mode that has additional functionality. PDP-8E Maintenance Manual volume 2 chapter 1 has all the gory details.

DPSZ is Double Precision Skip if zero. This is obviously something that pertains to Floating Point Math.

I had the impression that this program would print out the error, but nothing was printed. I tried a few different SR settings, but the result was always the same.

So, what's next? I don't know what to do about the SWAB. Maybe I can think of something to directly test DPSZ. Ideas? Thanks Mike
Click to expand...

Need to open the top cover and do a visual inspection of the (possible) EAE board set. Or not :-(

Don

PS I wanted to add my two cents here FWIW but Dave pretty much explained what is happening in the posts just prior to this ...
 
Last edited:
Now we are more enlightened... can you list exactly what cards you have in your system so that we are working from a common base. I tried to search the thread(s) but got myself lost!

I was having a read of the OS/8 languages manual (http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/dec/pdp8/os8/AA-H609A-TA_os8lang_mar79.pdf) and it did state that the FORTRAN IV compiler is "automatically self-expanding" meaning that it identifies what hardware you have and makes automatic use of it - although there are still some limitations if you haven't got all the hardware. Presumably, if you haven't got the FPU or EAE options - it emulates all the floating point stuff in software (with the penalty being speed). So (if you haven't got the EAE boards installed) the FORTRAN compiler should still perform your square root correctly. Of course, if you don't have the EAE option installed, running the MAINDECs are pointless for the EAE option!

Reading the words a bit more closely, DOUBLE requires the floating point hardware to be available. SQRT uses a normal REAL as the argument and function return value so should work both with and without the hardware assistance (from my reading).

Dave
 
Last edited:
Mike_Z said:
I think that I have just had an enlightening. I think that the problem that I'm having is I do not have a M8340/41 board in my machine. I have been confusing M837 which is extended memory and time sharing for the M8340/41 which is EAE. Geeezzz. So I suppose that which out the M8340/41, Fortran will not function properly? Am I correct? Mike
Click to expand...

I have run both Fortran IV and Fortran II on my SBC6120 system, which is based on the single-chip CMOS PDP-8 processor. This chip does not support any EAE instruction set functionality. According to the OS8 manual, Fortran IV libraries will use EAE if they detect it, otherwise will default to regular instructions, which will obviously run the code much slower. No reference to EAE support in FortranII at all, I don't think it will use it even if it is present.

Bottom line is without EAE you should still be able to run either FortranII or FortranIV.

Don
 
That is interesting, in that getting Fortran IV to run was the goal. To repeat the trouble I ran into with Fortran IV was that I wrote a program like this
Code: 
5    READ(4,10) S
10   FORMAT (E14.8)
15   WRITE (4,29) S
20   FORMAT (E14.8)
      GOTO 5

After compiling this program I could enter numbers and the program would repeat them back. If I entered numbers like

1.0 or 1.00 or 1.000 or 1E1 or 1E01, the answer would always be 0.100E01

Yet went I entered 3.0 the answer would be 0.300E01 which is correct but 3.00 would be a negative number and 3.000 would be another negative number but a different value. 4, 5 and 6 would work fine. None of the 7's would work and 8 and 9 would work in the same fashion as 3.

So..... I still at a loss where to look for the solution to this. Could there be a problem with a loaded library. I'm using F4, RALF, LOAD and FRTS --- with LIB8 library. Mike
 
What if you don't try and use input, but rather use a DO loop to count from 0.0 to 10.0 by 0.1 or 0.01 or 0.001. Then print out the value, the value squared, value cubed, etc.

Try and narrow down to if your CPU is doing math wrong, or if it is somehow just related to the input read of floating point numbers.

Don
 
Don, I'll try your idea. I did try using a defined constant, like S=7.0 and then writing it back to the TTY. This worked in a similar fashion as using an input, not correctly.

My PDP8E was rescued from the dumpster. It was part of a Kearny & Trecker machine tool. It has only has one 20 slot omnibus and the back space had a custom K&T bus that had all the interface stuff for the machine tool. The boards that I am currently using are (and installed this order)

Front Panel board
M8330 timing board
M8300 & M8310 Major Registers
M837
Vince's 32k memory board
M8650 set at 110 baud for TTY
M8650 set at 9600 baud for Kyle's Serial Disk
M8320 bus termination.

I have a few spare boards, including two sets of 8k G111 memory boards. I found that both memory sets have problems. One has a bit that can not be set and the other has a stuck bit. Some time in the future (?) I'll get all the boards I have tested and repaired.

I now understand that running the EAE tests will not work. This is the first time I tried to repair something I didn't even have. Maybe I can find a set of M8340/41 some day.

So, getting Fortran IV to run is still the goal with the machine. Let you know what happens with the DO LOOP program. Thanks Mike.
 
Mike_Z said:
My PDP8E was rescued from the dumpster. It was part of a Kearny & Trecker machine tool. It has only has one 20 slot omnibus and the back space had a custom K&T bus that had all the interface stuff for the machine tool. The boards that I am currently using are (and installed this order)

Front Panel board
M8330 timing board
M8300 & M8310 Major Registers
M837
Vince's 32k memory board
M8650 set at 110 baud for TTY
M8650 set at 9600 baud for Kyle's Serial Disk
M8320 bus termination.
Click to expand...

Is your M8320 bus terminator board in the last slot of the OMNIBUS backplane? It should be, even if there are a bunch of empty slots between it and the serial boards. The bus terminator should always be at the physical end of the bus (ie, last slot of all backplanes). Otherwise nothing much else comes to mind on your hardware configuration, it is fairly minimal.

Given that you can run diagnostics for extended periods of time (esp the memory diagnostic) even a misplaced M8320 would not seem to make a significant difference, as your Fortran issue is fairly repeatable.

Maybe it is time to check that the s/w disk image you are using does not have some corrupted bits in it.

Don
 
Last edited:
I pretty much agree with what Don has said. He chipped in his few cents a post or two ago - so I will chip in a few pence as well...

At the moment we have the hardware, the software and the application that we have to find a fault somewhere. We need to 'divide and conquer' to find out where the problem lies.

Now you know what cards you have and what they do I would suggest running each of the applicable MAINDEC diagnostics from Don's website for at least an hour each. This should rule out the hardware (it should identify 'hard' faults - which I don't think exist - and random 'soft' faults - which may cause you problems in the future).

Next - what is the state of play with FORTRAN IV? Try the following program which (if I read your posts correctly) doesn't work:

10 S=7.0
20 WRITE (4,30) S
30 FORMAT (E14.8)

If this fails, can you change statement 30 to FORMAT (F8.5) and try again.

If this also fails, there is a problem with FORTRAN somewhere.

Now, you could try and run FORTRAN on simh and (if it fails there) it is also definitely not the hardware (as there is no hardware involved!).

My preference would be to try BASIC first under OS/8 if you have that option on your disk.

.BASIC

You will be asked something like NEW or OLD.

Enter NEW TEST in response to the prompt (create a NEW program called TEST).

Enter the following program:

10 LET S = 7.0
20 PRINT "S=",S
99 END

and RUN it. Does it work?

If so, modify the program to:

10 LET S = 7.0
20 PRINT "S=",S
30 PRINT "SQR(S)=",SQR(S)
99 END

and RUN it. Does it give you the answer 7 and 2.6457...?

If so, modify the program again as follows:

10 PRINT "ENTER A VALUE FOR S..."
20 INPUT S
30 PRINT "S=",S
40 PRINT "SQR(S)=",SQR(S)
50 GOTO 10
99 END

and RUN it.

You should be prompted to enter a value and the value you entered, and its square root, should be displayed. You should get a run-time error reported from the SQR function if you enter a negative number; and BASIC should go back to the command prompt.

There is still a possibility here that the 'flavour' of BASIC you have on your OS/8 disk may have been built for the EAE cards you don't have - but let's worry about that one later.

What I am looking for is to see that BASIC runs on your hardware. If so, we can make the expressions a bit more complex to make sure that the floating point libraries of BASIC are OK - and then we can turn our minds towards the FORTRAN implementation - as we now know that your hardware is sound.

That's my take anyhow. Sometimes the quickest route is not always the most direct.

Dave
 
Interesting...

So, I found some RX disk copies of OS/8 and OS/8 with FORTRAN. I stuffed the OS/8 disk with BASIC on it into SIMH and ran BASIC. So far so good. I managed to enter a program. I then tried to RUN the program and I keep getting the error "BAD FILE". I suspect that either the compiler or run-time overlay that the BASIC front-end is trying to load is corrupt.

I will have a go with the FORTRAN at some point in the future and see if I can get that working.

Mike: Where did you download your OS/8 image files from? I may as well try and use your image files rather some random ones I found on the internet! I realise that you have modified your build for the serial disk interface rather than a real disk or tape - but at least we should both be using the same executable software.

I may still have a problem with my SIMH pdp8.ini file of course...

Possibly ran out of disk space on both the BASIC and the FORTRAN disks. I will have a go some other time and create a disk with the bare minimum on it. Just getting into OS/8 myself - so a bit of a learning curve to go up.

Dave
 
Last edited:
There is a lot here to look at and do. Here is what I have done so far.

Well, after Church this morning I had to look at a laptop at school that had water spilled on it. I'm betting that it got dumped into a bucket of water. I have it drying out, maybe it will work again.

OK, My bus terminator load card is in the last slot of the 20 slot omnibus. I also wrote a Fortran program with a DO loop as Don suggested.

Code: 
      S=0.0
      S2=0.0
      X=0.0
      DO 50 I=1, 100
10    WRITE (4,15) S, S2
15    FORMAT (E14.8)
      X=I          /I is an integer and this converts it to real
      S=(X/10)
20    S2=S**2
      END

'OUTPUT'
.00000000E0 .00000000E0
.10000000E0 .00000000E0
.20000000E0 .00000000E0
...... and so on......

I got the DO loop to work and all the S numbers printed out correctly. YET the S**2 would not work. I tried S2=(S)**2, S2=S*S and these didn't work either.

Next I tried

Code: 
10    S=7.0
20    WRITE (4, 30) S
30    FORMAT (E14.8)
      END

'OUTPUT'
.70000000E+01

I also tried S=7E2 with the correct answer. Now I wondering if READ is the problem.

I have heard about simh but not sure exactly how to get it or run it.

I'll try BASIC later.

Mike
 
Setting S to 7.0 and writing it out didn't work a while ago. If it looks like this is working now - go back to your AREA program (or try a READ of S) and see what happens. You never know - it might work?

Have a read of https://bigdanzblog.wordpress.com/tag/pdp-8/. This blog identifies getting SIMH, PDP-8, OS/8, BASIC, FORTRAN and Uncle Tom Cobly and all running!

SIMH is available from http://simh.trailing-edge.com in source and pre-built binary form for Windows. It has a whole load of simulators included.

My current pdp8.ini file look like:

SET CPU NOEAE
SET CPU 32K
SET CPU IDLE
SET TSC DISABLED

SET LPT DISABLED
SET RK DISABLED
SET RL DISABLED
SET DF DISABLED
SET RF DISABLED
SET DT DISABLED
SET TD DISABLED
SET MT DISABLED
SET CT DISABLED

; RX84/RX01 Floppy disk.
SET RX ENABLED
SET RX RX8E

ATTACH RX0 ./os8_rx.rx01
ATTACH RX1 ./os8f4_rx.rx01

SHO DEV

BOOT RX0

The software images I found were on RX01 floppies from https://www.pdp8online.com/images/images/os8.shtml.

EDIT: I downloaded the business BASIC from http://www.pdp8online.com/pdp8cgi/os8_html?act=dir;fn=images/os8/business_basic.rx01;sort=name (as specified in the blog) and that worked OK with SIMH straight away. There was some spare space on this disk - but I don't think that was the problem. My guess would be that there may be 'corrupt' disk images out there on various websites...

Dave
 
Last edited:
Well.... I've tried a number of items and there are still a boat load of trouble. I downloaded disk2.fortran.rk05 from pdp8online.com. Now before I even consider this file corrupt, let me tell you that I down loaded this file and made it the second disk on Serial Disk. Then I copied over a number of files to the system disk. It could be possible that I need to copy another file or two over to the system disk.

I copied

F4.SV
RALF.SV
LOAD.SV
FRTS.SV
PASS2.SV
PASS2O.SV
PASS3.SV
LIB8.RL

There are other .SV and .RL files on this disk. Some of them are OS8 programs like CCL, PIP and EDIT. Some are Fortran II files. But I'm not smart enough to know which is which, at least for every file. I may have labeled some of these incorrectly.

The entire directory is
BOOT.SV OS8
DIRECT.SV OS8
FOTP.SV ???
CCL.SV OS8
PIP.SV OS8
LOADER.SV Fortran II
FORT.SV Fortran II
F4.SV Fortran IV
PASS2.SV Fortran IV
PASS2O.SV Fortran IV
PASS3.SV Fortran IV
RALF.SV Fortran IV
LOAD.SV Fortran IV
XYPLOT.RL ???
LIBRA.SV ???
FORLIB.RL ???
FRTS.SV Fortran IV
NUMBER.RL ???
EDIT.SV OS8
PLOTLB.RL ???
PLOTR.FT Fortran program
AXIS.RL ???
PSCALE.RL ???
LINE.RL ???
PLOTR.LD Loaded Fortran program
PAL8.SV Assembler
BUILD.SV OS8
TDFRMT.SV ???
LIB8.RL Fortran IV Library

I picked this file 'disk2.fortran.rk05', because it was an RK05 file and matched what was being used for Serial Disk. There are other files but with a different format and I figured that made a difference. Mike
 
"...still a boat load of trouble". What trouble Mike? A problem shared is a problem halved (or is that doubled?)

Dave
 
Well, the square root still doesn't work, the exponential function will not work ( S**2 or S**3 ), the READ function still causes negative numbers when numbers like 3.00 instead of 3.0 are entered. Yet I can correctly compile programs with most of the other functions, adding, subtracting, etal. Maybe I do have some corruption in one of the programs or libraries. I'm using Kyle's Serial Disk RK05 on a Raspberry Pi for my storage. I also have Serial Disk on an XP machine. They both work fine and don't believe the trouble is here. Since Serial Disk is RK05, I figured I needed a RK05 disk image of Fortran to go with it. I have only found one source for that 'disk2.fortran.rk05 from pdp8online.com'. I have seen other Fortran disk images, but they were RX01.

Can I download a RX01 disk image and retrieve the Fortran files and run those on the RK05? Or maybe at least compare the files to see if there is a difference?

Is there a way to look at the output of F4, RALF, LOAD and FRTS individually to see where a possible error is occurring? Maybe I can narrow down the problem that way.

It is possible that the problem is in the Library LIB8.RL, can I look into the library and see what functions it contains? Maybe if I can find different listings of LIB8.RL, I could compare them possibly rule out the Library.

Forgive my 20 questions approach, I'm just thinking out load. I'd appreciate any thoughts. Mike
 
Have you run the RK05 images with SIMH to make sure that everything works OK?
You could compile a FORTRAN program with SIMH and run it on the 8/e, and compile it on the 8/e and run it on SIMH.
That might give you some idea of where the failure is ocuring.
 
OK, Looks like I will have to learn how to use SIMH. Dave gave me some references and I'll take some time to see if I can get that to work and try your suggestions. Thanks. Mike
 
So, I downloaded your disk2.fortran.rk05 and mapped it onto an RK05 drive in SIMH. Booted SIMH into RK0 to be greeted by the OS/8 '.' prompt.

Wrote a noddy FORTRAN IV program using EDIT (that was a trip down memory lane...).

Worked out how to use F4 the 'easy' way..

If you have a program called TEST.FT.

.R F4
*TEST/G<ESCAPE>

Where <ESCAPE> is the escape key on the keyboard. It takes the FORTRAN source in TEST.FT and runs it directly - no messing with files, RALF or the LOADer.

My noddy program consisted of setting S = 7.0. Setting T = SQRT( S ) and then WRITEing out the values of S and T.

And it got the answer wrong!

Not to be defeated I had a play around and realised I had setup SIMH with SET NOEAE (to disable the EAE hardware simulation). I commented out this directive in my pdp8.ini file and and restarted OS/8. This time - I was greeted by the correct answer!!!

At the moment I am thinking that FORTRAN runs OK on a PDP-8 with the EAE hardware - but has problems without the EAE present (or at least that is what I have found out for tonight at least). I will have a further think and see if I can come up with an alternative idea.

Dave

PS: SIMH will be your friend - get to know how to use it. Honestly. The pdp8 implementation contains a pretty full implementation of most of the common hardware there is out there (e.g. RK05 and RX01 disks, TU56 tape drives etc. etc. etc.). You can use the pdp8.ini to customise the simulation hardware environment and you can boot from a nominated device. You can (for instance) connect an RX01 image to the first RX controller and an RK05 image to the first RK controller and (providing OS/8 is configured with the appropriate hardware device drivers) copy files from one device to another. In your case, you can copy files from a downloaded RX01 image to an RK05 image and then use the resultant RK05 disk image with your serial interface to your physical PDP-8 hardware.
 
This was written prior to reading Dave last post.

Well..... I've been struggling with getting SIMH going, but after a while I did get it to work. Once again I was my own worst enemy, I kept using O rather than 0. And I kept getting confused between the RK05 drives. Serial Disk has SDA0: and SIMH uses RKA0:. That stuff is behind me. I used Dave's suggestion of reading Dan the Blog Man's site, but I changed the disk images to the ones I have on my PDP8E.

My PDP8.INI file looks like

Code: 
SET CPU NOEAE
SET CPU 32K
SET CPU IDLE

ATTACH RK0 ./rk0.dsk
ATTACH RK1 ./rk1.dsk

BOOT RK0

The rk0.dsk is DIAGPACK2.RK05 and rk1.dsk is DISK2.FORTRAN.RK05. Both files are from the pdp8online site.

Once I got the simulator started and I confirmed that the disk images were the same as my PDP8,

I deleted all the RKA0: *.DG and *.X8 to make room for my files.

Then I copied the Fortran files to the system disk

RKA0:F4.SV<RKA1:F4.SV
RKA0:pASS2.SV<RKA1:pASS2.SV
RKA0:pASS2O.SV<RKA1:pASS2O.SV
RKA0:pASS3.SV<RKA1:pASS3.SV
RKA0:RALF.SV<RKA1:RALF.SV
RKA0:FRTS.SV<RKA1:FRTS.SV
RKA0:LIB8.SV<RKA1:LIB8.SV
RKA0:LOAD.SV<RKA1:LOAD.SV

So, I believe the simulator is similar to my PDP8E.

Next with EDIT I wrote this Fortran program.

Code: 
5     READ (4, 10) S
10    FORMAT (E14.4)
15    WRITE (4, 20) S
20    FORMAT (E14.4)
      GOTO 5
      END
PDP8.JPG
Here is a screen print of entering 3.0, 3.00, 7.0 and 7.00. These are the same results that I get on my PDP8. So, I'm still wondering where the problem is. I think my machine is OK. Am I missing a file to properly compile my program? Or is one of the downloaded files corrupt? I think I know more, but still not enough. Thanks Mike
 
Last edited:
Yup.... I removed SET CPU NOEAE from my INI file and now the program works. Suppose I have to find a couple of M8340/41 cards. Thanks Mike

PS. Yet the OS8 handbook does say the Fortran expands if it doesn't find EAE. So apparently SIMH doesn't do so and my machine either doesn't or the disk images I have don't. Are there different versions of OS8 and Fortran IV? Maybe what I have doesn't match what the OS8 handbook says.
 
Last edited:
Do you really need FortranIV? It appears you have FortranII on your disk image (fort.sv). Have you tried using it?

Unless you have some big compute bound program you plan to run (which flies in the face of a PDP-8 anyway) FortranII should work w/o EAE.

Don
 
You must log in or register to reply here.
Back
Top