Bus Stuffing Demos

[+SpiceWare]

Updated the 128 pixel demo!

• additional 128x100 image
• additional 128x200 image
• blitter demo (virtual sprites)
• fixed bug in 128x200 datastream setup, the column offsets were reversed.

128x200 image:

 

was originally getting displayed like this:

 

the image now displays correctly:

 

In the blitter demo use the left difficult to control speed

 

128bus_20170119.bin

[Andromeda Stardust]

I finally tested the updated demos posted in the last couple of weeks on my 7800 and my Light Sixer.

 

Unfortunately my 7800 still shows extra vertical lines. Apparently bus-stuffing doesn't work correctly on my machine and bit 7 on the data bus seems to always be set.

 

rpg_20161231_PAL:

 

7800:

rpg20161231_PAL_A78.JPG

2600:

rpg20161231_PAL_L6.JPGrpg20161231_PAL_L6-2.JPG

-------------------------------------------------------

parrot_20161231_PAL:

7800:

parrot_20161231_PAL_A78.JPG

2600:

parrot_20161231_PAL_L6.JPG

--------------------------------------------------------

test_20161231:

7800:

test_20161231_A78.JPG

2600:

test_20161231_L6.JPG

--------------------------------------------------------

128chronocolour_20170101:

7800:

128chronocolour_20170101_A78.JPG

2600:

128chronocolour_20170101_L6.JPG

--------------------------------------------------------

128chronocolour_20170101b:

7800:

128chronocolour_20170101b_A78.JPG

2600

128chronocolour_20170101b_L6.JPG

 

--------------------------------------------------------

128bus_20170102:

7800:

128bus_20170102_A78-1.JPG128bus_20170102_A78-2.JPG128bus_20170102_A78-3.JPG128bus_20170102_A78-4.JPG

2600:

128bus_20170102_L6-1.JPG128bus_20170102_L6-2.JPG128bus_20170102_L6-3.JPG128bus_20170102_L6-4.JPG

 

 

What on earth is causing the jailbars on the 7800???

[+SpiceWare]

What on earth is causing the jailbars on the 7800???

 

 

For some reason bit 7 isn't getting "stuffed". It doesn't happen on my 7800, so it's not a problem with all of them. Possibly it's only an issue for PAL 7800 consoles.

[+SpiceWare]

Another update to the 128 pixel demo.

• move joystick to change color
• revised blitter demo which, as covered below, shows some major shortcomings to the 128 pixel display

 

For the joystick left/right controls color, up/down controls luma. The last 2 characters on the first line of the text demo is the current color value, 5E in this screenshot:


The 128x100 Galaga image:


The 128x200 Galaga image:


The blitter demo has 3 additional rows of images:


The rows are:

• sprite images for 128x200 moving over 128x200
• sprite images for 128x200 moving over 128x100
• sprite images for 128x100 moving over 128x200
• sprite images for 128x100 moving over 128x100

128x200 images can be considered 1LK images
128x100 images can be considered 2LK images

 

moving over 128x200 means 200 distinct Y locations
moving over 128x100 means 100 distinct Y locations

There's now 3 movement patterns:

• horizontal
• vertical
• horizontal & vertical

Additionally the left difficulty switch control of the movement is now set for A = 30 fps (used to be 15) and B = 60 fps

 

The vertical movement patterns show some major shortcomings to using an interlaced bitmap display for an action game. Let me know what you think - be sure to toggle the left difficulty switch to see the impact of different movement speeds.

 

ROM

128bus_20170120.bin

[+SpiceWare]

For those who have tested this which row, top=1 and bottom = 4, looks best to you over all movement examples? I'm leaning towards one of them, and am wondering if everybody else sees the same thing. Remember to run it with the Left Difficulty switch in both positions to see the impact different movement speeds have.

 

 

 

 

[alex_79]

The 3rd row looks better in my opinion, as it's the one that's less affected in vertical movements.
With the speed at 30fps the interlacing causes also artifacting in horizontal-only movement (in all 4 rows, but most visible in 3 and 4).

