Jump to content

Kroko

Members
  • Content Count

    431
  • Joined

  • Last visited

Community Reputation

10 Good

About Kroko

  • Rank
    Moonsweeper
  • Birthday 12/26/1969

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Germany

Recent Profile Visitors

11,311 profile views
  1. In that case do yourself a favor, spend an external quarz-oscillator and connect it to one of you CPLD inputs. I was using 10 MHz in the past. 10 Mhz is good enough for the kind of timing you need for external RAM. This input can be used as input to some counter on the CPLD to get all kinds of differnt time delays between things that you want to detect on address or databus.
  2. It really depends on what you want to do in the end. Are you really only interested to have the 8K switching logic on a CPLD and nothing else ?
  3. Yes, true ... not looking good But there are so many cheap little controllers now ...like Rasperry Pi Pico. 5$ and easy to interface ... levelshifters for the 3.3V are not a real problem, since you would need some interface PCB anyway.
  4. You do need to debounce the address lines in the sense that you only react on an address, in case it is seen by the CPLD long enough. Since not all address bits are set synchronously, a single read from the CPLD can result in a more or less random address. It might already be different a few nanoseconds later. If you trigger a bankswitch on an address that has not yet stabilized, most definitely the cartridge will crash sooner or later. In general, everything on the bus (data or address) that you are going to use for bankswitching needs to stabilize before usage. So you need to find a way in VHDL or Verilog (or however you program your CPLD) to realize some reliable timing. I tried a lot of things, but the only way that really worked for me was to connect an external oscillator to the CPLD. In case you ever want to support extra RAM, you will need an accurate timing anyway. All timing and delay mechanisms I tried failed, so I went with an external oscillator. BTW: Don't waste your time with CPLD. You can better to this with a small microcontroller ... everybody is using microcontrollers now. Even Raspberry Pi is fast enough. CPLD are no longer needed if you ask me.
  5. Can you find out (maybe with a multimeter) if the counter output is counting up on each power cycle ? I mean what the higher bits of the counter are doing ? ... do they count up or are they getting reset ? Or maybe you have the time to reverse engineer the schematic for us
  6. Without looking at the circuit, I doubt that it will work. What the circuit has to do is to select the highest address line on the EEPROM to select one of two 8K areas inside your 16K chip. If you want more than 16K to have more than two 8K games, you will need * a larger chip which may have a different pinout => you may need some kind of adapter * need a strategy to control the higher address lines because most likely your device is not doing this (you could use simple switches for that to set the high address lines to 0 or 1) Then by cycling the power you would select between two 8K roms. By the switches you could switch in two different ROMs.
  7. I am not working on anything at the moment ... I just remembered the discussion that I had a long time ago. The question was if it is save to drive the cartridge pins while the console is switched off. And I remember somebody was worried about driving current into a switched off console. If this is more a theoretical problem, then it is not necessary to think about cartridge behaviour during console power down. But if it is not only theoretical and somebody decides to have big capacitors on his cart, it may be alive significantly longer than the console. On the other hand, if this was a problem...we may have heard of it before (because it is not limited to bus stuffing devices).
  8. Does this mean the driver circuit in the cart can not electrically override the value on the bus, because the internal driver is stronger, or there are unpredictable resistances on the pins like dirt at the connector ? Would these kind of problems be possible to solve with a stronger driver that is really operating with 5V instead of 3.3V with more maximum current ? I understand that part ... I guess it is tricky to get the timing correct if you don't have a dedicated circuit or logic that can generate an "adress stable" signal. Somebody told me some time back (I don't remember who it was), that it is a very bad idea to stuff value into the 2600 circuits in case the 2600 is switched off. I know there have been lots of tests of this bus stuffing when the 2600 is powered normally. But do you know more about what happens if you continue to stuff when VCS power is off ? Should I be worried to inject voltages to the pins of the console if the console is not powered ?
  9. Thanks for the links. Very interesting to read 👍 Did you ever understand what exactly caused the issue on the Juniors ? On the other thread I only found this: "ZackAttack has determined the problem with the Juniors is most likely an electrical issue that, if a solution can to be found, would require hardware modifications" Do you remember what kind of "electrical issue" ?
  10. If you have two different drivers on the databus, are you sure that the console will not get damaged ? What happens if both drivers set different values ? Are 2600 databus drivers protected against such situations, where they have to drive the bus "against" a second driver ?
  11. It depends on how your hardware is designed. It is not very popular now to use a CPLD, because everything you need can be done by one little microcontroller. There were times, when these controllers were too slow to do the databus handling ... so a CPLD was doing that part of the job. But now they are (or can be) fast enough. Less chips .. less trouble .. less cost .. less board space .. less power consumption. etc.. (If your device needs too much power, you will need an external power supply...which you don't want) I would certainly not use a CPLD for any new design. Not only because you need VHDL or VERILOG and the complete toolchain for programming them. You also need to write the complete bankswitching logic in VHDL ...which you also don't want to do Startup of the microcontroller should be fast enough to establish a routine that can scan the address bus and output bytes on the databus, if cartridge rom is addressed by the console. You just need a contoller with enough pins and a smart routine for the handling of output to the databus. I think batari knows it very well, since I guess he is using such a microcontroller solution. You could use a parallel EEPROM, but that will need additional board space, makes routing the board more difficult, consumes power, costs extra money ...etc ... There should be enough memory inside the microcontroller to not need any additional chip for RAM or ROM. It is the same principle. You present some code to the console that writes a program to console RAM and then jumps to this code. After you have done that, you don't need to worry about the adress bus anymore, because code is now taken from RAM rather than ROM. This solution has the advantage that you are free to do whatever you want while the code is executing in RAM and don't need to worry about sending bytes on the databus from your cartridge. Also for this solution, your hardware needs to be "instant on" to a minimum degree. Otherwise the console will crash. There is nothing you can do to prevent this. If the console wants to read the reset vector from cartridge ROM, you need to be ready to provide the vector or the console will get some random value which will lead to a crash in most cases.
  12. You can not let your cartridge provide random values on the databus, you need to make sure that you keep control over what is going on. If the console shows some address on the bus, which is located in you cartridge, then you need to output something that makes sense. You need to construct your cartridge such, that some initial ROM is presented to the console. This can be a very simple ROM (only a few bytes). Or a very complicated one. Some cartridges provide a "menu system" ROM to the cartridge until they finished loading the real roms. Or they let you select one of several different ROMs that the cartridge can provide. After finishing the loading or selection they all have the same problem: to do a clean start of the ROM they loaded. This can be done by presenting a JMP ($FFFC) instruction to the console. Starting from that moment, the real ROM must be provided at the databus and the initial ROM is switched off. An example of a very easy initial ROM would be a reset and IRQ vector pointing to $1000. And a BRK instruction at $1000. This will result in an endless try of the console to jump to $1000. I think these are only 5 bytes you need to provide to the console while you are waiting for your SD content to load. After you loaded, you wait until the cartride provides $1000 at the adress bus and you provide the JMP ($FFFC) instruction instead of the BRK. Then you switch in the real ROM. I did not try this, but maybe somebody else wrote code like this before. You can also make some endless Loop ...important is only you have control over what the console is doing, while you are waiting.
  13. $3F is a little bit difficult, because the last 2K chunk in the rom file plays a special role. It needs to be placed at the fixed bank. So you could be tempted to open the file and read the last 2K to place it in the fixed bank. If you do it like that, then it is almost sure you will not produce a working ROM if the last chunk is not exactly 2K. In my opinion, a 3F ROM that does not have a file size that is some multiple of 2K is broken.
  14. As far as I know, the last two bytes are the IRQ/BRK vector. If this vector is unused and can contain random data, I see no reason why a ROM should fail on "real hardware". In case of Harmony I guess there is also some strategy to fill internal memory from a binary file. And here there could be a problem if the size is incorrect. The ROM content may be written to the wrong memory location, but that depends on how Harmony maps the file to its memory ... So there is no answer for "real hardware". You could only tell it for some specific device ...
  15. I guess nobody really thought of ROM files with a wrong size. This sentence just means that the last 2K block found in the ROM will be the fixed block. You should start counting blocks from the beginning of the file and put the last 2K block to the fixed bank, no matter if the last block is really 2K or not. This is also what would happen if you flash the ROM to some real memory. You would not flash it "backward" but from start of file until end of file, which leaves the last two bytes undefined or empty.
×
×
  • Create New...