• Please review our updated Terms and Rules here

PET 4032 with Shifted Video

A

AtariMac

Member
Joined
Mar 4, 2014
Messages
10
I fired up my PET 4032 over the weekend and after a couple of minutes of use the screen has shifted and the the 1st row of the screen is now on the last row. I thought that maybe it was just an issue of adjusting the yoke on the CRT, but that didn't work. The PET does not seem to have a horizontal hold and it was suggested to me to try this site since another PET discussed here seemed to have a similar problem.

Here is a link to my PET's screen. http://imgur.com/Ihdqbww

Any input is much appreciated!

Thanks!

Pete
 
Ah you've found this forum already.

From the screen size I think this is a non-CRTC machine (9" screen). So the schematics would be under
http://www.zimmers.net/anonftp/pub/cbm/schematics/computers/pet/2001N/index.html
Can you confirm this?

I'm not sure, but I suspec the flip-flop at G8 to play a role in it. It relates the new address to the actual video RAM address.
http://www.zimmers.net/anonftp/pub/cbm/schematics/computers/pet/2001N/320349-7.gif
If /NEXT is early it could count the new address into the F2/F4 address counters early....

OTOH the character timing seems stable - but loading the wrong address at the start of the line. Which would hint to The flip flop at H7, or even G9....
http://www.zimmers.net/anonftp/pub/cbm/schematics/computers/pet/2001N/320349-6.gif

What do you (forum members) think?

André
 
fachat said:
Ah you've found this forum already.

From the screen size I think this is a non-CRTC machine (9" screen). So the schematics would be under
http://www.zimmers.net/anonftp/pub/cbm/schematics/computers/pet/2001N/index.html
Can you confirm this?

I'm not sure, but I suspec the flip-flop at G8 to play a role in it. It relates the new address to the actual video RAM address.
http://www.zimmers.net/anonftp/pub/cbm/schematics/computers/pet/2001N/320349-7.gif
If /NEXT is early it could count the new address into the F2/F4 address counters early....

OTOH the character timing seems stable - but loading the wrong address at the start of the line. Which would hint to The flip flop at H7, or even G9....
http://www.zimmers.net/anonftp/pub/cbm/schematics/computers/pet/2001N/320349-6.gif

What do you (forum members) think?
Click to expand...

André,
You are on the right track. I would also look at a glitch by flip flop G6 (74LS107) or counter F4 (74177).

Can the OP execute a POKE 32768,24 to put an "X" in the first screen location and then try to read it back with a ? PEEK(32768 ). If the answer comes back 24, but there is no X on the screen that may tell us something??
-Dave
 
It is a 12" model.

I don't see G6 or F4 on the board at all. It was suggested to me that UB1, UB2, and UC1 might me the cause. I tried to piggyback those with a new flip-flop but that did not seem to have any affect at all.

I poked 32768,24 and nothing at all showed up. However, when I peek that location I do get a value of 24.
 
AtariMac said:
It is a 12" model.
Click to expand...
Then you have a fat 40 model? Do you have a 6545 CRT Controller chip? If so that is a different ball game.


I poked 32768,24 and nothing at all showed up. However, when I peek that location I do get a value of 24.
Click to expand...

That may say your video RAM addressing is fine from the CPU side, but the screen refresh side is messed up. It could be the 6545 CRTC or maybe the UC8 mux chip (74LS157). Do you have a scope to check signal TA0?
 
I wrote the following program and I get a valid value each time. But nothing shows up on the display.

10 ? "♥️"
20 FOR I=1 TO 20
25 READ X
30 POKE 32768,X
40 ? X
50 NEXT I
60 GOTO 60
100 DATA 1,2,3,4,5,6,7,8,9,10
101 DATA 11,12,13,14,15,16,17,18,19,20
 
I was wondering if it would be possible to poke to set margins? I can do this easily on my Atari 8-bits, but don't see any reference to it in the memory map of the PET.

I'm thinking if that were possible I could use that as a work around until this gets figured out.

Anyone know if that is a possibility?
 
AtariMac said:
There is a 6454A-1 located right between the 6502 and a 6520
Click to expand...

I don't imagine that it is on a socket? Let's exhaust other options before tackling replacing a soldered 40 pin DIP.

As far as playing with margins, the 6545 has a set of 18 registers that control those type of parameters, but I'm not sure where to start with that. Does anyone out there have the set of constants for the fat 40?

Here is a link to the 6545 register definitions.
 
dave_m said:
That may say your video RAM addressing is fine from the CPU side, but the screen refresh side is messed up. It could be the 6545 CRTC or maybe the UC8 mux chip (74LS157). Do you have a scope to check signal TA0?
Click to expand...

I do not have a scope. I know a guy who does so maybe he can help.

The 6454 is not socketed.

I'm still not 100% convinced that this isn't an issue with the display. I have a couple of people willing for me to send the motherboard so they can try it in their PETs and compare the results.

Maybe I should take advantage of that just so I can cross that off the list if their results are the same.
 
AtariMac said:
I'm still not 100% convinced that this isn't an issue with the display. I have a couple of people willing for me to send the motherboard so they can try it in their PETs and compare the results.
Click to expand...

It couldn't hurt, but I don't see how the monitor can place the "R" of READY on the end of the previous line. It seems to be a timing problem with the video data. Unfortunately, the refresh addresses come from the 6545 CRTC. But there is a mux in the path (UC8 ) which possibly might be the problem. Perhaps you can "piggyback" the 74LS157 mux chip and see if anything changes? I would want to put a scope on TA0 from the CRTC and the Screen Address 0 (SA0) output of the mux at the same time.
 
dave_m said:
It couldn't hurt, but I don't see how the monitor can place the "R" of READY on the end of the previous line.
Click to expand...
I'm with Dave on this one; if it were a monitor problem the R would probably be reversed.

This is obviously not a line problem so as Dave says, it can't be the monitor; it looks like a screen memory addressing problem, with the entire screen memory being displayed shifted 1 character to the left, with the first character shifted into oblivion...

How did it look when you typed in the little program?
 
Last edited:
MikeS said:
it looks like a screen memory addressing problem, with the entire screen memory being displayed shifted 1 character to the left, with the first character shifted into oblivion...
Click to expand...

Mike,
Something looks strange. What you say is correct for the first 40 characters, but look at the second line of 40 characters - it starts correctly. Only every other line is shifted left.

Also this does not look like a FAT 40 12" screen. Is this a 9" screen as André has suggested? If so, someone has installed a universal board into a 9" system? Perhaps the problem is with the Editor ROM that handles the formatting of the 40 character lines in BASIC4 or a problem with the constants in the 6545 which are stored in the Editor ROM also?

AtariMac, what is the dash number of the editor ROM UD7?
 
dave_m said:
What you say is correct for the first 40 characters, but look at the second line of 40 characters - it starts correctly. Only every other line is shifted left.
Click to expand...
I disagree. I could be wrong, but I think the first character of the second line is a space, which has been invisibly shifted one character to the left.

Numeric values in Commodore BASIC on the PET always include a leading and trailing space, a serious annoyance to programmers. The routine that displays number when you PRINT is the same one called to display the free memory on startup.
 
KC9UDX said:
I disagree. I could be wrong, but I think the first character of the second line is a space, which has been invisibly shifted one character to the left.

Numeric values in Commodore BASIC on the PET always include a leading and trailing space, a serious annoyance to programmers. The routine that displays number when you PRINT is the same one called to display the free memory on startup.
Click to expand...

You are right. I never noticed the numeric bytes free message has a leading space.
 
dave_m said:
You are right. I never noticed the numeric bytes free message has a leading space.
Click to expand...
Yeah, what he said ;-)

Looks like a Fat40 to me. The 9" screens I've seen don't have that wide metal frame around the screen bezel and the characters look a little different with the smaller pitch; I think the angle of the camera is distorting the shape somewhat, making it look square instead of trapezoid.

Should still get the PCB part number though; in fact we should always ask for that after the first post if it's not given ;-)
 
MikeS said:
Yeah, what he said ;-)

Looks like a Fat40 to me. The 9" screens I've seen don't have that wide metal frame around the screen bezel and the characters look a little different with the smaller pitch; I think the angle of the camera is distorting the shape somewhat, making it look square instead of trapezoid.

Should still get the PCB part number though; in fact we should always ask for that after the first post if it's not given ;-)
Click to expand...

I thought the characters should have double pixels (fatter), sort of like bold characters, but I am not very familiar with the fat 40.
 
You must log in or register to reply here.
Back
Top