This might be one of those questions that just could be answered theoretically, or just handled as "because it is so, dumbass."
But anyways.. *question got more complex as I began writing.. too much coffee*.
Since I started NES hacking about one year ago - and learning 6502 assembler - , I quickly found that certain "opcodes" would simply crash the cpu.
Yes, the KIL/HLT/DIE whatever you want to call them. Mostly "opcodes" with $*2. Mainly from branching to incorrect location, or forgetting to RTS from somewhere and end up in <wrong place>.. or from some datacollection.. you know how this could happen
The question is, WHY? I can see the reasoning behind stopping CPU by a BRK and having some control over the continued processing, but this just stops and halts until a reset. Was this intended as a forced stop or was it some kind of costcutting measure? I mean, there are a LOT of opcodes that crash the CPU instantly. Why have some potential programming error stop CPU irreversebly? Faulty design?
I watched some youtube movie about reverse engineering the 6502 where, if I remember correctly, this topic was adressed.
Still, I wonder why not have the CPU ignore opcodes like those and carry on? By software or hardware trapping buffer of some sort. For game consoles, this must have been a good idea? Maybe Nintendo REALLY trusted the individuals writing games for their console back in the days. A crashed game = unhappy player = the game itself and Nintendo gets bad publicity.
Like who cares? It worked, didn´t it?
But anyways.. *question got more complex as I began writing.. too much coffee*.
Since I started NES hacking about one year ago - and learning 6502 assembler - , I quickly found that certain "opcodes" would simply crash the cpu.
Yes, the KIL/HLT/DIE whatever you want to call them. Mostly "opcodes" with $*2. Mainly from branching to incorrect location, or forgetting to RTS from somewhere and end up in <wrong place>.. or from some datacollection.. you know how this could happen
The question is, WHY? I can see the reasoning behind stopping CPU by a BRK and having some control over the continued processing, but this just stops and halts until a reset. Was this intended as a forced stop or was it some kind of costcutting measure? I mean, there are a LOT of opcodes that crash the CPU instantly. Why have some potential programming error stop CPU irreversebly? Faulty design?
I watched some youtube movie about reverse engineering the 6502 where, if I remember correctly, this topic was adressed.
Still, I wonder why not have the CPU ignore opcodes like those and carry on? By software or hardware trapping buffer of some sort. For game consoles, this must have been a good idea? Maybe Nintendo REALLY trusted the individuals writing games for their console back in the days. A crashed game = unhappy player = the game itself and Nintendo gets bad publicity.
Like who cares? It worked, didn´t it?