Legacy versus ARM-based 2600 Game Development

[Mr SQL]

13 hours ago, batari said:

If programmers today really wanted to be authentic, you'd program on an Apple II or A8 or other system available back then, with only the tools and peripherals available then, and test only on real hardware with an EPROM emulator that was only available then, using only the bankswitching methods back then and not use any illegal opcodes or other technology or knowledge that wasn't known in the day. And, do so with little feedback. As far as I know, nobody has done that. However, it would be interesting if someone would. Sure, a game created under these conditions might not be as impressive and the limitations might be lost on end users and reviewers when they compare to other games. But at the same time, I wonder if such a game created under such conditions could be an underground success?

 

So in that sense, we are all choosing what technology we deem acceptable. Maybe a sticking point is something that theoretically might have been technically possible to release back then, but still we are still choosing modern technology and knowledge not available then to create such games.

 

We all have our ideas of what is or isn't "cheating" or going too far with the technology.

I understand everyone's point. I understood it all before I ever even worked on bB and Melody/Harmony. I predicted a backlash but honestly, the backlash has been far less than expected and I am happy that most people are embracing the technology. Because, due to the limitations of the 2600, the ARM will never be more than a coprocessor. It can never entirely take over the system as is the case with NES Doom. All video still is tied through the 6507/TIA combo and though the ARM can do some heavy lifting, it can't just take over and run the show.

 

It's important to note that for *any* current, complete ARM scheme, such as DPC+, CDFJ, take any screenshot of any frame of any game screen, whether it's Stay Frosty, Galagon, Mappy or whatever, and you could program this static screen to display this single static frame without using an ARM chip at all. Probably even in 4k.

 

Without the ARM, the difference is that the 2600 is not powerful enough, computationally, to produce these screens dynamically, i.e. 60 frames a second. What the ARM chip does, in essence, is provide the computational power for this to happen. What the ARM does, in that sense, isn't "cheating" as it isn't producing a display for any particular frame that isn't technically possible to display with stock hardware, and the ARM is never really taking over as the primary processor for the system as that just isn't possible to do; the 6507 is always needed.

 

If we can get Bus stuffing working, though, that can produce screens that wouldn't be possible on a normal 2600 without special hardware. However, one could even argue here that such hardware was possible back in the day, as the prototype computer addon "the Graduate" used this technique.

 

As pointed out before, although ARM chips are a game changer, in my opinion, the authenticity is not lost. All games, even ARM assisted, still have the 2600 feel to them, if there is such a thing, because it is the TIA chip that defines 2600-ness, to me.

 

 

Awesome perspective!

 

"If real programmers today wanted to be authentic..."

 

Fluid City and KC Monster Maze were created using a 1981 Arcadia SuperCharger and real hardware as you described. KC was indeed an underground success and Fluid City took 1st place at SillyVenture 2019.

 

"You'd program on an Apple II or A8 or other system available back then..."

 

