• Please review our updated Terms and Rules here

MAINDEC D0FC ISZ test

Mike_Z

Mike_Z

Veteran Member
Joined
Dec 1, 2013
Messages
1,713
Location
Near Milwaukee Wisconsin
I've been adding to my paper tape library of MAINDEC routines. Today I came across the ISZ test D0FC.BN and it didn't seem to work. I loaded the tape and the PDP8E started and halted after a few seconds, which didn't seem correct. I then tried to load the program from disk, thinking that maybe there was an error on the paper tape, but resulted in a similar behavior. Then after reloading the tape again, I checked the code at 0200, against the listing and the first page of code looked OK. I then checked the last page of code and most of it didn't match the MAINDEC listing. Both my paper tape and the disk file had the same errors. Not to surprising in that I made the paper tape from the disk file. Then I started to look for another copy of the D0FC.BN file, I found one, but it had similar code at the end. Then I noticed that there is another random ISZ MAINDEC file D0FA.BN. I'll try that one next. I also saw a youtube of D0FC.BN running on a PDP8M machine. That program ran much longer (in fact it looped) and reported 'FC' each time the loop was successful. Does anyone have what they believe is a good copy of D0FC.BN? I'm still looking, Thanks for the help, Mike
 
Thanks, I tried yours and it behaves the same as the others. So something is wrong with my hardware, etal. Odd thou, today I made 4 new MAINDEC paper tapes and they all worked just fine. Then this. The other odd thing is that D0FC didn't report any errors, the program just ran for a few seconds and then halted. I had forgotten about SIMh. Will have to brush up on it some. Maybe there is a cue there, but I suspect something else. Thanks for the help, Mike
 
Well if you can get the address it halted at and then look it up in the listings that will be a good start for debugging.
 
Vince beat me to what I was going to post.

To make sense of the documentation/listing you have to have a binary tape that matches.

For example, D0Fv - where ‘v’ is the version/release and should match.

I always check some random words and addresses just for my own sanity...

You can find later revisions of the binaries online. If they work OK, all well and good but (if they fail) you may have to start doing a bit of reverse engineering to find out what is failing. I have done this before, but it is easier to find the matching binary...

Don’t forget that the diagnostics look at the key switches for their configuration information.

A HALT whilst running the diagnostics is always a possibility if the program gets into trouble or goes into the weeds. This is why the recommended procedure is to run the diagnostic tapes in a specific order (the simple ones first building up in complexity). In this case, D0A and D0B must have been run first to give the first two (2) basic instruction tests a clean bill of health. This should (indirectly) identify possible memory errors before you get to the memory tests themselves.

Dave
 
Last edited:
Gentlemen, since it was rather warm this morning 35 degrees, I thought I'd take a walk and figure out how to attack this. Then after reading your reply's, I loaded up D0AB and D0BB, using my paper tapes and both loaded right up and ran just fine.
So, I loaded the D0FC.BN again and ran it. The behavior was the same. This is how I load the paper tape,
Code: 
.R ABSLDR
*PTR:D0FC.BN/G
^ (ready tape) >ENTER<
SR=0000
After the paper tape stops, the program seems to start, runs for about 5 or 6 seconds then halts at 7605.
Next, I checked the data at address 7602, this is what I found
ADD Found Should be
7602 0000 1411
7603 0033 6046
7604 7602 6041
7605 6213 5204
7606 5267 1013
7607 3021 7640
7610 7600 5202
7611 1334 5217

I then checked and found the file to have the correct code. Then I checked and found that the paper tape, for these addresses was also correct. So something must have over written this code when the program ran.
The next step will be to check the code in the machine against the file. This may take awhile, Mike
 
Mike_Z said:
After the paper tape stops, the program seems to start, runs for about 5 or 6 seconds then halts at 7605.
Next, I checked the data at address 7602, this is what I found
ADD Found Should be
7602 0000 1411
7603 0033 6046
7604 7602 6041
7605 6213 5204
7606 5267 1013
7607 3021 7640
7610 7600 5202
7611 1334 5217
Click to expand...
I don't think ABSLDR will load over the system handler. You may have to use a proper BIN loader to put code there. (Then you'd also need to reboot after.)

Vince
 
Vince, I don't understand. I've used ABSLDR for all the other MAINDEC's on paper tape and it worked fine. I have noticed that I need to re boot after a run. Mike
 
The lowest DEC BINLDR location is 7612, the last program location above is 7611 so there should be no overlap. They directly abut. ABSLDR IDK.
If you want, there is a RIM format of the tape here: https://www.ak6dn.com/PDP-8/MAINDEC/KK8-E_pdp8e_cpu/
I usually use those because I have the RIMLDR for the tty setup in my PDP-8m board which I can invoke via the SW switch.
Then I just send the RIM format tape down the console serial port via TeraTerm send binary file.
The RIM format I generate has a bit of code appended at the end so the program autostarts when the download is complete.
 
Last edited:
Yes, I would use either the RIM loader or the standard BIN loader.

I think you may be a bit optimistic loading this from an operating system with ABSLDR...

I think there maybe some “DEC magic” going on above 7600!

Dave
 
I've tried the BIN loader and I can load the other MAINDEC;s and they seem to run, both fomr tape and files. The D0FC ISZ tester loads, but refuses to run, but the behavior is different, the program runs and this time it does not halt. There is something wrong somewhere, but it will have to wait. I've been given orders. I need to do something else, Thanks for the help, Mike
 
Mike_Z said:
Vince, I don't understand. I've used ABSLDR for all the other MAINDEC's on paper tape and it worked fine. I have noticed that I need to re boot after a run. Mike
Click to expand...
This is note 3 on page 77 of the OS/8 SRM:
Code: 
3.  Programs which load into 07600 or 17600 are ignored by
    ABSLDR. No error is generated, but these locations are
    never loaded. (It is a good idea not to use 7600 in any
    field.)

Vince
 
You should be able to use bootstrap 13 if you set SR0 off. I should look, but I think bootstrap 02 may also work.

Vince
 
If it is running with the BIN loader, then are you waiting long enough?

Can you monitor the various registers (e.g. PC) to see what it is up to. The setting of status register SR9 has a dramatic effect on the speed. 1 = 11,000 operations/second as opposed to 0 = 3,500 operations/second. Although fast means not as thorough...

Dave
 
It looks to me like this cannot be run from OS/8 as it has code that sits in the system handler area of memory. And it isn't that ABSLDR couldn't be written to allow this, it just wasn't probably because it makes no sense to deliberately blow away the OS. The code they put up there is strange stuff. It sends a RUBOUT terminated string to the console including the RUBOUT. It then clears the transmit flag and enables the interrupts. ABSLDR probably loads everything except for this stuff. So the program runs and then tries to print something and jumps into a handler call argument list for saving the memory that OS/8 overlays use (at 7602 while the real entry point is 7600) and it goes into the weeds.

Interestingly, D0FC from 1971 looks the same as D07A (for the Straight 8) from 1967. At least the few bits I looked at. There are probably some very minor differences but the ISZ is the same instruction on all the different CPU's.

I suggest you toggle in the RIM loader and then use that to load the BIN loader and then feed in the tape.

It is really unlikely that it would boot if ISZ was not working.
 
You must log in or register to reply here.
Back
Top