In case you don't know, SpiceC will allow C programmers to make Atari 2600 games. I don't know anything about C programming, so I'll have to keep using batari Basic. [Update: maybe not if the concepts are the same.]

Thanks for the interest, but I think it's a bit early for the poll. Those interested in being beta testers should keep an eye on my SpiceC blog entries, I'll hopefully have something for people to test within a couple months. For general use it'll be later in the year.

If you know BASIC you'll be able to pick up C fairly easily. Concepts are the same, just the formatting (syntax) is different.

Honestly I think the fact that precise timing is so critical for the 2600, the most powerful option will always be ASM.

With the right framework C will make programming the Atari more accessible since it'll be a standardized language that many people already know. bB is a very specialized version of basic. A VB.net programmer couldn't just pick it up and start writing a game immediately without first learning some things about the Atari. C also leaves the possibility of using more modern IDEs and having source level debugging. Little things like conditional breakpoints can be huge time savers.

Honestly I think the fact that precise timing is so critical for the 2600, the most powerful option will always be ASM.

This is no longer true. I write my display kernels in C code that runs on the ARM chip and use the time in between emulating the ROM to calculate the next few bytes of ROM on the fly. It's kind of like having a display kernel which is made up of only LDA# STA tia_reg repeated over and over, but instead of hardcoding it in ROM you create it dynamically just before it's executed by the Atari.

I neither can nor will judge this (except for it being cool on its own).
But I ask to keep in mind that BatariBasic, DPC+, ARM, etc... will (and already have!) changed people's view of the VCS.
To me it loses a lot of its charme. Being the minimalistic console it used to be.
'Racing the beam' (that actually along with others triggered a new hype I dare say) becomes obsolete.
People forget about TIA, RIOT.
If different approaches are not separated by the designers, developers and gamers the Atari VCS at its core will vanish.
Surely you can still code in 4,8,12,16 KB and re-live the pain/challenge/excitement that VCS developers had for decades(!).
But it might become obsolete.
4 out of 5 new additions in the store rely on heavy additional processing power on the cartridge.
And people out there do not know the difference. It might in fact not matter to the person who plays the game. But what about the legacy value of the VCS?
I love what people do and what crazy ideas they actually realize but if the community as a whole is not carefully and open about it, it will annihilate what the VCS used to be.
It pains me to see old coding heroes being degraded to noobs in youtube/facebook/forum comments because their games didnt scroll or feature large title screens.
This is merely my personal statement, so hopefully noone is offended or feels criticised.
I am only worried. Quite worried.

I have this concern too and recognize that there will be people that compare a game built in 2018 with an ARM chip to a game built with only 2K of ROM back in the day. But I've also considered that someone is going to keep pushing the limits of what a 2600 cart can do. So I might as well join in with the fun and just make it a point to educate people that newer technology in the cart allows for visuals that were once impossible on the system. Besides no matter how much processing power there is on the cart, you still can't overcome the limitations of the TIA.

This is no longer true. I write my display kernels in C code that runs on the ARM chip and use the time in between emulating the ROM to calculate the next few bytes of ROM on the fly. It's kind of like having a display kernel which is made up of only LDA# STA tia_reg repeated over and over, but instead of hardcoding it in ROM you create it dynamically just before it's executed by the Atari.

Yes, if you let the ARM do the major work, then C is efficient enough to drive the TIA. But if you use a stock VCS without extra CPU, then nothing can come close to Assembler.

Besides no matter how much processing power there is on the cart, you still can't overcome the limitations of the TIA.

Like I said frequently before, to me the 2600 is not only the TIA. It is only the most significant bottleneck left by modern tech today.

Same here. To me it feels like Atari 2600 developing history is being rewritten.

But I honestly have no idea how to avoid that. If in theory(!) a whole computer would fit into a cart and we would then create games which only mock the 2600, most (non-developing) people would still think these are legit.

As I've blogged about before, adding extra hardware inside the cartridge is a fundamental part of the 2600's history. If you want to limit yourself to a specific period in time that's fine, and I even did so for Collect (including the color cycling "screen saver" that is seldom seen anymore), but I'm going to continue to work with others to keep advancing that history.

Games written using Spice C will start up with a splash screen showing AtariAge and Made With Spice C, using the logo below which was first mentioned here. The splash screen is when the timing is done for console detection - this is used so a single ROM can show proper colors on NTSC, PAL, and SECAM systems.

SuperCharger BASIC will let you declare unlimited variable arays while Flashback BASIC must steal extra array space from the virutal world because it uses CBS RAM which only covers the virtualworld and sprite RAM (256 bytes), even the row colors and sprite colors steal space from the virtual world, stored in the top two rows.

A more minor difference is that if you don't clear the virtualworld RAM it fills with garbage in it in the Stella emu, but not on the real hardware or the Javatari emu.