treep78

So I know it's been a while and it's likely no one cares about this project anymore, but I've had a few new thoughts and am seeing if I can get some feedback as to whether or not my new idea is feasible or if I'll just be wasting my time trying to implement it. I've been going over some of this project's issues as of late and I feel like I might have come up with a solution for at least some of them. The first issue I want to address is the method for drawing the screen. The best example I've seen of a 'high' resolution image on the VCS is the title screen kernel which managed an image with a width of 48 pixels. I was stumped as to how this was accomplished until I realized that the score is 48 pixels wide, I'm no good at deciphering assembly language but it seems that the image is being drawn by moving the score to the middle of the screen, breaking the image into six parts, and giving the 'numbers' a greater vertical height. Looking at the .bin file with a hex editor I have been able to locate the locations where graphics for the numbers are stored and change them straight from the .bin. Now there still remains the issue of the time it takes to write to an EEPROM and I believe I may have come up with the solution. Don't write to the EEPROM. Instead you could have a microcontroller read the address pins and when the Atari addresses the pixels you need to change you simply use 8 pins on the microcontroller as substitute data pins and feed in the images that way, thus negating the need to synchronize with the Atari or write new data to the EEPROM. I know I've probably rambled a bit or possibly not been as clear as I might have been so feel free to ask questions or to explain why this doesn't work, in the mean time I await your comments eagerly.

Ya, I think I got confused there for a sec. What I meant to say is that I'm not using them for gameplay, they're being sacrificed to produce the games horizontal pixels. If I remember correctly I get 1 color for player and missile 0, same for 1, then a background color and a play field color. That's how I came up with 4 colors per line. I'm hoping to be able to generate additional colors by having those four colors be red, blue, green, and black and changing their positions each time the screen is drawn to create additional colors. Not sure how yet, but I'm working on it.

Of course since my model doesn't use players, balls, or paddles that isn't an issue.

SpiceWare, thanks for the links and tutorials, looking through those now. Mr. SQL, any chance you could fill me in on how the 2600 addresses on cart ram? The ram chip I'm using is 32k and the 2600 is only addressing 4K of it for the ROM and it would be cool if I could get it to address more. I don't quite know how bank switching works, but maybe I could use that to let the 2600 address enough data to put an entire frame buffer on the RAM chip.

So as some may know I'm working on a coprocessor cart for the 2600 which will essentially reduce the system's job to generating graphics and sound. As such I'm now trying to decide if it would be possible to build a frame buffer using the majority of the 4KB the system can address as it might be difficult to always know which part of the screen the 2600 is drawing. Essentially, the idea is that the coprocessor will write an atari rom to a ram chip which the 2600 will read. The chip will contain a bare minimum kernel, the sound the system should currently be playing, and the line buffer which gets drawn with the TIA. The issue is that I'm not sure I can get the two chips in sync enough to know which line the system is drawing at any one time. Therefor I want to know if it would be possible to write at least a partial frame buffer so that the ram could hold several line buffers at once and the 2600 could just request the one it needs. For example, the code contains a variable F which is equal to the current line being drawn, 1-10 (holding a 1/16 of the frame in a buffer), and depending on that it could draw one of the line buffers in the 'ROM'. I'm assuming for the moment that since the 2600 can only draw four colors per line that each of the 160 pixels is represented by a 2bit number, 0-3, plus the four color pallet meaning that the frame buffer would be 44bytes (which sounds low). Of course I could be completely wrong. I'm kind of a newbie on the 2600 so some input from the experts out there would her really appreciated. Thanks in advance!

Ahh, bread boarding.

Well here's a bit of an update. I've received the parts to build the prototype with. In other news: AHHHHHHHHHHHH!!!!!!!! So I'm a bit out of my depth here, I know I have to use the SPI pins on the MSP to send data through the shift registers so they can be written to the parallel sram. What I don't know is how to do this. Of course I should have known this would happen; I'm a game designer which means I'm only half a programmer and, as much as I want to be, not much of hardware guy. If there are any hardware people out there maybe they can give me a hand here. Thanks in advance.

So one of the things I need to build this thing is an actual atari so I ordered a Flashback 2+ thinking I'd just do the cart mod. Well one epic fail later and my Flashback is broken, so I did what I should have done in the first place and ordered an actual 2600 on ebay. It wasn't a total loss, however, as I ended up getting a system without controllers or a power supply.

