128K/256K VRAM

[qwertymodo]

There is a hidden option is higan to enable the use of 128K VRAM, since the PPUs actually have an extra, unused address pin, which has been confirmed to work on real hardware. So, now we're at the point where we have the hardware, but can't really take advantage of it because there are no games that are even aware of it (and some, like Yoshi's Island which break entirely with it), so we need the tools to support development. It would be really nice if we could get support for this feature in bsnes+. It would require modifications to not only the PPU itself, but also the VRAM tools. I actually have a project in mind that could potentially benefit from the extra VRAM, so it would be really nice to have the ability to debug it.

The mod I linked actually supports using the full 256K available on the chips, but it does so in kind of a custom manner through the use of one of the CPU's unused PIO pins, so that might not be worth emulating, but 128K is fully supported by the stock hardware.

[devinacker]

I was actually thinking about this specific thing a few days ago when pondering the general concept of emulating more homebrew expansions / hardware mods as they're created.

Updating the VRAM tools would be easy enough, but it'd take a fair bit more time to rework (and test) VRAM accesses in the various PPU cores, so it'll probably wait until I make up my mind about whether or not I want to keep the performance core around.

(I almost wonder if "unused I/O pin behavior" should be a new option next to "expansion port device" for this sort of thing...)

[devinacker]

(obvious/gratuitous next step: using all six unused I/O pins to multiplex an entire 4 MB of VRAM...)

[devinacker]

I may try to do this soon, just as an experiment.

If I'm understanding the current mod(s) correctly:

• Setting $4201.0 low enables 128k (or rather, disables mirroring)
• Setting $4201.1 low switches 128k banks
  but I couldn't really tell if the two settings were supposed to work independently of each other (i.e. does bit 1 control one of the VRAM address lines all the time or only when the expansion is enabled via bit 0?)

Anyway, when I add this I may just do 128k at first, though I can certainly take it further if there's a consensus on how it's supposed to operate.

[qwertymodo]

[J] sent me a couple of the RAM expansion PCB's, and looking at them (but without probing because I'm lazy), I'm 99% sure that $4201.0 acts as an active-low enable for the 128K mode, and that when it is high, the RAM reverts to the lowest 64K block, regardless of the state of $4201.1.

In other words:

VRAM_A16 = PPU1_A16 & !CPU_19
VRAM_A17 = CPU_20 & !CPU_19

[devinacker]

Alright, makes sense to me. Any good test cases for at least the 128k mode (but preferably also 256k)?

[qwertymodo]

Here's a patch for Mega Man X that uses 128K mode: https://www.mediafire.com/?aokk8ly2ba1ez5c

[devinacker]

Okay, the vramexpand branch (based on the qt5 branch) has an experimental VRAM expansion setting in the "advanced" config tab for the accuracy core only. Haven't tested the full 256kb option yet.

(That MMX patch doesn't write $4201 to enable the expansion, so you'll have to change the byte at 0x3005A in the ROM to FE or FC for it to be able to actually access the expanded VRAM properly with this branch.)

[slidelljohn]

This is [J] I also go by slidelljohn. If there is anything that I can do to help get this implemented into bsnes plus I am more than willing to help. I still have more of the mod chips that I am willing to give away for free and I even have a test console that I could also give away if it’s needed to get this properly implemented in bsnes plus. Using the unused cpu I/O pins wasn’t necessary for adding 128 kB of vram but it was necessary to get games like yoshi’s island to work properly. Cpu pin 19 goes through a not gate then after that cpu pin 19 and ppu1 pin 46 go through a and gate to get 128 kB of vram. Cpu pin 20 also goes through a not gate but nothing else. For cpu pin 19, 0 = 128 kb, 1 = 64 kb. For cpu pin 20, 0 = 2nd 128 kb of vram, 1 = 1st 128 kb of vram. Even though my mod chip uses the full 256kb of ram that is on it you can only use 128kb of vram total at a time. The snes is not capable of using over 128kb of vram at a time. The extra 128kb of vram is really only useful for preloading data to it and being able to switch between the 1st 128kb of vram and the 2nd 128kb of vram. What I would probably do for setting up bsnes for using the extra vram is have a button or checkbox that enables/disables the 128kb vram so it would act exactly like real hardware and if you wanted to, have another feature that uses the cpu I/O for various different things like vram greater than 128kb. The cpu I/O pins could be totally left because the snes wasn’t actually designed for anything above 128kb of vram but it was definitely designed for 128kb of vram. If this does get implemented into bsnes is there any chance of using the name of my 128kb of vram mod chip for this. I called the mod chip Super V-Power. V stands for vram. On the back of the chip it says now you’re playing with power Super V-Power!

