C128 black screen / blank screen

[MiaM]

I'm not sure how the signal is supposed to look like, but to me it looks like it does every second Z80 clock cycle at 4MHz and the other at a lower frequency, to match up with the 6502/8502 bus timing.

Note that the C128 is notoriously slow at running Z80 code, as the Z80 is a an add-on to an almost finished design.

The C128 might even be the only computer with a Z80 that can directly address memory that both acts as screen memory and character definitions. More or less every other Z80 based computer has the character definitions in ROM and/or has a full bitmap mode, but no user definable characters, and/or the graphics memory is indirectly addressed (TMS9918 style).

Also IIRC the C128 only differentiates between fast and slow mode for the 8502, while the Z80 always runs slow enough to fit with the 40 col VIC-II video generation bus cycles.

 

[Eudimorphodon]

The C128 might even be the only computer with a Z80 that can directly address memory that both acts as screen memory and character definitions. More or less every other Z80 based computer has the character definitions in ROM and/or has a full bitmap mode, but no user definable characters, and/or the graphics memory is indirectly addressed (TMS9918 style).

Exidy Sorcerer. Has 2K of screen memory and 128 character’s worth of user defined graphics RAM, circa 1979.

 

[cjs]

The C128 might even be the only computer with a Z80 that can directly address memory that both acts as screen memory and character definitions. More or less every other Z80 based computer has the character definitions in ROM and/or has a full bitmap mode, but no user definable characters....

Far from it. Plenty of computers from 1978 onwards, such as the Sharp MZ-80K and the NEC PC-8001, had a PCG (programmable character generator) option available, and this was built-in on the later machines in those series.

Any time you're about to generalise about late '70s and early '80s home computers, it's worth pausing to check if you've not missed something in the popular series of computers in Japan at the time.

 

[MiaM]

Just realized that I forgot the Microbee too.

If I change what I wrote to use "general purpose" memory for screen memory and character memory, rather than chips that were dedicated to the video hardware, it probably narrows down to the C128 though?
Sure, on a computer like the Microbee you can store programs and data in the character + video RAM, but IIRC those are more expensive SRAM chips and it wouldn't had worked to use the slower DRAM chips in their configuration.

Last attempt at a definition that probably makes the C128 the only one: The only computer where a Z80 shares not particularly fast DRAM with screen and character definitions. I know that this is a really narrow definition, but the purpose is to explain why the C128 uses "weird" clock cycles for the Z80.

 

[gerha7]

My original VIC II chip (U21) is a MOS 8564R5 CA 3785. Suspecting the original VIC II was bad, I bought a used one on eBay (MOS 8564R5C AV 4285). Seller stated it was 'tested and working' but I get the same readings for each one and, of course, no video or garbage video.

Any pointers on where I can buy a VIC II chip that actually works?

 

[cjs]

If two different VIC chips, including one probably tested and working, are both failing, that's starting to point away from that device....

 

[cjs]

Well, I'm afraid we all weren't properly reading page 34 of the Service Manual:

Finally, the last clock is the Z-80 clock, which is a 4 MHz clock that only takes place during the low half of the 1 MHz clock.​

Not to mention further details on page 8:



But just to be sure, today I visited a friend who happened to have his C128 out from the pile at last and captured some actual signals. These are the VIC signals PHI IN (pin 30), Z80 PHI (pin 25) and 2 MHz (pin 23); rough frequency counts for each are given at the bottom of the screen.The first image is in standard 40-column mode at the BASIC prompt; the second is in 80-column mode at the CPM prompt, in case that might be any different (it isn't). Sorry about no capture for fast mode, but I'm not too familiar with the C128 and it didn't occur to me to do that.



So it looks as if both your VICs are fine, and the "Z80 PHI = 2 MHz" problem was just with whatever was generating the frequency count.

 

[Eudimorphodon]

FWIW, this sort of split timing (z80 getting multiple pulses on the offside of phi) is how the conceptually similar Z80 Softcard for the Apple II worked. The Apple II had both a 7mhz (2x colorburst) signal and the 6502’s Phi available on the slot connector, and the Softcard has circuitry to derive a gated 4mhz-ish clock on the downbeats from those two inputs.

 

[cjs]

These are the VIC signals PHI IN (pin 30), Z80 PHI (pin 25) and 2 MHz (pin 23);

Wait a second. I just realised that I'm seeing an ~1 MHz signal from pin 23, rather than ~2 MHz. That's not just based on the measurement; the time base (time per grid square, seen in the "H" section on the top line) is clearly 0.5 μs, with one half cycle of the waveform per grid square. However, I am pretty sure the probe was one pin from the end on the pins 1-24 side of the IC. So that's mysterious.

It's also been bugging me that the Z80 PHI signal measures as ~4 MHz. That's correct given the definition in the manual (page 138): "Period: defined as the time between the middle threshold points of two consecutive, like-polarity edges" and "Freq: defined as the reciprocal of period." The first two rising edges after my trigger point are ~0.25 μs apart; presumably using a trigger delayed by 0.15 μs after the first rising edge on that waveform would cause the measurement to change to ~1.5 MHz. But if we took the measurement as, say, the actual number of cycles or rising edges over the course of a second, it would measure as ~2 MHz. Is there some sort of standard for measuring waveforms with an odd duty cycle (if that's the correct term) like this? Certainly the processor itself is effectively running at what could only reasonably be called "~2 MHz," since it will do only ~2M T-cycles per second, right?

 

[gerha7]

Quick note: Thanks everyone for helping out on this. I'm incredibly grateful for all the time dedicated to this issue.

Regarding the VIC II pin 23, page 35 of the service manual states that pin 23 is the 'changing' system clock which will be either 1 or 2 MHz. I'm wondering if this refers to 1MHz in C128 slow (default) mode, and C128 fast mode. Looking at the C128 System Guide documentation and using the Vice C128 emulator, upon power-up (C128 40-column mode) if you type FAST it will blank the video display and run at 2MHz, then type SLOW (you won't see what you type) and RETURN and it puts it back to 1MHz mode and displays 40-col video again. Therefore, I assumed pin 23 was operating as normal...or not as high of a priority to pursue. I tried to enter FAST while measuring pin 23 but not change, still shows 1.022 MHz but that may be caused by whatever issue it is causing nothing or garbage to display.

Just a guess, but I feel the next most probable suspect is the Z80, since it has to go thru its start-up chores before it turns over control to the 8502. I don't get consistent readings from pin 43 (Z80EN) on the MMU. For a while it always measured low, which indicates Z80 mode. But recently it's been a mix of both. So I don't know if the Z80 is bad or if something else is bad (PLA, MMU, RAM IC's) that doesn't allow it to start-up cleanly to turn over control to the 8502.

Also, since it's been almost 8 months working on this thing, I finally decided to get at new testing tool...another C128 that works. : ) Most all of the troubleshooting steps I've followed in the diagnostic manual usually ends up with 'testing by substitution.' Which I was not able to do, so I could never claim any real progress by declaring 'I know for sure this chip works'.

I should get the machine this week so I'm chomping at the bit to see what normal readings are in plain C128 40-column slow mode, then start substituting IC's.

 

[cjs]

...pin 23 is the 'changing' system clock which will be either 1 or 2 MHz. I'm wondering if this refers to 1MHz in C128 slow (default) mode, and C128 fast mode.

Ah, that explains why I was seeing 1 MHz there. Yes, the "2 MHz" pin directly feeds ΦIN on both the 8502 CPU and the 8722 MMU (and nothing else). Well, that at least nicely shows how bad naming can waste other developer's time.

I don't get consistent readings from pin 43 (Z80EN) on the MMU. For a while it always measured low, which indicates Z80 mode. But recently it's been a mix of both.

Well, which you see depends on which CPU you expect to be running at that particular moment. I am not sure if the Z80 turns things over to the 8502 in one step, or if it may get it started and then use it to make some BIOS calls while it does its own thing (i.e., switching back and forth) before it finally decides it's going to boot the Commodore system instead of CP/M.

 

[MiaM]

