Jump to content
IGNORED

Legacy versus ARM-based 2600 Game Development


Thomas Jentzsch

Recommended Posts

It is all a matter of perspective:

 

In the eyes of the players:

If it plugs into the cartridge slot, accepts inputs from the controllers, and outputs video through the coax, it is an Atari 2600 game. As far as many consumers are concerned, they either don’t have the technical knowledge or don’t care to know how it does it, they just want it to play on their system.

 

What about people with RGB mods, games requiring custom controllers, or Starpath games? The Atari 2600 cannot natively output RGB, but I don’t think anyone would argue that improving the video output signal causes a game system to stop being the original system.  (X-box 720p games)

 

 

Similarly, some homebrew games have taken advantage of the fact that a Genesis controller can be used on an Atari 2600, adding an additional button. This is equivalent to requiring a Booster Grip controller for Omega Race, 

 

omega_race.jpg

 

con_CBSBoosterGrip.jpg

 

or the Dual Stick and foot-pedal controls for Steel Batallion on X-box. Requiring a specialized controller does not stop it from being a game for that console, it just fragments the market.

 

Starpath, CBS Ram+, and other cartridge enhancements that increase the RAM of the system have long been used to increase the graphical capabilities of a system and extend its life. The NES has a handful of games that used the MMC5 chip to boost the RAM from 2K to 3K, in addition to other performance enhancements. I don’t think these sort of enhancements prevent it from being a 2600 game.

 

In the eyes of a developer:

What exactly is an Atari 2600 “game”. Does the game have to be specifically written in 6502 assembler? If the game isn’t written in 6502 assembler, is it not a 2600 game? Several computers and game systems had a 6502 as their main processor, but different graphic/sound chips and available memory. If it were possible (it isn’t) to build an efficient cross-compiler that could compile C code into Atari 2600, Commodore 64, and NES to work specifically with those systems audio/video constraints, would that game be all three types? (Higher level language compilers are never as efficient at creating hand-written assembler, so this hypothetical couldn’t really ever happen).

 

Games like NES Doom blur the line at what really is an NES game.

 

 

 

 

The NES Doom hack is impressive, but I wouldn’t say that Doom is now an NES game or has been ported to the NES. TheRasteri cleverly engineered a way to convert the VGA signal to a graphical format the the Picture Processing Unit was able to produce. Similarly, I wouldn’t call Quake an oscilloscope game.

 

So are ARM assisted games mostly C games (or ARM7 assembly), and not Atari 2600 games. Maybe. If the majority of the code was written in C or Arm Assembly, from a developer perspective, it probably wouldn’t  be considered an Atari 2600 game. On the other hand, if the ARM7/C code is having to specifically address updating the TIA/6502 for this specific game (I.e. someone hasn’t written a driver to handle all this for you.), then the game is either a Atari 2600 game (or you are creating a new driver to display your game using the Atari 2600 limitations. 

 

I guess that would make Atari Bbasic games Bbasic games, and CDJF games CDJF games. (I haven’t tried using Spicewares new framework, so I might be vastly overestimating how much of the framework handles updating the 6507/TIA for you. Nor do I have any Bbasic experience)

 

 

 

Link to comment
Share on other sites

58 minutes ago, christo930 said:

This is where good game design comes in. 

Obviously, this is why I said within reason.  The goal is to create a game you can play on an Atari 2600.  That particular constraint is built in. 

 

You can play on the Atari-2600 with additional hardware, you mean.  :)  Not on the normal standard console.

 

But then i can also build a strong software-emulator inside a Atari-2600 game-modul, use the console itself only for powering-up this emulator and on the screen then you see a game running, which looks like a Nintendo64 game. But it runs on a Atari-2600 then.

 

And then? Everything is inside the game-module, is it still okay then, because you can play this game on the Atari-2600 console.

 

Where is the limit then? When a certain point of strength of the used technology is reached, or where? Then every console is not itself anymore, in my eyes.

 

For example, there is the RetroGEN adapter available, which you can connect inside the Super-Nintendo and then plug a Mega-Drive modul on the other side. Now you can play all Mega-Drive games on the SNES. A software emulator is used for that and the SNES only delivers the energy for running it.

 

