nesdev.org

After a close study of the SNES schematics:

http://www.neviksti.com/w/images/6/6f/N ... p_left.png

I noticed that all three main SNES chips (CPU, PPU1, PPU2) have a pin which is suspiciously marked as HVCMODE. It seems to be active high, and is grounded on all SNES units.

As we all (hopefully) know, the Super Famicom has the Nintendo identity code SHVC.

This would of course imply that the HVCMODE pin, when set to a high level, could possibly switch the Super Famicom/SNES into Famicom mode.

Question: has anyone so far experimented with this? There are also lots of other mysterious pins on the chips which seem to indicate further functionality.

EDIT:

Other random facts while studying the schematics:

- The PPUs support 128K VRAM

- One PPU contains the address generation logic (providing addresses to the VRAM), the other contains the graphics buffers for background/sprite/colour logic (including the DAC for RGB output)(only data connection to VRAM). CHR3-0, PRIO1-0, COLOR2-0 is obviously the tile/sprite graphics data being transferred.

- The CPU has a pin called /DRAMMODE, which is tied low. I bet that if you set it high, you disable the refresh cycle logic and thus free some extra CPU time.

- PPU-2 has a 24 Bit data bus. On the SNES, bits 15-8 from VRAM are also connected to bits 23-16, marked EXT7-EXT0 on the PPU. What could this be? Famicom mode? Reason for direct colour mode (EXT7-0 are a direct R3G3B2 input to the DAC)?

- S-DSP has an unconnected address line (A15). 128K sound ram possible?

Yeah, I tried this once when the documents appeared, but didn't get very far.
I hooked up all HVCMODE-pins to a switch and wrote a small test-ROM.
What I did then was to boot in normal SHVC mode, fill VRAM & Palette with some crap, write to a couple of NES display & sound register adresses in a loop, then switch back and forth.
Also tried this while playing a couple of normal games.

The screen would go black upon switching to HVC mode, then continue exactly at the same spot when switching back to SHVC mode. No crashes at all.
My assumption is that either the PPU stops generating NMIs or the CPU is halted in HVC mode. I didn't check activity with my scope, probably should have done that...

Wasn't able to display any graphics at all in HVC mode IIRC.

128k VRAM would be soooo nice for double-buffered 8bpp fullscreen graphics, but I consider the modification too difficult to justify writing software that requires it. Apart from that, it feels like cheating to me.

d4s wrote:Yeah, I tried this once when the documents appeared, but didn't get very far.
I hooked up all HVCMODE-pins to a switch and wrote a small test-ROM.
What I did then was to boot in normal SHVC mode, fill VRAM & Palette with some crap, write to a couple of NES display & sound register adresses in a loop, then switch back and forth.
Also tried this while playing a couple of normal games.

The screen would go black upon switching to HVC mode, then continue exactly at the same spot when switching back to SHVC mode. No crashes at all.
My assumption is that either the PPU stops generating NMIs or the CPU is halted in HVC mode. I didn't check activity with my scope, probably should have done that...

Wasn't able to display any graphics at all in HVC mode IIRC.

Man, isn't there anything you didn't try?

Very interesting! I noticed that the 5A22 CPU has an external /NMI line which is connected to VCC. Maybe the CPU switches to this pin after HVCMODE is activated.

You could be right that the CPU might be halted when switched to HVC mode and that the PPU ignores Famicon register writes until the HVC pin is activated. Thus, the screen is not activated during the switch.

But the pins obviously do something. Maybe this scheme only works when other pins are correctly set up. On the CPU, there are also 2 mysterious pins named TCKSEL0 & TCKSEL1, both tied to ground. CPU clock mode select?

I also wonder, if the features were implemented fully, where would the sound come out?

Well as far I know the SNES was supposed to be backward compatible but they gave it up at some point in the development of the system.

128k VRAM sounds like it'd allow games to have better graphics, but the SNES already allows ridiculously better graphics than all other consoles of the same time. Since as far I know VRAM is organized as 32768 16-bit words of data, only 15 bits are used when adressing VRAM, so the use of the 16th bit sounds possible to me.

