• Please review our updated Terms and Rules here

PDP-12 #435 at the University of Minnesota Duluth

Comparing the May 1969 copy that i have to the January 1970 produced the following differences:

Page 2:
1970 has two additional instructions:
SWD
STB
1970 shows the SXL instruction as 040N, 1969 shows it as 0400
1970 shows the SKP instruction as 0467, 1969 shows it as 0446
1970 shows the IOB instruction as execute PDP-8 I/O instruction, 1969 shows it as execute I/O operation

Page 3
1970 shows the LDF instruction as 064n Set Data Field n, 1969 shows it as 0640 Set Data Field
1970 shows the LIF instruction as 060n Set Instruction Field n, 1969 shows it as 0600 Set Instruction Field
1969 has 1900 as an undefined trapped instruction that is not on the 1970
1969 has 1717 as an undefined trapped instruction
1970 lists 1700 through 1737 as undefined trapped instructions

Page 5
1970 shows I=1 ß=0 operand is in next location 1969 shows address is in next location

Page 11
1970 shows 15 Bit Absolute Octal Address, 1969 shows 15 Bit (Address)-8

Page 12 (back page)
1970 shows @ and Bell that 1969 does not.
 
BitWiz said:
Would you like me to scan my copy of the May 1969 also.
Click to expand...
Sure! It would be nice to have the sequence for posterity. I would be happy to turn the scans into a "booklet PDF".

BitWiz said:
I might be able to produce a better quality copy if i scan it in black and white instead of color. I wanted to pick up the color of the original that is why I scanned it in color. I can also drag out my document scanner and scan it at a much high resolution but I didn't think we needed anything higher than 600 DPI.
Click to expand...
I agree that the color is nice -- nice to know how it evolved over time. At this point, I don't think that a higher-res scan is necessary.

BitWiz said:
Comparing the May 1969 copy that i have to the January 1970 produced the following differences:
Click to expand...
Very interesting! Some of these look like a notation difference (e.g., in the 1970 version they use n to indicate the variable part), some seem like omissions (1969 missing @ and bell), but some seem like typos, for example:

BitWiz said:
1970 shows the SKP instruction as 0467, 1969 shows it as 0446
Click to expand...
The 1972 version shows that the 044n instructions are listed as SNSn "Skip if sense switch n=1". So that's interesting.

Thanks again, @BitWiz -- really appreciate your help with this.
 
pahp said:
The 1972 version shows that the 044n instructions are listed as SNSn "Skip if sense switch n=1". So that's interesting.
Click to expand...
I actually corrected this in the cross-assembler when doing those dis-assemblies. I had previously generated the older value for LINC mode SKP.

I looked around trying to figure out what the "n" values for SNS do, but I couldn't find what n=6 would do, nor any real discussion of the SKP instruction. But it was clear from the listing what their assembler had generated for "SKP".

It may be that n=6 tested an unimplemented bit os the sense register, and they had inside knowledge how it would read, or something. But isn't the new 467 just "SNS I 7" instead of "SNS 6"? (I don't know why two unimplemented sense bits would behave oppositely.)
 
vrs42 said:
I actually corrected this in the cross-assembler when doing those dis-assemblies. I had previously generated the older value for LINC mode SKP.

I looked around trying to figure out what the "n" values for SNS do, but I couldn't find what n=6 would do, nor any real discussion of the SKP instruction. But it was clear from the listing what their assembler had generated for "SKP".

It may be that n=6 tested an unimplemented bit os the sense register, and they had inside knowledge how it would read, or something. But isn't the new 467 just "SNS I 7" instead of "SNS 6"? (I don't know why two unimplemented sense bits would behave oppositely.)
Click to expand...
I don't get this either.

I didn't even realize, until I looked at the Pocket Reference just now, that the I bit in SNS instructions inverts the condition (which is cool):
1732327723500.png
If I understand you, you're saying that it's weird that both 0446 and 0467 would be SKPs, since presumably both (nonexistent) "sense switches" 6 and 7 would likely return the same value (and the condition is inverted in the case of 0467)?

I wonder... is 0446 an actual SKP, or was that a typo?

Another thought... I notice that (above) 0466 is also listed as an unconditional SKP, which seems contradictory (how could 0446 and 0466 both be unconditional SKPs if the I bit inverts the condition?). Maybe if n=6 or n=7 it's always a SKP, regardless of the I bit? I'm away from our machine so I can't test.

Anyway, a good mystery.
 
