Legacy versus ARM-based 2600 Game Development

[+Gemintronic]

I'm out of the loop but isn't AtariAge DPC+ the only ARM enhancement available to the general public?

 

I'd love to hear about more ARM options.  Even if I can't get my hands on them (or program for them)

[+splendidnut]

10 minutes ago, Thomas Jentzsch said:

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

 

So, what would you like to talk about?

I agree there's no censorship.  BUT, the discussion stopped the last time I brought up a specs discussion.

 

UGH, I just wrote a bunch of stuff on comparing ROM sizes that the forum editor threw out when I grabbed that quote.

 

Basically, DPC+ is more like 24/28k ROM vs 32k of a plain old bankswitching scheme.  So there is definitely a trade off there.

[+splendidnut]

10 minutes ago, Gemintronic said:

I'm out of the loop but isn't AtariAge DPC+ the only ARM enhancement available to the general public?

 

I'd love to hear about more ARM options.  Even if I can't get my hands on them (or program for them)

CDF, CDFJ, CDFJ+... all requiring ARM-based coding to use.

[Thomas Jentzsch]

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

It solely depends on how effectively you use the resources. Additional resources can make life much easier. E.g. coding in C is much faster than coding in hand optimized assembler. And if you can reuse existing source code, that makes life a lot easier too. Also less resources usually require making compromises, which often require hard work get good results. And especially when it comes to graphics, an artist will always like to provide more input than you can handle.

 

But of course the complete opposite can also be true. 

[Thomas Jentzsch]

4 minutes ago, splendidnut said:

Basically, DPC+ is more like 24/28k ROM vs 32k of a plain old bankswitching scheme.  So there is definitely a trade off there.

There are always trade offs, it doesn't matter which tech you use.

 

E.g. SC RAM eats 256 from each bank, bank switching often requires duplicating code or major refactoring to avoid/minimize that. And so on. 

[Thomas Jentzsch]

5 minutes ago, splendidnut said:

CDF, CDFJ, CDFJ+... all requiring ARM-based coding to use.

Right. And AFAIK these are not limited to a few people only.

[+johnnywc]

Well, I usually steer clear of this conversation for personal reasons but since I and RobotWar were specially mentioned I figured I'd add my 2 cents (keep the change  )  ...

 

19 hours ago, Pat Brady said:

 

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

Congratulations on the 1942 nomination, it certainly is well deserved.  Thanks for the kind words regarding Turbo Arcade, and if you're a Qix fan you should download it and give it a try!  Nathan's graphics (particularly the warp-in/death animation) and @PacManPlus Bob D's sounds are worth checking out.

Quote

1. The ARM-using games dominated the 2600 categories, again.

True.  Makes sense, they have all of the extra memory and processing power potential.

Quote

1. @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.

Thanks, and thanks for the support!  I think you'll be particularly impressed with Dave Exton's artwork on RobotWar:2684 - he really outdid himself this time! 

Quote

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

Thanks again!  That was one of the first games I developed back in 2006 (along with Conquest of Mars in 2005).  At the time, I used the most advanced technology available that could be put on a cart (16K, 128 bytes of ROM) at a reasonable price.  Back then, if you wanted to use the Sara chip, it meant harvesting Sara chips from existing games like Dig Dug so I decided 128 bytes and to make the concession of symmetrical doors.

Quote

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

I'm not sure how many speeches came before Fred's where the recipient would have the knowledge that what they contributed was a direct result of the technology Fred invented, but certain he, Darrel and Chris (CDF) deserve all the credit for inventing the technology that allows these games to be made.  I'm also pretty sure I have mentioned the CDF team on numerous occasions in previous chats, comments, posts, etc. when explaining how games like this are possible on the 2600.  I may be misreading your point here, but it seems to suggest that Fred and his team do not get the credit they deserve, and I may have tacked on my thanks to Fred because of his Lifetime Achievement Award (although I obviously altered my speech to mention him first after his wonderful acceptance speech since it was fresh on my mind).

Quote

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

That sounds like a good idea.  Voters should be aware if a develop chooses not to use the latest technology.   

Quote

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

Well, there are always going to be games that are not possible on the 2600, but I do agree that the phrase can be misleading.  It should be "I never thought game X was possible on the 2600 back in the 80's", to which the answer for some games is "Yes, but with the latest technology, now it is!"   

Quote

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

Thanks for pointing that out.  "Cheat" implies that myself and other developers that choose to use the latest technology are doing it without the public knowledge and that the technology is only available to a select few, both of which are not true.  I personally make sure that all all responses on AA, public forums, chats, interviews, etc. when asked about the technology point out the extra resources available and whether or not this technology makes the game 'possible' on a 2600 where otherwise it would not.   

9 hours ago, Pat Brady said:

 

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

  you hit the nail on the head with that one, especially when James' schedules the awards show the same weekend as Valentines Day. ?  

Quote

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.

