C64 display with a bad U13 chip
RajW
I was working on a C64 today for Burt (a.k.a. Terminator) and ran
across a problem which I have not seen before. The computer would
power up properly and get to the blue screen, but the screen had a
'pattern of garbage on it. (See picture here)
http://www.c64.us/images/c64badu13.JPG
It took me a while to diagnose the problem since I had never seen it
before but the problem was a defective chip at U13 on a 250425 system
board. Hope this helps those of you out there repair your C64's.
C64 forever!
/*Raj*/
Riccardo Rubini
Hmm. One of the two RAM multiplexers; on that revision board, in U13,
there's a TTL 74LS257 chip. There should be another one in U25, and if it
fails, similiar garbage could happen on screen.
Riccardo
Riccardo Rubini
> Hmm. One of the two RAM multiplexers; on that revision board, in U13,
> there's a TTL 74LS257 chip. There should be another one in U25, and
> if it fails, similiar garbage could happen on screen.
I found this reference on the C64 service manual, which could explain better
what was going on, on Burt's C64, Raj:
---[ from the C64 service manual ]---
RAM Control Logic.
U13 and U25 are multiplexers. The address output from the microprocessor
are passed to RAM via U13 and U25 when the output Address Enable Control
(AEC) from the VIC IC is "high". When AEC is "low" the VIC IC outputs
refresh addresses on pins 24 - 31. AEC goes "low" when the system clock,
phase 2, is "low". Since all I/O decoding occurs when phase 2 is "high",
refresh is transparent to the processor.
Eight 4164 DRAMS provide 64k bytes of memory. One 2114 RAM (U6) provides
512 bytes of memory allocated for screen color data storage.
---------------------------------------
RajW
<rub...@despammed.com> wrote:
>Hmm. One of the two RAM multiplexers; on that revision board, in U13,
>there's a TTL 74LS257 chip. There should be another one in U25, and if it
>fails, similiar garbage could happen on screen.
Hey Riccardo,
Yeah, I know what the chips are. :) I've got more diagnostic stuff
than I can count. :) I was just posting the information for others to
be able quickly diagnose their C64's. I did swap the chips to test
them. Oddly enough, swapping the chip to U25 yielded a black screen...
no display.
/*Raj*/
P.S. I am working on a web site kind of like Ray Carlsen's but with
pictures of the various screens of defective C64s. That picture was
just a sample.
Hans Otten
>
>P.S. I am working on a web site kind of like Ray Carlsen's but with
>pictures of the various screens of defective C64s. That picture was
>just a sample.
Great! That will help reviving C64's that otherwise end up as garbage.
MSX & X10 & 6502 & Philips bouwdozen & sales:
http://www.hansotten.com
Scott McDonnell
Thanks a bunch! I actually have a few commodore 64s sitting here with that
exact problem. I hadn't looked at them too much, yet. But, now I you just
saved me a bunch of work.
Thanks again,
Scott
"RajW" <r...@intelc64.net> wrote in message
news:m654401ueuctnj1i7...@4ax.com...
RajW
<devi...@NOSPAMexcite.com> wrote:
>Thanks a bunch! I actually have a few commodore 64s sitting here with that
>exact problem. I hadn't looked at them too much, yet. But, now I you just
>saved me a bunch of work.
My pleasure! I fix Commodore equipment all the time and I love doing
it. As I get more defective C64's I will post more pictures. I'm no
Ray Carlsen... but I'm not bad. :)
Just an FYI... I keep all of my defective chips so I can duplicate the
problems. If anyone wants to have me repair their Commodore equipment
please feel fill out the repair form here:
http://www.c64.us/contact/cbmrepairs.htm
Ok... off to the laboratory (basement) to upgrade some more C128's to
64K of video RAM. :)
/*Raj*/
Agemixer
On Sun, 29 Feb 2004, RajW wrote:
> P.S. I am working on a web site kind of like Ray Carlsen's but with
> pictures of the various screens of defective C64s. That picture was
> just a sample.
Great work :)
Sometimes a picture tells more than a thousand of words.
Any idea for some diagnostic program or rather some POKE output screen
shots?
--
Agemixer/Skalaria - "First run, then load."
email: age...@japo.fi pass: "C64 mailinki" to the Subject: line
Spam filter is on
RajW
wrote:
>Great work :)
Thank you... Thank you... :)
>Sometimes a picture tells more than a thousand of words.
Yeah... I was going to just post a description of the problem but I
couldn't figure out how to describe that screen! haha
>Any idea for some diagnostic program or rather some POKE output screen
>shots?
To diagnose this fault? You would never get to a screen to put in any
pokes. If you are just talking in general about troubleshooting, I use
a Commodore C64 diagnostic cartridge with an external test harness and
a TurboCPU (4MHz Accelerator) cartridge to help me diagnose many
faults. If I have missed what you were asking please explain. :)
/*Raj*/
Agemixer
On Mon, 1 Mar 2004, RajW wrote:
> >Sometimes a picture tells more than a thousand of words.
>
> Yeah... I was going to just post a description of the problem but I
> couldn't figure out how to describe that screen! haha
hehe
> >Any idea for some diagnostic program or rather some POKE output screen
> >shots?
>
> To diagnose this fault? You would never get to a screen to put in any
> pokes. If you are just talking in general about troubleshooting, I use
> a Commodore C64 diagnostic cartridge with an external test harness and
> a TurboCPU (4MHz Accelerator) cartridge to help me diagnose many
> faults. If I have missed what you were asking please explain. :)
Ok.. I was talking about some usual "poor man's troubleshooting" methods,
as many home-repairers doesn't own or need any expensive oscilloscopes and
equipment to test the condition of a machine. For example, i was thinking
there are machines which may show up in a good condition, boots up well,
with a good picture and sound, but instead refuses to run, even smaller
programs because of a memory failures (first a POKE 53272,37 came to my
mind), and so on. With a POKE 53265,59:POKE53272,16+8*(bank and 1):POKE
56576,3.6-bank/2 or something like that, it is mostly possible to spot a
faulty RAM byte on a screen (as a 8 kilobyte banks. :) I also used this
"poor man's" troubleshooting methods for broken CIAs; Some pokes for I/O
ports and a digital multimeter (before opening any cases for chip
replacement) to see if the ports are working correctly. Also if there was
no sound it was possible to probe if there is SID was present by poking
some values into channel 3 and read the value from $d41b. And if there
was a black screen, it might still be possible to type in something. That
was just some example, ofcourse there is tons of tests... (poke nnnn,x
causing strange behaviors or a hangup instead of what the poke should
actually do)
Sorry for the fuzz, hope i did express myself clearly now :)
RajW
wrote:
>Ok.. I was talking about some usual "poor man's troubleshooting" methods,
>as many home-repairers doesn't own or need any expensive oscilloscopes and
>equipment to test the condition of a machine.
Oh... Ok! I understand. Well... most of the Commodore equipment that
is sent to me for repairs is usually dead or worse. I don't think I
have gotten in a single that C64 that didn't have a black or blue
screen with nothing on it.
>For example, i was thinking
>there are machines which may show up in a good condition, boots up well,
>with a good picture and sound, but instead refuses to run, even smaller
>programs because of a memory failures (first a POKE 53272,37 came to my
>mind), and so on.
Fortunately memory errors on a C64 manifest themselves very easily and
diagnostic hardware is usually not necessary. They can be a little
difficult to trace to RAM or ROM but still not that difficult to
diagnose.
>Sorry for the fuzz, hope i did express myself clearly now :)
No worries about the fuss. :) I think that my troubleshooting may be
a bit different because I tend to look at the Commodore from an
electronics point of view rather than a program point of view.
I completely understand what you are saying. As I get more defective
Commodores over the years I will start looking for ways to diagnose
them progmatically (yeah probably not a word! lol!). For example I
need to write a program to determine *exactly* which RAM chip is
defective. Of course this is a pain because depending on which chip
has the stuck bit, I would only be able to use certain memory
locations. GGgrrr! :)
I'm thinking it would be easier for me to write a program for an Atmel
microcontroller (uC) and then attach the uC to the RAM chip with a
special 'chip clip'. Heh.. who knows. :)
/*Raj*/
Agemixer
On Tue, 2 Mar 2004, RajW wrote:
> For example I need to write a program to determine *exactly* which RAM
> chip is defective. Of course this is a pain because depending on which
> chip has the stuck bit, I would only be able to use certain memory
> locations. GGgrrr! :)
Hehe, sometimes that's the funniest part of it :)
What kind of methods you do try at first, when you got a computer with no
sign of life at all (excluding a blown fuse)?
I have also a memory question i've set aside for a while, as i'm not sure
about, but i guess you know better... (Probably Rick or Ray may answer
aswell..)
I know that most mem fault behaviors should normally give either a
'0'-bit, '1'-bit or an unstable floater on a certain location, but i
have been wondering, might it also be possible (for certain DRAM types),
that a certain poke on some memory bit may affect some other bit in the
memory (i.e. poking $0801 a $01 may turn $9801 go $fe instead of staying
$FF test pattern) or anything like that, affecting a (physically) nearest
working logic inside the faulty chip?
If it is true, i've been coding a deep-test routine (which i did put
aside) to compare such memory faults, but the worst thing for such
bit-by-bit test is that it is 512000 times slower than the standard
memory test with patterns of $55 and $AA... :)