• Please review our updated Terms and Rules here

PET cemetery - 4016 repair

yes, everything is going to the correct places and I've not found any shorts or broken traces.
I've had a poke around the board to look for anything that looks odd or any misbehaving logic but it all looks fairly normal. I'm at a bit of a loss.
 
/READ EVEN is output 6 from the74138 and /WRITE EVEN is output 11 which is what I labelled the probes as to make it easier to match against the bus values.
However I did go back and check over /READ EVEN with my scope as I had said there was some activity but not a lot, and there is a sporadic single pulse that the data logger didn't pick up as the timing probably wasn't tight enough.
So I do have activity on /READ EVEN it's just nowhere near as active as /WRITE EVEN which could be normal?
 
If the PET is running my PETTESTER correctly, there should be a burst of activity on /WRITE EVEN as it writes data into the video RAM, followed by a burst of activity on /READ EVEN as it reads back the values from the video RAM and compares it to what should be there.

This would mean that there should not be the odd pulse here or there observed on /READ EVEN if things are working correctly.

I'll take a look at the waveforms again shortly.

Dave
 
is it possible I've corrupted the ROM? or is the fact it's booting and initialising the screen an indication it's ok
I altered the section to use the 50HZ config:
CRTC_INIT:

; PET/CBM 60Hz Business.
; ======================
;
db 49 ; Register 0.
db 40 ; Register 1.
db 41 ; Register 2.
db 15 ; Register 3.
db 39 ; Register 4.
db 0 ; Register 5.
db 25 ; Register 6.
db 32 ; Register 7.
db 0 ; Register 8.
db 9 ; Register 9.
db 0 ; Register 10.
db 0 ; Register 11.
db 16 ; Register 12.
db 0 ; Register 13.
db 0 ; Register 14.
db 0 ; Register 15.
db 0 ; Register 16.
db 0 ; Register 17.

my compiled bin is identical to the one you provided bar a small change at the beginning which is what I expected....
From
Screenshot 2024-12-18 190016.png
To
Screenshot 2024-12-18 190035.png
 
If the screen is readable, it is generally OK. I was (however) wondering the same thing...

Could you dump out a bit more of the ROM, as you have not attached all of the register initialisation values.

The registers start at address 5 in the ROM, so another line of dump would give me everything I would need to know.

Dave
 
Ahh, very interesting so a similar issue (albeit without the reversed characters) alas not the correct settings for mine, that config just has the same issue but with what I guess is 60hz as it's smaller.
Can I pull the initialisation out of the original ROMs? if so which one holds it?
 
You will find all of the Commodore PET ROMs here: https://www.zimmers.net/anonftp/pub/cbm/firmware/computers/pet/index.html.

The EDIT ROM is where all the screen and keyboard stuff is located. Unfortunately, depending upon which version of the EDIT ROM you are using, the CRTC initialisation table 'moves around' in memory. This is all resolved by the assembler...

There is a commented disassembly of the edit-4-40-n-60Hz-901499-01.bin (Screen editor for BASIC 4, normal keyboard, CRTC, 40 columns, 60 Hz) ROM here: https://www.zimmers.net/anonftp/pub/cbm/firmware/computers/pet/edit-4-40-n-60hz-901499-01.dis.txt.

This is the CRTC initialisation table from that disassembly:

Code: 
;--------------- CRTC SETUP TABLES
; This table is used to setup the CRTC chip screen parameters.
; The values here configure the screen for 20kHz

$E7B1:           .BYT 31,28,29,0F,20,03,19,1D    ; CRTC register data -  40 COL TEXT mode
$E7B9:           .BYT 00,09,00,00,10,00,00,00    ; CRTC register data -  40 COL TEXT mode
$E7C1:           .BYT 00,00                      ; CRTC register data -  40 COL TEXT mode

$E7C3:           .BYT 31,28,29,0F,28,05,19,21    ; CRTC register data -  40 COL GRAPHICS mode
$E7CB:           .BYT 00,07,00,00,10,00,00,00    ; CRTC register data -  40 COL GRAPHICS mode
$E7D3:           .BYT 00,00                      ; CRTC register data -  40 COL GRAPHICS mode