[+SpiceWare]

30 downloads so far. I'm still waiting for additional feedback to decide if it's worth proceeding with Cicada...

 

 

[Andromeda Stardust]

30 downloads so far. I'm still waiting for additional feedback to decide if it's worth proceeding with Cicada...

 

 

It's worth it. So I guess the ARM will handle all of the game logic and just set up all the sprite data in RAM to be loaded each screen. The potential to have a 60Hz display kernel will be epic. And I'm aware the colors will be out of sync when the enemies dance or dive bomb the player's ship. I think a monocrome "game boy" mode with green or blue hues (like the buss stuffing preview) would be grand. Maybe cycle through the color options in the menu?

 

Unfortunately I appear to have misplaced my Harmony cart, so I can't test these awesome demos at this time...

[+SpiceWare]

So I guess the ARM will handle all of the game logic and just set up all the sprite data in RAM to be loaded each screen.

correct, just like with Space Rocks and Stay Frosty 2, though the 6507 code will be using Bus Stuffing instead of DPC+.

 

The potential to have a 60Hz display kernel will be epic.

Therein lies the problem - two alternating frames, thus 30 Hz flicker, must be used in order to generate a 128x200 display. This is just like the RPG demo, see screenshots in reply #5 though that's only 96 pixels across so it can update the color as well.

 

The issue with the 30 Hz flicker is it causes some really bizarre visual effects when the objects move around:

 

For slower games like the RPG it's not a problem, but for faster games like this I'm not sure it's worth proceeding and thus have asked for feedback from people who've seen it. Only one reply so far, so it seems like the answer is the visual effects are to distracting, thus not worth pursuing.

[TheHoboInYourRoom]

It doesn't work on my system. Looks like bits 6 to 3 aren't coming through. NTSC 2600 Jr.

 

[+SpiceWare]

Hmm, that's worse than alex_79's 7800

 

Have you tried any of the other demos? I'm also curious if the older demos, from before the 7800 fix, behave differently.

[Andromeda Stardust]

correct, just like with Space Rocks and Stay Frosty 2, though the 6507 code will be using Bus Stuffing instead of DPC+.

 

Therein lies the problem - two alternating frames, thus 30 Hz flicker, must be used in order to generate a 128x200 display. This is just like the RPG demo, see screenshots in reply #5 though that's only 96 pixels across so it can update the color as well.

 

The issue with the 30 Hz flicker is it causes some really bizarre visual effects when the objects move around:

128bus_20170120.png

 

For slower games like the RPG it's not a problem, but for faster games like this I'm not sure it's worth proceeding and thus have asked for feedback from people who've seen it. Only one reply so far, so it seems like the answer is the visual effects are to distracting, thus not worth pursuing.

And the venetian blinds effect will look bad on HDTVs. Just saying...

[TheHoboInYourRoom]

Hmm, that's worse than alex_79's 7800

 

Have you tried any of the other demos? I'm also curious if the older demos, from before the 7800 fix, behave differently.

These are both from A Programming CHALLENGE post #96:

 

test_bus_NTSC.bin

 

parrot_bus_NTSC.bin

 

The dark-colored areas are somewhat unpredictable, usually flashing in a complicated way between the dark bluish color and the "normal" color my Atari is putting out. I tested them again today and more dark areas showed up.

 

I took a closer look at 128bus_20170120.bin and actually five bits of each byte (D6-D2) aren't coming through. There's some subtle chaotic interaction with other bits that turns off a few of the "blocked" ones, most evidently in the line-drawing demo; I'm pretty sure the affected bits are drawn with the same player objects, like a write to GRPx slightly influencing future writes.

[+SpiceWare]

Bummer, but thanks for testing! I thought there might be a slight chance that the changes to make it work with my evil 7800 caused an issue for your Jr, but that's not the case. I've pinged cd-w about it to see if he has any ideas.

[TheHoboInYourRoom]

I just tried parrot_20161231_NTSC.bin and got exactly the same result.

 

