6502.org

Sure they wouldn't matter within the loop, but outside they may. And dealing with the status flags a brief look at the I-Flag would detect a false IRQ inhibit as well. To say it simple: I would assume a certain stable configuration of M,X, and I during the idle loop - anything else indicates something didn't work as expected.
You only reprogrammed - no changes to the logic - the CPLD ?
On one hand - fine! It is running, these spurious malfunctions are gone, hooray.
On the other hand - was a flaky programmed chip really the cause? How could that happened? How can you be sure the next programming is a good one too? And is the bug really gone or will it appear again, just 1000 times less frequently?

I hope you have done right by reprogramming the CPLD. And that such an unstable behavior of that chip never appear again.

Ah-hah! You're reading my mind. I disconnected the probes this morning when I came into my office—the unit was still chugging along. We'll see if the presence of the probes has anything to do with stability. I'll reconnect the probes sometime later to see if the unit is still running.
I have no reason to believe the CPLD that is in the unit has a hardware issue. That said, I'm going to program a different one and see how it behaves.

I'll bet an AM radio would reveal what you want to know! Tuned between stations and placed near POC it'll produce one kind of modem-y noise before a crash and a different kind of modem-y noise after. But I wonder if it's necessary. I'm not convinced the probes are a cause for concern. Suppose one of the POC signals does change significantly when a probe is attached. That's a nontrivial anomaly in itself (and stuff like that is certainly possible). But unless I've gotten the facts wrong, POC has been seen to work then fail with the probes in place -- and likewise seen to work then fail with the probes absent. So what triggers the failure? Seems to me you'd need a second anomaly. Two anomalies isn't impossible, but it is somewhat implausible.
Makes sense. Probably best to also do a re-test using the original CPLD code (pre-tidy-up, I mean).

There isn't a single radio in the house. The one radio we had conked out several years ago and I never got around to replacing it.
The unit ran for almost two days with the probes disconnected. I reconnected them this evening and everything was still flying straight and level.
Well, I've got POC V2.0 running on a different (new) CPLD that I programmed with the tidied-up code. I'll let it go for a few more days and if nothing untoward happens, I'll reprogram the CPLD with the older code and see if that breaks it.

(Same for me: I need to use the car radio if I want to do AM experiments...)

I've been regularly using this Radio Shack Realistic 12-714 radio since Dec 1981:



I've fixed the earphone jack a couple of times, and the battery snap a time or two, and sprayed the volume control with contact cleaner, and today it works the same as new.

A few feet of wire, a germanium diode, a high impedance earphone (one of he old cheapies) and your body will suffice. Just loop the wire on the table around your POC, connect it to the diode, connect the earphone across the diode and your body makes a suitable ground. Easy peasy.

I was going to suggest that, but here's one thing I haven't seen suggested: I've made one of those before(from a Dick Smith Funway kit) and they use a piezo-based earpiece, so a piezo will likely work, too. If you've got a dead PC, they sometimes have a piezo as their beeper speaker, if they have one.

Geesh! I remember those things. I figured by now they are all in landfills.

I never had one of those, I had a yellow Flavoradio.

There was a bug in the older CPLD code but that wasn't the cause of the trouble. The trouble was coming from an unsuspected place.

When I did the layouts for both versions of POC V2, I allocated enough room around the ROM so I could piggyback a ZIF socket into the ROM's socket to make it easier to swap out ROMs during firmware development.¹
The ZIF socket I've been using was one I had used in the past for testing ROMs in the empty ROM socket in the Commodore 128. It had gotten quite a bit of use and had laid about for a while before being pressed into service with POC V2. The socket turned out to have an intermittent connection in it.

How did I figure this out, you ask? I couldn't get POC V2.0 to run properly after making nothing more than a cosmetic change to the test firmware code I was using, a change that simply moved some text from one place on the screen to another. In trying to figure out what the heck was wrong, I put the previous (working) ROM back into the ZIF socket and it too seemed to have the same problem. You can imagine the language I used when that happened!

So there I sat, baffled by what was going on, thinking I had a flaky ROM, when it suddenly occurred to me I was overlooking something else, which was the ZIF socket. It made sense: both versions of POC V2 were displaying similar problems, even with firmware code that had worked before. Also, as I was testing, I was constantly moving the socket from one unit to the other. In other words, I was moving the source of the problem from one unit to the other when I moved the socket.

With all that stewing in my little dinosaur brain, I yanked out the ZIF socket and plugged the ROM directly into the socket soldered into the board. I powered up, the unit came to life, the POST screen was displayed and the logic probes indicated normal activity on /IRQ and RDY.

I let the unit run like that for several days and then powered off. I unplugged the ROM, put the ZIF socket back in place and put the same ROM in the ZIF socket. Sure enough, the unit didn't boot. Just for grins, I powered down, pressed down on the ROM with my thumb, and then powered up. The unit booted and the probes indicated normal activity.

I also tried the above series of tests on POC V2.1, using a ROM I had burned back in November and knew was functional. Same results: with the ZIF socket installed, sometimes the unit would behave and sometimes it wouldn't.

I have ordered a new ZIF socket, which I hope to receive in the next day or two. Presumably it will function as it should and I can get on with developing firmware.

——————————
¹In future endeavors of this kind, I will solder the ZIF socket into the prototype's PCB instead of piggybacking it on the ROM socket. The only reason I didn't do that with POC V2 was the frugal Irishman in me didn't want the 15 dollar ZIF socket becoming a permanent part of the assembled unit.

I've had a few problems with ZIF sockets over the decades, that they did not grab the EPROM pins firmly enough to make a good contact. The green 3M ones were the worst. Forcing the EPROM side to side to scrape the contacts as I slowly tightened the socket usually did the job.

I can vouch that the green 3M sockets as being junk. I've had grief with them in the past.

I did try "scraping" the contacts by wiggling the ROM as I closed the socket, thinking that was all it was. It didn't turn out to be the case with this particular socket. I'm guessing it's an internal mechanical problem.

So, this was it? The ZIF socket? The authentic "Gremlin Brand ZIF Socket"? This is what's been causing your recent woes?

That's great you found it.

It appears to be the socket. It's an Aries socket, which is not a cheap brand.