C128 black screen / blank screen

[ClassicHasClass]

Afaik those lines "only" affect the 8502 while in 64 mode, not in 128 mode, so at least in theory it should be possible to do this even in 8502 C128 mode. But then maybe it would had been harder to set up the 8502 in a way that ensures that after writing to the 64/128 mode I/O thing ends up doing an indirect jump to the reset vector location, without altering bank 0 memory contents (that I think the C128 doesn't touch if you hold C= or a cart pulls GAME/EXROM at boot).

I.E. to me it feels like the Z80 more helps with switching to C64 mode as cleanly as possible rather than being particularly helpful for the GAME/EXROM cartridge port signals. (I would think that code that reads those as inports in C128 mode, determines that at least one is low, and jumps to the code switching to C64 mode, would execute similarly fast either on the 8502 or Z80).

The Magic Voice doesn't assert any lines when the machine is turned on - it only does so when it sees the machine going for reset vectors, at which point it pretends to be an Ultimax cartridge. Ordinarily it would then take over the 64 with its own reset vector, copy its code to $c000, and reassert BASIC and Kernal ROM to finish startup. However, the machine is already in 128 mode by this point because the Z80 didn't see any lines asserted. My understanding is this ends up in an unhandled situation between the PLA and the MMU. Even if the 8502 saw EXROM in the second check at $e242, it would never end up running the Magic Voice's initialization routine, so the cartridge would still fail.

By having the Commodore key down, the Z80 has already forced the machine to 64 mode before the Magic Voice sees the 8502 start. The 8502 then goes for vectors in the correct configuration and everything works. I guess this is a sort of race condition, but not really one due to the way they're clocked AIUI.

 

[gerha7]

I received my second C128 (call it C128 #2) and I verified it works (displays C128 mode green startup/BASIC screen), as advertised by the seller. Luckily, it's the same motherboard as my first C128, 310381 Rev 7. I haven't had a whole lot of time but here's what I covered so far. I didn't see any physical differences between the motherboards, e.g. bodge wires, trace by U3 (post #5). On the C128 #2 the voltages looked OK, pin 2 on the datasette port tested 5.030 VDC.

Below are the readings (MHz) when the C128 #2 was plugged into a composite monitor (1702) and in C128 40-col mode in slow/default mode, and nothing plugged into any other port.
VIC II pin (these VIC II readings matched what was measured on C128 #1)...
18 = 1.023
23 = 1.022 (2.045 in fast mode--wasn't able to test fast mode on C128 #1)
25 = 2.273 same waveform as in post #39
29 = 14.37
30 = 8.163
MMU pins 43 (Z80EN - low if Z80 mode) and 47 (C128/C64 mode - high when in C128 mode) were both high, (I'll have to measure this on C128 #1)
Z80 pin 6 (PHI system clock) = 2.273 which is also what C128 #1 showed
8502 pin 1 = 1.023 (2.045 in fast mode)

Chip swapping: Next I removed each of the following socketed chips from C128 #2 and put in the one from C128 #1:
MMU (U7), SID (U5), VIC II (U21), ROMs (U32 through U35), CIA's (U1, U4), VDC (U22), IC timer (U28)
All of them worked fine...showed green startup/BASIC screen. Therefore, I assume those chips from C128 #1 are OK.

So, it seems the next ones to test are the 8502, Z80 and PLA. But unfortunately, none of these are socketed. Any input on which one I should try first? Also, I've seen this but not sure if it's recommended. Is it possible to remove, for example the 8502 from C128 #1 and simply set it atop/piggyback on the existing 8502 in the C128 #2?

 

[MiaM]

How much data can your scope store?

You could trigger on the reset pulse and capture as much as possible on various bus signals, and compare the two computers.

When reset is released the Z80 should start running code from the Kernal ROM.

As the RESET line (IIRC?) is asynchronous there will be jitter of up to one clock cycle between captures unless you use an AND/NAND gate to combine _RESET with the 1MHz clock signal for triggering your scope, so any slight variations in where things start on each capture would be normal.

A logic analyzer would be ideal here but a modern digital scope is also usable, although way more tedious.

Maybe start looking at signals like _MREQ, _RD and A0 on the Z80, and perhaps also _M1. IIRC M1 pulses once for each instruction (IIRC on the bus cycle that reads the first byte of the instruction). A0 should toggle as it executes instructions, and this should at least happen for a short while even if the Kernal ROM contents is bad (or the PLA doesn't access the Kernal ROM correctly). _RD should obviously pulse for each bus cycle that isn't a write. _MREQ should pules for all bus cycles (IIRC the C128 doesn't use _IORQ).

You could also look at the enable signal for the Kernal ROM. It should pulse whenever the Z80 reads code.

I don't know what the value is for various chips today, but as the Z80 is a generic component I would probably go for that one first before the PLA or the 8502, and maybe even cut the legs and desolder each leg individually to reduce the risk of PCB damage. But then I suck at desoldering things from PCBs that have more than a single layer, which I at least partially blame on me only having cheap manual spring loaded "solder suckers" (not sure what the correct name is in English). If you have one of those fancy high quality Hakko desoldering stations you could of course go for any of the chips.

Btw if it seems like the Z80 tries to execute code, but fails at some point, it might be worth considering burning a test EPROM that just contain Z80 NOP instructions, as that should result in the Z80 executing 4k worth of nops and then ending up trying to execute random garbage from RAM. I'm too lazy to check how many clock cycles a Z80 uses to execute a NOP but you should have plenty of time to capture oscilloscope traces.

You could also try just removing the Kernal ROM. If that results in the data bus being pulled up to FF, the Z80 should then repeatedly execute the RST38 instruction, that jumps to address 38 (similar to the INT instructions on an 8088, or TRAP on the 68000 or whatnot). This should produce a repeating pattern on most bus signals, except of course that the VIC chip would at least do DRAM refresh and I think it probably always does some other bus accesses too even if the display isn't switched on.

 

[gerha7]

I took voltage readings for every pin on the Z80 on the good and bad C128's. The ones that were significantly different from each other, I highlighted in yellow. Not sure if these indicate a defect with the Z80 or if the cause could be external to the Z80 (e.g. bad trace, bad PLA, bad RAM, etc.). The kernal ROM IC should be fine since I swapped in the one form the bad C128 into the good C128, and it worked fine.

I've also attached a comparison scope reading on pin 30 (A0). The scale is different (Sa/s and horizontal time scale), not sure why that happened. I press my scope's 'Auto' button for each pin reading.

 

[MiaM]

In order for that comparison to work you'd probably need to run the C128 in any mode where the Z80 is active. I.E. either boot CP/M or use any of the odd non-CPM programs that use the Z80.
A quick search tells that in C128 mode you put a Z80 program at address $FFEE and then write $B0 to $D505 to switch to Z80. A simple Z80 program that just jumps back to $FFEE and then actually switching to Z80 mode should be possible to do with just a few POKEs. I.E. put $C3 $EE $FF at $FFEE (subject to incorrect byte order error), and then put $B0 at $D505. Would be four POKEs. I haven't got VICE installed on the computer I'm writing this on so can't test it out. I would use the monitor to put in the first three bytes and then use POKE in basic for the last one as it seems like a bad idea to fiddle with the MMU registers using the monitor. Btw a longer example can be found here.

I'd say that INT being low on the bad C128 is a bit suspicious, but I assume that the Z80 runs with interrupts disabled while doing the initialization. Might be worth removing the CIA chip that generates IRQ/INT and see if that signal changes.

It somehow seems like the Z80 is trying to run code but is somehow stuck on the bad C128. BUSRQ and BUSAK shows that the bad C128 has the Z80 active while the good C128 has the Z80 inactive.

I was about to wrote a lengthy thing about it looks like A0, A1, A4, A5 being stuck high but your scope capture shows A0 toggle. I don't know exactly how the signals are supposed to look like, but your captures at least seems reasonable for running in Z80 v.s. in 8502 mode.

 

[gerha7]

Not sure I'm doing this right. In VICE from the C128 40-column screen, I enter 'monitor', then enter 'M FFEE' to display values starting at $FFEE. Per the C128 System Guide, I can simply move my cursor over the values and enter new values and press enter. I do another 'M FFEE' to verify the values saved. I exit the monitor and back at the READY prompt I enter POKE 54533,176. It 'restarts' but just back at the C128 mode 40-col screen...doesn't start in CP/M mode.

 

[gerha7]

Using my SD2IEC, I was able to get the good C128 to boot with CP/M. Getting late though. Will take measurements tomorrow to compare voltages on the bad C128 Z80 to the good C128 Z80 running CP/M.

 

[Ozymandias_EBON]

I am very interested to see how this turns out.

I bought my new-to-me C128 +1571 about a week ago off FB Marketplace.
The only issue it seemed to have was the Control Port 2 was stuck going Up.

I ordered a diag cartridge (785260) and harness.
It identified issues with U1 and U4... new chips on order.
It was still able to boot and run programs just fine... until last night.

Now I am getting a black screen with a white vertical line on the left side of the screen (which I think is an artifact of converting from SVideo to HDMI).
The diag cartridge has no effect on the screen display (same black screen and small white line).
My diag cartidge has a voltage display and shows 4.92 on initial power on and then changes to 4.96.

Not saying we have the same issue... but I'm following your path to see if I can find my culprit.

 

[MiaM]

re using the monitor: Maybe you have to select a particular bank. Can't remember the details and whatnot. Also you have to be in a mode where I/O is visible at the $Dxxx area but still have RAM at the $Fxxx area I think. If you have all ram, like the standard bank0/1 mode, the write to $Dxxx won't "take" and if you have all ROM you'd probably just jump to Z80 Kernal code or whatnot, maybe, perhaps? Not 100% sure...

Either way sitting at the prompt in CP/M would probably be good enough for taking measurements. Remember that more or less all I/O is done using the 8502. Newer/modified versions of C128 CP/M does console I/O using the Z80.


==============

Now I am getting a black screen with a white vertical line on the left side of the screen (which I think is an artifact of converting from SVideo to HDMI).

I think that that white line is always there, it's just outside the visible area with most CRT monitors.
In your case a dead test cartridge, or preferably the newer similar but way better one, would be a good idea.
If you happen to have any game cartridge that is known to work on the Max/UltiMax (IIRC Jupiter Lander for example?) you could try that cart.
If your diag cart has dip switches for selecting between different tests then check if you can select any "dead test" cart.

 

[Ozymandias_EBON]

I think that that white line is always there, it's just outside the visible area with most CRT monitors.

Ah! Good to know.

In your case a dead test cartridge, or preferably the newer similar but way better one, would be a good idea.

I have a KFF2, and I can run the deadtest rom on it, but I believe it's not a true dead test cart.
Is there a dedicated 128 Dead Test or is it just the C64 version?
I was looking at this one: https://ebay.us/m/Z7h7Q5

 

[gerha7]

I've taken voltages of the Z80 with CP/M running (at the A> prompt) on the good C128...see updated chart below.

When the good C128 is in C128 mode or running CP/M, the Z80 HALT and INT lines are always high (inactive), but on the bad C128 they're low. The service manual states HALT is active low indicating the Z80 has executed a HALT instruction and is awaiting some kind of interrupt before execution can continue....while in the HALT state it just executes NOPs. Well, the INT is low as well...driven by "external devices".

Not sure what this means...seems like the Z80 is waiting for instructions that never arrive....or a defective Z80?

 

[MiaM]

HALT ending up somewhere between 5V and 0V indicates to me that it's probably switching between Z80 and 8502 mode. Perhaps CP/M is constantly calling an "is there anything in the input buffer" routine that ends up switching to 8502 mode to call the regular C128 mode Kernal to do that I/O?

Maybe get some version of BASIC for CP/M (or any other language for that sake) and run a long empty FOR NEXT loop that just eats up time/cycles?

P.S. for readability maybe add an underscore in front of or after the signal name in your table for the active low singnals?

 

[gerha7]

Updated the Z80 voltage compare chart with control line notation (used a forward slash since an underscore may be misread as an overscore for the letters below). Also attached the scope readings of pins 16 (INT) and 18 (HALT) on the good C128 running CP/M (80-col mode) and bad C128. The HALT line (pin 18) on the good C128 looks to be pulsing (1.023 MHz) but looks consistently low on the bad C128.

 

[MiaM]

My gut feeling says that CP/M just calls the C128 mode Kernal to wait for a key press, kind of sort of, perhaps?

 

[cjs]

The scale is different (Sa/s and horizontal time scale), not sure why that happened. I press my scope's 'Auto' button for each pin reading.

It's the 'Auto' button that's the problem. If a signal is changing between low and high during the reading, it will set a vertical scale that will clearly show the ~0V level and 3-5 V level (whatever high is for that particular signal). If it's consistently low, it will set a vertical scale that will clearly show you the noise around 0 V (perhaps, giving a clear waveform ranging from -0.2 to +0.2 V), which is just hard to read because the noise isn't important. Similar issues arise with the horizontal scale.

When doing these measurements, I'd suggest you not use auto mode, but instead always set your vertical scale to, say, 2 V/division, so that both you and we will find it easier to see at a glance what the signal level is, without having to look at the scale setting and/or the measurements to figure out if we're looking at an actually changing value or just noise.

For the horizontal setting, I would start with 10 μs/division (or maybe even higher); this will easily show you signals changing once every few dozen clock cycles, and you can decrease that ("zoom in") if it's changing quite quickly and you need to see more detail about when it's changing. Whatever you use for horizontal scale, use the same for both the working and the broken C64.

 

[gerha7]

Thanks @cjs it makes sense, I should have looked that closer. I assume the settings you suggested would provide what a logic probe would provide...high, low, pulse. I also changed my scope setting to be DC coupling. I've updated the table to show each pin's reading with 2V/division (vertical) and 10 μs/division (horizontal). The differences are highlighted in yellow.

Again, INT (pin 16) is always low (active) on the bad C128 so not sure what would be causing that...I'll have to look at the schematic to see where it leads.

Also, for RD (pin 21) they both oscillate but the bad C128 max volage is 3.66V but the good C128 gets to 4.4V. Not sure if that's an issue.

 

[cjs]

I assume the settings you suggested would provide what a logic probe would provide...high, low, pulse.

Right! Except that, being on a 'scope screen, you also get a sense of what kind of plus it is, and you can see if things are going "non-digital" (e.g. sometimes sitting at intermediate levels, or getting really noisy).

I also changed my scope setting to be DC coupling.

Oh, yes! I hadn't noticed that you were AC-coupled, but you definitely want to be DC-coupled or a continuous high signal will look low. (Though those last four images are all DC-coupled, right?)

I've updated the table to show each pin's reading with 2V/division (vertical) and 10 μs/division (horizontal). The differences are highlighted in yellow.

That's a great table, and gives some good clues. In particular:

Again, INT (pin 16) is always low (active) on the bad C128 so not sure what would be causing that...I'll have to look at the schematic to see where it leads.

/INT always asserted is almost certain to keep things from working, so that's a good thing to track down.

Also, for RD (pin 21) they both oscillate but the bad C128 max volage is 3.66V but the good C128 gets to 4.4V. Not sure if that's an issue.

That is in theory ok, since a TTL "on" level is anything over 2.8 V, and it's quite normal in TTL systems for "on" signals to be under 4 V all over the place. But it is slightly worrisome that in two systems that are supposed to be identical the same signal is at different levels. But maybe not too worrisome, since TTL "on" outputs can often vary a bit in voltage depending on other loads on the chip. On a MOS 6502, for example, you'll see the "on" levels for address lines vary a bit depending on how many address lines are "on."

 

[gerha7]

Oh, yes! I hadn't noticed that you were AC-coupled, but you definitely want to be DC-coupled or a continuous high signal will look low. (Though those last four images are all DC-coupled, right?)

Unfortunately, no. On post #73 and others before it, it was AC-coupled. At the very bottom left of my scope's screen, it shows channel 1, volts/div and coupling setting.

 

[cjs]

At the very bottom left of my scope's screen, it shows channel 1, volts/div and coupling setting.

Ah, I see now! I was looking at the wrong bit of the screen.

 

[gerha7]

Desoldered the 8502 IC's in both C128's, socketed them and put the 8502 from the bad C128 into the good C128. The good C128 started up fine and passed diagnostic test and dead test. So it's not the 8502. I assume the next one to swap is the Z80. But before I do that, I'll keep looking at other sources/causes as to why the interrupt (Z80 pin 16) stays low or is almost always low. Not looking forward to soldering the bodge wire to the socket.