• Please review our updated Terms and Rules here

Repairing my 2001-N

Firstly, PETTESTER just calculates the checksum. It does not 'know' what the correct checksum is. That is the job of the human (i.e. you).

You only require C7 to be present for the keyboard to work.

Warning! The 74LS145 is an open collector device. So, if you are looking for a logic HIGH you will be disappointed! You can check each output from the 74LS145 on the oscilloscope by adding a 10k pullup resistor to +5V as well as the oscilloscope probe... Many a '145 has been sacrificed in error because the open collector nature has not been taken into account.

You should observe activity on pin 20 of each EPROM.

Dave
 
Last edited:
The 'C' ROM is definitely wrong! You did install 901465-20 into the UD6 socket?

There are two (2) versions of the 'B' ROM. An original 901465-19 and a patched 901465-23. I wonder which one was in my machine when I calculated the checksum for my documentation?

Dave
 
I tried the 10k pullup from each output. No go.

I then checked the output from the 6520. Pins 2,3,4,5 (KEYA-D) are all HIGH. So this needs further investigation.

I installed 901465-20 into the UD6.
Will try reburn another ROM and also try -23 and see if I can get a match.
 
Good news.

Burnt another -20 ROM and now getting the correct checksum.

Then burnt a -23 in place of the -19 and it's getting the matching checksum for B

So getting

b=4168 c=5960 d=a425 f=cf19
 
I couldn't hold myself back. With the excitement of the ROM's being correct I replaced the PETTESTER with a 901474-02 and booted up.

It's alive!!!

20250129_220438.jpg


With that over it's back to the PETTESTER to work out why the 6520 is not working.
 
Last edited:
>>> Then burnt a -23 in place of the -19 and it's getting the matching checksum for B

So that's worth knowing... I will add that to the PETTESTER V05 manual.

Check that you are observing pulses on UC7 pins:

23 (low going).
22 (high going).
24 (high going).

35 and 36 (just pulsing).

21 (just pulsing).

25 (1 MHz clock).

34 (/RESET). Should be HIGH. However, can you check that it does pulse LOW when the PET is reset.

I would also be inclined to just check the power supply pins of UC7 as well (0V = pin 1 and +5V = pin 20) by putting a multimeter directly across the pins to make sure it is being supplied with Volts...

Yes, pins 2, 3, 4 and 5 of UC7 should be changing state when PETTESTER is at the ROM checksum and keyboard test screen.

The above tests make sure that the key power and control signals are present and that the chip selection logic is driving the device correctly.

The /I/O signal (sheet 1) derived from UD2 pin 16 (/SELE) via link 'S' is very important for the I/O sub-system. As is the output from B2 pin 6 (X8XX). They both work in tandem to decode addresses in the range E8XX - where all of the I/O devices live...

Dave
 
Last edited:
Getting there slowly but surely.

I've checked all the waveforms and they look correct, though not sure about pin 23.

Have also checked the power with a DMM and get a stable 5.0V

Pin 21:
C7_21.png

Pin 22:
C7_22.png

Pin 23:
C7_23.png

Pin 24:
C7_24.png

Pin 25:
C7_25.png

Pin 35:
C7_35.png

Pin 36:
C7_36.png

Reset is also good. It's HIGH and goes low when reset.
 
Well, there is no reason why it should not work...

Pin 23 is just strange because it is largely generated by the software (PETTESTER) accessing the device - so not 'locked' onto anything. Under these circumstances I find it better to use single shot so as to see what is going on - and then use continuous to look for 'strange' non-TTL signals.

Where are you measuring these signals? Directly on the pins of the PIA?

Dave
 
Yes, measuring directly off the PIA.

I've tried 3 different PIA's so can't believe the are all faulty. Also have a SY6520 I tried. Same result.

Unless the 74LS145 is faulty and pulling all 4 pins high but I can't imagine this to be the case.

Checked pin23 again. Looks better with single shot.

pic_148_2.png
 
I popped the 901474-02 ROM back in just to double check and keyboard is not working there either.
One thing I noticed is there is no cursor flashing. Not sure if this is relevant. This is without the 6522 and 6520 for the IEEE-48 installed.

And on the PIA:
PA0=L
PA1=H
PA2=L
PA3=H

Whereas with the PETTESTER PA0-PA3 is H
 
There is a 'cause and effect' here.

With the 'real' PET ROMs in, an interrupt is generated from the keyboard PIA in response to the VIDEO ON signal.

The interrupt causes the keyboard to be scanned and the cursor to be flashed.

If the keyboard PIA is not working correctly, no interrupt will be generated, the cursor will not flash (part of the interrupt handler) and the keyboard will not work.

PETTESTER polls things in software - no interrupts to mess us up.

Unfortunately, the interrupt vector is encoded within the kernal ROM.

Dave
 
Good to know. I read somewhere they should work which is why I bought them.

I might have to get hold of a known working 6520. Mine should work and I can't believe they are all faulty but I guess it's not impossible.

On the theory of the PIA working and there is some other fault on the PCB.

The data lines should all be correct as they are shared with the rest of the system and I think we would have seen some other issues if they were incorrect.
Similarly can we assume R/W is fine as that's used with the RAM.

Phi2 is good, Reset is good.

This only leaves the other input lines of which there are not many. Maybe there are some timing issues with the select lines. Might be time for my logic analyser on CS1, CS2, CS3
 
Hooked up the logic analyser and can see the PIA is being addressed.

Looking at CS0, CS1, /CS2 I can see there is one small pulse (in red below) where CS0 is HIGH, CS1 HIGH, and /CS2 LOW
Screenshot from 2025-01-30 15-38-05.png


Zoomed into the pulse:
Screenshot from 2025-01-30 15-37-44.png


Hmm....requires further head scratching.
 
Not sure if I'm seeing that.

The long gap is during a reset.

Screenshot from 2025-01-30 18-07-27.png

The first few pulses don't select the PIA as /CS2 is always high when CS0 is high.
Screenshot from 2025-01-30 18-08-40.png

The 3rd pulse here however has the correct logic:
Screenshot from 2025-01-30 18-10-28.png

Screenshot from 2025-01-30 18-11-35.png
 
Taking another stab at this. I've bought another PIA from a trusted seller (tested and working) and seeing the same results.

If it's not the PIA any other ideas as to what else to look at?
 
All I can think of at the moment is a faulty data line or control line between the CPU and PIA causing it to be incorrectly programmed.

Can you remind me how many channels you have on your logic analyser?

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