Re: Issues with 6502?
Posted: Sat Jul 19, 2025 5:55 pm
Lots of advice coming at you, Niek6502, and the situation may seem rather murky. But one or two important points seem clear to me.
Things sound pretty crazy when you talk about "completely derailing (nonsensical addresses, weird read/write pin outputs etc)," but let's take that apart a bit. For starters, there's nothing weird about the read/write pin going low for 3 cycles.It's going low because a BRK instruction is executing -- it fetched the $00 BRK opcode from $800C. (And yes it appears to have skipped 4 bytes to get to $800C, but perhaps it got there incrementally and we don't see that because some samples are failing to appear -- just an alternative theory to keep in mind.) But it certainly seems to be executing a BRK, and that would very readily explain the "weird" read/write pin output.
It also may seem weird that the expected write data fails to appear in the recorded samples. Instead what the recorded samples show is the data which was read in the immediately preceding cycle. (Example: $8007 and the cycle that follows) That's consistent with my suspicion that the samples were taken too soon. Virtually all 65(C)02 systems (including yours, I infer) do not drive the data bus during the first half of a write cycle -- ie, during the PHI2-low portion. Since the bus isn't being driven, what will remain there is whatever state most recently *was* driven... and that's the last byte of the instruction that generated the write. We clearly see that several different times.
It remains because of the storage effect resulting from the capacitance of the bus lines; this phenomenon is well known. And it won't disappear until the 2nd half of the cycle when the CPU drives write data onto the bus. This supports my conclusion that the samples taken by the Arduino were taken too soon, while PHI2 was still low and the CPU hadn't yet driven write data onto the bus. But why?
Electrical noise is always present to some extent, and it has potential to induce hiccups. For example, a signal (like PHI2) that rises from low to high may, with noise impressed upon it, appear to go low->high->low->high! IOW, there's an illusion of multiple transitions. And that includes both high-to-low transitions and low-to-high transitions! This means there's potential for the Arduino to take its sample on the opposite edge to the one you intended.
I agree with BDD that you'd do well to buffer the output of the 555, as that'll result in much faster rise & fall times (the transitions will occur more snappily). An 'AC14 would be ideal, but even just one of your existing inverter sections -- 74HC04, not 'LS04 -- would probably suffice. And yes that'll help satisfy the CPU spec as he noted.
But more important, IMO, is that it'll result in more reliable sampling by the Arduino. Your samples clearly are getting taken at the wrong time. There may be multiple factors at play, but certainly the slow rise & fall times from the 555 make it easier for noise to falsely trigger the Arduino.
-- Jeff
Things sound pretty crazy when you talk about "completely derailing (nonsensical addresses, weird read/write pin outputs etc)," but let's take that apart a bit. For starters, there's nothing weird about the read/write pin going low for 3 cycles.
Code: Select all
8005 r 1 8d sta $7abc
8006 r 1 bc
8007 r 1 7a
7abc w 0 7a --> still seeing 7a instead of 01
800c r 1 00 ---> and here things go completely off the rails - it skipped 4 bytes ???
800c r 1 00
800d r 1 00
01fa w 0 00 **read/write pin!
01f9 w 0 80 **read/write pin!
01f8 w 0 0e **read/write pin!It also may seem weird that the expected write data fails to appear in the recorded samples. Instead what the recorded samples show is the data which was read in the immediately preceding cycle. (Example: $8007 and the cycle that follows) That's consistent with my suspicion that the samples were taken too soon. Virtually all 65(C)02 systems (including yours, I infer) do not drive the data bus during the first half of a write cycle -- ie, during the PHI2-low portion. Since the bus isn't being driven, what will remain there is whatever state most recently *was* driven... and that's the last byte of the instruction that generated the write. We clearly see that several different times.
It remains because of the storage effect resulting from the capacitance of the bus lines; this phenomenon is well known. And it won't disappear until the 2nd half of the cycle when the CPU drives write data onto the bus. This supports my conclusion that the samples taken by the Arduino were taken too soon, while PHI2 was still low and the CPU hadn't yet driven write data onto the bus. But why?
Electrical noise is always present to some extent, and it has potential to induce hiccups. For example, a signal (like PHI2) that rises from low to high may, with noise impressed upon it, appear to go low->high->low->high! IOW, there's an illusion of multiple transitions. And that includes both high-to-low transitions and low-to-high transitions! This means there's potential for the Arduino to take its sample on the opposite edge to the one you intended.
I agree with BDD that you'd do well to buffer the output of the 555, as that'll result in much faster rise & fall times (the transitions will occur more snappily). An 'AC14 would be ideal, but even just one of your existing inverter sections -- 74HC04, not 'LS04 -- would probably suffice. And yes that'll help satisfy the CPU spec as he noted.
But more important, IMO, is that it'll result in more reliable sampling by the Arduino. Your samples clearly are getting taken at the wrong time. There may be multiple factors at play, but certainly the slow rise & fall times from the 555 make it easier for noise to falsely trigger the Arduino.
-- Jeff
Dunno about that, but I did have to use a hacksaw when I had to cut a cable to splice in a new section.