You will probably observe that the initialisation values are the same that I have in my PETTESTER?!

Dave
 
hmmm, my edit ROM is edit-4-40-n-50Hz.901498-01 but it looks like no one has disassembled that one.
I've tried the two sets of settings for the 50hz business and the two of the 50hz Graphics out of your tables, but so far they just change how the data is displayed (size/position) rather that what is displayed.
Business fills the screen better and the second of the to is over to the right, so the first Business PET/CBM 50hz one is the best ... but that's the one I was mainly using.
 
Last edited:
>>>And I wouldn't have thought the business keyboard Vs graphics keyboard would affect the RAM testing and the ROM CRC checks would it?

Correct. But we haven't got passed the video RAM test first!

Going back to the original problem.

UC3 decodes for B02 and BR/W (with the A input strapped to 0). The other key signal decodes come from G1, /G2A and /G2B.

The '6' on the UC3 'CBA' input signals really only indicates a READ cycle (BR/W=HIGH when B02=HIGH) - and there will be loads and loads of other cycles that match this condition. The key '6' is when it occurs when /SEL8 is LOW (signifying it is a READ of the video RAM). No /SEL8 - not video RAM read - it is as simple as that.

Obviously, the CPU is writing a test pattern into the video RAM, it is just getting the two consecutive characters mixed up with each other and we get some corruption on the video screen.

I did check the source code for my video RAM test and it WRITES the test pattern through all of the video RAM first and then checks it. However, it abandons the test (and loops back to the writing again) on the FIRST error it finds. This may account for the lots of /WRITE EVEN signals and a sparse /READ EVEN. If the first video character is supposed to be $00 ('@'), and the CPU finds a $01 ('a') instead, then this would account for it. However, we would have to have an 'asymmetric' fault somewhere for this to happen (i.e. the write to video RAM occurs at one address whilst the read from video RAM occurs at a different address). The only thing that could account for this (offhand) is if the signal BR/W (or /WRITE EVEN) is short circuited to something somewhere...

This brings me back to the video RAM sockets, video RAM PCB tracking or video RAMs.

Is it worth swapping the two (2) video RAMs over?

Post a photograph with the video RAMs one way, swap them over and post another photograph with the video RAMs the other way around. You never know, it might give us another data point in this perplexing problem. It will be obvious when we find the fault!

Dave
 
Last edited:
OK, I'm going to make myself a little break out board to let me get a better look at the video RAM, as I was fumbling about with bits of wire and resistors checking the data lines, so I didn't really get a proper look at the order that the lines came in, I just made sure that each one did something. I'm almost tempted to use a level shifter and a pi pico to massively over engineer something simple :p
 
I haven't had too much time today, but what I have done is remove the video RAM and then manually manipulate the data lines while monitoring the output of UB3, so from ESD to LSD, and they match. I ran through each data line individually so 00000000,10000000, 01000000, 00100000 etc
I then matched what I was getting on the screen to the PETSCII character set
I was getting @, a, b, d, h, p, blank, Horizontal line, inverted @
This is all good up to the last two, and checking a couple of other character configurations and it seems that ESD6 and ESD7 are the wrong way round as inverted @ should be 00000010 not 00000001 and vice versa for the line character. Not exactly sure what this means of if it's not some normal quirk, but it's something!
PXL_20241219_223931843[1].jpg
 
ESD7 is the video invert bit...

An '@' shoukd be 00000000 and invert '@' should be 10000000 (with ESD7 on the left and ESD0 on the right).

Not sure where you are getting your bit patterns from...

Dave
 
Ahh, I'd used some online interactive lookup, but it had multiple values for different PETSCII variants, I'd selected CBM but clearly not the right one. So I can at least confirm that my data lines from the RAM and out of UB3 are working as expected.
So this has to be an address issue to the RAM..... I'll see if I can get some time and really look over this properly I've beeped it all out but it's clear that's not highlighting the issue, so I'll get the clips on the TA lines into UC8, 9 10 along with their select and also log the SA lines directly on the RAM. That should show if I have an issue before the three multiplexers or after .... maybe :)
 
You must log in or register to reply here.
Back
Top