7 Apr
2010
7 Apr
'10
3:25 p.m.
Tony Duell wrote:
It is poor policy to not give consideration to a potential source of a
problem on the basis of an assumption.
A more typical way of programming this would be to load a register with the
loop count and decrement till zero or negative. 9 is the first value to be
output both in that scenario (the '145 is a decade decoder) as well as the
observed sequence, the observed sequence being one which increments.
I don't have the 6502 instruction encoding at hand, but I'll hazard a guess
there is only a 1-bit difference between a decrement instruction and an
increment instruction, said instruction coming out of ROM. A sequence which
was supposed to go from 9 down to 0 would hence go from 9 up to F and then 0,
within 4 bits.
Note also the intended sequence is a cycle-of-10, the observed sequence is a
cycle-of-8, there are 2 values (0,9) in common to the sequences, and 10+8-2=16=2^4.
That would seem to be in contradiction to your earlier suggestion of the
unlikely not likely being the problem.
The sockets are not a problem as they have been checked already.
The power supply levels have also been checked.
Tony Duell wrote:
The unlikely does occur on occasion.
Of course...
However, assuming the firmware does the obvious thing (load a register
with 0, write it to the output port, increement it, go round again), I am
wondering just what sort of firmware failure could cause this. If the
counter was stored in RAM, it could be a RAM problem, I suppose. Speaking of early Commodore PETs, I have here a
4032 on which some of the keys
do not work. Some time ago I took a brief look at it and, as I recall,
concluded the problem was not the keyboard but rather something was messed up
with the scanning, something like not all columns/rows being scanned. I think
it was a 6821 or 6822 or some such doing the I/O, but the diagnosis was perhaps
more suggestive of something like a PROM bit failure causing the firmware
program to foreshorten the scan sequence.
Possible, I suppose, but unlikely. Do you have a logic analyser? If so, try triggering it
on a write to the
apporpriate PIA register, and look at machine cycles arround that. See if
you can figure otu what hte frmware is really doing.
If I had a logic analyser it would have been applied already.
Only a couple
of chips are in sockets in this model/unit, not the problem.
Far too many times i've thoguht 'Oh, that's certainly not the problem'
and then spent hours/days looking elsewhere only to find in the end that
that it _was_ the problem :-)
I can't rememebr who first said 'In any system that which is most
obviosulty correct, beyond all need of checking, is the problem.'