The ultimate atari cartridge: Need input!

[treep78]

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

[+batari]

I thought the point was a single-chip solution... if not, I missed that part about the RAM chip (I thought it was intended as an option only, not as a requirement.)

 

A 2-chip solution will work (25 MHz is enough for that). One challenge here is getting stuff onto the RAM chip after the console boots but before the 6507 needs it. I don't know how much time you have but I think it's under 20 ms. Another challenge is the board size. A 32-pin chip will need to go above the screw making for a bigger board. Well, it's not so much of a challenge, but it does add cost.

[CPUWIZ]

I know that this has little to do with the ultimate cart, but big bankswitched games, even with extra SARA RAM can be made.

 

http://atariage.com/forums/topic/219144-new-homebrew-board-coming-soon/?p=3027111

 

 

[+Random Terrain]

If you big brained people get together and make some kind of new cart that will have the good DPC+ graphics, but will have more RAM for extra variables, I'll be very, very, very, very, very, very, very, very, very, very, very, very, very, very, very, very happy

[treep78]

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!

[treep78]

I thought the point was a single-chip solution... if not, I missed that part about the RAM chip (I thought it was intended as an option only, not as a requirement.)

 

A 2-chip solution will work (25 MHz is enough for that). One challenge here is getting stuff onto the RAM chip after the console boots but before the 6507 needs it. I don't know how much time you have but I think it's under 20 ms. Another challenge is the board size. A 32-pin chip will need to go above the screw making for a bigger board. Well, it's not so much of a challenge, but it does add cost.

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

Edited September 11, 2014 by treep78

[+5-11under]

Time to get to work, then.

[+Gemintronic]

Yes, and as penance for posting this in the batari BASIC section you must add kernel support to bB. This would have the side benefit of having plenty of users/testers/guinea pigs

[treep78]

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?

[treep78]

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?

[treep78]

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.

[+SpiceWare]

That's a blessing in disguise. There's a flaw in the Flashback hardware that makes it so that A12 is always on, which might have caused you problems. This flaw causes DPC, DPC+, SARA and other cartridge games to not work. SARA = extra chip that gives games 128 bytes of additional RAM.

 

At least you got a couple of brand new joysticks to use with your 2600. They also have brand new paddles which are jitter free, plus the plastic's not brittle.

[treep78]

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.

[treep78]

Ahh, bread boarding.

Edited September 17, 2014 by treep78

[Cybearg]

How do you even...

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

[Andromeda Stardust]

Grabs popcorn...

 

I often wondered if "bus-stuffing" from the cart side was possible. People told me "No" amd I dropped it. But you are one determined motha and I wish you the best of luck. I always thought 160x192 fmv on the TIA would be cool. Basically forget every other player 1, 2, missile, ball register and spam the TIA by changing the background color on every clock. Pitfall II spammed the audio register at 15khz so sound is doable. Make full motion video work and then come up with a proggy running cart-side to populate this video stream with game graphics.

[Keatah]

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!

 

Why am I picturing a VCS with a bra?

 

..now tubes are coming to mind. I'm outta here!

[ZackAttack]

I often wondered if "bus-stuffing" from the cart side was possible. People told me "No" amd I dropped it. But you are one determined motha and I wish you the best of luck. I always thought 160x192 fmv on the TIA would be cool. Basically forget every other player 1, 2, missile, ball register and spam the TIA by changing the background color on every clock. Pitfall II spammed the audio register at 15khz so sound is doable. Make full motion video work and then come up with a proggy running cart-side to populate this video stream with game graphics.

My understanding is that the harmony already does some bus-stuffing in it's DPC+ implementation. Changing the TIA COLUBK register every color clock is not possible from the cart because no control signals are available and the 6507 is too slow. The fastest the background color could be changed without modifying the system is only every 9 color cycles. It's actually good that this limitation exists because it forces all VCS games to have that VCS look and feel.

 

@Treep there are also 96 pixel kernels that you could use. I think they are just 2 48pixel kernels interlaced together.

[+SpiceWare]

My understanding is that the harmony already does some bus-stuffing in it's DPC+ implementation.

No bus-stuffing happens in DPC+. You might be thinking about Fast Fetch mode, but that's not done via bus-stuffing.

 

Have you seen my DPC+ ARM Development series? In the comments of Part 8

There's no connection between the 6507 and the ROM. The connections are this:

 

6507 <--> ARM <--> Flash (ROM) and SRAM (RAM)

 

The ARM emulates everything about the cartridge, not just the DPC+ data fetchers. This emulation includes the bank switching hardware, any expansion RAM, and the ROM - this includes the connection between the 6507 and the simplest 2K and 4K ROMs.

If Fast Fetch mode is turned on, the ROM emulation routine monitors for the LDA # command. If found, instead of returning the next byte in ROM (the value after # ), that byte is used to specify a DPC+ register and the value from that register is returned instead.

Edited May 15, 2015 by SpiceWare

[ZackAttack]

I was thinking of the Fast Fetch mode. Could have swore the documentation stated 3 cycle register updates. Must be confusing it with my own project. Sorry about that.