orange808

Thumbs up for the Polybius cab. :-)

"Just enhance" the missiles and ball with unique images. It's okay if the additional sprites share colors with P1, P2, and PF. All I want is VDEL and a unique image register for all three of the additional "sprites" (the ball already has VDEL). Maybe the "image" register for the missiles/ball would default to 255? That would allow legacy software to function normally. Unique missiles and ball images would add a lot. That VDEL for the missiles would also really help. That would open a lot of possibilities: a ton of them. "Just enhance" is in quotes for a reason. I understand the incredible amount of complexity that would add. I imagine changes could also mess up a lot of new complex kernels that run at the absolute far edges of TIA's capabilities. As is, TIA is a marvelously intricate, complicated, and elegant design. While "bitmap kernels" are not the primary use case, the additional bitmap kernel options with ARM would probably trigger and upset a lot of people--and bring down a sh*tstorm of nerd rage. The machine would be pure evil. 🤣

Latency doesn't matter. Get the hardware together and tweak the game afterwards. You have complete control over your installation, so embrace it. Relax the difficulty and nerf the game's rules if necessary. You're not targeting hard core gamers. Don't worry about it. You may also end up changing the colors in the game to suit your installation. If you have a core game together, the details should be fluid. Might consider a weighted floor mat. https://www.instructables.com/Floor-Mat-Game-Controller/ I'd use a beamer for the image. I'd actually use two beamers, a camera, a raspberry pi, and a MiSTer. Image on the wall, "game controller" image on the ground, pi processes and passes inputs from camera, and MiSTer runs the game. Everything mounts on the ceiling. Difficult to break and steal.

Well, there are technical problems with side scrolling and you probably want to experiment with ways to mitigate artifacts. While scrolling, you'll see the "double vision" artifact attached to this post. It happens when you scroll four color clocks at a time. For the playfield, it probably has to scroll four color clocks; I don't know the solution. You can hide it a little with design decisions. Big bright solid areas of background will especially stand out. For me, most 2600 side scrollers are difficult to play because the sprites exhibit the same artifact as the background. But why? Sprites can be finely positioned. Moving the sprites four color clocks in a single frame creates uncertainty about the exact position of the sprites to my eye. You have to adjust accordingly. Additionally, plan to avoid rounding errors that would make enemies appear to tremble or jitter when changing direction while the screen is scrolling.

Oh, no. If you want to see cheap shots, hit up the Displaced Gamer YouTube channel. There, you'll find plenty of it--especially in comments. My point is: legacy games are romanticized to extreme levels and the realities don't always match the narrative--and that narrative is right here in this thread. And, sorry for the cheap shot, written by some people that don't look at the code of the games. I know good and well why things aren't perfect. It's because working in assembler with E1 bank switching is difficult--and the environment itself limited the dev's ability to be efficient. There were likely some other things going on, too. It seems unfinished. Yet, the romanticized lie of perfect "tight code" from the hands of Gods on Mount 6507 gets used to tar and feather anything ARM. Plenty of cheap shots to go around, I suppose. And, I found plenty more silliness disassembling Burgertime--although I'm not done, yet. I want to fix some of the worst problems. There's a playable game in there.

It''s probably more satisfying to simply enjoy the experience, art, and creativity of game software on its own terms, when possible. My only issue is that the game shipped with a bug and Stella could have "saved the day". I hope Audacity will take a few minutes to try Stella and Gopher2600 while debugging their next one.

Ah, the amazing efficiency of the legacy dev. Like identical caches of the lives counter in Burgertime on the zero page. Why? Well, the score kernel and the game will check it, so let's cache it twice. So efficient. Great job.

In the meantime, here's a hardcoded "easy" hack. BurgerTime Easy.ips

There's a lot of unfinished stuff out there on various hard drives that you may never experience.

I've found two ram cache instances of SWCHB. I see two checks that fully implement pause. I see checks for two player mode that load the states of the burger columns and change the score value/colors. That wraps up all the known and expected functionality that revolves around SWCHB. I don't see anything that references bit D3 (the color/bw switch) by checking SWCHB or the program's ram caches. So, I'll look closely at the raw differences between the two roms for a minute or two and be done. Almost certain it's a bad dump of an identical rom. Edit: Had found the game reset when I first started looking at the rom. Sorted out the logic of the player changes and the pause today.

