Repairing my 2001-N

[johnq]

This might turn out to be a long running thread.

A while back I got a 8032-32B PET, or so I thought. It turned out to be a franken PET with a 8032 case, 2001-N board and a CRT. Not only that the 2001-N had a mix and match of wrong chips, and lots of missing chips.

More info on that here if you want to know the history:

J

Post in thread 'PET 8032-32B How many chips should be missing on the m/b?'

Oct 28, 2023

I'm also wondering if the main board has been swapped from another machine?
Can anyone identify is this is all original parts?

PET 8032
Motherboard Assy 320351 E (PCB part no. is 320350 Rev B)

Also confusing is one of the ROM chips is a 901447-29
which according to the list is a editor ROM is for a Screen editor for BASIC 4, normal keyboard, no CRTC

No CRTC?! Is this ROM also incorrect?

It has the following ROMS - which also appear to be in the wrong locations:
901447-29
901447-10
901465-02
901465–20

The other ROMs are missing.

• johnq

Fast forward a year and I've now decided to try and repair the 2001-N.
Assembly 320351

It was missing pretty much all the socket chips, so RAM, ROM, CPU, PIA which I've replaced with known good, or equivalents (for the ROMs)

I've used these ROM adapter boards in VIC-20/C64's so I know they work and have tested them with a custom ROM tester.

First thing I did was hook up the motherboard to power without any of the chips in.
Power rails are all stable and present. +5V, -5V, +12V

Next I checked the reset line - working as expected.

I then inserted a 6502 NOP adapter and checked the address lines and logic. All working as well. So 6502 seems to be functioning.

Inserted 6502, RAM, ROMs, powered on and no magic smoke. So far so good.

I don't have a 9" CRT for this board so have connected up my RBG2HDMI adapter set to the PET 9" Profile.

Powered on am getting something on the display but not what I expected. No beep, no text, just alternative squares.

First off the line in the middle of the screen, I think that might be some incorrect setting on my RGB2HDMI PET Profile. Though I've tried adjusting various settings and this seems to be the best display I get. So maybe a problem with the PET or maybe the RBG2HDMI

The squares however - this is not good.

Found this post where someone was having the same issues:

P

Post in thread 'PET cemetery - 4016 repair'

Dec 14, 2024

Top left = Character ROM & RAM (flickering image)
Top Right = No Character ROM, just RAM (image stable)
Bottom Left = No Ram just Character ROM, ESD7 LOW (image stable)
Bottom Right = No Ram just Character ROM, ESD7 HIGH (image stable)

• plagued

Bottom Right = No Ram just Character ROM, ESD7 HIGH (image stable)

Well in my case I have the RAM inserted, and all RAM chips have been tested ok. I've checked the address/data lines on the RAM chips with a scope and can see data on the lines and it looks ok.

I've also tried the PETTESTER ROM and see the same issue.

One thing is I don't have any PIA's inserted. Looking at the schematic if I'm not wrong these should only be needed for the keyboard and IEEE. With them not inserted it should not cause these video issues correct?

I've replaced 2 logic chips that were running hot and cleaned up some corrosion under one of the socket chips. Luckily no track damage.

Any tips of where to start troubleshooting next?

I've got plenty of hardware tools to assist in the repair. DMM, Scope, logic analyzer.

 

[johnq]

Well it would help to plug in the 2114 video ram chips!

It's looking a lot better but still some issues with the video. (running pettester)

The settings on the RGB2HDMI can't be right. Resolution is wrong and the screen keeps flashing on and off every second so makes capturing it a pain. Will need to dig into this.

I am setting error on the RAM - tried multiple different 2114 chips, all give the same output. Then on the last photo looks like a crash?

I might swap out the 2114 sockets as I''ve had issues with these types of sockets before. I don't trust them.

 

[daver2]

If you have removed the video RAM (and they are in IC sockets) you can pull the data output lines of the video RAM low (using 100 Ohm resistors). This should produce a screen full of '@" characters.

Dave

 

[johnq]

Replaced the sockets but didn't make any difference.

I've tried 100R resistor to all the data lines on the RAM chips and do indeed see @

 

[daver2]

Right, so now move each resistor in turn from 0V to +5V, note the character that is displayed, and move the resistor back again to 0V.