This adapter, together with a Mega-Drive game-cartridge, could theoretically also be built directly inside a SNES game-module. Then, from the outside, it would look like a normal SNES game-modul. If i would built "Sonic the Hedgehog" inside a SNES modul together with this adapter, is "Sonic the Hedgehog" a SNES game then?  :)

 

I know that this is an extreme example, cause a software-emulator is used, but i gave this example, because i ask - where is the limit then? To which point, additional technic then is okay and from which point on, it is not accepted? Is it accepted as long as a chip, of the console on which a game runs, does anything directly in the game? Or to which point? This is the question, i ask myself then.

Edited by AW127
Link to comment
Share on other sites

1 hour ago, christo930 said:

This is where good game design comes in. 

Obviously, this is why I said within reason.  The goal is to create a game you can play on an Atari 2600.  That particular constraint is built in. 

 

I get where you're coming from with the design being the focus, but determining goals for other people's hobby time isn't a good look. Having a tighter constraint than creating "a game you can play on the 2600" isn't a real impediment to creating an enjoyable game. Game design skills are, but that's neither here nor there. We have some very original and fun 2600 homebrew titles that are 4k and less, and run on vanilla hardware, so clearly it's possible.

 

"game dictating the technology" isn't as useful of a guiding dictum as you think, even with the "within reason" dilution. A game design doesn't exist in a vacuum, apart from the medium. From the very fist inklings of a design, the chosen technology informs the design, and visa versa; they're intertwined, and exceedingly so in the case of old technology. Or to pull out a favorite Raymon Chandler quote, "there is no art without resistance of the medium."

 

My own philosophy has always been that homebrew developers should just follow their own muse, and do whatever they want. Happy developers are more likely to be dedicated developers, and they will be more likely to spend more time polishing their games. Fun games may be the result; maybe not all the time, but I suspect that would be the case whether the games were constrained or not.

 

  • Like 5
Link to comment
Share on other sites

3 minutes ago, RevEng said:

 

I get where you're coming from with the design being the focus, but determining goals for other people's hobby time isn't a good look. Having a tighter constraint than creating "a game you can play on the 2600" isn't a real impediment to creating an enjoyable game. Game design skills are, but that's neither here nor there. We have some very original and fun 2600 homebrew titles that are 4k and less, and run on vanilla hardware, so clearly it's possible.

 

"game dictating the technology" isn't as useful of a guiding dictum as you think, even with the "within reason" dilution. A game design doesn't exist in a vacuum, apart from the medium. From the very fist inklings of a design, the chosen technology informs the design, and visa versa; they're intertwined, and exceedingly so in the case of old technology. Or to pull out a favorite Raymon Chandler quote, "there is no art without resistance of the medium."

 

My own philosophy has always been that homebrew developers should just follow their muse, and do whatever they want. Happy developers are more likely to be dedicated developers, and they will be more likely to spend more time polishing them. Fun games may be the result; maybe not all the time, but I suspect that would be the case whether the games were constrained or not.

I'm not interested in telling homebrewers what to do. It's not like they would listen anyway.  I am giving my perspective as someone who plays the games.

It seems to be almost taken for granted that the games with the better technology are going to be better than the ones with lesser technology (whether that means more ROM space, more RAM or an ARM chip). This just clearly isn't the case.  Not only that, but the same argument against the ARM chip can also be made against larger ROM or extra RAM.

 

The argument, or one of the arguments is that the high tech games stand out more and grab more attention and this will discourage people who otherwise would write 4k games from actually writing (or releasing) their games.  And that people will unfairly judge their game because they didn't use the extra technology in their game.  But this absolutely flies in face of reality.  For one, we wouldn't be playing Atari games if all that mattered is technology.  But even putting that aside, there are some bigger (more tech) games even for the 2600 that absolutely suck as games.  Maybe they look better or are more impressive as tech demos, but not games.  There are 2 and 4k games that suck ass and there are good / fun games that are 4k.  If the game works in 4k, that's fine.  That is what I mean by the game design should be the main thing. 

 