I haven't been able to open that link you put, it just loads the page indefinitely, not sure if that's just me though. In general though, if your having trouble getting any code working there are two basic approaches that I like. 1. Guess and check by reverting the code to something functional (if it was ever at that stage) and adding things back in one at a time until it breaks. 2. Find code similar to what you're trying to accomplish that you know works (like another mini kernel) and change it bit by bit to match yours, sometimes you get something incredibly basic wrong and don't even notice until you go through this process. If I can ever open the page with your code I'll try to go through it and see if I can offer some more helpful suggestions.

So because I'm an idiot and forgot that you need a hex inverter I started looking into it. In the Pixels Past schematic it shows a 14 pin hex inverter, but it only seems to be inverting a single signal so I'm thinking I can swap out the 14 pin inverter with a six pin inverter which only handles a single signal therefore saving about $.50 on the BoM (every penny counts). Does that make sense?

Ordered parts last night. Though I realized that I forgot to order a hex inverter. I don't suppose anyone knows how to let the atari read data without one?

No, sadly it's a 2-3 chip solution unless there is a way for the 6507 to access the MSP's ram directly, and even then you'd need a chip with more that 512B for a game ruling out the PDIP MSPs (though MSP430s go up to 66KB ram with 512KB flash). The DIP MSPs only go up to 16kB flash so games larger than that would require a different chip package, or external flash EEPROM (8 pin package >$1). But hey, it would let you have games as big as you wanted without worrying about bankswitching! Here are the chips I'm looking at: MCU: http://www.digikey.com/product-detail/en/MSP430G2553IN20/296-28429-5-ND/2638885 RAM: http://www.digikey.com/product-detail/en/CY7C199CN-15PXC/428-2158-5-ND/1206029 Flash: The choices here are endless and since it's being read by the MSP430 it isn't parallel and therefore much smaller and cheaper, however they aren't PDIP and so are a little harder to solder, but its not that bad. On the small side here is a 128KB flash chip: http://www.digikey.com/product-detail/en/SST25VF010A-33-4I-SAE/SST25VF010A-33-4I-SAE-ND/2297792 On the large side here is a 16MB flash chip: http://www.digikey.com/product-detail/en/W25Q128FVSIG/W25Q128FVSIG-ND/3008697 For a basic 16KB game you're looking at $4.80 in chips (though I need to make sure you won't need more components to write to the ram. If anyone has done this before maybe you could let me know.), a few resistors, a PCB (can be made in your kitchen at home!), and optionally some kind of casing. All said I think even the ones for larger games can be built for under $10, even at a quantity of 1! --------------------------------------------!!UPDATE!!-------------------------------------------- So I have found that I need to include shift registers to have enough pins to write to the ram, as such I am adding them to the BoM. The good news is that they are only $0.63 a piece. Shift Registers (X2): http://www.digikey.com/product-detail/en/SN74HC595N/296-1600-5-ND/277246

Hey everybody, I just found the lazy way out of the controller problem! just run two cables with d-sub connectors down the back of the system and plug them in ti the controller ports, then the controllers into them. Stupid? Probably. Costly? Somewhat. Viable? Kinda. Lazy? You bet!

And in case I'm coming off otherwise I know I'm a complete armature in the realms of the 2600.

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.

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

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.

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.

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

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?

I didn't know where else to put it.

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.

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!

Thought it was worth asking. I'm not worried about quality of production though, I work at a maker lab and we have some good fabrication tools. Thanks for the quick responses.

So I'm working on a 2600 game and when it's done I'd like to put it on a cartridge, but I want to build it myself and I've run into a few questions. 1. I've been looking around at EPROM, EEPROM, and flash EEPROM and have found that flash looks like the best option, but can I even put a 2600 game on flash EEPROM? 2. The flash module I've found is a 32 pin PDIP package and is 256kB ( http://www.digikey.com/product-detail/en/SST39SF020A-70-4C-PHE/SST39SF020A-70-4C-PHE-ND/2297831 ), my target size is 64kB, will it be a problem if I use a chip that size? 3. I've seen a lot online about programming flash EEPROM, but most of the ones I've seen have been for a different style chip with what looks like a single I/O 8 pin chips as a posed to the multiple I/O many pin arraignment you find on atari games, what is the best way to program the chip I want to use? 4. How do you program the 22v10 chip and is this one a good choice? http://www.digikey.com/product-detail/en/ATF22V10C-15PU/ATF22V10C-15PU-ND/1008580 5. What would be required to build a cart which is compatible with DPC+, right now I'm developing the game without it as I fear it might be too complicated, but I though I'd ask anyway. 6. Is there an actual step by step on building an atari cartridge? I'm no stranger to electronics, but I've dealt mostly with micro controllers and simple circuits and this is a bit out of my experience. I would really appreciate an answer to any or all of these questions. Thanks in advance!