Jump to content

treep78

Members
  • Content Count

    25
  • Joined

  • Last visited

Community Reputation

17 Good

About treep78

  • Rank
    Space Invader
  • Birthday February 14

Profile Information

  • Gender
    Male
  • Location
    Abilene, TX | Harvard, MA | Salisbury, VT
  1. 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.
  2. 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.
  3. Of course since my model doesn't use players, balls, or paddles that isn't an issue.
  4. 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.
  5. 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!
  6. 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.
  7. 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.
  8. 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.
  9. 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?
  10. 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?
  11. 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
  12. 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!
  13. And in case I'm coming off otherwise I know I'm a complete armature in the realms of the 2600.
  14. 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.
×
×
  • Create New...