Jump to content

tokumaru

Members
  • Content Count

    275
  • Joined

  • Last visited

Community Reputation

81 Excellent

About tokumaru

  • Rank
    Moonsweeper

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Rio de Janeiro - Brazil

Recent Profile Visitors

11,642 profile views
  1. It just occurred to me that Atari 2600 graphics drawn exclusively with playfield pixels look a lot like SNES graphics... in mosaic mode! It kinda looks like the game is in the middle of a scene transition (à la Super Mario World), and my brain keeps waiting for the animation to finish and the final graphics to appear. Not that the graphics look bad or anything, it's just that rendering detailed backgrounds is far from being one of the things the 2600 excels at. I love all the mock-ups posted in this thread, especially because they're so unconventional.
  2. I feel like a true one line kernel, where you do EVERYTHING in a single line, would be way too limiting, but you can have a longer kernel, spreading tasks over multiple lines, and still update the graphics every line to get the most out of the TIA's resolution. If you divide the screen into multiple regions, you can prepare the data for the next region (graphics and mask pointers, counters, etc.) over the course of several lines while drawing the graphics of the current region. Or you can even jump between different kernels that do different tasks depending on what you need to display in each region. You mentioned the conditional code to display objects as a big concern, but the biggest kernel killer IMO are the asymmetrical playfields. If you're doing that, there will be barely any time left for anything else.
  3. The problem with consoles like the 2600 or the NES is that their colors aren't internally defined in RGB, and that their video chips output composite video signals directly. The problem with this is that there's no definitive correct way to decode colors from a composite signal, specially when they're slightly out of spec, as was common in these old consoles. With each TV decoding the colors differently, everyone has a different notion of what colors appear correct to them, so emulator authors have to make the tough call of selecting a specific color conversion formula or selecting a manually created palette so they can display the graphics in RGB. Later consoles such as the Master System, the Genesis and the SNES had their palettes internally defined in RGB, so even though the colors also got mangled as the video signal was encoded into composite and decoded by different TVs, emulators can simply rely on the original RGB values as the intended colors and use those.
  4. It comes down to how the games are programmed. When you reset the console, the program goes back to the beginning, but the memory (RAM) is not erased, so games get to choose whether they're gonna keep any of the state from the previous play session. By design or by mistake, a game may end up not resetting the variables involved in playing music.
  5. The system only has a handful of color slots for the objects it can draw: 1 for the background, 1 for the playfield and the ball, 1 for player 0 and missile 0 and finally 1 for player 1 and missile 1. However, these colors can be changed at any time, even in the middle of a scanline, meaning that in some cases, if the screen's design allows it, you can have more than 4 colors per scanline. In Stella you can activate the "debug colors" mode so it will render all the objects with fixed colors, allowing you to see where each of the TIA's objects are used. You can also step through the game code instruction by instruction as the image is rendered, so you can easily see when exactly the color registers are used.
  6. You simply can't assume that all code ever written for a platform will conform to any specific set of standards. Developers are free to use RAM as they please. Like it's been pointed out, some of the game state might not even be stored in RAM... part of it may be implicit from the state of the video hardware, for example. You asked specifically about the lifetime of variables, and that certainly can vary a lot from program to program. In a game with different play styles, the same RAM positions will almost certainly be used for radically different purposes depending on the current level or play style. RAM is also commonly repurposed during screen transitions, when the computations for the next screen may overwrite data that's no longer needed from the previous screen. Another example of radical changes in the meaning of RAM positions is when enemies die and new ones are spawned in their places... depending on the types of enemies/objects occupying these kinds of temporary slots, each position of memory may represent completely different attributes. Probably not in a Pong game, which is really simple and will do fine without advanced RAM management, but in games with more complex worlds, 128 bytes is simply not enough to store all of it at all times, so in those cases you can expect more RAM to be shared among different things as gameplay progresses and they're activated and deactivated.
  7. The 6502/6507 always accesses the stack at $0100-$01FF, it just so happens that, on the 2600, page 1 is a mirror of page 0. As for the actual memory layout while have are running, there are no rules at all... programmers have complete freedom to use that space however they want. You're not even required to have the stack go from $FF down, the stack can actually start anywhere as long as you're careful and keep it from clashing against the game state variables. Speaking of game state, there's absolutely no standard way to organize that and it varies wildly from game to game. Games programmed in the same framework (e.g. batari Basic) or using the same engine will end up having some RAM map similarities, since they share large portions of code. Each game needs to remember different things, and calculate things in different ways, so they don't really adhere to any kind of standard when organizing that data in the little RAM that's available.
  8. Awesome! The Harmony cartridge is more versatile than I thought! Thanks for letting me know!
  9. Do note that any RGB values you find are not gonna look 100% correct, simply because there can't be 100% correct RGB representations of colors generated in the analog video domain. Even if you do all the math and precisely simulate the NTSC signals and decode them to RGB (some emulator filters do this), the result still won't be absolutely accurate because every TV decodes these signals differently. So don't get too hung up on finding the "perfect palette", because there's no such thing. Just use one that looks correct to you.
  10. Cartridges that boot into their own software (e.g. when accessing external storage, configuring FPGAs, displaying menus, etc.) before running your code are useless for testing the boot up state of the machine, though. For those cases you do need an old fashion socketed EPROM/EEPROM/FlashROM cartridge and an EPROM programmer. EPROM emulators are also a thing, but those are harder to find.
  11. Unless you're intentionally doing something experimental that relies on undocumented behavior or things like that, programs should behave the same across reasonably accurate emulators. If you're doing everything by the book and yet the program behaves differently on different emulators, it's better to sort that out before testing on hardware. Testing on hardware is more like a validation step, it will do little to help you figure out what you're doing wrong. Even if your code appears to work as expect on real hardware as is, the fact that some emulators have issues with it could mean that something is ever so slightly off that it could still fail on hardware under certain circumstances.
  12. Have you tried Stella's debug colors mode? You can see what objects are used for what without having to guess.
  13. Double posted due to Wi-Fi trouble.
  14. Some assemblers do allow you to define symbols whose values start with a #, and the # will in fact be honored when the symbols are used, but that greatly hurts the readability of your code.
  15. Looks very doable to me, bB or otherwise. It's just single colored playfield blocks and a dot, not hard to draw at all. I do feel like the snake could use a different color than the solid Tetris blocks though, in order to avoid confusion when the playfield gets more cramped. Being at most 4 blocks wide,the snake could easily be drawn with a stretched player object.
×
×
  • Create New...