When it comes to sound, you got something wrong. The sound RAM is organized as 64k bytes (65535 bytes) so there should already be A0-A15 used. I belive the system was supposed to have only 32k bytes of sound memory but Nintendo decided to increase it to 64k right before the release of the console (because some "official" documents (that probably leaked form Nintendo) state it's 32k).

Bregalad wrote:Well as far I know the SNES was supposed to be backward compatible but they gave it up at some point in the development of the system.

The question is: how far did they come and what traces of this might still be left in the chipset? I mean, why is the pin still there on all 3 chips, clearly marked on the schematics? Why does it obviously do something, without crashing the system, when put high?

128k VRAM sounds like it'd allow games to have better graphics, but the SNES already allows ridiculously better graphics than all other consoles of the same time. Since as far I know VRAM is organized as 32768 16-bit words of data, only 15 bits are used when adressing VRAM, so the use of the 16th bit sounds possible to me.

I am pretty sure that if you use VA15 as a chip select for a second set of 2*32k SRAM chips, you'll get 128K VRAM. But, as d4s pointed out, the modification would be too complex to justify.

When it comes to sound, you got something wrong. The sound RAM is organized as 64k bytes (65535 bytes) so there should already be A0-A15 used. I belive the system was supposed to have only 32k bytes of sound memory but Nintendo decided to increase it to 64k right before the release of the console (because some "official" documents (that probably leaked form Nintendo) state it's 32k).

Look at the schematics, bottom left corner:

http://www.neviksti.com/w/images/9/99/N ... _right.png

There are 2 chip selects on the S-DSP (/CE0 & /CE1) which select the upper and lower 32K ram. But there is also an additional address pin (MA15) which is unconnected. Does it support 64K * 2 = 128K sound ram? But how would it be accessed, since the SPC700 only has a 16 Bit address bus.

The name of the HVCMODE pin could be a false indication of its functionality. If we take the November 1988 press conference into account (where they obviously had already functional hardware):

http://www.disgruntleddesigner.com/chri ... tml#sfcbon

The prototype Super Famicon realized Famicom compatibility through a very lame pass-through audio/video input and a separate Famicom console connected to it. Maybe the HVCMODE pin was connected to the Famicom switch on this prototype, causing the system to halt and pass the Famicom video output through?

That however wouldn't explain that the Famicom and Super Famicom memory map and register locations are quite familiar. The joypad registers are even at the same locations. It would absolutely make sense to map the Famicom PPU and CPU registers in this memory map at their familiar locations.

In all cases, it shows that the Super Famicom was somehow a cobbled-up design. The presence of the HVCMODE pin indicates to me that the Super Famicom chip design probably did not change much from the November 1988 prototype. In other words, they had fully working silicon 2 years before finally releasing the console.

I hope there is some magical pin that lets the PPU read from the CPU's address space. That would allow tons of amazing hardware tricks being done.

There is not, and can not be.

psycopathicteen wrote:I hope there is some magical pin that lets the PPU read from the CPU's address space. That would allow tons of amazing hardware tricks being done.

This would be completely impossible. The only data connection between the CPU and the PPU are an 8 bit address (PA7-0) and data bus (CD7-0), allowing the CPU access up to 256 PPU registers.

I seriously doubt that a unified memory architecture would have been a wise idea, since the PPU accesses video ram at 5.37 Mhz , which would have left no free memory cycles for the CPU during active display.

6502freak wrote:

psycopathicteen wrote:I hope there is some magical pin that lets the PPU read from the CPU's address space. That would allow tons of amazing hardware tricks being done.

This would sadly be completely impossible. The only data connection between the CPU and the PPU are an 8 bit address (PA7-0) and data bus (CD7-0), allowing the CPU access up to 256 PPU registers.

I seriously doubt that a unified memory architecture would have been a wise idea, since the PPU accesses video ram at 5.37 Mhz , which would have left no free memory cycles for the CPU during active display.

I find it a step backwards that Nintendo didn't connect the Super PPU to the cartridge like they did with the NES. There's no expandability!

psycopathicteen wrote: I find it a step backwards that Nintendo didn't connect the Super PPU to the cartridge like they did with the NES. There's no expandability!

This would have meant at least 34 additional pins to the cartridge connector. The chosen way to update graphics on the SNES was obviously flexible DMA, instead of static CHR bankswitching schemes. Super FX cartridges demonstrated quite efficiently how the architecture could be expanded externally this way (the DMA bus is available on the cartridge slot).

Makes perfect sense from a 1989/90 perspective.

6502freak wrote:

psycopathicteen wrote: I find it a step backwards that Nintendo didn't connect the Super PPU to the cartridge like they did with the NES. There's no expandability!

This would have meant at least 34 additional pins to the cartridge connector. The chosen way to update graphics on the SNES was obviously DMA, instead of CHR bankswitch. Super FX cartridges demonstrated quite efficiently how the architecture could be expanded externally this way (the DMA bus is available on the cartridge slot).

How fast is the DMA bus on the cartridge slot? I hope it's not limited to 2.68 Mhz like the DMA built into the CPU is.

psycopathicteen wrote: How fast is the DMA bus on the cartridge slot? I hope it's not limited to 2.68 Mhz like the DMA built into the CPU is.

It is indeed limited to 2.68 Mhz. But hey, that's 2.68MB/s! It was enough to make DOOM playable on the SNES. I wouldn't consider this a step backward. With a modern microcontroller and FPGA, you could build some interesting expansions using this bus.

6502freak wrote:

psycopathicteen wrote: How fast is the DMA bus on the cartridge slot? I hope it's not limited to 2.68 Mhz like the DMA built into the CPU is.

It is indeed limited to 2.68 Mhz. But hey, that's 2.68MB/s! It was enough to make DOOM playable on the SNES. I wouldn't consider this a step backward. With a modern microcontroller and FPGA, you could build some interesting expansions using this bus.

I guess it can be a little bit faster regarding the time it takes the cpu to set everything up, but not by that much.

128k VRAM would be soooo nice for double-buffered 8bpp fullscreen graphics, but I consider the modification too difficult to justify writing software that requires it. Apart from that, it feels like cheating to me.

My mind must be rotting already :(
You are right in that anything above 224x144 will exceed 32K of VRAM, and thus won't be double bufferable via TDADDR change. And even 224x144 doesn't have enough room left for a tilemap, so you'd need 224x132.

And yet, smkdan's S-DD1 MMC demo; runs at 240x160@30hz just fine.
http://byuusan.kuro-hitsuji.net/lunar.sfc

How in the hell did he do that, then?