Jump to content
IGNORED

*** RFC for new atari 2600 Multicart/Supercart ***


ALaMothe

Recommended Posts

Hey everyone, I have been toying around with developing an Atari 2600 enhancement cartridge, but I am not into the scene as much as others. Basically, I love the Atari 2600/800, used to write games for the A800 (but not the 2600, but played them of course), and now I develop gaming hardware, 3D engines, etc.. That said, I have been trying to make sense of the different products available for the 2600. So, after doing some research, seems the Harmony Cartridge does what I wanted to do more or less. I wanted a cartridge with a microSD card, that supported bank switching, RAM, and maybe had some support for features that Atari 2600 home brewers wanted as long as I could add them without shaking the trees too much.


I am thinking about everything from added sound support in the cart, to a color LCD screen to RGB LEDs to add special effects.


Anyway, I have been developing hardware for about 30 years, and the last 15, I have my own manufacturing in china, so if I did this, I would hope to sell 1000+ carts to break even, thus, I am just wondering about the market size. I found one cart that sold 204 units then the company seemed to go defunct, or the license expired?


In any event, if I did this, I would probably put it on kickstarter at some point to get the word out and use that to generate sales, so any "special" features in the cart, hopefully enough people would get it, so it became a standard ideally. But, primarily I would follow the rules for all the bank switching and RAM carts that have been reverse engineered to be compatible.


So, I can tell over the years that many of these "super carts" or "multicarts" have been developed, but its not clear to me if they are successful? Seems many never ship, or ship a little, or whatever. Maybe the problem is many developers have not done formal manufacturing and get overwhelmed?


Alas, I guess I am putting out an "RFC" of sorts with the simple question -- is there a need for another multi/supercart for the Atari 2600 (sorry 7800 people, I never got into that console, so I will stick with the 2600 for now :) -- and if there is a need, based on my specs above, is there anything else that is very common that home brewers are desperate to have? As well, as making something that normal 2600 fans can use to play games that range from 4-64K.


Finally, I don't want to go nuts on this and make a huge project that never gets done. I have shipped about 50-60 embedded systems over the last 15 years and the one lesson I have learned is keep it simple as possible to serve the purpose, you can always add stuff LATER!


Comments? (I will post this on Atari Museum, and Atari 2600 on Facebook as well, so I can get a good cross section of comments, not sure were "developers" hang out primarily).


Thanks --

Link to comment
Share on other sites

IMO, the cart would need to match all the functionality of the Harmony Encore and then provide something extra on top of that. Features I would like to see include:

* Support for online gameplay

* App Store with DRM so games could be sold cheaply over the internet without worrying about piracy

* Ability to develop games in C++

* Support file system access in the game so they can be much larger than what's out there now

* Bluetooth controllers

 

I know everything I just said is the exact opposite of keeping it simple, but simple is boring.

  • Like 1
Link to comment
Share on other sites

I like the idea of enhancing the sound. You would have the run the sound out of the cartridge. Because of the mods on many 2600's, you would need to support rf and av. You would need to mix the Atari sound with output of the cartridge sound. Maybe an rf demodulator in the cartridge. Then you can mix the audio, easily, and have AV outputs. The same problem as the atarivox has. Maybe a couple people would use the DRM. However for the most part this doesn't seem necessary. I don't think you could add C++ support within the cartridge. Being able to access larger amounts of ROM, could be handy, for games with a lot of media. How much would these enhanced carts cost? Having online capabilities would be pretty interesting. Being able to have multiplayer over the internet, or between 2 consoles side by side, would allow for some interesting games.

 

If you did make cartridges. I would like to see enhanced sound support, Enhanced ROM size, such as being able to use all the space on the SD card for a single game. Capability to connect to another console locally, or over the internet(wifi or bluetooth). Can this be done at a reasonable cost?

Edited by yllawwally
Link to comment
Share on other sites

Hmmm -- well, C/C++ support doesn't really have anything to do with a cart. That has to do with the architecture, the 6502 has C/C++ support right now, you can always get a compiler and generate 6502 machine code and then write games, just like there is Batari BASIC. It's just that the memory, math, and video kernels require you to code in ASM for a lot of things. But, I guess if someone wants to couple a 64K cart with bankswitching, extra RAM, and an API of functions and pre-written video kernels, and then put a C/C++ 6502 compiler on top, that could be done, but that's a different kind of project. I think the Batari guys would be better suited to do that since they already have a BASIC based solution, coupled with the Harmony they could get that working in a few months. But, I think this goes back to BASIC is a lot easier than C/C++, so a complete toolchain and hardware solution for C/C++ games would definitely allow better games, but I wonder if it would scare away as many programmers :)

 

