• Please review our updated Terms and Rules here

PET 2001N IEEE-488 interface issue

ScottishColin said:
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.,
Click to expand...
It's at 5.1V. I did wonder if I had pulled it too low as I have my RGBtoHDMI (Raspberry PI) powered from the PET 5V rail.
It was quite nice using the CRT for a change!🙂 I tend to leave it off to save it a little, especially when faulting and power-cycling it all the time.
 
daver2 said:
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.
Click to expand...
To ensure I have it right. The program is as follows:
1741720486847.png

The traces look good:
1741720510840.png

I connected it to the analyser and the timing looks pretty good:
1741720576658.png
Note: Only /ATN-out and /ATN-in connected.


daver2 said:
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...
Click to expand...
Thanks. I remember that from the book as the graphic. PETs with 'hands' over their 'ears' made me smile.
 
Something still looks wrong with your program, but I am going out now - so I don't have time to look at it at the moment.

My wife is 'ushering' me!

Dave
 
Better than the Project Manager 'ushering' you. Have a good time!

Yes, you are right. There is (the damn dummy) PEEK missing.

Original section from the book:
Code: 
620 REM TEST ATN
630 POKE 59456,251:C=PEEK(59425)
631 C1=PEEK(59424)
640 POKE 59456,255:C1=PEEK(59425)
650 MSK=128
660 A=C AND MSK
670 IF A=0 THEN GOTO 700
680 A=C1 AND MSK
685 IF A=0 THEN GOTO 705
700 PRINT "ATN IS BAD"

My revised code, with the dummy PEEK and tidied PRINT:
1741723963322.png

The scope is a different shape but still /ATN-out and /ATN-in are in step:
1741724023451.png
Analyser looks consistent:
1741724177723.png
Note: Only /ATN-out and /ATN-in connected.
 
For anyone interested...
razza said:
I got bored with typing PEEK and POKE statements which also allows room for error. I wrote this for consistency (and error checking on my part)...
Code: 
10 PRINT "CLS" : REM CLS TO BE REPLACED WITH <SHIFT-CLR/HOME>
20 PRINT "IEEE-488 PEEK POKE TEST": PRINT ""
30 PRINT "DI01-8 TEST"
40 A=PEEK(59424):A$=STR$(A)
50 POKE 59426,0
60 B=PEEK(59424):B$=STR$(B)
70 POKE 59426,255
80 C=PEEK(59424):C$=STR$(C)
90 PRINT "INIT=" + A$ + ", P LOW= " + B$ + ", P HIGH=" + C$ : PRINT ""
100 PRINT "EIO TEST"
110 A=PEEK(59408):A$=STR$(A)
120 POKE 59409,52
130 B=PEEK(59408):B$=STR$(B)
140 POKE 59409,60
150 C=PEEK(59408):C$=STR$(C)
160 PRINT "INIT=" + A$ + ", P LOW= " + B$ + ", P HIGH=" + C$ : PRINT ""
200 PRINT "DAV TEST"
210 A=PEEK(59456):A$=STR$(A)
220 POKE 59427,52
230 B=PEEK(59456): B$=STR$(B)
240 POKE 59427,60
250 C=PEEK (59456):C$=STR$(C)
260 PRINT "INIT=" + A$ + ", P LOW= " + B$ + ", P HIGH=" + C$ : PRINT ""
300 PRINT "NFRD TEST"
310 A PEEK(59456):A$=STR$(A)
320 POKE 59456,253
330 B=PEEK(59456):B$=STR$(B)
340 POKE 59456,255
350 C=PEEK(59456):C$=STR(C)
360 PRINT "INIT=" + A$ + ", P LOW= " + B$ + ", P HIGH=" + C$ : PRINT ""
400 PRINT "NDAC TEST"
410 A=PEEK(59456):A$=STR$(A)
420 POKE 59425,52
430 B=PEEK(59456):B$=STR$(B)
440 POKE 59425,60
450 C=PEEK(59456):C$=STR$(C)
460 PRINT "INIT=" + A$ + ", P LOW= " + B$ + ", P HIGH=" + C$ : PRINT ""
500 PRINT "ATN TEST"
510 A=PEEK(59425):A$=STR$(A)
520 POKE 59456,251
530 B=PEEK(59425):B$=STR$(B)
540 POKE 59456,255
550 C=PEEK(59425):C$=STR$(C)
560 PRINT "INIT=" + A$ + ", P LOW= " + B$ + ", P HIGH=" + C$ : PRINT ""
Click to expand...

I suspect if you replace lines 500-560 above with the following, it will work:
Code: 
500 PRINT "ATN TEST"
510 POKE 59456,251
520 A=PEEK(59425):A$=STR$(A)
530 B=PEEK(59424):REM DAMN DUMMY PEEK
540 POKE 59456,255
550 C=PEEK(59425):C$=STR$(C)
560 PRINT "P LOW= " + A$ + ", P HIGH=" + C$ : PRINT ""

But as the prehistoric cassette has lost most of my program, I can't test it without retyping 80% of it.
 
razza said:
%<---- SNIP----
I am wondering if the joystick/cb2 adaptor I inserted has caused a problem. I was careful to hold the board by the sides. My gut feel is the 6522 based on this.
---- SNIP---->%
Click to expand...
I guess I should have gone with my gut. The 6522 was indeed at fault.

Thanks for your help on this.
 
>>> and successfully found a fault with it

An emphatic YES, that is why I recommend it...

Of course, it depends upon the prevailing fault.

Dave
 
Don't forget that there are a couple of signal lines that it doesn't test.

Also, it doesn't test the interrupts either.

Dave
 
Very true. I was going to map the Vic keyboard matrix to the pins used by IEEEE488 last night. I couldn't find a keyboard matrix in Zimmers, so I went to the pub to celebrate my working PET instead 😂
 
You must log in or register to reply here.
Back
Top