Subject: That pesky Jupiter Ace *still* won't work...

From: Philip Pemberton <[email-masked]>
Date: Tue May 27 07:38:47 2003

Hi,
  I've just finished fixing the Ace's PCB using wire-wrap wire. All the
broken tracks I've managed to find have been fixed and all the damaged
through-hole plating has been repaired. Except there's one problem. The Ace
*still* won't boot to the FORTH interpreter.
  There is a load of garbage on the display - this seems to change while the
machine is running. The power consumption of the board - CPU and all - is
around 800mA (according to the crappy meter on my Farnell 1A bench PSU). I've
got the output on the PSU set to 9V, no current limit.
  Does anyone here have a logic analyser or microprocessor debugger that I
could borrow for a few days? I've got two scopes (a Tek 466 and a Gould
OS1100) and a Fluke 25 multimeter, but that's about it in terms of test
equipment.
  Alternatively, does anyone know if a diagnostic ROM exists for the Ace?
Something that would replace ROM A and just load the video/font RAM with the
usual Ace character set would be very handy.
  The 2114Ls I'm using appear to be OK, but they draw a lot of current - in
the region of 75 to 100mA each.

Thanks.
-- 
Phil.
[email-masked]
http://www.philpem.dsl.pipex.com/

---

From: [email-masked] (Tony Duell)
Date: Wed May 28 01:31:36 2003

> *still* won't boot to the FORTH interpreter.

Argh!. There aren't that many chips in the machine...

>   There is a load of garbage on the display - this seems to change while the

Garbage as in random dot patterns, or garbage as in characters? Is it 
loading the character generator at all?

> around 800mA (according to the crappy meter on my Farnell 1A bench PSU). I've

DOesn't sound excessive...

> could borrow for a few days? I've got two scopes (a Tek 466 and a Gould

Where are you in the country? I am not lending out any of my test gear (I 
depend on it too much!), but if it's physcially possible for us to get 
close together, I can have a quick look and wave some probes over it...

> usual Ace character set would be very handy.

I believe the normal ROMs do that early on anyway.... I've never heard of 
a diagnostic ROM for the ACE

> the region of 75 to 100mA each.

YEs, they do eat current...

-tony

---

From: Philip Pemberton <[email-masked]>
Date: Wed May 28 08:32:05 2003

> Argh!. There aren't that many chips in the machine...
I know...
I also know that the repairs to the through-hole plating for the main RAMs, 
buffers and video RAMs are fine.
That leaves the possibility of:
  A) Dead RAMs
  B) Dead LS buffers
  C) Dead ROMs
  
I can pretty much discount C - the ROMs work fine in my Preprom - even at
4.5V (it's a so-called "Production Grade" programmer - the multilevel verify 
can be disabled, though).

> loading the character generator at all?
Random dot patterns. It doesn't look like the chargen is getting loaded at
all.

> close together, I can have a quick look and wave some probes over it...
I'm in Leeds, West Yorkshire.

> a diagnostic ROM for the ACE
They load the chargen *after* testing the main RAM. If the main RAM test (or
another part of the POST) fails, the Ace won't even load the chargen. If I
had designed the firmware, I'd have made it load the CG RAM, clear the VRAM
and then run a selftest. If the selftest fails, display an error. Simple.
Instead, I get the dubious pleasure of re-learning Z80 assembler and hacking
together a diagnostic ROM...

I'll try monitoring the RAMSEL, etc. pins on the LS138. I think there's a
bus conflict somewhere because the CPU, EPROMs and RAMs are getting quite
hot... I'll try and track down a thermometer later. I know there's a
DS18S20 DirectDigital sensor around here *somewhere*...

Later.

---

From: Philip Pemberton <[email-masked]>
Date: Thu May 29 08:50:00 2003

I'm beginning to wonder... Does anyone know what clock frequency the Ace runs
at? The RAMs I'm using are Toshiba TMM214APL-1 (2114L-2) chips. The EPROMs
are Texas Instruments TMS2732s, part number TMS2732-45 -- 450nS rated. Is it
likely that the Ace is acting up because the ROMs aren't updating their data
outputs fast enough? By my reckoning, 1MHz = 1uS or 1000nS. 2MHz = 0.5uS or
500nS. ISTR the Ace ran at 1.8432MHz, which should still be in spec for the
ROMs...
I've just checked the address lines going to the RAMs. I now have a list of
which CPU pin connects to what RAM line. There are no shorts to Vcc or Gnd on
the board, so I think I can rule out a bus conflict, unless the inputs to the
LS138 decoder are screwed up... I think more testing is in order. Now where's
that Tek gone...

