Pat Brady

Congrats @johnnywc and @Nathan Strum! Both games and both packages look fantastic.

I know mram@4000 is mirror RAM a la Rescue on Fractalus. What's the difference between ram@4000 and hram@4000?

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).

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.

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.

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.

Feel free to include my contribution.

I've worked a bit on a bass line, but not finished it yet. Hopefully this week.

Juno First does not use the ARM.

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.

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.

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.)

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.

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.

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.

It's important to recognize that you do not have to implement everything that the header can represent. That's true whether the header represents devices as bitfields or enumerations. There are a few demos that use 2xPOKEY@$440. Nothing uses any other 2xPOKEY configurations, or more than 2 POKEYs, AFAIK. From reading your posts earlier I infer that you may have to choose between a second POKEY and a first SN76489. If that's the choice, there's not really a right or wrong answer. If you do choose 2xPOKEY, limit it to @$440. Forgive me if I'm off-base here — my hardware design experience is limited and distant — but I don't think you need a massive mux. Each address can only correspond to one device and only the 1st POKEY might be at multiple addresses ($450, $800, $4000). (You could map them differently, the only important thing is that $450 goes to one and $440 goes to the other.) For a microcontroller-based carts, the limitations might be different. Don't spend any resources on POKEY@$810 in any case. No released software uses it, and any future software that needs 2xPOKEY should use the existing $440 mapping. I don't believe it needs to be in the header either. I argued for bitfields earlier, but not in the context of POKEY mappings. If enumerating the POKEY possibilities (none; @$4000; @$800; @$450; @$400+@$450) would make it easier to implement, then let's do that.

Thanks for picking this up. I like the approach. I have a few quibbles. Probably not a huge deal, but my preference would be for size to be implicit even if RAM is enabled. For example, 40K ROM + 8K RAM seems like a useful configuration that doesn't seem difficult to implement. Strongly agree with this. We're really only replacing the cart type bytes, right? I have no love for ACTUAL CART DATA STARTS HERE, but IIRC a few existing implementations do look for it. Why not put the V4 stuff at $40? And maybe deprecate ACTUAL CART DATA STARTS HERE, so that V4 readers know to ignore it. Gonna respond separately about the audio stuff.

There are also excellent games in 16K and less. Reading these two posts back-to-back, in a context where nobody is proposing to remove ROM size information, it seems like you are suggesting that an ARM processor does not make a big difference. From your other posts, I don't think that's what you believe, but I can't find any other way to read this sequence.

My semi-educated guess is that the cost would have been in the millions. My point was that if they cared about getting it right, they could have done much better in 4K (e.g. by giving Frye better guidance, more time, and/or more help). And if they did not care about getting it right — which I believe is the case — then going to 8K might have made it only slightly less awful.

By 1981, Atari's in-house developers were extremely familiar with the 2600, and had come up with lots of clever tricks. I'm not sure that a decent Pac-Man needs many tricks besides flickering and 6-digit score, and Atari's original 2600 Pac-Man uses both of those (though the flicker could be improved). From what I've read, Tod Frye's knowledge of the 2600 was definitely not the problem. I think the fundamental problem was that Atari management at that time just did not care whether their customers liked their games. They understood (correctly) that Pac-Man would sell well even if it stunk, and they either didn't anticipate or didn't care how that would play out in 1983. Also DEBRO's port, which is excellent and only 4K. Asteroids was 8K and came out before Pac-Man, but was an outlier. 8K had a real cost at the time and was not absolutely necessary for Pac-Man. The decision to keep Pac-Man 4K was at least defensible, unlike some of the other decisions. Undoubtedly true, but Atari chose to spend RAM and ROM on the 2-player variant instead of making the 1-player game better, and that's one decision (among many) that made it a bad port. I'd say the same for attract mode color cycling. The colors and the shape of Pac-Man's mouth were bad decisions that had no benefits at all. I hacked it so the colors are correct and Pac-Man's mouth opens as a wedge. It's not great, but feels more like Pac-Man. Took about 30 minutes, and most of that was finding the sprite tables and color-changing code. To be clear, I don't blame Frye specifically. I think he gave Atari what they asked for.

If not adding more launchers, I recommend leaving the 7800 in 1-button mode. That way, both buttons work, as will the single button on a CX40 or compatible.

DPC+, CDF, CDFJ, MovieCart, and ACE have really obliterated all of the old rules about what is possible on the 2600. Even without any on-cart processing, we have Space Raid (4K and 8K versions, both ROM-only, both outstanding achievements IMO) and Atari's own Desert Falcon (16K with 128 bytes of RAM). I expect the above cartridge types could put more objects on the screen. EDIT: @Andrew Davie's MovieCart reproduction of Zaxxon arcade gameplay is also worth seeing. It's not a 2600 game, but it demonstrates what the 2600 is capable of displaying.

Given sufficient processing power on the cart, the 2600 can do Zaxxon and a lot more.

@Andrew Davie I sent you a PM.

The original came out in 1984, for more-powerful systems, and only on disk and cassette. I always think it's a laudable goal to minimize cart hardware, but in this case, even if you're going for something that could have been done BITD, bankswitching (and also SARA/CBS/BurgerTime RAM, if that would help) would be totally appropriate. By 1984 bankswitching was the norm for new 2600 games.