Will you use bB, SpiceC, or both?

[vidak]

Yeah I'm with the ASM or die faction, but I won't get in the way of the raspberry pi nanos in cartridges aping the 2600 hardware.

 

I think the normative test for "aping" or "traditional" should be: is the code actually being executed by the 2600 hardware?

 

Personally I don't care either way, but I will only evet write "traditional" 2600 code without acceleration.

[+stephena]

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.

 

This is not the case, as was discussed ad-infinitum before. Why don't you (a) just use Javatari exclusively, and (b) stop using and commenting on Stella completely. You're doing this in multiple threads, giving false information and in general being confused about what's going on. And TBH it's starting to really irritate me, spreading incorrect info.

[Kiwi]

 

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

 

This is true. C programming for the Colecovision have a programmer's guide and I just use those functions and mine. You'll have to deal with brackets and semicolon in C. There's array in C, gosub/function, branches, enough to make a game.

[Mr SQL]

 

This is not the case, as was discussed ad-infinitum before. Why don't you (a) just use Javatari exclusively, and (b) stop using and commenting on Stella completely. You're doing this in multiple threads, giving false information and in general being confused about what's going on. And TBH it's starting to really irritate me, spreading incorrect info.

 

stephena, there's no reason to get angry. Regarding the thread with the uncleared register bug, why not implement the same fix made to the Harmony BIOS instead? Check the original thread where Fred, Ekhard and I resolved the SuperCharger bug; you'll see it indeed had to do with a register not being cleared.

 

Regarding Flashback BASIC working differently in Stella, I think CBS RAM should be cleared unless you want to emulate frying the cart; that's not static RAM.

 

Javatari has slightly different behavior so I think it's a good idea to check both. It's cool that it has a different codebase and I like using Stella and Javatari to compare when something works differently on the real hardware for that reason, it can help to determine if it's a bug or not.

[Lillapojkenpåön]

I don't think I will feel inspired to make another batari Basic game after my first one, but it was really fun and easy to learn, and a great simple way to learn how to think about coding for the 2600, or coding at all as in my case.

 

I'm really looking forward to try Spice C, and if the forum gets a Spice C section it will probably be a great place to learn C while making an awesome 2600 game.

Edited February 25, 2018 by Lillapojkenpåön

[+Gemintronic]

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.

 

Yep. Easy to use development tools will cave in all enthusiasm for the VCS. You've made this clear in other threads.

 

You've posted this in the batari BASIC section with more game makers rather than game developers. Game makers are excited to create games. Game developers are more excited over the technical challenges and show of nuanced experience in coding. Neither perspective is wrong until we judge the other side.

[+Random Terrain]

If a modern assembly language programmer doesn't use the same tools as they did in the early 1980s, all copies of his or her program should be destroyed. And the punishment for quick and easy testing with an emulator should be public flogging.

 

youtube.com/watch?v=os2ZZF4JWNw

https://www.youtube.com/watch?v=os2ZZF4JWNw

[ZackAttack]

If a modern assembly language programmer doesn't use the same tools as they did in the early 1980s, all copies of his or her program should be destroyed. And the punishment for quick and easy testing with an emulator should be public flogging.

 

I'm not sure that's severe enough punishment. Perhaps we could make a custom cart with some switches to program it one byte at a time and require them to use that for all future development. Of course it would be stored in RAM so you have to program it again if you cut the power.

Edited February 27, 2018 by ZackAttack

[Osgeld]

If a modern assembly language programmer doesn't use the same tools as they did in the early 1980s, all copies of his or her program should be destroyed. And the punishment for quick and easy testing with an emulator should be public flogging.

 

 

my god how tall are the doors in that place

[enthusi]

I do not mind easy to use tools.

But these come hand-in-hand with major changes to the total ability of the device.

I simply do not follow the-more-the-better approach here - I hope no one who does feels offended.

I value efficient game-design and efficient code-design alot.

Both things the VCS used to stand for.

[Osgeld]

I thought it stood for Video Computer System

[carlsson]

It is true that the old style of hand coding your own kernal and fitting both the game and all audiovisuals in the frame, gave 2600 programmers a bit of mad scientist feel. Most of us others who indeed understand 6502 assembly language but are way too lazy to juggle cycles on such low level wouldn't even bother going there, given the amount of time required to get a stable display. I understand that with things like batari BASIC and C compilers, the 2600 becomes far more accessible, but also far less mysterious. Now it to a big deal can be treated like any other retro gaming system with strictly limited resources.

 

