The ultimate atari cartridge: Need input!

[treep78]

So I've been a bit frustrated as of late as to how difficult it is to make an atari 2600 cart with bank switching, mostly because it requires specialized programming hardware. Being so frustrated I decided to do what most of us do when we reach an impasse: try to find a new way of doing something.

 

Now I'm fairly familiar with game programming and I have a bit of experience with programming for the MSP430 micro controller and I though, "If other systems could use in cart chips, why not the 2600?". So the idea is this, instead of programming games for the 6507, simply run the games entirely on the MSP430, and only use the 2600 to draw to the screen and play sound.

 

Now I know building the game engine for the MSP430 would be no problem, but after that it comes down to some unknowns.

 

1. While some games might fit on the chip, others could go on a small flash chip.

 

2. In theory all that would need to be accessed by the 2600 is a short line of code which would contain only the horizontal line the system needs to draw at any given time, and whatever sound it's playing. Though I don't know if that would have to be in assembly or binary.

 

3. I am unsure as of yet if I could access the data on the MSP directly through the pins or if I would have to have a ram module that the chip would constantly be writing to for the system to access.

 

4. The biggest hurdle however would be telling the MSP what the controllers are doing, I assume that the 2600 must communicate with the cartridge somehow to perform bank switching, I just don't know how that is done.

 

Finally I need your thoughts, does the community want something like this? Is it stupid? Impossible? If it isn't it would enable Atari games to be built which look nearly as good as NES games and wouldn't that be awesome! If anyone wants to help with the project it would be greatly appreciated especially on the 6507 side of things. Of course the whole project would be open source for anyone who wants to build an affordable 2600 cart requiring no special tools capable of running high quality games.

 

So what to you say we make this happen!

[Mr SQL]

treep78,
what you've described has already been done with the ARM chip and there are some awesome games and demos out for it as well as the DPC+ extensions for bB

 

It might be more interesting to see an approach utilising another display chip in addition to the more powerful CPU; a cart like this is already available for Nintendo with video out on the cart to support the enhanced graphics modes.

 

If NES like functionality is what you're after, there's also a free Programming Framework available that can push the VCS to run games with large virtual worlds and tile mapped characters just like the NES; check out the review of KCMM at 12:05 in this Video by Metal Jesus and the Immortal John Hancock:

http://www.youtube.com/watch?v=Zsl65fKYsvk

Games created with the Framework can be written rapidly in Abstract Assembly, an alternative to using bAtari BASIC which is also supported.

 

The bankswitched media, can be any of these:

Harmony/Melody cart, Tape or CD

[+SpiceWare]

This doesn't seem like a topic that belongs in the batari Basic forum.

 

I though, "If other systems could use in cart chips, why not the 2600?".

Disregarding bankswitching hardware and extra RAM, this was done back in the day. David Crane created the DPC, a coprocessor that was used for Pitfall II. Sadly the market collapsed before they could use it for other games - it would have been interesting to see what else they could do with it as there's features in DPC that were not used in Pitfall II.

 

Back in 2010 cd-w did a DPC Music demo while I did a DPC Sprite Demo.

 

2. In theory all that would need to be accessed by the 2600 is a short line of code which would contain only the horizontal line the system needs to draw at any given time, and whatever sound it's playing. Though I don't know if that would have to be in assembly or binary.

Anything plugged into the cartridge port does not have access to the hardware in the Atari, so no matter what you're going to be writing 6507 code that reads data from your MSP and writes it to the video and sound registers in the Atari. Likewise, the 6507 code will read in the state of the controllers, collision registers, etc. and write that information to the MSP.

 

4. The biggest hurdle however would be telling the MSP what the controllers are doing, I assume that the 2600 must communicate with the cartridge somehow to perform bank switching, I just don't know how that is done.

This is done by setting aside a range of addresses to be used as "registers" and "hotspots" by the MSP. If the 6507 writes data to a register it's used by the MSP. Likewise if the 6507 reads data from a register, it's data provided by the MSP. There's no read-write line in the cartridge port though, so registers are either read-only or write-only. A hotspot is like a register, but just accessing the address will trigger an event, no data is passed between the 6507 and MSP.

 