Accomplishing something evokes its own joy and it doesn't matter what other people think.  Yes, atta-boys are nice, but at the end of the day, you are also trying to beat a problem and that is where the joy comes from. 

 

 

Link to comment
Share on other sites

4 hours ago, christo930 said:

This is where good game design comes in. 

Obviously, this is why I said within reason.  The goal is to create a game you can play on an Atari 2600.  That particular constraint is built in. 

And there we are full circle. Which constraints? The original ones? The most modern ones? Something in between? 

  • Like 2
Link to comment
Share on other sites

6 hours ago, CapitanClassic said:

In the eyes of a developer:

What exactly is an Atari 2600 “game”. Does the game have to be specifically written in 6502 assembler? If the game isn’t written in 6502 assembler, is it not a 2600 game? Several computers and game systems had a 6502 as their main processor, but different graphic/sound chips and available memory. If it were possible (it isn’t) to build an efficient cross-compiler that could compile C code into Atari 2600, Commodore 64, and NES to work specifically with those systems audio/video constraints, would that game be all three types? (Higher level language compilers are never as efficient at creating hand-written assembler, so this hypothetical couldn’t really ever happen).

Interesting observation - I have created efficient BASIC cross-compilers for the Atari 2600 SuperCharger and CBS RAM+ and I am working on creating a cross compiler for the Atari 800. If I get them running on the A8 and 5200 these will still be Atari games across Atari platforms unless I can write one for the C64... 

 

11 hours ago, christo930 said:

Personally, this would turn me off.  I would read it as "I wanted to make the best game that can fit into 4k" as opposed to just making the best game they possibly could or the best implementation of the game they had in mind.  And in some sense, that really is what you are doing.  Now, obviously one can never have too much space and you have to have some limits in your mind or the game will never end, it would just get bigger forever. 

I think the game should dictate the technology and not the other way around, at least to a degree.

 

"Atari games across all platforms" is what you are describing which was Nolan's vision for the 2012 Pong Challenge - any technology could be used to create the Atari game.

The other way around was allowed - the Atari 2600 could be used too.  The other entries were all modern platforms creating an Atari 2600 look and ambiance for the game.

 

What do you think of the first Flashback that offered players Nintendo Atari games? The idea was similar - to have the games dictate the technology using the "more powerful" Nintendo on a chip technology as the expressive medium to create a better looking Atari 2600 experience updated for players today.

 

I think the Pong Challenge worked better with your concept for having a large user base from the phone games with indirect cultural influence from Atari, as compared to the market segment that wanted an Atari Flashback and didn't get the memories they had expected/remembered with the games.

 

Link to comment
Share on other sites

2 hours ago, Thomas Jentzsch said:

And there we are full circle. Which constraints? The original ones? The most modern ones? Something in between? 

The constraints are the ones chosen by each individual programmer, based on what their own goals are for the game they're making, and the enjoyment they get out of the hobby.

 

For example, John Champeau left the homebrew scene for a decade, and came back in large part because Darrell had shown him what was possible by using the extended capabilities of the Harmony cart. This reignited John's interest in the homebrew scene. His interest for the games he's been working on recently lies in pushing an arcade port as far as possible on a 2600 using that technology. That approach is equally valid to someone choosing to code something entirely in assembly without any extra RAM or other cartridge enhancements, because that's what each person chooses to do.

 

I get that it would be nice if a broader set of end users would understand and appreciate the differences between those approaches, but this is a small community to begin with, and programmers who fully grasp these concepts are a smaller subset still. I'm a reasonably well-informed non-programmer, but to me all programming is equally a mystery. It doesn't matter if a game is written in assembly, C, batari Basic, or Esperanto. It's all beyond me, so I have equal respect for anyone who programs 2600 games, provided they're putting in the effort to complete a game to its highest potential. If that potential is a 1K mini game or a 32K arcade port, what matters to me is the end result. Some of my favorite games are the mini games programmed by Seemo, which are brilliantly designed to uniquely be 2600 games. He leverages the "limitations" of the console so they become an integral design element, so much so that it's hard to imagine his games on any other platform. The controls, gameplay, fluidity, sound, graphics and attention to detail are polished to an incredibly high degree. They're unique, creative, innovative, and fun. And that has nothing to do with which underlying technology is driving the game. It's about the willingness to put in the effort.

 

