Jump to content

Pat Brady

+AtariAge Subscriber
  • Posts

    487
  • Joined

  • Last visited

1 Follower

About Pat Brady

Profile Information

  • Location
    Madison, WI, USA

Recent Profile Visitors

5,350 profile views

Pat Brady's Achievements

Dragonstomper

Dragonstomper (6/9)

716

Reputation

  1. Congrats @johnnywc and @Nathan Strum! Both games and both packages look fantastic.
  2. I know mram@4000 is mirror RAM a la Rescue on Fractalus. What's the difference between ram@4000 and hram@4000?
  3. There is only one other currently available option. Regardless, I for one welcome discussion of 7800 hardware, whether it's standalone or an interface to something else. @-^CrossBow^- @evietron — it sounds to me like Evie is/you are aware of all the POKEY addresses. Just to be clear, the list is: $4000, $450, $800, $440 (the last used for stereo paired with $450).
  4. It's a good question. I consider the 2600, 8-bit computers/5200, and 7800 to be 3 different platforms. They do share the same CPU (the 2600's runs slower), and the 2600 and 7800 use the same sound chip, but there's not much similarity otherwise (unless running the 7800 in 2600 mode, in which case it's a 2600). They have completely different graphics processors and memory layouts. The NES also uses the same CPU, so I don't see it as any further away. Whether porting an existing game is easier than starting from scratch probably depends on the nature of the game and how it was coded. If the original was coded with the game logic cleanly separated from the display code, then porting the game logic might be fairly straightforward. If all the code is intertwined, it might be easier to start from scratch. Coding for reuse takes effort. My impression is that BITD it wasn't really a consideration: it was hard enough just to get a game working in the allotted time. Since the graphics systems are all completely different, the display code — which might be a substantial part of the total code — cannot be reused in any case. Even if the code is cleanly separated, the systems have big differences in RAM and practical CPU power. That's obviously a problem when going from a more powerful system to a less powerful system. But going in the other direction, it might make it hard to take advantage of that power, which we typically want to do. For example, the 2600 has only 128 bytes of RAM in the console, and games have to be coded around that limitation, and that might prevent desired improvements in a 7800 game, so you zmay end up rewriting it anyway. I know some of the 8-bit computer homebrewers have done ports using code from C64 or BBC Micro versions (again, same CPU, different graphics chips). Maybe it makes more sense when the source and target platforms' capabilities are in the same ballpark.
  5. I have never heard of POKEY@$8000. $8000 is typically ROM. Did you mean $800? $800 is used in bankset and has some issue with startup due to the BIOS doing something in that space. RevEng and batari are the people to ask about that. POKEY@$450 is common in homebrews that put something else at $4000. The only other thing I'm aware of is double-POKEY, with one at $450 and the other at $440.
  6. New 2600 games in 1982 were 4K or 8K. CC is 128K, which might have been viable in 1986, had the market not moved on to newer consoles. It's a 2-year-old 2600 game, one that received a ton of attention when it came out. I think it's not very realistic to think that promoting it at this point will move the needle enough to make them develop a 7800 game, especially since IIRC they explicitly stated disinterest in the 7800. It has no more relevance to this forum than any other 2600 game. If you want to encourage more 7800 development, tell your friends to buy 7800 games from people who make 7800 games.
  7. Feel free to include my contribution.
  8. I've worked a bit on a bass line, but not finished it yet. Hopefully this week.
  9. Thanks! We aren't using CDFJ audio, it's just TIA. We sometimes update one register twice per frame, but never more than that. The notes with 2 updates sound distorted. I'm hoping to reduce that for the next release. Thanks also for the constructive comments on the tempo. Speeding it up to arcade speed (128 BPM) makes some of the rhythms imperfect mathematically, but they're close enough that I can't tell the difference, so we're going with that.
  10. Yeah, AFAIK the lazy-programmer meme has no basis in reality. It might be more accurate to say mismanagement, at least at Atari itself from 1980-1982 when they were swimming in cash and still skimping on development costs. EDIT: Regardless of whatever was going on at Atari Inc. at the time, I agree with you that most of these games are at least decent on the 2600. I definitely enjoyed Centipede and Defender BITD.
  11. It's right at 120 BPM. The arcade is about 128 by my measurement. That's as close as we can get while keeping it perfectly steady. I'll see if I can increase the speed a bit — the triplets won't be perfect but might be close enough for human hearing. (The arcade game has a dedicated audio CPU which I think lets it choose an arbitrary tempo. Obviously we don't have that luxury.)
  12. In my imagining, this 2600 Plus would have happened in the early 1980s, when a 6502 at 1.79 MHz should have been feasible. I forgot another important and easy enhancement: a 2- or 3-button standard controller. Even without any TIA enhancements, a 2600 with a faster clock, more RAM, bigger banks, and a multi-button controller would have been a significant upgrade. Similar to POKEY in capability, but different in design, based more directly on (and remaining compatible with) TIA.
  13. I'm a bit annoyed at how much time I've wasted thinking about this particular alternative history, where instead of the 8-bit computers Atari made a 2600 plus that was compatible with 2600 games. A few things could have been done without redesigning any of the big chips, and making compatibility mode relatively easy to implement: The easiest thing: add more address pins and a R/W line to the cart connector (a la 7800). Allows bigger ROMs without bankswitching, and bigger banks with it. Increased CPU speed, like you said. Even the modest bump to 1.79 MHz would make a big difference for the 2600 because you could do much more in the kernel. Increased RAM, like you said. 128 bytes at $180 is the most obvious one, which would decouple the stack from zero page. Beyond that, put more 128-byte blocks at other mirrors, and/or put 1 or 2K at $800. Add an ADC for paddles, so the kernel doesn't have to read them (admittedly this was not a widely-used feature in the 8-bit computers AFAIK). Those 4 things (or just the first 3) would be a *huge* upgrade IMO. Further into fantasy territory is a "TIA Plus" that might be implementable with a compatibility switch. My wishlist: Allow full-width playfield using the other 4 bits of PF2 and mirrored addresses of PF0-1. Provide 4 player sprites and 4 missiles, using mirrored addresses (which kind of explodes the collision detectors, so may need to be clever about that). Improve audio (which gets the most detail here because it's what I know the most about): Increase frequency counters to 6, 7, or 8 bits. Tweak the distortion definitions to account for the higher resolution. Provide a few more distortion settings (5, 9, 10, and 13 are currently redundant), ideally at octave intervals (useful and easy to implement) of existing settings. Provide 1 or 2 more channels using the mirrored addresses. Increase dynamic range to 5, 6, 7, or 8 bits. Redesigning the 6502/6507 is too far out for me to think about. EDIT: not annoyed at anybody here, I thought about all that before yesterday.
  14. Looks great to me, including your idea to allow implementations to preload ROM into RAM in certain unusual cases. Only thing I'll add is that single POKEY@$440 is not necessary AFAIK, though it doesn't hurt anything. I have one other thought, purely about documentation. @RevEng mentioned a while back that some implementations of POKEY@$450 mirror it to some or all otherwise-unused addresses in the $400-$4FF space. From a software standpoint, this is fine: if I don't declare in the header what I want at, say, $440, then I don't care what's there. In C/C++ terminology they would say something like "behavior of unmapped regions is undefined." Should we add some language like that, so that implementors know they can mirror, and developers know not to rely on anything there? EDIT: thanks again to both of you.
×
×
  • Create New...