Finally I need your thoughts, does the community want something like this? Is it stupid? Impossible? If it isn't it would enable Atari games to be built which look nearly as good as NES games and wouldn't that be awesome! If anyone wants to help with the project it would be greatly appreciated especially on the 6507 side of things. Of course the whole project would be open source for anyone who wants to build an affordable 2600 cart requiring no special tools capable of running high quality games.

It's been done with the ARM chip. We developed DPC+ back in 2010. It's an updated version of DPC, utilizing an ARM chip as the coprocessor. You can also offload game logic to the ARM chip, but not when the screen is being generated as the ARM's too busy at that time acting as a coprocessor. DPC+ can run on the Harmony Cartridge, as well as the Melody board for stand alone games. The 2600 emulator Stella has also been updated to support DPC+.

 

For DPC+ the registers are defined as $F000=$F07F with the read-only registers existing from $F000-$F027 and the write-only registers from $F028-$F07F. Additionally the addresses $FFF6-$FFFB are used as hotspots to control bankswitching, there are six 4K banks that the 6507 can select from.

 

Games I've finished for DPC+ include Space Rocks and Stay Frosty 2.

 

DPC+ games under development include Draconian and Frantic.

 

The source code for the above games, with the exception of Stay Frosty 2, can be found in my blog. Use the Categories in the right column to make it easier to find. Stay Frosty 2 source will be made available at a later date, probably a year or so after it's been released.

[+SpiceWare]

I forgot to add - don't let the existence of DPC+ discourage you from creating something new. I didn't let the existing of Asteroids discourage me

[+Gemintronic]

I do wonder what these cartridge making topics have to do with batari BASIC.

 

Are you planning on modifying the batari BASIC kernel to support these new boards of yours treep78?

[treep78]

That's for the great replies! That's a lot of good info, though I get the feeling that I've done a poor job articulating what I want to accomplish so I'll try to address that better.

 

1. Yes I do know about the harmony and melody carts, but the problem I have with them that I'm trying to address is price. Those carts are very expensive and can't be hand assembled. All the components I've chided are in a DIP package and the only programming tool required is an mps430 launchpad ($10 with two chips).

 

2. As far as performance is concerned DCP+ and the supercharger are baloney efforts but still rely too heavily on the 6507. I plan to us it only to pass the drawing info and sound to the TIA. the actual processing would all be done on the MSP and games would be written in C. Then the MSP would compile a very small about of data and comply it to the RAM chip for the 6502 to pass on. This would allow for MUCH better graphics and a higher screen resolution as the system is now using fewer scan lines to execute code.

 

3. I could be wrong, but all the info I found says that the Cartridge has access to the address and data lines and if any info about the controllers passes through there then the MSP could capture that info. Otherwise, uh..... Put the controller ports on the cartridge?

 

4. As for running video out of the cartridge itself it feels like cheating. I mean at that point I might as well just build an entire console that slots into the system and put cartridges into that and while that would be a lot easier it would no longer use any of the 2600 hardware aside from the voltage converter to produce 5v. If you guys want that I could do that instead.

 

If I missed anything I'll try to get back to it. Again thank you for all of the input.

[treep78]

I do wonder what these cartridge making topics have to do with batari BASIC.

 

Are you planning on modifying the batari BASIC kernel to support these new boards of yours treep78?

I didn't know where else to put it.

[+wongojack]

I'm from another area in technology. While I have a very simple working knowledge of assembly programming, I just don't have a desire to get good at it. However, I really appreciate the desire to solve unique problems in unique ways, so I want to encourage you here.

 

However, as a consumer of classic gaming tech, I'm not really interested in seeing how we can add things on to the 2600 to make it better. I realize they did something similar with Pitfall II, and Space Rocks blows your mind it is so good. I guess there is a certain degree of authenticity to it, but if you are going to make a game that is beyond the spec of the system then why not just make it for another system? If we've really seen everything that the 2600 can do then why not make some 7800 games? That system could use them.

[Mr SQL]

That's for the great replies! That's a lot of good info, though I get the feeling that I've done a poor job articulating what I want to accomplish so I'll try to address that better.

 

1. Yes I do know about the harmony and melody carts, but the problem I have with them that I'm trying to address is price. Those carts are very expensive and can't be hand assembled. All the components I've chided are in a DIP package and the only programming tool required is an mps430 launchpad ($10 with two chips).

 

