Jump to content

orange808

Members
  • Posts

    399
  • Joined

  • Last visited

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

4,387 profile views

orange808's Achievements

Moonsweeper

Moonsweeper (5/9)

402

Reputation

  1. "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. 🤣
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. In the meantime, here's a hardcoded "easy" hack. BurgerTime Easy.ips
  8. There's a lot of unfinished stuff out there on various hard drives that you may never experience.
  9. 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.
  10. 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.
  11. 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.
  12. 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? 😞
  13. +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.
×
×
  • Create New...