+Andrew Davie Posted January 30, 2021 Share Posted January 30, 2021 Here's an experiment on my light sixer to see if the misbehaving I'm seeing onscreen in my PlusCart's menu is caused by heat. So, first we see normal letter spacing (look at the spacing in the word ROMs, for example). Now I briefly apply heat (via hairdryer) to TIA.... spacing is now wrong. Next I apply some squirts of relatively pure (99%+) IPA... and we can see the TIA cooling down. This experiment is the proof I needed that glitches on the 32 character display are heat-related issues causing changes in TIA operation. 6 Quote Link to comment Share on other sites More sharing options...
+batari Posted January 30, 2021 Share Posted January 30, 2021 I wouldn't necessarily say this glitch is caused by heat. What this video demonstrates is that there is a race condition in the hardware of the TIA, and the heat changes the timing just enough to show the race condition visually. It's not a fatal flaw, as having the text shift by a little bit doesn't make the cart unusable, but it does make me wonder if there is a way to recode the menu and avoid the race condition altogether? 3 Quote Link to comment Share on other sites More sharing options...
alex_79 Posted January 30, 2021 Share Posted January 30, 2021 I did some tests about this and I believe the issue is a RESxx at the same cycle of a motion pulse following an HMOVE. https://github.com/stella-emu/stella/issues/699 https://atariage.com/forums/topic/311795-576-and-1008-characters/?tab=comments#comment-4646705 In post #20 of the second thread, I posted 3 modified binary that avoid the race condition. 2 of them seem to work reliably on all my consoles, while the other one triggers another type of race condition that still needs to be investigated... 2 Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted January 30, 2021 Author Share Posted January 30, 2021 5 hours ago, alex_79 said: I did some tests about this and I believe the issue is a RESxx at the same cycle of a motion pulse following an HMOVE. https://github.com/stella-emu/stella/issues/699 https://atariage.com/forums/topic/311795-576-and-1008-characters/?tab=comments#comment-4646705 In post #20 of the second thread, I posted 3 modified binary that avoid the race condition. 2 of them seem to work reliably on all my consoles, while the other one triggers another type of race condition that still needs to be investigated... #1 and #2 appear to work OK on my glitchy L6'er. Looks to be really difficult for me to carry this across to the existing kernel, though - it's just a bit hard for me to modify/understand. I'd need to spend more time than it's probably worth to get things modified/sorted. 1 Quote Link to comment Share on other sites More sharing options...
Mr SQL Posted January 31, 2021 Share Posted January 31, 2021 23 hours ago, Andrew Davie said: Now I briefly apply heat (via hairdryer) to TIA.... This is not a conclusive experiment because you put a hairdryer on the chip to make it operate out of spec. Maybe TIA's that are out of spec without the hairdryer were damaged by heat or from variation in manufacture. Quote Link to comment Share on other sites More sharing options...
CPUWIZ Posted January 31, 2021 Share Posted January 31, 2021 Or you could be living in Vegas (or, gosh, Australia) and your air conditioner is not working. 3 Quote Link to comment Share on other sites More sharing options...
+x=usr(1536) Posted January 31, 2021 Share Posted January 31, 2021 10 minutes ago, CPUWIZ said: Or you could be living in Vegas (or, gosh, Australia) and your air conditioner is not working. Having lived in a non-climate-controlled top-floor apartment in Los Angeles, I'll concur. June to October, nothing was running with a case on and a number of box fans were doing their best to keep everything from crashing. Quote Link to comment Share on other sites More sharing options...
+batari Posted January 31, 2021 Share Posted January 31, 2021 2 hours ago, Mr SQL said: This is not a conclusive experiment because you put a hairdryer on the chip to make it operate out of spec. Maybe TIA's that are out of spec without the hairdryer were damaged by heat or from variation in manufacture. Not exactly. I haven't looked at the code itself but I strongly suspect the TIA is operating within spec even with the glitch. I think it's the code itself that is operating out of spec. The Stella Programmer's Guide says "the motion registers should not be modified for at least 24 machine cycles after an HMOVE command," probably because things like this race condition can happen. 1 Quote Link to comment Share on other sites More sharing options...
Mr SQL Posted January 31, 2021 Share Posted January 31, 2021 5 hours ago, batari said: Not exactly. I haven't looked at the code itself but I strongly suspect the TIA is operating within spec even with the glitch. I think it's the code itself that is operating out of spec. The Stella Programmer's Guide says "the motion registers should not be modified for at least 24 machine cycles after an HMOVE command," probably because things like this race condition can happen. I came across an example where changes in the display materialized after several hours KC Monster Maze 20 hour burn in - YouTube But putting a hairdryer on a chip to get it to go out of spec is not a valid experiment because that can be done with any chip to get it to malfunction. It would be more interesting to see this experiment happen within spec without forcing it. 7 hours ago, CPUWIZ said: Or you could be living in Vegas (or, gosh, Australia) and your air conditioner is not working. 7 hours ago, x=usr(1536) said: Having lived in a non-climate-controlled top-floor apartment in Los Angeles, I'll concur. June to October, nothing was running with a case on and a number of box fans were doing their best to keep everything from crashing. Those are both good points but the hairdryer is hotter than the surface of Venus. Quote Link to comment Share on other sites More sharing options...
alex_79 Posted January 31, 2021 Share Posted January 31, 2021 (edited) On 1/30/2021 at 3:56 PM, Andrew Davie said: Looks to be really difficult for me to carry this across to the existing kernel, though - it's just a bit hard for me to modify/understand. I'd need to spend more time than it's probably worth to get things modified/sorted. I had a look at the source on GitLab and here is a fix that I think should work (I don't have a Pluscart, but running the modified binary in my Harmony cart fixes the glitch on my 6 switch console) The race condition in the Pluscart rom is caused by the "sta RESP0" at the end of the _KERNEL_B macro (line 335). Change it to use absolute addressing, so it ends at cycle 1, which is safe (the table in this post shows when the position counters receive clock pulses with HMOVE starting at various cycles): ; preparation for next line ldx #$00 ;2 also clear value for next kernel stx HMP1 ;3 @69 sta.w HMOVE ;4 @73 ; sta RESP0 ;3 @00 <======== RACE CONDITION !!!!!! sta.w RESP0 ;4 @01 safe! Then you just need a few adjustments to keep everything aligned: Decrease the SLEEP argument from 14 to 13 in KERNEL_A (line 298) macro to compensate for the extra cycle caused by the change above MAC KERNEL_A ; displays: 00--00--11--11--11----00--00--00--00 ; SLEEP 14 SLEEP 13 _KERNEL_A {1}, {2}, {3}, {4}, {5}, {6}, {7}, {8}, {9} ENDM Change the value stored in HMP0 from $b0 to $c0 at line 1151 (we need to increase the value because with the RESP0 at cycle 1, we are skipping the first clock pulse to the motion counter) ; lda #$b0 lda #$c0 sta HMP0 lda #$80 sta HMP1 With this change we fix the alignment of characters 0-1 and 4-5, but we offset chars 2-3 and 6-7 1 pixel to the left (because the above HMP0 value is used for both KERNEL A and B)... To fix this, we add strobes to RESP0 ending at cycle 6 in KERNEL_B_BOTH and KERNEL_B macros (from line 340), so to skip the first clock pulse here too (for the timing of the motion pulses, refer to the column for HMOVE at cycle 3 in the table linked above) MAC KERNEL_B_BOTH sta HMOVE ;3 @03 ;lda LineBackColor+{1}; #{3} ;2 ;sta COLUBK ;3 @08 ; SLEEP 7+6 sta RESP0 ;3 @06 SLEEP 10 _KERNEL_B {1}_{2}, {5}, {6}, {7}, {8}, {9}, {10}, {11}, {12} ENDM MAC KERNEL_B ; displays: --00--00--11--11--1100--00--00-- sta HMOVE ;3 @03 ; SLEEP 13 sta RESP0 ;3 @06 SLEEP 10 _KERNEL_B {1}, {2}, {3}, {4}, {5}, {6}, {7}, {8}, {9} ENDM pluscart_fix.zip Edited January 31, 2021 by alex_79 1 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted January 31, 2021 Share Posted January 31, 2021 1 hour ago, alex_79 said: Change it to use absolute addressing, so it ends at cycle 1 Hmm, same RESP0 at cycle 76/0 in the 128 pixel bus stuffing demo: EntryEven: ; 65 ldx #L8_3_CLOSE ; 2 67 stx HMP1 ; 3 70 sta HMOVE ; 3 73 @73-74 - move left 8 <-- HMP0 must have HMvalue sta RESP0 ; 3 76/0 ;__________________________________________________ dec LoopCounter ; 5 5 beq KernelDone ; 2 7 (3 8) stx NUSIZ1 ; 3 10 - now 3 close ldx #$B0 ; 2 12 sta GRP0 ; 3 15 - blank out Stella copy of P0 (not seen on hardware) sty GRP1 ; 3 18 @0-38 datastream 4 SLEEP 4 ; 4 22 I'm in the middle of updating that demo to use the final BUS driver so it'll work once again in Stella. Don't have time today to work on it, so added a note in the source - will send you a test build when it's been done. 1 Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted January 31, 2021 Share Posted January 31, 2021 I've been going back and forth with Andrew in PlusCart forum about the glitch issue. This is another alternate we were looking at. Andrew tested it on his glitchy console and it worked. @alex_79 you mind testing it too? 32 Char (20210131_A).zip 1 Quote Link to comment Share on other sites More sharing options...
alex_79 Posted January 31, 2021 Share Posted January 31, 2021 12 minutes ago, Omegamatrix said: @alex_79 you mind testing it too? Tested on my L6 and '91 Jr. Works fine on both! 1 Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted January 31, 2021 Share Posted January 31, 2021 That's good. But maybe your solution will be easier to implement, if it is stable for multiple consoles. @Andrew Davie can you give Alex's code a try? Quote Link to comment Share on other sites More sharing options...
CapitanClassic Posted January 31, 2021 Share Posted January 31, 2021 If this testing goes well, then does it means Bus Stuffing is once again a possibility on all VCS systems, (JRs and 7800)? 2 Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted January 31, 2021 Share Posted January 31, 2021 31 minutes ago, CapitanClassic said: If this testing goes well, then does it means Bus Stuffing is once again a possibility on all VCS systems, (JRs and 7800)? Looks like Darrell is close to revamping BUS stuffing. This glitch issue looks solvable because there were already cycles available in the code Darrell posted. 1 Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted January 31, 2021 Author Share Posted January 31, 2021 2 hours ago, Omegamatrix said: That's good. But maybe your solution will be easier to implement, if it is stable for multiple consoles. @Andrew Davie can you give Alex's code a try? Yes. Tested and is working perfectly. I am unable to get @alex_79's version to exhibit any abnormal behaviour. I cycled through temperature conditions several times. I consistently saw the original version glitching (either in the unstable transition or in the hot "mode") and switched to the new version which always appeared rock solid perfect. I tried warming/cooling the TIA while it was running, while the menu was running, etc. Looks to me to be a perfect fix for this machine, at least. TY all! Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted January 31, 2021 Author Share Posted January 31, 2021 @alex_79's version also has just been confirmed-working on @juansolo's Atari -- which previously failed (all the time) on the spacing. Looking good! Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted January 31, 2021 Share Posted January 31, 2021 1 hour ago, CapitanClassic said: If this testing goes well, then does it means Bus Stuffing is once again a possibility on all VCS systems, (JRs and 7800)? No. The 128 Pixel Kernel glitch is the player alignment issue due to the race condition inside TIA. The Bus Stuffing issue with the JRs and 7800 is incorrect data ends up on the databus. That causes graphical corruption like the vertical strips in this image, as well as program crashes. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted January 31, 2021 Share Posted January 31, 2021 3 hours ago, Omegamatrix said: Looks like Darrell is close to revamping BUS stuffing. This glitch issue looks solvable because there were already cycles available in the code Darrell posted. I am not revamping bus stuffing. The BUS driver went thru numerous revisions. The last revision of the BUS driver was a drastic change from the prior, so Stella only supports the final version. So out of all the demos posted only the RPG demo runs in current builds of Stella. In response to Stella issue 707 I started updating 128 Pixel demo to use the final BUS driver, but RL issues in early November caused all of my 2600 projects to go on the back burner. I'm back to working on them again. Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted February 2, 2021 Author Share Posted February 2, 2021 Took me long enough, but I finally have @alex_79's kernel running in the PlusCart menu. So far, so good! It does my head in a bit, how it all works. First you get a stand-alone binary (F4 bankswitching) working, with bank 0 doing all the up/down menu stuff, and then calling the display code which lives in bank 1 to 3 (even frame) and 4 to 6 (odd frame). But because that code displays letters/words which are dynamically generated, the PlusCart has to dynamically generate those banks. That is, dynamically generate 6507 code. So it's basically a whole bunch of subroutines putting in correct bits of 6507 binary into an array - and that binary data happens to correspond to a (dynamic) version of the original 6507 stand-alone. Except the letters are different. And there's no debugging - you either get it right, or it fails. I spent quite a few hours on this one, and found a few glitches/bugs along the way. Hopefully in the next day or two we'll see beta-testers give it a go and then ASAP - live to everyone. Meanwhile, here's a screenshot (using the new "Users Online" overview page). 4 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 2, 2021 Share Posted February 2, 2021 53 minutes ago, Andrew Davie said: ... dynamically generate 6507 code ... And there's no debugging - you either get it right, or it fails. Hardcore. Glad we went the Data Stream route, if we get something wrong we usually still get a screen, just with graphical glitches. The usually because it will fail if the data stream that was wrong was used for flow control, as it contains a list of ROM addresses to jump to. 1 Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted February 2, 2021 Author Share Posted February 2, 2021 Love that font. 3 pixels wide! Quote Link to comment Share on other sites More sharing options...
+batari Posted February 3, 2021 Share Posted February 3, 2021 On 1/31/2021 at 1:33 PM, CapitanClassic said: If this testing goes well, then does it means Bus Stuffing is once again a possibility on all VCS systems, (JRs and 7800)? This testing isn't related to the issues with bus stuffing, but regardless, I am confident that we can fix bus stuffing. The way to fix it has been worked out, I just haven't had time to work on the driver lately. The driver will need to undergo some major changes so Stella will also need updating to support it. 2 Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted February 4, 2021 Author Share Posted February 4, 2021 @batari I'm gonna take a wild guess that your WiFi password is ")66]U('=I;B$*" 1 1 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.