1 Jun
2003
1 Jun
'03
8:26 a.m.
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/