But, the grand scheme of app stores and DRM and all that is applicable to something where you have development companies spending a lot of money and developing professional level games. Right now, as far as I can tell there are a handful of actual finished working homebrews and programming the 2600 is so complicated, there aren't a lot of people that want to take on the challenge since their is no ROI.

 

However, I like the idea allowing 2600 players to play with each other via a network and hardware, I have always thought that would be cool. But, you would need a meeting place, then a way to log your 2600 onto the network, then there is no way really to play a game "networked" other than to hack it such that one player sends his controller commands to the other player and then the video stream is shared. Playing two 2600's at the same time with the same game, and then remotely sending the joysticks to each wouldn't work without synchronization. In other words, the games would have be to designed as networked in the first place.

 

Hmmm - anyway, I kinda want to keep this to just a cartridge for the 2600 that adds memory, and some features. But, I want to target players not programmers (since there are like 50 of them :), but even still there aren't that many players either than actively care about multicarts -- I think I am coming to the conclusion that the harmony (great product by the way), has covered the market need more than enough. And sure, I could add features to it, but those features would have to target players, and I am not sure there is enough there to get a good amount of sales for the engineering effort...

 

Continues to think.....

Link to comment
Share on other sites

Ability to develop games in C++

We're already writing games in C that target the ARM chip within the Harmony - see Draconian*, Frantic*, Space Rocks, Stay Frosty 2 and Timmy!*. Due to the nature of the 2600, key portions must still be written in 6507 assembly. It's entirely possible somebody could develop a "batari C" that would hide the 6507 code like batari BASIC does.

 

The DPC coprocessor, developed by David Crane for Activision, was used for Pitfall 2. It added a bunch of slick features like Data Fetchers, 3 voice music, etc. and was used to create Pitfall 2. Sadly the console market crashed before they could use it for any other games. The Harmony lets us create custom bankswitch schemes such as DPC+, which improves upon DPC.

 

 

As a programmer, one of the slickest things about Harmony is it's actually two boards. It's a Melody coupled with an SD/USB daughterboard. This allows for the creation/sale of stand alone games which utilize the advanced features of the Harmony, such as Chetiry, Space Rocks and Stay Frosty 2.

 

 

* these games are not yet finished but you can still download versions of them, completed with source, from my blog.

Link to comment
Share on other sites

We're already writing games in C that target the ARM chip within the Harmony - see Draconian*, Frantic*, Space Rocks, Stay Frosty 2 and Timmy!*. Due to the nature of the 2600, key portions must still be written in 6507 assembly. It's entirely possible somebody could develop a "batari C" that would hide the 6507 code like batari BASIC does.

 

I thought the ARM only had a few cycles available for game code. Isn't it spending most of it's time feeding the 6507?

Link to comment
Share on other sites

I just played Space Rocks, very impressive -- of course its 32K, so would have been an expensive cart back in the day. But, imagine playing that instead of Atari Asteroids, the authors would have been rich! Very nice game -- I would have come up with a better name though :)

Link to comment
Share on other sites

 

I thought the ARM only had a few cycles available for game code. Isn't it spending most of it's time feeding the 6507?

Most of the time (during the display, ~75-80%) the ARM is busy with feeding the 6507. In the remaining ~20% the ARM can work on its own (interrupted once for vertical sync). At 70 MHz, this effectively results into an ARM running at ~14 Mhz (vs a 6507 running at ~200 kHz). So you can do a LOT more calculations.

Link to comment
Share on other sites

I thought the ARM only had a few cycles available for game code. Isn't it spending most of it's time feeding the 6507?

 

Most, but not all. During Vertical Blank and Overscan the ARM drops an $EA (the NOP instruction) on the bus to idle the 6507. It can then run ARM code at full speed. My basic frame (screen update) loop is:

  • Overscan - ARM idles 6507, runs all the game logic
  • Vertical Sync - ARM gives control back to 6507 to generate the required sync signal
  • Vertical Blank - ARM idles 6507, updates RAM with what to draw on this frame. We refer to the RAM as a Data Stream.
  • Kernel - ARM gives control back to 6507 to run the Kernel (name for the section of 6507 code that updates TIA scanline by scanline in order to generate the visible display). The 6507 doesn't have direct access to the RAM, but there's just enough time for the ARM to read RAM values and hand them over to the 6507. We refer to this ARM assist as a Data Fetcher.
  • loop back to Overscan