2. As far as performance is concerned DCP+ and the supercharger are baloney efforts but still rely too heavily on the 6507. I plan to us it only to pass the drawing info and sound to the TIA. the actual processing would all be done on the MSP and games would be written in C. Then the MSP would compile a very small about of data and comply it to the RAM chip for the 6502 to pass on. This would allow for MUCH better graphics and a higher screen resolution as the system is now using fewer scan lines to execute code.

 

3. I could be wrong, but all the info I found says that the Cartridge has access to the address and data lines and if any info about the controllers passes through there then the MSP could capture that info. Otherwise, uh..... Put the controller ports on the cartridge?

 

4. As for running video out of the cartridge itself it feels like cheating. I mean at that point I might as well just build an entire console that slots into the system and put cartridges into that and while that would be a lot easier it would no longer use any of the 2600 hardware aside from the voltage converter to produce 5v. If you guys want that I could do that instead.

 

If I missed anything I'll try to get back to it. Again thank you for all of the input.

treep78,

OK I'm curious why you feel the supercharger is a baloney effort? It's just a retro flashcart from 1982 for running 6k games - no special coprocessor though it does have an awesome 2K OS.

 

I don't think video out cheating, it's not too different than using a 32-bit CPU to run C code and seems to compliment it; It would be intersting to see at least!

 

otoh wongojack has an excellent point that it's no longer the same classic system once you add these features; I prefer to push the limits of the retro technology but it's fascinating to see what can be done.

 

I hope somone can post a pic/link for the Nintendo cart with the video out; it's fielded complaints but it seems a pretty cool feature to be able to have a video mod right on the cart for hybrid modern gaming while leaving the classic video signal intact off the motherboard.

[+Gemintronic]

I didn't know where else to put it.

 

Probably in the general Atari 2600 section. Your audience in this section hardly knows how to program in BASIC and would not have the skills needed to properly address your question.

http://atariage.com/forums/forum/16-atari-2600/

 

There's a very charitable selection of assembly coders willing to help that check out this sub-section so that's why you've gotten any informed responses.

[Cybearg]

Maybe I'm alone in this, but I think treep's proposal of shifting processing to a cheap on-cart processor would be awesome! I'd LOVE to have NES-equivalent capabilities on a 2600 cartridge!

 

As for the question of "what's the point?", the point is that everyone who has a 2600 (a lot of people) can then play those advanced games. It only expands what the system is capable of. If there was a cartridge that could give the 2600 N64-style capabilities while still running the standard hardware, wouldn't that be pretty cool and worth doing?

 

Expanding what can be done on a 2600 cart only expands the potential of the 2600. There will always be geniuses who push the 2600's capabilities with cutting-edge Assembly wizardry, but not everyone can do that. Would you rather have more great games, some that push native functionality and some that rely on newer assist hardware, or fewer games overall, potentially with more schlock as people who are limited by batariBasic push out only limited shovelware games because it's the best they can technically manage?

 

Yes, the 7800 could use some love, but the 7800 doesn't have near the audience of the 2600, nor will it ever. Making more advanced things possible allows more variety for 2600 players and 2600 homebrewers while still leaving the 7800 and pure 2600 audiences in-tact. It doesn't hurt anyone to try to advance things.

Edited September 10, 2014 by Cybearg

[+Gemintronic]

Right. But, he's not targeting batari BASIC in any way, shape or form.

[Cybearg]

Right. But, he's not targeting batari BASIC in any way, shape or form.

No, but programming games in C on a more modern processor would likely be more accessible to batariBASIC homebrewers than making whole race-the-beam kernels from scratch in Assembly. So it's still very relevant to those of us who aren't inclined toward Assembly programming.

Edited September 10, 2014 by Cybearg

[+Gemintronic]

sure. right on.

[+SpiceWare]

1. Yes I do know about the harmony and melody carts, but the problem I have with them that I'm trying to address is price. Those carts are very expensive and can't be hand assembled. All the components I've chided are in a DIP package and the only programming tool required is an mps430 launchpad ($10 with two chips).

I don't know what Melody costs, but at one time you could select the Melody board as an option for most any game in the AtariAge Store and it only added $5 to the price of a game.

 