Part of this recent dust-up seems to be about how much attention ports like Mappy or Galaga (Galagon) are receiving relative to other games. And yes, because they're leveraging the Harmony cart, they can pull off some neat tricks that the 2600 couldn't do without some major compromises. However, I submit that if the Harmony cart never existed, and someone had put in the effort to make the best Galaga port that could run on a stock cartridge, it would still garner a disproportionate share of attention because it was Galaga. Just like Pac-Man 4K did. Or Halo. It would be interesting to see what a stock version of Galaga would look like. But someone would have to be interested enough in taking on that challenge to put in the work. In the end, this entire hobby is about programming what's of interest to each person. When I was creating episodes of a comic strip for my blog, I did it because I wanted to. Sure, it was nice if they got some extra views or a few positive comments, but I created them because it was fun, and I enjoyed the process of creating them. When it wasn't fun anymore, I stopped. If it becomes fun again, I'll start back up. But it has to be fun for me, for my own reasons. Not someone else's.

 

Finally, it's been mentioned once or twice about how vastly different the development tools are today, vs. a paper tape based time sharing system of the 70's, or other now-antiquated tools. I think that's a really salient point. How "pure" does development need to be in order to be authentic? Should Stella with its Time Machine and debugger be tossed aside because that sort of tool set wasn't available? From my perspective, I create graphics for quite a few games - and I don't discriminate between something that's Harmony enhanced or not, whether 2K, 4K, 8K, 32K, DPC+, batari Basic, CDFJ or whatever. Each game is a challenge to try to make the graphics look as good as possible within the limitations I'm given by the programmer. Is it cheating that I use Photoshop? That I'm throwing more computing power at an eight-bit sprite than Atari probably had in its entire building at one point? Are the programmers cheating by writing graphics conversion utilities to take those bitmaps and convert them into usable 2600 code? Should I be drawing everything out on graph paper with colored pencils, and physically mailing them to the programmers so they can hand-code each bit into the game? It might be a fascinating historical exercise, but it doesn't interest me. None of the programmers I've worked with have complained about how I create the graphics. What matters are the end results. I'm certainly not going to slap "game graphics created in Photoshop" on the box. :roll: 

  • Like 7
Link to comment
Share on other sites

IMO there is a difference between using modern technologies where it is obvious and where not.

 

Hardly anyone will assume that the manual, label, box etc. are created using technologies from the past. People know from their daily experience that technology has made huge progress over the last 40 years. However, if they look at the cart which looks and feels like their old Combat, Pac-Man or Pitfall! cart and plug it into their ancient console, how should they assume that inside the cart some completely different technology exists (or not)?

 

You have to be active in a community and interested into discussions like this one (or technical blog entries) to become aware. And only after you have gotten the idea that the might be some difference, you can decide if you want to find out more (or not).

 

So for me the whole topic is not about if modern technology should be used or not (as a developer or customer I can decide if that is relevant to me or not), but only about being transparent and informing the customer. The AA store already has e.g. the Melody label, but the info behind is probably too technical and detailed for most customers.

Link to comment
Share on other sites

11 hours ago, AW127 said:

 

You can play on the Atari-2600 with additional hardware, you mean.  :)  Not on the normal standard console.

 

But then i can also build a strong software-emulator inside a Atari-2600 game-modul, use the console itself only for powering-up this emulator and on the screen then you see a game running, which looks like a Nintendo64 game. But it runs on a Atari-2600 then.

 

And then? Everything is inside the game-module, is it still okay then, because you can play this game on the Atari-2600 console.

 

Where is the limit then? When a certain point of strength of the used technology is reached, or where? Then every console is not itself anymore, in my eyes.

 

For example, there is the RetroGEN adapter available, which you can connect inside the Super-Nintendo and then plug a Mega-Drive modul on the other side. Now you can play all Mega-Drive games on the SNES. A software emulator is used for that and the SNES only delivers the energy for running it.

 

