• Please review our updated Terms and Rules here

SIMH/os8diskserver/PDP-8

Hi All;

Thank You Mike for the Update..
"" The engine will be out soon to check all the clearances and a general inspection. I rebuilt the engine about 5 years ago, all new babbitt etal. ""
I hope that You take Plenty of Youtube Video's for the Rest of T'Less people to Enjoy..

THANK YOU Marty
 
No need to remove the engine. Just open the little hatch in the bottom of the oil pan, use the swivel sockets to remove the rod ends, put some PlastiGauge on the bearing, tighten it back up, remove the rod end again, and measure the width of the PlastiGauge.
 
If you only want to check the crank bearings, But I want to check the cam and gearing, the transmission bearings, grind the valves and inspect the magneto. I've got a feeling that the thrust clearance on the crank is too wide and I want to make sure nothing is loose in the magneto. That can cause major trouble. Dirty hands Mike.
 
I use an old 1950 Black and Decker machine for the valves. I had to machine a couple new pilots for the Model T stems, but it works well.

Got back to the PDP8E, loaded the RIM Loader and loaded the BIN loader. AND... the bin loader would not run. Reloaded and tried again. Checked and re checked everything, all looked good. So I checked the BIN loader that I thought I had loaded. It was not there. So, I tried again, no soap. Shut everything down and toke the dog for a walk to think about it. Came back, started the PDP8E up loaded the RIM and the BIN, and this time it was there. Next I loaded DHKMA and it worked also. The TTY displayed everything that Don has posted earlier. I entered the fields on SR and off it went. I got the 5's the program ran for about 4 hours with no errors.

Seems odd that the PDP8E seemed to be hung up on something, Yet I could load Kyle's Serial Disk and I could load up OS8. I wonder if when I shut the machine down if something was set that prevented the BIN load. Then after a power off and on, that something was reset and allowed it to run.

What's the difference between the DHKMA and DHMCA? It says that DHMCA tests the time share, which I do not have, but does it do any additional tests on the memory? DHKMA says extended memory test and DHMCA says memory extension.

Suppose it is time to move on to the other CPU tests. I figure that I'll just work my way down the list. The adder is next. I want to keep my eye on whether or not I have more trouble with loading the BIN. It could be a clue to something amiss in the machine, or it could be human error again. Thanks Mike
 
What's the difference between the DHKMA and DHMCA? It says that DHMCA tests the time share, which I do not have, but does it do any additional tests on the memory? DHKMA says extended memory test and DHMCA says memory extension.

DHMCA is a test for the functionality of the M837 KM8-E board. It will test the extended addressing logic (ie, EMA addessing) and the instruction and data field addressing registers. It also will check that the 'time share' logic is working, if you have that enabled on your M837 card. This logic is not used by OS8, but will be used by the time-sharing operating systems like TSS8. It allows a 'user mode' operation that traps on halts and IOTs so you can run a true multiuser O/S on the PDP-8e.

The actual memory test program is DHKMA and it will assume that the extended addressing logic on the M837 card is known to be working.

DHMCA should be run first, and then run DHKMA memory testing afterwards.

Don
 
Seems odd that the PDP8E seemed to be hung up on something, Yet I could load Kyle's Serial Disk and I could load up OS8. I wonder if when I shut the machine down if something was set that prevented the BIN load. Then after a power off and on, that something was reset and allowed it to run.

I replaced some front panel bulbs and finished the installation of the new front panel overlay last night. Now my 8/e won't run. Load Address works, but nothing else. A power cycle fixed it just once. Oh well, time to do some debugging.
 
Mike, sorry to hear that during your spruce up our machine failed. I bet something with the front panel either broke or didn't get re connected. Probably a user error, that's never happened to me.

I believe that the BIN loader trouble I had was self inflicted. I had two BIN loaders and one does not work. I think that one was the one that I was attempting to force to work, yesterday.

This morning I got DHMCA loaded and I verified a few addresses with the proper data. So it looks like it loaded correctly.