2. As far as performance is concerned DCP+ and the supercharger are baloney efforts but still rely too heavily on the 6507. I plan to us it only to pass the drawing info and sound to the TIA. the actual processing would all be done on the MSP and games would be written in C. Then the MSP would compile a very small about of data and comply it to the RAM chip for the 6502 to pass on. This would allow for MUCH better graphics and a higher screen resolution as the system is now using fewer scan lines to execute code.

What's a baloney effort? I have no idea what you mean by that.

 

There's no way to get away from requiring the 6507 to do things. Most of my game logic is written in C, but the part that draws the screen must be in 6507 code. Also note, the 6507 must trigger a sync signal when Overscan is done so the TV knows it's time for Vertical Blank. Basically this is what my games are doing:

1. 6507 - trigger the sync signal, written in assembly
2. ARM - game logic, written in C
3. 6507 - preps for the kernel (positions the sprites, preps the coprocessor, etc), written in assembly
4. 6507 - runs kernel (draws screen), written in assembly. Utilizes ARM as a coprocessor to speed things up
5. ARM - game logic, written in C
6. 6507 - jump back to 1

 

3. I could be wrong, but all the info I found says that the Cartridge has access to the address and data lines and if any info about the controllers passes through there then the MSP could capture that info. Otherwise, uh..... Put the controller ports on the cartridge?

The cartridge port reads the address lines so the cartridge hardware knows what address the CPU is requesting data for. It writes to the data lines to return the data for the specified address. The Atari isn't set up to have the address bus driven by the cartridge port..

 

Also, as mentioned before, there is not a read-write line - so even if you could drive the address lines from the cartridge port you're going to have a difficult time with TIA. TIA registers are READ-ONLY and WRITE-ONLY and they share the same address space. If you write to address $0008 you're going to set the color of the playfield, however if you read from address $0008 you're going to get back information about paddle0. Without the read-write line, the TIA chip won't know what you're trying to do if the cartridge accessed $0008.

Edited September 10, 2014 by SpiceWare

[treep78]

Ya I agree that working with the 7800 would be cool, but I want to make something a lot of people could enjoy and they still make 2600s (I think the new flashback is out soon) where as the 7800 had a relatively short lifespan. The same problem exists with building a peripheral, or even a separate system, the carts would cast (a little) more or it would have to be its own thing. It also doesn't get any more classic than the 2600.

 

Also, I'm now wondering if there would be a way for an admin to move this topic to the general 2600 section?

[treep78]

I did not mean to type baloney I was trying to say valiant. Darn autocorrect.

[treep78]

I don't know what Melody costs, but at one time you could select the Melody board as an option for most any game in the AtariAge Store and it only added $5 to the price of a game.

 

 

What's a baloney effort? I have no idea what you mean by that.

 

There's no way to get away from requiring the 6507 to do things. Most of my game logic is written in C, but the part that draws the screen must be in 6507 code. Also note, the 6507 must trigger a sync signal when Overscan is done so the TV knows it's time for Vertical Blank. Basically this is what my games are doing:

• 6507 - trigger the sync signal, written in assembly
• ARM - game logic, written in C
• 6507 - preps for the kernel (positions the sprites, preps the coprocessor, etc), written in assembly
• 6507 - runs kernel (draws screen), written in assembly. Utilizes ARM as a coprocessor to speed things up
• ARM - game logic, written in C
• 6507 - jump back to 1

 

The cartridge port reads the address lines so the cartridge hardware knows what address the CPU is requesting data for. It writes to the data lines to return the data for the specified address. The Atari isn't set up to have the address bus driven by the cartridge port..

 

Also, as mentioned before, there is not a read-write line - so even if you could drive the address lines from the cartridge port you're going to have a difficult time with TIA. TIA registers are READ-ONLY and WRITE-ONLY and they share the same address space. If you write to address $0008 you're going to set the color of the playfield, however if you read from address $0008 you're going to get back information about paddle0. Without the read-write line, the TIA chip won't know what you're trying to do if the cartridge accessed $0008.

Sure melody might have only added $5 but that's $5 to a $25 cart. I'm talking about something that could be build entirely for around $5 and programmed by anyone using only the $10 MSP430 launchpad programmer.

 

And your method for running the games is correct if I can't get the controllers to communicate directly with the MSP, but that would drastically cut down on how much CPU time I have to get the 6507 to write to the TIA thus reducing resolution.

