PET 2001N IEEE-488 interface issue

[razza]

Notice that you have missed a POKE command out from your test program as opposed to the one in the book.

Driving ATN is directly from the POKE.

The ATN input is not a direct PEEK. It is a bit more convoluted.

This is probably why the book program is working, but your test program is not.

Dav

You mean this section from the book?

I see that C and C1 are taken from different locations initially. I can't see the point of line 631 though. C1 is overwritten by line 640 (59425) before the variable stored in line 631 (59424) is used. So, C is the low value from 59425 and C1 is the high value also from 59425. Which is what my tester program does.

If I have misunderstood your post please shout.

 

[Hugo Holden]

It is interesting that the "heart" printed out, rather than clearing the screen...

Dave

I couldn't figure out how to type the reversed Heart character into the code at the time because I had not used the RVS button. But I also couldn't see a clear screen routine in the code either, so I wondered what that REM clear screen remark was all about, can you explain it ? When I put the reverse Heart in it works and clears the screen as it should. Obviously that reversed heart value 211 is a clear screen control code. It is awkward to type in the Heart in reversed form after the " , but it works better with the whole print statement typed in in reverse video, then it comes out looking correct on a program listing. Now it clears the screen.

 

[daver2]

Yes, printing the reverse heart is the clear screen code ! It is just one of those things in PET land.

Dave

 

[daver2]

>>> If I have misunderstood your post please shout.

Yes, your understanding of the code is correct - but not about the reason the code is like it is.

The ATN input is NOT a simple digital input bit on the PET. The ATN IN signal goes to CA1 of the PIA and not to a conventional PAn or PBn.

There is a function within the PIA that can detect edges of a signal (within hardware) so the CPU is not involved in this action.

However, there needs to be a read of a specific port to 'reset' or 'prime' the logic within the PIA. The 'dummy' PEEK accomplishes this action.

It is NOT the data that is returned by the PEEK that is of any value (hence the variable the author has used is overwritten fairly quickly afterwards) but the PEEK action reading from the specific port within the PIA.

This is explained in an earlier chapter of the book. It is also explained in the PIA datasheet.

Because the 'book' test program appears to work, I suspect your problem is either 'dirty' gold connectors or externally to the PET.

Dave

 

[razza]

Really useful thanks. I'm at work now, so I'll try and look later.
I have read this in conjunction - http://blog.tynemouthsoftware.co.uk/2023/10/pet-ieee-488-diagnostics-updated-version.html?m=1

 

[daver2]

The CA1 input cannot be directly read via the PIA registers. It is not a conventional input.

The CA1 input (when initialised) sets the internal IRQA1 flag (bit 7 of Control Register A) so it can be read by the CPU. The 'edge' of CA1 (causing the setting of IRQA1) can be configured by a bit in CRA (bit 1). As a result, either a high-going or low-going edge on ATN (CA1) can trigger the setting of IRQA1.

Once IRQA1 is set, it will never clear unless the CPU takes some action (i.e. once one transition has occurred on CA1, no further transitions will be responded to).

To clear IRQA1 requires a CPU read of Peripheral Output Register A, (hence the dummy PEEK).

