Glitchy 6-switcher

[+Andrew Davie]

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.

 

[+Al_Nafuur]

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.

 

[+Andrew Davie]

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.

 

 

 

[+Andrew Davie]

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.

 

[+Andrew Davie]

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.

 

[+Al_Nafuur]

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 ?

[+Andrew Davie]

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.

 

[+Andrew Davie]

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.

 

[+Al_Nafuur]

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

 

[+Andrew Davie]

 

[+Andrew Davie]

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.

[Omegamatrix]

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.

[+Andrew Davie]

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

 

[+Andrew Davie]

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.

 

[+Andrew Davie]

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".

 

[Omegamatrix]

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.

[Omegamatrix]

And just for clarity, the detection code is ran every frame.

[+Andrew Davie]

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.

[Omegamatrix]

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  @

 

[+Andrew Davie]

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.

 

[Omegamatrix]

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.

[+Andrew Davie]

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.

 

[+Andrew Davie]

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....

[Omegamatrix]

That unit could be very valuable as is, if we come up with a new kernel to trial.

[+Andrew Davie]

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!