[+SpiceWare]

Sure melody might have only added $5 but that's $5 to a $25 cart. I'm talking about something that could be build entirely for around $5 and programmed by anyone using only the $10 MSP430 launchpad programmer.

Ah - I misread that as $10 in parts going into the cartridge.

 

And your method for running the games is correct if I can't get the controllers to communicate directly with the MSP, but that would drastically cut down on how much CPU time I have to get the 6507 to write to the TIA thus reducing resolution.

Have you written a 2600 program before? Based on this, and some of your other comments, I get the feeling you're not familiar with the details. Specifically reading the joystick is not going to have any affect on the time you have for updating TIA to draw the display - they're done at different times.

 

Referencing this timing diagram from my Collect blog entries:

 

 

A typical program flow would be:

• Generation Vertical Sync (3 scanlines)
• Vertical Blank - Game logic, including setting the X positions of the 5 objects (37 scanlines)
• Kernel - generate the display the player sees (192 scanlines)
• Overscan - Game logic (30 scanlines)
• back to 1

Reading of the joysticks will occur during either #2 or #4, while updating TIA to display the game only occurs during #3. When you offload to your hardware, be it ARM or other, you'll just have a brief stub of 6507 code that preps for the handoff to the other CPU. In the ARM routines it looks like this:

CallArm:
        ldx #<ARMsub
        stx DF0LOW
        ldx #>ARMsub
        stx DF0HI
        ldx #1              ; 1 = OverScan()
        stx DF0WRITE
        ldx SWCHA
        stx DF0WRITE
        ldx SWCHB
        stx DF0WRITE
        ldx INPT4
        stx DF0WRITE        
        ldx INPT5
        stx DF0WRITE        
        ldx #$ff
        stx CALLFUNCTION

 

DF0LOW, DF0HI, DF0WRITE and CALLFUNCTION are some of the "registers" for DPC+.

 

The stores to DF0LOW and DF0HIGH are setting a pointer to DPC+ Display Data (which is RAM) for where the following stores to DF0WRITE will be done.

 

• The #1 used for the first DF0WRITE to tell the ARM code which function to run.
• SWCHA contains the current reading of both joysticks
• SWCHB contains the state of the console switches
• INPT4 is the left player's firebutton
• INPT5 is the right player's firebutton
• Storing $FF to CALLFUNCTION triggers the ARM code.

[+batari]

The MSP430 is too slow for this task. I've experimented with other chips (DIP too) and I don't think you'll get this to work with a chip slower than 50MHz or with less than a 32 bit bus.

