• Please review our updated Terms and Rules here

COMMODORE CBM PET 2001-N DESPERATE

Correct (as I said, not a trick question).

What is that hexadecimal value of the character 'k' (when converted from PETSCII)?

What character is being displayed, and what is the equivalent hexadecimal value (when converted from PETSCII)?

Dave
 
I solved the problem anyway: the video RAM in F7 was very hot. I tried replacing it, and the graphical glitch disappeared!
 
That table is ASCII not PETSCII!

I have worked it out here and came to the conclusion that F7 was faulty.

If F7 had not been hot, how would you have worked it out (knowing now that your values for 'k' and '[' are wrong because you used an ASCII lookup table and not the correct PETSCII lookup table for this PET's character generator)?

Dave
 
daver2 said:
That table is ASCII not PETSCII!

I have worked it out here and came to the conclusion that F7 was faulty.

If F7 had not been hot, how would you have worked it out (knowing now that your values for 'k' and '[' are wrong because you used an ASCII lookup table and not the correct PETSCII lookup table for this PET's character generator)?

Dave
Click to expand...
but where i can find a PETSCII tab??
 
After 32 Dram pass, i removed the romulator and i tried to turn on... I have low quantity ram on screen
 

Attachments

  • 17356658853992475516000052177792.jpg
    17356658853992475516000052177792.jpg
    1.3 MB · Views: 7
Desperado, I think you should re-read post #220. You will see that using those methods, it would have fixed your PET in short order.

The thing is with the Pettester it requires an analysis/interpretation of its output and familiarity with PETSCII that has been too difficult for you, and you have been relying on Dave to interpret its every output for you with each deployment of it. This has slowed you right down used up a lot of Dave's time and worn him out.

You need a repair process where you can work through it yourself and interpret the results yourself. You really would be better off with the method I suggested as you only have to examine memory bytes and they are easy to interpret. You should re-read the article I wrote about that and the method to find faulty soldered in DRAM.

You are pretty good with the scope now which helps and you can do most of the things required to fix PET computers, test power supplies, resets, CPU activity, you can use the NOP generator etc and you have also figured out how a number of logic chips work too, so you have made good progress.

Hope you have a good New Year !

(PS: On the topic of PETSCII and ASCII, you might recall in the article I wrote, Wilson-Taylor made a switchable converter in their PET printer interface. I drew it in a diagram to show the conversion, at the logic level, attached. I had not seen PETSCII before I got my PET)
 

Attachments

  • petscii.jpg
    petscii.jpg
    71 KB · Views: 5
Last edited:
daver2 said:
That table is ASCII not PETSCII!

I have worked it out here and came to the conclusion that F7 was faulty.

If F7 had not been hot, how would you have worked it out (knowing now that your values for 'k' and '[' are wrong because you used an ASCII lookup table and not the correct PETSCII lookup table for this PET's character generator)?

Dave
Click to expand...
please, I need you to teach me how you managed to trace back to F7....I would like to learn to understand these PETSCII characters and the conversions because honestly I understand very little :(
 
The website is here: https://www.pagetable.com/c64ref/charset/.

Select PET-B (PET Business) and "US lower PET" from the options:

1735755114984.png

This will give you the screen as follows:

1735755182834.png

There are 16 columns (from '@' to 'o' across the top). 16 just happens to be convenient for hexadecimal counting from $0 to $F.

There are 16 rows (from '@' downwards on the left). Again, convenient for hexadecimal.

So, an '@' is at the intersection of $0 and $0 = $00.

An 'o' is at the intersection of $0 and $F = $0F.

A '0' as at the intersection of $3 and $0 = $30.

It obviously makes sense to print this image out and mark the $0 through $F codings on the top of the image (left to right) and the left of the image (top to bottom).

However, if you use the online version, you can click on a character and the website gives you the decimal and hexadecimal value of the character!

A 'k' in this case is at the intersection of $0 and $B = $0B = 0000 1011 (in binary).

The character that was displayed was a '[' at the intersection of $1 and $B = $1B = 0001 1011 (in binary).

The difference (in this case) being bit 4 (counting from the right-hand side as bit 0).

There were also two (2) further errors I observed. The '.' character was displaying as a '>' character.

By the same process above, a '.' character is $2E = 0010 1110 (in binary).

A '>' character is $3E = 0011 1110 (in binary).

Again, bit 4 has changed from a logic '0' to a logic '1'.

Looking at the schematic for the PET VDU sub-system:

1735755856185.png

We observe that F8 is responsible for bits 0 through 3 and F7 is responsible for bits 4 through 7.

Therefore the fault could lie with video RAM F7 - or even with the 8-bit latch F9.

As your video RAM was socketed, I would have suggested exchanging video RAMs F7 and F8 to see if the fault 'moved' (the erroneous characters changed) or 'remained' (the erroneous characters stayed the same).

If the fault moved, it would have indicated a video RAM fault (as that was the ONLY change we made to our PET configuration between tests). The faulty component would, therefore, have been the original F7 that we have now moved to F8.

If the fault stayed the same, it is not likely that the video RAM was at fault, and we would have looked at an IC socket issue or F9.

I strongly suggest you read this post and try to understand it...

If you do not understand it, ask questions about what you do not understand - until you do...

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