Faulty C128 - Advice Desired

Started by EvilCensor, August 30, 2010, 08:51 AM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

EvilCensor

I recently acquired a nice C128 and found a few quirks.

First it seems to work fine in C128 mode but GO64, CBM-key and power-on gives me the following screen:



Also whilst trying to use SPRDEF I get this:



When powered up with a C64 cartridge all I get is a black screen.

I've tried re-seating U32 and U33 but it made no difference.. would really love to get this working and not just give up on it.

All constructive advice welcome ::)

Hydrophilic

Very interesting.  The C64 screen is not very informative, but the SPRDEF screen is.  It seems VIC is correctly accessing RAM from $2000~$3F3F (you can see all the + symbols in the top left and the prompt at the bottom left).  There are no ROMs in this region to cause a problem.  But the screen is garbled with color, which comes from $1C00~1FE7.  The CPU never sees ROM in that location, but the VIC normally sees Char ROM in area $1000~$1FFF. 

When you enter hi-res bitmap mode (GRAPHIC 1 or SPRDEF), the /CHAREN line is released (should go +5V) so that VIC will not see ROM (it will see RAM).  Because the screen colors are garbled, I'm betting the VIC is still seeing ROM which implies that the /CHAREN line is somehow being grounded (0V).

The C128 uses the MMU for memory management so this shouldn't cause serious problems.  But the C64 uses /CHAREN of CPU port ($00/01) for "bank" selection.  So if /CHAREN remains grounded, it will have serious trouble, as you have reported.

/CHAREN is controlled by bit 2 of the CPU port.  It's normal C128 value (not bitmap mode) is 0.  So if it's stuck low there shouldn't be a problem most of the time.  But the normal C64 value is 1.  If it's stuck low, the wrong memory config will be selected causing system crash.

Bit 2 maps to pin 28 of the 8502 (U6) and connects to only two things: a pull-up resistor pack (RP7-8) and pin 25 of the PLA (U11).  Both these chips are soldered directly to motherboard.  I suggest confirming the problem by testing the voltage in C64 mode or in SPRDEF.  You should get a reading of 2.8 to 5 volts, if you get a low reading, like 0.0 to 0.7 volts then it is being grounded.  In that case, check for any solder beads or other metal that might short the line to ground; check around the CPU, around the PLA, and along the line between them.

It might be possible that the trace is broken going to the pull-up resistor.  With power off, use a continuity tester to be sure the line is good between the CPU and the pull-up resistor.  It is also possible, but unlikely, the pull-up resistor is bad.  With the power off, you can check the resistance and it should be about 3.3k ohm.

If that doesn't help (no shorts, no broken trace, good resistance) then either CPU or PLA are the problem.  Unfortunately neither are easy to replace because they're custom chips and are directly soldered to the board.  Removing small soldered chips is a pain, but these are monster 40 and 48 pin chips!

Good luck!
I'm kupo for kupo nuts!

EvilCensor

Many thanks for the long and informative post I will try what you recommend this weekend.. I followed the C128 diagnostic sheet but could see nothing on it that sounded similar to this issue.

However I bought (just out of hope) a 318020-03 and 251913-01 and replaced the ones in the C128 with no luck, I also transposed U1 and U4 once again with no change in C128s function (out of interest they were numbered 2085 and 2385).

Would it be worth buying a diagnostic cartridge for this issue - would it even work in your opinion?

Hydrophilic

I don't think it would worth buying a diagnostic cartridge because the /CHAREN line does not go to the cartridge port so it could not directly be tested.  I am not familiar with any such cartridges so I don't know if it would work.  I assume it would work in C128 mode but not in C64 mode.

That being said, the /GAME and /XROM lines also control memory configuration in C64 mode, and these do run to the cartridge port.  So although a diagnostic cartridge wouldn't help with /CHAREN diagnosis, it might uncover additional problems.

If you don't already have voltage/resistance meter (multi-meter), I suggest buying one of them instead.  They are cheap and usefull for many things besides Commodores.
I'm kupo for kupo nuts!

EvilCensor

Yes I have a volt meter - I will check it out this weekend and hope it's nothing that can't be fixed in the meantime.

Hydrophilic

I just thought of something that might save some time.  You should be able to test /CHAREN from software because CPU I/O lines are bi-directional.  So you might want to try this code

?peek(1)and4: graphic1,1: ?peek(1)and4: graphic0

A normal C128 should report 0, 4.  If the /CHAREN line is being grounded then you should get 0, 0.

If you get normal value, then /CHAREN line and CPU are probably okay and the problem is more likely the PLA or something connected to it.  Unfortunately for trouble-shooting purposes, the PLA connects to almost to everything!  (all ROMs, 8502, Z80, MMU, cartridge port, and more)
I'm kupo for kupo nuts!

BigDumbDinosaur

Quote from: Hydrophilic on September 09, 2010, 07:43 AM
I just thought of something that might save some time.  You should be able to test /CHAREN from software because CPU I/O lines are bi-directional.  So you might want to try this code

?peek(1)and4: graphic1,1: ?peek(1)and4: graphic0

A normal C128 should report 0, 4.  If the /CHAREN line is being grounded then you should get 0, 0.

If you get normal value, then /CHAREN line and CPU are probably okay and the problem is more likely the PLA or something connected to it.
Possibly a pullup.  Commodore was notorious for going the cheap route with commodity parts like resistors.

QuoteUnfortunately for trouble-shooting purposes, the PLA connects to almost to everything!  (all ROMs, 8502, Z80, MMU, cartridge port, and more)
PLAs in Commodore machines have had a history of problems.  Back in the early to mid 1980s when PLA were still pretty new technology, retention failures weren't uncommon.  A PLA that failed to retain whatever had been written into it would invariably cause the machine to simply quit, or act in a bizarre fashion.  I recall a number of 128 (and C-64) failures brought about by faulty PLAs, and these were fairly new machines at the time.
x86?  We ain't got no x86.  We don't need no stinking x86!