That's not to say there isn't another speedy DIP chip out there (or that there won't be a fast MSP430 someday) but the 25 MHz I see reported with current MSP430 chips just isn't going to cut it.

 

Also I see that the MSP only has 10 I/O pins. You need at least 21.

[treep78]

MSPs range from 8 to 56 I/Os, the one I'm working with has 18. It also has more than enough speed (about 10X) the 6507. What you're talking about is generating a 640X480 video signal as was demonstrated by Rossum with a cortex M0. But that isn't how the 2600 works. Even if that was what I was trying to do the MSP430 is perfectly capable of generating composite video and has been done before. Racing the beam can be done with a LOT les than 50MHz if you aren't going for full tv resolution. More over an MSP430 console could easily be built using a similar technique used for the 2600, store the content (flash eeprom) and use 1 MSP for all the processing and another to generate the audio and video.

[+wongojack]

Would you rather have more great games, some that push native functionality and some that rely on newer assist hardware, or fewer games overall, potentially with more schlock as people who are limited by batariBasic push out only limited shovelware games because it's the best they can technically manage?

 

It is true that there is more interest in the 2600 than other machines, but that interest is still really limited to hobbyists, and the homebrew scene limits it even further. I'm sure there are more people collecting for the 2600 than the 7800, but its not like anyone gets into homebrews for the $$. Besides, that was just an example. How about making NES style games for the NES?

 

Regarding "Would you rather have more great games or more schlock?" I dunno, at some point if the games stop looking like 2600 games then I won't really be interested. Even in the case of Space Rocks - it is awesome, but there are sooo many ways to play Asteroids that as a consumer, I'm not really THAT interested. I mean, I haven't even played all the highly rated games from the original library.

 

Again - I love solving problems, so please use your creative spirit to push this endeavor forward as only the power of discovery can. I know that feeling and it really can be motivating. However, I'll probably just play games that look like NES games on the NES (or just on the PC).

[+batari]

MSPs range from 8 to 56 I/Os, the one I'm working with has 18. It also has more than enough speed (about 10X) the 6507. What you're talking about is generating a 640X480 video signal as was demonstrated by Rossum with a cortex M0. But that isn't how the 2600 works. Even if that was what I was trying to do the MSP430 is perfectly capable of generating composite video and has been done before. Racing the beam can be done with a LOT les than 50MHz if you aren't going for full tv resolution. More over an MSP430 console could easily be built using a similar technique used for the 2600, store the content (flash eeprom) and use 1 MSP for all the processing and another to generate the audio and video.

 

You can generate video with an MSP430 and make a standalone console, sure, but weren't we talking about an Atari cartridge? No, a 640x480 video signal that's not what I am talking about. I am the guy behind Melody and Harmony and I've done all this before.

 

As pointed out before you can't just take over the bus on a 2600 as you are proposing. You CAN'T control the TIA directly using an MSP430 on a cartridge. You MUST run 6507 code. Therefore your MSP430 MUST poll the address bus and MUST deliver data to the data bus to run this code. 25 MHz is just too slow for this, and you need 21 I/Os (A0-A12, D0-D7).

[treep78]

Ahh yes, the elephant in the room: why not make games for another system. Well the reason I got interested in making a 2600 games is not really relevant to this project, but the thing it has over a NES is that nes carts are VERY complex including a bunch of chips one of which being the infamous lockout chip. Now of course the sega master system and genesis/megadrive don't have that problem since their carts are just EPROMs and a pair of capacitors, but nobody has a master system and making a genesis game takes more time than I have (I'm a full time student and work 20 hours a week). Now of course I would love to make a game system from scratch but the problem there is getting them into the hands of other people (even if they are cheap) and getting other people to make games for it as it's not exactly profitable to make a game for a non modern console, especially one that requires cartridges (even though carts are awesome!). The only instance I can name is Pier Solar which was also released on modern systems.

 

Oh, and if you want to know why I wanted to make a 2600 game to begin with I'll tell you, though it may be offensive to people without a sense of humor. I wanted to perpetrate a hoax that Nintendo had stolen the idea for The Legend of Zelda by making a bunch of carts of a 2600 port of the game and sending them off to various people to get the buzz going. The idea was to have three 'levels' to the game, the first being just a copy of LoZ adapted for the 2600. The second level was that the game would contain cryptic clues that the team who made the game had all died in a car crash, but not before they sent the game off to nintendo trying to get them to publish it and now they haunted the game. The third level would only be solvable once you had figured out the conspiracy theory and would reveal the whole thing to of course be a hoax. I would have used old cart shells and hand made circuit boards to sell the idea of the game being a prototype. While I was working on the game I decided to look into how to make the carts, but it turned out that since I needed bank switching to store even a severely cut down version of LoZ and to produce the ~10 carts I wanted would have been really expensive so I've sort of abandon the hoax idea in favor of this project.

 

Which reminds me, if anyone wants the character sprites I made let me know. They're pretty good, they don't use any advanced kernels (though they do use the player1color option) they're all 8X~12 and include 2 frame animations of walking NSEW. The trick of course is that they only really look good on a black background (the game was going to be called Shadow Lands).

[treep78]

 

You can generate video with an MSP430 and make a standalone console, sure, but weren't we talking about an Atari cartridge? No, a 640x480 video signal that's not what I am talking about. I am the guy behind Melody and Harmony and I've done all this before.

 

As pointed out before you can't just take over the bus on a 2600 as you are proposing. You CAN'T control the TIA directly using an MSP430 on a cartridge. You MUST run 6507 code. Therefore your MSP430 MUST poll the address bus and MUST deliver data to the data bus to run this code. 25 MHz is just too slow for this, and you need 21 I/Os (A0-A12, D0-D7).

You clearly missed the part where the MSP430 was writing to a 32 pin parallel RAM chip, not the 6507 directly. That was the whole point, the 6507 was going to only have to read and process a VERY small amount of code and flicker was going to be used to get more than 4 colors (red blue green and black) per line.