+Andrew Davie Posted January 29, 2021 Share Posted January 29, 2021 I dug up a PAL 6-switcher to test PlusCart. Fortunately for us, it exhibits the poor spacing on the text kernel. Specifically, the first two PF0 sprites are shimmering back and forth by one pixel (but different on each scanline, mid character) in therms of visuals. For example, on the line "Search ROM", the "Se" and the "ch" are jiggly/broken, mostly appearing one pixel too-far-right. The jiggle is where for perhaps half of the lines (but different each frame) the character is actually in the right pixel position. The whole thing is shimmering and broken mid-character (vertically), in other words. So, if we want to test various kernel timing alternates, I have a machine to do it on. Unfortunately, I'm not skilled enough with the 32-char kernel to really understand what to change to test things. Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted January 29, 2021 Share Posted January 29, 2021 can you give the cartridge slot pins of the 6-switcher a good clean with alcohol? I still suspect that these glitches come from bad contacts. At least on my 7800 PAL I mostly don't have these glitches with a clean PlusCart without the shell. Link to comment Share on other sites More sharing options...
+Andrew Davie Posted January 29, 2021 Author Share Posted January 29, 2021 2 minutes ago, Al_Nafuur said: can you give the cartridge slot pins of the 6-switcher a good clean with alcohol? I still suspect that these glitches come from bad contacts. At least on my 7800 PAL I mostly don't have these glitches with a clean PlusCart without the shell. Hard to access -- but I sprayed IPA on the pluscart pins, and inserted/removed the PlusCart 20 times or so, jiggling it around. At first the machine was OK, 30 seconds or so, but then the glitches creep in and after about 2 minutes it's fully glitchy again. Repeated. Sprayed pins with IPA, fairly violent jiggling, re-test. 30 seconds OK, then glitches are back. 1 Link to comment Share on other sites More sharing options...
+Andrew Davie Posted January 29, 2021 Author Share Posted January 29, 2021 Without touching the PlusCart, machine OFF/ON and by the time I'm at the menu, the glitches are going full-speed-ahead. Power off and wait for 30 seconds, turn on -- no glitches, and then 30 seconds after menu is there they startup again. After about a minute they're once again full-speed-ahead. I don't think it's the cartridge slot myself. I think it's something related to the temperature characteristics of the hardware. I guess I could confirm that by finding some freon and spraying on a glitchy unit. 1 Link to comment Share on other sites More sharing options...
+Andrew Davie Posted January 29, 2021 Author Share Posted January 29, 2021 Update: I disassembled the unit so that I could test spraying IPA on the TIA when it was glitchy. Unfortunately, it's working perfectly with no sign of any glitching after 10 minutes. Previously it took a minute or so. If it glitches again when reassembled, I think we'd have to conclude temperature-related causes. Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted January 29, 2021 Share Posted January 29, 2021 1 hour ago, Andrew Davie said: Update: I disassembled the unit so that I could test spraying IPA on the TIA when it was glitchy. Unfortunately, it's working perfectly with no sign of any glitching after 10 minutes. Previously it took a minute or so. If it glitches again when reassembled, I think we'd have to conclude temperature-related causes. can you heat it up with a hairdryer ? Link to comment Share on other sites More sharing options...
+Andrew Davie Posted January 29, 2021 Author Share Posted January 29, 2021 1 minute ago, Al_Nafuur said: can you heat it up with a hairdryer ? I will try that tomorrow. Meanwhile, after reassembling -- it's glitching again. Took a while, though... about 10 minutes. So, it's inconclusive. I took the opportunity to re-seat the TIA in its socket, just in case there was an issue there. Apparently not. Link to comment Share on other sites More sharing options...
+Andrew Davie Posted January 30, 2021 Author Share Posted January 30, 2021 Opened it up again. Turned it on for a couple of minutes. No glitches yet. Then the hairdryer. It took just 5 seconds of blowing a hairdryer on the TIA to start the glitches. Then I took my bottle of IPA and did a couple of squirts on the TIA. Glitches disappeared in 2 or 3 seconds. So, it's absolutely definitely temperature-related and it's the TIA. 1 Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted January 30, 2021 Share Posted January 30, 2021 33 minutes ago, Andrew Davie said: Opened it up again. Turned it on for a couple of minutes. No glitches yet. Then the hairdryer. It took just 5 seconds of blowing a hairdryer on the TIA to start the glitches. Then I took my bottle of IPA and did a couple of squirts on the TIA. Glitches disappeared in 2 or 3 seconds. So, it's absolutely definitely temperature-related and it's the TIA. Do you have some of these small heatsinks for the Raspberry PI ? https://www.banggood.com/3Pcs-Black-or-Gold-or-Green-or-Silver-Aluminum-Radiator-Heat-Sink-with-Back-Glue-for-Raspberry-Pi-4B-p-1552741.html Link to comment Share on other sites More sharing options...
+Andrew Davie Posted January 30, 2021 Author Share Posted January 30, 2021 Link to comment Share on other sites More sharing options...
+Andrew Davie Posted January 30, 2021 Author Share Posted January 30, 2021 2 minutes ago, Al_Nafuur said: Do you have some of these small heatsinks for the Raspberry PI ? https://www.banggood.com/3Pcs-Black-or-Gold-or-Green-or-Silver-Aluminum-Radiator-Heat-Sink-with-Back-Glue-for-Raspberry-Pi-4B-p-1552741.html Yes, I do have some that are suitable. Link to comment Share on other sites More sharing options...
Omegamatrix Posted January 30, 2021 Share Posted January 30, 2021 The glitch being caused by thermal effects is no surprise. Andrew have you tried to make the 32 char display self healing? Just gotta have a detection run at the top of the kernel and then use alternate HMOVE values each frame. Link to comment Share on other sites More sharing options...
+Andrew Davie Posted January 30, 2021 Author Share Posted January 30, 2021 Just now, Omegamatrix said: The glitch being caused by thermal effects is no surprise. Andrew have you tried to make the 32 char display self healing? Just gotta have a detection run at the top of the kernel and then use alternate HMOVE values each frame. There was some debate about if the glitching was heat-related or physical/mechanical such as cartridge connections. Now that's settled, dynamic modification is the way to go. I don't really have the skills to do this, but definitely something that seems to be a good idea. I understand the principle - single pixel background-colour pixel/playfield on top line, then adjust HMOVE based on collision/no collision. The kernel code is quite complex and hard to read, and getting that stuff in as well may be a lot of work. But in the long term, yes, this would seem to be a good idea. That, or we ask everyone to put a heatsink and/or water cooling on their '2600 Link to comment Share on other sites More sharing options...
+Andrew Davie Posted January 30, 2021 Author Share Posted January 30, 2021 4 minutes ago, Omegamatrix said: The glitch being caused by thermal effects is no surprise. Andrew have you tried to make the 32 char display self healing? Just gotta have a detection run at the top of the kernel and then use alternate HMOVE values each frame. On reflection, this won't work. Look at the video -- it seems to be a per-line effect. On some lines it's glitching, on the next line it isn't. And the effect varies depending on the heat of the TIA. I think it's going to be way more complex than a detection at top of frame. Link to comment Share on other sites More sharing options...
+Andrew Davie Posted January 30, 2021 Author Share Posted January 30, 2021 More to the point, there's a "cold" state where everything is normal. There's a "transition" band where glitches happen or not, on a per-line basis. There's a "hot" state where everything is shifted 1 pixel, but rock-solid. In normal usage, this machine tended to settle (after 10 minutes or so) into the "transition" band and never reached "hot". Link to comment Share on other sites More sharing options...
Omegamatrix Posted January 30, 2021 Share Posted January 30, 2021 Is the 32 character the same kernel that Eshu wrote? If it is then P0 is the problem, and the HMOVE value in question is set outside of the kernel. On a non-glitch system use $B0 for the HMP0 value. On a glitched system $C0 for HMP0 would work. Now what we are seeing is that glitch can happen at any time. I had the exact same problem with the 36 character but found just checking once at the top of the frame was enough to correct the glitch. So all that is needed is to write the detection code that happens at the top of the frame. The ball is free so using one pixel of GRP0 and overlapping a 1 pixel wide ball will work. If you look at the 36 char demo I sent you I do exactly that in there to judge if the frame is glitching or not. Link to comment Share on other sites More sharing options...
Omegamatrix Posted January 30, 2021 Share Posted January 30, 2021 And just for clarity, the detection code is ran every frame. Link to comment Share on other sites More sharing options...
+Andrew Davie Posted January 30, 2021 Author Share Posted January 30, 2021 3 minutes ago, Omegamatrix said: Is the 32 character the same kernel that Eshu wrote? If it is then P0 is the problem, and the HMOVE value in question is set outside of the kernel. On a non-glitch system use $B0 for the HMP0 value. On a glitched system $C0 for HMP0 would work. Now what we are seeing is that glitch can happen at any time. I had the exact same problem with the 36 character but found just checking once at the top of the frame was enough to correct the glitch. So all that is needed is to write the detection code that happens at the top of the frame. The ball is free so using one pixel of GRP0 and overlapping a 1 pixel wide ball will work. If you look at the 36 char demo I sent you I do exactly that in there to judge if the frame is glitching or not. No, it is one written by @Thomas Jentzsch but it does seem to be P0. I will do some more investigation, including confirming that your 36 character demo works on this machine. Link to comment Share on other sites More sharing options...
Omegamatrix Posted January 30, 2021 Share Posted January 30, 2021 Here is the auto-detection code that runs for the 36 character kernel. The 32 char kernel will need to do something similar. The most important element of it is that is does the positioning of P0 exactly the same as it does for the line that glitches. That is it's doing all of the weirdness of a an early HMOVE ending at cycle 73 followed by a strobe of RESP0. This allows it to exactly replicate the positioning as it does in the kernel. Then all that is needed is the collission check with the ball. If the code is like Eshu's, "DEFAULT_HMP0_VAL" value would be $B0, and alternative would be $C0. DoKernel: sta VBLANK ; A=0 SLEEP 8 lda #THREE_COPIES_CLOSE ;2 @13 sta NUSIZ0 ;3 @16 sta NUSIZ1 ;3 @19 sta CXCLR ;3 @22 clear collisions lda #COL_SCREEN ;2 @24 sta COLUP0 ;3 @27 lda #BORDER_SHAPE ;2 @29 sta PF0 ;3 @32 lda #NO_MO_74 ;2 @34 sta HMP1 ;3 @37 sta HMBL ;3 @40 lda #DEFAULT_HMP0_VAL ;2 @42 sta HMP0 ;3 @45 lda #BALL_1_CLK | PF_PRIORITY | PF_REFLECT ;2 @47 sta CTRLPF ;3 @50 lda #ENABLE ;2 @52 sta ENABL ;3 @55 sta RESP0 ;3 @58 lda #BL_P0_OVERLAP_BIT ;2 @60 set a single bit that should line up with the ball for a collision sta GRP0 ;3 @63 SLEEP 7 ;7 @70 sta HMOVE ;3 @73 sta RESP0 ;3 @76 ;--------------------------------------- ldx #5 .loopDelay dex bne .loopDelay SLEEP 2 lda frameCounter ;3 @ lsr ;2 @ ldy #DEFAULT_HMP0_VAL ;2 @49 bit CXP0FB ;3 @52 bvs .goodAlignment ;2/3 @54/55 ldy #ALTERNATE_HMP0_VAL ;2 @56 jmp .storeHmoveValue ;3 @ .goodAlignment: SLEEP 4 ;4 @ .storeHmoveValue: sty hmoveVal ;3 @ Link to comment Share on other sites More sharing options...
+Andrew Davie Posted January 30, 2021 Author Share Posted January 30, 2021 Results from testing the 36-character demo. Firstly, in normal use -- stable. In the "transition" state as described above, the first two characters (of the 32) are glitchy/unreadable/ustable. Once "hot" -- stable again. This is pretty much as I expected. As I said, you can't seem to rely on a once-per-frame check, as the transition state is unstable along the frame. Since this machine seems to like living in the "transition" state, a once-per-frame detection won't help. Link to comment Share on other sites More sharing options...
Omegamatrix Posted January 30, 2021 Share Posted January 30, 2021 Well, you can do it before entering each row then if you have the cycles. I had high hopes that it work as is. Orange808 had a 7800 that was intermittent as well, and the once per frame was stable on it. Link to comment Share on other sites More sharing options...
+Andrew Davie Posted January 30, 2021 Author Share Posted January 30, 2021 30 minutes ago, Omegamatrix said: Well, you can do it before entering each row then if you have the cycles. I had high hopes that it work as is. Orange808 had a 7800 that was intermittent as well, and the once per frame was stable on it. It's stable on this machine if it's either cold... or hot. Not... warm. And again, once per row won't make any difference - the visuals are breaking up mid-character on each row. In other words, almost each scanline is different. I can do a video if that would help you visualise. Link to comment Share on other sites More sharing options...
+Andrew Davie Posted January 30, 2021 Author Share Posted January 30, 2021 A heatsink on the TIA made little difference - still glitchy after it had warmed up. Maybe I should go the other way and encourage it to the second stable state (hot) ASAP. Insulation.... Link to comment Share on other sites More sharing options...
Omegamatrix Posted January 30, 2021 Share Posted January 30, 2021 That unit could be very valuable as is, if we come up with a new kernel to trial. Link to comment Share on other sites More sharing options...
+Andrew Davie Posted January 31, 2021 Author Share Posted January 31, 2021 7 hours ago, Omegamatrix said: That unit could be very valuable as is, if we come up with a new kernel to trial. Yes, I'm aware of its significance in both its behaviour and that it's in the hands of a developer who can use it to test things. Any tests/changes I make are tempoary! Link to comment Share on other sites More sharing options...
Recommended Posts