26 May
2003
26 May
'03
10:26 p.m.
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.
philpem(a)dsl.pipex.com
http://www.philpem.dsl.pipex.com/
27 May
27 May
11:03 a.m.
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.
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?
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
DOesn't sound excessive...
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
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...
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.
I believe the normal ROMs do that early on anyway.... I've never heard of
a diagnostic ROM for the ACE
The 2114Ls I'm using appear to be OK, but they
draw a lot of current - in
the region of 75 to 100mA each.
YEs, they do eat current...
-tony
7:49 p.m.
In message <m19Kn8R-000IznC@p850ug1>
ard(a)p850ug1.demon.co.uk (Tony Duell) wrote:
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).
*still*
won't boot to the FORTH interpreter.
Argh!. There aren't that many chips in
the machine... Garbage as in random dot patterns, or garbage as in
characters? Is it
loading the character generator at all?
Random dot patterns. It doesn't look
like the chargen is getting loaded at
all.
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...
I'm in
Leeds, West Yorkshire.
I believe the normal ROMs do that early on anyway....
I've never heard of
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.
--
Phil.
philpem(a)dsl.pipex.com
http://www.philpem.dsl.pipex.com/
28 May
28 May
10:25 a.m.
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.
--
Phil.
philpem(a)dsl.pipex.com
http://www.philpem.dsl.pipex.com/
30 May
30 May
10:37 a.m.
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
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.
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
A short between 2 address or data lines? 2 chips enabled simultaneously
(address decoder problem)?
-tony
10:35 a.m.
*still* won't boot to the FORTH interpreter.
Argh!. There aren't that many chips in the machine... 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...
I'm in
Leeds, West Yorkshire.
11:08 p.m.
In message <m19LrzA-000IzIC@p850ug1>
ard(a)p850ug1.demon.co.uk (Tony Duell) wrote:
Didn't you have a relatively high -ve voltage on a
data line? If so, you
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.
--
Phil.
philpem(a)dsl.pipex.com
http://www.philpem.dsl.pipex.com/
31 May
31 May
6:08 a.m.
New subject: That pesky Jupiter Ace *still* won't work...t
Didn't you
have a relatively high -ve voltage on a data line? If so, you
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...
6:29 p.m.
New subject: That pesky Jupiter Ace *still* won't work...t
In message <m19MAeX-000IznC@p850ug1>
ard(a)p850ug1.demon.co.uk (Tony Duell) wrote:
So what haven't you replaced yet? That could be a
good starting point for
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.
--
Phil.
philpem(a)dsl.pipex.com
http://www.philpem.dsl.pipex.com/
1 Jun
1 Jun
7:35 a.m.
New subject: That pesky Jupiter Ace *still* won't work...t
In message <m19MAeX-000IznC@p850ug1>
ard(a)p850ug1.demon.co.uk (Tony Duell) wrote:
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?
So what haven't you replaced yet? That could
be a good starting point for
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...
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
8:26 a.m.
New subject: That pesky Jupiter Ace *still* won't work...t
In message <m19MYT7-000IzSC@p850ug1>
ard(a)p850ug1.demon.co.uk (Tony Duell) wrote:
Even better - a Fluke 25 on "Diode Vf/Continuity Beep" mode.
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?
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...
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...
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.
I'll have a look at that over the next few weeks. Some of the data
signals
looked a bit "dirty" (electrical noise?)...
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).
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.
--
Phil.
philpem(a)dsl.pipex.com
http://www.philpem.dsl.pipex.com/
10:20 a.m.
New subject: That pesky Jupiter Ace *still* won't work...t
In message <m19MYT7-000IzSC@p850ug1>
ard(a)p850ug1.demon.co.uk (Tony Duell) wrote:
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...
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?
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... 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).
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...
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
2 Jun
2 Jun
1:46 a.m.
New subject: That pesky Jupiter Ace *still* won't work...t
In message <m19Mb5L-000IyHC@p850ug1>
ard(a)p850ug1.demon.co.uk (Tony Duell) wrote:
I have no idea...
Looks like it'll set RAMTOP (?) to 0, thereby screwing up
any and all further RAM calculations.
Er...
No. My Z80 is rusty. VERY rusty...
Sounds as though the timing chain is fine, but it
can't hurt to check it.
Agreed.
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.
Will do.
You're right about it not being a real mux - a couple of 1k carbon
resistors and a tristate buffer. YUCK!
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.
OK.
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.
Right. What does it do if it finds no valid RAM? 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...
Are you sure no stack or data memory is needed for this... 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?
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...
[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.
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.
--
Phil.
philpem(a)dsl.pipex.com
http://www.philpem.dsl.pipex.com/
7:20 a.m.
New subject: That pesky Jupiter Ace *still* won't work...t
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.
Will do.
You're right about it not being a real mux - a couple of 1k carbon
resistors and a tristate buffer. YUCK! 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...
Are you sure no stack or data memory is needed for this... 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?
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... [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.
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.
7644
days inactive
7650
days old
13 comments
2 participants
participants (2)
-
ard＠p850ug1.demon.co.uk -
philpem＠dsl.pipex.com