I suppose it is the mysterious flare that some might regret see going away, but the question is what you get instead? More programmers, more game concepts with varying degree of doability, an even wider following? Or just watered out efforts that are no different than what you find elsewhere?

[DirtyHairy]

I think one aspect worthy of note is the hard dependency of all current ARM-enabled games on the SOC of the harmony / melody. At the moment, the only way to run any game that uses the ARM (short of the original cartridge that includes the SOC) is either the harmony cartridge or an emulator (and the only choices that support ARM at this time are Stella and Stellerator). If the harmony cartridge ever was to go out of production, considerable effort would be necessary to get those games to run on a new cartridge platform, much more than is required for other cartridge types. Anybody developing an ARM-enabled game can decide that this is an acceptable tradeoff, but they should be aware of it.

Edited February 27, 2018 by DirtyHairy

[+SpiceWare]

I value efficient game-design and efficient code-design alot.

 

With only 26K^* of space for the ARM code(ARM Thumb instructions taking 2 or 4 bytes each) and its data (which tends to be larger due to more detailed sprites, more colorful sprites, audio samples, 3-voice music data, etc.) efficient code is still a major factor. We spend a lot of time optimizing, with help from cd-w, Thomas, and others. John's currently doing a round of optimizing on Mappy.

 

^* 32K - 4K for 6507 code - 2K for CDF driver. We only had 24K of space when we used DPC+. A major part of the design of the newer CDF that I'm using with Spice C was, surprise-surprise, to be more more efficient.

[Thomas Jentzsch]

I suppose it is the mysterious flare that some might regret see going away, but the question is what you get instead? More programmers, more game concepts with varying degree of doability, an even wider following? Or just watered out efforts that are no different than what you find elsewhere?

That's the question. I don't follow bBasic very closely, but most results I have seen don't make me very optimistic. And for the few remaining games I sometimes would like to see a remake which uses the hardware more efficiently.

 

And IMO it's not a mysterious flare which gets lost. Once each Atari 2600 game was born in the kernel. Almost everything else revolved around that kernel. So designing an optimal kernel was (and for me still is) one major key for creating the optimal game solution. Without that, you are limited to a number of standard kernels (I can spot more than 9/10 bBasic games within seconds) and a major part of the original uniqueness of each game gets lost.

 

Using ARM based kernel eases the problem a bit, because most logic is moved from the 6507 kernel code into the language used for the framework. So at least in theory the standard kernels might become a bit more flexible. But still the result can always only be a compromise lacking its own unique look.

[Thomas Jentzsch]

With only 26K^* of space for the ARM code(ARM Thumb instructions taking 2 or 4 bytes each) and its data (which tends to be larger due to more detailed sprites, more colorful sprites, audio samples, 3-voice music data, etc.) efficient code is still a major factor. We spend a lot of time optimizing, with help from cd-w, Thomas, and others. John's currently doing a round of optimizing on Mappy.

That's true for now.

 

But I am 100% sure this limit will soon fall. Soon we will have 64K games and once a new board has been designed, only costs are the limit. And we all know that hardware costs are dropping permanently. So affordable memory available will increase more and more. And then there will be no need for any space optimizations.

 

Also speed will not become a relevant issue, because processor speeds are every increasing too. So soon we will be in about the same situation as modern game development and efficient hardware will allow inefficient coding. So a major part of the attraction of the 2600 to many developers will be lost.

 

And in the future, when the current modern hardware we base our current games on will become obsolete, we may have another problem.

[enthusi]

 

With only 26K^* of space for the ARM code(ARM Thumb instructions taking 2 or 4 bytes each) and its data (which tends to be larger due to more detailed sprites, more colorful sprites, audio samples, 3-voice music data, etc.) efficient code is still a major factor. We spend a lot of time optimizing, with help from cd-w, Thomas, and others. John's currently doing a round of optimizing on Mappy.

 

^* 32K - 4K for 6507 code - 2K for CDF driver. We only had 24K of space when we used DPC+. A major part of the design of the newer CDF that I'm using with Spice C was, surprise-surprise, to be more more efficient.

