• Please review our updated Terms and Rules here

Repairing my 2001-N

It's a 8 channel.

I was also thinking about the suspect data line however the data line is connected directly to 6502. I'm seeing activity on all the data pins and have beeped out the lines on a DMM so it rules out a break in the tracks.
 
It would still be nice to see how the PIA is being initialised by PETTESTER, and compare it to what the firmware should be doing - even if we have to do it a data bit at a time...

Dave
 
Should the PIA be initialised right after a RESET or when the PETTESTER starts the keyboard testing routing?

I've hooked up the control pins (With the PETTESTER)
Done a reset and captured a few seconds of data.

The PIA is selected here: CS0 HIGH, CS1 HIGH, /CS2 LOW

1739034721555.png

Zoomed in:

1739034627879.png

I'll capture the data bits, but what should these be sync to?

Leave in the control lines, RS1, RS2 and then 3 bits at a time?
 
The PIA is initialised when my PETTESTER gets to the keyboard/ROM checksum test and then should cycle around the key matrix.

Dave
 
Can your logic analyser perform logical functions on the individual channels?

If you look at the data sheet for the PIA, and look how it is hooked up to the PET, you should be able to decipher the write cycles to the various registers.

Compare these to the source code listing for PETTESTER.

Dave
 
Will do some further digging.

Using a sigrok so it can perform some logical functions in the software. Just seen that someone has written a 6502 decoder but it needs 12 channels. Might be time for a upgrade to a 16 channel one :)
 
E810 (write) writes data to the data port (A).

E811 (write) writes the control register and data direction register (A).

If you decode these two addresses (using the control pins of the PIA) you should be able to see what is being written.

Dave
 
I read through the datasheet a few times and I'm still at a loss. How do I decode the addresses to E810 and E811 using the control pins.

I understand how the chip select lines work and have a basic understanding now of the control registers.

I have been looking at the chip select lines during the keyboard cycle and can see the PIA being addresses multiple times.
 
I think I worked it out.
E810 = b1110100000010000

With the address bits set like this /X8XX is H, /IO is L,
CS0=H, CS1=H, /CS2=L
RS0 = L, RS1 = L

I can see this on the logic analyzer

e810-811.png

Hmm. So PIA is being addressed.

Time to sleep on it.
 
Ok so I have some very interesting results. Went to a friend who has a dynamic PET and spent a few hours taking loads of logic analyzer samples from the PIA with PETTESTER
First tested all my PIA's and they all work 100%

Next probed all the data pins individually for address E810 and E811.
On initialization I can see b00001111 written to E810, then b00000100 to E811

Looking at the source code this corresponds to:

lda #$0F ; DDRA pins. 0=IN, 1=OUT. IIIIOOOO.
sta pia1 + 0 ; Initialise DDRA.
lda #$04 ; Change to data register - but no CA1/CA2 interrupts!
sta pia1 + 1 ; Output to CRA.

After the write to E810 with 0xF the PA0 pin drops low.

So all good there - as expected.

Back to the faulty PET. The control pins (RS0, RS1, CS0, CS1, /CS2) all match the working PET, however the data pins D0-D7 is different.

I'm seeing b00000000 written to E810, then b00010000 written to E811.

This explains why the PIA is not working. Why the data is wrong is a mystery.

Comparing D0 with working/faulty - all the pattens match except D0

Working:
1739099610910.png

Faulty:
1739099642350.png
 
Well diagnosed.

Writing $00 to $E810 will cause all of port A to be an input. I agree, this is why it looks like the PIAs are not working...

Did you mean that the write to $E811 was $10 (instead of $04)?

Were you using the same PETTESTER ROM in the second PET (where things were working) or a different ROM?

Let me think about this one. The first thing to rule out is an incorrectly programmed PETTESTER EPROM.

Dave
 
I was using the same PETTESTER EPROM.


Yes, on the faulty device $00 written to $E810, and $10 to $E811

Very odd.
I also swapped around 6502 CPU's just in case there was something odd going on with it - but it didn't make any difference.
So same PIA, PETTESTER, CPU working on dynamic PCB but not my faulty 2001N PCB.
 
All I can think of (off the top of my head) is that something sitting on the data bus is corrupting those values.

However, I can't see how we can make a logic HIGH (as in the case of $10) from a 'wire-AND' configuration.

If the data bus was getting corrupted too often, PETTESTER would not work, as the instruction stream uses the database.

What I am thinking about is that a write to the PIA causes something else to drive the data bus thinking there was a read from a different location. This is a longshot though.

Dave
 
Also can't think as to why this is occurring. As you said if the data was corrupted then this would effect the running of PETTESTER. Why would it only be writing incorrect data when trying to initialise the PIA. Doesn't make sense

Going to see if I can get 16 channel logic analyzer (With more bandwidth) and repeat the tests. It will be easier to see all the signals on one screen.

The other PIA and VIA are not connected so there is not much else in circuit to mess with the data lines. Will have a look through the schematic to see if I can spot any other potential culprits
 
The ROMs are on the data bus, and the DRAM and video RAM are gated onto the data bus via E8 and E9.

Just refresh my memory, what sort of EPROM are you using for the PETTESTER?

Is the reference machine you were using a 'dynamic' PET or a 'universal' PET?

Dave
 
Using a 27C256 (100nS) with a 23XX adapter.

Reference machine is a universal PET 8032. Made a mistake above and referred to it as a dynamic.
 
Ah ha...

That's what I thought...

The Universal has a subtle difference.

Your 2001N assumes that when /SEL E is LOW (pin 20) that the ROM will be disabled when A11 (pin 18) is HIGH. The ROM is enabled when A11 (pin 18) is LOW ONLY.

The universal only enables the E ROM when /SEL E is LOW and X8XX is LOW (i.e. the ROM is enabled for everything except the I/O 'hole' between $E800 and $E8FF.

How does you adapter actually work?

Is it possible that your PETTESTER EPROM is being enabled within the I/O 'hole' - thus corrupting the CPU writing to anything (r reading from anything) in the address range $E800 to $E8FF?

EDIT1: Looking at the documentation for the 23XX EPROM adapter board leads me to think that the links should be configured as follows:

1739121371917.png

(Assuming I am using the same adapter that you have purchased of course)!

EDIT2: I see from post #1 that you are using the 23XX adapter on all of the ROMs. Beware that the EDIT/PETTESTER ROM is only 2K, whereas all of the other ROMs are 4K. As a result, the EDIT/PETTESTER 23XX adapter will have to be linked differently to all of the others... For the 4K ROMs, A11 is a conventional address line whereas it is effectively an active LOW chip select line for the EDIT/PETTESTER ROM adapter.

Dave
 
Last edited:
Yes, I'm using the 23XX adapter. i think you might be onto something here. I don't think I've got it configured as a 2316. I'll double check things
 
If you have it configured as a 2332 (as per the others) it will corrupt the I/O space on yours but not on a universal (due to the addition of some external logic).

The reason for the modified logic was to extend the EDIT ROM to a 4K 2332 device to support extended character sets etc. However, the I/O space overlaps this ROM - so some logic is required to 'drill a hole' in it...

It might be something as simple as user error 🤔!

Dave
 
Back
Top