EDIT: I don't know if this is relevant, but the dark areas show up more solidly (less of the normal colors) if I push the fire button or joystick directions; the effect is strongest when I push left. I'm using a 3-button Genesis pad.

Edited January 25, 2017 by TheHoboInYourRoom

[+SpiceWare]

I just tried parrot_20161231_NTSC.bin and got exactly the same result.

 

EDIT: I don't know if this is relevant, but the dark areas show up more solidly (less of the normal colors) if I push the fire button or joystick directions; the effect is strongest when I push left. I'm using a 3-button Genesis pad.

Can you open up your Jr and take photos? Chris is wondering if it's one of the rare 1-chip variations.

[TheHoboInYourRoom]

Can you open up your Jr and take photos? Chris is wondering if it's one of the rare 1-chip variations.

I have the motherboard out, but I haven't dared to undo the tabs holding the shielding in place. I can tell you immediately it has 3 separate chips. You probably need to see the exact part number for the TIA, don't you?

[+SpiceWare]

I have the motherboard out, but I haven't dared to undo the tabs holding the shielding in place. I can tell you immediately it has 3 separate chips. You probably need to see the exact part number for the TIA, don't you?

 

 

Post photos of what you can, it might give us enough information.

[TheHoboInYourRoom]

Well, these are the photos I took; I tried to get decent coverage of the space underneath the shielding. I was able to read the part numbers with a flashlight at an extreme slant.

 

 

The chipset is Taiwanese. Here are all three part numbers for completeness:

 

RIOT

8733S

UM6532

 

CPU

STK 6507

8733

 

TIA

8733S

UM6526N

Edited January 27, 2017 by TheHoboInYourRoom

[+SpiceWare]

Thanks! That's a lot more info than I thought you'd be able to get

 

Hopefully we can figure something out, else it might end up derailing Bus Stuffing.

[TheHoboInYourRoom]

You're welcome. Fingers crossed!

[ZackAttack]

I see two possible causes to this problem. Either the timing is off or the electrical aspects make it impossible to force some of the data lines low. Ideally you'd have access to the problematic system and a logic analyzer to figure this out. However, since that is likely not feasible I'm proposing the creation of a test program that can be used to determine which one is causing the problem.

 

This program would initialize all the ZP RAM to $FF, hold the data bus low for a second, and then display what's in ZP RAM as PF pixels. Since the data bus is being stuffed with $00 for over a million clock cycles it removes timing from the equation. This will work because $00 is the BRK statement. That means the system will continually push PC+2 and the status register until a non break command is given. That should make it hit every RAM address in the stack page. What ends up in the RAM will indicate if the cart is electricaly capable of forcing the bus low.

 

A solid background color would indicate a timing issue. The appearance of any PF pixels would indicate the cart/system combination is not electrically capable of driving the entire data bus low.

 

Psuedo code:

Reset:
Set $00 to $7f to 0
Set $80 to $ff to $ff
Set status register to $ff (or as close to that as possible)

Drive data bus to $00
Sleep for 1 second (data bus must be left $00 during this time. I.E. disable IRQ handlers that would cause otherwise)

Resume normal ROM emulation mode. BRK vector should point to here.
Break:
do vsync
set TIA regs back to 0
set COLUBK and COLUPF to something that will have contrast on NTSC and PAL.
do vblank
LDX #0
TXS
LDY #192
drawline:
PLA
STA PF1
DEY
BNE drawline
do overscan
JMP Break

[Crispy]

I ran the 128bus_20170120.bin file on my 2600 Jr., and this is what I see.

 

 

After reading about some of the issues reported here I was curious about how the data bus was behaving during the data contention that bus stuffing creates. I looked at the data bus on my 2600 four switch, and here's what I saw on the scope. Unfortunately I can't hook my four switch up to a TV to see how the image looks since I currently have a whole bunch of parts unsoldered.

 

 