I don't feel optimistic. No differences between the roms where the enemy vertical positions are translated for use in the kernel. No difference between the roms for toggling the missiles and ball in the display kernel. No difference in the missile/ball rom data table the display kernel references. I'm pretty sure the kernels are identical, but I'm analyzing a bad dump. Altering the table or the code to calculate the translated vertical position would have been the easiest way to globally patch the missiles and ball. I don't see that here. Unless I'm unlucky and something essential is corrupted, it's time to analyze the logic further and see if there's a check on the color/bw switch in there. I'm not sure there are enough differences in the naked hex dump (that weren't obviously corrupted data) for another feature to be in there.

Thanks for clearing that up. On my "heavy" common cart (the only version I own), the egg enemy in particular will sometimes extend beyond the "floor". I wonder if that's what got fixed? Would like to know if this happens on the possible alternate version and the scanline "height" of the square enemies.

Pretty please, help me. 🙂 The bankswitching is mind bending. From what I gather, the checks against SWCHB (looks like one direct check and one against a cache?) are superficially handled identically between the (bad dump?) Singapore rom (posted immediately above) and the known version of the rom. If there was a bug that previously disabled a difficulty option and the rom (posted immediately above) had fixed it, wouldn't we have expected to see a different way of handling either the direct check or the cache of the register? Where is it even paying attention to the status of color/bw, anyhow? All I see are checks on difficulty switches. Maybe I missing something? 😞

+1 on the misconceptions about what the 6507 is doing. By definition, DPC music is hammering an audio register very quickly and the 6507 is the only one that can talk to TIA. So, when people say the 6507 isn't working during blanking periods, it's misleading. And, when you do put the 6507 into an extended NOP status and (simultaneously) maintain the program counter, you incur a tradeoff penalty with audio--and the developer is forced to rely on "standard" TIA audio. There's no free lunch with the Atari.

I hope I can get over it... ;-/ Oh! 8-D I just did!

This community has a long history with boxed hacks. Piling on to this one seems odd.

There's nothing inherently wrong with stealth. In many cases, it's favorable when a game openly advertises stealth as a core mechanic. Although, the best stealth games won't necessarily tell you how to play. It's most satisfying when gamers can choose how to play. The Dishonored series is the obvious example of a modern stealth design. Don't miss those games. Both combat and stealth are options and I found them equally satisfying. Additionally, the second game wisely removed the stupid "ending" penalty that shamed gamers for using the combat option. The real problem is when game designers take a clumsy approach and "bolt on" stealth elements to an existing action game with little thought or polish. Enemies spotting me with their backs turned is bullshit. There's also the enemies that can't see me staring directly at them down a hallway because I'm outside an arbitrary circle surrounding the baddie--like it's an N64 game. That sucks. And, of course, the "instant fail" mission mechanic is almost always jarring and frustrating. That kind of rigid "pass or fail" design is inappropriate outside of achievements. Games are fun. It's supposed to be entertainment. Quality stealth game play has to be a core design mechanic with deep roots in the inital concept of a game's development. Often, that's not the case and that's where stealth gets a bad name. Escort missions are the devil. It only works in multiplayer games. "Computer" controlled allies are almost always unsatisfying. I don't understand how so many well known shitty game mechanics and scenerios keep repeating themselves and reappearing--when it's clear that people hate them. Stealth works well in Dishonored. Prince of Persia The Sands of Time managed to tie the princess into the game for narrative purposes without the player suffering through too much "escort" game play. Quicktime events suck, too. Did Space Ace or Dragon's Lair ignite a huge genre of blockbuster games? Nope. That's because pushing buttons during a cutscene is a bore. Even worse, I encountered games on PC that didn't account for potential latency--and the input windows for uninformed gamers using borderless fullscreen and a laggy Xbox controller were unplayable. I had to help a friend get things configured properly to pass some sections of the Tomb Raider reboot. Not really a Tomb Raider game, though. The new ones stink. The exploration and puzzles are replaced with a clumsy marriage of cliche, paint-by-numbers, mass murder, game mechanics and Space Ace. Yuk. And, of course, they also threw in some clumsy buggy stealth for good measure. 🙂

Thanks. I'll peek at github to see when changes were made to the kernel. If all else fails, it can be patched on the ARM side in that checkswap() function.

Double and triple check it on real hardware. If it's there for sure, make a bug report in the batari Basic thread. If you don't see it on your Atari machine, maybe Stella has a bug. I admit I only spent a few weeks actually using batari Basic, but I am almost certain this bug was not present back then in the DPC+ kernel. I have seen this before while coding a kernel, though. It's the "undefined behavior" the Stella guide warns us about when we don't leave the registers alone. Back then, the only really big bug I encountered was related to the top of the playfield. That was easy enough to work around.

Next thing to do is have other people try it out on other consoles. Your TIA may (or may not) be an outlier.

int checkswap(int a, int b) { signed int temp1; char s1,s2; s1=checkwrap(RIOT[player1y+a],RIOT[player1height+a]); s2=checkwrap(RIOT[player1y+b],RIOT[player1height+b]); temp1=s1-s2; if (temp1>0) { // larger is higher if ((temp1-=5)>0) {// not overlapping if (temp1>RIOT[player1height+b]) return SKIP; else return OVERLAP; } else return OVERLAP; } else // largerXislower { if ((temp1=(temp1^0xFF)-5)>0) return OVERLAP; else {//notoverlapping if (temp1>RIOT[player1height+b]) return NOOVERLAP; else return OVERLAP; } } } Six scanlines.

I was just curious. I don't remember how the bB DPC+ kernel handles things. I do remember what might solve the issue over on the ARM side. That's where the flicker handling is. Just need to add one to a variable in the code. The result would increase the required blank scanlines between non-flickering repositioned player1 sprites from six to seven scanlines. Although, that wouldn't be fantastic; more flicker isn't desirable. What specific x coordinates trigger the issue? At first, I figured it would be related to "kernel 6". Kernel six is a tricky spot in the DPC+ kernel at the center of the screen. The kernel needs to strobe player1 (RESP1) and write to the playfield at the exact same time. To sort the problem out, the kernel takes care of the playfield on time and stobes the player1 sprite late. The kernel does two separate repositions using HMP1 afterwards. One to apply the required "fine positioning" and another to "make up" for strobing late. I assumed it would be kernel 6, but it looks like it happens earlier?

Does it still happen if you set NUSIZ1 to zero?

Yep. TIA is pissed. Looks like the sprite is being "turned on" too soon after repositioning. https://alienbill.com/2600/101/docs/stella.html#NUSIZ