To me (and a large fraction of embedded linux coders out there and even more so any ARM microcontroller developers) this is completely different (and actually QUITE popular) game.

Even if you would write everything in perfect ARM assembler.

Not saying that it is trivial or even simple here.

 

If tools make things simpler: great.

But here these tools require major changes of the 'things'

Also totally valid. But something completely else.

Maybe not so much from the gamer's perspective who evaluates the game and not the code but I would prefer 'native games' with all their special charme and wit in game logic (dictated by restrictions and then embraced by the most knowledgable of the coders) over a game written in C running on ARM, using VCS colors and audio and still looking worse than any C64 game of 1982 (no offence

 

A VCS on steroids gets pretty close to a PICO8.

Restrictions for colors, graphics and also for ROM size, sure.

But the CPU is almost taken out of the specs. People do incredibly amazing stuff with the Pico8, no doubt.

Written in LUA which allows for a quick success and easy entry level. It oozes 'retro' visually but has yet nothing to do with it.

 

Sorry if I got carried away here

I am not judging what others do but I try to portrait a picture of how I see these recent developments with more than a grain of salt.

 

Edit:

I too wrote some code for small ARM CPUs/microcontroller (not even SOCs). Partially in C but also in ARM assembler.

[+SpiceWare]

Yep, and we're back to continuing the history of Adding Extra Hardware inside the cart. As such this will be my last reply on "should/shouldn't" - if you're interested, follow along; if not, don't.

[enthusi]

Hm, I am sorry if that caused any distress.

"should/should not" was never my intention. We should just be very aware of what this (potentially) means and brings along with it.

[Thomas Jentzsch]

Darrell, IMO you shouldn't feel attacked here, because you aren't. If you don't write the framework, someone else will. Same for the hardware and drivers. That's not the problem.

 

IMO the problem is, how do we make the "ordinary" people understand what is going on? Being open about the hardware used (like you are) is the first step. But this is not sufficient. Comments like "You would be millionaires back then." show the problem. Most people do not realize what is going on. And to be honest, I doubt that there is much we can do about it, besides being open. Those who want to see will see. But I am afraid most people don't care about legacy and values.

 

Nevertheless, a rational discussion about this topic should be possible between those who care. And I know you do.

[Mr SQL]

Hm, I am sorry if that caused any distress.

"should/should not" was never my intention. We should just be very aware of what this (potentially) means and brings along with it.

 

While I agree with Gemtronics perspective, you have raised an important issue which I think Atari's new portable consoles addresses succinctly; they do not expose the ARM chip (except as market research for an experiment via one controlled release) specifically so that games will be limited to using the Atari platform as it existed bitd.

 

ie SuperChip, CBS RAM and other legacy expansion schemes are supported but running 32-bit game loops on the ARM is not.

 

There is another C project you may like better but it does not as yet have it's own runtime library/framework like this one does; I've encouraged the author to utilize my ASDK framework which SuperCharger BASIC and Flashback BASIC use to provide a soft blitter chip and display lists like the A8 using legacy technology only, which is also possible. DLI's in particular make the ASDK competitive with many of the 32-bit ARM rendering techniques, but being restricted to 4K and 5K (which I think makes it more fun) of compiled BASIC is the limiting factor here.

 

I'm looking forward to seeing and playing the games from this C because the awesome games used to model the framework/runtime give it alot of potential!

[+SpiceWare]

Hm, I am sorry if that caused any distress.

"should/should not" was never my intention. We should just be very aware of what this (potentially) means and brings along with it.

Sorry if I took it the wrong way.

 

It seems that you're coming to this after seeing dismissal of older developers, something I've always made clear that they had constraints that we don't such as in the interview I linked to:

MT> Why is 'Medieval Mayhem' so much better than the original 'Warlords' for the Atari VCS?

 

DS> I think the main thing is that nowadays ROM is cheap. Carla Meninsky only had 4K of ROM to work with for Warlords, and she utilized it to the fullest. In contrast, Medieval Mayhem uses 32K, of which 6K alone is used for the main menu. Having additional ROM made it possible to add features from the arcade version that could not be squeezed into a 4K game.

While I'm coming at it from dismissal of what I'm doing, such as this comment I ran across about Draconian - "This is a 2600 game in the same way that Virtua Racing is a Genesis game, maybe even less so." As such, I become a bit defensive.

 

