Z80 cursor but no text

[albertusj]

I recently built a ZX80 replica and it worked great.

http://www.myprius.co.za/ZX80kit/zx80_cir.gif

Unfortunately, it failed recently. It only produced a blank raster and on the oscilloscope, the video signal timebase would vary wildly. Here is what I've tried so far:
- replaced 7805
- replaced every 74 logic chip
- replaced crystal

Nothing helped. I then borrowed a CPU from a ZX81 I had. It came back to life but now it produced a raster with a cursor but no text. When you press the key for "print" the cursor moves forward as if it printed PRINT but the word itself is missing. There is also no K inside the cursor. Any ideas as to what could be wrong?

I have a spare ZX80 and ZX81 ROM, neither of which it liked. Could it perhaps not be reading the ROM correctly? How are the characters generated?

Thanks

[1024MAK]

Have you checked for any dry solder joints or other poor connectors?

Does very slightly bending or flexing of the board make any difference?

The ZX80 and ZX81 computers actually use the Z80 CPU to generate the video picture with some help from the on board logic chips (in the case of the ZX81, this is the ULA). Anything that results in the Z80 CPU not running the ROM program will cause the video generation to stop, then you will get a blank screen (CRT) or loss of signal screen (some LCDs).

A very simple description (it’s actually even more complex than this description) of the ZX81 system is:

• ROM program (combined OS and BASIC) decides it’s time to display a new video field, so the program counter (PC) is set to the start address of the display file (CPU jumps to this address).
• The CPU then tries to execute the “code” here. It performs its normal read of the RAM, but the ULA ‘steals’ the data byte and then pulls all the data lines to logic low (logic one). So by the time that the CPU actually samples the data on the data bus, it finds the code 0x00, which is a NOP operation code as far as the CPU is concerned.
• The ULA, now having the byte from the display file, now uses this data as an index during the CPU DRAM refresh cycle to read the pixel data from the ROM (the CPU supplying the other bits of the address).
• The ULA grabs the pixel data and loads it into a parallel to serial shift register, then the pixel data is clocked out using the dot clock, hence the pixel data is properly timed to follow the raster (electron gun) in the TV.

The ZX80 is very similar, except that individual TTL 74xxx series logic chips are used to provide the same functionality as the ULA in the ZX81.

In the ZX80
IC9 (74LS165) is the parallel to serial converter that outputs the serial pixel data. So check the signals into and out of this chip.

Also are you using 74LSxxx series chips, or a different range?
And which chips are you using for the Z80 CPU and RAM?

As due to the way that the video system steals the video data byte from the CPU, the timing has to be exact, otherwise it all falls out of step.

Mark

[albertusj]

I'm using as many LS chips as possible. Some I could only get in regular 74, like the 7405s at U15 and U14. I'm testing with a NEC D780C-1 borrowed from a ZX81. U13 had to be a 74HCT04N and one 74HCTLS74 at U18.

The weird thing is that it worked for two weeks, and then suddenly died. I'm getting a new CPU.

Thanks for all the help.

[albertusj]

There is life!

Poking, prodding and a new CPU later. I suspect a via wasn't plated properly. I'm going to re-solder as many of the vias as possible. I can certainly testify to the fact that the ZX80 does NOT like an HC chip in the U9 position. If it is not an LS, it won't work. Also, tapping around U9 produced some video noise so I'm going to re-visit the soldering.

Weird thing is that my video conditioner is dead. Could my monitor have spiked the poor thing?

[RetroTechie]

Welcome to this forum, albertusj!

ZX80 (and -81) need most things to work in order to get anything looking like normal screen output. Behaviour suggests that CPU is working, and both ROM and RAM as well. At least enough that CPU doesn't crash.

At first I thought you might have some timing problem, causing wrong data to be picked up by the pixel shift register (IC9). Something like enabling/disabling the ROM too early or late. Such an issue is still possible btw. But since screen output only changes per character, there's a simpler possibility: that this shift register is clocked with pattern for 8 pixels, but fails to shift out the individual dots. That means: check what happens on pins 2 (dot clock), 15 (clock inhibit) and 1 (load) of IC9. And try blind-typing some special (graphics!) characters, see / post photo of how those are represented on screen.

Also you might want to check operation of other parts of the clock circuit. Basically everything around IC20. I'd be curious what happens to the 6.5 MHz dot clock as it passes from IC20 (pin 3) through C9/R2 network. Also check whether you used the correct values for C9, R2, R27, C15, R20 and C11. What exact type/manufacturer did you use for IC20 and IC9? Like Mark said, ZX80 is very sensitive to component changes. It's more 'analog' in behaviour than a ZX81. Although ultimately, everything digital is analog too.

If you used IC sockets, try to do measurements directly on the IC pins. That way you'll catch IC socket contact issues too.

How are the characters generated?

As a fellow hardware builder once said: "first understand, then build". Seems you skipped that.

So you shouldn't have to ask this question really. You BUILT the thing, dammit! Then you should know how it works. And thus how to fix it. Replacing 'random' components is stupid. Measure, think, conclude, in short: analyse the problem!

I suspect a via wasn't plated properly.

That kind of problem really should have been found by checking the board before soldering in any components. Even brand new pcb boards from respected suppliers have problems sometimes. But okay...

I can certainly testify to the fact that the ZX80 does NOT like an HC chip in the U9 position. If it is not an LS, it won't work.

You could maybe add some pull-up / pull-down resistor(s) in a strategic position to help with the differences in logic levels. But better to put in LS first until everything works.

Weird thing is that my video conditioner is dead. Could my monitor have spiked the poor thing?

ESD damage perhaps? Monitor (esp. CRT) that leaks relatively high amount of current from mains to its circuit GND?

[albertusj]

Thank you for the valuable input. Like an excited puppy, I guess I rushed into the building process without pausing to reflect and think. I'm learning a lot though and having fun.

[albertusj]

To protect my ZX80 I'm thinking of introducing an optocoupler into the video signal path. I can then use the output of the optocoupler and feed into the back porch generator. I'll then give the back porch generator its' own DC supply. I just have to make sure of the input impedance the ZX80 sees.

[1024MAK]

Normally a capacitor is used for coupling.

If you are going to try to use an optocoupler, first, you will need a suitable driver for the LED. Secondly, you best choose a really fast optocoupler.

Mark

[albertusj]

Yeah, I was actually looking at the optocoupler specs with just that in mind. I was wondering about using a capacitor instead. From what I see on the web though about video driving techniques, the series capacitor used is rather large.

[1024MAK]

Yikes! The normal value is 100uF, with a voltage rating of 16V or 25V. Also the system should be powered from a filtered +5V rail.

Just checking, we are both talking about monochrome composite video signals, yes?

Mark