5 Jun
2019
5 Jun
'19
12:11 a.m.
I looked at the address 0 line, and pressed the RESET button, and it'd wiggle
for a short period of time, then go high. Hmm... I looked at the other
address lines, and while not all of them wiggled, they all ended up at logic
1 after a short period of time, as if the CPU was stuck at address 0xFFFF.
I did the same thing watching the data lines, and the symptoms were similar.
They'd wiggle around a bit, then settle at logic 1 and stay there.
As far as I recall, the 6502 reads the address to jump to in the event of a
(maskable) interrupt from FFFE and FFFF. Could the inverted INT line (or maybe
the inverted NMI line if FFFA and FFFB both contain FF) into the 6502 be
getting pulled low by something and maybe end up getting stuck low?
I think a software interrupt BRK instruction (00) also results in a jump to
the address specified by FFFE and FFFF so perhaps this is another avenue to
explore, although I'm not sure how the CPU would end up addressing FFFF
only in the event that BRK is being executed.
Executing certain invalid opcodes may cause the CPU to hang so this might
be another possibility.
Maybe the RAM in the RIOT chip is not working properly? If that were the
case, since it appears that the stack is stored in that RAM, the first time
a subroutine was called and a return executed, it'd cause possibly 0xFFFF to
be read as the return address, and that's where things go awry.
The stack is also read when an RTI (return from interrupt) instruction is
executed, which may be on return from an actual interrupt or BRK instruction,
however RTI can also be used just to get an address from the stack into the
program counter without adding one to it like RTS does.
An approach I've used to test stack RAM is to write a very basic memory tester
to execute on reset and program it into an EPROM used to replace the monitor
ROM. The results can be written to the parallel ports on a 6522. I think once
I even managed to this with a 2K static RAM with flying leads from the power
pins to roughly 5V worth of battery to keep the contents while moving the RAM
chip from where it was written to the machine under test (!).
I guess maybe I need to dig out my logic analyzer, and monitor the address
and data busses, and trace out what is actually happening. But, I figured
I query the list here to see if anyone might have some other things that I
could do that might be easier to identify what's wrong with the thing.
I think I recall there being a SYNC signal which the 6502 asserts when it is
reading code to execute as opposed to data. Perhaps this could be used with
a logic analyser to see what the CPU is executing?
I have some fuzzy recollection of other signals, maybe READY or something
like that which might be usable to implement single stepping through
instructions. Or if they are in the wrong state or floating, maybe they
could possibly be responsible for the problem.
Regards,
Peter Coghlan.