This adapter, together with a Mega-Drive game-cartridge, could theoretically also be built directly inside a SNES game-module. Then, from the outside, it would look like a normal SNES game-modul. If i would built "Sonic the Hedgehog" inside a SNES modul together with this adapter, is "Sonic the Hedgehog" a SNES game then?  :)

 

I know that this is an extreme example, cause a software-emulator is used, but i gave this example, because i ask - where is the limit then? To which point, additional technic then is okay and from which point on, it is not accepted? Is it accepted as long as a chip, of the console on which a game runs, does anything directly in the game? Or to which point? This is the question, i ask myself then.

 

Well, if you are just using a 2600, and the video output of the 2600 and not a cable that hooks into the cartridge, the TIA is the limiting factor.  As I understand it, and I could be wrong, you might be able to pull off something like the CGA "video player" (a pseudo video player) with a pre-rendered video in the ROM made up of elements the TIA can display, but that the TIA is still a major limiting factor.

Though I guess you can muddy the water and use a video and or audio chip on the cartridge, but I think most people would agree that it's no longer a 2600 if you are basically just using it as a power supply.

 

I saw the video of the NES Doom someone posted real quick and I suppose it's arguable in both directions, that it both is and is not a NES game (I didn't notice any other wires and that the PPU is what is drawing the frames).  But assuming it is the case that the PPU is drawing the screen, I just don't think the 2600 has this level of ambiguity.

Link to comment
Share on other sites

8 hours ago, Thomas Jentzsch said:

And there we are full circle. Which constraints? The original ones? The most modern ones? Something in between? 

 

I would say that if you can play it on an unmodified 2600, those constraints.

 

The people doing 4k games can make all the same arguments against the DPC or Sarah chip games or supercharger games.

Link to comment
Share on other sites

5 minutes ago, christo930 said:

I would say that if you can play it on an unmodified 2600, those constraints.

 

The people doing 4k games can make all the same arguments against the DPC or Sarah chip games or supercharger games.

Yes, exactly. All constrains are subjective, even the "unmodified 2600" one. But yet they exist.

 

E.g. one could put an emulator in a 2600 case which reads normal 2600 carts like Combat. But the emulator has some advanced picture processor with powerful AI, which creates high resolution graphics, with shading (maybe even 3D) from the original TIA commands. Then one could come and say this is still a valid 2600, because the cart is original. 

 

Or is a RetroN 77 an original console just because I can put my cart into it? Or why does the TIA define the 2600, why not the RIOT or the 6507? All is arbitrary here. 

 

For me anything that existed close to the crash for the Atari 2600 (or would have been feasible for market sale back then) is fully legit. That means the combination of TIA, RIOT, 6507 etc. Maybe some extra RAM and something like a DPC. From there on, we more and more deviate. But that's my subjective opinion.

Link to comment
Share on other sites

11 minutes ago, Thomas Jentzsch said:

Yes, exactly. All constrains are subjective, even the "unmodified 2600" one. But yet they exist.

 

E.g. one could put an emulator in a 2600 case which reads normal 2600 carts like Combat. But the emulator has some advanced picture processor with powerful AI, which creates high resolution graphics, with shading (maybe even 3D) from the original TIA commands. Then one could come and say this is still a valid 2600, because the cart is original. 

 

Or is a RetroN 77 an original console just because I can put my cart into it? Or why does the TIA define the 2600, why not the RIOT or the 6507? All is arbitrary here. 

 

For me anything that existed close to the crash for the Atari 2600 (or would have been feasible for market sale back then) is fully legit. That means the combination of TIA, RIOT, 6507 etc. Maybe some extra RAM and something like a DPC. From there on, we more and more deviate. But that's my subjective opinion.

I don't think an emulator stuffed into a woody case qualifies as a 2600 even if it has a cartridge reader.  While it is true that there are some things that are ambiguous, I just don't think we are dealing with said ambiguity here.  I'm not saying the overall argument is invalid, because it's not. I do see your point about the arbitrary nature here.

 

I may be using wrong terminology here.  I am under the assumption that the TIA is the chip that generates the sound and graphics.

 

