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.

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.

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

On AtariAge? Not likely. If you want to go all out, follow your heart!

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

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

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

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

It's fair to say I've neglected this blog. But now I'm using it, so that's cool. You probably shouldn't expect updates to be regular. I'm finally taking the first steps in writing an actual game for the VCS, and I'm doing it from the inside out, more or less. Making sure the individual effects and modules work, and that I thoroughly understand them, before integrating them. This first module is rather generic and could be used in any number of games: a sound driver and its associated data format. It's pretty simple, with only three message types: sound updates, sustain times, and end-of-sound. Sound updates are 3 bytes that map directly to the AUDx registers. The sustain and end-of-sound messages are control messages, and I set the high bit to mark them. End-of-sound is $FF, so that leaves the other 127 values for sustain times of 0-126 frames. A zero-frame sustain sounds a little weird, but only one message per channel is processed per frame, which means every message has an inherent length of one frame, so a zero-sustain just leads to a sound fragment that lasts for two frames. I'll also write a macro for making the sustain messages more readable. End-of-sound sets everything to zero. But really I'm just repeating the comments I wrote in the source code. The driver will be elaborated on eventually; I plan to reserve a special sound effect ID that will cause the driver to bypass normal processing, in order to allow for randomly generated music and effects. By the way, if you read the source code, I apologize for the cycle-count spaghetti. I just had to make utterly sure the code would run within the VSYNC period in all cases. It so happens I have plenty of time left over, and the code so far is only about half a page long, so there's room to expand in both dimensions. For the actual numbering of sound effects, I already have a format worked out: [7][6][5][4][3][2][1][0]\____/\_/\_____________/ | | | | | \-> In-page sound ID | | | \-> Sound-already-playing flag | \-> Page number I don't seriously expect to need a full kilobyte of sound data. I may not even need more than a couple pages, but it's better to have too many possible addresses than to run out. And I'm fairly certain almost every sound effect will be longer than four or five bytes (including end-of-sound), so the limit of 32 sounds per page is a reasonable tradeoff. The already-playing flag will only exist in RAM, after a sound ID has already been loaded, to avoid needlessly setting the sound data pointers on every frame. Regardless, I haven't used it yet, so this format is subject to change as I figure out the logistics of interpreting it. Actual sound design should come first. In the meantime, have a noise burst and a bwoop sound, in the attached binary. Press fire on the left joystick for the noise and push the stick to the right for the bwoop. Comments and critique welcome. Cheers!

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

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?

Thanks for your help, everyone. I'm almost certainly going to use an LFSR. That's weird, my Harmony has never shown the yin-yang. The loading latency, though, is unpredictable, right?

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?

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.

That color conversion trick is slick!

Hypnotic. I love it!

Interestingly, the game actually doesn't crash on my VCS, so I shot a short video showing how bad the jitter gets. The zip archive also has a second video showing the slight jump when the fireball sound is played. carrot-kingdom-jitter.zip