VRC-VI multicart
Moderator: Moderators
- l_oliveira
- Posts: 409
- Joined: Wed Jul 13, 2011 6:51 am
- Location: Brasilia, Brazil
Re: VRC-VI multicart
The reset circuit is the basic stuff seen on pirate multicarts (capacitor charging with /Phy2 when it stops toggling) clocking a binary counter...
Now for the ROM patch, here you go. Apply this to the original ROM. I dunno but it might work with the translated rom, too but not sure. You can just patch it for mapper then patch for the translation... That should work.
Let me know if this works for you.
Now for the ROM patch, here you go. Apply this to the original ROM. I dunno but it might work with the translated rom, too but not sure. You can just patch it for mapper then patch for the translation... That should work.
Let me know if this works for you.
- Attachments
-
- Akumajou Densetsu mapper26_(J).ips
- Converts Akumajou Densetsu for the Madara/Esper Dream2 board type.
- (235 Bytes) Downloaded 376 times
Re: VRC-VI multicart
Long time lurker, first time poster. I have to say that I have learned more reading NESDev than any other forum, so all of you definitely have my respect.
l_oliveira: Just wanted to say that this post is just what I needed and that I'm attempting a 2-in-1 VRC6 cart myself (Esper Dream 2 and Akumajou Densetsu). I do have a question though...
When I attempt to apply the patch you posted and then split the ROM, I'm getting an error in FamiROM: Do you or anyone have thoughts on how to resolve this issue?
Also, while I'm at it, can anyone point me in the direction of info on best methods for using a manual switch on a cart to toggle between EPROMs? I've been searching far and wide and so far I've seen that using the OE# or CE# pins might be a viable option. I'm just still trying to wrap my head around it all. For background, I do have some experience as I have successfully translated Lagrange Point and made a couple other repros (IE: Recca).
I found this on the interwebs and thought a similar setup might be a viable solution (with 28F010s and 28F020s):
Thank you all in advance for reading and I apologize if this is slightly off topic.
l_oliveira: Just wanted to say that this post is just what I needed and that I'm attempting a 2-in-1 VRC6 cart myself (Esper Dream 2 and Akumajou Densetsu). I do have a question though...
When I attempt to apply the patch you posted and then split the ROM, I'm getting an error in FamiROM: Do you or anyone have thoughts on how to resolve this issue?
Also, while I'm at it, can anyone point me in the direction of info on best methods for using a manual switch on a cart to toggle between EPROMs? I've been searching far and wide and so far I've seen that using the OE# or CE# pins might be a viable option. I'm just still trying to wrap my head around it all. For background, I do have some experience as I have successfully translated Lagrange Point and made a couple other repros (IE: Recca).
I found this on the interwebs and thought a similar setup might be a viable solution (with 28F010s and 28F020s):
Thank you all in advance for reading and I apologize if this is slightly off topic.
- l_oliveira
- Posts: 409
- Joined: Wed Jul 13, 2011 6:51 am
- Location: Brasilia, Brazil
Re: VRC-VI multicart
Hi there. I checked the patch and it has changed the number of chr banks to 32. It's supposed to be 16 (128KB). Fix that with something such as AcidPhire NES Header Checker or other header editing tool.
Akumajou Densetsu should have 256KB of PRG and 128KB of CHR.
And the schematic for ROM selector looks fine. But I would suggest you instead use a 2x bigger EPROM and use the highest address line as toggle that way you don't need to make ugly piggybacks.
Thanks for reporting the issue. I have not noticed it because I usually split NES ROMs by hand using a hex editor.
Akumajou Densetsu should have 256KB of PRG and 128KB of CHR.
And the schematic for ROM selector looks fine. But I would suggest you instead use a 2x bigger EPROM and use the highest address line as toggle that way you don't need to make ugly piggybacks.
Thanks for reporting the issue. I have not noticed it because I usually split NES ROMs by hand using a hex editor.
Re: VRC-VI multicart
Thanks for the info! I used AcidPhire NES Header Checker and was able to split the ROM successfully.l_oliveira wrote:Hi there. I checked the patch and it has changed the number of chr banks to 32. It's supposed to be 16 (128KB). Fix that with something such as AcidPhire NES Header Checker or other header editing tool.
Akumajou Densetsu should have 256KB of PRG and 128KB of CHR.
<SNIP>
Thanks for reporting the issue. I have not noticed it because I usually split NES ROMs by hand using a hex editor.
I'm still relatively new to repros and translations so this part went right over my head:
I'm not sure how to achieve this. I have already attempted very ugly piggybacks and that was lesson in Frankenstein soldering.And the schematic for ROM selector looks fine. But I would suggest you instead use a 2x bigger EPROM and use the highest address line as toggle that way you don't need to make ugly piggybacks.
I definitely should've done a lot more homework. I figured I should reach out here before ruining an endangered and precious piece of hardware.
How would I use the highest address line to toggle? I do have several 29c040s and 28f020s, so I have the parts. I just need to get past this whole learning curve thing.
Again, thank you very much for your help with this!
- l_oliveira
- Posts: 409
- Joined: Wed Jul 13, 2011 6:51 am
- Location: Brasilia, Brazil
Re: VRC-VI multicart
The logic is pretty simple:
I used 1MB EPROMs on my cart, which can be partitioned in:
1 segment of 1MB
2 segments of 512KB
4 segments of 256KB (I used this on my cart)
8 segments of 128KB
16 segments of 64KB
32 segments of 32KB
64 segments of 16KB
128 segments of 8KB (this is the average size of an Atari 2600 game).
Each address line added to the ROM doubles it capacity, so A19 (highest address line for 1MB ROM can be used to split it at 2 chunks of 512KB by connecting it to a switch. Low means first half and high means second half. If you used A18 too you would have four possible values meaning you now have four banks of 256KB and so on.
I used 1MB EPROMs on my cart, which can be partitioned in:
1 segment of 1MB
2 segments of 512KB
4 segments of 256KB (I used this on my cart)
8 segments of 128KB
16 segments of 64KB
32 segments of 32KB
64 segments of 16KB
128 segments of 8KB (this is the average size of an Atari 2600 game).
Each address line added to the ROM doubles it capacity, so A19 (highest address line for 1MB ROM can be used to split it at 2 chunks of 512KB by connecting it to a switch. Low means first half and high means second half. If you used A18 too you would have four possible values meaning you now have four banks of 256KB and so on.
Re: VRC-VI multicart
You sir, just made something click. For some reason, I thought it was way more complicated than that.l_oliveira wrote:The logic is pretty simple:
I used 1MB EPROMs on my cart, which can be partitioned in:
1 segment of 1MB
2 segments of 512KB
4 segments of 256KB (I used this on my cart)
8 segments of 128KB
16 segments of 64KB
32 segments of 32KB
64 segments of 16KB
128 segments of 8KB (this is the average size of an Atari 2600 game).
Each address line added to the ROM doubles it capacity, so A19 (highest address line for 1MB ROM can be used to split it at 2 chunks of 512KB by connecting it to a switch. Low means first half and high means second half. If you used A18 too you would have four possible values meaning you now have four banks of 256KB and so on.
A19 Low = First Half
A19 High = Second Half
Excellent! Thank you very much for explaining that!
Re: VRC-VI multicart
Sorry for necro-posting this thread. I'm also trying to make VRC6 multicart. I'm a little confused about the replacement of 32K SRAM since it has no +CE but only a single /CE. How did you use a 74LS32 to create a +CE from other pins? Could you please share your schematic?
And there is another question bothering me. I noticed the WRAM /CE pin on VRC6 (pin 16) passes a 1k res and a diode to the /CE of 6264, also follows a 82p cap to GND. Here is a simple sketch:
What the hell is it? How does this supposed to work?
And there is another question bothering me. I noticed the WRAM /CE pin on VRC6 (pin 16) passes a 1k res and a diode to the /CE of 6264, also follows a 82p cap to GND. Here is a simple sketch:
Code: Select all
VRC6 pin16 ---+---|>|---+--- WRAM /CE
| |
+---1K----+
|
82p
|
GND
Re: VRC-VI multicart
That's a deglitcher.
A design flaw in the NES/FC makes it impossible to tell whether the CPU is accessing $E000 or $6000 until it's too late, so memory access to $E000 will briefly look like access to $6000.
By delaying the RAM's enable signal, that momentary incorrect pulse won't be received by the RAM, and writes to $E000-$F003 won't corrupt the contents of RAM.
(1kΩ·82pF = 82ns ; the glitch is roughly 30ns long. The diode means that when /WRAMCE rises, it'll immediately disable the RAM instead of waiting another 82ns)
—
I'm not clear what the 74'32 is doing in l_oliveira's original post; all SRAMs that I know of already support "/OE grounded" topology, and the VRC6 doesn't have a +CE output.
A design flaw in the NES/FC makes it impossible to tell whether the CPU is accessing $E000 or $6000 until it's too late, so memory access to $E000 will briefly look like access to $6000.
By delaying the RAM's enable signal, that momentary incorrect pulse won't be received by the RAM, and writes to $E000-$F003 won't corrupt the contents of RAM.
(1kΩ·82pF = 82ns ; the glitch is roughly 30ns long. The diode means that when /WRAMCE rises, it'll immediately disable the RAM instead of waiting another 82ns)
—
I'm not clear what the 74'32 is doing in l_oliveira's original post; all SRAMs that I know of already support "/OE grounded" topology, and the VRC6 doesn't have a +CE output.
Re: VRC-VI multicart
This glitch only affects writing to PRG RAM, right?lidnariq wrote: A design flaw in the NES/FC makes it impossible to tell whether the CPU is accessing $E000 or $6000 until it's too late, so memory access to $E000 will briefly look like access to $6000.
By delaying the RAM's enable signal, that momentary incorrect pulse won't be received by the RAM, and writes to $E000-$F003 won't corrupt the contents of RAM.
(1kΩ·82pF = 82ns ; the glitch is roughly 30ns long. The diode means that when /WRAMCE rises, it'll immediately disable the RAM instead of waiting another 82ns)
VRC6 has a fixed bank at $E000~$FFFF, it will not mistakenly read PRG RAM at startup due to this glitch, will it?
I replaced the PRG RAM on my VRC6 multicart to 32K FRAM (FM18W08), and removed the backup battery (MM1026 also removed). Then I found the game won't run unless I disable the FRAM (disconnect FRAM's /CE from the deglitcher and tie it to VCC). I don't understand why this happens. I'm suspecting that a bus conflict is occuring between PRG ROM and PRG RAM.
Re: VRC-VI multicart
At startup, the VRC6's RAM enable should be disabled, so RAM shouldn't get the /CE signal on startup. Later on, the RAM will still see a glitchy /CE even on reads to $E000-$FFFF (e.g., IRQ vector) but the bus will be driven by the ROM afterwards.Haruka wrote:VRC6 has a fixed bank at $E000~$FFFF, it will not mistakenly read PRG RAM at startup due to this glitch, will it?
No, that won't be a bus conflict. The VRC6 itself is only going to assert /PRGRAMCE or /PRGROMCE, never both.Then I found the game won't run unless I disable the FRAM (disconnect FRAM's /CE from the deglitcher and tie it to VCC). I don't understand why this happens. I'm suspecting that a bus conflict is occurring between PRG ROM and PRG RAM.
I don't suppose you have access to an oscilloscope?
Re: VRC-VI multicart
What if the 82p cap was short-circuit? That would explain why disabling FRAM does make the game booting fine while otherwise don't.No, that won't be a bus conflict. The VRC6 itself is only going to assert /PRGRAMCE or /PRGROMCE, never both.
Nope. Neither do I have a logic analyzer nor multi-meter...I don't suppose you have access to an oscilloscope?
- l_oliveira
- Posts: 409
- Joined: Wed Jul 13, 2011 6:51 am
- Location: Brasilia, Brazil
Re: VRC-VI multicart
This is what the 74LS32 is doing on that cart (might not be wired physically like this on my cart as I just drew this from my head).
The circuit below is meant to make up to the fact that 62256s have no non-inverted Chip Enable pin. Maybe it could be simpler with your FRAM IC, you might not even need the 74LS32 and just use the /CE signal from the mapper chip directly.
The circuit below is meant to make up to the fact that 62256s have no non-inverted Chip Enable pin. Maybe it could be simpler with your FRAM IC, you might not even need the 74LS32 and just use the /CE signal from the mapper chip directly.
- l_oliveira
- Posts: 409
- Joined: Wed Jul 13, 2011 6:51 am
- Location: Brasilia, Brazil
Re: VRC-VI multicart
Oh it just occurred me that FRAM may actually require /OE and /WE to pulse for it to pass through the rewrite cycles from read and write accesses.
I suggest Haruka try this circuit with the 74LS32 I posted on the previous post for creating specific /OE and /WE signals for the FRAM while having the FRAM /CE connected to GND...
I suggest Haruka try this circuit with the 74LS32 I posted on the previous post for creating specific /OE and /WE signals for the FRAM while having the FRAM /CE connected to GND...
- krzysiobal
- Posts: 1037
- Joined: Sun Jun 12, 2011 12:06 pm
- Location: Poland
- Contact:
Re: VRC-VI multicart
Me too, but all VRC6 PCBs have Mitsumi 1026B Battery Backup chip which is connected to the RAM+CE (RAM/CE is driven by VRC6)lidnariq wrote: I'm not clear what the 74'32 is doing in l_oliveira's original post; all SRAMs that I know of already support "/OE grounded" topology, and the VRC6 doesn't have a +CE output.
If you want to use 62256 and still make use of the additional battery backup feature, you can use 7432 and wire it as:
Code: Select all
VRC6./CE 1026B.+CE | 62256./CE
(deglitched) (pin 3) | (pin 20)
-----------------------+-----------
0 0 | 1
0 1 | 0
1 0 | 1
1 1 | 1
1026B pin 3-+-|---\
| |NOR )O----+---\ .-+---\
`-|---/ |NOR )O--+ |NOR )O--62256./CE
VRC6./CE-----------------+---/ `-+---/
Re: VRC-VI multicart
Someone on the gbdev Discord server ran into this when trying to adapt Game Boy RPG Game Paks' save chips to be "immortal." I don't recall exact details, as I myself am nowhere near needing extra RAM on that platform, but at least one of the enable signals had to pulse.l_oliveira wrote:Oh it just occurred me that FRAM may actually require /OE and /WE to pulse for it to pass through the rewrite cycles from read and write accesses.