Bus Stuffing Demos

[Bus Stuffing Demos]

I'll give it a good cleaning and report back tomorrow.

No improvement, by the way.

 

This is all I can get:

[Bus Stuffing Demos]

 

 

Isopropyl alcohol and a cotton swab.

I know about that method; used it on the Harmony. For some reason I thought the connector was too thin to accommodate a swab, but I just checked and it'll be fine.

 

I'll give it a good cleaning and report back tomorrow.

[Bus Stuffing Demos]

 

Noting that it takes only 39 ohms of resistance between the harmony cartridge and the data bus to break bus stuffing, it's important to have the contacts perfectly clean on both the Harmony cartridge and on the 2600 cartridge connector. I've seen oxidation on connector contacts introduce 50 ohms or more of resistance.

Do you happen to know a good, halfway-convenient way to clean the connector? Cartridges are easy, but I've never actually done the connector.

[Bus Stuffing Demos]

I followed SpiceWare's suggestion and cleaned my Harmony, and the results were slightly better than my first try, but about half the bits are still always high, with the same chaotic flickering in places. Running the parrot test actually showed some appreciable brightness gradients, mostly in the columns that had the "dark areas" I reported earlier.

[Testing CRT Screen Size]

27" Sharp NTSC (early 2000s), using v1.1

Cold: 22, 225, 15

Warm: 23, 226, 13

[Season 6 - The New HSC - Week 2 = Millipede]

Well, good to see you're all doing really well. I have no idea how; this game is really, really hard.

Patience and facial contortions.

[Season 6 - The New HSC - Week 2 = Millipede]

Getting better.

 

171,705

[Season 6 - The New HSC - Week 2 = Millipede]

I've never played much of Millipede before. It's really fun!

 

123,882

[Season 6 - The New HSC - Week 1 = Missile Command]

Kept putting this off. I tried.

 

33,400 - 4B

[Bus Stuffing Demos]

You're welcome. Fingers crossed!

[Bus Stuffing Demos]

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

[Bus Stuffing Demos]

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?

[Bus Stuffing Demos]

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.

[Bus Stuffing Demos]

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.

[Bus Stuffing Demos]

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

 

[Space Taxi]

 

• Is there a difference in acceptance among the player base?

 

On AtariAge? Not likely.

 

If you want to go all out, follow your heart!

[When does season 6 start?]

Finally decided to get involved in this. Can't wait!

[Stella 4.7.3 released]

Do you have any SHA checksums we could check for the new release?

[Cat Quest 2600 (WIP)]

But don't you also save cycles by not having to point to / load different PF data? (I really need to learn basic kernel techniques. )

Yeah, you do. I misinterpreted your meaning a bit.

[Cat Quest 2600 (WIP)]

The Playfield pixels mirrored use less cycles, or is it just less time critical when the write is made?

Less time-critical, if it isn't asymmetric.

[Cat Quest 2600 (WIP)]

Ooh, neat. This looks like a project worth following.

[WIP: Dodgeball]

I found a bug which I presume has to do with the way the Pong reflections are computed. It shows up when either player throws their ball in a direction that has an upward or leftward component (that is: up-right, up, up-left, left, down-left) while the player is also butting up against a wall, so that the ball has no room to move before a collision happens. The screenshot below was taken after the green player had thrown its ball due left normally (with room for the ball to travel for a few frames) against the far left wall, and the ball was at rest. However, if the player had instead thrown the ball in the same direction while butted up against the wall, the ball's position seen in the screenshot would be where it would *start* flying from. It's as if the game short-circuited through 64 frames' worth of collision detection before rendering the ball, and then did it again normally for another 64 frames. Perhaps it's related to the decay-reset bug?

 

The bug does not happen when the ball is thrown right, down-right, or down. I also replicated it on real hardware.

 

 

 

Changing topic, it feels weird that after dropping your ball ("throwing" with no direction) you can't pick it up again until the throw decay ends. Is that on purpose?

[Post-menu random number generation]

Thanks for your help, everyone. I'm almost certainly going to use an LFSR.

 

With Harmony, the RAM area is completely used for the stall code, displaying the Yin-Yang symbol.

That's weird, my Harmony has never shown the yin-yang.

The loading latency, though, is unpredictable, right?

[Post-menu random number generation]

I have a concept for a VCS game that would rely on an RNG in at least a couple crucial ways. I know from using Omegamatrix's startup values program that the Harmony ROM selection menu will repeatably leave the RAM in a certain state, which I'm sure depends on where a particular ROM happens to be in the file system, but it's still deterministic. Maze Craze will also more often than not produce one particular first maze, and this can change based on how I traverse the file menu before selecting it.

 

So I'm wondering what the best source for a random seed would be to ensure good RNG performance no matter if a game is running on a Harmony with the menu BIOS, a Harmony in single-image mode, or (possibly in the future) a dedicated cartridge. My first guess would be to almost immediately sample INTIM and store the value, say, at the top of RAM and skip over that byte in the init routine. Is the latency of ROM loading unpredictable enough to make that a viable strategy?

[Best reference for DASM's illegal opcodes?]

Another option is to look at DASM's source. This file has illegal opcode mnemonics in an array called Mne6502illegal[], except for the illegal NOP addressing modes (related to what Omegamatrix said). Might be useful since there's not much standardization of the actual mnemonics.