Do you mean the 83 crash or when the 2600 or games for it stopped being made?  The 2600 is uniquely long in its commercial lifespan.

Link to comment
Share on other sites

The TIA does the sound and graphics. The 6507 drives the TIA and other chips. The RIOT does I/O and contains the RAM.

 

I would mean the 83 crash. Because afterwards there was no market anymore which would have justified big investments into new technology (and even without the crash, the 2600 wouldn't have been developed much further). Just things which were already in the pipeline or minor improvements based on already existing tech (e.g. going from 16K to 32K ROM) would qualify then. So anything you can realistically imagine for the next very few years after 83.

Link to comment
Share on other sites

13 hours ago, CapitanClassic said:

I haven’t tried using Spicewares new framework, so I might be vastly overestimating how much of the framework handles updating the 6507/TIA for you. Nor do I have any Bbasic experience

 

Nothing to try yet, development of SpiceC is on the back burner. I decided the CDFJ tutorial had a higher priority due to people like @Dionoid working on CDFJ projects like Fool's Gold (facebook video of it in action).

 

SpiceC would be like bB in that the framework will have a number of prewritten Kernels, which is the 6507 code that updates TIA. The user of SpiceC would select the three Kernels they wished to use:

  • menu kernel
  • game kernel
  • score kernel

You can see examples of that in this blog post. Once configured, they'd write their game logic in C instead of BASIC.

 

One thing I'm worried about is since there's already a backlash against bB, and one against ARM, how bad would the backlash be against SpiceC?

  • Like 1
Link to comment
Share on other sites

27 minutes ago, SpiceWare said:

 

 

 

One thing I'm worried about is since there's already a backlash against bB, and one against ARM, how bad would the backlash be against SpiceC?

 

I would say ignore the backlash.  Any open forum is going to have contrarians and probably loud ones at that.  Most of us just like cool stuff and aren't overly concerned how the sausage is made.

 

As far as I'm concerned, if I stick something in the 2600 I got for Christmas back in 82 and something neat happens then it is something cool for the 2600.  Tunnel Runner was awesome!  Back in the day, I was all over anything that made games cooler.  The Booster Grip, Ram Plus, SARA, DPC, were all aces in my book.

 

These purity conceits do little to keep the hobby going and I can already see they are demotivating for high reputation developers who are doing far more for the hobby than I ever will.  I believe the converse is true as well.  I don't think the Harmony is demotivating for developers who choose more constrained ways to achieve their vision.  If the game is good, people will be interested regardless of what is inside the cart. Making the "stock" hardware do more than we thought it could is neat too!

 

Fun and joy vastly outweigh the conceits of anyone who believes rules need to be imposed lest the result be what they consider "not a real 2600 game".

Edited by frogstar_robot
  • Like 5
  • Sad 1
Link to comment
Share on other sites

6 hours ago, Nathan Strum said:

Part of this recent dust-up seems to be about how much attention ports like Mappy or Galaga (Galagon) are receiving relative to other games. And yes, because they're leveraging the Harmony cart, they can pull off some neat tricks that the 2600 couldn't do without some major compromises. However, I submit that if the Harmony cart never existed, and someone had put in the effort to make the best Galaga port that could run on a stock cartridge,

I agree with a lot of what you said, but I respectfully disagree the dust-up is about any specific game. This discussion was born in the "hey someone should make 2600 galaga thread" or whatever it was called, but it was initiated by AW127 as a philosophical question. I also disagree that it's a dust-up at all; For some reason people have taken the "versus" in the "Legacy versus ARM-based 2600 Game Development" title to mean a cage-match sort of definition of "versus", rather than the definition of "versus" that means an intellectual exploration of differences and implications thereof.

 

For some reason when the following observations have been made, there seems to be an anti-ARM, anti-Galaga, anti-John, and anti-Spice, subtext that's imported by some readers.

  • The ARM assist wouldn't have been possible in any real sense back in the day.
  • ARM allows for kernels that aren't really feasible without hardware assist.
  • The hardware distinctions that 6502 geeks make between ARM hardware assist and stock hardware are lost on most 2600 gamers, and even if they do understand, they don't care.

 

But the people making those previous observations have also made these observations.

  • Using the ARM isn't "cheating"
  • Developers should do what they want to do
  • Darrell and John are amazingly talented, and their games took a lot of skill to make
  • ARM-assist brings it's own set of constraints and challenges
  • There's no stopping progress, and hardware-assist is progress

 

And for some readers (not saying you specifically) the take-away is that the conversation is anti-Galaga, anti-John, or anti-Darrell. It's very weird. I think it's good to have an open and logical discussion of how the 2600 homebrew landscape is changing in the face of new tech, but if people are importing toxic messages that aren't in the original posts, I don't know how that will happen.

 

  • Like 5
Link to comment
Share on other sites

1 hour ago, SpiceWare said:

One thing I'm worried about is since there's already a backlash against bB, and one against ARM, how bad would the backlash be against SpiceC?

You're good. I think the backlash against bB is pretty much dead these days. There were a few anti-bB comments over the past five years, like people wanting to filter out bB games from their collections, and such, but it's so minor as to not really be a factor. If anything, the ARM-assist in bB has helped the situation, since people no longer complain about bB games all having the same look.

 

There's a perception that assembly programming takes more skill, and therefore merits more pride and appreciation. Kind of like the appreciation of the craftsmanship behind a handcrafted good you designed and made with tools, vs one you designed and 3D printed. I'll leave the validity of that perception for another "versus" thread.

 

  • Like 2
Link to comment
Share on other sites

1 hour ago, SpiceWare said:

 

You can see examples of that in this blog post. Once configured, they'd write their game logic in C instead of BASIC.

 

One thing I'm worried about is since there's already a backlash against bB, and one against ARM, how bad would the backlash be against SpiceC?

I think the backlash against bB was due to a lot of poorly developed games being pumped out because of how easy the bB framework made it to create a simple game. Developers/Consumers were afraid that too many poorly designed games would flood the homebrew market making it harder for the great games to be found.

 

The backlash against ARM is mostly due to the fact that ARM allows for games to look much better than non-ARM assisted games. I don’t think consumers were complaining. Developers being upset that ignorant consumers would compare the ARM games to their non-ARM assisted games, as unfair don’t have a good argument.  I don't think ARM games should fine forced to brand their games with a label so that people would stop complaining the graphics don’t look as good on 4K games. Developers make their own choices about what constraints they are willing to accept for their games, and since ARM/Melody boards exist, they shouldn’t complain that someone else is using technology that they chose not to use for their own game.

 

I think that there will be less backlash against SpiceC than there was for bB (the tool will have a similar effect, making it easier to make a game for the 2600 without writing in 6502 assembly). I love that tools that you/RandomTerrain write make it easier for people to make games for these ancient systems. I think that is what helps keep the homebrew scene alive. Things like the NES Maker or Scratch by MIT make more people interested in creating games, and lower the barrier to entry. Sure, there might be some people who pump out some horrible games, but because the tools exist we will also get some amazing games from developers who wouldn’t have even tried without the tool existing. 

Link to comment
Share on other sites

Back in the day the cartridge was invented to provide consumers with a friendly fool-proof method for changing out a part or parts of a fixed-function computer. Particularly ROM programs.

 

I'll stick to the simple concept that if it fits in the slot it's a VCS game. And if I was a VCS I would see an ARM game cartridge as a smartROM. A type of ROM that has the ability to write its own program on the fly or output a whole series of bytes from 1 input request. So to speak.

 

Wherever this debate takes us it can't be denied that ARM games still have a VCS flavor about them.

Link to comment
Share on other sites

33 minutes ago, CapitanClassic said:

I think the backlash against bB was due to a lot of poorly developed games being pumped out because of how easy the bB framework made it to create a simple game. Developers/Consumers were afraid that too many poorly designed games would flood the homebrew market making it harder for the great games to be found.

 

 

The fundamental problem there is very few people, myself included wants to say "your game sux" to a homebrew coder.  I have no problem lavishing praise on a good game or even writing the developer a letter saying how much I enjoy the game or even telling them things I don't like about their game (which come from playing the game so much) or bugs that I have found.  But I would be really hard pressed to say I don't like it period.  I might download it, try it for 5 minutes and then never see it or think about it again.

 

Link to comment
Share on other sites

11 minutes ago, Keatah said:

Back in the day the cartridge was invented to provide consumers with a friendly fool-proof method for changing out a part or parts of a fixed-function computer. Particularly ROM programs.

 

I'll stick to the simple concept that if it fits in the slot it's a VCS game. And if I was a VCS I would see an ARM game cartridge as a smartROM. A type of ROM that has the ability to write its own program on the fly or output a whole series of bytes from 1 input request. So to speak.

 

Wherever this debate takes us it can't be denied that ARM games still have a VCS flavor about them.

Not to mention games that simply couldn't be done without the ARM.   I think Zoo Keeper and Mappy fall into those categories.

Then again, looking at Aardvark, I initially thought it was an ARM game.  That has to be a pretty major compliment.

Link to comment
Share on other sites

5 hours ago, christo930 said:

 

Well, if you are just using a 2600, and the video output of the 2600 and not a cable that hooks into the cartridge, the TIA is the limiting factor.  As I understand it, and I could be wrong, you might be able to pull off something like the CGA "video player" (a pseudo video player) with a pre-rendered video in the ROM made up of elements the TIA can display, but that the TIA is still a major limiting factor.

Though I guess you can muddy the water and use a video and or audio chip on the cartridge, but I think most people would agree that it's no longer a 2600 if you are basically just using it as a power supply.

 

I saw the video of the NES Doom someone posted real quick and I suppose it's arguable in both directions, that it both is and is not a NES game (I didn't notice any other wires and that the PPU is what is drawing the frames).  But assuming it is the case that the PPU is drawing the screen, I just don't think the 2600 has this level of ambiguity.

 

