Jump to content


+AtariAge Subscriber
  • Content Count

  • Joined

  • Last visited

Community Reputation

43 Excellent

About vcsrocks

  • Rank
    Star Raider

Profile Information

  • Gender
  • Location

Recent Profile Visitors

2,169 profile views
  1. I remember seeing this a couple of years ago. The idea is interesting in that it creates a bus extender for the VCS. This would allow for the production of 8/16/32KB games without bankswitching in the actual game cart (i.e. the bankswitch controller is in the "adapter" plugged between the VCS and the actual game). One thing I would have done differently though is to make the bankswitch selection automatic. This can be easily achieved by implementing the physical switch with four extra pads in the "bankswitched cartridge connector". Every time you insert a game, the connector circuitry will close JP1 and JP2 as required by the ROM in the cart.
  2. Here is the updated list of tested games/schemes: Dig Dug (F6SC) Megaboy (F0) EF Template (EF) Sword of Surtr (F4) BMX (F6) Asterix (F8) Pacman (4K) Air-Sea Battle (2K)
  3. I did not manage to make the video over the weekend as I intended to, but that may have been actually a good thing. A few days ago I designed a SARA module to add RAM to the cart based on the feedback of @MemberAtarian. As I could use the same design for another project I will be working on, I had the PCBs made and they arrived today: It is basically an external RAM with a 74HC02 as address decoder: The other components/jumpers/headers are there for the next project 🙂 And here is the module plugged into the cart: I tested Dig Dug with this setup and it works fine. I also checked the bus timings and they look good.
  4. OK, as always, there is more than one way to skin a cat. I came up with a few ways the user could switch games on a multi game cart and at some point I will try all of them. For now though and for the sake of moving forward, I have settled on the 32in1 on/off switch to flip through the games in ROM. That is very simple to implement and does not require any additional hardware! I've tested this today and it works fine, so I will try to load up a video of the progress so far over the weekend.
  5. F0 works fine. I was able to play Megaboy without any problems, so now the list of tested games/schemes is: Megaboy (F0) EF Template (EF) Sword of Surtr (F4) BMX (F6) Asterix (F8) Pacman (4K) Air-Sea Battle (2K) Now back to the game switch...
  6. That would be the most user friendly approach by far. I'll have to see what I can do about the vendor ID though, as I don't have one I can use for this project. Maybe there is a module out there I can use. For now, I need to cross a few other bridges before I get to the actual flashing process, but I will definitely keep it in mind. Thanks for the suggestion!!
  7. Thinking about this after my last post yesterday, it hit me that it would probably be fairly easy to implement F0 as well, now that we are dealing with 64KB images. I will put the game selection on hold and try this first...
  8. Not a whole lot of time to play with this over the weekend, but I did manage to test the EF scheme and it works fine on the prototype. So the current list of schemes confirmed to work are: F4, F6, F8 and EF. So I will be working on the multi game selection now...
  9. After years of dealing with jumpers and re-purposed old cart PCBs I decided to have these made at the end of last year. The idea comes for a similar board I've seem somewhere for the MSX. They really help as there are no more bad connections or jumper cables getting disconnected and driving me craze for hours (or days as it has been the case more than once). The lined up address and data connectors make general debugging and analysis (e.g. with a logic analyzer) a lot easier and the A12 inverter saves wiring and board real estate. They were definitely not cheap, but all in all the amount of time they have saved me since I got them is paying. That looks quite good! I guess the two main differences is that they went the CPLD route, which is much more straight forward but a lot more expensive as a final product; and you have to use an standard programmer for the ROM which makes it a bit more difficult and intimidating for people without practice.
  10. I've found this great thread with an functional example of EF (thank you @Wickeycolumbus) : That will help me test EF!
  11. I've managed to test the following games with the new prototype: Sword of Surtr (F4) BMX (F6) Asterix (F8) Pacman (4K) Air-Sea Battle (2K) I was able to play the games for as long as I wanted with no glitches, so that tells me the firmware is working (at least for these particular games). I also checked the ROMs in Stella to figure out when the game does the backswitching and make sure I hit that point of the game multiple times. I still need to find an EF ROM to test and then perform the following additional tests: NTSC console. So far I have tested on a PAL console but the NTSC version is slightly faster, so I will be testing this too 7800 console, as it has completely different timings at start up which may confuse the firmware More games to make sure the solution works every time I am also working on a solution to switch the games on a multi-game ROM image. Stay tuned 🙂
  12. After some digging I found an old stock of flash memories I have which are still available for purchase in most reputable online stores at a fairly good price. So here is the new prototype: I tested Asterix again and it works fine, so I will be testing some more games to cover all schemes. But as the saying goes, every time you solve a problem you create another one. In this case, the memory I am using is too big! It has 256KB which for 2600 standards is a waste. I will see if it is viable/worth to make this a configurable multi-game cart (i.e. it can be configured as a single game or multi game cart depending on what is being published).
  13. That would be the best solution, but it is not possible even if bankswitching is completely left out. In the VCS, the 6507 expects the data bus to be stable about 400ns after the address bus is setup. The PIC18F26Q10 needs 62.5ns per instruction cycle, so that translates to about six instructions to do the following: Detect an address change. As the communication between CPU and ROM is asynchronous, the MCU will have to detect a change in the address bus to start decoding it. The fact that the address bus is 13bit long (A[12:0]) and the MCU data bus is 8bit further complicates things. That could potentially be done with IOC but it will still cost between two and four cycles if IDLE mode is used. Control the data output state. There are two separate registers involved in fully implementing tri-state in a PIC18. That would already take at least three cycles. The MCU has configurable open drain outputs, which could help though. Fetch the data from flash. This is the killer. It takes a minimum of six cycles to read a PFM location (i.e. four cycles to set the pointer and two cycles for the actual read) and another two cycles to output it to the port. There are other methods to read PFM, but the net cost is always equal or higher than this. So at best we are at 11 cycles which will not work. This would go towards a STM32 solution or at least a fast 16bit MCU. If the PIC18 does not work, than the option is back on the table, but if the PIC18 works in conjunction with an external ROM, the overall cost will probably still be lower than going with a more powerful MCU.
  • Create New...