Bus Stuffing Demos

[netspecter]

The forum is saying I don't have permission to download it.

 

EDIT: I can download other attachments in this thread just fine, even in a private window. It's just this latest ROM that I can't get.

 

 

I can't download it either.

[ZackAttack]

Sorry, I had originally posted in a private conversation and didn't realize it works like that. Try this one.

stuff test 2 - going high.bin

[TheHoboInYourRoom]

It works! Eventually. I tested the ROM after cleaning the Harmony and the cartridge port, and one bit wasn't being stuffed, but it corrected itself in about 30-45 seconds top to bottom. Strange.

 

[Keatah]

How "healthy" must a VCS console be to work with bus-stuffing? And is it more temperature sensitive when using stuffing?

[ZackAttack]

It works! Eventually. I tested the ROM after cleaning the Harmony and the cartridge port, and one bit wasn't being stuffed, but it corrected itself in about 30-45 seconds top to bottom. Strange.

 

going-high.jpg

Thanks for providing the pictures. That's very helpful. What's really interesting is that it was always working where it stuffs a single bit per byte, but the same bit failed when stuffing 7 bits per byte. Could you also post a picture of the power transformer you use with that system. Specifically I want to see what voltage and amperage it's rated for and if it's AC or DC.

 

How "healthy" must a VCS console be to work with bus-stuffing? And is it more temperature sensitive when using stuffing?

 

I'm not really sure it means a system is unhealthy if it doesn't handle bus-stuffing. I think it's more of a variation thing. There are internal resistances that vary from one system to the next and in some cases the resistance is such that bus-stuffing doesn't work. Temperature changes can change the internal resistance of some of the components. That may be why it took some time to start working. There are also some variations in the voltage threshold that determines if a signal is interpreted as a 1 or 0. I think that's why stuffing high works on some systems where stuffing low doesn't work and vice versa.

[+Nathan Strum]

Well, here's the Jr. that failed with the previous test:

 

 

But here's my heavy-sixer (s-video modded) that worked:

 

 

(Sorry for the crooked photos - but it cuts down on the moire patterns that way.)

 

I'm assuming this somehow makes sense?

[+Nathan Strum]

Four-switch Sears:

 

 

Vader:

 

[ZackAttack]

The plan is to detect which method works and use that on a system. So if the first test program works there's no need to test the stuff high test program. As long as one or the other works we're in good shape. Do the three systems you show failure with stuff high all work with the other test program?

[+Nathan Strum]

Do the three systems you show failure with stuff high all work with the other test program?

 

 

Yep - they all worked with the previous one.

[TheHoboInYourRoom]

Could you also post a picture of the power transformer you use with that system. Specifically I want to see what voltage and amperage it's rated for and if it's AC or DC.

[Andromeda Stardust]

The plan is to detect which method works and use that on a system. So if the first test program works there's no need to test the stuff high test program. As long as one or the other works we're in good shape. Do the three systems you show failure with stuff high all work with the other test program?

This is awesome if true that the few system that don't like the original bus stuff all work with the alternate method. If that's the case, then perhaps future game carts utilizing bus stuffing could ship on standard or slightly modified Melody hardware with both programs and a simple DIP switch "if low setting experiences graphical artifacts, flip switch to high" or some such.

[Keatah]

Mmm.. Maybe there could be an autodetect or test routine or something. Simply writing/stuffing values, and reading them back normally.

 

And a quick flash of a white dot on the left side of the screen indicating high is used. Or a dot flash on the right side indicating low is being used. Something simple for troubleshooting information.

 

Maybe even detect which way the joystick is being held, left or right, to override any autodetect. A way to manually force a scheme.

Edited March 25, 2017 by Keatah

[TheHoboInYourRoom]

Mmm.. Maybe there could be a test routine or something. Simply writing/stuffing values, and reading them back normally.

 

And a quick flash of a white dot on the left side of the screen indicating high is used. Or a dot flash on the right side indicating low is being used. Something simple for troubleshooting information.

It would have to deal with the fact that most TIA registers are write-only. Something that manipulates the collision flags most likely.

[Keatah]

OK. I'm not a VCS programmer. So, then, maybe an auto-detect routine could involve user input somehow. Dunno.

[TheHoboInYourRoom]

OK. I'm not a VCS programmer. So, then, maybe an auto-detect routine could involve user input somehow. Dunno.

No, it could still be automated. Like say you're stuffing data into the playfield registers and moving one of the sprites in 4-pixel increments to see if the desired bits are coming through, which would show up in the collision latches. Or you could keep the player objects still and assert their bits one by one, checking collisions with some other object. Stuff like that.

