Jump to content

jaholmes

Members
  • Content Count

    36
  • Joined

  • Last visited

Posts posted by jaholmes


  1. (bump)

     

    This is a fascinating thread. Out of curiosity, was the issue ever root-caused? I mean, beyond experimentally determining that the filter choke in the sixer's power circuitry seemed to play a part? I'd love to know, as I'm not too keen on modding my stock heavy sixer. At the same time, I'm contemplating buying a Harmony as a development board, and I understand that the Harmony and the SF2 board (Melody) are essentially the same.


  2. (removing my prior, long-winded answer, as the capacitors in the power circuit could lead to some wonky readings if not diligently discharged first.)

     

    Probably the simplest way to validate the power switch theory is just to get it out of the way--bridge the leads with something metallic so that it's permanently "on". Without having my 2600 open in front of me, it's hard to say what I'd use, although I have a few pairs of jumper wires with tiny alligator clips on them, which is probably what I'd prefer. Of course, the challenge with any dynamic test like this is making sure you don't short to anything else.


  3. Congrats on another nice sixer! I think I read somewhere that the case revisions and the motherboard revisions weren't really aligned at all. In other words, IIIRC, there were motherboard revisions that did actually ship in both heavy and light cases. Or something like that.

     

    Poking around for a citation, though.


  4. Excellent work. Even the music is awesome! It's fun to wonder what people "back in the day" would have thought seeing something like this on the real hardware.

     

    And honestly, this makes the NES version look a bit weak. The background tilemaps in an NES can be remapped to the cartridge's address space, meaning that, with a bit of circuit design, one could make an almost codeless version of this for the NES--setting aside the music, anyway. With that in mind, there'd be no reason not to create tiles with curvature and whatnot; the "giant pixels" are soooo Atari 2600. :)


  5. I'm a big fan of behind-the-scenes documentaries in general, and especially as they pertain to creative works like movies and games. And this one was certainly no exception. All of the Atari folks involved seemed genuinely nice and down-to-earth. Of course, it would be hard not to be humble about what happened to Atari, but then they're certainly deserving of appreciation for what happened on the way up, too.

     

    About E.T. specifically: It was only a few years ago that I became aware of the "worst video game ever" label that E.T. had (according to some) achieved. I found that pretty funny. Like just about every kid on my street with a 2600--well, I had a Coleco Gemini--I got E.T. for Christmas that year. But I actually liked the game. It was one of the few games in my 2600 library that had a clear and concise ending rather than being an endless procession of steadily more difficult (but otherwise identical) screens, and that made it good for those times when I had the urge to simply "win" at something.

    • Like 1

  6. Thanks guys! I really appreciate all the helpful responses I'm getting.

     

    Finally, write A, X, and Y one after the other into GRP0 and GRP1; you'll need to include an extra write so the last sprite will be changed.

     

    For your question, check out <snip> VDEL explained.

     

    Perfect! I get it now. :) I couldn't figure out why I was seen eight writes for 48 pixels. Looking back at the Stella guide, I sort of get what it's saying now, but the practical implications are much less clear from its wording.

     

    Thanks again,

    Aaron

     


  7. The A, X, and Y registers can all be preloaded as well. That way during the time sensitive section all that needs to be done are writes.

     

    Yes, in fact that's exactly what I see in the E.T. disassembly I have in front of me. I suppose, given the very limited number of CPU cycles available and the costly indirect+index addressing used to fetch the bitmaps--that's almost half the available cycles right there!--the number of different ways to do this particular maneuver is somewhat limited.

     

     

    Btw, I recently posted a demo that is similar to what you're asking about here: http://atariage.com/forums/topic/237574-demo-3-sprites-without-flicker/ Reviewing how that works might give you some further insight.

     

    That's pretty slick. Definitely will bookmark this as an example. Thanks!

    Aaron


  8. You should be able to search around the forum for lots of topics related to 48/96pixel kernels.

    <snip>

    If you feel this is something you're ready for I would suggest starting with just a Player0 duplicate wide sprite and trying to get different graphics to be displayed.

     

    Thanks! I will certainly do that. I was hoping there'd be a timing diagram floating around--in fact, I'd almost swear I saw one, but now I've lost track of it--but I suppose a bit of experimenting could derive a practical one fairly quickly if I start simply enough. I'll give it a go.

     

    "Ready for"? Probably not, heheh. :) I have a tendency--for better or worse!--to take a depth-first approach to learning these things.

     

    Thanks again,

    Aaron


  9. Hi all! I hope I haven't picked a dull or oft-asked question for my first post. Here goes:

     

    Is there a document or forum post that explains exactly how and when the GRP0/1 registers are latched and used during the course of a scanline?

     

    In particular, I'm trying to understand how the title graphics of the game E.T. are rendered. Each line of E.T.'s face comprises six sprite instances--three of player 0, three of player 1--that are interleaved to create a row of 48 pixels. I understand how NUSIZ0/1 are used to make each sprite appear three times, however the timing of the writes to GRP0/1 that permit all 48 pixels to be unique is more of a mystery.

     

    Suggestions for further reading?

     

    Kindest regards,

    Aaron

×
×
  • Create New...