• Please review our updated Terms and Rules here

SIMH/os8diskserver/PDP-8

I read somewhere that F4 needs a floating point CPU, mine must have one, because it seems to work.

FRTS contains its own software floating point routines. If it finds a hardware floating point processor at run time it uses that otherwise it uses its built-in routines. There are a very few language restrictions when using the software routines but otherwise it's only a question of the speed of operation.
 
Jack, they are both 4. READ(4,10) and WRITE(4,20). Still have not found the files where they are set.

Bob, you wouldn't know how to tell if my PDP8E has Floating point? Or how I could find out?

Thanks Mike
 
The only hardware floating point option for the 8 that I'm aware of is the FPP8A, a set of two hex cards for the PDP-8/A. They would not physically fit in your 8/E. Does anyone know of anything else?

Jack
 
The only hardware floating point option for the 8 that I'm aware of is the FPP8A, a set of two hex cards for the PDP-8/A. They would not physically fit in your 8/E. Does anyone know of anything else?

Jack

The single cabinet full of FLIP CHIPs that is used with the PDP-12 and 8/I. Not too useful for an 8/e either.
 
Bob, you wouldn't know how to tell if my PDP8E has Floating point? Or how I could find out?
Thanks Mike

As jackrubin and m_thompson have noted above your pdp8/e is very unlikely to have a floating point processor. There were 2 types made for the 8 - the original FPP and the A version. The former predates the omnibus 8s (and it's bigger then an 8/e) but can be used with 8/e and an omnibus interface. You'd certainly know if you had one ;). The later version was for the 8/a and was hex wide (the 8/e is quad wide). Again I'm sure it could be used with an 8/e but wouldn't fit into the omnibus, you'd really need an 8/a chassis daisychained.
 
As jackrubin and m_thompson have noted above your pdp8/e is very unlikely to have a floating point processor. There were 2 types made for the 8 - the original FPP and the A version. The former predates the omnibus 8s (and it's bigger then an 8/e) but can be used with 8/e and an omnibus interface. You'd certainly know if you had one ;). The later version was for the 8/a and was hex wide (the 8/e is quad wide). Again I'm sure it could be used with an 8/e but wouldn't fit into the omnibus, you'd really need an 8/a chassis daisychained.

Or just move your 8/e CPU board set to the 8/a box for a one box solution. The OMNIBUS expansion cables (two of them) are not easy to find in my experience. You would lose the blinkin' lights panel, however.

Don
 
Two other people have asked me related questions about 8/A boards in the last couple of days, though related to the RL8A. Lou already demonstrated that the hex-wide RL8A controller (M8433) will run on a quad extender board in an 8/E. Tonight, I figured I'd take a look at putting a hex board in a deep chassis (i.e. power supply in the back) version of an 8/M. The answer is that if you pull the original fan you can have a front panel 8 with RL drives.

The M8433 is especially nice for this project because it has no contacts at all on the E and F segments of the board - nothing, no data, no clocks, no power, no ground. Other boards of interest (FPP8, MOS memory) do have some connections on these tabs but they could be jumpered if you really wanted to use them in a quad chassis. If needed, you could mount the fan on the outside of the case or arrange inboard cooling with a different fan configuration.

IMG_7256.jpgIMG_7257.jpgIMG_7260.jpgIMG_7261.jpg
 
Last edited:
Jack, that one look more like the KL8A (M8319) quad serial line card. The four UARTs in the top right corner. Happen to have a few of those including the bulky cable harness.
 
That's more like I remember it.

I used to have one. But I was foolish once back in the early 90ies and traded it together with the FPP8A I had for a RK611. How stupid is that...
 
Today I tried to LINK the FORLIB.RL file to my simple program that uses the square root, but I received a BAD INPUT FILE in response to it. I did;

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

.R RALF
*SDA0:TRI.RL<SDA0:TRI.RA$

.R LOAD
*SDA0:TRI.LD<SDA0:TRI.RL
*SDA0:TRI.LD<SDA0:FORLIB.RL
*$

This is where the Bad Input file occurred. If I do not use FORLIB then it will work. So apparently my FORLIB is not a RALF module or something is wrong with it. Looking at what I can see about the file is that it does have 165 blocks to it so there is something in it. I started to read about LIBRA and it looks like you can add and delete stuff from library files, but I don't see how to just look and see what in a file. AND there is no RA files to re assemble.