Later.

---

From: [email-masked] (Tony Duell)
Date: Sat May 31 18:33:33 2003

> That leaves the possibility of:

Didn't you have a relatively high -ve voltage on a data line? If so, you 
might well have killed a buffer chip...

> I'm in Leeds, West Yorkshire.

Argh... Too far from me in London, then.

-tony

---

From: [email-masked] (Tony Duell)
Date: Sat May 31 18:34:47 2003

> 500nS. ISTR the Ace ran at 1.8432MHz, which should still be in spec for the

This rather depends on how many clock cycles there are in a RAM cycle (or 
more precisely, between the time the last memory control signal is 
stable, and the time tha the data is read). This is not necessarily just 
one clock cycle.

> the board, so I think I can rule out a bus conflict, unless the inputs to the

A short between 2 address or data lines? 2 chips enabled simultaneously 
(address decoder problem)?

-tony

---

From: Philip Pemberton <[email-masked]>
Date: Sat May 31 18:39:08 2003

> might well have killed a buffer chip...
They've all been replaced with new chips, though... Guess I've got the
dubious pleasure of looking for dead buffers and shorts...

Later.

---

From: [email-masked] (Tony Duell)
Date: Sat May 31 18:40:44 2003

> dubious pleasure of looking for dead buffers and shorts...

So what haven't you replaced yet? That could be a good starting point for 
what still might be blown...

-tony

---

From: Philip Pemberton <[email-masked]>
Date: Mon Jun 2 07:57:21 2003

> what still might be blown...
Only the components from the video timing chain.
It is possible that some of my repairs to the board may have shorted out.
These repairs were concentrated around the RAMs, more or less. $DEITY knows
how I'm going to test for that...

Later.

---

From: [email-masked] (Tony Duell)
Date: Mon Jun 2 07:57:33 2003

> Only the components from the video timing chain.

You have a 'scope, and the outputs of the timing chain should be pretty 
regular, so it's not hard to ensure it's clocking correctly... You have 
checked the CPU clock, etc, are presnet, right?

> how I'm going to test for that...

An ohmmeter ?  :-)... Check for shorts between adjacent pins/tracks, and 
the like

More seriously, look for signals on RAM pins that don't look like clean 
TTL signals. If you find any, make sure you have not got 2 signals 
shorted together.

You mentioned earlier that the ACE only loads the chargen after checking 
program RAM, etc. What does it do if the test fails? HALT? Goes into a 
tight loop? Can you see if it's getting there with the 'scope (if it's a 
tight loop, most of the address pins should be static, at least during 
MREQ cycles).

-tony

---

From: Philip Pemberton <[email-masked]>
Date: Mon Jun 2 07:57:37 2003

> checked the CPU clock, etc, are presnet, right?
I can't see why the timing chain could be at fault. The master clock (for the
Z80) is running, the sync signals (which require pretty much ALL of the
signals from the TIC to be working) are OK...

> > These repairs were concentrated around the RAMs, more or less. $DEITY
> > knows how I'm going to test for that...
Even better - a Fluke 25 on "Diode Vf/Continuity Beep" mode.

> TTL signals. If you find any, make sure you have not got 2 signals  shorted
> together.
I'll have a look at that over the next few weeks. Some of the data signals
looked a bit "dirty" (electrical noise?)...

> tight loop, most of the address pins should be static, at least during 
It looks like I misunderstood the code - it stores 0xFC in every byte,
starting from the bottom of the main RAM, until the byte it reads back is not
equal to 0xFC. It then rounds the RAM count down to the nearest kilobyte.
Obviously, if it thinks the RAM isn't set up right, the stack is going to get
pretty badly fudged. That shouldn't stop it from loading the CHG though...
My money's on a short circuit somewhere in the VRAM circuitry.

Later.

---

From: [email-masked] (Tony Duell)
Date: Mon Jun 2 07:57:51 2003

> signals from the TIC to be working) are OK...

Sounds as though the timing chain is fine, but it can't hurt to check it.

IIRC there's some kind of multiplexer between the timing chain and the 
video RAM address lines (I can't remember if this is a real mux, or one 
of the Jupiter Ace type ones [1]). Maybe worth checking that's OK.

