Legacy versus ARM-based 2600 Game Development

[+TwentySixHundred]

Can't believe this old chestnut was cracked open again...

[+Defender_2600]

It would seem that any additional hardware can be considered legitimate, at least as long as the Atari 2600 doesn't get too close to the performance of the MARIA chip ... but again, I don't see why necessarily stop at the technology developed in 1992, since the Atari 2600 is still alive. And there is no doubt that ARM-based 2600 games are spectacular, so who would ever want to give up on them?

 

We know that additional hardware has always been used, not only in Pitfall II, it also happened with Nintendo, SEGA, NEC... for which using an additional chip in the cartridge (or even "questionable" external add-on) was a source of pride and was well highlighted on the original boxes. Old times, old rules; new times, new rules.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

[+batari]

5 hours ago, Thomas Jentzsch said:

I think we already agreed that "cheating" is not the right term here.

I suppose everyone has his own rule when the line is crossed here. Maybe even one that's not listed. 

 

But your list nicely shows the problem. As soon as you go beyond 1. you go into arbitrary territory. Many are drawing the line around 4 or 5. But that's as arbitrary as drawing the line at 2 or somewhere even beyond 9. 

 

So, by which non-arbitrary rule is a game following rule 9 not a legit Atari 2600 game? 

Rule 9 was referring to some games I heard of that, although they ran on a modified NES emulator, the modifications were beyond the abilities of the NES chipset and they were impossible for the console to do no matter what hardware you put on a cartridge.

 

I think it would be akin to modifying the TIA emulation in Stella to support, say, a dozen player objects instead of two while basically keeping the rest equal. Still, even with such modifications, even though they will never run on real hardware no matter what you throw at it, can arguably retain much of the original flavor of the console, so some may argue it would still not be breaking the rules.

 

I don't know of any games like that for the 2600.

 

[+Andrew Davie]

3 minutes ago, batari said:

I don't know of any games like that for the 2600.

 

A number of my early CDFJ demos would run on Stella but not on real hardware.

They 'leveraged' the fact that Stella was not counting ARM cycles, and so I did a lot more work on the ARM than it could actually do in the available time dictated by the frame architecture.  Essentially I was taking advantage of "infinite" clock speed. I don't do that anymore

I thought that might be an example of rule 9. Sort of.

[CapitanClassic]

1 hour ago, batari said:

Rule 9 was referring to some games I heard of that, although they ran on a modified NES emulator, the modifications were beyond the abilities of the NES chipset and they were impossible for the console to do no matter what hardware you put on a cartridge.

 

I think it would be akin to modifying the TIA emulation in Stella to support, say, a dozen player objects instead of two while basically keeping the rest equal. Still, even with such modifications, even though they will never run on real hardware no matter what you throw at it, can arguably retain much of the original flavor of the console, so some may argue it would still not be breaking the rules.

 

I don't know of any games like that for the 2600.

 