After some more reading, I found that the LIB8.RL, if on the SYS drive, will automatically be used during LOAD. So I tried that and it worked. There were no errors at all, except the program answer was wrong. So I wrote a very simple program with SQRT

Code:
	A=36
	B=SQRT(A)
	WRITE (4, 10) B
10	FORMAT (E14.3)
	END

I figure the answer is 6.0, but the machine spits out 4.24. I must be using SQRT incorrectly. Mike
 
FORLIB.RL is the library for the FortranII system (FORT.SV, SABR.SV, LOADER.SV). The OS/8 FortranII and FortranIV are incompatible systems because (as previously discussed) the FortranIV system is based on the Floating Point system whereas the FortranII system generates native PDP8 code.

Strange error in your example above - oddly the result is SQRT(A/2)???
 
I also found reference to the Square Root function being called SQTF for FORTRAN II (see http://www.quadibloc.com/comp/fort02.htm). There looks to be an 'interesting' document at ftp://ftp.dbit.com/pub/pdp8/doc/fivssm.doc.

Have you run all the MAINDECs for your 8e that will run yet? If not - you may assume that you are using SQRT incorrectly - whereas the PDP-8 is telling you that it is not working properly...

Dave
 
Other than the hand written routines that Mike Thompson provided, I have not run any other routines. I remember talking about the MAIN DEC's but you'll have to refresh my memory as to where to find them. Could they be all the *.DG files that I have on the system disk? Mike
 
Here is a screen shot of a spreadsheet that I use that itemizes all the core CPU/option diagnostics, and switch options for loading/running them, and how they indicate success/failure. I load these from paper tape (RIM or BIN) images thru the console, but if you have them on an OS8 disk they should have similar names (ie, something like D0AB.SV, etc).

Capture.jpg

BTW if someone can tell me how to post larger images please do so. Even if I do a screen shot that is fairly large size, by the time it gets to the posting it has shrunken to (almost) illegibly small. Is there a trick to larger images, or is this something the management has configured in the forum software?

If I post a PNG that is 1050x542 55KB it gets turned into a JPG 484x248 30KB. Hardly seems like much of a saving.

Don
 
Last edited:
I found some maindec files on so-much-stuff website. Those titles look like some of the names you have. Is there any particular order that these files should be done in. For example should the memory test be done first? Maybe tomorrow I can try a couple of these. Since Bob pointed out that my SQRT error is 1/2, I wonder if there is a problem with the adder? Thanks Mike
 
I found some maindec files on so-much-stuff website. Those titles look like some of the names you have. Is there any particular order that these files should be done in. For example should the memory test be done first? Maybe tomorrow I can try a couple of these. Since Bob pointed out that my SQRT error is 1/2, I wonder if there is a problem with the adder? Thanks Mike

I would run the basic instruction tests #1 and #2 first. They provide good overall coverage. Then follow with the memory checkerboard test to test memory.

I've not found the 'random' series tests to be that useful overall. Usually either an instruction works or it doesn't, unless there is some really obscure timing and or thermal problem. The 'adder' test is marginally useful, but usually if there are adder problems you can't even get from one instruction to the next.
 
so-much-stuff is a good website. I have http://www.bernhard-baehr.de/pdp8e/MAINDECs.html bookmarked. The BIN files are here (binary from paper tape) - but good descriptions of what they are. Unfortunately, the documentation is in TIF format not PDF. Use the PDF files from so-much-stuff (http://so-much-stuff.com/pdp8/software/maindec.php). The documentation contains some pointers as to what to run first - but as AK6DN has said - processor tests 1 and 2 first.

You could have some latent errors still within the processor (say the MQ register) which won't normally show up until you use it. The MAINDECs provide a systematic way of testing the 8/E logic out by starting small (does the HALT instruction work correctly) and building up from there.

You may also find that getting a copy of SIMH up and running as an 8/E (or one of the other simulators) may identify if your FORTRAN square root works correctly (in which case it is a hardware issue) or not (in which case you could try using SIMH with OS/8 to build your test program correctly first and then try it on the hardware second).

Dave
 
Last edited:
Back
Top