I just played Space Rocks, very impressive -- of course its 32K, so would have been an expensive cart back in the day. But, imagine playing that instead of Atari Asteroids, the authors would have been rich! Very nice game -- I would have come up with a better name though :)

Thanks! It couldn't have been done back in the day as the game logic is running on the ARM chip. It's possible they could have used other CPUs in the cartridge, like what was going on with the Graduate. For DPC+ we have TIA updates down to 5 cycles, the Graduate used bus stuffing to get that down to 3. We're looking to do something with bus stuffing in the near future.

 

I asked for name suggestions and eventually went with Space Rocks after seeing Keeping an Eye on Space Rocks on NASA's site. I also liked the double entendre of "outerspace is awesome" as I'm a programmer in the space industry here in Houston. The software I work on was used to design MESSENGER.

 

As for the 1000s of copies, that's probably a factor in why batari designed the Harmony in two parts - the expensive part could be used for both the low volume Harmony and high volume Melody.

 

Are you aware that the Classic Game Fest will be held at the end of July in Austin? The first year was so-so, the second was impressive. This will be their third year.

Edited by SpiceWare
Link to comment
Share on other sites

Hmmm -- well, C/C++ support doesn't really have anything to do with a cart. That has to do with the architecture, the 6502 has C/C++ support right now, you can always get a compiler and generate 6502 machine code and then write games, just like there is Batari BASIC. It's just that the memory, math, and video kernels require you to code in ASM for a lot of things. But, I guess if someone wants to couple a 64K cart with bankswitching, extra RAM, and an API of functions and pre-written video kernels, and then put a C/C++ 6502 compiler on top, that could be done, but that's a different kind of project. I think the Batari guys would be better suited to do that since they already have a BASIC based solution, coupled with the Harmony they could get that working in a few months. But, I think this goes back to BASIC is a lot easier than C/C++, so a complete toolchain and hardware solution for C/C++ games would definitely allow better games, but I wonder if it would scare away as many programmers :)

I was thinking that ALL the code would be run on the cart. There would be an API with the bare essentials for interfacing with the 2600. That API could be emulated in a library so game development could be completely done in a modern IDE such as Visual Studio. There could also be a library of prebuilt engines similar to what batari basic offers. The benefit of this would be the ability to produce the best looking games with much less effort than writing in 6507 assembly.

 

But, the grand scheme of app stores and DRM and all that is applicable to something where you have development companies spending a lot of money and developing professional level games. Right now, as far as I can tell there are a handful of actual finished working homebrews and programming the 2600 is so complicated, there aren't a lot of people that want to take on the challenge since their is no ROI.

If the cart supports DRM you could potentially release games that can only be played on real hardware. It might encourage more homebrews to be developed if there is a way to release the game without the hassle and risk of producing a quantity of carts. There's also the benefit to players who want to purchase homebrews to play on real hardware but can't afford to pay $50 a cart. In theory an emulator could be run on the cart to allow for DRM of 6507 coded games too.

 

However, I like the idea allowing 2600 players to play with each other via a network and hardware, I have always thought that would be cool. But, you would need a meeting place, then a way to log your 2600 onto the network, then there is no way really to play a game "networked" other than to hack it such that one player sends his controller commands to the other player and then the video stream is shared. Playing two 2600's at the same time with the same game, and then remotely sending the joysticks to each wouldn't work without synchronization. In other words, the games would have be to designed as networked in the first place.

Agreed. I figured this feature would be limited to new games and hacks. Anything not originally designed for online multiplayer would probably suck at it anyway.

 

Hmmm - anyway, I kinda want to keep this to just a cartridge for the 2600 that adds memory, and some features. But, I want to target players not programmers (since there are like 50 of them :), but even still there aren't that many players either than actively care about multicarts -- I think I am coming to the conclusion that the harmony (great product by the way), has covered the market need more than enough. And sure, I could add features to it, but those features would have to target players, and I am not sure there is enough there to get a good amount of sales for the engineering effort...

 

Continues to think.....

The harmony is a great product and the support for it on the forums is top notch.

 

What if the cart could also be built as a stand alone system? Then the market for it wouldn't be limited to people that still have a working 2600. If the cart has a decent FPGA on it, both operating modes should be possible with a single hardware design.

 

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