A TIA walked into a bar and asked for a hairdryer and some alcohol....

[Andrew Davie]

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.

 

 

[+batari]

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?

[alex_79]

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

[Andrew Davie]

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.

[Mr SQL]

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.

[CPUWIZ]

Or you could be living in Vegas (or, gosh, Australia) and your air conditioner is not working.

[x=usr(1536)]

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.

[+batari]

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.

[Mr SQL]

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.

 

[alex_79]

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 by alex_79

[+SpiceWare]

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.

[+Omegamatrix]

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

 

 

[alex_79]

12 minutes ago, Omegamatrix said:

 @alex_79 you mind testing it too?

 

Tested on my L6 and '91  Jr. Works fine on both!

 

[+Omegamatrix]

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?

 

 

[CapitanClassic]

If this testing goes well, then does it means Bus Stuffing is once again a possibility on all VCS systems, (JRs and 7800)?

[+Omegamatrix]

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.

[Andrew Davie]

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!

 

[Andrew Davie]

@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!

 

[+SpiceWare]

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.

 

[+SpiceWare]

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.

 

[Andrew Davie]

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

 

[+SpiceWare]

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.

[Andrew Davie]

Love that font. 3 pixels wide!

[+batari]

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.

[Andrew Davie]

@batari I'm gonna take a wild guess that your WiFi password is ")66]U('=I;B$*"