Jump to content
IGNORED

Bus Stuffing Demos


SpiceWare

Recommended Posts

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

post-6010-0-45516400-1513790244_thumb.jpg

Link to comment
Share on other sites

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

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

Link to comment
Share on other sites

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:

post-10599-0-18311400-1513806205.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:

post-10599-0-85580900-1513806227.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)

post-10599-0-02189700-1513806407.jpg

post-10599-0-35075300-1513806415.jpg

post-10599-0-27645700-1513806422.jpg

Edited by alex_79
  • Like 1
Link to comment
Share on other sites

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

post-6010-0-07650800-1513814850_thumb.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.

post-6010-0-53714300-1513814876_thumb.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.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

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

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

Link to comment
Share on other sites

 

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!

Link to comment
Share on other sites

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:

attachicon.gifcold.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:

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

attachicon.gifP1070064.JPG

attachicon.gifP1070066.JPG

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

  • Like 2
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

  • 1 month later...

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.

  • Like 4
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...