In fact have you checked you have some activity at all the address and 
data pins of all the RAMs? If you see a pin that looks 'stuck' it would 
be worth investigating.

[1] A vile idea of putting a 1k resistor in series with a TTL output and 
then coupling it to a 3-state output. If the 3-state output is 'off' then 
the other (totem-pole) output drives the line via the 1k resistor. If the 
3-state output is 'on', then it overrides the signal coming via the 1k 
resistor...

> equal to 0xFC. It then rounds the RAM count down to the nearest kilobyte.

Right. What does it do if it finds no valid RAM?

> pretty badly fudged. That shouldn't stop it from loading the CHG though...

Are you sure no stack or data memory is needed for this...

> My money's on a short circuit somewhere in the VRAM circuitry.

For it to load the chargen, the Wr/ and CS/ signals to the chargen RAM 
must be asseted at the same time, right? Can you attempt to detect this 
with the 'scop, maybe with an external OR (or NOR) gate? If you can 
trigger on that [2]  (assuming a good 'scope [3]), then maybe you can 
look at the data going into the chargen, etc.

[2] A useful trick, I don't rememebr where I learnt it, is to pulse the 
reset line at a few 10's of Hz. Slow enough that the machine does 
something after each reset, but fast enough that you get repetitive 
signals to look at on the non-storage 'scope.

[3] A delayed timebase is very useful here....

-tony

---

From: Philip Pemberton <[email-masked]>
Date: Tue Jun 3 08:16:32 2003

> Sounds as though the timing chain is fine, but it can't hurt to check it.
Agreed.

> of the Jupiter Ace type ones [1]). Maybe worth checking that's OK.
Will do. You're right about it not being a real mux - a couple of 1k carbon
resistors and a tristate buffer. YUCK!

> data pins of all the RAMs? If you see a pin that looks 'stuck' it would 
OK.

> > starting from the bottom of the main RAM, until the byte it reads back is
> > not equal to 0xFC. It then rounds the RAM count down to the nearest
> > kilobyte.
I have no idea... Looks like it'll set RAMTOP (?) to 0, thereby screwing up
any and all further RAM calculations.

> > Obviously, if it thinks the RAM isn't set up right, the stack is going to
> > get pretty badly fudged. That shouldn't stop it from loading the CHG
> > though...
Er... No. My Z80 is rusty. VERY rusty...

> with the 'scop, maybe with an external OR (or NOR) gate?
I'll have to snaffle a 40-series gate from my junkbox but it should be
possible. I'll need to find a set of probes as well...

> If you can  trigger on that [2]  (assuming a good 'scope [3]), then maybe
> you can  look at the data going into the chargen, etc.
On a dual-channel scope? Hmm... That's going to be fun...

> signals to look at on the non-storage 'scope.
Right. I'll grab a 555 from the junkbox as well.

> [3] A delayed timebase is very useful here....
The 466 has a dual timebase with a Delay mode so I guess there's no problem
there.

Later.

---

From: [email-masked] (Tony Duell)
Date: Tue Jun 3 09:00:44 2003

> resistors and a tristate buffer. YUCK!

I thought it might be... Yuck (or Bletch!) is right :-)

> Er... No. My Z80 is rusty. VERY rusty...

Well, the stack is needed for CALL (or more strictly RET, in that a CALL 
will get to tthe right place without the stack, but you'll never get back) 
instructions, certainly. Does it call any subroutines (or use RSTs) 
before loading the chargen?

> possible. I'll need to find a set of probes as well...

4000 series CMOS may well not be fast enough for this -- you should get a 
74LS32 or 74LS02, I think. You don't wnat problems caused by the test set-up.

In cany case, just chack that the CS/ line is not always asserted 
(grounded). It might well be for something like the chargen or video 
memory, since those are read out continuously to produce the display. If 
that is the case, you just need to trigger on the Wr/ signal at the RAM 
(which will be a combination of the Z80's Wr/ signal, the output from an 
address decoder, and so on).

> On a dual-channel scope? Hmm... That's going to be fun...

Well, if one bit is loading correctly it'll be a start...

> Right. I'll grab a 555 from the junkbox as well.

Indeed :-)

> The 466 has a dual timebase with a Delay mode so I guess there's no problem

Oh, if you have a Tektronix with 2 timebases and the delay time 
multiplier control you'll be fine ;-)

-tony