If you start with video data bit 7, this should give you an inverse '@' (although I see your screen is already displaying an inverse '@'. I wonder if this is another error on your adapter?).

You should get a unique PETSCII character at each step.

There are a number of recent threads where I have published the binary code and the corresponding PETSCII character if you go and look for them.

Your starter for ten:

00000000 = @.
00000001 = a.
00000010 = b.
00000100 = d.
00001000 = h.

The character may be upper case or lower case (depending upon which character generator is fitted).

You also need to check that the correct number of rows and columns are being displayed for your PET. You probably need to fix your adapter for this.

There is another test we can perform (also documented in other threads) where we connect the video RAM address pins to the video RAM data pins (using our resistors again). This should give us the full PETSCII character set (in order) on the screen.

Happy to talk you through these steps in more detail if you can't locate the threads.

Dave

 

[johnq]

Thanks, I found the threads describing the procedure.

First I sent through each bit pulling it low and get the correct pattern as seen in other thread:

00000000 = @
00000001 = a
00000010 = b
00000100 = d
00001000 = h
00010000 = p
00100000 = blank
01000000 = underscore
10000000 = inv @

One thing to note is I don't need to pull it to 5V. Just removing the resistor from 0V causes a change in the display. Not sure of this is a issue or not.

I then went through your post connecting SA0 to D0 with a resistor:

SA0 to ESD0
...
SA3 to ESD3

SA4 to ESD4.
...
SA7 to ESD7

and get the full PETSCII characters. They all look good.

 

[daver2]

A TTL input will generally float high if it is disconnected. However, in this mode, it can (and does) act like a small antenna (and, therefore, be susceptible to noise). Pulling the pin up to +5V (via a resistor) guarantees a noise-free logic HIGH input rather than guess that this is a HIGH... This behaviour is expected.

The display is NOT correct. Please check your display with my PETTESTER documentation - you should note that the character sequences are not correct (especially the inverted video bit). We are not just looking for well-formed characters. We are looking for the correct characters in the correct locations.

There is a black line in the middle of the screen, and I can't see an '@' character (binary code 00000000). The top-left of the screen should have an '@' symbol (if things are correct).

The last screen (post #6) appears to be 40 characters wide, but the screen full of '@' symbols (post #4) only appears to be 32 characters wide.

I think you really need to get the display adaptor sorted out next...

Dave

 

[daver2]

I am assuming this schematic matches your board:

https://www.zimmers.net/anonftp/pub/cbm/schematics/computers/pet/2001N/320349-8.gif

The video RAMs should be F8 and F7.

Just to confirm, the resistors should be connected as follows:

Video RAM F8:

pins 5 -14
pins 6 - 13
pins 7 - 12
pins 4 - 11

Video RAM F7:

pins 3 - 14
pins 2 - 13
pins 1 - 12
pins 17 - 11

Dave

 

[johnq]

Yes, that's the schematic that matches my board.
Confirmed - the resistors are connected as you described.

I see what you mean about the display not matching against the PETTESTER document. Something weird is going on here.


I'll start looking at the profile settings on the display adapter. I really need to get it fixed as it's adding to the confusion.

 

[daver2]

Exactly. We need to see what is a fault on the PET and what is a fault with the adapter.

I think other people have got a PET to HDMI adaptor working, and posted their parameters.

For the single character mode ('@', 'a', 'b', 'd', ...) there should be a full screen of the same character, and they should all be stable.

This demonstrates that the data latch F9 is OK and everything else further downstream (so character generator ROM F10, parallel to serial shift register E11, and the bit of logic from E11 to the VIDEO signal on J7 pin 1).

I am just setting one data bit HIGH at any one time, but you can set multiple data bits high - and the character obtained on the display should still be correct.

One bit at a time is the absolute minimum to detect a 'stuck bit'.

Using the address pins to drive the data pins more fully checks the ability of the video sub-system to respond to dynamically changing signals. However, it also tests the SA0-SA9 signals from https://www.zimmers.net/anonftp/pub/cbm/schematics/computers/pet/2001N/320349-7.gif - in particular the multiplexers F3, F5 and F6 and the state machine comprising G3, F2 and F4.

Do you have an oscilloscope? If so, what have you got?

Dave

 

[johnq]

I've spent the last few hours trying various RGB2HDMI profile (From Chuck and Adrian's Digital Basement) . Found one specifically for the 2001N 9" which I've set but unfortunately it's still doesn't look right. As I don't have a working PET I cannot confirm if it's a video adapter issue. Tried various geometry settings in the adapter and it doesn't get any better. So maybe it's PET issue? Still not sure about this.