The DHMCA instructions say to;
1. load address 0200
2. set SR0=1 to not test memory only
3. set SR9,10,11 to the extended fields. I set them all to ones
4. Clear and continue
5. The program runs and halts at 3651. The instructions say that this confirms memory only test. This happens.
6. Press continue
7. The program will run until an error occurs or the user can stop it with setting SR1=1.

My machine will halt almost immediately after #6 at address 243, which is a program halt.

Appears that maybe my problem is with extended memory. I checked my cache of spare parts and I found another M837 board, but this resulted in the same behavior.

I suppose that the next step is to better understand the DHMCA program and find out what was being done just prior to Address 243. Then look at my M837 boards for a problem. Am I thinking correctly? Mike
 
Hi Mike,

I believe you said that you're using one of Vince's 32k memory cards? It's possible to get some errors with these cards due to speed problems (documented on Vince's site IIRC). I found that my card didn't work properly if it was towards the back of the 2nd omnibus but it works fine in the slot just after the cpu. I reported this to Vince some time back and he confirmed that this was a likely symptom of the speed problems he knew about.

Since mine worked fine in that slot I never got around to swapping any ICs (Vince's suggested solution).

I'm not suggesting this is your problem, just something to be aware of. Maybe check the details with Vince?
 
Last edited:
The HALT at 243 indicates a problem with the CDF/RDF instruction or the DF (data field) register and not memory.

The test code is (simplified):

AC = 7767
store binary 001 into DF.
Logically OR the value in AC with the value in DF (but DF shifted left by 3 bits). This should give a value in the accumulator of 7777.
Complement the accumulator (which should give 0000).
Skip the next instruction if AC non-zero (i.e. an error).
HALT

What value is in the accumulator after the CPU halts?

I notice that the first two tests (that have passed) store binary 000 into DF correctly and binary 111 into DF also correctly. But it is 001 that fails. Is it possible that there is some interaction between one or both of the higher two bits of DF (e.g. storing 001 leads to 000 in DF)? I think you had some problems like this before didn't you?

You could also try manually loading values from 0 to 7 into DF via the front panel and check that the correct combination of indicator lamps light for DF.

You could then try a very small hand-assembled program to narrow the problem down further:

0200 6201 ; CDF 0000
0201 6211 ; CDF 0010
0202 6221 ; CDF 0020
0203 6231 ; CDF 0030
0204 6241 ; CDF 0040
0205 6251 ; CDF 0050
0206 6261 ; CDF 0060
0207 6271 ; CDF 0070

set PC to 0200 and single step through the program. The program should store 0 through 7 into DF as each instruction is executed. If this is OK it is probably the RDF instruction that is at fault somewhere. Let me think of a small program for that eventuality.

Dave
 
Last edited:
The accumulator has 0007 in it when the machine halted.

Your short program seems to work. I loaded it at 0200 and single stepped through it. With the function switch on STATUS the data bits 9, 10 and 11 progressed from 000 to 111.

I'm not familiar with what the CDF and RDF instructions do. I'll do some reading to better understand these. Thanks Mike
 
Next you could try the following little program (set PC to 0200 and single step each instruction again).

0200 62n1 ; CDF 00n0
0201 7200 ; CLA (AC = 0000)
0202 6214 ; RDF
0203 7240 ; CLA CMA (AC = 7777)
0204 6214 ; RDF

Set n to 0 first (instruction at address 0200 to 6201) and then increment n by 1 for each run of the program.

You should get the following results:

n = DF AC after instruction 0202 AC after instruction 0204
-------- ---------------------------- ---------------------------

n AC02 AC04
0 0000 7777
1 0010 7777
2 0020 7777
3 0030 7777
4 0040 7777
5 0050 7777
6 0060 7777
7 0070 7777

Hope this makes sense?

Dave
 
So - an answer of 0007 (not 0042)...

Can you just double check when the machine halts that memory address 0051 actually contains the value 7767. If not, the AC is not loaded correctly with the constant 7767 before we start to execute the test code in DHMCA.

When DHMCA halts at 0243, you could reset the PC to 0235 and single step through from there.

The instruction at 0235 should load AC with the value 7767.
The instruction at 0236 should load DF with binary 001.
The instruction at 0237 should update the AC value from 7767 to 7777.
The instruction at 0240 should complement the AC from 7777 to 0000.

I would assume that one of these steps is going wrong somewhere...

Dave
 
Just fired the PDP8E up again to try your next suggestion. Loaded BIN and DHMCA. Started it as before and the results were the same. So, I thought of trying what Bob suggested. I had Vince's card 6 slots away from the CPU. I bunched the CPU, the 32K memory card and the M837 right next to each other. Tried again and the program is running. It beeps every four minutes or so. And the SR=1 stops the program. I'll try it again tomorrow. Mike
 
Just fired the PDP8E up again to try your next suggestion. Loaded BIN and DHMCA. Started it as before and the results were the same. So, I thought of trying what Bob suggested. I had Vince's card 6 slots away from the CPU. I bunched the CPU, the 32K memory card and the M837 right next to each other. Tried again and the program is running. It beeps every four minutes or so. And the SR=1 stops the program. I'll try it again tomorrow. Mike

That's how I have my 8m configured. Timing+CPU+EAE in the front slots, followed immediately by MemExt. Rear of the backplane is bus loads, two 8K core memory sets, then the EMI shield. Random I/O boards are in the middle slots.

Don
 
There were a bunch of chip changes on Vince's memory board from the very first versions. If yours still has the fast chips it may cause problems.
 
There were a bunch of chip changes on Vince's memory board from the very first versions. If yours still has the fast chips it may cause problems.

I believe I have the later version. ALS245s and LS540. I have not had the time or absolute need yet to put it up on an extender and see what is going on. The 16K core is 100% reliable right now, so I'm going to stick with that as long as possible. Earlier when I was taking the machine apart I pulled all the core memory and used just the SRAM board configured for 32K and it would not work reliably in that configuration either.

Don
 
Today, I put the 32K memory card back into its original slot. I want to see if I could replicate the halt during the DHMCA. I could not the program ran fine. I then tried the card in 4 different positions and they all worked fine. I'm at a loss as to why it halted the first time. I'm thinking of taking some time to test the core memory boards that I have. I have 2 sets of G111 8K boards. If I remember correctly one set seemed to work, while the other set had some problem. So since I'm familiar with DHKMA and DHMCA I figure that maybe tomorrow I'll load up the core cards and see what happens, before continuing in my search as to why I'm having trouble with Fortran. Mike
 
It could have been just a bad/dirty connection somewhere on one of the edge connectors of one of the cards.

Have you run all the diagnostics in the right sequence and got a full set of PASSES so that your 99.9% sure that the 8e is as 'correct' as it can be before moving on to your FORTRAN program again? You could try your FORTRAN program and it works. The odds are probably against you though.

Dave
 
No, I have not finished with all the MAINDEC programs. I only work a little bit at a time. So far with the 32K board in place the DOAB, DOBB, DHKMA and DHMCA programs have run successfully. I will continue and hopefully a problem will arise.

I did do a little more with the Fortran program. I was first alerted by an error in calculating a square root. Since then I simplified the program and found that it is more basic and pertains to floating point numbers. My program just accepts a FPN from the TTY and then returns it to the TTY. I found that a 3.0 will work correctly, yet a 3.00 and 3.000 returns a negative number. This includes numbers like 3E1 works, whereas 3E2 and 3E3 does not. The FORMAT statement is correct and allows for enough characters on both input and output. I also found that any number starting with a 7 does the same. The 8 and 9 work similar to the 3. The remaining numbers are OK. So, something that accepts a FPN from the TTY and accept converts it to FP in the computer is doing something wrong. The Square Root error occurred because it was trying to work on a negative number. So I'm pretty sure that it is not the library LIB8 file.

This is sure a head scratcher. Mike
 
Back
Top