| VCF East | Apr 17 - 19, 2026, | InfoAge, Wall, NJ |
| VCF Latam | Apr 24 - 26, 2026, | Bahía Blanca, Argentina |
| VCF Pac. NW | May 02 - 03, 2026, | Tukwila, WA |
| VCF Southwest | May 29 - 31, 2026, | Westin Dallas Fort Worth Airport |
| VCF Southeast | Aug 01 - 02, 2026, | Atlanta, GA |
| VCF West | Aug 01 - 02, 2026, | Mountain View, CA |
| VCF Midwest | Sep 12 - 13, 2026, | Schaumburg Convention Center, IL |
| VCF Montreal V2.0 | Nov 07 - 08, 2026, | Saint-Lambert, Montreal, Canada |
| VCF SoCal | See you in 2027, | Southern CA |
-
Please review our updated Terms and Rules here
C128 black screen / blank screen
- Thread starter gerha7
- Start date
Thanks, I can give that a try.
I'm wondering if the PLA (U11) might be an issue as well...after watching a video from Verne's Misadventures. I desoldered the PLA from the board then tested the signals on the VIC chip. Still no change, pin 23 on the VIC should test 2MHz but it tested 1.022 MHz. Pin 25 should test 4Mhz but it tests 2.04 MHz. I'll put a socket in for U11 and maybe look for a used PLA to see if that works.
Here's the weird part, after I removed the PLA, turned on the C128 and tested pin 23 of the VIC, I swore it tested 2.045 MHz, which is what it should be. But a minute later I tested it again and it was back down to 1.022 MHz.
I'm wondering if the PLA (U11) might be an issue as well...after watching a video from Verne's Misadventures. I desoldered the PLA from the board then tested the signals on the VIC chip. Still no change, pin 23 on the VIC should test 2MHz but it tested 1.022 MHz. Pin 25 should test 4Mhz but it tests 2.04 MHz. I'll put a socket in for U11 and maybe look for a used PLA to see if that works.
Here's the weird part, after I removed the PLA, turned on the C128 and tested pin 23 of the VIC, I swore it tested 2.045 MHz, which is what it should be. But a minute later I tested it again and it was back down to 1.022 MHz.
Hmm. Re-reading some old comments, I am left wondering how you measure the clock speeds. You did mention a scope, but also a ? result for measurement (some frequency tool in the scope?).
I worry whether you can actually see the clocks properly in the scope. What scope is this? What's its bandwidth?
I worry whether you can actually see the clocks properly in the scope. What scope is this? What's its bandwidth?
It's an OWON HDS242 40MHz handheld oscilloscope, 250 MSa/s (single channel). The probe is always set to 10x (I only have one probe) and I always check probe compensation when turning on the oscilloscope. I always use the Auto button.
Agreed. I can understand VIC pin 23 being at 1MHz...the specs say it can be at either 1 or 2MHz. I think when in C128 mode, from BASIC, entering 'FAST' puts it in 2MHz (and video goes blank as expected), and entering 'SLOW' brings it back down to 1MHz. Attaching video of testing VIC pin 23.
As for VIC pin 25, it should always be 4MHz (for the Z80) but it's always testing around 2.27MHz. See video.
Sorry if it displays sideways, not sure how to correct that, and it's a little distorted since I had to convert it to MP4. It plays fine (upright) from VLC Media Player.
As for VIC pin 25, it should always be 4MHz (for the Z80) but it's always testing around 2.27MHz. See video.
Sorry if it displays sideways, not sure how to correct that, and it's a little distorted since I had to convert it to MP4. It plays fine (upright) from VLC Media Player.
I'm still at it. I purchased several 7406N DIP-14 Hex Inverter Buffer/Driver IC's to replace the four original 7406 IC's at U29, U30, U37 and U63. After I replaced them I got some display activity--sporadically displays garbage but an improvement over consistently getting a black screen. Attached are some images. Next step is to get readings from the VIC II chip and others to see if there has been any improvement.
Attachments
Sorry if I missed something, but what happens when you insert the dead test cart?
(I would recommend the new destest as it can actually display meaningful text even if all RAM is broken, it displays it from ROM and uses hardware tricks to make the VIC chip display/hide parts of the text to indicate fail/pass and whatnot for the initial ram test, instead of just flashing error codes like the old dead test does).
A bit of theory of operation:
The Z80 starts up first. It has to, there is a hardware bug in the Z80 that makes it do random memory accesses if it isn't allowed to do it's normal startup procedure!
The Z80 uses 4k of the C128 Kernal ROM, the other 12k is used by the 8502 in C128 mode. The Z80 code first checks if the GAME and/or EXROM signals are held low in the cartridge port, and I think it also tests if the Commodore key is held down. If so it switches directly to C64 mode. Otherwise it does some more initialization and then switches to regular C128 mode, and I think the C128 8502 Kernal checks GAME and EXROM again once or twice and uses that to switch to C64 mode.
Note that there is a signal telling if you are in C64 or C128 mode. That signal should obviously start in C128 mode, and if you have a cart installed and/or hold the Commodore key down it should switch to C64 mode almost immediately after power on. If this works then you can be sure that the Z80 executes code with a decent success rate.
A few things that you can easily test:
With a Datasette connected, or a test setup for the sense wire, the motor power should come on a brief moment when powering up and then be switched off. If you pull sense low the motor signal should come on. This indicates that the Kernal 60Hz interrupt code and the I/O ports work correctly.
If you then type LOAD and press return, or press shift+RUN/STOP while having sense active, the motor should still be on. Pressing just STOP (RUN/STOP without shift) should then turn off the motor signal. This tells that the Basic interprester correctly calls the Kernal cassette LOAD code.
Also if you connect any disk drive set to the default device 8 the C128 reads the first sector on the first track, which is the way it boots for example CP/M. If this happens the C128 Kernal runs.
Re garbage: I don't know if there are any dead test style diagnostic ROMs that can use the 80 col output. You might want to check if the sync frequencies are correct after starting without a C64 cart inserted, that would indicate that the Kernal at least ran the code that initializes the 80 col chip. The 80 col chip has it's own RAM and also it's own clock, so if you get the correct sync frequencies then it's likely that any diagnose thing for the C128 would correctly display things on the 80 col output.
I've toyed with the idea of creating a C128 Z80 diag rom of sorts, like a cross between the stock C128 Z80 ROM code and the modern RAM tests that for example Adrians Digital Basement have used to diagnose and repair various TRS 80 computers in his videos. I don't know if there would be a real use case for a test like this as compared to a C64 dead test / destest cart, but still. In general the dagnose+repair procedure seems to be to get a C64 dead test / destest to work correctly, and then move on to whatever other symptoms may exist.
Re Z80 clock frequency: I can't remember how the circuit works but the C128 slows down the Z80 to fit 6502/6800 style bus cycles, and maybe it does this by just elongating the Z80 clock pulses rather than using the Z80 inputs that can extent bus cycles (wait state input)?
As for the AC voltages, it's normal that they are higher than spec depending on the load of the PSU and whatever your mains voltage happens to be at the moment.
Side track: The stock C128 power supply is a good power supply, so if you eventually want to use this C128 without needing to share PSU with your C64 you might want to consider getting a stock C128 PSU. You might want to replace the capacitors though, IIRC there are only a few of them and they tend to be from one of the bad brands (IIRC FRAKO or ROE or similar, the yellow/orange/red european ones tend to be bad, while the blue Philips ones (obviously found in for example the Philips made versions of the 1084 monitor and whatnot) tend to be good).
Fun little known fact: If you lower the 5V input from the external PSU the jail bars on the 40 col output goes away almost completely. This is a weird reason for not using contact cleaner on a working C128, by wiggling the power connector you can get rid of the jail bars, while if you use contact cleaners you will have jail bars forever
(I would recommend the new destest as it can actually display meaningful text even if all RAM is broken, it displays it from ROM and uses hardware tricks to make the VIC chip display/hide parts of the text to indicate fail/pass and whatnot for the initial ram test, instead of just flashing error codes like the old dead test does).
A bit of theory of operation:
The Z80 starts up first. It has to, there is a hardware bug in the Z80 that makes it do random memory accesses if it isn't allowed to do it's normal startup procedure!
The Z80 uses 4k of the C128 Kernal ROM, the other 12k is used by the 8502 in C128 mode. The Z80 code first checks if the GAME and/or EXROM signals are held low in the cartridge port, and I think it also tests if the Commodore key is held down. If so it switches directly to C64 mode. Otherwise it does some more initialization and then switches to regular C128 mode, and I think the C128 8502 Kernal checks GAME and EXROM again once or twice and uses that to switch to C64 mode.
Note that there is a signal telling if you are in C64 or C128 mode. That signal should obviously start in C128 mode, and if you have a cart installed and/or hold the Commodore key down it should switch to C64 mode almost immediately after power on. If this works then you can be sure that the Z80 executes code with a decent success rate.
A few things that you can easily test:
With a Datasette connected, or a test setup for the sense wire, the motor power should come on a brief moment when powering up and then be switched off. If you pull sense low the motor signal should come on. This indicates that the Kernal 60Hz interrupt code and the I/O ports work correctly.
If you then type LOAD and press return, or press shift+RUN/STOP while having sense active, the motor should still be on. Pressing just STOP (RUN/STOP without shift) should then turn off the motor signal. This tells that the Basic interprester correctly calls the Kernal cassette LOAD code.
Also if you connect any disk drive set to the default device 8 the C128 reads the first sector on the first track, which is the way it boots for example CP/M. If this happens the C128 Kernal runs.
Re garbage: I don't know if there are any dead test style diagnostic ROMs that can use the 80 col output. You might want to check if the sync frequencies are correct after starting without a C64 cart inserted, that would indicate that the Kernal at least ran the code that initializes the 80 col chip. The 80 col chip has it's own RAM and also it's own clock, so if you get the correct sync frequencies then it's likely that any diagnose thing for the C128 would correctly display things on the 80 col output.
I've toyed with the idea of creating a C128 Z80 diag rom of sorts, like a cross between the stock C128 Z80 ROM code and the modern RAM tests that for example Adrians Digital Basement have used to diagnose and repair various TRS 80 computers in his videos. I don't know if there would be a real use case for a test like this as compared to a C64 dead test / destest cart, but still. In general the dagnose+repair procedure seems to be to get a C64 dead test / destest to work correctly, and then move on to whatever other symptoms may exist.
Re Z80 clock frequency: I can't remember how the circuit works but the C128 slows down the Z80 to fit 6502/6800 style bus cycles, and maybe it does this by just elongating the Z80 clock pulses rather than using the Z80 inputs that can extent bus cycles (wait state input)?
As for the AC voltages, it's normal that they are higher than spec depending on the load of the PSU and whatever your mains voltage happens to be at the moment.
Side track: The stock C128 power supply is a good power supply, so if you eventually want to use this C128 without needing to share PSU with your C64 you might want to consider getting a stock C128 PSU. You might want to replace the capacitors though, IIRC there are only a few of them and they tend to be from one of the bad brands (IIRC FRAKO or ROE or similar, the yellow/orange/red european ones tend to be bad, while the blue Philips ones (obviously found in for example the Philips made versions of the 1084 monitor and whatnot) tend to be good).
Fun little known fact: If you lower the 5V input from the external PSU the jail bars on the 40 col output goes away almost completely. This is a weird reason for not using contact cleaner on a working C128, by wiggling the power connector you can get rid of the jail bars, while if you use contact cleaners you will have jail bars forever
Oh, that contact cleaner thing is quite the trick! I would have naïvely just used a diode or two to drop the voltage, but this sounds a lot easier. Unfortunately, I made the mistake of cleaning my contacts, but I will have a quick search and see if I can find some "contact dirtier." CRC must sell something good for that.
Thanks for the response @MiaM below are my replies by paragraph:
P1: For the dead test car, I don’t get any flashes or diagnostic display.
BTW - I’ve tried several scenarios but all yield random results. For example, I try turning on the C128 with no cartridge inserted, then with a game cartridge inserted, then with the diagnostic cartridge set to C128 diagnostic, then set as dead test. All of these mostly show a black screen [on 1702 monitor], but sometimes show garbage screen or a solid blue, grey or some other color. There seems to be no pattern or consistency.
P2: Here’s the dead test/diagnostic cart I'm using: Commodore 64 / 128 6 in 1 Dead Test, Diagnostic and 1541 Tools - Versa64Cart USA | eBay
P3 & P4: Correct, in light of that I ordered a C128 kernal ROM to replace my existing one, but I still got the same results (black screen or sometimes garbage)…although there’s no guarantee the ordered ROM works since I don’t have a working C128 to validate. Pin 47 on the MMU is high when in C128 mode, but it’s now testing low (C64 mode) even if I have no cart inserted or not pressing the C= key. The only time I consistently get a high voltage (C128 mode) on pin 47 is when I have the diag cart in dead test mode (I didn’t try diag mode). Also pin 43 on the MMU randomly is low or high regardless, but tests consistently low (Z80 mode) when using diag cart in dead test mode.
P5 & P6: I don’t have a Datasette but do have a 1541 floppy drive that I know works, I use it on my C64. When I turn on the C128, the 1541 spins for about 3 seconds then stops…seems normal.
P7: I didn’t do much testing on the VDU, but I did connect a CGA monitor (IBM 5153)..it shows white when turned on when the C128 is off. I pressed the 40/80 column key down and turned on the C128, the monitor would go blank. Tried on-off several times and still just shows blank, and tried diag/dead cart too but same blank screen on CGA.
The C128 I bought didn’t come with a C128 PSU, the one I use (C64PSU.com by Electroware) works/tests well.
What bugs me is the clock on the VIC pin 25 (Z80 PHI), it should be 4MHz but always tests around 2.045 MHz. Would a bad Z80 cause that?
P1: For the dead test car, I don’t get any flashes or diagnostic display.
BTW - I’ve tried several scenarios but all yield random results. For example, I try turning on the C128 with no cartridge inserted, then with a game cartridge inserted, then with the diagnostic cartridge set to C128 diagnostic, then set as dead test. All of these mostly show a black screen [on 1702 monitor], but sometimes show garbage screen or a solid blue, grey or some other color. There seems to be no pattern or consistency.
P2: Here’s the dead test/diagnostic cart I'm using: Commodore 64 / 128 6 in 1 Dead Test, Diagnostic and 1541 Tools - Versa64Cart USA | eBay
P3 & P4: Correct, in light of that I ordered a C128 kernal ROM to replace my existing one, but I still got the same results (black screen or sometimes garbage)…although there’s no guarantee the ordered ROM works since I don’t have a working C128 to validate. Pin 47 on the MMU is high when in C128 mode, but it’s now testing low (C64 mode) even if I have no cart inserted or not pressing the C= key. The only time I consistently get a high voltage (C128 mode) on pin 47 is when I have the diag cart in dead test mode (I didn’t try diag mode). Also pin 43 on the MMU randomly is low or high regardless, but tests consistently low (Z80 mode) when using diag cart in dead test mode.
P5 & P6: I don’t have a Datasette but do have a 1541 floppy drive that I know works, I use it on my C64. When I turn on the C128, the 1541 spins for about 3 seconds then stops…seems normal.
P7: I didn’t do much testing on the VDU, but I did connect a CGA monitor (IBM 5153)..it shows white when turned on when the C128 is off. I pressed the 40/80 column key down and turned on the C128, the monitor would go blank. Tried on-off several times and still just shows blank, and tried diag/dead cart too but same blank screen on CGA.
The C128 I bought didn’t come with a C128 PSU, the one I use (C64PSU.com by Electroware) works/tests well.
What bugs me is the clock on the VIC pin 25 (Z80 PHI), it should be 4MHz but always tests around 2.045 MHz. Would a bad Z80 cause that?
I can't see how, it's buffered by a 7407. But it would be worth popping that 7407 and seeing what the the signal looks like without it loading the line. If it's still ~2 MHz, check the other clock outputs and the clock inputs. If those look ok, it seems as if that would be a bad VIC II, no?
I removed IC 7407 (U57) by the VIC II chip, here are the readings from the VIC II, pin:
18 - 1.022 MHz
23 - 1.022 MHz
25 - 2.273 MHz
29 - 14.31 MHz
30 - 8.16 MHz
It's pretty much unchanged from when the IC was in place. Chip U60 is also a 7407, should I remove just that one and take the readings again?
18 - 1.022 MHz
23 - 1.022 MHz
25 - 2.273 MHz
29 - 14.31 MHz
30 - 8.16 MHz
It's pretty much unchanged from when the IC was in place. Chip U60 is also a 7407, should I remove just that one and take the readings again?
For reference, the schematic sheets I'm working from are 310378-1-left-and-right.gif (CPUs) and 310378-2-left-and-right.gif (video and clock) from zimmers.net.
I should have indicated the exact 7407; I didn't happen to notice that there are two of them. It's U60 you should remove; U57 will not affect the Z80 PHI line.
I'll also note that I'm just accepting what you say the frequencies should be; if you aren't sure that you've got these right, you can write up your logic for determining these (ideally with links to any datasheets you use) for me or others to check.
I should have indicated the exact 7407; I didn't happen to notice that there are two of them. It's U60 you should remove; U57 will not affect the Z80 PHI line.
I'll also note that I'm just accepting what you say the frequencies should be; if you aren't sure that you've got these right, you can write up your logic for determining these (ideally with links to any datasheets you use) for me or others to check.
I removed the 7407 at U60 and I still get the same readings as post #34.
For expected MHz readings, I'm using the Service Manual C-128/C128D Computer by Commodore (1987), page 35 (PDF page 37). My motherboard is a 310381 Rev 7.
I've used the C128 Diagnostic manual for much of my troubleshooting, but it only gets me so far when following the 'Troubleshooting the C128 System Clocks' section. Page 2-5 (PDF page 18) paragraph 2.4.5 step 2 and 3 all give the same readings, 2.27 MHz. I've replaced U60 and Q6 as directed but still get the same readings.
For expected MHz readings, I'm using the Service Manual C-128/C128D Computer by Commodore (1987), page 35 (PDF page 37). My motherboard is a 310381 Rev 7.
I've used the C128 Diagnostic manual for much of my troubleshooting, but it only gets me so far when following the 'Troubleshooting the C128 System Clocks' section. Page 2-5 (PDF page 18) paragraph 2.4.5 step 2 and 3 all give the same readings, 2.27 MHz. I've replaced U60 and Q6 as directed but still get the same readings.
The main oscillator that drives everything except the 80 col chip must be running at the correct frequency, otherwise the 40 col output wouldn't be a technically correct video signal.
You aren't supposed to measure the Z80 clock using a frequency meter, but rather measure the waveform length of "short" cycles.
In particular the VIC-II likely just constantly generates Z80 clock pulses that would make the Z80 bus cycles compatible with the 8502 bus cycles.
Sorry if I've already forgotten something in this thread, but: Have you checked what the signals that switches Z80 v.s. 8502 does?
I'm looking at the schematics at Zimmers
https://www.zimmers.net/anonftp/pub/cbm/schematics/computers/c128/index.html
Page 1 is the interesting one.
the MMU has a Z80EN signal and PLA generates a BA signal that are wire-or:ed with a few gates eventually feeding the Z80 _BUSRQST input to tell the Z80 to give up control, and the Z80 outputs _BUSACK that via a gate feeds AEC on the 8502 (an input that was introduced with the 6510, that tri states the bus, at the time in order to not need bus drivers between the 6510 and the VIC-II chip, but is also used for for example external DMA devices (cartridge port like the REU) and in this case to let the Z80 drive the bus). The _BUSACK is also fed in inverted form to the PLA.
I recommend that you set up your oscilloscope with no free running and to trigger on the release of the reset line (thankfully the C128 has a reset button so you can easily repeat measurements by just pushing the reset button). That way you can measure various signals and see what happens at what point in time after reset is released. (To really measure super exactly you'd want to gate the clock with the reset line, but that seems to not be worth the effort). If your oscilloscope has an external trigger input it might be worth using that for the reset signal, at least if you "only" have two channels, as then you can measure any two different signals at the same time. Since the reset is so slow you can use almost whatever wire you have at had as long as you don't damage the BNC connector on your oscilloscope and as long as the wire don't pick up interference from whatnot you have nearby. Or rather this is true if you measure on the actual reset button but perhaps not if you measure on the reset line that goes to a lot of chips in the computer, as they might not like a slow rise time on the reset line.
Re the switcing between the Z80 and 8502: We have to remember that the Z80 was added late during the C128 design. In particular they stuggled getting the C64 CP/M cart working and as the goal was to be compatible with the C64 they decided to include a Z80, and thus there are a bunch of 74xx chips to use the Z80 rather than doing more revisions of the C128 specific chips in order to not need as many 74xx chips. (And/or perhaps the 74xx chips uses signals that aren't available in the MMU, PLA and/or whatnot, and/or they ran out of chip count on the chips).
Also note that some signals have a bit odd names. The 8502 clock is called 2MHz even when running at 1MHz, and the frequency is switched using registers in the VIC-IIe chip.
You aren't supposed to measure the Z80 clock using a frequency meter, but rather measure the waveform length of "short" cycles.
In particular the VIC-II likely just constantly generates Z80 clock pulses that would make the Z80 bus cycles compatible with the 8502 bus cycles.
Sorry if I've already forgotten something in this thread, but: Have you checked what the signals that switches Z80 v.s. 8502 does?
I'm looking at the schematics at Zimmers
https://www.zimmers.net/anonftp/pub/cbm/schematics/computers/c128/index.html
Page 1 is the interesting one.
the MMU has a Z80EN signal and PLA generates a BA signal that are wire-or:ed with a few gates eventually feeding the Z80 _BUSRQST input to tell the Z80 to give up control, and the Z80 outputs _BUSACK that via a gate feeds AEC on the 8502 (an input that was introduced with the 6510, that tri states the bus, at the time in order to not need bus drivers between the 6510 and the VIC-II chip, but is also used for for example external DMA devices (cartridge port like the REU) and in this case to let the Z80 drive the bus). The _BUSACK is also fed in inverted form to the PLA.
I recommend that you set up your oscilloscope with no free running and to trigger on the release of the reset line (thankfully the C128 has a reset button so you can easily repeat measurements by just pushing the reset button). That way you can measure various signals and see what happens at what point in time after reset is released. (To really measure super exactly you'd want to gate the clock with the reset line, but that seems to not be worth the effort). If your oscilloscope has an external trigger input it might be worth using that for the reset signal, at least if you "only" have two channels, as then you can measure any two different signals at the same time. Since the reset is so slow you can use almost whatever wire you have at had as long as you don't damage the BNC connector on your oscilloscope and as long as the wire don't pick up interference from whatnot you have nearby. Or rather this is true if you measure on the actual reset button but perhaps not if you measure on the reset line that goes to a lot of chips in the computer, as they might not like a slow rise time on the reset line.
Re the switcing between the Z80 and 8502: We have to remember that the Z80 was added late during the C128 design. In particular they stuggled getting the C64 CP/M cart working and as the goal was to be compatible with the C64 they decided to include a Z80, and thus there are a bunch of 74xx chips to use the Z80 rather than doing more revisions of the C128 specific chips in order to not need as many 74xx chips. (And/or perhaps the 74xx chips uses signals that aren't available in the MMU, PLA and/or whatnot, and/or they ran out of chip count on the chips).
Also note that some signals have a bit odd names. The 8502 clock is called 2MHz even when running at 1MHz, and the frequency is switched using registers in the VIC-IIe chip.
Yes, in that diags manual, 2.4.5 steps 1 and 2 are exactly what I was thinking from the schematic. Your measurements on pins 30 and 29 of the VIC (which are connected to pins 6 and 80 of the clock generator U28) match what's expected according to step 1, and yet, with U60 removed, the output on pin 25 is not the 4.0 MHz clock you expect. Since we eliminated U60 affecting that test, it does appear to be a bad VIC (U21).
It would be interesting to look at the exact waveform on pin 25 (with U60 removed) and see what that looks like, though regardless I don't see how to fix a broken VIC.
(Actually, as MiaM points out, it's possible that the way you're measuring that clock is not giving a correct result; checking it on a 'scope would properly verify that it really is 2 MHz instead of 4 MHz.)
It would be interesting to look at the exact waveform on pin 25 (with U60 removed) and see what that looks like, though regardless I don't see how to fix a broken VIC.
(Actually, as MiaM points out, it's possible that the way you're measuring that clock is not giving a correct result; checking it on a 'scope would properly verify that it really is 2 MHz instead of 4 MHz.)
Well it is about 4 MHz half the time! It's just the other half the time it's 0 Mhz.
I'm reasonably certain now that that's a bad VIC, though it might be worth confirming with someone here who has a working C128 that can show us the waveform he sees on that pin.
I'm reasonably certain now that that's a bad VIC, though it might be worth confirming with someone here who has a working C128 that can show us the waveform he sees on that pin.