pahp said:
I don't get this either.

I didn't even realize, until I looked at the Pocket Reference just now, that the I bit in SNS instructions inverts the condition (which is cool):
View attachment 1290062
If I understand you, you're saying that it's weird that both 0446 and 0467 would be SKPs, since presumably both (nonexistent) "sense switches" 6 and 7 would likely return the same value (and the condition is inverted in the case of 0467)?

I wonder... is 0446 an actual SKP, or was that a typo?

Another thought... I notice that (above) 0466 is also listed as an unconditional SKP, which seems contradictory (how could 0446 and 0466 both be unconditional SKPs if the I bit inverts the condition?). Maybe if n=6 or n=7 it's always a SKP, regardless of the I bit? I'm away from our machine so I can't test.

Anyway, a good mystery.
Click to expand...
I just gave a bunch of these a try:
0456 -> Skip
0466 -> Skip
0467 -> Skip
0446 -> No Skip
0447 -> No Skip


0446 does not skip and 0466 does skip.
 
I checked the code, rather than rely on my memory, and the cross assembler used to generate 456, but now generates 467, based on the work to reconstruct the focal-12 source. The 456 value is interesting, because I think it's just SNS 16, but it somehow does skip, where SNS 6 does not.

> 1970 shows the SKP instruction as 0467, 1969 shows it as 0446
It seems the 1969 version is/was just wrong, then.
 
pahp said:
I would say sure, if you don't mind! I always learn something new. Thanks!
Click to expand...
I took it apart so here are the double pages.
 

Attachments

Hi folks, here's a random question. We are playing around with Vince's dump of FOCAL-12. From the PDFs, it looks like it was intended to be assembled using LAP6-DIAL. PAL8 doesn't seem to be able to handle the inclusion of LINC mnemonics. @ZachyCatGames was able to get it to assemble by replacing the LINC mnemonics with literal numeric instructions (similar to how SPCWR3 declares constants for LINC instructions). But this made us wonder whether there is/was any assembler made for the PDP-12 that runs on OS/8 (or OS/12) that could handle the mixed instructions... PAL12, if you will? Thanks!
 
pahp said:
Hi folks, here's a random question. We are playing around with Vince's dump of FOCAL-12. From the PDFs, it looks like it was intended to be assembled using LAP6-DIAL. PAL8 doesn't seem to be able to handle the inclusion of LINC mnemonics. @ZachyCatGames was able to get it to assemble by replacing the LINC mnemonics with literal numeric instructions (similar to how SPCWR3 declares constants for LINC instructions). But this made us wonder whether there is/was any assembler made for the PDP-12 that runs on OS/8 (or OS/12) that could handle the mixed instructions... PAL12, if you will? Thanks!
Click to expand...
The pal in 8tools will assemble LINC code if you use the -e flag. (Without the -e it pretty strictly enforces "Family of Eight".)
 
pahp said:
@ZachyCatGames got errors trying to compile FOCAL-12 with PAL12, but got it to compile with your pal -e, @vrs42 -- thanks!
Click to expand...
Interesting. The reconstruction is meant to be almost exactly the source as presented in the listing. DEC presumably compiled that source with something, and PAL12 should have been the reasonable choice. Maybe some compile time option is needed?
 
vrs42 said:
Interesting. The reconstruction is meant to be almost exactly the source as presented in the listing. DEC presumably compiled that source with something, and PAL12 should have been the reasonable choice. Maybe some compile time option is needed?
Click to expand...
They might've time traveled to the future and used your assembler.
Would the assembler in LAP6-DIAL behave any differently? The listing pdf mentions DIAL at the top of each page.

But yeah, I tried two different versions of PAL12, one is the one linked above, the other I found on one of our LINCtape. I couldn't get either to assemble any of your focal12 pal files without any errors (I was able to get binaries with errors though). The PAL12 on our LINCtape spammed `IC ILIST` forever (seemingly, I don't have infinite time available, unfortunately. EDIT: `12-ajaa.pal` did give some other errors after I tried Ctrl-Cing, after which the entire program locked up) with all of the pal sources files. The PAL12 on that rk05 image completely failed to assemble `12-ajaa.pal` but was able to assemble `16383.pal` and `57236.pal` with errors.

If helpful, I've attached all of my logs (00 logs are from the PAL12 from that rk05, 01 logs are the PAL12 from our LINCtape) and the PAL12 build from our LINCtape.
 

Attachments

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