Bus Stuffing Demos

[TheHoboInYourRoom]

Another failure on my Rev. E Jr.

After a few cycles, the scanning bar started jittering back and forth by a couple color clocks (to the right) as it scanned. This test is actually more successful when my Atari is cold (D0 of both PF1 and PF2 were stuffed correctly before this photo was taken).

[ZackAttack]

Another failure on my Rev. E Jr.

After a few cycles, the scanning bar started jittering back and forth by a couple color clocks (to the right) as it scanned. This test is actually more successful when my Atari is cold (D0 of both PF1 and PF2 were stuffed correctly before this photo was taken).

bustest-0.jpg

 

Was this with the updated version I posted this morning? DirtyHairy discovered a bug which cause things to get worse after the first cycle on systems with at least one stuff-low failure. Version 2 should fix that at least.

 

Perhaps the stuff-high code has a bug as well. I'll review the code again to be sure. If the code was working properly that screen shot would indicate that 6 of the 8 bits can't be stuffed high or low. Based on your previous test that seems to indicate the code is not working correctly.

[TheHoboInYourRoom]

It was version 1. I'll try version 2 after I get off work.

[ZackAttack]

It was version 1. I'll try version 2 after I get off work.

 

Based on your feedback I think I found another problem. Should have a version 3 posted soon. Please make sure you grab the latest when you test tonight. Thanks.

[alex_79]

Tested version 3 on my 7800 and it works, altough there's still some warm up time to make it perfectly stable. It just takes a few seconds (like, between 5 and 10), not over two minutes like in a previous test rom (here's another example with the same console)

 

Here is the result with the console just turned on:

The spots indicated by the arrows (that in the picture are on), actually flicker on and off for that short warm up time.

 

After that the image is stable and it's like this:

 

 

I must add that I just noticed that my 7800 shows slightly graphics corruption in the "2600BC" demo credits, which makes me wonder if it is starting to fail and if its behaviour is therefore the result of that fact, rather than a different hardware revision. (Sorry for the flash. Seems to be the only way to avoid the blur caused by the scrolling text)

Edited December 20, 2017 by alex_79

[DirtyHairy]

Success On my PAL Jr., the third build (didn't the the second one though) works consistently. Nice job!

[TheHoboInYourRoom]

Version 3 is a success, with a little interesting warm-up behavior.

 

Now, that first photo was taken at the end of the first cycle less than 30 seconds after turning the Atari on, so it was still cold. But a couple bits flickered slightly while the tests were running: D6 of PF1 started flickering near the end of the stuff-low test and continued during the stuff-high test, and D6 of PF2 started flickering (during the stuff-high test) about a minute after the PF1 bit did.

 

After the Atari warmed up from playing a game, there was no flickering at all. However, the image at the end of the cycle was never incorrect.

[zilog_z80a]

hi, i'm so curious...

 

what means "after atari warmed up" ?

 

thanks

[TheHoboInYourRoom]

hi, i'm so curious...

 

what means "after atari warmed up" ?

 

thanks

When the Atari is on, it generates heat and gets hotter. After a certain amount of time, it reaches a stable temperature and stops getting hotter. So, I was talking about how my Atari was behaving after it had reached that stable, warmer, temperature.

[Andromeda Stardust]

When the Atari is on, it generates heat and gets hotter. After a certain amount of time, it reaches a stable temperature and stops getting hotter. So, I was talking about how my Atari was behaving after it had reached that stable, warmer, temperature.

If the Atari acts up when cold, perhaps one can exacerbate the bad behavior by placing in a freezer overnight prior to conducting the test? Or if you're really brazen, spray the chips with coolant from an inverted duster can. I have witnessed a change occur onscreen naturally as an Atari heats up.

[ZackAttack]

Version 3 is a success, with a little interesting warm-up behavior.

bustest-1-a.jpg

 

Now, that first photo was taken at the end of the first cycle less than 30 seconds after turning the Atari on, so it was still cold. But a couple bits flickered slightly while the tests were running: D6 of PF1 started flickering near the end of the stuff-low test and continued during the stuff-high test, and D6 of PF2 started flickering (during the stuff-high test) about a minute after the PF1 bit did.

bustest-1-b.jpg

 

After the Atari warmed up from playing a game, there was no flickering at all. However, the image at the end of the cycle was never incorrect.

 

Ok, great. This is exactly what we want to see. The failures were properly detected and compensated for. Obviously the detection doesn't need to be visible or take so long but for debugging purposes it's nice to see it in action. The correction isn't applied until after the detection phase. So it's normal to see glitches at that time. The important thing is that the test pattern was always correct.

[TheHoboInYourRoom]

 

Ok, great. This is exactly what we want to see. The failures were properly detected and compensated for. Obviously the detection doesn't need to be visible or take so long but for debugging purposes it's nice to see it in action. The correction isn't applied until after the detection phase. So it's normal to see glitches at that time. The important thing is that the test pattern was always correct.

Awesome!

[iesposta]

And now we can make more great bit-mapped games like the Sillyventure 2600 game RoboMechanik (or Robo Mechanic as in the Topic)!

http://atariage.com/forums/topic/273227-robo-mechanic/

[Novastar]

All corrections work on my vader ntsc

[ZackAttack]

Tested version 3 on my 7800 and it works, altough there's still some warm up time to make it perfectly stable. It just takes a few seconds (like, between 5 and 10), not over two minutes like in a previous test rom (here's another example with the same console)

 

