Legacy versus ARM-based 2600 Game Development

[+Random Terrain]

Single-height sprites on the Atari 2600 are better looking to me than Atari 7800 sprites, so I plan to stick with the Atari 2600.

 

The best kernel that batari Basic has at the moment is DPC+, but it doesn't have enough normal variables (easy-to-use variables that you don't have to push and pull from the stack). The DPC+ kernel has bigger, more colorful playfields and more sprites with twice the data of standard kernel sprites, but all of that sprite and playfield data is still supposed to fit in one little 4k bank.

 

If we had the ability to stuff two or three banks with sprite and playfield data and have something like 512 to 1024 variables, I could make the Atari 2600 games I've been wanting to make for years. Does anyone feel like creating a DPC++ kernel?

 

[Someone might ask, why don't you learn how to use assembly language and become a highly efficient coder so you could make the most complicated games using only 2k and 4 variables? I have what might be called a learning disability. Maybe there's another term for it. I'm lucky I can use BASIC. My code will always be more bloated and complicated than it should be. My brain is like a strainer. Only certain things will stay in the strainer and I never know what those things will be. I basically start from scratch every time I try to do something. I do a lot of copying and pasting and reverse dictionary style searches using a search engine. My only hope is for people with bigger and better brains to create things like DPC++ or DPC+++++++++. Some people make Atari 2600 games for the challenge of doing it with the least amount of ROM, RAM, and code. I like to make Atari 2600 games because I like the Atari 2600. I'll use a supercomputer in a cartridge if that's what it takes for me to get the job done.]

[+Andrew Davie]

8 minutes ago, Random Terrain said:

My code will always be more bloated and complicated than it should be. My brain is like a strainer. Only certain things will stay in the strainer and I never know what those things will be. I basically start from scratch every time I try to do something. I do a lot of copying and pasting and reverse dictionary style searches using a search engine.

Welcome to my world!

[+ZeroPage Homebrew]

Double Post, Ignore

Edited January 18, 2020 by ZeroPage Homebrew

[RevEng]

5 hours ago, Random Terrain said:

Single-height sprites on the Atari 2600 are better looking to me than Atari 7800 sprites, so I plan to stick with the Atari 2600.

In it's lowest resolution, the 7800 sprites are the same pixel width and height as the 2600 single-height sprites, except on the 7800 sprites can be multi-color on the same line without flicker, and be up to 32 bytes in width - bytes, not bits. That's not even taking into account the higher resolution 320 pixel modes.

 

If you're perceiving a superiority on the 2600 side for some specific comparison, that's purely up to a difference in pixel artist work. Have a look at the 7800 Bentley Bear, Arkanoid, or Rikki&Vikki homebrews, and let me know if you still think the 2600 has better looking sprites.

 

[edit - here we go again. Soon Al's going to have to move a bunch of 2600 vs 7800 posts into a new thread.  ]

 

[+Random Terrain]

1 hour ago, RevEng said:

In it's lowest resolution, the 7800 sprites are the same pixel width and height as the 2600 single-height sprites, except on the 7800 sprites can be multi-color on the same line without flicker, and be up to 32 bytes in width - bytes, not bits. That's not even taking into account the higher resolution 320 pixel modes.

 

If you're perceiving a superiority on the 2600 side for some specific comparison, that's purely up to a difference in pixel artist work. Have a look at the 7800 Bentley Bear, Arkanoid, or Rikki&Vikki homebrews, and let me know if you still think the 2600 has better looking sprites.

 

 

Thanks. Looks like Rikki & Vikki have sprites that are as detailed as you'd expect from a better console. Not blocky-looking like some other sprites I've seen on the Atari 7800. Problem is I couldn't move to the Atari 7800 until someone makes an IDE for 7800basic that is similar to Visual batari Basic.

 

I bet somebody could adapt this JavaScript sprite editor for the Commodore 64 so it will be able to make Atari 7800 sprites:

vintageisthenewold.com/new-online-sprite-editor-for-the-commodore-64/

Edited January 18, 2020 by Random Terrain

[RevEng]

26 minutes ago, Random Terrain said:

Problem is I couldn't move to the Atari 7800 until someone makes an IDE for 7800basic that is similar to Visual batari Basic.

Matt Smith (@mksmith)  is the author of the very pretty 7800 Arkanoid port I linked to earlier, and he's also the author of Atari Dev Studio. It's an IDE for both the 2600 and 7800, which works with bB, 7800basic, and dasm. It has a 7800basic compatible sprite editor, which Matt personally uses to create and update sprite designs for Arkanoid. (His were the initial sprites, but now it's fair to say the majority of the Arkanoid graphics were provided by the very talented @Defender_2600.)

 

Come on in, the water is fine.

 

[Omegamatrix]

19 hours ago, TwentySixHundred said:

Im worried about those making breakthrough discoveries like Spiceware - Reveng ect are going to feel deflated/discouraged by the criticism. Just don't want to lose their valuable input as it's essential to progress and development. Even as a bB user i feel a bit on the backfoot and somewhat of a 'cheater' by using these tools because some despise the use of. Personally i like the BASIC language and feel comfortable using it and think it's the best thing since sliced bread.

 

Here i have been waiting for years that Batari would pick the bB project back up again and continue development. I have a hunch he may have discontinued the project for having the same feelings of those who feel discouraged to continue theirs. No idea but a question that sits in the back of my mind.

Yeah, I'm pretty sure they don't feel too great about it. I've not surprised about the difference in opinions, but I am discouraged by the hostility to change. Here we have this amazing tool that can help us build really amazing games, and the discussion just seems to have enabled people to pull out a shovel and start dumping crap all over it out of fear.

 

When a new homebrew thread gets sidetracked by pages of debates of why a game couldn't have been done in the day, how it is unfair to other homebrews or games of the past, and the insistent need to educate people about these things, then I just think wow we have really missed the point, completely.

 

Someone has a new game, they want to share it and see what you think. I'm sure they don't post it to have a never ending debate on what an Atari game is.

 

When someone posts a crappy game usually very few people comment and those that do are usually supportive with ideas for improvement. When someone posts an great game with a different processor it's like WWIII and the fricking nukes are coming out. I just think man you don't have to be that way, you don't have to feel threatened, and if you don't like it why not just leave it alone? I'm sure the author would rather have some feedback on how it plays than a whole pile of shit comments.

[+TwentySixHundred]

4 hours ago, ZeroPage Homebrew said:

Ah! Thank you for the correction.

 

Is there a comprehensive post somewhere that outlines DPC, DPC+, CDF/CDFJ, ARM, Harmony, Harmony Encore, UnoCart and the all the various related/supported bankswitching techniques of each? The classic bankswitching methods seem well documented but not all the newer ones. I'm able to find bits and pieces here and there but piecing them all together makes my head spin a bit.

 

4 hours ago, Random Terrain said:

Single-height sprites on the Atari 2600 are better looking to me than Atari 7800 sprites, so I plan to stick with the Atari 2600.

 

The best kernel that batari Basic has at the moment is DPC+, but it doesn't have enough normal variables (easy-to-use variables that you don't have to push and pull from the stack). The DPC+ kernel has bigger, more colorful playfields and more sprites with twice the data of standard kernel sprites, but all of that sprite and playfield data is still supposed to fit in one little 4k bank.

 

If we had the ability to stuff two or three banks with sprite and playfield data and have something like 512 to 1024 variables, I could make the Atari 2600 games I've been wanting to make for years. Does anyone feel like creating a DPC++ kernel?

 

[Someone might ask, why don't you learn how to use assembly language and become a highly efficient coder so you could make the most complicated games using only 2k and 4 variables? I have what might be called a learning disability. Maybe there's another term for it. I'm lucky I can use BASIC. My code will always be more bloated and complicated than it should be. My brain is like a strainer. Only certain things will stay in the strainer and I never know what those things will be. I basically start from scratch every time I try to do something. I do a lot of copying and pasting and reverse dictionary style searches using a search engine. My only hope is for people with bigger and better brains to create things like DPC++ or DPC+++++++++. Some people make Atari 2600 games for the challenge of doing it with the least amount of ROM, RAM, and code. I like to make Atari 2600 games because I like the Atari 2600. I'll use a supercomputer in a cartridge if that's what it takes for me to get the job done.]

That's where the underlining complexity lies with bB DPC+ as opposed to ARM tech written in ASM. Although bB DPC+ is using ARM technology bB has qwerks and restrictions of it's own (we are already on the back foot). Some would think we have all this extra RAM and co-processor power when in reality the same level can be achieved with those who write code in assembler, bankswitch and create virtual sprites.

 

bB really needs it's own category because as RT has mentioned we only have 4k of that 32k to stuff all our graphics data in and that includes colours. There is a trick i have used for Street Rod 2600 that sacrafices code ROM space to save on using graphics bank data but it's extremely ROM costly and tedious. It's basically nothing compared to assembler where you could fill two + full banks of graphics data. DPC+ is commonly used with bB for the simple fact of giving bB uses a more even playing field IMO. Trying to create a 4k bB game with more substance then say Combat is extremely hard. We have the restrictions of not only the system but additional for bB itself.

 

As easy as it is to make a quick simple little game in bB it's quiet the challenge in itself to make something fun and with meat on the bones. Im just hoping the development of the DPC+ kernel continues and we can utilize more of it's potential power to be honest. And the ability to store graphics data in other banks if we wish would be nice. Reveng, Omegamatirix and Karl G ect have been slowly making some improvements and they're much appreciated!

Edited January 18, 2020 by TwentySixHundred

[+TwentySixHundred]

49 minutes ago, RevEng said:

Matt Smith (@mksmith)  is the author of the very pretty 7800 Arkanoid port I linked to earlier, and he's also the author of Atari Dev Studio. It's an IDE for both the 2600 and 7800, which works with bB, 7800basic, and dasm. It has a 7800basic compatible sprite editor, which Matt personally uses to create and update sprite designs for Arkanoid. (His were the initial sprites, but now it's fair to say the majority of the Arkanoid graphics were provided by the very talented @Defender_2600.)

 

Come on in, the water is fine.

 

I too would like to test the waters in 7800BASIC sometime soon however it's a matter of expanding from my 2600 habits i find the problem at the moment.

[+TwentySixHundred]

20 minutes ago, Omegamatrix said:

Yeah, I'm pretty sure they don't feel too great about it. I've not surprised about the difference in opinions, but I am discouraged by the hostility to change. Here we have this amazing tool that can help us build really amazing games, and the discussion just seems to have enabled people to pull out a shovel and start dumping crap all over it out of fear.

 

When a new homebrew thread gets sidetracked by pages of debates of why a game couldn't have been done in the day, how it is unfair to other homebrews or games of the past, and the insistent need to educate people about these things, then I just think wow we have really missed the point, completely.

 

Someone has a new game, they want to share it and see what you think. I'm sure they don't post it to have a never ending debate on what an Atari game is.

 

When someone posts a crappy game usually very few people comment and those that do are usually supportive with ideas for improvement. When someone posts an great game with a different processor it's like WWIII and the fricking nukes are coming out. I just think man you don't have to be that way, you don't have to feel threatened, and if you don't like it why not just leave it alone? I'm sure the author would rather have some feedback on how it plays than a whole pile of shit comments.

It's a tricky debate and where i understand the purist side of the fence about recognition for bare bones programing i whole heartily respect that ?. However as a bB programmer i understand the side we stand on all too well. I started writing code since 2009 for bB and only last year actually posted my first full game. Got to the stage i was like "frick it im going to post this DPC+ 32k game and if people don't like well so be it".

 

I just feel only those who frequently use bB really understand it has additional limitations of it's own. It's no easy walk in the park to make something fun with some substance. I think people look at the easy part of bB and that's only putting some boring sprites on the screen and moving them about. The real challenge/skill comes from making the game actually fun within bB's limitations.

[+Random Terrain]

1 hour ago, RevEng said:

Matt Smith (@mksmith)  is the author of the very pretty 7800 Arkanoid port I linked to earlier, and he's also the author of Atari Dev Studio. It's an IDE for both the 2600 and 7800, which works with bB, 7800basic, and dasm. It has a 7800basic compatible sprite editor, which Matt personally uses to create and update sprite designs for Arkanoid. (His were the initial sprites, but now it's fair to say the majority of the Arkanoid graphics were provided by the very talented @Defender_2600.)

 

Come on in, the water is fine.

 

 

Thanks. I either forgot it existed or didn't know it existed.

[Omegamatrix]

15 hours ago, TwentySixHundred said:

It's a tricky debate and where i understand the purist side of the fence about recognition for bare bones programing i whole heartily respect that ?. However as a bB programmer i understand the side we stand on all too well. I started writing code since 2009 for bB and only last year actually posted my first full game. Got to the stage i was like "frick it im going to post this DPC+ 32k game and if people don't like well so be it".

 

I just feel only those who frequently use bB really understand it has additional limitations of it's own. It's no easy walk in the park to make something fun with some substance. I think people look at the easy part of bB and that's only putting some boring sprites on the screen and moving them about. The real challenge/skill comes from making the game actually fun within bB's limitations.

I agree. The challenge/skill of making a game actually fun is universal. It doesn't mater what platform you are using.

 

People gave undeserving flack to BB for years. Now that has mostly shifted to flack for ARM games.

 

I am a supporter of BB. I love that it has given people a chance to make games, people who may never had the time or perseverance to learn assembly. Random Terrain, thank you for making games. ?

 

I've also helped out people with incorporating assembly in BB when I had the chance. When you pair an assembly person with a BB person you can have a very powerful and rewarding relationship. Years ago I helped Cybearg by creating a custom BB kernel for him for his game Heartbreak. We literally were replacing files in the BB source so that it would build using the custom kernel.

 

The benefit was that we were able to extend BB beyond what it normally could do, and it gave Cybearg the freedom to make the game he wanted to make. He did all the game logic and I did all the technicals. I created a routine that would use the driving control or a joystick with auto-detection so that you could hot-swap them while playing the game. The custom kernel allowed for a non-flickering multi-colored display that also ran collision detection while it was drawing, and put the collision results in a variable that was easy and ready for the BB game logic. That project was a lot of fun. Oh, and I also did some work for Cybearg on the BB DPC+ kernel to do a split score. That one is useful.

[+TwentySixHundred]

41 minutes ago, Omegamatrix said:

 Oh, and I also did some work for Cybearg on the BB DPC+ kernel to do a split score. That one is useful.

I remember that custom kernel you created for the split screen, just can't find that topic at this moment ?. IIRC Karl G has also made some custom score kernels for text ect. We really need these to be added to an updated bB build as they only help expand what is possible. Control of the kernel is obviously one very restricted area when programming with bB so any additions are welcomed. Thanks to yourself and everyone that contributes ?

 

Edit: you linked the post ?

Edited January 18, 2020 by TwentySixHundred

[+batari]

On 1/9/2020 at 12:19 PM, emmanuelf said:

Rev B of the LPC2103 is not affected by MAM.2 errata.

Athough Rev B has been around since 2011 or so, and most chips available since then are indeed Rev B, many older Harmony carts sold before that have a Rev A chip and I wouldn't want to fragment the Harmony user base.

[+batari]

On 1/16/2020 at 9:33 PM, Mr SQL said:

That's not to far off from their vision for the Atari Pong Challenge contest in 2012:

 

In the first phase of the contest, Atari received nearly 90 submissions from independent developers looking to remake Pong. After a comprehensive review, seven finalists were chosen for consideration by a celebrity judging panel made up of Nolan Bushnell, one of the original founders of Atari, Dave Castelnuovo of Bolt Creative (Pocket God), David Whatley of Critical Thought Games (geoDefense), and Mike Schramm of TUAW. In addition, the Atari community weighed in on the final ranking, with over 200,000 total votes logged for the various finalists. Ultimately, the winners announced today represent the top choices from Atari, the Atari community and the judging panel.
 

I think if you have also used Melody to previously host the SARA chip games selection or any legacy formats from the early 80's it's an ambiguous indicator.   

 

Does Aria support CBS RAM+ games too? How about SuperCharger games?

 

I'm also curious if you've ever reprogrammed an actual CBS RAM+ cart like you have with SARA carts - this has been discussed in theory, but the dumper example was defective and I have not heard of anyone actually reprogramming one. The Atari Flashback Portable had it's own version of CBS RAM+ that was a little different and interesting to figure out, but it would be nice to see someone reproduce a functioning example of the old CBS RAM+ tech like you have done with the SARA carts to have a phsycial model to compare and better understand.

 

The original idea of Melody was to produce a reprogrammable flash-based cart that cost about the same as traditional hardware. However, it turned out to be a bit more costly to produce, though it was also much more powerful than we anticipated.

 

It turns out, Aria is the solution to that original quandry. The Aria board has a significantly less powerful ARM chip, but is powerful enough for most legacy bankswitch schemes. It does support a CBS+ scheme, and SARA and of course the traditional bankswitch schemes. Though I have never tried to support Supercharger on it, it *might* but I am not sure. It did turn out to actually be competitive with traditional hardware for production cost.

 

So, Melody boards handle some higher end stuff now and Aria handles some lower-end stuff.

 

 

[Thomas Jentzsch]

What makes me wonder here on AtariAge is, that critical discussions are often perceived negative (some people even actively try to stall a discussion because they are afraid of that perceived negativity). We had the same problem with bB, where people thought that bB games got dismissed in general. Even after it had been made very clear multiple times by multiple people discussing that this is not the case. And the same is now happening with ARM games. And again, no one is against ARM games in general and this has been made very clear multiple times too. Still some people perceive the discussion like this.

 

I don't know if this is a cultural thing. I am from Germany and here we like(d?) to discuss the pros and cons open minded. And a discussion alone and exchanging arguments doesn't mean that one side is in favor in general and the other side is against in general. There is no simple black and white, reasonable discussions are about all kinds of shades of grey. And usually these shades are only regarding certain aspects of a topic and not the whole idea in general.

 

Maybe this is a cultural thing, I don't know. Or we have lost the ability to recognize nuances only lately (some general developments make me think so). Heck, if one would start a discussion about the pros and cons of boxed releases, I almost sure now that someone would come around and assume that the OP is against boxes in general.  

Edited January 18, 2020 by Thomas Jentzsch

[Thomas Jentzsch]

20 hours ago, Andrew Davie said:

Well, for "fairness" in awards... maybe a "weighted/handicap" system would work - whatever that may be. Votes for a 1K game would be skewed such that the 1K game could reasonably compete against (say) a 32K game or an ARM-assist game in terms of "best game". A carefully considered skewed/weighted voting system that takes into account graphics, playability, skill level of the programming, hardware assists used, environment (bB, ARM, bankswitch) memory requirements (both ROM and RAM) would then balance out the comparisons and result in a more nuanced "best game" award. The award would be based on an evaluation of all these factors, not just which does the most amazing things visually.

I doubt we would even remotely agree on the adequate weights here.  So the voters will have to weight all aspects individually by themselves.

[+Random Terrain]

In the year 2000, they will give awards for the most comments added to code.

 

youtu.be/k6IF3X-HeS0

 

[KevKelley]

2 hours ago, Thomas Jentzsch said:

I doubt we would even remotely agree on the adequate weights here.  So the voters will have to weight all aspects individually by themselves.

I don't know. I have played some simple games with squares and minimal graphics that neat out graphically impressive games. I would think if you are playing Atari 40 years later graphics aren't the most important thing ?

[+mksmith]

10 hours ago, Random Terrain said:

 

Thanks. Looks like Rikki & Vikki have sprites that are as detailed as you'd expect from a better console. Not blocky-looking like some other sprites I've seen on the Atari 7800. Problem is I couldn't move to the Atari 7800 until someone makes an IDE for 7800basic that is similar to Visual batari Basic.

 

I bet somebody could adapt this JavaScript sprite editor for the Commodore 64 so it will be able to make Atari 7800 sprites:

vintageisthenewold.com/new-online-sprite-editor-for-the-commodore-64/

Hey RT! I've have actually used that editor as a base for the one that currently exists in Atari Dev Studio. I'm still deciding whether to keep maintaining it as (at least in the case of Windows) paint.net can now output the correct images for 7800basic. As @RevEng noted I have used it for the majority of the final images in Arkanoid and it does a good job with the basics.

 

The only downside to using VS Code is it's cross-platform nature and whether some of the vbb tools can be included (a few requests!!) - unless they can be redesigned in JS most cannot be transferred.

 

I try and add things ongoing to Atari Dev Studio as I find a need. I would love full intellisense based on the source code but still trying to find some appropriate code to scan a document but the built-in one does a reasonable job.

 

Hopefully yourself and @TwentySixHundred might head over and make some 7800 games - it's really enjoyable and provides (for me at least) a little bit more freedom!

[+TwentySixHundred]

28 minutes ago, mksmith said:

Hopefully yourself and @TwentySixHundred might head over and make some 7800 games - it's really enjoyable and provides (for me at least) a little bit more freedom!

7800BASIC development has definitely been on my mind for a good 12 months or so now. Especially after you made the ADS extension for VSC as i used it to develop most of Bass Fishing Tournament. I feel the system has great potential and quite a powerful homebrew platform. I'm also really interested in porting over Bass Fishing Tournament and maybe Street Rod to harness its graphical capabilities.

 

Problem is i haven't looked into it deep enough when it comes to the syntax, keywords and functions ect. I'm in my safe/comfort zone with bB and ask the question to myself how much of my bB knowledge can transition to 7800BASIC (to be honest i am hoping alot). I feel completely in control when coding in bB and sky's the limit (besides all the restrictions lol).

 

I guess it's the fear of jumping into the unknown -- where to start -- what to do -- how much does it differ from what i know ect ect

[+Random Terrain]

13 minutes ago, TwentySixHundred said:

I guess it's the fear of jumping into the unknown -- where to start -- what to do -- how much does it differ from what i know ect ect

 

RevEng adapted the info on the bB page to make the Atari 7800 version, so parts are going to look very similar:

 

https://www.randomterrain.com/atari-2600-memories.html#7800basic

[+batari]

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.

 

 

 

 

 

 

 

 

[+mksmith]

6 hours ago, TwentySixHundred said:

7800BASIC development has definitely been on my mind for a good 12 months or so now. Especially after you made the ADS extension for VSC as i used it to develop most of Bass Fishing Tournament. I feel the system has great potential and quite a powerful homebrew platform. I'm also really interested in porting over Bass Fishing Tournament and maybe Street Rod to harness its graphical capabilities.

 

Problem is i haven't looked into it deep enough when it comes to the syntax, keywords and functions ect. I'm in my safe/comfort zone with bB and ask the question to myself how much of my bB knowledge can transition to 7800BASIC (to be honest i am hoping alot). I feel completely in control when coding in bB and sky's the limit (besides all the restrictions lol).

 

I guess it's the fear of jumping into the unknown -- where to start -- what to do -- how much does it differ from what i know ect ect

There isn't a whole lot of difference really - the basics are very much the same. I found the gfx initially to be the most interesting difference and fitting them into banks.  Plenty of help around to answer your questions too - believe me I asked quite a few ?

 

 

[azure]

7 hours ago, batari said:

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.

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.