intvnut Posted April 29, 2014 Share Posted April 29, 2014 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Arnauld Posted April 29, 2014 Share Posted April 29, 2014 (edited) 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 Quote Link to comment Share on other sites More sharing options...
intvnut Posted April 29, 2014 Author Share Posted April 29, 2014 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? Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted April 29, 2014 Share Posted April 29, 2014 that phantom 13th cycle we've discovered CALL has? Intriguing! Tell me more... Quote Link to comment Share on other sites More sharing options...
intvnut Posted April 29, 2014 Author Share Posted April 29, 2014 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. Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted April 29, 2014 Share Posted April 29, 2014 @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. Quote Link to comment Share on other sites More sharing options...
Rev Posted April 29, 2014 Share Posted April 29, 2014 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! 1 Quote Link to comment Share on other sites More sharing options...
intvnut Posted April 29, 2014 Author Share Posted April 29, 2014 (edited) @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 Quote Link to comment Share on other sites More sharing options...
Arnauld Posted May 18, 2014 Share Posted May 18, 2014 Just a quick follow-up on this one: I confirm that I consistantly get Color Stack mode as well on my SECAM Intellivision. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted May 28, 2014 Share Posted May 28, 2014 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. Quote Link to comment Share on other sites More sharing options...
intvnut Posted June 16, 2020 Author Share Posted June 16, 2020 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. Quote Link to comment Share on other sites More sharing options...
intvnut Posted June 16, 2020 Author Share Posted June 16, 2020 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. Quote Link to comment Share on other sites More sharing options...
JohnPCAE Posted June 16, 2020 Share Posted June 16, 2020 What happens if you replace CALL BUG with B BUG and replace JR R5 with a direct jump back to the loop? Quote Link to comment Share on other sites More sharing options...
+nanochess Posted June 16, 2020 Share Posted June 16, 2020 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted June 16, 2020 Share Posted June 16, 2020 Not only that, DZ-Jay is gone. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.