Weirdest Intellivision Bug I've Ever Seen

[intvnut]

Ok, this has got to be the absolute WEIRDEST bug I've ever seen. I discovered it while chasing down a bizarre "Flip to Color Stack" bug in my program.

 

Here's the scenario: I have a function that resides at $C022 in the memory map. It was a simple "spin and wait for keypress" function. Every so often, calling it would flip the display into color stack mode!

 

Now, I'm already aware that the STIC is read-sensitive at location $C021, due to aliasing. And reading $C021 will pop the display into color stack mode. But, I wasn't reading $C021, at least not directly.

 

I've constructed a minimal test case (attached). The key comes down to the highlighted two lines:

@@loop:
        NOP                     ; Take this out, and it goes away
        CALL    BUG
        B       @@loop

....

        ORG     $C022
BUG     MVI     $1FE,   R0      ; Take this out, and it goes away
        JR      R5

I think the NOP can be any instruction, so long as there's a linear fetch leading into CALL BUG. I tried putting the @@loop label on CALL BUG and it didn't trigger. Likewise, if I try to remove the MVI $1FE, R0 in the BUG function, it goes away. But, if I bracket it with "PSHR R5/PULR PC", it still triggers(!). That is, if I rewrite BUG as follows, the bug still triggers, as long as I also keep that MVI in there too:

BUG     PSHR    R5
        MVI     $1FE,   R0      ; Take this out, and it goes away
        PULR    PC

What the code should do is stay in FGBG mode. In that mode, you'll get gobbledegook on a black screen. (See attached expected result.) But, on a real Intellivision, you get the attached photo instead.

 