[+SpiceWare]

OK. I'm not a VCS programmer. So, then, maybe an auto-detect routine could involve user input somehow. Dunno.

 

I'd suggested doing something like this:

 LDY #$FF
 STY STUFFVALUE (register the driver uses to configure type of bus stuffing)
 STY $80
 LDY #$00
 STY STUFFVALUE
 STY $81

---

After which analyzing the values in $80 and $81 would let you know if bus stuffing worked using one method, the other, some combination of the two, or not at all. cd-w and I set up bus stuffing to work for both TIA and RAM as stuffing RAM is handy for setting indirect jumps during the kernel, which are used for flow control. You can see a non-bus-stuffing example of that in this blog entry where I do this during the kernel using DPC+'s Fast Fetch feature:

        lda #<DS_JUMP           ; 2 29
        sta NextKernel          ; 3 32
        lda #<DS_JUMP           ; 2 34
        sta NextKernel+1        ; 3 37
...
        jmp (NextKernel)        ; 5 19 

---

With bus stuffing the 10 cycle LDA/STA/LDA/STA for setting up the jump is reduced to 6 cycles.

 

However, ZackAttack mentioned that since TIA is a different physical chip than RIOT, where RAM is located, that bus stuffing of RAM may not work the same as bus stuffing TIA.

[Keatah]

Wonder if there is something in common with the ones that fail, like a certain mfg of the chips? A certain brand of capacitor or AC adapter? Or perhaps it is a revision of the mainboard? Or maybe before/after a certain datecode, all chips fail, because of a specification change? Could even be the capacity of the noise suppression bypass caps - caps that are in parallel with VDD/VCC.

 

Maybe it even has to to with the cleanliness of the board and cartridge slot and its surrounding area?

 

Maybe power supplies are an issue, both internal regulator + capacitor AND the external wall wart.

 

All these are things to check. Would be telling to put them on a logic analyzer AND a scope. See exactly how much current and time is required to stuff a low or a high. See if anything is sloppy. See if the ARM processor can sink or source the necessary current. Change input power supply with a programmable source. One that can shape the wave to simulate ripple

 

Maybe there are pullup/pulldown resistor difference inside one or more of the chips?

 

There's a lot of things to be considered when operating a circuit in a way not originally designed. Goes with the territory.

 

---

 

When I mentioned health of the VCS, I was more or less referring to how fresh and in-spec the internals were. Maybe a unit needs to be close to falling out of spec and older for one method to work? Or closer in spec and newer for the other method to work.

 

That one test unit didn't work, at first, but did later supports all the above.

Edited March 26, 2017 by Keatah

[TheHoboInYourRoom]

It's definitely temperature-related in my case. If I run the latest test after playing a game, it works. The glitch has only happened when the Atari is cold.

[Keatah]

Maybe some frequency/oscillator is changing frequency enough to make it or break it? Maybe the VCS' clock is being skewed in relation to the ARM's clock?

[+SpiceWare]

If you install Stella 5.0.0-pre6 you can now run these demos in emulation.

[ZackAttack]

Maybe some frequency/oscillator is changing frequency enough to make it or break it? Maybe the VCS' clock is being skewed in relation to the ARM's clock?

 

I'm pretty sure we've ruled out timing related issues at this point. I was able to verify with a logic analyzer that the stuffed value is always put on the bus at least 100ns before the 6507 asserts its own value. The ARM syncs with the VCS on every VCS clock cycle so there isn't really an opportunity for them to drift apart.

 

[yell0w_lantern]

I only tested stuffing high on my Jr and my 7800.

It worked on the Jr but failed on the 7800, mirroring Nathan Strum's results on his non-Jr consoles.

[ZackAttack]

I only tested stuffing high on my Jr and my 7800.

It worked on the Jr but failed on the 7800, mirroring Nathan Strum's results on his non-Jr consoles.

That's great. Based on your previous post the Jr was the only one that failed with the stuffing low test program. So at least one of the test programs has worked on every system you own, correct? Thanks for testing this!

 

 

 

I can't download it either.

 

I posted it again here. Please try again. Thanks.

[alex_79]

Finally tested on my 7800.
Results are very similar to those of TheHoboInYourRoom: initially one bit wasn't being stuffed. It stayed that way for about 2m30s, then it gradually corrected from top to bottom in about a minute.

 

 

 

[iesposta]

Awesome alex_79!
Just like Kosmic Stardust's video of the TIA test,

where the 3rd column Star Trek Transporter materializes.

Edited April 1, 2017 by iesposta