• Please review our updated Terms and Rules here

PDP-12 #435 at the University of Minnesota Duluth

The RICM's PDP-12 is also having problems, so I ran those serial console tests yesterday. I use PuTTY for the serial console with the port configured to 1200, M, 7, 2 and it works OK.
 
I made a video today demonstrating auto restart with a program to rotate a bit through the AC and how -- with the auto restart control -- you can turn the PDP-12 into a musical instrument.
 
pahp said:
I made a video today demonstrating auto restart with a program to rotate a bit through the AC and how -- with the auto restart control -- you can turn the PDP-12 into a musical instrument.
Click to expand...
I have the music program written by Gerald Johns for the classic LINC. When your 12 is solid, it would be fun to get it working there. I think it toggles the LINK bit for audio control.
 
vrs42 said:
If you have the big backplane you may also have the priority interrupt controller.

The EAE provides multiplication, division and normalization primitives which are useful for floating point emulation. Of course, if you had an FPP, the emulation with integer arithmetic was pretty lame, even with the EAE assist.

The EAE instructions are a bit similar I think, at least in power, to the hardware multiply and divide available in the LINC instruction set.

Vince
Click to expand...
No divide instruction on the LINC -- only multiple.
 
Today, Kyle Rose and I did a bunch of debugging on the PDP-12. We verified that both serial interface cards are capable of sending and receiving characters with the punch-in programs. We used MTTTY to avoid any terminal escape sequence shenanigans. We verified that the OS/8 bootloader.rim loads correctly from the rimloader (by checking it after loading). We also made sure that we had a known good PDP-12 boot disk image. However, when attempting to boot OS/8, we got our usual error, which is that it requests Block 0 and then crashes with no prompt.

We also finished testing the last chunk of flip chips that are testable without the use of the 'scope, so now every easily-tested flip chip has been tested within the last 3 months or so.

Given that both serial connections seemed to be behaving correctly, we tried loading the BIN loader. That seemed to work, but when we ran it to load the first diagnostic (D0AB), we didn't set the RSW to 4000. It did not seem to load the diagnostics properly. Anyway, we finally got it to run, and we ran and loaded D0AB, which passed with flying colors, including testing each sense switch individually. We ran out of time, but we'll start with the next diagnostic. Hopefully we will be able to narrow down whatever the issue is.
 
@m_thompson I thought that D0AB was the first diagnostic to run. I'm hoping to run more tomorrow. Is there a different preferred order?
 
I think that both parts of MAINDEC-08-D1MA are usually run first. They are supplied in RIM format so less functional instructions are needed to load it.

I remember seeing a recommended sequence for the diags, but I can't find it.
 
I mentioned over in the "What I did to my PDP-8 today" thread that I've been working on a "HELLORLD!" program for the UMN PDP-12. I got it working perfectly under the SIMH branch @vrs42 is working on in his big SVN repository, and was excited to see it run on "actual germanium".

Today @pahp toggled it in at the console, and it seems that the AC never clears after returning from LINC mode: the AC always seems to have 0030 in it. You can see a demonstration of the effect here.

I've added a CLA instruction to the code as a workaround for now, but Vince, do you know what could be causing this? I don't see any documentation of any side-effects of the LINC 6141/PDP 0002 instructions that could explain this, and the trap-handler code I found for the 12 seems to assume that you can blindly TAD after coming back via PDP.

At present, this seems like a bug in the UMD machine, but perhaps AC is meant to report on some sort of error condition or something?
 
Well, I couldn't see a lot in the video, so I went downstairs and tried it. It does the same thing here.

From what I can see with single step on, the LINC instruction immediately changes mode to L mode, and then the DSC is fetched. During E2 of DSC, AC is set to 30. Then a fetch of PDP is followed by a fetch of the TAD in 8 mode. AC is still 30.

This matches my understanding of the LINC and PDP instructions. Unlike the LINC-8, which has a separate register set, the PDP-12 wants you to communicate between the modes in AC.

The mystery then changes to why the DSC left 30 in AC. I think I used to know that, but nothing is coming to me now.
 
Oh, I think it's because DSC is documented to update the Y co-ordinate in AC.

Page 72 of this document:
does mention that the AC is set to 30 by each DSC instruction of their example. Page 127 desribes DSC, and says 30 is added to V (which is to say, AC).

So, it seems this isn't working in the SIMH. Looking at the code, it seems I did the clear of the bottom 5 bits of AC as documented at the start (page 71), but forgot to copy "y" back at the end. (Beware; LINC documentation numbers the bits other way 'round.)
 
vrs42 said:
So, it seems this isn't working in the SIMH. Looking at the code, it seems I did the clear of the bottom 5 bits of AC as documented at the start (page 71), but forgot to copy "y" back at the end. (Beware; LINC documentation numbers the bits other way 'round.)
Click to expand...
Well, that's quite a relief from our end! The emulator is always easier to repair than the physical machine, of course.

I'll keep the extra CLA I just put in, and go do a bit of code-bumming to get the instruction count back down again.
 
So, I tweaked the code for DSC. It should now clear the low 5 bits of AC, then OR in 6*scale at the end to update Y. (Scale is two for half-high mode, otherwise 4.)

I got slightly inspired, and set up a .ini file for tank. After re-assembling tank.pal to turn off me VC8E kludges, and turning on the EAE option, it actually draws and updates the tanks! They update preposterously fast, and you can't steer them (or anyways not the left one), but I think my SIMH is doing the right thing.

Alas, tank.pal is basically a disassembly of tank.sv. Is there original source code for tank anywhere?

I should try space war, too.
 
SpaceHobo said:
Well, that's quite a relief from our end! The emulator is always easier to repair than the physical machine, of course.

I'll keep the extra CLA I just put in, and go do a bit of code-bumming to get the instruction count back down again.
Click to expand...
Yes! Thanks @vrs42 -- and of course it's always nice to knock a bug out of an emulator. And kudos to @SpaceHobo for the keen eyes... blinkenlights for the win. I'll try to run the updated program later today.
 
pahp said:
Yes! Thanks @vrs42 -- and of course it's always nice to knock a bug out of an emulator. And kudos to @SpaceHobo for the keen eyes... blinkenlights for the win. I'll try to run the updated program later today.
Click to expand...
It was a lot of fun watching your videos on my phone at the pub, and scribbling notes on my copy of the listing. International console-level debugging!
 
vrs42 said:
So, I tweaked the code for DSC. It should now clear the low 5 bits of AC, then OR in 6*scale at the end to update Y. (Scale is two for half-high mode, otherwise 4.)
Click to expand...
Now I am thinking DSC may still be not-quite-right. It seems to me that in half-high mode, only the bottom 4 bits of AC should be cleared? Otherwise each line of the text will still be 32 pixels high., creating effectively a blank line between each line of text.
 
You must log in or register to reply here.
Back
Top