Jump to content

vcsrocks

+AtariAge Subscriber
  • Content Count

    75
  • Joined

  • Last visited

Everything posted by vcsrocks

  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.
  14. UPDATE: The firmware seems to work fine for Asterix. I will be testing a few other games but one obvious problem at this point is the EPROM I picked for the prototype. It works fine for F8 and F6 but it is too small for F4 and EF. It is also too slow (300ns) which significantly narrows the switching window the MCU has. Last but not least, it breaks most of my requirements, so I will look for a replacement more likely to be usable in the final product.
  15. 32 and 64KB should not be a problem. I found the description of EF but could not find any images to test it. Do you have one you can send me or point me to? I have created a prototype board: Now I will be working on the firmware.. 2 and 4KB games will not require any active participation from the MCU except for the A12 inverter so I will start straight with Asterix (F8) and move on from there...
  16. Danke Al_Nafuur!! That sounds like a good solution. I have already started with the PIC18 solution, so I'll see where that takes me first. I also like the challenge of creating a functional mapper controlled by an 8bit processor as I've always been told that it is not possible 🙂 Cheers
  17. Thanks Mr SQL!! That's very encouraging. I will wire up a PIC18 proto on the weeked. Let's see how far I can get
  18. Hi all, I have created the following post yesterday: Someone just told me that I should have created it in this subforum. I don't want to duplicate the post but I have also not found how to move the post here. Any suggestions? Also, if you can comment on the bankswitch schemes you currently use in your programs and any experience you can share on how to implement a bankswitch controller on a 8bit Microchip PIC will be much appreciated. Cheers!
  19. Started looking into what components to use for this. I will need an inverter for A[12], the bankswitch controller and a communication protocol to download the image from the PC into the ROM. The bankswitch controller must also be able to save the bankswitch selection in some sort of permanent memory. This pretty much excludes most inexpensive CPLD candidates as they would not be able to retain the bankswitch configuration. One option would be to have configuration jumpers though. If they are not SMT however, it increases a lot the assembly cost. I also looked into ARM processors (e.g. like the one used by the UnoCart) and FPGAs, but that would likely blow my requirement to sell the final product under 10€. So I am left with 8 and 16bit processors. The price constraint will probably play a significant role in this, so I will start small and go up until I find the cheapest solution. From what I have laying around, I selected a PIC18F26Q10 for the POC. They run at 16MIPs which gives me 62.5ns per instruction cycle, so let's see how far I can get with that. Anyone out there with experience in implementing bankswitch in a Microchip PIC or any other 8bit MCU??
  20. OK, got it 👍 I will go with the working assumption that the cart will support F8, F6 and F4 for now. Last night I ran some queries on my ROM database and 90% of the games I have images for use one of the three schemes or no mapping at all. SARA will depend on the hardware I end up with having RAM to spare.
  21. Thanks. That already starts narrowing it down 🙂 When you say FE (64K) do you mean Activision FE? Do you use F4 also with SARA? Cheers.
  22. Which bankswitching do you normally use?
  23. Hi all! Last month I saw the following ad on eBay: I thought the appeal of this kit for homebrew development was very limited: No bankswitching/mapper (only 2K games or 4K games with further modifications on the board) It required messing around with UV lamps, programmers, etc Required some knowledge of electronics Buying the parts separately would probably be less expensive Not possible to ship as a product to customers It would be probably easier and faster to use one of the existing USB/SD carts to test on a real hardware. This did make me think though that I had never seen a development kit for the 2600 which would allow homebrewers without knowledge of electronics to self publish their games. If a mapper is required, then that knowledge need goes up real fast. As in Europe we have very limited offers of good homebrew games available (most of them are from the USA and shipping quickly becomes a problem), I thought about making this my next project. The idea is to have blank carts (populated with all required components but without any game image in them) and a simple to use cable and PC software which would allow the user to create a cart ready to be shipped to customers as well as test games in a real atari. Is this something that would interest the homebrew community? Here are some requirements I have come up with: The final product must cost under 10€ (populated cart PCB) All components must be easy to find. Preference should be given to components still in production Must be usable by people with no experience in electronics No soldering Must support mappers (the ones used by batari Basic at a minimum, as a lot of people seem to use bB) No physical alterations to select the desired mapper (or no mapper) Must fit in a standard Atari cartridge case Components should be SMD to keep production cost as low as possible All comments will be appreciated!! Cheers.
×
×
  • Create New...