Jump to content
IGNORED

Will you use bB, SpiceC, or both?


Random Terrain

Will you use bB, Spice C, or both?  

29 members have voted

  1. 1. Will you use bB, Spice C, or both?

    • I'm only going to use batari Basic.
      4
    • I'm switching to SpiceC.
      5
    • I'll use batari Basic and SpiceC.
      9
    • I only use assembly language.
      5
    • I only use batari Basic and assembly language.
      2
    • I just hack the graphics of classic games, so I don't care.
      0
    • I beg or pay others to make games for me. I don't care what they use.
      0
    • I only play games. I don't care what is used. Just make me more games to play!
      4

  • Please sign in to vote in this poll.

Recommended Posts

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.

Batari Basic for loops:

for x = 1 to 10 : a[x] = x : next




C for loops:
for (x=1; x<=10; x++)
{
   a[x] = x;
}




Batari Basic if-then-else:
 if a > b then r = 2 : pfpixel 3 5 on : d = d-1 else d = d+1 : r = 3




C if-then-else (// is a comment, like rem or ; in batari BASIC)
if (a > b)
{
  r = 2;
  pfpixel(3, 5, ON);
  d--;  
  // Note the following could be used instead of d--
  // d = d - 1;
  // d -= 1;
}
else
{
  d++; // likewise d = d + 1 or d += 1 could be used
  r = 3;
}


  • Like 4
Link to comment
Share on other sites

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

Maybe it wouldn't be so hard then. I'm also used to surrounding things with curly brackets when using CSS.

Link to comment
Share on other sites

I've been learning Ada, a very strongly typed language - and it's taught me a lot about C and BASIC.

 

I think the 2600 really is so much about the hardware that you can't use strong typing.

 

I agree it's too early to be talking about C for the 2600.

 

What does having C over BASIC for the 2600 achieve? This is a genuine question, and not a snarky comment!

 

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

Link to comment
Share on other sites

What does having C over BASIC for the 2600 achieve? This is a genuine question, and not a snarky comment!

The language shouldn't make a big difference. Maybe the coding will become easier for those used modern languages for years.

 

But the framework should benefit from the extra experience and better additional hardware available now.

 

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

That's for sure.

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

I am only worried. Quite worried.

 

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.

Link to comment
Share on other sites

Here we go again :roll:

 

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.

 

 

if the community as a whole is not carefully and open about it

 

All along I've been open about the use of 32K for Medieval Mayhem (which was not at all common back in the day, I believe Fatal Run from 1990 was the only one to do so) as well as the use of DPC+ and CDF in my later games.

 

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.

 

post-3056-0-03262500-1510854205.png

  • Like 4
Link to comment
Share on other sites

In case you don't know, Spice C 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.

 

Cool to see a another Tiny C implementation, I think there is at least one other C that is far enough along to run demo's and example code and another in development.

 

Anyone who prefers programming in BASIC might like to try Flashback BASIC and SuperCharger BASIC.

 

They have advanced functionality like a PPU and display lists and they run on a standard Atari.

 

Flashback BASIC Quickstart guide

 

Flashback BASIC Manual

 

Here are 20 BASIC games you can play online and programming lessons to get you started.

 

If you prefer old school vintage BASIC, that's supported too, graphics designers are optional.

 

You can also create audio visuals with no programming using just the desingers.

Link to comment
Share on other sites

 

Cool to see a another Tiny C implementation, I think there is at least one other C that is far enough along to run demo's and example code and another in development.

 

Anyone who prefers programming in BASIC might like to try Flashback BASIC and SuperCharger BASIC.

 

They have advanced functionality like a PPU and display lists and they run on a standard Atari.

 

Flashback BASIC Quickstart guide

 

Flashback BASIC Manual

 

Here are 20 BASIC games you can play online and programming lessons to get you started.

 

If you prefer old school vintage BASIC, that's supported too, graphics designers are optional.

 

You can also create audio visuals with no programming using just the desingers.

 

What's the difference between Flashback BASIC and SuperCharger BASIC?

Link to comment
Share on other sites

 

What's the difference between Flashback BASIC and SuperCharger BASIC?

 

Great question RT, both BASIC's are cross compatible with only minor differences for the programmer:

 

Flashback BASIC has 5K like a VIC-20, while SuperCharger BASIC has 4K available, SuperCharger SpaceInvaders no longer runs on the SuperCharger as of Beta4 because it runs out of memory:

 

http://atariage.com/forums/topic/269548-supercharger-spaceinvaders/

 

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.

  • Like 1
Link to comment
Share on other sites

I won't vote until I see Spice C in the virtual flesh, but if nothing else, this thread gives a place to discuss it in the meantime. :)

 

It seems to me that the main advantage of this over DPC+ bB isn't the language of choice, but rather having the main game logic in ARM code, allowing for more CPU cycles, addressable RAM, etc.

 

I'm not thrilled at the idea of having to use a Linux VM, so I may at least try my hand at compiling the toolchain for my beloved Mac.

Link to comment
Share on other sites

I may at least try my hand at compiling the toolchain for my beloved Mac.

Be great if you got it working. I found this at GitHub, it hasn't been updated in a few years but might be useful:

This script builds the Linaro ARM toolchain on Mac OS X and for Mac OS X. Base is the modified version of the crosstool-NG by Linaro.

DirtyHairy got it to run via a Docker container. I haven't looked into it yet as the limitation will probably require revisions to the scripts.

The wrapper script mounts the current working directory into the docker container. Therefore, all source files must reside below the current working directory.

Linaro's also available for Windows, perhaps that version could be run on the Mac via Wine. Likewise I bet that'll require script revisions.

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