As far as getting people to understand, I don't think that's possible. Sure people here understand that Asteroids was possible because of the added resources due to the creation of bankswitching, that Jr. Pacman was possible because they figured out how to add RAM inside a cartridge that wasn't designed for it, and that Pitfall 2 used a coprocessor; however the typical gamer has no idea what any of that even means, let alone care about it.

[StanJr]

Nothing is ever going to make me not like or look down upon Ms. Pac-man. I can play that thing all day. I don't care if it was made by Captain Picard on Data's neural net using an iron flling in a cave during the 19th century. It's a great game, it's a lot of fun. No amount of new homebrew releases are going to change that. By the same token, I'm also plenty excited about Draconian, Mappy, and whatever else is pushing or being pushed by new developments in how the VCS utilized. Is there a ceiling where I say, "ok, this no longer looks like the Atari 2600 at work?" Probably, but I haven't seen it yet. I'm not smart enough to know the inner workings of what's going on, I just know if I enjoy a game or not.

I can see how people new to the 2600 might not know the difference, but chances are good they didn't grow up with the system so they wouldn't likely know anyway. Furthermore, if some impressive new game brings them to the system with all of it's whistles and bells, I don't see the down side. People who really geek out on this stuff will then dig in and learn all about the system and its origins, its original limitations and its development history. People who don't will play the hot game for a few weeks and then move on to something else.

 

Maybe I just have no idea what the problem is. If Thomas makes incredible games that are fun to play with ASM and Darrell makes incredible games that are fun to play with Spice C, and bjbest makes incredible games that are fun to play with Bb, don't we all win?

[+Random Terrain]

I made this thread to see how many batari Basic (bB) users will be switching to Spice C when the time comes. If most bB users are going to switch to SpiceC, it would be stupid of me to spend months working on a new online tutorial that will be an adapted version of a couple Atari Basic books (so new users can learn about BASIC and bB at the same time).

 

Since some assembly language programmers who have the ability and inclination to improve bB don't have much spare time to devote to it and other assembly language programmers seem to hate any tool like batari Basic that can give the common man and the learning disabled the ability to make Atari 2600 games, batari Basic is probably going to wither and die. Visual batari Basic (the bB IDE) has already been abandoned, so it will probably stop working after some future Windows update and we'll lose many useful features and tools that other text editing programs will never have. If bB is dying, it would be smarter to focus on SpiceC.

About some of the other stuff that was posted in this thread, below are a few things I have on the bB page.

Q. Why do people make Atari 2600 games these days?

A. There seems to be three main reasons why people make Atari 2600 games:

• They want to do something hard to challenge themselves, so they use assembly language.
• They're doing it for school.
• They had an Atari 2600 as a kid and always wanted to make their own Atari 2600 games because there's something special and magical about the graphics and sound effects that other consoles don't have.

The third type of person will usually want and need every tool, trick, and shortcut they can get. That's why they use batari Basic, Visual batari Basic, and various kernels, minikernels, modules and enhancements.


______________________________________________________


Q. Isn't it lazy to use batari Basic?

A. As it says in this post at AtariAge, it's hard to make a fun game that anyone would want to play, whether you use assembly language or batari Basic. There's a lot of crap out there made with assembly language, so using assembly language doesn't mean your game will be any good.

The time and energy you save by using batari Basic can be used on trying to make your game more fun. You can think of batari Basic as the lazy way out, but you still have to come up with the most unique concept that you can, write the program and create your sprite animations and sound effects. There's a lot of work to do if you want to create a polished game that hasn't already been done to death.

The tool you use doesn't really matter. What matters is that your game must be fun. And it also wouldn't hurt if it's fun while being fairly unique instead of just being another clone or port.


______________________________________________________


Q. Isn't using more than 4k considered cheating?

A. Atari and other companies used more than 4k in the early 1980s. If it wasn't cheating back then, why would it be cheating now? Take a look at my page about cheating for more information.

[Osgeld]

Some of us like making games (in my case nothing ever I consider release worthy) but we are not professional developers in the peak of the Atari craze, we are not going to get 100 grand for a space shooter that can be barfed out for an iphone in 10 min in 2018, and we have jobs and lives that reflect that

 

we just want to have fun with our old little toy, sorry if that offends the purists, how dare someone have fun with a 2600, heresy I tells ya

Edited February 28, 2018 by Osgeld