I think you will find this very interesting - I was an advanced programmer in the 80's who didn't just write video games, I also wrote tools for the homebrew community that wrote games in BASIC just like today, but the BASIC games were slow and did not compare to Atari games (we called all video games Atari games until around 1984, the VIC-20 and CoCo were initially marketed as Atari's you could program as well as play Carts on).

 

I expanded the graphics and sound capabilities of Microsoft BASIC so that homebrew programmers could use ASCII art designers to draw the sprites like bB, and use sound designers to embed digitized audio clips and manipulate the sound Fx in BASIC; I had a column in the mags to teach these concepts and I demo'd them at Expo's to pack the booth and turbocharge sales of my software while giving away the free dev kit.

 

With the knowledge I have Today, I could use an Apple II, A8 or Color Computer to port the SuperCharger BASIC compiler and I bet you could do the same with batari BASIC. We grow nerdier over time - 10,20,30,40 years later and we find ourselves writing things we only dreamed of in the 80's.  
 
"It's important to note that for *any* current, complete ARM scheme, such as DPC+, CDFJ, take any screenshot of any frame of any game screen, whether it's Stay Frosty, Galagon, Mappy or whatever, and you could program this static screen to display this single static frame without using an ARM chip at all. Probably even in 4k. 
Without the ARM, the difference is that the 2600 is not powerful enough, computationally, to produce these screens dynamically, i.e. 60 frames a second."

 

It is powerful enough - I wrote a soft blitter chip that can ouput display lists to control sections of the screen like the A8. Reviewers have confused the games with ARM games.

 

Try the demo's listed here in Fluid City and see what you think; I haven't seen any ARM games blit 60 FPS dynamically yet but it certainly has the potential to exceed a soft blitter written in 6507 asm. 

 

Emerging Blitter Technology

 

BoulderDash  blitters wonderfully using just the standard technology by using a great deal of memory with an ingenious array of kernels. Sokobon and the new Chess display are great examples where homebrewers can start to use these technologies in a development kit.

 

The ARM appears to be used as a bit-blitter in some ARM games though not always general purpose - with the gameloop running on it I percieve this as driving the TIA and the 6507; with DPC+ bB I would consider the ARM to assist as a co-processor because the gameloop still runs on the 6507.

 

The BD kit has a 10x10 pixel Camera with a large virtual world, tile mapping and definable character graphics that can draw recognizable objects using the playfield, while SuperCharger BASIC has a 20x10 CAM and lower res playfield character graphics. It would be cool to see an ARM based blitter throw out a 40x40 pixel CAM with the virtual world, tile mapping and higher res character graphics - Maybe Batari BASIC with just the blitter running on the ARM? This could be an extension like DPC+ bB since with a blitter only the blitter need run on the ARM and not the whole gameloop. Perhaps the 30x30 bB playfield that fits in the 128 bytes of Superchip RAM could be blitted by the ARM with very little changes to bB...
 

[+Andrew Davie]

57 minutes ago, Mr SQL said:

BoulderDash  blitters wonderfully using just the standard technology by using a great deal of memory with an ingenious array of kernels. Sokobon and the new Chess display are great examples where homebrewers can start to use these technologies in a development kit.

Sokoboo did use the engine developed and used in Boulder Dash, but Chess is a fresh bit of code that does not use that engine. They are unrelated, even though they do look similar. Chess is much less generic, and hardwired for the needs of that display. The original BD/Sokoboo engine is much more generic, but limited in # of unique tiles it could display.

[Mr SQL]

3 hours ago, Andrew Davie said:

Sokoboo did use the engine developed and used in Boulder Dash, but Chess is a fresh bit of code that does not use that engine. They are unrelated, even though they do look similar. Chess is much less generic, and hardwired for the needs of that display. The original BD/Sokoboo engine is much more generic, but limited in # of unique tiles it could display.

How close does the generic BD engine come to handling enough unique characters to render Chess or Archon?

Can it be added to the engine and/or could the new code be used as a similar kit engine?

  

[+SpiceWare]

 

Strange - I set this topic to be ignored, but it showed up in the top-level forum overview. Oh well, I've removed the ignore setting for now.

 

13 hours ago, azure said:

If I remember right, it was a minority of machines that don't work with bus stuffing? Does anyone have a solid idea on what the technical reason was or is it still a mystery?

I don't know if anybody has a solid idea on what the issue is or not.

 

Quote

Also, why not implement bus stuffing in Stella and let developers opt to implement ROM releases? It would emulate the bus stuffing of a working machine.

Adding support to Stella for BUS Stuffing was one of the first things we did, you can run the RPG demo in the latest release of Stella:

 

rpg_20170616_NTSC.bin

 

rpg_20170616_PAL.bin

 

 

While we were figuring things out the spec for the BUS bankswitch scheme was under constant revision. I only kept RPG up to date with the changes, so if you want to check out the other bus stuffing demos you need to use a Harmony Cart or install Stella 5.0.0-pre6 or pre7. I'd like to eventually update the older demos to the current BUS spec, but it's a low priority.

 

Quote

Then anyone could use it in Stella, but if they have a working 2600 and a Harmony or Uno cart they could play it on the real thing also.

 

I did add a section for an eventual BUS tutorial in the Harmony/Melody club.  Do note that AtariAge will not produce games for sale that utilize BUS, and because of that my time is currently focused on the CDFJ tutorial followed by a DPC+ tutorial (though I'm not sure it makes sense to spend time on that as CDFJ supersedes DPC+).

[Albert]

Just now, SpiceWare said:

Strange - I set this topic to be ignored, but it showed up in the top-level forum overview.

The "Ignore Topic" functionality is through a third-party plugin, and I'm guessing it's difficult to squelch ignored topics from appearing on the front page.  I haven't looked, but it's very likely that the latest topic for all forums is cached to make rendering the main forum index (and any other pages that show the last topic in a forum) faster.  If that's the case, it would make hiding that topic (and displaying a topic that is not ignored) much more difficult.  I can explore solutions for that sometime down the road.

 

 ..Al

[+SpiceWare]

5 minutes ago, Albert said:

it's very likely that the latest topic for all forums is cached

 

Caching for performance would make sense, was just surprised to see it so clicked it to see if it would show You've chosen to ignore this topic like it does for ignored users - it didn't, it showed the topic.

 

Anyway it's not a big issue, I've even removed the ignored topic setting.  

 

 

[Albert]

Just now, SpiceWare said:

Caching for performance would make sense, was just surprised to see it so clicked it to see if it would show You've chosen to ignore this topic like it does for ignored users - it didn't, it showed the topic.

Ahh, that's interesting, I wasn't aware of that.  That would require another query when displaying the topic, which is probably why the plugin author didn't do it (since the topic is hidden in most places, just not on the forum index as you noticed). 

 

 ..Al

[+stephena]

22 minutes ago, SpiceWare said:

 

Quote

Also, why not implement bus stuffing in Stella and let developers opt to implement ROM releases? It would emulate the bus stuffing of a working machine.

Adding support to Stella for BUS Stuffing was one of the first things we did, you can run the RPG demo in the latest release of Stella:

 

 

Just my perspective on this.  While I will accept almost any changes to Stella that anyone wants to submit, I would recommend against creating games that only run in Stella (or any emulator), and not also on real hardware.  This has happened quite a bit in the NES and SNES communities, going so far as requiring specific versions of certain emulators for the ROMs to work.  The reasoning is that the most important thing is to create a good game that people can play, no matter if it runs on original hardware or not.

 

My opinion on the above is that if it doesn't work on real hardware, what's the point?  Over the years, 1000's of hours of work has gone into Stella to make it as compatible with the real thing as possible.  If we start adding features to emulators that bypass the inherent limitations of the 2600, why even develop for it?  At that point, you're moving from an emulation to an abstract game engine.  And there are already dozens of game engines that surpass the 2600 in every way.

 

Anyway, this may not be what's being suggested; I just wanted to throw my opinion out there.  There's nothing wrong with adding a new bankswitching scheme to Stella to help with development in conjunction with real hardware.  But I'd be opposed to adding a new scheme that would be used solely to play games that can't also be played on real hardware.

[+Karl G]

10 minutes ago, stephena said:

While I will accept almost any changes to Stella that anyone wants to submit, I would recommend against creating games that only run in Stella (or any emulator), and not also on real hardware.

I completely agree with your reasoning, but is that something that has ever happened, or that someone has tried to do in our community? I haven't heard of any "emulator only" Atari games so far.

[+stephena]

It has never happened (AFAIK) with the 2600, but I can potentially see the thoughts of it in this thread.  And as I said, it is quite common in NES and SNES communities.  I'm just saying it's not a good idea to open that can of worms.

[+SpiceWare]

19 minutes ago, stephena said:

I would recommend against creating games that only run in Stella (or any emulator), and not also on real hardware.

 

BUS ran OK on 93.5% of the consoles we tested it on. It didn't work on some of the NTSC Jrs and one of the PAL 7800s.  I was impressed that it even worked on a few Coleco Gemini units.

[+stephena]

1 minute ago, SpiceWare said:

 

BUS ran OK on 93.5% of the consoles we tested it on. It didn't work on some of the NTSC Jrs and one of the PAL 7800s.  I was impressed that it even worked on a few Coleco Gemini units.

Yep, and in my comments I didn't mean this WRT the BUS scheme.  That one was added with the intent of using it on real hardware.  What I would want to avoid is (a) a scheme that will never be used on real hardware, and (b) writing a game that uses the emulator as its main basis.  The emulator should always be secondary to real hardware.  Real hardware should always be the arbiter of what it 'right' and 'wrong'.

 

In fact, there are some schemes in Stella now that exist only in emulation.  I have already removed one in the past, and may revisit that in the future if others become obsolete.  For now I won't remove any code, but I'd also hesitate to add new code unless the above conditions can be met (or if someone else is willing to completely write and maintain that part of the code).

[+batari]

13 hours ago, azure said:

If I remember right, it was a minority of machines that don't work with bus stuffing? Does anyone have a solid idea on what the technical reason was or is it still a mystery?

 

Also, why not implement bus stuffing in Stella and let developers opt to implement ROM releases? It would emulate the bus stuffing of a working machine. Then anyone could use it in Stella, but if they have a working 2600 and a Harmony or Uno cart they could play it on the real thing also.

There were reports of BUS not working on a few consoles but the reasons are unclear. I have about 12 consoles and tested all of them a few years ago and one didn't seem to work with BUS. But, when I went back to experiment and figure out the reason why it didn't work, all consoles worked perfectly.

 

There is a chance we could get BUS working if I can get my hands on a console that failed with it before, and I can figure out the reason.

[Mr SQL]

1 hour ago, Karl G said:

I completely agree with your reasoning, but is that something that has ever happened, or that someone has tried to do in our community? I haven't heard of any "emulator only" Atari games so far.

 

The default setting for the Retron 77 community build actually break some Atari games including some of the bundled Retron 77 games that I've developed on the real hardware without Stella as batari described earlier, we've worked on bugs that can only be found this way as well.

 

1 hour ago, stephena said:

 The emulator should always be secondary to real hardware.  Real hardware should always be the arbiter of what it 'right' and 'wrong'.

 

In fact, there are some schemes in Stella now that exist only in emulation.  I have already removed one in the past, and may revisit that in the future if others become obsolete.  For now I won't remove any code, but I'd also hesitate to add new code unless the above conditions can be met (or if someone else is willing to completely write and maintain that part of the code).

If you try Fluid City on the Retron 77 after disabling merge frames and phosphor which also merges frames, it will almost work like the real hardware but it flushes a remaining Judder bug that can be seen intermittently; I don't see this on my PC with Stella or Z26 so it's likely close to the hardware limits on this hotspot. 

 

And if you use the option menu to tag the game as a PAL60 game it turns from Fluid City into Judder City - that code branch needs more attention.

 

SillyVenture used real hardware where the game and the demo effects work by default however  Atari Pacman has flickery ghosts by default; Stella solves the flickering ghosts issue by default but lowers the effective frame rate possible by whatever factor you merge frames by.

  

[azure]

1 hour ago, SpiceWare said:

Adding support to Stella for BUS Stuffing was one of the first things we did, you can run the RPG demo in the latest release of Stella:

I guess I've been really out of the loop.

 

1 hour ago, SpiceWare said:

While we were figuring things out the spec for the BUS bankswitch scheme was under constant revision. I only kept RPG up to date with the changes, so if you want to check out the other bus stuffing demos you need to use a Harmony Cart or install Stella 5.0.0-pre6 or pre7. I'd like to eventually update the older demos to the current BUS spec, but it's a low priority.

 

I did add a section for an eventual BUS tutorial in the Harmony/Melody club.  Do note that AtariAge will not produce games for sale that utilize BUS, and because of that my time is currently focused on the CDFJ tutorial followed by a DPC+ tutorial (though I'm not sure it makes sense to spend time on that as CDFJ supersedes DPC+).

I didn't realize I needed a specific Stella version the last time I tried some of the demos. I think I got there by the search and didn't notice the 1st post. Oops. The NTSC version you linked now worked fine. I have a Harmony. I'll try the demo out on my two 4-switches and one Jr. I have a 6-switch, but it's not working right for even normal games.

 

[+Karl G]

1 hour ago, batari said:

There were reports of BUS not working on a few consoles but the reasons are unclear.

I wasn't involved in the testing at that time, but I think my Jr. is one of the consoles that won't run the BUS demos. Right now, my Harmony cart is buried in a box somewhere, and I'm assuming that they won't work on the Unocart. If I confirm that mine is one of the problematic consoles, I'd be willing to loan it out for the purposes of troubleshooting, if that would be helpful.

[+batari]

20 minutes ago, Karl G said:

I wasn't involved in the testing at that time, but I think my Jr. is one of the consoles that won't run the BUS demos. Right now, my Harmony cart is buried in a box somewhere, and I'm assuming that they won't work on the Unocart. If I confirm that mine is one of the problematic consoles, I'd be willing to loan it out for the purposes of troubleshooting, if that would be helpful.

If you can determine if BUS fails on your console, I would take you up on that. I *think* this is the latest bus tester with some changes I made a couple of months ago that I *hoped* would solve the problems, but as of yet I haven't even been able to replicate the issue with older versions of the driver.

bustester_01_19_20.bin

[+batari]

9 hours ago, Mr SQL said:

"It's important to note that for *any* current, complete ARM scheme, such as DPC+, CDFJ, take any screenshot of any frame of any game screen, whether it's Stay Frosty, Galagon, Mappy or whatever, and you could program this static screen to display this single static frame without using an ARM chip at all. Probably even in 4k. 

Without the ARM, the difference is that the 2600 is not powerful enough, computationally, to produce these screens dynamically, i.e. 60 frames a second."

 

It is powerful enough - I wrote a soft blitter chip that can ouput display lists to control sections of the screen like the A8. Reviewers have confused the games with ARM games.

 

Try the demo's listed here in Fluid City and see what you think; I haven't seen any ARM games blit 60 FPS dynamically yet but it certainly has the potential to exceed a soft blitter written in 6507 asm.

That is a good point: Essentially any screen in any ARM game can be replicated without special hardware; basically the kernel would require an unrolled kernel loop with a series of immediate loads and stores. With a Supercharger, it is all RAM so you could theoretically change the immediate loads every frame and have a playable game in some cases.

I think my point was more about the game logic. The processing required for some of the ARM games would exceed the capabilities of the 6507 to handle in one frame. But, with simpler game logic, a Supercharger could produce a screen of similar detail to an ARM game and could and modify it every frame, just maybe not to the same extent as we are limited by the processing power of the 6507.

 

Indeed a blitter algorithm could help that along, especially if you don't require everything to occur in one frame all the time.

 

[Mr SQL]

27 minutes ago, batari said:

That is a good point: Essentially any screen in any ARM game can be replicated without special hardware; basically the kernel would require an unrolled kernel loop with a series of immediate loads and stores. With a Supercharger, it is all RAM so you could theoretically change the immediate loads every frame and have a playable game in some cases.

I think my point was more about the game logic. The processing required for some of the ARM games would exceed the capabilities of the 6507 to handle in one frame. But, with simpler game logic, a Supercharger could produce a screen of similar detail to an ARM game and could and modify it every frame, just maybe not to the same extent as we are limited by the processing power of the 6507.

 

Indeed a blitter algorithm could help that along, especially if you don't require everything to occur in one frame all the time.

 

X2! I get the most power in the soft blitter games that halve the Hz and steal an entire extra frame for calculations. The alternate method is to blit sections of the screen from BASIC with display list calls made from either vertical blank to get enough time, and it uses up most of it leaving very litttle time per frame for the gameloop.

 

There's so much potential here with the ARM pushing 60 FPS dynamically coupled with complementary techniques like BD queue illustrates to dynamically split tasks across frames using the TIA/6507 side if we want to keep the gameloop there. Gameloops on the ARM are interesting too of course - it opens up c as a high level language for Atari games which is another cool factor as we don't have as much overhead on the 6507 and can realistically only use Assembly or compiled BASIC for the smaller footprint memory sizes to get the most power.  

 

That's another interesting point - some programmers prefer to write Atari games in c; I love BASIC, but a lot of modern programmers grew up on c and java syntax and it's great that the ARM makes more development choices possible; no doubt there are or will be fun Atari games where it was a matter of preference more than performance for the author to write the gameloop in c on the ARM vs BASIC or asm on the 6507. 

 

[christo930]

On 1/17/2020 at 5:47 AM, azure said:

I've avoided this topic for a while, because I like both design philosophies and it's a hot topic. However, I think maybe 4K game developers ought to consider proudly advertising their games as 4K and unassisted. Wear it like a badge of honor.

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.

 

Instead of making a big deal about the ROM size or what helper chip you're using or not using, just make a big deal about what a fantastic game it is.  All the technology in the world will not help a bad game.  If your game's biggest feature is that it fits in some pre-determined ROM size, maybe it just isn't that good.

[Thomas Jentzsch]

Are you a developer?

[christo930]

On 1/17/2020 at 8:28 AM, s0c7 said:

I tend to think of Supercharger games as being "not 2600" games, but Supercharger games.  The same with the ARM stuff.  They are "Melody" games.  That's not belittling them or saying they are cheating, etc.  They're just their own thing.  I have no interest in making one, but I understand the appeal and think it will eventually become the only game in town.

What do you mean by eventually? 30 years?  We've had extra RAM for a long time and people are still making 4k games, some of which are quite good.  If technology is everything, why are we even playing Atari 2600 games?

[christo930]

36 minutes ago, Thomas Jentzsch said:

Are you a developer?

If this was meant for me (mine is the comment right before this one), no.

 

I see these compos for really small games occasionally and most are more tech demos than what could reasonably be described as games.  IIRC, there used to be a years 2k and 4k game compo years ago, I think for the C64 IIRC.

 

Though I can look at something and appreciate an accomplishment, as a game player, I really only care about the game.  Is the game fun?  Is the art reasonably represented by the graphics?  Does the sound "work" or is it insulting my ears and giving me a migraine?

As someone who has followed this sort of thing for like 25 years, there seem to be a lot more people who can code than can make good new games.

[AW127]

3 hours ago, christo930 said:

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

 

 

When thinking like that, why make a game for the Atari-2600 then? I have a different opinion in this point. When making games for a retro-system, the technology always dictate the game and not vice-versa and this is the fascinating thing about the different available retro-systems (consoles and computers). Get the most out of the given old technology.

 

If the game should dictate the technology, like you wrote, then i would suggest, making a game for the PC. A game, which pushes the newest graphic-cards and CPU's to their limits. Where is the sense to make a game on a retro system and his older technology then, when the game should dictate the technology?

[christo930]

1 minute ago, AW127 said:

 

When thinking like that, why make a game for the Atari-2600 then? I have a different opinion in this point. When making games for a retro-system, the technology always dictate the game and not vice-versa and this is the fascinating thing about the different available retro-systems (consoles and computers). Get the most out of the given old technology.

 

If the game should dictate the technology, like you wrote, then i would suggest, making a game for the PC. A game, which pushes the newest graphic-cards and CPU's to their limits. Where is the sense to make a game on a retro system and his older technology then, when the game should dictate the technology?

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.