Is it only my Intellivision? (I haven't had the time to dig out an Intellivision 2 or even try it on another Intellivision 1.)

 

This is a totally bizarre bug! I worked around it in my code by moving the function down. But still... it was and still is a true head scratcher. I have no idea what the root cause might be. I don't own a logic analyzer either, so I can't really see what's happening on the bus.

 

I will say this: I saw the bug both with a CC3 and a JLP board, so the board isn't likely to be the culprit.

weird_bug.zip

Edited April 29, 2014 by intvnut

[Arnauld]

This is extremely weird indeed. I'm in a train right now for a short vacation, leaving Paris and my Intellivision until next Sunday. But I definitely will test this on my console when I'm back. I was half tempted to suggest that it might somehow be related to the SDBD mechanism, but it doesn't seem to make much sense. Something like: there recently was a 1-decle instruction (the NOP), let's see if it was a SDBD. That would imply that the 'D' flag just means "there might have been a SDBD but we still need to doublecheck". It would also imply that the CPU is looking one (or two?!) instructions backward, not taking the JSR jump into account. That sounds very unlikely...

 

Edit: Not to mention that MVI should not even be affected at all by a SDBD. But I seem to recall an IntvProg thread mentionning that it might by under certain circumstances -- I don't remember for sure.

Edited April 29, 2014 by Arnauld

[intvnut]

This is extremely weird indeed. I'm in a train right now for a short vacation, leaving Paris and my Intellivision until next Sunday. But I definitely will test this on my console when I'm back. I was half tempted to suggest that it might somehow be related to the SDBD mechanism, but it doesn't seem to make much sense. Something like: there recently was a 1-decle instruction (the NOP), let's see if it was a SDBD. That would imply that the 'D' flag just means "there might have been a SDBD but we still need to doublecheck". It would also imply that the CPU is looking one (or two?!) instructions backward, not taking the JSR jump into account. That sounds very unlikely...

 

Edit: Not to mention that MVI should not even be affected at all by a SDBD. But I seem to recall an IntvProg thread mentionning that it might by under certain circumstances -- I don't remember for sure.

 

 

Wild, isn't it?

 

As best I can figure, there's some strange state lingering somewhere after the CALL that shows up when I do a direct-mode instruction. I wonder if it's related to that phantom 13th cycle we've discovered CALL has?

[+DZ-Jay]

that phantom 13th cycle we've discovered CALL has?

Intriguing! Tell me more...

[intvnut]

Intriguing! Tell me more...

 

Well, it's merely that when we did actually try to measure CALL, it appears to be 13 cycles, rather than the published 12 cycles in the data sheet. No idea what the processor is actually doing across those 13 cycles.

[GroovyBee]

@intvnut: If you make a ROM with this "feature" in (and any other quirks that you're are interested in) I can put it on my logic analyser and tell you whats happening. All I need are the addresses of the instruction(s) you are interested in observing. However, its not something that I can do immediately but I'll certainly add it to my list of things to investigate.

[Rev]

This is extremely weird indeed. I'm in a train right now for a short vacation, leaving Paris and my Intellivision until next Sunday. But I definitely will test this on my console when I'm back. I was half tempted to suggest that it might somehow be related to the SDBD mechanism, but it doesn't seem to make much sense. Something like: there recently was a 1-decle instruction (the NOP), let's see if it was a SDBD. That would imply that the 'D' flag just means "there might have been a SDBD but we still need to doublecheck". It would also imply that the CPU is looking one (or two?!) instructions backward, not taking the JSR jump into account. That sounds very unlikely...

 

Edit: Not to mention that MVI should not even be affected at all by a SDBD. But I seem to recall an IntvProg thread mentionning that it might by under certain circumstances -- I don't remember for sure.

 

 

It takes a bug to get Arnauld out of hiding!

 

Now how about that Rick D game we have been salivating over for years!

[intvnut]

@intvnut: If you make a ROM with this "feature" in (and any other quirks that you're are interested in) I can put it on my logic analyser and tell you whats happening. All I need are the addresses of the instruction(s) you are interested in observing. However, its not something that I can do immediately but I'll certainly add it to my list of things to investigate.

 

There's just such a ROM (with source code) attached to my original post. :-) The test calls "BUG" repeatedly. I'm going to guess that the best trigger point, if you can get a trace of a window of several bus cycles, would be to trigger on returning from interrupt. (ie. the PULR R7 at $101C) That would capture the next iteration or two of the loop that calls BUG repeatedly.

 

There's something strange about the MVI $1FE, R0 at location $C022 in the test binary I posted. Obviously, to pop into Color Stack mode, whatever anomaly this is needs to happen during the portion of the VBlank interval that the STIC registers are still visible. I'm going to guess whatever anomaly this is should be visible shortly after returning from interrupt.

 

What I don't know is if the anomaly is a CP1610 anomaly or an RA-3-9600 anomaly. If it's an RA-3-9600 anomaly, it might only be visible on the private 14-bit bus between it and the STIC. Likewise if it's a STIC anomaly, as the STIC is responsible for decoding the 3-wire GI bus phase into BAR', DTB' and DWS' for the GRAM/GROM.

Edited April 29, 2014 by intvnut

[Arnauld]

Just a quick follow-up on this one: I confirm that I consistantly get Color Stack mode as well on my SECAM Intellivision.

[+DZ-Jay]

What I don't know is if the anomaly is a CP1610 anomaly or an RA-3-9600 anomaly. If it's an RA-3-9600 anomaly, it might only be visible on the private 14-bit bus between it and the STIC. Likewise if it's a STIC anomaly, as the STIC is responsible for decoding the 3-wire GI bus phase into BAR', DTB' and DWS' for the GRAM/GROM.

 

Has the culprit being identified? I was just curious.

[intvnut]

On 4/29/2014 at 12:20 AM, Arnauld said:

Edit: Not to mention that MVI should not even be affected at all by a SDBD. But I seem to recall an IntvProg thread mentionning that it might by under certain circumstances -- I don't remember for sure.

Necro-bump:  IIRC, SDBD + MVI performs a mix of MVI + SDBD MVII.  

 

From what I remember @Carl Mueller Jr said, it's something like this:

• Opcode sequence is 4 words:  SDBD; MVI; <address>; <data>
• Result: 
  • Reads lower byte at <address> into lower byte of target register (like MVI).
  • Reads lower byte of <data> into upper byte of target register (like second part of SDBD MVII).

I still haven't implemented this in jzIntv, FWIW. 

 

If I had to guess at a cycle count, it's probably 17 cycles total for SDBD + MVI.

[intvnut]

On 5/28/2014 at 2:41 AM, DZ-Jay said:

Has the culprit being identified? I was just curious.

Not that I know of.

[JohnPCAE]

What happens if you replace CALL BUG with B BUG and replace JR R5 with a direct jump back to the loop?

[+nanochess]

18 hours ago, intvnut said:

Not that I know of.

That's a new record of time taken to answer

Edited June 16, 2020 by nanochess

[+atari2600land]

Not only that, DZ-Jay is gone.