Page 2 of 3

Re: VS Daughterboard compatible to their NES mapper counterp

Posted: Mon Sep 12, 2016 9:19 am
by lupin3rd
lidnariq wrote:I think I'm asking specifically about the headers that pass through to the system.

If the whole thing is a sandwich with these layers:

PPU
socket
daughterboard
pins
mainboard

this would need to interpose between the daughterboard and the mainboard ... but if the socket and pins are one and the same, the only way I can think of to do this would be to add another set of sockets between the pins and the mainboard.
Ah, now I understand. Yes, that is exactly how the board is setup. I believe the sockets have really long pins on them, so they are soldered to the daughterboard, but pass through to the main board.

Re: VS Daughterboard compatible to their NES mapper counterp

Posted: Mon Sep 12, 2016 12:14 pm
by lidnariq
Well, you could try getting three 40-pin sockets -- either milled or stamped -- and breaking or otherwise removing only one of either PPU A10 or PPU A11.

Put the unmodified one in the CPU socket, and put the one missing PPU A10 or PPU A11 in the PPU socket according to the mirroring the game needs. (Contra should need the one missing PPU A11). Then put the daughterboard in the new sockets.

Mind, this leaves that pin floating, which isn't the best idea, so you might want to additionally add a jumper in one of the CHR ROM sockets from the now-floating pin to either ground or +5V.

Re: VS Daughterboard compatible to their NES mapper counterp

Posted: Tue Sep 13, 2016 6:02 pm
by lupin3rd
Got excited when I realized that I have a bunch of cheapo 40-pin sockets laying around... Folded pin 27 (A11) out of the way, and booted it up. It ain't perfect, but it's a step in the right direction! Disclaimer: I did not ground or tie the pin to +5V yet, do you think that might clear up what's in this video?

Re: VS Daughterboard compatible to their NES mapper counterp

Posted: Tue Sep 13, 2016 6:14 pm
by Dwedit
A11 for the nametables only, not for the CHR RAM, correct?

Doesn't VS system also have some mode to use more CHR data than a usual NES game? Wonder if that would be triggered here?

Re: VS Daughterboard compatible to their NES mapper counterp

Posted: Tue Sep 13, 2016 6:16 pm
by lupin3rd
Dwedit wrote:A11 for the nametables only, not for the CHR RAM, correct?
Correct; I did it in a way that would be like unplugging A11 from the PPU.

Re: VS Daughterboard compatible to their NES mapper counterp

Posted: Tue Sep 13, 2016 7:51 pm
by lidnariq
lupin3rd wrote:It ain't perfect, but it's a step in the right direction! Disclaimer: I did not ground or tie the pin to +5V yet, do you think that might clear up what's in this video?
Part of it could be, but the sprites would not be caused by that. That behavior's just wrong.

I suppose another possibility is, since the NTRAM is also socketed (that Toshiba RAM in 2C/8C), you could get a 28-pin socket and do the same trick with pulling out PPU A10/A11 from that.
Dwedit wrote:Doesn't VS system also have some mode to use more CHR data than a usual NES game? Wonder if that would be triggered here?
Yes, but no. This is on the UNROM-like daughterboard, which doesn't use the M99 CHR banking.

Re: VS Daughterboard compatible to their NES mapper counterp

Posted: Wed Sep 14, 2016 2:14 pm
by lupin3rd
lidnariq wrote:
lupin3rd wrote:It ain't perfect, but it's a step in the right direction! Disclaimer: I did not ground or tie the pin to +5V yet, do you think that might clear up what's in this video?
Part of it could be, but the sprites would not be caused by that. That behavior's just wrong.
In the video, to me anyway, it looks like some crazy stuff is happening during the drawing of the screen. Like, the game is writing graphical data to the PPU outside of the VBLANK cycle. I want to be wrong about that.

Can anyone explain the purpose of mirroring to me? I mean, is it used for double-buffering type purposes -- where one screen is drawn, while the other section of memory is being written to? And then it flips on the next frame?
lidnariq wrote:I suppose another possibility is, since the NTRAM is also socketed (that Toshiba RAM in 2C/8C), you could get a 28-pin socket and do the same trick with pulling out PPU A10/A11 from that.
Mine isn't socketed. I can fix that, though. I wish there was another test I could try to see if the behavior changes.
lidnariq wrote:
Dwedit wrote:Doesn't VS system also have some mode to use more CHR data than a usual NES game? Wonder if that would be triggered here?
Yes, but no. This is on the UNROM-like daughterboard, which doesn't use the M99 CHR banking.
Is VS Gumshoe the game that used that method? I know there was a service release about modifying the board to be able to do it; did any other games get released that used it?

Re: VS Daughterboard compatible to their NES mapper counterp

Posted: Wed Sep 14, 2016 2:38 pm
by lidnariq
lupin3rd wrote:Can anyone explain the purpose of mirroring to me?
Cost-cutting.

Honestly, that Nintendo managed to find a 4K RAM for the Vs. System at all is kinda surprising.
Is VS Gumshoe the game that used that method? I know there was a service release about modifying the board to be able to do it; did any other games get released that used it?
m99 CHR banking was used by all games that came as 6 ROMs (well, specifically any game that had two ROMs for sockets 2A/2B or 8A/8B)

Vs. Gumshoe did something a little weirder, and used that same control to also control one of the address lines (A13) on socket 1D or 6D.

Re: VS Daughterboard compatible to their NES mapper counterp

Posted: Wed Sep 14, 2016 2:48 pm
by Myask
lupin3rd wrote: Can anyone explain the purpose of mirroring to me? I mean, is it used for double-buffering type purposes -- where one screen is drawn, while the other section of memory is being written to? And then it flips on the next frame?
Mirroring in the NES is basically because the VRAM doesn't have room for the four pattern tables that they decided to address [because doubling the on-system VRAM wouldhave been incredibly expensive at the time (beaten by: lidnariq), but still to allow for cartridge-based expansion for those who would spend]. Really, it's "how do we connect A10 of console VRAM? [when] Do we use the console-supplied 2KiB VRAM?"

