• Please review our updated Terms and Rules here

Data General Nova 1200

It wasn't U11.

As far as I can tell, the "P" pulse refers to a special pulse used for interacting with I/O devices. When a No I/O Transfer instruction is sent, which device it applies to depends on the last 6 bits of the instruction. Device code 0 refers to the CPU, and is sort of a dummy instruction. The decoding for that goes nowhere, and presumably for moments where the CPU needs to test itself like this (see U63B pins 9 and 12).
1749792988780.png
We never see the ION signal set at any point, which is good because we shouldn't.

Anyway, kind of stumped right now, as the diagnostic manual is incredibly obtuse at times about explaining what precisely you need to test.
 
CommodoreZ said:
As far as I can tell, the "P" pulse refers to a special pulse used for interacting with I/O devices. When a No I/O Transfer instruction is sent, which device it applies to depends on the last 6 bits of the instruction. Device code 0 refers to the CPU, and is sort of a dummy instruction.
Click to expand...
P is just another signal you can send to the device (along with S and C). Not used a whole lot (most notably used to initiate a seek or recalibrate on a disk drive), but given there were 2 bits available so that decodes into 4 possible options...

Device 77 refers to the CPU. There is no device assigned to device 00. Test A10 is verifying that u64A is not stuck at a 0 output...
 
Okay, we may have found the point of failure, and it's upstream of the part being explored per post #101.
1749869931575.png
This N8271 shift register is used to store a bunch of states as we progress through processing. The signal we care about is how IO*E is generated from IO(F+D). Presumably, that data is loaded in every time PTG5 is asserted (processor time group 5)
1749870100006.jpeg1749870110345.jpeg

So why is IO*E changing when PTG5 is not being asserted? We're not using the serial function, so that can be ignored. The reset would presumably clear that value, not set it, so how exactly is that happening?
1749870158108.png
The cyan trace should only change with the blue trace, and it's changing whenever it feels like it.

1749870195341.jpeg
We're also seeing suspicious signals down the line that are triggered from IO*E. Look at the rise time spikes on IO*E on U62A, with rather slow ramp-up. Plus, there are negative going spikes out of U62A when edges cross in some ways that feel like we shouldn't be seeing any changes. But I think this could explain why we're never seeing U63B's O0 ever pulse low like we expect to. Now I just need to find my spare N8271's...

I'm still not clear how exactly the CPU logic test is determining that this failure is occurring, but whatever. We'll get there.
 
CommodoreZ said:
So why is IO*E changing when PTG5 is not being asserted? We're not using the serial function, so that can be ignored. The reset would presumably clear that value, not set it, so how exactly is that happening?
View attachment 1302672
The cyan trace should only change with the blue trace, and it's changing whenever it feels like it.
Click to expand...
Do you think it's shifting rather than holding? Looks like the serial in is floating, which we've seen previously results in a high level. So suppose pin 13 is not properly grounded - if it floats from time to time (e.g., due to a bad solder joint), then it looks like a high level to the chip and will do a shift regardless of the state of the Load input...
 
1749919417175.png

I fixed it? I honestly don't know what happened.

I replaced U42. And the tests kept failing. So I had my hand-entered diagnostic routines tested with a second set of eyes. Turns out I had some bits wrong... human error. :oops:

I still don't know what initially caused the fault that sent me down this rabbit hole, but what's important is that it's running BASIC again in a minimal 8K configuration. At this point, I want to just bring myself back up to a stable 16K configuration, and then take another crack at installing my modern fan controller module such that I can hear myself think when the machine is running. Those two industrial Noctua fans are loud at full-bore.

Oh, and word of advice? Don't debug when you should be sleeping.
 
So, on the 8K core plane I've been using, I ran the 1200 Logic Test for like 80 minutes non-stop, and it ran without issue for the duration of the test. Then I switched over to the Memory Checkerboard III test, which also ran without issue for over an hour, no faults detected or reported.

I switched over to my second 8K core plane which had been reconfigured to start at address 00000 (normally I have it start at 20000). While it seemed like the bootstrap routine ran fine, the binary loader did not, meaning my attempt to pull in Memory Checkerboard III failed. I have half a mind to toggle the source in by hand from the accompanying manual. It's interesting how I can examine and load memory from the front panel on that plane with no issue, but I can't load that in from a program running at full speed. Strange.

I've also determined that my third 8K core plane has 4 stuck bits. Bits 6 and 13 always write/read back 0. Bits 7 and 12 always write/read back 1.

My fourth (and final) 8K core plane causes the front panel lamps to go into oscillation, so that's concerning.

Also, my second experiment with that modern fan controller has proven to be useless. I need to find a better solution for PWM fan control, and I'm thinking of going dumber this time, rather than smarter. Just having a speed potentiometer sticking out the back of the modern PSU vent will likely be better so I can turn the speed down on both and keep airflow consistent. I've been told simple 555 timer circuits can be built to this end, and maybe I'll tackle that later.
 
It's been nigh on 50 years and I don't know if this relates to the problems you're seeing, but my recollection is that a common failure point on those core memory boards is the sense amp transistors (2N5022 w/heat sink). Might be a good idea to track down a few for when you do end up needing them :)
 
Steve Toner said:
It's been nigh on 50 years and I don't know if this relates to the problems you're seeing, but my recollection is that a common failure point on those core memory boards is the sense amp transistors (2N5022 w/heat sink). Might be a good idea to track down a few for when you do end up needing them :)
Click to expand...
It's interesting that I've seen a number of these core memory boards show up on eBay recently with multiple (in some cases a half-dozen ) 2N5022 missing, apparently having been scavenged in order to repair other boards. Example with four missing:
107-000414-01 NOVA 8K Memory - Front.jpg

I'm curious as to why many of these core memory boards didn't use (those cute radial-fin) heat sinks?

Heat Sinks.jpg

I thought that it was a pretty neat cost-shaving design decision to implement the current source resistance components just once, off-board adjacent to the power supply, rather then on a per-board basis.
 
You must log in or register to reply here.
Back
Top