I believe you are talking about NES Doom. Which runs Doom on the Raspberry Phi, and then has a VGA to Picture Processing Unit (PPU) driver to encode the video and push the pixels to the NES's display hardware. This is like a bus stuffing, or what the Movie Cart does, but definitely not "impossible for the console" to do. Although,  I guess that boils down to what is meant by the console "doing it." The console is doing it if you interpret that as using the consoles display hardware to draw the screen, it isn't doing it if you are talking about running all the 3D calculations to draw the screen (but under that definition,  is Star Fox a SNES game or a Super FX chip game, is Mech Warrior 2 a x486 game or an ATI/VooDoo game?

 

[+batari]

2 minutes ago, CapitanClassic said:

I believe you are talking about NES Doom. Which runs Doom on the Raspberry Phi, and then has a VGA to Picture Processing Unit (PPU) driver to encode the video and push the pixels to the NES's display hardware. This is like a bus stuffing, or what the Movie Cart does, but definitely not "impossible for the console" to do. Although,  I guess that boils down to what is meant by the console "doing it." The console is doing it if you interpret that as using the consoles display hardware to draw the screen, it isn't doing it if you are talking about running all the 3D calculations to draw the screen (but under that definition,  is Star Fox a SNES game or a Super FX chip game, is Mech Warrior 2 a x486 game or an ATI/VooDoo game?

 

NES Doom sounds more like 7 or 8 on my list (depending on how the video is produced) rather than 9. The game(s) in #9 literally can't run on a real console (or at least that is what I read.)

[CapitanClassic]

1 minute ago, batari said:

NES Doom sounds more like 7 or 8 on my list (depending on how the video is produced) rather than 9. The game(s) in #9 literally can't run on a real console (or at least that is what I read.)

Sorry, I misread what you wrote. Yes, Rule #9 is like what you/Andrew were saying,  or those  NES games that only work on NOAC systems, and use tricks that only work with those particular fake NES systems,  that wouldn't work on any real NES. Dont know any of the top of my head, but I have heard that such games do exist.

[Thomas Jentzsch]

5 hours ago, batari said:

I think it would be akin to modifying the TIA emulation in Stella to support, say, a dozen player objects instead of two while basically keeping the rest equal. Still, even with such modifications, even though they will never run on real hardware no matter what you throw at it, can arguably retain much of the original flavor of the console, so some may argue it would still not be breaking the rules.

Right. There is no logical or even common agreement to define when a game is legit or not. Therefore it seems that in case of a competition, it should be up to the organizer to define the where to draw line. Just like it is done in demo competitions.

[Mr SQL]

4 hours ago, batari said:

Rule 9 was referring to some games I heard of that, although they ran on a modified NES emulator, the modifications were beyond the abilities of the NES chipset and they were impossible for the console to do no matter what hardware you put on a cartridge.

 

I think it would be akin to modifying the TIA emulation in Stella to support, say, a dozen player objects instead of two while basically keeping the rest equal

The existing default merge 3 frames feature supports 6 player objects instead of two but blurs individual frames which is not equal and may be better or worse depending on the program.

 

Programmers coding to a modern Television with a real Atari console may miss out on what is possible since the Atari 2600 programs the electron beam directly not an emulated beam which also merges frames yielding 4 player objects instead of two.

 

Because merged frames are doubled too emulation can already support a dozen player objects on modern Television. The combination causes display changes that may be perceived as better or worse and can break some demos and games.

 

[+Pat Brady]

Hope this isn't beating a dead horse. I've been thinking about this a lot, particularly yesterday during the @ZeroPage Homebrew awards show.

 

Full disclosure: I am doing music and sound for 1942, which was nominated for Atari 2600 Best WIP Homebrew (Port), and did not finish in the top 3. I don't feel like this post is sour grapes and I hope it doesn't come across as such. Turbo Arcade is spectacular and certainly deserved the win. Actually all 6 nominees look really good (though I haven't played Qix yet for unrelated reasons). Anyway:

1. The ARM-using games dominated the 2600 categories, again.
2. @johnnywc and his collaborators (among others) do a fantastic job of putting this technology to use. I own a few of his games — some using ARM, some not — on cart and plan to buy RobotWar: 2684. It takes talent and effort to produce games of this quality, regardless of platform.
3. His original Lady Bug port, 16K ROM only, is still one of the best games on the 2600 and one of the best ports of Lady Bug for any console.
4. When James started talking about a Lifetime Achievement Award, I immediately thought of @batari. At that moment I was specifically thinking about, among numerous accomplishments, his invention of the cartridge board that makes possible all of these games that continue to dominate the awards. At that point in the show I had heard barely any mention of either his name or that technology. (John's nice acceptance speech for Atari 2600 Best Homebrew (Port) came later.)
5. If the nominations are going to list the ROM size, then they should list ARM-ness too. The differences between 32K bankswitched ROM — with or without 128 bytes of RAM — and 32K ROM plus 8K RAM plus a 70 MHz ARM are huge, in terms of both what it allows the developer to do and when it became technologically feasible. But currently they are all marked simply 32K.
6. More than anything else: it's time to retire the "I never thought game X was possible on the 2600" claim, at least regarding games that use an on-cart CPU. When someone says that, they mean: "I know something about the constraints imposed by the 2600, and I did not think game X was possible under those constraints." Doing a game using an ARM massively relaxes 2 of the 3 biggest constraints (processing power and RAM), and also lets the programmer do a lot more stuff in the display kernel. This technology has rewritten our expectations of what is possible on the 2600. It has been obvious for several years now.
7. Please don't read anything between the lines above. To be extra-clear: I unequivocally reject the word "cheating" to describe the general use of an on-cart CPU.

 

EDIT: #6 was not intended to call out any individual. I've heard or read that statement from a lot of people and was already thinking about it before yesterday.

[+batari]

I would be in favor of a separate category for "legacy-style" 2600 games.

 

As I see it, there are only two ways to define this unambiguously. The reason is that the words "legacy" and "ARM-based" aren't even close to the whole story. There is a wide gap between the two terms, as it is definitely very possible to create games that are neither legacy nor ARM-based.

 

So, to remain unambiguous, the answer should be to either define "legacy" literally, or create some agreeable definition of "ARM-based."

 

Taking "legacy" literally and unambiguously is pretty easy, as it would mean that the game cannot use any hardware that was not actually used on physical carts in the day. And "the day" means the commercial life of the console (1992 or earlier.) It doesn't allow for hardware that was theoretically possible in the day, as that definition would be ambiguous. This would include the standard bank-switching such as F4, Sara, DPC, and Supercharger. Modern retooling of legacy stuff such as 3E would not be allowed, neither would expansions of legacy bankswitching such as 3F beyond 8k.

 

Either that, or say that anything not "ARM-based" is allowed. The words "ARM-based" can't be taken literally, though. I think the spirit of the words would be "no co-processing." That would allow many different hardware types, and even games that only currently run on an ARM-based board, as long as the 6507 runs all game code, and the ARM chip was only used to handle hardware functions and not actually used to run any game code. This means that 3E and other modern schemes would be fine, and games like Chaotic Grill, which uses DPC+ but without co-processing, would be allowed.

 

So which would it be? If I had to choose, I would pick the first one.

[Thomas Jentzsch]

I think we would need a dozen categories to be fair. I don't think there is a good solution to this.

[+batari]

25 minutes ago, Thomas Jentzsch said:

I think we would need a dozen categories to be fair. I don't think there is a good solution to this.

True, but the world isn't fair. You can't make everyone happy.

 

Probably the answer that would upset the fewest would be to adopt the same rule as the demo scene uses, which I think is the same as stated above.

[Thomas Jentzsch]

9 minutes ago, batari said:

True, but the world isn't fair. You can't make everyone happy.

That's what I meant to say.

10 minutes ago, batari said:

Probably the answer that would upset the fewest would be to adopt the same rule as the demo scene uses, which I think is the same as stated above.

The demo scene doesn't even allow SC RAM.

[+batari]

21 minutes ago, Thomas Jentzsch said:

The demo scene doesn't even allow SC RAM.

I thought they would provided you used a real SARA chip.

 

Regardless, I’d be fine with any rule as long as it was well-defined and consistently applied. 

[Thomas Jentzsch]

I don't think this will work as it works in the demo scene. The approach for writing a game is very different. Game developers do not develop to win an award, very different to demo coders. So the the former will not care for rules defined by others, but only for their own ones. And then you will have all kind of variations, just like today.

 

That's why I suggested giving each game an easy to understand tech rating, as this might influence the voting towards the low tech games.

Edited February 13, 2022 by Thomas Jentzsch

[+batari]

I don’t have a strong opinion either way but if it were up to me, I’d still have a best 2600 game category but create a new division for 2600 games written with well-defined restrictions. Like in auto racing, for example, the definitions and restrictions are subject to change from year to year, though. 

[+Karl G]

1 hour ago, batari said:

I don’t have a strong opinion either way but if it were up to me, I’d still have a best 2600 game category but create a new division for 2600 games written with well-defined restrictions. Like in auto racing, for example, the definitions and restrictions are subject to change from year to year, though. 

The <= 4K category is a partial answer to this, as 4K and under games don't frequently make use of extra on-cart hardware. Also not a perfect solution, but it's helpful.

[orange808]

We all know it, but (at some point) taking advantage of additional resources requires more work. Storing additional assets and the ability to explore more capabilities requires the ability to make more and better assets. More gameplay options means more game design. 

 

It's why I celebrated when during the early mobile boom. Indies could operate again.

 

Yes, restrictions make things more difficult sometimes. They are also a comfortable security blanket that keeps things from going over our heads. That's not an effort to tear people down. It's my life experience. Limitations are challenging, but they can also be a guarantee that a project won't get out of hand.

 

Anyhow, that's why I don't think we need a ton more catagories. And, that's why enhanced carts aren't a problem. More options means more work--and if and when I finish what I'm working on, I'll prove it.

[orange808]

Slightly off topic and unrelated to me, the NES is getting a new enhanced "mapper" to take advantage of the FPGA resources in flashcarts.

 

https://somethingnerdy.com/blog/

 

I'm surprised it took this long.

Edited February 14, 2022 by orange808

[+Pat Brady]

2 hours ago, orange808 said:

We all know it, but (at some point) taking advantage of additional resources requires more work. Storing additional assets and the ability to explore more capabilities requires the ability to make more and better assets. More gameplay options means more game design. 

 

"We all know it." ?

 

For starters, I do not think amount of work is an interesting metric to anybody but the developers' spouses.

 

But I am almost certain that a lot of work has gone into K-Jo Chases the Cheese, Soul of the Beast, Hellway, and Runes of Moria even though those are only 4K each and don't have a huge number of assets. Squeezing gameplay and content into limited resources is also a form of work. And to me, all four of those games are incredible achievements.

 

Game of the Bear is 32K ROM-only. RobotWar:2684 is 32K ROM plus 8K RAM and a 70 MHz ARM chip. Does that mean RobotWar:2684 was more work than Game of the Bear? Does anybody besides you care?

 

In my particular case, music and sound for 1942, I have an entire 4K bank for in-game music and sound effects (data and drivers). Compared to many games, that is a luxury. The hard part is just coaxing the desired sounds out of TIA. Filling up the space is easy. And I haven't had to devise an optimal storage format, or make difficult decisions about what to exclude. On the other hand, if it was a DPC game, I'd have 3 8-bit oscillators plus one conventional TIA channel to work with. DPC is an additional resource that makes the job easier, not harder. DPC+, with its 16-bit oscillators, is even more of a boon.

 

2 hours ago, orange808 said:

And, that's why enhanced carts aren't a problem.

 

Okay. Has anybody said enhanced carts are a problem?

[Octavio Pinho Bokel]

I think nobody is saying that it is a problem, my point is only that it should be clearly indicated in the award itself, regardless of how the categories are divided (transparency is never a bed thing).

I am working on a 2 players version of Hellway, and I decided myself that I want it to run on a standard cart, worse case if I fail, to use an additional 128 bytes of RAM (SuperChip), and I am still nit capable, I will give up on this project! This is completely arbitrary limitation, and it is my personal journey!

In the end we are just a very small/selected group of people that for some reason have joy doing this. Limitations are part of the fun of this hobby, otherwise we would all do Unity games. It is up to each developer to find in its heart the way to go, and how to have the most fun during its own path.
Doing the game is its own game!

I am not in favor of dividing anything, just of informing everything

 

 

 

[+splendidnut]

7 hours ago, Pat Brady said:

For starters, I do not think amount of work is an interesting metric to anybody but the developers' spouses.

Amount of work is interesting to me.  Stating that you don't find it interesting is fine, but WHY did you feel the need to drag developers' spouses into the discussion? 

 

6 hours ago, Pat Brady said:

Game of the Bear is 32K ROM-only. RobotWar:2684 is 32K ROM plus 8K RAM and a 70 MHz ARM chip. Does that mean RobotWar:2684 was more work than Game of the Bear? Does anybody besides you care?

 

I care.  I'm always interested in knowing what things were difficult and what things were easy when it comes to development.  It's provides insight into the development process, and may provide useful information that could be applied to any future projects that I may endeavor to do.... But maybe I'm just weird like that.  Maybe most developers don't care about the amount of work.  *shrug*

 

With the example you provided, Game of the Bear probably fits in with what you said about attempting to fill 4K with music and sounds.... more of general, creative work to figure out what to put in, and not necessarily HARD, gotta figure out how to squeeze something into given constraints work.  Where as, RobotWar probably had more of the later, due to the nature that regardless of ARM, you still have to write the kernel in 6507 code.  BUT, I'm really just taking a guess here.

 

In regards to YOUR work specifically, you are working with the general TIA sound constraints... so ultimately, it's a mix of both categories.

 

The fun thing about the those two examples (Game of the Bear / RobotWar:2684) is that one is a port and the other is an original game.  Two games that didn't actually "compete" with one another in the awards due to the original/port split.  Regardless of that, they're both HIGH quality games well deserving of awards.

 

----

P.S.  I'd argue about the ARM specs... since that doesn't paint the whole picture... but it seems like no one seems to like to talk about that.  Oh well.

[RevEng]

Legacy_versus_ARM-based_2600_Game_Development thread, I wish I knew how to quit you.

14 hours ago, Thomas Jentzsch said:

That's why I suggested giving each game an easy to understand tech rating, as this might influence the voting towards the low tech games.

While I wouldn't personally oppose such a rating, when it comes time to applying the score I think some developers will take it as a stigma. If it works like you hope - that it's a golf-type-handicap score that might influence voting away from games that use more tech - it will pretty much will guarantee some devs will feel this way.

 

Perhaps one mitigation could be for the developer (or someone they designate) to submit info about their game, which is ideally seen first in the voting process. This could be be a standard template, which could have a "tech used" section, along with a free-form word-limited "comments by the developer". 

 

I call this a mitigation, and not a solution, because I suspect the bulk of the voting public will still make the same choices when educated, simply because they value different things than those who impose constraints on their games. But at least those same devs might feel they lost with an educated public.

[Thomas Jentzsch]

25 minutes ago, splendidnut said:

P.S.  I'd argue about the ARM specs... since that doesn't paint the whole picture... but it seems like no one seems to like to talk about that.  Oh well.

There definitely is no censorship here and murmuring about it doesn't help the discussion.

 

So, what would you like to talk about?