VRC-VI multicart

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderator: Moderators

User avatar
l_oliveira
Posts: 409
Joined: Wed Jul 13, 2011 6:51 am
Location: Brasilia, Brazil

Re: VRC-VI multicart

Post by l_oliveira »

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.
Attachments
Akumajou Densetsu mapper26_(J).ips
Converts Akumajou Densetsu for the Madara/Esper Dream2 board type.
(235 Bytes) Downloaded 376 times
zansatsu0
Posts: 15
Joined: Tue Sep 06, 2016 9:52 am

Re: VRC-VI multicart

Post by zansatsu0 »

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:
rom_short.png
rom_short.png (1.51 KiB) Viewed 10288 times
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):
Image

Thank you all in advance for reading and I apologize if this is slightly off topic.
User avatar
l_oliveira
Posts: 409
Joined: Wed Jul 13, 2011 6:51 am
Location: Brasilia, Brazil

Re: VRC-VI multicart

Post by l_oliveira »

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.
zansatsu0
Posts: 15
Joined: Tue Sep 06, 2016 9:52 am

Re: VRC-VI multicart

Post by zansatsu0 »

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.
Thanks for the info! I used AcidPhire NES Header Checker and was able to split the ROM successfully.

I'm still relatively new to repros and translations so this part went right over my head:
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'm not sure how to achieve this. I have already attempted very ugly piggybacks and that was lesson in Frankenstein soldering. :shock:

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!
User avatar
l_oliveira
Posts: 409
Joined: Wed Jul 13, 2011 6:51 am
Location: Brasilia, Brazil

Re: VRC-VI multicart

Post by l_oliveira »

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.
zansatsu0
Posts: 15
Joined: Tue Sep 06, 2016 9:52 am

Re: VRC-VI multicart

Post by zansatsu0 »

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.
You sir, just made something click. For some reason, I thought it was way more complicated than that.

A19 Low = First Half
A19 High = Second Half

Excellent! Thank you very much for explaining that!
Haruka
Posts: 53
Joined: Fri Mar 23, 2018 8:58 pm

Re: VRC-VI multicart

Post by Haruka »

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:

Code: Select all

VRC6 pin16 ---+---|>|---+--- WRAM /CE
              |         |
              +---1K----+
                        |
                       82p
                        |
                       GND
What the hell is it? How does this supposed to work?
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: VRC-VI multicart

Post by lidnariq »

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.
Haruka
Posts: 53
Joined: Fri Mar 23, 2018 8:58 pm

Re: VRC-VI multicart

Post by Haruka »

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)
This glitch only affects writing to PRG RAM, right?
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.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: VRC-VI multicart

Post by lidnariq »

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?
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.
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.
No, that won't be a bus conflict. The VRC6 itself is only going to assert /PRGRAMCE or /PRGROMCE, never both.

I don't suppose you have access to an oscilloscope?
Haruka
Posts: 53
Joined: Fri Mar 23, 2018 8:58 pm

Re: VRC-VI multicart

Post by Haruka »

No, that won't be a bus conflict. The VRC6 itself is only going to assert /PRGRAMCE or /PRGROMCE, never both.
What if the 82p cap was short-circuit? That would explain why disabling FRAM does make the game booting fine while otherwise don't.
I don't suppose you have access to an oscilloscope?
Nope. Neither do I have a logic analyzer nor multi-meter...
User avatar
l_oliveira
Posts: 409
Joined: Wed Jul 13, 2011 6:51 am
Location: Brasilia, Brazil

Re: VRC-VI multicart

Post by l_oliveira »

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.
VRC6_32KWRAM.PNG
VRC6_32KWRAM.PNG (7.38 KiB) Viewed 8566 times
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.
User avatar
l_oliveira
Posts: 409
Joined: Wed Jul 13, 2011 6:51 am
Location: Brasilia, Brazil

Re: VRC-VI multicart

Post by l_oliveira »

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...
User avatar
krzysiobal
Posts: 1037
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland
Contact:

Re: VRC-VI multicart

Post by krzysiobal »

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.
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)

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-----------------+---/    `-+---/
Just don't forget to supply 7432 from the battery aswell and use CMOS variant (74HC/74HCT), not the TTL (LS/F)
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: VRC-VI multicart

Post by tepples »

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.
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.
Post Reply