Here is the result with the console just turned on:

cold.jpg

The spots indicated by the arrows (that in the picture are on), actually flicker on and off for that short warm up time.

 

After that the image is stable and it's like this:

warm.jpg

 

 

I must add that I just noticed that my 7800 shows slightly graphics corruption in the "2600BC" demo credits, which makes me wonder if it is starting to fail and if its behaviour is therefore the result of that fact, rather than a different hardware revision. (Sorry for the flash. Seems to be the only way to avoid the blur caused by the scrolling text)

P1070064.JPG

P1070066.JPG

P1070067.JPG

 

How many low and high failures where there during the first detection phase? And which bits failed? If you look at Hobo's screenshot you can see that D6 had a stuff high failure, I assume this would have also appeared as a failure on the stuff low step before it too.

 

If detection is working properly it indicates your system had 3 bits which failed both high and low. Two of them would have been corrected by varying which register is stored and the third would still appear as a glitch. Most significant bits are corrected first in order to minimize the magnitude of the glitches. For PF it doesn't matter, but for color, move and other TIA registers it would.

 

If it's a detection issue, I could cycle through all 128 values for each bit a few times to improve the chance of detecting the intermittent failures. It appears that this failure only occurs when the value being stuffed is $fc, and even then it's only some of the time. I was also thinking about including a mechanism to allow the detection to be rerun at any given time. Just in case something changes after playing a game for a while.

 

In my notes from the last round of testing it was the systems that TheHoboInYourRoom ​and alex_79 tested which were the most problematic. One is already working completely and the other is very close. We'll need to refine the driver some and test across a broader range of systems. Looks like we will be successful soon enough.

[MayDay]

Sadly, it doesnt seem to fix my problematic Jr. This sequence plays in a loop, so I took a video of one iteration. It looks okay for a bit, then goes into a loop, looks okay again for a bit, then does it again.

[ZackAttack]

Sadly, it doesnt seem to fix my problematic Jr. This sequence plays in a loop, so I took a video of one iteration. It looks okay for a bit, then goes into a loop, looks okay again for a bit, then does it again.

 

Thanks for posting the video. That is very helpful. During the stuff-low sweep D6 should be detected as a failure but it's not failing when $00 is stuffed. Looks like this is the same problem that alex_79 has. Had it been properly detected I'm certain the correction routine would have fixed it.

 

Should be a simple change to include all 128 values in the detection routine. I'll try to post a new version soon.

[alex_79]

 

How many low and high failures where there during the first detection phase? And which bits failed?

 

bit 7 isn't stuffed low, while all bits seems to be stuffed high.

 

Video attached (you can see bit 0 of pf2 flicker a bit in a few spot at about 9 sec):

7800_bus_test.zip

[ZackAttack]

Tested version 3 on my 7800 and it works, altough there's still some warm up time to make it perfectly stable.

 

Sadly, it doesnt seem to fix my problematic Jr. This sequence plays in a loop, so I took a video of one iteration. It looks okay for a bit, then goes into a loop, looks okay again for a bit, then does it again.

Ok, version 4 has improved the detection algorithm based on your feedback. Please try it out.

[alex_79]

Works!

This is the result after the first detection phase (the console has been powered off for about 30 min before the test) .

Edited December 21, 2017 by alex_79

[MayDay]

Bus Stuffing Test V4.

[ZackAttack]

Bus Stuffing Test V4.

Great! That system has 7 low failures which are all switched over to high and then it works fine.

[WIZZARD77]

Here is the results on my 4 Switch

Edited December 24, 2017 by WIZZARD77

[minimoose]

Great! That system has 7 low failures which are all switched over to high and then it works fine.

ZackAttack, you are a genius!

 

How about an update?

 

-minimoose

[ZackAttack]

How about an update?

There's still a lot to finalize before this could go mainstream, but at least at this point it's been shown to work on every system that we've tried. Unfortunately I'm not sure how to retrofit this to the original BUS driver or if it will even be possible. In order to make it work for the problematic systems the opcode used has to be calculated on the fly and only some of the bits are stuffed. This is dependent on the value being stuffed so it can't be calculated until we know what value is going to be stuffed in.

 

I've been working with MayDay to build a fighting game based on this technology. Hopefully we'll be posting a playable demo in the next month or two. We did post a test rom of the background last month which uses bus stuffing to draw the background.

 

Despite everything being written in C it is not any easier to write games with this new driver. Now instead of just racing the beam the ARM MCU is racing the 6507 while the 6507 is racing the beam.