One can use one-screen patterns to double-buffer, yes--then it's basically bankswitching the VRAM.
The two-screen size of [NES] VRAM means one can have scrolling buffer OR have a complete separate screen to buffer.

We have a rather excellent graphic on the wiki showing how basic sidescrolling works.

I hope that's not confusing.

Re: VS Daughterboard compatible to their NES mapper counterp

Posted: Sat Sep 17, 2016 10:02 pm
by lupin3rd
Myask wrote:Mirroring in the NES is basically because the VRAM doesn't have room for the four pattern tables that they decided to address [because doubling the on-system VRAM would have been incredibly expensive at the time (beaten by: lidnariq), but still to allow for cartridge-based expansion for those who would spend]. Really, it's "how do we connect A10 of console VRAM? [when] Do we use the console-supplied 2KiB VRAM?"
I think I'm understanding a bit more about that now. On the console, you have the convenience of connecting to more RAM supplied by a cart, or other features (mappers, SRAM, backups, etc.). Thanks!
I saw that image! It is indeed helpful, especially due to the circular nature of wrapping the scrolling buffer back around to the start. :)

Okay, so this project is starting to wear me out. I feel like there is a simple-ish solution within reach, but I'm overlooking it. What about this idea...

Making a CPU/PPU daughterboard, but instead of modifying NES ROMs to burn and play on it, do you think I'd get better mileage out of adding an edge connector to plug the original cart in, but then tying the necessary CPU/PPU pins to the cart's edge connector?

In essence, wouldn't I be recreating the same interface that the NES uses to talk to games? I think the only necessary modification using this approach would be using a socket to intercept a few of the address lines, as the VS is by default hardwired to more RAM, so to downgrade it, shouldn't I just be able to tie those extra addressing pins to the connector and plug the cart in?

Re: VS Daughterboard compatible to their NES mapper counterp

Posted: Sat Sep 17, 2016 10:48 pm
by lidnariq
lupin3rd wrote:Making a CPU/PPU daughterboard, but instead of modifying NES ROMs to burn and play on it, do you think I'd get better mileage out of adding an edge connector to plug the original cart in, but then tying the necessary CPU/PPU pins to the cart's edge connector?
That would make sense for future ease-of-use, but there's still the need to interpose between the PPU and the NT RAM.

Plus, the Vs. System is incompatible with any games that add their own RAM for the CPU. Might still be worth it, though.
so to downgrade it, shouldn't I just be able to tie those extra addressing pins to the connector and plug the cart in?
Yeah, theoretically. That's what the sockets you added should have been doing... but why it caused corruption on sprites is just confusing.

Comparing the behavior in your video to the behavior in FCEUX, ... it kinda looks like the connection between PPU A11 and the RAM on the daughterboard maybe being interfered with? All of the tiles that are "good" on the title screen come from the upper half (tiles where PPU A11 is +5V), and all the wrong tiles of the title screen are replaced by the tile where PPU A11 was high instead. (You'll note that the lower half of the "CONTRA" is mostly intact, but the upper half and all of the places that would be text are instead bits of the stylized protagonists:
contra-title-screen-fceux-ppu-viewer.png
contra-title-screen-fceux-ppu-viewer.png (5.23 KiB) Viewed 3440 times
Contra on Nintendo VS System-I1cCh12hHIg-18.275sX.jpg
Contra on Nintendo VS System-I1cCh12hHIg-18.275sX.jpg (17.74 KiB) Viewed 3440 times
Similarly, the tile that's supposed to contain the stars in the background ($4F) is replaced with the pattern for tile $CF...

Did folding the pin over in the socket actually keep it from making contact?

Re: VS Daughterboard compatible to their NES mapper counterp

Posted: Sun Sep 18, 2016 12:38 am
by lupin3rd
lidnariq wrote:Did folding the pin over in the socket actually keep it from making contact?
Yes. There should have been no connection there. The socket that normally holds the PPU is plastic and is the type that has no metal near the entry hole. So the pin that was folded out of the way, was flat over the top of a plastic socket, no metal touching! :)

Re: VS Daughterboard compatible to their NES mapper counterp

Posted: Sun Sep 18, 2016 12:48 am
by lidnariq
Just for paranoia's sake, does the title screen work correctly if you get rid of the sockets? (Like it did in the first place)

Re: VS Daughterboard compatible to their NES mapper counterp

Posted: Sun Sep 18, 2016 8:32 am
by lupin3rd
lidnariq wrote:Just for paranoia's sake, does the title screen work correctly if you get rid of the sockets? (Like it did in the first place)
Yes. As soon as I put it all back with all pins connected, title screen looks good, the black screen showing the score and number of lives looks good, and then the game starts and we're back to square one, with incorrect tiles everywhere.

Re: VS Daughterboard compatible to their NES mapper counterp

Posted: Sun Sep 18, 2016 8:45 am
by Dwedit
So in other words, you disconnected PPU A11 for everything and not just nametables, just as I suspected above.
PPU memory map:
0000-1FFF: CHR-RAM
2000-2FFF: Nametables (full 4K)
To get vertical mirroring, we want to have it disable the bottom set of nametables (2800-2FFF) without messing with CHR-RAM.

NES Cartridges have pins that go back to the address selection for the internal nametable memory, and can be controlled by the wiring on the board, or by a mapper, or even let the cartridge host the full 4K of nametables.

But if there is no such thing there, I guess you'd need to do 'A11 = (NOT A13) AND A11.'