The source code for the Kernal, including the Z80 part, is out there if you want to check out exactly what the Z80 does and how it turns over operations to the 8502.

IIRC it really only does a few very basic things, i.e. check the cartridge port pins to potentially switch to C64 mode, and not much more before switching to 8502 mode. Remember that the C128 and almost all other multi processor systems with a Z80 starts in Z80 mode due to a hardware bug / undocumented behavour in the Z80 that causes it to do weird bus cycles if it's not allowed to go through with it's reset procedure. I.E. the checking of the pins on the cartridge port to switch to C64 mode is kind of an backsplanation of sorts; the 8502 could had done that test about as fast as the Z80 if there wouldn't had been a Z80 at all.

 

[ClassicHasClass]

The Z80 hands off to the 8502 very early, after the expansion port and Commodore key check. The boot sector check, for example, is done by the 8502 (if it's a CP/M disk, the boot sector code instructs the 8502 to hand control back to the Z80 to enter CPMLDR).

Remember that the C128 and almost all other multi processor systems with a Z80 starts in Z80 mode due to a hardware bug / undocumented behavour in the Z80 that causes it to do weird bus cycles if it's not allowed to go through with it's reset procedure. I.E. the checking of the pins on the cartridge port to switch to C64 mode is kind of an backsplanation of sorts; the 8502 could had done that test about as fast as the Z80 if there wouldn't had been a Z80 at all.

While that's all true with the Z80, the official reason (we report, you decide) is to deal with 64 cartridges that alter expansion port lines in realtime, most notoriously ones like Commodore's own Magic Voice. The Z80's startup code isn't affected by those lines, so it can still get the machine into 64 mode if the Commodore key is down no matter what skulduggery is occurring on the cartridge side.

 

[Eudimorphodon]

It's also been bugging me that the Z80 PHI signal measures as ~4 MHz. That's correct given the definition in the manual (page 138): "Period: defined as the time between the middle threshold points of two consecutive, like-polarity edges" and "Freq: defined as the reciprocal of period." The first two rising edges after my trigger point are ~0.25 μs apart; presumably using a trigger delayed by 0.15 μs after the first rising edge on that waveform would cause the measurement to change to ~1.5 MHz. But if we took the measurement as, say, the actual number of cycles or rising edges over the course of a second, it would measure as ~2 MHz. Is there some sort of standard for measuring waveforms with an odd duty cycle (if that's the correct term) like this? Certainly the processor itself is effectively running at what could only reasonably be called "~2 MHz," since it will do only ~2M T-cycles per second, right?

The next section after the "time" definitions talks about "count values", is there a button you can punch on the scope to get a "counts per second" on that channel? I kind of suspect what the scope is "thinking" is it's looking at something like an SPI bus channel, where it's decided the "clock" is 4mhz because that's the minimum peak-to-peak time it's observed (on those pairs you get during the low periods of the 1mhz clock). If you imagine this signal being something like a 0,2 RLL encoded serial signal it would be completely legit to say it was "4mhz" regardless of the actual number of "1s" in any given period. Duty Cycle in this context would generally refer to an instance where the width of the high and low *halves* of the pulses is consistently different. (IE, a well known example is how the intel 8284 clock generator used in 8086/8088 machines had a 33/66% duty cycle and the datasheet for the HMOS CPUs likewise specifies different minimum times for the high/low halves of the cycle.) Presumably the scope would identify that situation correctly.

What we're seeing here is, from the Z80's point of view, an edge case of "cycle stretching", IE, where you usually run at X mhz, but under certain conditions you hold the CPU high or low for an unusually long time in order to deal with slow/contended memory or whatever instead of using wait states, making the effective clock rate X * (the percent of time you're actually running). The C128 and Z80 softcard are just cycle-stretching every other clock cycle instead of doing it irregularly, resulting in this 50% "hit" that's constant instead of intermittent. I'm not sure if this is a common enough situation for the scope to be expected to automatically recognize it.

 

[MiaM]

While that's all true with the Z80, the official reason (we report, you decide) is to deal with 64 cartridges that alter expansion port lines in realtime, most notoriously ones like Commodore's own Magic Voice. The Z80's startup code isn't affected by those lines, so it can still get the machine into 64 mode if the Commodore key is down no matter what skulduggery is occurring on the cartridge side.

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 next section after the "time" definitions talks about "count values", is there a button you can punch on the scope to get a "counts per second" on that channel? I kind of suspect what the scope is "thinking" is it's looking at something like an SPI bus channel, where it's decided the "clock" is 4mhz because that's the minimum peak-to-peak time it's observed (on those pairs you get during the low periods of the 1mhz clock). If you imagine this signal being something like a 0,2 RLL encoded serial signal it would be completely legit to say it was "4mhz" regardless of the actual number of "1s" in any given period. Duty Cycle in this context would generally refer to an instance where the width of the high and low *halves* of the pulses is consistently different. (IE, a well known example is how the intel 8284 clock generator used in 8086/8088 machines had a 33/66% duty cycle and the datasheet for the HMOS CPUs likewise specifies different minimum times for the high/low halves of the cycle.) Presumably the scope would identify that situation correctly.

Yeah, IMHO it's actually kind of bad that the oscilloscope displays some sort of average frequency for something that from an analogue perspective jitters incredibly between two frequencies. Also from an analogue perspective, I think that you wouldn't really see any meaningful signal if you try to tune a shortwave receiver to the 2.x MHz frequency the oscilloscope displays. I.E. I doubt that a shortwave receiver would detect more signal strength at that frequency than at other adjacent frequencies. But it would for sure detect something at 4MHz and at 1MHz.

Btw this kind of shows that the Z80 is somewhat of a cludge, as both the Z80 and the 80 col video hardware would had been part of the design from day one, the Z80 would run faster with the 40 col video switched off, but afaik it doesn't.

 

[Eudimorphodon]

Btw this kind of shows that the Z80 is somewhat of a cludge, as both the Z80 and the 80 col video hardware would had been part of the design from day one, the Z80 would run faster with the 40 col video switched off, but afaik it doesn't.

Commodore sold a Z80 cartridge for the C64, my vague impression was that the Z80's integration into the 128 was mostly unchanged from what they did in that cartridge. (Which seems to be much the same, again, as the Apple II's; they take the ~8mhz dot clock, divide it in half for ~4mhz, and then gate it with Phi.)... Which, leads on to this: According to Bil Herd (see the linked newsgroup post) the Z80 was *not* part of the original design of the machine that became the C128. According to Herd the mandate was to try to make the machine "100% compatible" with the C64, but they kept running into all these problem children among existing C64 peripherals, one of which happened to be the Z80 cartridge. (Herd says the cartridge wasn't even compatible with all C64s.) By designing the Z80 into the board they could knock that one off their list because with it onboard it became redundant and... again, per Herd, having it there also gave them a magic get-out-of-jail free card for solving problems with some even ruder peripherals, like the Commodore Speech cartridge.

Anyway. Sure, if they *had* designed the computer completely around the Z80 from day one it would have been a silly omission to not allow the Z80 to run at full blast, but... taken in context, well, what they did makes sense. The implementation as it is technically checks the box of being fully compatible with a C64 *with the Z80 cartridge plugged in*. I mean, sure, there was probably all of one guy on the entire planet that would have been upset if he couldn't use C64 CP/M with SOFT80 to display a really terrible 80 column screen via the VIC-II, but it's a thing that would have been locked out if they forced the VIC-II to go to sleep when the Z80 was on. And, sure, they could have added circuitry to make it able to switch, but if the Z80 integration really was the late addition as described it at the least probably would have required another silicon revision for the custom chips. It's not as if such a change would have realistically had much of a chance of selling many more machines; CP/M-80 was dead as a mainstream OS, at least in the US, by the time the C128 came out. I don't think it being able to run it twice as fast would have made much of a difference.

(* It's an oft-told tale that the Apple II was the "best selling CP/M machine in the US" for a year or two around 1981. The Z80 Softcard actually ran slightly slower than the Z80 in the C128; a few people mildly grumped about it, but there were still enough 2Mhz 8080 machines in circulation that such performance wasn't *unusually* pitiful. The early Kaypros, an even more recent machine, ran at 2.5mhz. Keep in mind that most of the software people would have run on a C128 under CP/M would have been written when, or even before, these machines were "typical" CP/M mules, because of how the CP/M software market was basically frozen in amber by 1985. In that light, well, doesn't seem like making the C128 faster would have been a real high priority.)

 

[Eudimorphodon]

Yeah, IMHO it's actually kind of bad that the oscilloscope displays some sort of average frequency for something that from an analogue perspective jitters incredibly between two frequencies.

Well, like I said, what it does is perfectly reasonable if you think about the frequency being the clocking frequency of something like a serial transmission. If I put these probes onto something like an SPI conversation that would actually be useful information to me; some random rapidly fluxxing number based on the data contents would not be. Sure, there would be a use case for a separate "counts per second" that tells you the number of beats in a period separate from their frequency, which is why I'm wondering if the scope might actually have a button somewhere for that. (I have a "smart scope" myself, but it's a Siglent, not a Rigol, and I also haven't used it anywhere near enough to know off the top of my head if that's a function it has.)

I mean, in the end it is a *scope*, so in a case like this it's pretty easy to grok what it's doing from the picture. I suppose what would be more interesting is knowing how long the zero pauses could be before it decides that frequency based on two adjacent pulses was no longer "typical" enough to call the frequency.

 

[cjs]

Yeah, IMHO it's actually kind of bad that the oscilloscope displays some sort of average frequency for something that from an analogue perspective jitters incredibly between two frequencies.

Well, like I said, what it does is perfectly reasonable if you think about the frequency being the clocking frequency of something like a serial transmission.

You two are talking about entirely different things. Though MiaM didn't mention it, he's clearly not discussing the images I posted (which have no measured frequencies around 2 MHz in them whatsoever), but the earlier one from a different 'scope.

Now that I know what the Rigol is actually measuring when it measures "frequency," I'm happy enough with it. (Hell, they even got the little diagram on the screen about as clear as could be for that measurement.) Regarding the other 'scope, I disagree with MiaM's "kinda bad" evaluation, though perhaps in a subtle way: the measurement may be "kinda bad," but it's no worse than mine: both 'scopes get the period wrong as the repeated waveform for each period is actually .25 μs high, .25 μs low, .25 μs high, 1.25 μs low, giving a frequency of 1 MHz. (This proper mathematical definition is generally not what engineers are looking for when looking at such a waveform, though!)

The real problem is that the Service Manual just doesn't do a good job of defining what it means about what that waveform should be. "4 MHz" without any qualifications is easily misleading.

The next section after the "time" definitions talks about "count values", is there a button you can punch on the scope to get a "counts per second" on that channel?

It seems there is, though it's not clear from the manual how that works. Next time I happen to have an appropriate waveform available, I'll try out the counts measurements and see exactly what they do. Thanks for pointing that out.

 

[Eudimorphodon]

It seems there is, though it's not clear from the manual how that works. Next time I happen to have an appropriate waveform available, I'll try out the counts measurements and see exactly what they do. Thanks for pointing that out.

If you find it let us know. I might look into whether the Siglent can do it because I was actually doing something kind of similar to this with a Homebrew circuit a few years ago. (I built a video circuit that did multiple fetches against shared memory inside of one low period of a 6502 clock; if you scoped the video fetches against phi it would look very similar to the C128’s traces, but even weirder because the video reads were effectively clocked 8 times faster, not four.) I was still using an analog Tektronix at the time, so any frequency measurement was eyeballing traces against the divider marks.

 

[Eudimorphodon]

Though MiaM didn't mention it, he's clearly not discussing the images I posted (which have no measured frequencies around 2 MHz in them whatsoever), but the earlier one from a different 'scope.

I guess I missed that earlier picture, that we were comparing scope A with scope B kind of got lost in translation there...

But now I *am* wondering what my Silgent would do in this situation, give me an output like the Rigol's or like that other scope. I might need to, just for laughs, specifically synthesize this situation and see what I get.