Pat Brady

Note that Concerto, as of the current firmware revision, cannot load the full game (or other >128k games).

Nice! I haven't made it very far, but the text is readable and the controls work well. Would it be possible to move the lines of text closer together, reducing the need for scrolling? Also, for some reason, Stella detects it as a paddle game. I believe its controller detection looks for certain instruction sequences. You might want to ask around about that. You will get more exposure in the Atari 2600 Programming forum or even more in the Atari 2600 forum.

I actually overlooked this, even though you stated it clearly. Let's see, 10+9*128/2/2 = 298 MARIA cycles for the background, leaving enough time for several sprites per zone (exact number depends on their widths and modes, but I think you could do, for example, an 8-pixel 160B player, 4 8-pixel 160A enemies, and 3 4-pixel 160A projectiles). Anyway I am now convinced that this is indeed viable for a real game.

Yes, it's absolutely preference, not objective truth. The same could be said to all the people who have expressed the opposite opinion. Actually it feels a bit taboo to acknowledge any advantage of the NES here on the 7800 forum (except for audio, where the predominant attitude seems to be that we should forget TIA and just slap a POKEY on everything). So maybe I'm playing devil's advocate a bit. But I do genuinely like the 256 resolution, compared to 160's chunkiness or 320's litany of restrictions and caveats. Of course you're right that sprite capacity is one of the 7800's advantages. But I've read the list of 7800's advantages so many times, I didn't feel the need to re-enumerate them. The 7800's practical CPU disadvantage, OTOH, is rarely if ever mentioned. I will say: once your library gets to a certain size, a lot of NES games start to look somewhat uniform. Developers had to be creative to avoid the 16x16 tiles look. At a high level I think that's the 7800's biggest advantage. Agree. The Famicom did have an audio pin, but Nintendo removed it for the NES. As much as I like 2A03 sound, it would be fun to hear some of the more exotic alternatives.

Especially a corporation which, even in its heyday, very clearly took its customers (and, from what I've read, its employees) for granted.

Totally agree with this. Uh, at the risk of you thinking I have a severe case of Dunning Kruger ;), and of drawing the ire of numerous other posters, I do think the NES is somewhat better overall. Graphically, the 7800 can do a few things the NES can't, but each particular 7800 mode comes with its own drawbacks and IMO none of them provide as good of a balance as the NES. The 7800 and the NES have the same CPU, but the NES has more effective processing power, because its graphics chip doesn't shut the CPU down ~half of the time. The NES obviously has way better built-in sound. Of course that does not mean we can't have fun writing and playing 7800 games. It's also worth noting that the 7800 was clearly designed, in the aftermath of the expensive and small-libraried 5200, to be inexpensive and 2600-compatible. Given those goals, GCC did a good job on it. Your tiles (meaning visual tiles, not necessarily how they are structured in display lists) appear to be 8 pixels wide and about 12 pixels tall. Tree canopies are 3 tiles wide, 3 tiles tall. Your mockup has 11 canopies in each dimension, making it about 264 pixels wide and 396 tall. Maybe everybody understood that, but IMO if you're going to show this and say "see what the 7800 can do!," I think you should clarify that if a 7800 game were to use those graphics, the screen would only show a fraction of that mockup. And even taking a screen-sized chunk of it, it's not clear that it would leave enough DMA time to draw more than one sprite per zone.

How many pixels wide and tall is that mockup? More to the point, the 7800 does not require a full-screen bitmap (neither does the NES).

I don't want to wade deeply into the NES-vs-7800 debate right now, but FTR 7800 Attack of the PETSCII Robots does use an on-cart mapper (and an on-cart POKEY). So if you consider SMB3 to not run on a "stock" NES then PETSCII Robots does not run on a stock 7800. The 7800 version is one of the very best looking 7800 games. The NES version, in its current state, looks like a disappointment, certainly not a fair representation of that system's capabilities. Your Zelda mockup looks great. Do you think there are reasons other than development budget that no 7800 game looks like that?

OK, I started this a long time ago, stopped after level one. I reduced the volume of footsteps and climbing sfx, and changed the background music to be all in "pure" distortion settings. I am attaching this as an IPS file, which I realize is not the norm on atariage, but is fairly common elsewhere. So you'll need an IPS utility (you can choose one here; I use uips from cmdpack, which is open-source and cross-platform but is only distributed as source code). I have two different a78 files of the released Donkey Kong Junior (differing only in the header), and @KevinMos3's excellent graphics hack. This patch should work on any of those. TIA can probably do better than this still, but that might require updating or replacing the audio driver code, which is outside the scope of what I did here (I only edited the audio data). I'd like to eventually update the other levels, but no idea when I'll get around to that. Several other projects are higher priority.

Nice additions! Of the screen wipes, I especially like the 2nd and 3rd ones. And I always dig @mvo's stuff.

The Chiefs (along with the Bills) were one of the first teams he did. See above.

Did I say 3? I meant 300. There are exactly 300 Americans who know that it's "Fahr'n fahr'n fahr'n" instead of "Fun fun fun."

I'm one of like 3 Americans who knows that. I decided to take that liberty anyway. It felt appropriate for the 2600.

I did not identify it, but that's my fault, not yours. Now that you mentioned it, I can hear it clearly. Sounds great!

I worked on this a while ago, intended to add a bit more, then didn't. One of @Thomas Jentzsch's comments reminded me about this, so here it is. funfunfun.bin

I just watched this segment. Nice interview, lots of interesting details. The game looks and sounds stunning.

Nice interview. I enjoyed the discussions about Bluto vs. Brutus and the non-technical aspects @darryl1970 emphasized in porting.

Looks great! Thank you for 48K compatibility.

Or they just didn't have the resources (time and access to an arcade cabinet) to learn the details of the arcade game, or the resources (time and ROM space) to implement them.

Initially I leaned towards option 2, but if the player with the key wanders off looking for other items, it might be excessively frustrating for the other player. More importantly IMO, keys should behave the same as other items. So if one player taking a bridge means the other player can't pick up that same bridge (as was stated in post #1), then keys should work the same. If you do option 3 and make the other items work like keys, then the players mostly play in their own sandboxes. Maybe option 1 is still best.

Not sure this is worth debating, but I initially wrote my response (multiplexing with work) before I saw yours, then I updated it slightly when I saw your post and @Michael Malak's response.

To elaborate a bit, the question wasn't whether it was technically feasible, or even whether it was profitable. The question was whether management believed it would maximize profit. Parker Brothers Q*Bert is pretty good as-is, and I think it is extremely unlikely that any company's management would have approved a bigger ROM, or certainly any sort of coprocessor chip, at the time. The people that did Q*Bert did a smashing job, given the 4K limit in addition to the 2600's inherent limitations. I think you're confusing Harmony with CDFJ. What you described (ARM emulates various bankswitching schemes) is what Harmony does. CDFJ lets the game use the ARM directly.

Have you considered making the character something other than a frog? It's obviously in the same genre as Frogger, but the gameplay is quite a bit different. IMO using a frog sets the expectation that it plays like Frogger, and using some other animal would soften that expectation. Also, some other animal might better match the fine-grained movement.

I prefer #2 and #4 (extremely similar to each other), which to me look nearly as contrasty and more vibrant. EDIT: this looks fantastic, and #1 and #6 are certainly good options.

I watched a couple of interviews of these guys. They formed a business together, but it's still 3 individuals who don't necessarily share identical viewpoints on everything. AFAIK Dan never said anything remotely negative about homebrew.