The voltage level at the TIA data pin is being pulled down to 0.92 V by the Harmony cartridge. Following the specs for the 6502, that exceeds the maximum voltage for a valid logic low by 0.12 V. However, we're really interested in how the TIA handles this. Unfortunately I can't find any published specs related to the low level voltage for the TIA. Obviously we're seeing bus stuffing working on most machines, but I get the feeling that things are right on the edge.

 

I'd like to do some more testing. Would you be able to create a bus stuffing demo that puts a single black pixel somewhere in the middle of each scan line? In other words, write $FF to GRPx except for one write near the middle of the line. Here you would write $FE. This would have the effect of creating a single pixel wide vertical black line positioned roughly in the middle of the screen, and would provide a single event to trigger my scope on. With this I can figure out how much margin there is before bus stuffing breaks.

 

Also, I had a thought about those who have machines that can't handle bus stuffing. It's possible that cleaning the cartridge connector may fix the issue. Oxidation build up on the cartridge contacts will introduce additional resistance between the cartridge and the data bus, and could be enough to keep the voltage from going to low enough to count as a logic low.

Edited January 31, 2017 by Crispy

[+SpiceWare]

I ran the 128bus_20170120.bin file on my 2600 Jr., and this is what I see.

 

...

Looks right to me.

 

Interesting. I'm not much into the hardware side of things, hopefully this info will useful for Chris and Fred. Thanks!

 

I'd like to do some more testing. Would you be able to create a bus stuffing demo that puts a single black pixel somewhere in the middle of each scan line? In other words, write $FF to GRPx except for one write near the middle of the line. Here you would write $FE. This would have the effect of creating a single pixel wide vertical black line positioned roughly in the middle of the screen, and would provide a single event to trigger my scope on. With this I can figure out how much margin there is before bus stuffing breaks.

Sure thing:

128bus_20170130.bin

 

This screen's after the moving Galaga demo:

 

Of course it's really alternating between these two screens:

 

Also, I had a thought about those who have machines that can't handle bus stuffing. It's possible that cleaning the cartridge connector may fix the issue. Oxidation build up on the cartridge contacts will introduce additional resistance between the cartridge and the data bus, and could be enough to keep the voltage from going to low enough to count as a logic low.

Good idea, I've noticed I need to clean my Harmony's contacts every few months. Been a while, so just did - it was quite dirty:

 

Thanks again!

[Andromeda Stardust]

I ran the 128bus_20170120.bin file on my 2600 Jr., and this is what I see.

 

2600Jr_stuff-1.jpg

 

After reading about some of the issues reported here I was curious about how the data bus was behaving during the data contention that bus stuffing creates. I looked at the data bus on my 2600 four switch, and here's what I saw on the scope. Unfortunately I can't hook my four switch up to a TV to see how the image looks since I currently have a whole bunch of parts unsoldered.

 

2600-4SW-Stuff.JPG

 

The voltage level at the TIA data pin is being pulled down to 0.92 V by the Harmony cartridge. Following the specs for the 6502, that exceeds the maximum voltage for a valid logic low by 0.12 V. However, we're really interested in how the TIA handles this. Unfortunately I can't find any published specs related to the low level voltage for the TIA. Obviously we're seeing bus stuffing working on most machines, but I get the feeling that things are right on the edge.

 

I'd like to do some more testing. Would you be able to create a bus stuffing demo that puts a single black pixel somewhere in the middle of each scan line? In other words, write $FF to GRPx except for one write near the middle of the line. Here you would write $FE. This would have the effect of creating a single pixel wide vertical black line positioned roughly in the middle of the screen, and would provide a single event to trigger my scope on. With this I can figure out how much margin there is before bus stuffing breaks.

 

Also, I had a thought about those who have machines that can't handle bus stuffing. It's possible that cleaning the cartridge connector may fix the issue. Oxidation build up on the cartridge contacts will introduce additional resistance between the cartridge and the data bus, and could be enough to keep the voltage from going to low enough to count as a logic low.

Could it also be like one of those issues where the timing actually changes as the system warms up? For instance the following video demonstrates this effect. An obscure timing bug changes as the console operates. 1:25 for the money shot: