Bus Stuffing Demos

[+SpiceWare]

That warmup period is problematic, would crash my kernels as they bus-stuff jump addresses to RAM.

 

 

Could work around that by using a traditional 7 cycle LDA DS0DATA/STA RAM.

[ZackAttack]

I'm calling it a success. Hopefully everyone agrees.

 

Could always enhance the driver to include a "fast jump" feature.

 

JMP FastJump would be detected and the 2 byte address is pulled from ARM memory instead of the ROM. Similar to how fast fetch works.

[Andromeda Stardust]

Tested on my Best AV modded 7800 using a pre-release Concerto cart loaded with Harmony 1.06 BIOS:

 

As you can see, there are lines missing on the Sports Car screengrab, but not the "High" Test. Currently I am unable to test the demos on my 4-switch VCS as my old Harmony cart is MIA and the Concerto PCB won't fit without permanent alteration of the board.

[+SpiceWare]

Tested on my Best AV modded 7800

Looks good! Toggle the Right Difficulty switch to change the colors in the first image, set the way you have it lets you see which player is used to draw which part of the image.

 

As you can see, there are lines missing on the Sports Car screengrab, but not the "High" Test.

Actually, my car looks just fine. Those lines aren't caused by faulty bus stuffing - they're a side affect of having to use flickerblinds to draw 96+ pixels on the Atari. You can see them in these photos from my 7800:

 

 

you can see the source of the lines here, where I modified the chronocolour demo to display all pixels and to use a single color. One image is the even frame, the other odd:

[Andromeda Stardust]

^^I honestly don't know. One really impressive effect however is when the full color blend image, the RGB 20Hz flicker is pretty gross to the naked eye, yet it blends smoothly with the longer exposure setting on my digital camera, which can have a longer persistence of image than the human eye under low lighting conditions.

 

Not shown, the RPG demo had dark lines between vertical tiles, so it may or may not be bit 7 again like another user posted. Cool to have full motion; the graphics looked almost Coleco quality.

[+SpiceWare]

^^I honestly don't know.

I do know, if it was a bus stuffing issue you'd see the problem repeating every 8 pixels.

 

One really impressive effect however is when the full color blend image, the RGB 20Hz flicker is pretty gross to the naked eye, yet it blends smoothly with the longer exposure setting on my digital camera, which can have a longer persistence of image than the human eye under low lighting conditions.

Yep, that's how I took my earlier photo of it.

 

Not shown, the RPG demo had dark lines between vertical tiles, so it may or may not be bit 7 again like another user posted. Cool to have full motion; the graphics looked almost Coleco quality.

 

The RPG demo uses a different player layout than the 128 pixel demo - take a look at the road, swamp, or water - every 8 pixels is up/down a row from the 8 pixels to the left:

 

Like the car demo, the pixels drawn alternate every frame. With the player layout in RPG you'll see 8 pixels, gap, 8 pixels, gap, ... repeated across the screen - thus the problem is every "9" pixels, not 8, so it's not bus stuffing. This gap is noticeable on all 2600s I've seen, I think the difference in just how noticeable is due to some combination of console type(sixer/4-switch/junior/7800), connection type (rf, S-Video, composite), and display. Here's a closeup from my 2600 with CyberTech S-Video mod on my C= 1084S - four gaps are noticeable in the horizontal section of bricks:

 

Represented as text, the player (sprite) layout is this with 0 and 1 representing the 2600's two players for the RPG demo:

0 1 0 1 0 1 
 0 1 0 1 0 1

---

and this for the car demo:

0 0 1 1010 0   1
 0 0 1    0 010 

---

The gap occurs when players are not drawn next to each other, thus the car demo is does not have gaps in the sections drawn using 1010 and 010.

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

 

going-high.jpg

The sequence is actually a bit weirder than this. I ran the test again cold, within a couple seconds of turning on the Atari. At first both halves of the test, the 1- and 7-bit stuffing, fail on the same bit (D6). Within a minute the 1-bit stuffs to PF1 correct themselves (possibly top to bottom, but I don't know since I can only see one row correcting) and only some minutes later did the 7-bit stuffs to PF2 correct as I previously described. It's pretty sensitive to room temperature, it seems.

[Andromeda Stardust]

I do know, if it was a bus stuffing issue you'd see the problem repeating every 8 pixels.

 

Yep, that's how I took my earlier photo of it.

 

 

The RPG demo uses a different player layout than the 128 pixel demo - take a look at the road, swamp, or water - every 8 pixels is up/down a row from the 8 pixels to the left:

 

Like the car demo, the pixels drawn alternate every frame. With the player layout in RPG you'll see 8 pixels, gap, 8 pixels, gap, ... repeated across the screen - thus the problem is every "9" pixels, not 8, so it's not bus stuffing. This gap is noticeable on all 2600s I've seen, I think the difference in just how noticeable is due to some combination of console type(sixer/4-switch/junior/7800), connection type (rf, S-Video, composite), and display. Here's a closeup from my 2600 with CyberTech S-Video mod on my C= 1084S - four gaps are noticeable in the horizontal section of bricks:

IMG_8501.jpg

 

Represented as text, the player (sprite) layout is this with 0 and 1 representing the 2600's two players for the RPG demo:

0 1 0 1 0 1 
 0 1 0 1 0 1

---

and this for the car demo:

0 0 1 1010 0   1
 0 0 1    0 010 

---

The gap occurs when players are not drawn next to each other, thus the car demo is does not have gaps in the sections drawn using 1010 and 010.

So, the RPG demo is drawn in 8 pixel blocks every 9 pixels? Weird. So every ninth pixel being blacked out is an intended side effect. I did not realize that.

 

So it appears I have a "very good" 7800 when it comes to bus stuffing. That is positive news, given the ROM corruption issues I and others had with Concerto, prior to simply flashing the Harmony BIOS on it.

[cd-w]

So, the RPG demo is drawn in 8 pixel blocks every 9 pixels? Weird. So every ninth pixel being blacked out is an intended side effect. I did not realize that. So it appears I have a "very good" 7800 when it comes to bus stuffing. That is positive news, given the ROM corruption issues I and others had with Concerto, prior to simply flashing the Harmony BIOS on it.

It is 8 pixel blocks with a gap of 8 pixels. The CRT is not very precise at switching the beam off and on, so you see a gap. The effect is less visible on some TVs and if the console has a svideo or rgb mod.

 

Chris

[+SpiceWare]

As cd-w says, it's 8 pixels drawn, then 8 pixels not drawn. There's no 9th pixel, the gap's just a video artifact caused by using flicker.

 

You can even see it in Stella (BUS support added to 5.0.0-pre6) if you have the phosphor mode turned off:

 

While you can see it, it's clear in Stella that the gap is smaller than a pixel.

[+SpiceWare]

BUS is a work in progress and we made a change that broke backwards compatibility in Stella. As such the demos would work on Stella 5.0.0-Pre6 and Pre7, but not on anything after that.

 

I've updated the RPG demo for the new spec, as well as the new C compiler we're using, so it can now be run in Pre8 or Pre9. I'll update the other demos to the current BUS driver over the next week.

rpg_20170616_NTSC.bin

rpg_20170616_PAL.bin

[Andromeda Stardust]

Cool, I'll have to check these out...

 

Do you think any of the bus stuff demos will run on the Retron77?

[+SpiceWare]

I would be very surprised if they ran on the Retron77

[cd-w]

Fred has come up with a possible fix for bus stuffing on problematic 2600Jr consoles. Can someone with a problematic Jr run the attached binary from their Harmony cart and post a photo of the results?

 

Thanks,

Chris

 

bustester00_bin.zip

Edited October 22, 2017 by cd-w

[TheHoboInYourRoom]

I ran this while my Atari was still cold. There was no change after warming up.

[iesposta]

I ran this while my Atari was still cold. There was no change after warming up.

bustester.jpg

 

That's a shame that it fails.

It will not happen, but games and demos should be made even if they only work on VCS/Vader systems.

 

Atari developed BUS for The Graduate computer attachment which they shelved.

The Graduate would fit the woody / Vader Atari 2600.

 

Atari the company changed hands, and released the 2600 Jr. 9 years after the VCS release.

Atari the company released the Atari Flashback Portable 39 years after the VCS.

[DirtyHairy]

This is how it looks on my PAL Jr. (on our LCD). It looks like bit 7 is stuck (as it was before on my machine), and the sprite used for the diagonal lines enters starfield mode on my TIA

 

Edited October 22, 2017 by DirtyHairy

[cd-w]

I ran this while my Atari was still cold. There was no change after warming up.

 

This is how it looks on my PAL Jr. (on our LCD). It looks like bit 7 is stuck (as it was before on my machine), and the sprite used for the diagonal lines enters starfield mode on my TIA

 

Thanks for testing - it looks like we are not yet there Fred is now looking to obtain his own problematic Jr consoles to help him diagnose the issues.

 

Chris

[Thomas Jentzsch]

This is how it looks on my PAL Jr. (on our LCD). It looks like bit 7 is stuck (as it was before on my machine), and the sprite used for the diagonal lines enters starfield mode on my TIA

That's interesting.

 

Maybe the research for bus stuffing could be also used for a more reliable/controlled starfield generation/emulation on all console types?

[DirtyHairy]

 

 

Thanks for testing - it looks like we are not yet there Fred is now looking to obtain his own problematic Jr consoles to help him diagnose the issues.

 

You're welcome. I am currently swamped in other things, so this won't happen soon, but I have been thinking about getting a cheap logic analyzer and looking at the bus myself.

 

Maybe the research for bus stuffing could be also used for a more reliable/controlled starfield generation/emulation on all console types?

 

I thought I understood pretty well how the startfield is triggered by now (not talking about the substructure), but obviously, something funky is going on with my TIA here. I'd like to play around a bit with the source of the test ROM to find out whether this is related to bus stuffing at all or rather a random find of a timing glitch.

Edited October 23, 2017 by DirtyHairy

[alex_79]

I get the same result as DirtyHairy on my 7800:

I also have two jr consoles (one made in 1984, the other one in 1991); the test rom works fine on both of them.

[ZackAttack]

Here's another attempt which combines my prototype driver, stuffing high and low, detection of failures, and an idea Fred had to use multiple registers and illegal opcodes to correct up to 2 bits. Hopefully this will work on all the machines that previously ran into issues.

 

This must be run on a harmony cart. Emulators will not know how to load it.

 

Current build:

stuff-with-detection-and-correction4.bin

 

Previous builds:

stuff-with-detection-and-correction3.bin

stuff-with-detection-and-correction2.bin

stuff-with-detection-and-correction1.bin

 

When you first load the rom it will have some vertical lines on the sides, a test pattern in PF1 and PF2 should be black. A blue bar will sweep across part of the screen. This is the program using collision detection to determine if there are any bits which can't be stuffed low. The blue bar should turn red if a failure is detected.

 

Next pf2 should be all on. Any bits that were detected as low failures will now switch to being stuffed high. The blue bar sweeps the screen again to detect high failures this time and will turn red as soon as it finds any.

 

Once the detection is complete, the algorithm will find the optimal combination of stuffing low, high, and using different store instructions. It will then attempt to display the test pattern with this optimal combination. If all is well there should only be the vertical bars on the sides of the screen were PF0 is. The rest of it should look like the picture below.

 

The program will repeat a cycle of low detection, high detection, test pattern indefinitely. However, the correction values are retained, so there shouldn't be any more failures detected after the first iteration if it finds a correct combination to use.

 

 

Edit:

12/21 version 4 improves failure detection so stuffing high and low are checked with all 128 values for each data bit multiple times. Should now detect intermittent failures much better.

12/20 version 3 makes P0 positioning more robust, completely restarts detection each cycles, fixes stuff-high driver bug

Version 2 fixes bug that corrupted state in subsequent passes

 

Edited December 21, 2017 by ZackAttack

[DirtyHairy]

Success... sort of On my PAL Jr. the first pass reliably ends with the correct test picture. All subsequent runs display two black bars (see my photo below) but, as the first test picture is fine, I suspect that this is not an issue with the algorithm itself, but merely a bug in the subsequent passes.

 

[ZackAttack]

Success... sort of On my PAL Jr. the first pass reliably ends with the correct test picture. All subsequent runs display two black bars (see my photo below) but, as the first test picture is fine, I suspect that this is not an issue with the algorithm itself, but merely a bug in the subsequent passes.

 

IMG_20171219_233431.jpg

Would you post a video of the first few iterations? Hopefully it can help me find the bug.

 

This is exciting. We may be close to a workable solution.

[DirtyHairy]

Would you post a video of the first few iterations? Hopefully it can help me find the bug.

 

This is exciting. We may be close to a workable solution.

 

 

I'll add it to my backlog, might take a few days though Agreed, very good work, I am confident that this nails the issue on my VCS.