Agreed.  I (and mostly @Thomas Jentzsch ) spent a lot of time trying to squeeze as much as we could into Avalanche (4K) and I spent months freeing up space in Lady Bug (original) to fit in all the features I wanted to add.  With that said, I would say I spend probably the same amount of time (or more) fitting all the features into the new games as well (even with 30K of ROM) as I usually end with < 16 bytes left by the time I'm through my nth round of optimization.  Just thought I'd mention that; 32K is still a limit that needs to be dealt with (although it's a much different approach than squeezing a few bytes out of a 4K ROM).  Almost all of my games use some sort of compression (Super Cobra Arcade uses compression tools developed in tandem with Nathan, Darrell and Thomas) and Turbo uses my own compression scheme for the graphics.  All of the TIA sounds I use are stored using my own compression scheme.  Granted that most of the compression is done to free up ROM for bells & whistles like animated title screens, scoring instructions, etc. but it's work nonetheless.

Quote

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?

Not sure about GotB, but I can speak about RobotWar:2684.  I developed it for 18 months (on and off of course) and I approximate that I spent about 150 - 200 hours on it (I really need to start keeping a log file).  Hope that helps (for those who care  ).

Quote

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.

Agreed on the struggles of making good sound/music using the TIA.  Mappy is the only game that uses DPC (at the cost of 5 cycles per scanline - nothing is free  ) but I am amazed at what the talented sound developers like Bob,  @iesposta (WoW Arcade) @catlegs (Galagon) and yourself can make the TIA sound like!   

 

PS The music and sound for 1942 is coming out great!  (Champ Games is always looking for good sound guys if you're interested  )   

 

 

[+Al_Nafuur]

12 minutes ago, Thomas Jentzsch said:

19 minutes ago, splendidnut said:

CDF, CDFJ, CDFJ+... all requiring ARM-based coding to use.

Right. And AFAIK these are not limited to a few people only.

 

But they require a special hardware.

 

[+Gemintronic]

20 minutes ago, splendidnut said:

CDF, CDFJ, CDFJ+... all requiring ARM-based coding to use.

 

So, are there any performance comparisons for the 4 publicly available options?  Say, amount of instructions that can be executed before returning control to the 6502?

[+splendidnut]

1 minute ago, Gemintronic said:

 

So, are there any performance comparisons for the 4 publicly available options?  Say, amount of instructions that can be executed before returning control to the 6502?

I personally do not have that information as I have not used any of them.  I just recently started digging into learning about more about ARM chip programming.

[Thomas Jentzsch]

3 minutes ago, Al_Nafuur said:

But they require a special hardware.

Just like DPC+. (I was referring to Gemintronic's post)

[+splendidnut]

1 minute ago, Thomas Jentzsch said:

Just like DPC+. (I was referring to Gemintronic's post)

Except for ChaoticGrill.  Which @Al_Nafuur / @DirtyHairy got running on the PlusCart / UnoCarts.  Because it doesn't use ARM coding outside of just needing the DPC+ driver. 

 

[Thomas Jentzsch]

2 minutes ago, Gemintronic said:

So, are there any performance comparisons for the 4 publicly available options?  Say, amount of instructions that can be executed before returning control to the 6502?

These are all the same, since it is the same CPU. CDF was the big jump compared to DPC+. The advantage of the later ones (CDFJ(+)) is the better use of available resources (more efficient 6507 kernel code, better RAM organization etc.). I don't know how big these advantages are, but most likely they are not a game changer.

[+Andrew Davie]

11 minutes ago, Gemintronic said:

 

So, are there any performance comparisons for the 4 publicly available options?  Say, amount of instructions that can be executed before returning control to the 6502?

It's hard to say because you generally do the ARM stuff in C.  I've written quite a few graphical demos now, and have a good handle on what's do-able.  There's plenty of enough time, just, to do full-screen playfield graphics that update every frame.

 

edit:  heh "plenty of enough".... left it there.

Edited February 14, 2022 by Andrew Davie

[+johnnywc]

1 minute ago, Thomas Jentzsch said:

These are all the same, since it is the same CPU. CDF was the big jump compared to DPC+. The advantage of the later ones (CDFJ(+)) is the better use of available resources (more efficient 6507 kernel code, better RAM organization etc.). I don't know how big these advantages are, but most likely they are not a game changer.

To add to that: as Fred mentioned in his acceptance speech, due to a chip shortage he has developed CDFn drivers that use 60mhz chips instead of 70mhz and has asked develops to try to get their games to run with the 60mhz chips first.  There is also something called MAM level which does caching which increases the # of ARM instructions that can be executed, but again there are old chips with a "MAM bug" that require it to be partially disabled.  As has been mentioned before, the ARM code is typically executed during VBlank and OverScan (which for me is about 15% per frame).  Hope that helps!

[Thomas Jentzsch]

13 minutes ago, johnnywc said:

As has been mentioned before, the ARM code is typically executed during VBlank and OverScan (which for me is about 15% per frame). 

More info:

• 6507 @1.19 MHz ~0.5 MIPS
• ARM7TDMI @70Mhz ~62 MIPS (~53.5 @60MHz)

Assuming 85% 6507 and 15% ARM time this results into ~9.7 MIPS which is a factor of ~19 compared to 6507 only.

Edited February 14, 2022 by Thomas Jentzsch

[+Andrew Davie]

1 minute ago, Thomas Jentzsch said:

More info:

• 6507 @1.19 MHz ~0.5 MIPS
• ARM7TDMI @70Mhz ~62 MIPS

Assuming 85% 6507 and 15% ARM time this results into ~9.7 MIPS which is a factor of ~19.

I'd say any ARM instruction does a lot more potential "work" than a 6507 instruction. And then there's the # bits in the operands.  I think these factors are significant and allow ARM to probably increase that advantage by quite a bit.

[+splendidnut]

1 minute ago, Thomas Jentzsch said:

More info:

• 6507 @1.19 MHz ~0.5 MIPS
• ARM7TDMI @70Mhz ~62 MIPS

Assuming 85% 6507 and 15% ARM time this results into ~9.7 MIPS which is a factor of ~19.

That's about what I was figuring.  20 times more power.... which is hard to see when there are other people just throwing around the 70mhz and claiming supercomputer! 

 

[Thomas Jentzsch]

2 minutes ago, splendidnut said:

That's about what I was figuring.  20 times more power.... which is hard to see when there are other people just throwing around the 70mhz and claiming supercomputer! 

That's only counting instructions. But @Andrew Davie is correct, the ARM instructions are more powerful. I have to look for a benchmark which has numbers for both (Dhrystone maybe).

 

[+Al_Nafuur]

29 minutes ago, Thomas Jentzsch said:

Just like DPC+. (I was referring to Gemintronic's post)

My point was (a little off topic), but a developer of a CDF, CDFJ, CDFJ+.. game, only has the option to release his game on cartridge via closed hardware/software (Melody board). Whereas a developer of none ARM games has multiple options.

[Thomas Jentzsch]

24 minutes ago, Thomas Jentzsch said:

That's only counting instructions. But @Andrew Davie is correct, the ARM instructions are more powerful. I have to look for a benchmark which has numbers for both (Dhrystone maybe).

I found about 340 Dhrystones/s for an Atari 8 Bit (1,79 MHz, ANTIC disabled). That would result into ~225 Dhrystones/s for a 6507. The ARM used in the Harmony cart has about 110,000 Dhrystones/s. That would be a factor of almost 500. But even though the Dhrystone benchmark is quite old, it seems not well suited for the 6502. The CPUs are just too many generations apart to find an adequate benchmark for both.

I figure the truth is somewhere between 19 and 500. I would guess ~50. 

 

BTW: Another source claims 0.02 DMIPS/MHz for the 6502 (vs. 0.68 for the ARM). That would result into a factor of 2,000, which seems even more unrealistic than the 500 from above.

Edited February 14, 2022 by Thomas Jentzsch

[+splendidnut]

1 minute ago, Thomas Jentzsch said:

I figure the truth is somewhere between 19 and 500. I would guess ~50. 

Yeah, that seems like a good guess to me... With my novice experience of looking at ARM assembly, it still seems there's a lot of LOAD, MODIFY, STORE sequences with memory ops which is on par with the 6502.  The big power increase (outside of the 32-bitness) seems to be the pointer/memory accesses themselves:  offset calculations are more powerful on the ARM than the 6502.

[+Pat Brady]

13 hours ago, orange808 said:

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.

 

2 hours ago, splendidnut said:

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*

 

No, you're absolutely right, and I should have worded it differently. And last night I was irritated by the notion that constraints are a "comfortable security blanket." That may be true in some contexts, but in the context of Atari 2600 game development, it is bullshit. This is a piece of hardware that has been obsolete for almost as long as it has existed, and we're all trying to do interesting things on it. It is not a source of comfort. It is a challenge. The challenge is the point.

 

What I meant about work was that, in the context of the Awards, speculation on how much work went into each game is not a factor in my voting at all.

 

WRT Game of the Bear and RobotWar:2684, I intentionally chose two deserving winners that did not compete against each other. And though I wasn't thinking of this at the time, they were both written by prolific authors whose full catalogs are pretty much award-worthy.

 

[+Gemintronic]

Might have said this before, but.. still mulling it over in my mind.  Especially when thinking about fairness of judgement for awards.

 

1. Game made with retail era hardware assist (original DPC, up to 64k ROM)

2. Games made with modern hardware assist (128k or more ROM, Boulderdash bankswitching, etc..)

3. Games made with modern hardware assist plus co-processing (Melody using ARM features, CDFx)

 

I think the non technical will always get more excited about games made with modern hardware assist + co-processing.  Especially if it's a replica of games they're already familiar with.  The closer you can get to arcade perfect the more nostalgic pull.  But, I think enough people understand the apparent difference in challenge going from divisions 1, 2 and 3 to warrant separate awards on technical achievement.

[Thomas Jentzsch]

That's in the direction of the tech rating I suggested above.