Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store

vcsrocks

Members
 View Profile  See their activity

  • Posts

    121

  • Joined

  • Last visited

 Content Type 

Everything posted by vcsrocks

  1. vcsrocks
    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...
  2. vcsrocks
    Thanks! ?
  3. vcsrocks
    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.
  4. vcsrocks
    I've found this great thread with an functional example of EF (thank you @Wickeycolumbus) : That will help me test EF!
  5. vcsrocks
    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 ?
  6. vcsrocks
    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).
  7. vcsrocks
    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.
  8. vcsrocks
    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.
  9. vcsrocks
    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...
  10. vcsrocks
    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
  11. vcsrocks
    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
  12. vcsrocks
    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!
  13. vcsrocks
    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??
  14. vcsrocks
    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.
  15. vcsrocks
    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.
  16. vcsrocks
    Which bankswitching do you normally use?
  17. vcsrocks
    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.
  18. vcsrocks
    Silly mistake. Thanks.
  19. vcsrocks
    Very good point! But they switch only half the ROM space, so there is a maximum of 512KB possible. One good thing about the Tigervision scheme is that it uses a hotspot in the TIA space, which saves the RAM byte. If one byte in the ROM was to be used as indication of the current bank, no RAM would be required at all. The question really is, would anyone ever need 1MB for a VCS game...
  20. vcsrocks
    Hi bcombee. I know what you mean, but this BS is for ROM only, so the lack of R/W is not an issue. Whenever the CPU access RAM (addresses 0x80-0xFF) the cart "sees" this access as it gets the full data and address buses. To access the ROM, the CPU uses addresses 0x1000-0x1FFF effectively using A12 as chip select. For RAM access, A12 is low so a normal cart inverts this line and presents it to the ROM OE or CE ports. This effectively puts the data lines of the cart in high impedance. A low A12 allows the CPU, RIOT or TIA to take over the data bus, depending on the address being accessed and the R/W line, but the cart still receives all signals so RAM access can still be used by the BS logic to trigger the page selection. As for the access to the RAM itself, at the end it does not matter if the CPU is executing a read or a write. What matters is what is in the address and data lines. If the data lines are driven by the CPU or by the RIOT makes no difference. The real use case would be anyway to execute a write first (as it would not make much sense to read before something is stored in the hotspot), but again, it should not matter. Last but not least, the RAM hotspot can be any address in the range 0x80-0xFF, although 0x80 would probably make more sense because of the stack. As soon as the BS sees an access to address X (0x80 for the sake of argument) it will set the ROM page to whatever value is in the data lines.
  21. vcsrocks
    Hi everybody, Talking to a homebrewer here at AtariAge the topic of large ROMs (128KB+) came up. One part of the bankswitching schemes which always put me off is the amount of memory used by routing overhead and the hotspots. Yes, I know that in the great scheme of things that may end up being negligible, but the whole point of using bankswiting is to have more memory available and large ROMs require a larger number of hotspots So I was thinking if a trade off with RAM could be acceptable, why not have a hotspot in RAM and bankswitch according to the value saved in that hotspot. The idea is that a write to that specific address would trigger the bankswitch. A read to that address would not do anything as the bank is already selected. Using a full byte in RAM, the cart could have 1MB of ROM available (256 * 4096). Coding would be as simple as loading the accumulator with the desired bank number and storing it into the hotspot address in RAM. With one additional RAM byte, the BS routine could route a call to 256 distinct subroutines in the new bank (see diagram below). And a relatively simple one-size-fits-all solution could be created by using another RAM byte and a single dispatch sub-routine: Does anything like this exist already? Would it make sense to use it for very large ROMs?
  22. vcsrocks
    Better late than never... HAPPY NEW YEAR!!
  23. vcsrocks
    This board uses the same principle as all other pause boards for the 2600. It intercepts the RDY line used by the TIA for synchronization with the CPU. According to this post: http://atariage.com/forums/topic/207257-2600-pause-mod-on-a-7800/ it will not work out-of-the-box, but it should be possible to find a way to install it and pause the 7800 while in 2600 mode. As for the 2600 adapters (cx55, Intellivision System Changer, ColecoVision Expansion Module 1) they usually are close to a complete 2600 system, so they should be easier to mod...
  24. vcsrocks
    I've been getting some questions on the board's "mute" line (yellow wire). The mute line is fully functional on all boards I shipped. The reason I had not mentioned it in the installation instructions is because initially I had designed it to be used with AV mods. If RF is still used (which is my personal preference btw), the mute can still be used by connecting it directly to pin 13 on the TIA (both PAL and NTSC). The caveat is that the audio will be grounded during pause. In my tests on three consoles (2 PAL and 1 NTSC) this works fine and the line consumes less than 5mA during pause, but I cannot guarantee this will be the case for all versions and reviews, so there is a bit of a "do it at you own risk" associated to it... The consumption can be tested during installation or just leave it on pause for a while and check if the TIA gets hotter before you put the case back together. Shouldn't be the case but that is the safest way to go. During the normal game (i.e. pause off) the line is in high impedance which makes it "invisible" to the TIA.
  25. vcsrocks
    That's actually clever, although I am not sure how much modding it requires on the PCB overall. This version only requires one TIA pin to be disconnected.
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2023 AtariAge

×
×
  • Create New...