Sample text from the 6520 PIA datasheet (https://web.archive.org/web/2022110...ve.6502.org/datasheets/rockwell_r6520_pia.pdf):










Dave

 

[daver2]

The Motorola MC6820 PIA is an equivalent of the 6520 - but the datasheet is much more descriptive...

See https://deramp.com/downloads/mfe_archive/050-Component Specifications/Motorola/Motorola - MC6820 - Peripheral Interface Adapter (PIA).pdf.

The relevant section (for CA1 input) is:



Notice that the IRQA1 (bit 7) is only ever SET on the specified transition of the CA1 input. This bit is only cleared by the CPU dummy read (PEEK).

Dave

 

[Hugo Holden]

It seems like the moral of the story is, if you find a line of code in a program that you don't think is needed, think twice, unless you know the hardware like the back of your hand (like Dave does)

 

[razza]

That's why we are pleased to have Dave here

 

[razza]

Because the 'book' test program appears to work, I suspect your problem is either 'dirty' gold connectors or externally to the PET.

I am starting to think you are correct. The fault is odd. I am mostly able to get a response from CATALOG but I have only managed a successful load once (tonight) since I have had this issue.
I've tried a new SD card with similar symptoms.
I've cleaned the connectors on the pet and in the SD2PET.
I am going to see if TFW8b will do a replacement/check, my only other option is someone around South London with a PET that wouldn't mind me dropping by?

I know photos are not that helpful but....
Top


Bottom

 

[daver2]

One of those gold fingers on the top side doesn't look fully gold, but a mixture of gold and copper.

What are the tracks like leading to the edge connector fingers on the top?

Even though there may appear to be a lot of gold on a finger, the contact area of a connector can still be extremely small.

When I developed some cards at work, I remember inserting and removing the prototype cards into/from the backplane to check the alignment of the connector / gold finger contact points by looking at the scratches in the hard gold plating.

Dave

 

[razza]

I think it's the light in the original photo. The chassis ground is the worst but I would have thought that was not used in the SD2PET?

 

[daver2]

Yes, it looks better like that...

Dave

 

[razza]

Another play this morning. I said previously things sometimes works before it "warms up" and I have witnessed that again. I powered it up from cold and loaded Invaders fine, rebooted and loaded the BacktoPET demo and left that running for 10mins. It's now broken again. I loaded the IEEE488 diagnostic program and it's reporting good (or rather saying nothing!).

TFW8b have advised use old/slower SD cards (one of the three is) and they all behave the same. The only other option is to send it for testing. I feel the only option I have is to prove it on or off the PET by post the SD2PET back for testing at my cost.

The other option is to buy this diagnostic board which I can get for ~£30.
@daver2 - Do you think there is value in the board?

 

[Hugo Holden]

The main thing, in all fault finding exercises, is to understand how a circuit (in this case a GPIB interface) is supposed to work.

Even without any form of diagnostic kit, or test program, you can check all of the signals with a scope.

I once spent a lot of time trying to fault find RS-232 interfaces. There were all sorts of kits out there with LED's to indicate signals present, good or bad etc. They were a waste of time. I cannot say that about the diagnostic board you are wondering about, it might be wonderful.

But like the notion in a car that has a lamp that tells you if your oil pressure is ok, if the battery charging is good, or if the engine is overheated, you had best regard these lamps or LED's as "Idiot Lights".

They cannot tell you if there are issues in the logic levels on either side of where the light deploys. It is always better to examine every signal with a scope, and decide if it is ok, or not, for yourself. But that requires a knowledge of exactly what the signals look like, what they should be doing and when and good scope setup skills.

 

[razza]

I agree, but as Dave is convinced it is external to the PET or connector. As you say "he knows the hardware like the back of his hand". So, I'm inclined to agree with him.

I think I'll send it back, which then proves the PET or the SD2PET. If I need to fault the PET, I can do that with an analyser/scope.
.

 

[daver2]

If you are going to repair a lot of PETs, or you want to ensure that you have the tools necessary to repair your own PET into the future, then purchasing a tool like this may be useful. If you are trying to fault-find for a one-off event, then seeing lots of blinking and flashing lights (in my opinion) does not help.

As you imply that this fault could be temperature related, I would be inclined to run the Primrose book test for a long while (without anything connected to the PETs IEEE488 port) to see if anything is reported. This will involve removing the message from line 810 (REMing it out) and removing the delay from line 810 (REMing it out). You may want to consider outputting a "TEST RUNNING" message every 100 (or so) iterations of the loop. The idea is to get the maximum amount of running (and thrashing of the IEEE488 interface) with no error messages produced.

One thing I just thought of is "which version of BASIC are your running"? I suspect I know the answer to this question already, but (to just confirm) can you post a photograph of the PET start-up screen and what part numbers are on the ROMs.

The /ATN signal operation was incorrect in 'old ROM' versions of the PET. This issue was fixed with 'new ROM' versions.

Post #20 shows a strange behaviour with the /ATN signal. This is unexpected. I would run a basic test (constantly driving /ATN out and monitoring /ATN in for errors). However, rather than using your logic analyser, use an oscilloscope on the /ATN bus pin. There should not be a 'delay' between /ATN out, the /ATN bus signal and /ATN in... You may have found the issue - but didn't follow up on it. The logic analyser 'cleans up' any rubbishy signals and presents them in digital form. It may be lying to you! An oscilloscope will indicate for real what the /ATN out and /ATN bus signals look like. Because /ATN bus is 'delayed', /ATN in and 6520-CA1 will follow suite - so the problem is from /ATN out to /ATN bus.

The /ATN signal is generated by the controller to get the attention of the other devices on the bus. For example, if the PET wants to communicate with the SD2PET, it will activate (set LOW) the /ATN signal and initiate some data transfer to the SD2PET, then raise the /ATN signal high again (note this will happen part wat through the data transfer cycle). If the /ATN signal does not make it out of the PET and onto the IEEE488 bus properly, the SD2PET will never see the PET transaction. It will appear deaf...

The other thing to check (with the power OFF using a continuity test with your multimeter) would be for good connections from your SD2PET to the PET via the connector for all of the IEEE488 signals individually. Perhaps 'flex' the SD2PET ever so slightly (whilst taking the continuity measurement for each pin in turn) to ensure that the associated connection is not an intermittent fault.

The above tests should not take too long, can be done with the test equipment you already have, and don't cost any money...

Dave

 

[razza]

I might not have enough time to respond to all points now, so please bear with me Dave ...

If you are going to repair a lot of PETs, or you want to ensure that you have the tools necessary to repair your own PET into the future, then purchasing a tool like this may be useful. If you are trying to fault-find for a one-off event, then seeing lots of blinking and flashing lights (in my opinion) does not help.

I felt it would make faulting easier, initial LED visuals, I can get to all the IO more easily, especially as it is in circuit.

One thing I just thought of is "which version of BASIC are your running"? I suspect I know the answer to this question already, but (to just confirm) can you post a photograph of the PET start-up screen and what part numbers are on the ROMs.....
The /ATN signal operation was incorrect in 'old ROM' versions of the PET. This issue was fixed with 'new ROM' versions.

It's V4 so should be OK...

As you imply that this fault could be temperature related, I would be inclined to run the Primrose book test for a long while (without anything connected to the PETs IEEE488 port) to see if anything is reported. This will involve removing the message from line 810 (REMing it out) and removing the delay from line 810 (REMing it out). You may want to consider outputting a "TEST RUNNING" message every 100 (or so) iterations of the loop. The idea is to get the maximum amount of running (and thrashing of the IEEE488 interface) with no error messages produced.

It's been doing that since first thing this morning. I REMed the clear screen line and the FOR...NEXT delay but left the "END OF TEST" line in so when I came down for coffee during the day I could see it had not hung.
Note: It has only ever hung when communicating (or not) with the SD2PET.

The other thing to check (with the power OFF using a continuity test with your multimeter) would be for good connections from your SD2PET to the PET via the connector for all of the IEEE488 signals individually. Perhaps 'flex' the SD2PET ever so slightly (whilst taking the continuity measurement for each pin in turn) to ensure that the associated connection is not an intermittent fault.

It's hard to get the probe end into the SD2PET to do a decent test. It was made clear to me in my email exchange with TFWb that it must not be opened.
The SD2PET connector looks good and I have flexed and tried it at different insertion distances and angles. Maybe I should dig out an old edge connector and meter those out.

I'll have to come back to these, a "fun filled" conference call awaits!

Post #20 shows a strange behaviour with the /ATN signal. This is unexpected. I would run a basic test (constantly driving /ATN out and monitoring /ATN in for errors). However, rather than using your logic analyser, use an oscilloscope on the /ATN bus pin. There should not be a 'delay' between /ATN out, the /ATN bus signal and /ATN in... You may have found the issue - but didn't follow up on it. The logic analyser 'cleans up' any rubbishy signals and presents them in digital form. It may be lying to you! An oscilloscope will indicate for real what the /ATN out and /ATN bus signals look like. Because /ATN bus is 'delayed', /ATN in and 6520-CA1 will follow suite - so the problem is from /ATN out to /ATN bus.

The /ATN signal is generated by the controller to get the attention of the other devices on the bus. For example, if the PET wants to communicate with the SD2PET, it will activate (set LOW) the /ATN signal and initiate some data transfer to the SD2PET, then raise the /ATN signal high again (note this will happen part wat through the data transfer cycle). If the /ATN signal does not make it out of the PET and onto the IEEE488 bus properly, the SD2PET will never see the PET transaction. It will appear deaf...

 

[daver2]

>>> I'll have to come back to these, a "fun filled" conference call awaits!

I get those as well. Fortunately today's conference call was with my Project Manager colleague - so that is actually enjoyable.

Dave

 

[ScottishColin]

Unlikely I know but as it picks up 5V from the cassette port, have you checked the voltage, if only for the sake of ruling it out?

Colin.,