My mmx hack only uses the 128kb of vram but I could create another mmx test rom that uses the 256kb of vram. I was working on a mmx 256kb vram hack that loaded the in game menu data into the second 128kb of vram and this greatly increased the speed of going into and exiting the menu. I’m not sure if I finished that test rom but I can check. I did modify the nSide debugger to support debugging 128kb of vram. The download link for the modified debugger is on byuu’s forum in the page I created that shows the development of this modchip.

I probably wouldn’t use all of the unused I/O pins on the cpu to give it 4 MB of vram because we could still use those pins for other projects. I do have one project in mind for using one of those unused I/O pins. There is a pin on the cartridge connector that supposedly only goes to the expansion port under the snes console and since that isn’t really used today except by very few people it could be tied to one of the unused I/O pins to give extra sram or rom space to a newly designed snes pcb cart. I’m not sure how that would work but it was something that I was thinking about trying.

Since byuu’s forum is no longer here I decided anything new that I create for the extra vram mod chip will be on my project page on romhacking.net. Here is the link to my page:
https://www.romhacking.net/forum/index.php?topic=27609.0

devinacker if you get this working in bsnes plus please let us know about it on my romhacking.net page. And if you need any help with anything just let me know and I’ll do my best to try and help you out.

qwertymodo I’m interested in the project that you have in mind for 128 kb of vram maybe you can give us some details on it on my page on romhacking.net. It would be nice to get the 128 kb vram going on the snes hacking scene. If we can get this going maybe Analogue would consider adding this feature to their Super NT.

[devinacker]

Like I mentioned in my previous post, I actually pushed a feature branch a little while before you posted that, though it only makes the expansion available in accuracy builds at the moment. Here's what the addition to the config dialog looks like:

Right now it doesn't invert pin 20, but it shouldn't really matter as long as it switches 128kb banks like it's supposed to. I still haven't tried doing anything with the full 256kb yet, though.

[slidelljohn]

My pc setting were all messed up so I had some trouble compiling it at first but I got it working now. This is really going to help get things going with extra vram hacks. I really appreciate you getting this implemented in bsnes plus.

Is it ok for me to post a compiled version of the bsnes expanded vram on my romhacking.net page?

[devinacker]

Sure, feel free to post a build if you like.

[slidelljohn]

I posted the build on my projects page. I played around with the source code and posted a build of some modifications that I made as well. You should check it out because I think you might like some of the stuff that I did. I edited some stuff in the tile viewer, I added a option to choose what debugging screens get displayed at start up, and I added a multi threaded, multi buffer near lag free cpu tracer.
If you like any of these changes that I made you can have the source for it. I definitely wouldn't mind contributing to the source.

[devinacker]

Updated vramexpand dev build based on the current master branch: https://ci.appveyor.com/project/devinacker/bsnes-plus/branch/vramexpand/artifacts

I'd like to probably merge this into master soon, though right now it is still only supported for accuracy builds.

As of right now, other builds shouldn't have any performance difference; if SNES::PPU::SupportsVRAMExpansion is false then accesses to the VRAM object should basically be optimized into regular array reads.

I recently got rid of the performance PPU in master so that both non-accuracy builds use the compatibility PPU, but I might allow the compatibility PPU to support expanded VRAM only when building the compatibility profile.

Either way, it's not a huge performance impact and there would still be a pretty drastic speed difference between all three profiles regardless, so I'm leaning towards doing that in order to make this available in the compatibility builds as well.

(e: still need to update the VRAM viewer and other related debug tools to actually recognize the larger VRAM size, but I'll do that soon)

[devinacker]

Pushed another update which should properly handle VRAM expansion settings in all relevant debug views. (The Tile Viewer only shows whichever 128k bank is currently actually visible to the PPU, but all displayed addresses should account for the currently selected bank no matter what.)

Also, I'm now properly inverting the highest VRAM address bit to match the actual hardware mod behavior.

The only thing I think I need to do now before merging this into master is to determine if I want to allow this to be supported in the compatibility and possibly also the performance profile, since this does carry a bit of a performance impact for all VRAM accesses. It's not a huge difference, so I'm considering enabling it only for the compatibility/balanced profile, but I'm not sure yet.

[devinacker]

VRAM expansion support is now merged in master, still for accuracy builds only. I'd still like to consider enabling it for at least one of the other profiles, but I'm pretty satisfied with it for now until it starts getting more usage.