• Please review our updated Terms and Rules here

PDP-12 #435 at the University of Minnesota Duluth

DougIngraham said:
It would be difficult (very or extremely might be good to add before difficult) to add to an older machine like a PDP-12.
Click to expand...
I'm not sure if you know this, @DougIngraham , but my former student Julian is working on a "nonvolatile 24k on a card" flip chip that, with some daughter cards and ribbon cables) plugs into the interface to the external 24k cabinet. So, once that's working, any 8k PDP-12 will be able to easily jump up to the full 32k. He's made one version that worked in some sense but had some showstopping bugs that he's working out.
 
pahp said:
I'm not sure if you know this, @DougIngraham , but my former student Julian is working on a "nonvolatile 24k on a card" flip chip that, with some daughter cards and ribbon cables) plugs into the interface to the external 24k cabinet. So, once that's working, any 8k PDP-12 will be able to easily jump up to the full 32k. He's made one version that worked in some sense but had some showstopping bugs that he's working out.
Click to expand...
That sounds like a really interesting project but that is not changing the extended memory system to allow for the 17 bit addressing that is the 128k mentioned in the video or found on the 8/a.

I look forward to hearing how Julian's project turns out.
 
DougIngraham said:
Actually you could get an EAE on the 8/a. They did this by using the 8/e CPU (KK8E). You replaced the M8615 (KK8A CPU) in slot 1 with the bus terminator card and put the other CPU cards in the bottom slots of the 8/a chassis. One of my 8/a machines was equipped this way.
Click to expand...
I'd describe this as an 8/E CPU with EAE in an 8/A chassis. It was done fairly often, though, as a solution to the problem that there's no way to extend the 8/A CPU card to include EAE instructions.

Vince
 
DougIngraham said:
That sounds like a really interesting project but that is not changing the extended memory system to allow for the 17 bit addressing that is the 128k mentioned in the video or found on the 8/a.

I look forward to hearing how Julian's project turns out.
Click to expand...
Yes, of course. The connection was "adding memory to a pdp-12", but what you were talking about would be much cooler (and exponentially harder).

We will definitely keep people posted about Julian's project; I'm trying to get him to sign up here.
 
We continue to test all testable flip chips. Hoping to finish today, and if luck smiles on us, repair two M216s that are failing.

@vrs42 @m_thompson and @DougIngraham -- we notice that there are many tests for M221 chips:
  • M221_IN.TST
  • M221.new
  • M221.NEW
  • M221.NEW.1
  • M221.NEW.2
  • M221_REG.TST
Is there a recommendation of which tests to do, or not to do (that is the question)? Thanks!
 
I'm imagining the next M221 test to be named something like M221.NEW.2.FINAL.FINAL.TST :ROFLMAO:
 
Funny, but I have seen documents labelled kind of like this. Not fun trying to figure out which is really the "final" one.
 
tradde said:
Funny, but I have seen documents labelled kind of like this. Not fun trying to figure out which is really the "final" one.
Click to expand...
Yes, it would be best if the test suite could be amended to use functional names for these tests, if possible.
 
pahp said:
We continue to test all testable flip chips. Hoping to finish today, and if luck smiles on us, repair two M216s that are failing.

@vrs42 @m_thompson and @DougIngraham -- we notice that there are many tests for M221 chips:
  • M221_IN.TST
  • M221.new
  • M221.NEW
  • M221.NEW.1
  • M221.NEW.2
  • M221_REG.TST
Is there a recommendation of which tests to do, or not to do (that is the question)? Thanks!
Click to expand...
The M221 is by far the most complicated to test. There have been several running starts at it, but so far, no definitive approach has been developed which "tests everything". So I'd probably run them all, except one with the lowercase.

At one point, Kyle even wrote a file with about a zillion randomly generated vectors, figuring that was as likely to find a problem than a bunch of half-finished manually generated tests.

Vince
 
SpaceHobo said:
Yes, it would be best if the test suite could be amended to use functional names for these tests, if possible.
Click to expand...
In general, if there's a "correct" test, it's called "Mxxx.TST", where Mxxx is the number of the flip chip module. Everything else is experimental or under development, though much of it is quite useful. Alas, Warren is deceased, so some of this is also historical.

If I had experience with something actually not working, I've probably renamed it so that the name has lowercase. That prevents it's selection in the tester software, as that mono-cases the input before attempting to look things up.

Vince
 
vrs42 said:
The M221 is by far the most complicated to test. There have been several running starts at it, but so far, no definitive approach has been developed which "tests everything". So I'd probably run them all, except one with the lowercase.
Click to expand...
Thanks! That's great to know. I appreciate it.

vrs42 said:
At one point, Kyle even wrote a file with about a zillion randomly generated vectors, figuring that was as likely to find a problem than a bunch of half-finished manually generated tests.
Click to expand...

Hey, that's a great idea!

vrs42 said:
In general, if there's a "correct" test, it's called "Mxxx.TST", where Mxxx is the number of the flip chip module. Everything else is experimental or under development, though much of it is quite useful.
Click to expand...
...
vrs42 said:
If I had experience with something actually not working, I've probably renamed it so that the name has lowercase. That prevents it's selection in the tester software, as that mono-cases the input before attempting to look things up.
Click to expand...
Thanks. I think I was worried about something being misleading or dangerous, so avoiding the lowercase is helpful advice, and just knowing that the issue is not so much "bad tests" as that the M221s are just complicated to test thoroughly.

vrs42 said:
Alas, Warren is deceased, so some of this is also historical.
Click to expand...
I also understand wanting it to reflect some of the history of the project and Warren's work. Makes sense to me!

As always, thank you for the context and helpful information.
 
pahp said:
Thanks. I think I was worried about something being misleading or dangerous, so avoiding the lowercase is helpful advice, and just knowing that the issue is not so much "bad tests" as that the M221s are just complicated to test thoroughly.
Click to expand...
I am, of course, also open to the possibility that someone will someday produce a proper set of vectors to fully test the M221 :).

Vince
 
vrs42 said:
The video makes clear that I should have been more specific about which Kyle did the random vectors for the M221. That was Kyle Owen, not the Kyle in the video :).

Vince
Click to expand...
Yes! I knew what you meant but clarity is great.
 
Hello! :)

Yes, random vectors were a fun thought for the M221, but what would be interesting is to leverage an expensive license of some ASIC automatic test vector generation tool. I probably could have had access years ago to such things at the university, but not anymore.
 
Sperry had a tool to do something like that. I worked in the design verification group on new hardware being developed. This piece of code generated code segments, then emulated that code to predict what the results would be and then ran the actual code. This did find some interesting flaws that may not have shown up any other way. I did not write that code, just saw it being used.
 
It was fun to notice this afternoon that our M169 card references LINC-8 by name:1000002301.jpg1000002300.jpg
 
You must log in or register to reply here.
Back
Top