It's not easy then, to set a limit or a point, up to which it is acceptable or not. How much of the work to run a game, must come directly from the Atari-2600 itself, that people can still call it a Atari-2600 game? As you already mentioned, then new video and audio chips would be possible and could be integrated. When normal limits of a system were blurred, it's difficult to find an end then. But also normal, that meanings in this point can be different. Sad would be, when in the year 2040 (if earth still exist then?) a newbie to the Atari-2600, saw a video of a running ARM-game on a Atari-2600 and then would think: "Aaah, this is how the typical games for this system looked like, back in the days." You understand what i mean?   :)

Edited by AW127
  • Like 1
Link to comment
Share on other sites

9 minutes ago, AW127 said:

Sad would be, when in the year 2040 (if earth still exist then?) a newbie to the Atari-2600, saw a video of a running ARM-game on a Atari-2600 and then would think: "Aaah, this is how the typical games for this system looked like, back in the days." You understand what i mean?   :)

I think really it's better to not worry about misconceptions future generations may have. The 2600 will be remembered only as a blocky pixelated footnote in the dark pre-history of gaming, before Nintendo invented the industry.

 

If someone in the year 2040 sees an ARM assisted 2600 game, I'll be stoked, no matter what incorrect notions they may have.

 

Link to comment
Share on other sites

8 hours ago, Nathan Strum said:

The constraints are the ones chosen by each individual programmer, based on what their own goals are for the game they're making, and the enjoyment they get out of the hobby.

 

This is absolutely correct and okay, but then such a game is not a normal Atari-2600 game anymore. And then such games should not compete against normal Atari-2600 games in competitions like "best game of the year" then.

 

Not, because such games should be comdemned, absolutely not i also like to play them, but for fairness reasons, because it's clear, that such games then have much higher chances to win.

Link to comment
Share on other sites

1 minute ago, RevEng said:

I think really it's better to not worry about misconceptions future generations may have. The 2600 will be remembered as a footnote in the dark pre-history of gaming, before Nintendo invented the industry.

 

If someone in the year 2040 sees an ARM assisted 2600 game, I'll be stoked, no matter what incorrect notions they may have.

Well, we're seeing 2600 games 30 years after the system was commercially unviable, so I think it is likely that future gamers will see them.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...