I've re-run all the tests and in all cases I can see 40x27 characters with the extra blank line, so 40x26 if you ignore the blank line. Strange!

First photo - resistor connected across the data/address lines. Same output as previous. First char is not a @
Second photo - data lines all shorted to GND via a resistor.
Third photo - data bit 4 pulled high.

I've gone through each data bit again (pulling high/low) and confirmed the correct output.

I've got a Hankek DSO5102 scope, as well as a USB logic analyser.

 

[daver2]

Ok, so parts are looking good and parts not.

I suspect the fault to be on https://www.zimmers.net/anonftp/pub/cbm/schematics/computers/pet/2001N/320349-7.gif. But this is a guess at this stage.

The next thing would be to check the following signals:

H7 pin 2 - HDRIVE.
G10 pin 11 - VDRIVE.
H10 pin 11 - VIDEO ON.

My suggestion is to use a 2 channel oscilloscope to monitor:

1. HDRIVE (oscilloscope trigger) and VIDEO ON.
2. VDRIVE (oscilloscope trigger) and VIDEO ON.

The VIDEO ON signal MAY BE an amalgamation of two components (but just checking the schematics this may not be so). Seeing (for example) VDRIVE and VIDEO ON on the same oscilloscope photograph, and triggering the oscilloscope on VDRIVE should stabilise the signals and be able to compare where VIDEO ON occurs relative in time to VDRIVE.

We are also looking for the frequency of HDRIVE and VDRIVE and to ensure these signals are all heathy TTL voltages.

Dave

 

[johnq]

Channel 1 - VIDEO ON
Channel 2 - VDRIVE (Trigger)




Channel 1 - VIDEO ON
Channel 2 - HDRIVE (Trigger)

 

[daver2]

Your VDRIVE signal (if I am reading your oscilloscope trace correctly) is running too fast (134 Hz verses what it should be 50 Hz or 60 Hz).

We need to work this one back...

HDRIVE seems to be OK though.

Dave

 

[johnq]

I've rechecked the connections to VDRIVE and they are 134Hz. Sounds like we are onto something.

Will ponder through the schematic though a quick look I can't see how this signal should be generated.

I poked around on the input to the NAND gate G10
G10 Pin 13



G10 Pin 12


Both 135Hz.

CK (H8 Pin 9)


INIT (H8 Pin 10) always high.

Need to do some reading up on how this 50/60Hz signal is supposed to be generated.

 

[daver2]

/INIT is supposed to be HIGH. That is good!

Check H8 pin 12 first (NEXT).

There are posts describing this circuit and an online simulation of the entire logic (I posted a link to this in a thread somewhere).

Dave

 

[johnq]

H8 pin 12 and 9:



Working backwards this is generated via the 7474 G8:

Pin9:

Pin10:


Pin11:


Pin12:


Pin13:

 

[daver2]

G8 pin 9 is a high pulse.

G8 pin 8 should be a low pulse at the same frequency as pin 9.

G8 pins 11 and 12 show pulses on the oscilloscope trace, but do not indicate the frequency. Can you investigate further please.

After that, we are looking at the logic driving G8 pin 12.

Dave

 

[daver2]

Here is the link to the simulation of the logic generating VDRIVE (post #58 from Hugo).

Post in thread 'Pet 2001N horizontal line'

Jan 6, 2023

Not H11 - that is a straightforward TTL device.

The PET video state machine.

There have been numerous repairs of this on VCFED - so one of those threads will have a description of the way this thing works.

Let's use that rather than re-invent the wheel.

Dave

• daver2

• 

This is obviously for a 60 Hz VDRIVE machine...

Dave

 

[johnq]

Thanks for the link. Will look through and start comparing the timings.

G8 pin 8 (Q) is the same frequency as pin 9 (/Q) but inverted so all good there.

G8 pin 11 is 1Mhz:


Pin 12 is 540Hz:


Pin 12 is derived from the AND Gate G1:

Input Pin1:


Input Pin2: