Some advice debugging a Z80 system (Jupiter Ace)

212 views
Skip to first unread message

John Kennedy

unread,
Jul 3, 2021, 8:09:14 PM7/3/21
to retro-comp
Hi -

I've built a Jupiter Ace on an original PCB, but it's not quite working. Close but no cigar.

(The Jupiter Ace is a 1980's UK computer, based on a Z80 and rather like a ZX81 in hardware spec, although with different video generation - RAM for character sets as well as screen - and no ULA, but 28 TTL 74LSxxx chips).

The components I used are as close as I can find (definitely not CMOS) with the exception of a replacement for the power regulator. I am using a built-for- ZX81 video modulator which is making a nice, clear display.

When powered up, the screen is filled with nonsense, although pressing the keys does something close to what a real Ace does, so this makes feel good about the ROMs.
I've compared the clock signal to that on a working Ace, so I think that part is good too.

The display is sometimes indicative of corrupt character set memory, as well as screen memory. The system memory also seems messed up, as although I can tell that I am entering code, it gets corrupted and does not execute. i.e. RAM is sort of working, but not quite.

I have swapped out the RAM chips with different brands many times with no change.

Here is the clock comparison with a working Ace, and a typical video display:

jupiterstatus.png

One thing I did find - the data lines are very noisy indeed. Here's some snaps of the data lines compared with an address line on the same system. What's going on here? 

SDS00017.BMP
 
and compared to the clock:

SDS00020.BMP

Any suggestions for advice to what to look for very welcome!

-John

Bill Shen

unread,
Jul 3, 2021, 9:17:35 PM7/3/21
to retro-comp
Data lines are generally noisy, but when I see data settling to 1.5V point, or not all the way to ground, or not reaching 5V, I think of data contention.  You must have multiple sources that can drive the data line and one or more is turning on at the wrong time.  The fault is likely the control lines (enable, direction).  Check the control lines visually or with scope or remove one or more data drivers to see if the data bus clean up.  Another debugging method is watch the scope traces and at the same time push down or wiggle individual IC with your finger and see if trace characteristic changes.   Most electronic problems are mechanical.
  Bill

John Kennedy

unread,
Jul 3, 2021, 9:20:16 PM7/3/21
to retro-comp
Thank you Bill, I'll take a look. (The data lines are way noisier that those on a working Jupiter Ace, I should have added).
I will compare the control lines on both systems to check the timing look similar.

John Kennedy

unread,
Jul 3, 2021, 9:45:05 PM7/3/21
to retro-comp
Yup, I think you are onto something, Bill! :-)


WR
SDS00021.BMP

RD
SDS00022.BMP

Blue = working system, Yellow - non-working system

Bill Shen

unread,
Jul 3, 2021, 10:22:02 PM7/3/21
to retro-comp
Ah, much better.  You can trigger on reset going high and monitor the data line immediately after reset.  My guess is data line started off clean like the working system, but then ran into contention when certain devices are access.  On the other hand, if the data is in contention right off reset, then you can remove, one at a time, buffers and RAM until the data lines are clean.
  Bill

John Kennedy

unread,
Jul 5, 2021, 8:22:41 PM7/5/21
to retro-comp
Sadly I have gotten nowhere.. comparing the systems side-by-side very carefully, there is very little difference in the signals.

The only thing I've determined is that I'm using P2114-LC-1 static RAMS, and the working system uses a mix of MM2114N-3L and MM2114-L. Would this make a difference?

-john
Reply all
Reply to author
Forward
0 new messages