In message <m19MYT7-000IzSC_at_p850ug1>
ard_at_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?
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
Even better - a Fluke 25 on "Diode Vf/Continuity Beep" mode.
> 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_at_dsl.pipex.com
http://www.philpem.dsl.pipex.com/
Received on Sun Jun 01 2003 - 15:26:00 BST