HVCMODE Pin??? - NESdev BBS

HVCMODE Pin???
by 6502freak on 2010-06-07 (#62572)

After a close study of the SNES schematics:

http://www.neviksti.com/w/images/6/6f/NTSC_ver2_top_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?

by d4s on 2010-06-07 (#62578)

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.

by 6502freak on 2010-06-07 (#62579)

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?

by Bregalad on 2010-06-07 (#62580)

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

by 6502freak on 2010-06-07 (#62581)

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?

Quote:
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.

Quote:
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/NTSC_ver2_bottom_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.

by 6502freak on 2010-06-07 (#62583)

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/chrisc/secret/SFC_1988Q4.html#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.

by psycopathicteen on 2010-06-07 (#62590)

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.

by ReaperSMS on 2010-06-07 (#62591)

There is not, and can not be.

by 6502freak on 2010-06-07 (#62592)

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.

by psycopathicteen on 2010-06-07 (#62593)

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!

by 6502freak on 2010-06-07 (#62595)

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.

by psycopathicteen on 2010-06-07 (#62596)

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.

by 6502freak on 2010-06-07 (#62598)

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.

by psycopathicteen on 2010-06-07 (#62600)

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.

by byuu on 2010-06-07 (#62617)

Quote:
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?

by tomaitheous on 2010-06-08 (#62623)

Quote:
Super FX cartridges demonstrated quite efficiently how the architecture could be expanded externally this way (the DMA bus is available on the cartridge slot).

Games like StarFox ran in 4bit tile mode to keep the bandwidth down, IIRC. I wouldn't say 'efficiently' and compared to what a cart mapped area could do, it makes the SNES approach more like a barely adequate after thought.

Quote:
Makes perfect sense from a 1989/90 perspective.

Then the famicom was way ahead of its time. It could swap out banks faster than the 32bit generation could transfer memory. I can just imagine what the SNES could have achieved with a setup like that. Hell, it doesn't have to be a whole 64k bank system. Just a mode where there's enough address lines to the cart, to take care of a single line of video/pixels. The hardware on the cart side can cycle though/map the next line based on some sync system. Easy peesy pumpkin pie.

by smkd on 2010-06-08 (#62629)

cool thread.

The 128K VRAM capacity explains those unused upper bits from the registers that select where tiles/tilemaps are, but there doesn't seem to be anything obvious for how the DSP would access 128K samples.

Would've been nice if the SPC had it's own little bank of memory to itself and the DSP had a full 64KB. An 8KB or 32KB chip dedicated or something. Games still looked great with 64KB VRAM but the ARAM constraint was awful for sample quality. Felt wasted having a DSP that good with a tiny bit of RAM attached. AAA developers did fine but so many SNES soundtracks have aged so poorly with horrible playback quality.

@cart discussion: it seems much easier to justify the cheaper 'PRG only' cart with a generous amount of RAM in the system (compression being much more feasible) and DMA.

@byuu: It has to write to tiles currently being used on screen due to lack of room, but it only does that on the same frame that the buffers are swapped so no glitches are visible.

by 6502freak on 2010-06-08 (#62631)

tomaitheous wrote:
Games like StarFox ran in 4bit tile mode to keep the bandwidth down, IIRC.

Games like Doom on the other hand run pretty well in 256 colours. The DMA scheme is fast enough to let an outside controller render graphics in the VRAM of the PPU at acceptable frame rates. On NTSC, 256x150 graphics in 256 colours and constant 30 fps is absolutely possible. On PAL, this figure could be even higher (though I would not develop a game which only runs on one TV system).

Besides, 4bpp is higly misleading, because you can (if we take HDMA, colour math and sprites out, though they make great status displays) still use up to 121 colours using subpalettes, without putting much additional strain on the bus.

Quote:
I wouldn't say 'efficiently' and compared to what a cart mapped area could do, it makes the SNES approach more like a barely adequate after thought.

CHR banking may have been good for swapping tiles in-and out (Neo Geo style), but would have been way more expensive on the other hand. For Nintendo (more cart lines, at least 2 ROM chips in cartridge) and the game developer (storing UNCOMPRESSED graphics in expensive mask roms). This is NOT efficient.

DMA on the other hand, may be used for purposes far beyond graphics transfer. I think it's a much more elegant design than then NES custom mapper chaos.

Letting ANY device respond quick enough to address bus B enables the CPU to write its data ANYWHERE it wants. Or vice versa. This is quite flexible, elegant and powerful, allowing some interesting configurations.

Quote:
Then the famicom was way ahead of its time. It could swap out banks faster than the 32bit generation could transfer memory.

I think this figure is a misrepresentation of the situation.

Because in the end, bankswitching is mainly another method of flipping address lines. Every time you do a JMP (or JML) with the CPU, you use the CPU's own bankswitching. Every time you change a sprite pattern, you use the PPU's own bankswitching. Every time I set a new VRAM address pointer in the PSX , I'm using its bankswitching.

In the end, it comes down to the amount of memory available a given to a system. A NES game with 512K CHR ROM would, by that logic, compare favourably to a SNES game using 64K VRAM.

Quote:
I can just imagine what the SNES could have achieved with a setup like that.

Yes, we can all construct our favourite SNES setup from a 2010 perspective, where ROM/RAM and processing speed is dirt cheap. This is not the case in 1990. 2.68 Mhz is really fast, considering that CD-ROMS and harddisks from that era were hardly pushing 150KB/s - 1MB/s.

Given the DMA bus of the SNES, you could construct a pretty impressive video playback device without too much effort, using DMA to stream data from SD-cart. You could also stream data directly to the SPC700.

Quote:
Hell, it doesn't have to be a whole 64k bank system. Just a mode where there's enough address lines to the cart, to take care of a single line of video/pixels.
The hardware on the cart side can cycle though/map the next line based on some sync system. Easy peesy pumpkin pie.

This mehod is way more complex than a simple register driven DMA scheme, because it requires strict synchronization with the PPU (more cart lines, heck, why not put every single chip pin on the cartridge slot?). How are you going to synchronize a mass storage device (you don't want to store big videos and animations in ROM, do you?), with flexible access times, to the memory fetch scheme of the PPU? Or a different CPU, like the SuperFX?

Putting the PPU address and data bus on the cart line, and cutting the DMA bus, would have been a big mistake by Nintendo. Games like StarFox and Doom would not have been possible with 1993/94 technology. Doing otherwise would have meant going the Sega 32X route.

Noadays of course, with FPGA's, lots of (dual port) RAM and powerful microcontrollers: yes, you could practically bypass the whole SNES rendering scheme with it. Nintendo should have anticipated that in 1990.

by byuu on 2010-06-08 (#62636)

Quote:
@byuu: It has to write to tiles currently being used on screen due to lack of room, but it only does that on the same frame that the buffers are swapped so no glitches are visible.

That's what I was thinking at first, but there doesn't seem to be enough time ... you can't write while the frame is active, so that's 262-160 = 102 scanlines * 1324 / 8 = 16881 bytes possible to transfer during Vblank+Forceblank combined. You'd need to transfer 38400 bytes to avoid any tearing, right?

EDIT: I see, use 'bankswitching' via TDADDR for most of the buffering, and draw onto the rest during Vblank/Forceblank. It looks like you are limited to 20fps at 240x160 in NTSC mode, though.

262-160=102 scanlines*1324/8=16881 bytes per frame, or 0x41f1 bytes.
Bankswap range is in 0x2000 increments.
240*160=38400 or 0x9600 bytes.
So draw 0000-95ff for your first frame all during Vblank to start you off. Now start alternating with:
- draw a000-cfff on frame 1
- draw d000-ffff on frame 2
- draw 0000-35ff on frame 3 and swap TDADDR from 0000 to a000
Invert the process for the next frame.

So it looks like I'd need to decrease the resolution to something like 240x144 for 30fps on NTSC, meh.

And find room in there for the tilemap.

by smkd on 2010-06-08 (#62639)

yeah I missed the '30hz' bit of your post. Both CT and lunar.sfc are 20hz.

by tepples on 2010-06-08 (#62640)

6502freak wrote:
On NTSC, 256x150 graphics in 256 colours and constant 30 fps is absolutely possible. On PAL, this figure could be even higher (though I would not develop a game which only runs on one TV system).

Then render 256x144 in NTSC and 256x176 in PAL. If you have an external renderer capable of texture mapping, it should be able to correct for the pixel aspect ratio difference.

Quote:
Besides, 4bpp is higly misleading, because you can (if we take HDMA, colour math and sprites out, though they make great status displays) still use up to 121 colours using subpalettes, without putting much additional strain on the bus.

But then the external renderer has to build a set of subpalettes and determine which subpalette best represents each 8x8 pixel area.

by 6502freak on 2010-06-08 (#62642)

tepples wrote:
But then the external renderer has to build a set of subpalettes and determine which subpalette best represents each 8x8 pixel area.

Yes, but at least it would be an option to decide whether VRAM transfer bandwidth or additional computations for the external CPU would the more limiting factor.

If I had to decide between smooth and fullscreen video playback using 4bpp tiles/subpalettes and less smooth, smaller video playback using 8bpp, I would clearly go for the 4bpp variant.

Colour math could be used to construct a mode between 4bpp and 8bpp. Like: use 4bpp tiles to store brightness and overlay it with 2bpp tiles for colour. Or just calculate a global 64 colour palette as a result of colour math between 4bpp and 2bpp layer, and use it. That would save 25% bandwidth compared to 8bpp.

If we use pre-calculated tiles for the 2bpp layer (like single colour hues for an 8x8 block), one could save even more, and it could even be more colourful than 8bpp. This would almost be like YUV quantization used in JPEG encoding. You would be surprised how much the human eye sucks at perceiving hues.

The more I think about it, the more I really like this idea...

by psycopathicteen on 2010-06-08 (#62654)

Quote:
Games like Doom on the other hand run pretty well in 256 colours. The DMA scheme is fast enough to let an outside controller render graphics in the VRAM of the PPU at acceptable frame rates. On NTSC, 256x150 graphics in 256 colours and constant 30 fps is absolutely possible. On PAL, this figure could be even higher (though I would not develop a game which only runs on one TV system).

Besides, 4bpp is higly misleading, because you can (if we take HDMA, colour math and sprites out, though they make great status displays) still use up to 121 colours using subpalettes, without putting much additional strain on the bus.

But you can do full screen with a PPU bus.

Quote:
CHR banking may have been good for swapping tiles in-and out (Neo Geo style), but would have been way more expensive on the other hand. For Nintendo (more cart lines, at least 2 ROM chips in cartridge) and the game developer (storing UNCOMPRESSED graphics in expensive mask roms). This is NOT efficient.

Just because there are pinouts from the PPU to the cart doesn't mean it have to use CHR ROM. Carts could be used to support expansion V-RAM or enhancement chips. That's not to say that the system can't have both the V-RAM/DMA combo and a PPU bus at the same time.[/quote]

by ReaperSMS on 2010-06-08 (#62657)

A full PPU bus would have meant another 50 or so pins on the cart connector, and at least 3 more chips, since the PPU has two mostly independent memory busses.

If they were ever considering a switched rom, they would have had to toss mode-7.

by psycopathicteen on 2010-06-08 (#62662)

ReaperSMS wrote:
A full PPU bus would have meant another 50 or so pins on the cart connector, and at least 3 more chips, since the PPU has two mostly independent memory busses.

If they were ever considering a switched rom, they would have had to toss mode-7.

Have the first 64 KB V-RAM and the second 64 KB cartridge, and only allow Mode-7 to be run from the first 64 KB.

by 6502freak on 2010-06-08 (#62663)

ReaperSMS wrote:
If they were ever considering a switched rom, they would have had to toss mode-7.

YES, correct, I forgot about that! Because the PPUs don't have one, but two separate address buses for each SRAM chip. Without 2 address buses, there is no Mode 7.

I think the WHAT IF THE SNES HAD BLABLA discussion here isn't particularly interesting any more, because in the end, the hardware is what it is, and the communication mechanism for external hardware is register driven DMA. Anyone not agreeing can look at the schematics, wire some obscure high density connector to all necessary signals on the mainboard, and make their personal "what if I had been a hardware designer at Nintendo" SNES.

Instead, we should concentrate on the 6bit, compressed colour mode, and why no one did come up with that idea yet!

Perhaps I'm going to try making a test rom to see if the following could be useable:

MODE 1, using one 4bpp and one 2bpp BG.

Palette entries for the 4bpp layer is 16 colour greyscale, to encode the brightness of the picture. This layer is full 256x224, taking 28672 bytes.

Palette entries for the 2bpp layer is a 12 colour gradient between RGB. Replicate this gradient with 4 different intensities, and we have 96 different hues. Store 3 different 2bpp tiles to use all 96 hues with BG2 in 8x8 blocks. This layer takes 2*896 = 1792 bytes.

Activate colour subtraction between BG1 and BG2. A compressed 256x224 picture with up to 96*15+1 = 1441 colours needs a transfer size of 30208 bytes.

You may think that 8x8 colour blocks may look ugly, but a fact is that the human eye is very forgiving when it comes to the perception of colour. The most important aspect is that the brightness is full 256x224.

When I have some time left, I'm going to test if this compression scheme is a valid approach.

by tomaitheous on 2010-06-08 (#62667)

Quote:
You may think that 8x8 colour blocks may look ugly, but a fact is that the human eye is very forgiving when it comes to the perception of colour.

And that means what, exactly? Have you every written an automatic converter? I have and it's a pain in the ass to deal the errors and perceived artifacts for sub a single plane system. And it's slooooow, not real time. So it's not practical in a real world solution without having some serious ugly artifacts or sticking with a single 16(15) color palettes and treating it a single 4bit bitmap. SegaCD has many examples of rendering to 4bpp subpalette plane system. I think you'll find a common fact is that the pseudo bitmap for the vram is left/treated as straight 4bpp and one 16(15) color palette.

Quote:
Yes, we can all construct our favourite SNES setup from a 2010 perspective, where ROM/RAM and processing speed is dirt cheap. This is not the case in 1990. 2.68 Mhz is really fast, considering that CD-ROMS and harddisks from that era were hardly pushing 150KB/s - 1MB/s.

2.68mhz is really fast for 1990? Yeah, maybe if the only thing you ever code were old 8bit computers or the SNES. Megadrive came out in 1988 and did 205 bytes per scanline. The PCE came out in 1987 and have near unrestricted access to vram (I/O) during active display - giving more bandwidth and active display at the same time per frame. And what relevance does CD-ROM and hard drives from that era have to do with anything? It's not "really fast, considering". It's just about relatively average, actually.

Quote:
CHR banking may have been good for swapping tiles in-and out (Neo Geo style), but would have been way more expensive on the other hand. For Nintendo (more cart lines, at least 2 ROM chips in cartridge) and the game developer (storing UNCOMPRESSED graphics in expensive mask roms). This is NOT efficient.

DMA on the other hand, may be used for purposes far beyond graphics transfer. I think it's a much more elegant design than then NES custom mapper chaos.

First of all, the nes "mapper chaos" is what prolonged the life of the Famicom and NES to begin with. If the NES was stuck with straight vram and no DMA system, like the Master System that came out 2 years later, it would have fallen to the side. The mapped memory to the PPU is what gave it extreme flexibility. That's something SMS homebrew and demo coders could kill for on that system. For all the Famicom/NES graphic faults/weaknesses, the PPU memory mapped via cart was its biggest strength that helped over come that. Especially later on in the systems life.

Second, I never mentioned anywhere of ditching VRAM + local DMA. That's you jumping to conclusions. I was referring to having the PPU upgradeable via the port still, like how the original Famicom/NES was.

The two PPU setup was custom. Built from scratch. These weren't just some off the shelf parts. They could have done anything they wanted to during the design phase. To say they couldn't have done this or that, in realistic speculation, is ignorant IMO. Especially considering the video setup totally appears as though they tried to squeeze everything they could out of the chips. I'd say a lot of modes are pretty useless, but they're there. I doubt the design team blew a lot of chip real estate just for these limited features. I think it would be a fairly good assumption that they re-used a lot of module logic to get the most out of the chip(s) setup.

Third, did you even read what I wrote about the single line system on the cart port? The PPU active display is limited to 256 pixels. All you would need is 8 address lines on the cart port and 8 data lines for the bus. Fastrom supports 7.159mhz rom/ram. That's all you would need. *Any* external logic would take care of switching the 256byte page as the PPU signals from the cart port. There's nothing complex about that. That's a fairly simple design. And yes, it would require external logic - but how is that different from Nintendo already using a series of external chips to render to a buffer, that the PPU has to DMA to vram via cpu requests? Well, it's different in that it's much more efficient. Full 256x224/240 resolution at 60fps. And for what? 17 more lines on the cart interface?

Quote:
Games like Doom on the other hand run pretty well in 256 colours. The DMA scheme is fast enough to let an outside controller render graphics in the VRAM of the PPU at acceptable frame rates.

Well, that's your opinion

Quote:
Besides, 4bpp is higly misleading, because you can (if we take HDMA, colour math and sprites out, though they make great status displays) still use up to 121 colours using subpalettes, without putting much additional strain on the bus.

Who cares what the total color count is? It's about freedom of use of color. And a subpalette system like that greatly impedes upon this. I'm no stranger to tile/tilemap graphics and programming for these old consoles. Or tweaking graphics and squeezing out as much color and detail as possible. Attention to detail via color is not directly relative to the highest color count. You can add all the overlays by sprites and vertical gradients and such. Matters nothing to detail, for where it counts. Let alone quoting the max color count for a subpalette system, especially in the context of a real time rendering system using that as the bitmap display.

Quote:
EDIT: I see, use 'bankswitching' via TDADDR for most of the buffering, and draw onto the rest during Vblank/Forceblank. It looks like you are limited to 20fps at 240x160 in NTSC mode, though.

How does TDADDR work relative to MODE 7 and direct color mode?

by 6502freak on 2010-06-08 (#62670)

tomaitheous wrote:
And that means what, exactly? Have you every written an automatic converter?

Yes I have.

Quote:
I have and it's a pain in the ass to deal the errors and perceived artifacts for sub a single plane system. And it's slooooow, not real time.

I didn't ask YOU to write it. Let that be my problem.

Quote:
So it's not practical in a real world solution without having some serious ugly artifacts or sticking with a single 16(15) color palettes and treating it a single 4bit bitmap.

You can't know for sure, because this method was never used on the SNES.

Quote:
SegaCD has many examples of rendering to 4bpp subpalette plane system. I think you'll find a common fact is that the pseudo bitmap for the vram is left/treated as straight 4bpp and one 16(15) color palette.

You don't seem to get what I was thinking about. I was talking about a encoding scheme related to the YUV quantization of the JPEG codec, using colour math between two layers. The 4bpp layer has the brightness of the picture, the 2bpp layer the hues.

This is not in any way related to the Sega CD codecs using subpalettes.

Quote:
2.68mhz is really fast for 1990? Yeah, maybe if the only thing you ever code were old 8bit computers or the SNES. Megadrive came out in 1988 and did 205 bytes per scanline.

Yeah, and it's also way more limited, since it can only do VRAM transfers. SNES has a general purpose DMA controller. It can be used for way more.

Quote:
The PCE came out in 1987 and have near unrestricted access to vram (I/O) during active display - giving more bandwidth and active display at the same time per frame.

I know that too. I even built my own development system for the PC-Engine using SD cards and wrote my own file system and browser.

Is this now another discussion about which console is better?

Quote:
And what relevance does CD-ROM and hard drives from that era have to do with anything?

Simple: DMA is way more flexible, and obviously not only intended for graphics, which seems to be your fixed mindset. The expansion connector on the bottom of the SNES has also the DMA lines.

Quote:
It's not "really fast, considering". It's just about relatively average, actually.

If you quote me, do it properly. Considering the mass storage devices of its era, the bus is actually quite fast. Isn't DMA also used by the SNES Powerpack for very short loading times?

Quote:
First of all, the nes "mapper chaos" is what prolonged the life of the Famicom and NES to begin with.

Maybe, but only because the initial hardware was quite spartanic to begin with.

Quote:
If the NES was stuck with straight vram and no DMA system, like the Master System that came out 2 years later, it would have fallen to the side.

Interesting, I always thought the Master System failed more due to lack of high profile third party developers like Konami, Capcom and Namco.

Quote:
The mapped memory to the PPU is what gave it extreme flexibility. That's something SMS homebrew and demo coders could kill for on that system.

I'll bet they also look with envy on the NES 2bpp graphics.

You see how stupid this comparison is? We can now throw technical data back and forth, completely out of context of any actual real situations.

Quote:
For all the Famicom/NES graphic faults/weaknesses, the PPU memory mapped via cart was its biggest strength that helped over come that. Especially later on in the systems life.

Yes, but only because the initial configuration of the NES was very meagre to begin with.

Luckily, we don't have that situation on the SNES. Well, we have another, more serious problem on the SNES than any lack of convoluted CHR bank scheme: lack of processing speed.

Quote:
Second, I never mentioned anywhere of ditching VRAM + local DMA. That's you jumping to conclusions. I was referring to having the PPU upgradeable via the port still, like how the original Famicom/NES was.

Okay, so you want just to have everything.

As I said: Nintendo should have the foresight to put every possible pin on the cartridge connector. That would have enabled the possibility in 2010 to built a super video accelerator, which in effect degrades the PPU to a 15 Bit DAC.

Quote:
The two PPU setup was custom. Built from scratch. These weren't just some off the shelf parts. They could have done anything they wanted to during the design phase.

Sure, they could have put in the newest 32Bit CPU into the design.

Quote:
To say they couldn't have done this or that, in realistic speculation, is ignorant IMO.

It's not about what they COULD have done. It's about how to avoid unnecessary costs. It's about to have a FOCUS. What is important to game developers and what isn't. Where to draw the line and say: STOP, that is enough. You have big problems to take a 1989/90 POV in this matter.

Frankly? The crippled CPU speed and bus is a way more bigger problem. But even with that, developers were able to create amazing games. Nowadays, if there is a limitation, people want extra hardware in cartridges to fix them. And no, we are not being content with what is possible, we bitch constantly about what is NOT possible.

Quote:
Especially considering the video setup totally appears as though they tried to squeeze everything they could out of the chips. I'd say a lot of modes are pretty useless, but they're there. I doubt the design team blew a lot of chip real estate just for these limited features.

Like what? Mode 7? Colour math? Hardware multiplication and addition? 128 Sprites? DMA/HDMA?

Quote:
Third, did you even read what I wrote about the single line system on the cart port? The PPU active display is limited to 256 pixels. All you would need is 8 address lines on the cart port and 8 data lines for the bus. Fastrom supports 7.159mhz rom/ram. That's all you would need.

What are you talking about??? You were talking about some scheme to directly control the PPU through the cartridge port, providing an external framebuffer, accessible to the CPU and any external devices, somehow similar to MMC5 on the NES.

I'm sorry to burst your bubble, but that would take way more than just an 8 Bit line buffer (not to mention the fact that he PPU has a 16 Bit data bus). It would take an entirely seperate frame buffer, and an additional bus controller which monitors the PPU to schedule the accesses between this frame buffer and any external devices.

Of course, you could now say: well, let's take the biggest FPGA with the biggest dual port ram, and connect it to the PPU.

Like I said: 2010 perspective for a 1990 game console. Nintendo should have seriously thought about that.

Quote:
*Any* external logic would take care of switching the 256byte page as the PPU signals from the cart port. There's nothing complex about that. That's a fairly simple design.

So you are just talking about a 256Byte ROM bankswitch scheme with 256 byte Pages? I don't follow you at all. What is *ANY* external logic?

Quote:
And yes, it would require external logic - but how is that different from Nintendo already using a series of external chips to render to a buffer, that the PPU has to DMA to vram via cpu requests?

DMA has not to be in close sync with the PPU. DMA has not not fight with the PPU for memory access cycles during rendering. Register driven DMA allows for very simple FIFO buffers for communication.

Quote:
Well, it's different in that it's much more efficient. Full 256x224/240 resolution at 60fps. And for what? 17 more lines on the cart interface?

You are now pulling all these vague descriptions and half thought-out concepts out of your butt. I'd suggest you study the schematics first, before your fantasy is running wild here.

Quote:
Well, that's your opinion

Yeah, it's obviously not my mother's, thanks for the reminder.

I'd suggest then to play Doom on a decent 486/Pentium/Core i7 PC, and not a cheap 1990 16 Bit console.

I guess according to you, Nintendo should have taken the 32X route. We all know how great that concept turned out.

Quote:
Who cares what the total color count is? It's about freedom of use of color.

Then I guess you are on the wrong system then.

Quote:
And a subpalette system like that greatly impedes upon this.

Yeah, boohoo. But it's an unchangeable reality: either have "freedom of choice in colours(tm)" and less speed, or have more speed with more restrictions. Again: you wanna have it all. For you, retro developing seems about what the consoles CAN'T do, and not what they CAN do. Every obstacle causes you to whine.

Gosh, I hope you never come across an Atari 2600.

Quote:
I'm no stranger to tile/tilemap graphics and programming for these old consoles.

That's good, because otherwise, this would be a fairly pointless discussion.

Quote:
Or tweaking graphics and squeezing out as much color and detail as possible.

Tedious work, isn't it?

Quote:
Attention to detail via color is not directly relative to the highest color count.

I didn't say so. Nor has it any relevance to the point I was making that using subpalettes can increase the amount of colour detail.

Quote:
You can add all the overlays by sprites and vertical gradients and such. Matters nothing to detail, for where it counts.

With sprites, you can enhance colour detail a lot. Ask any C64 coder.

Quote:
Let alone quoting the max color count for a subpalette system, especially in the context of a real time rendering system using that as the bitmap display.

No matter how many words you are using up here, fact is: 4bpp tiles with supbalettes >> 4bpp tiles with fixed 16 colour palette in terms of colour detail.

And now I am really fed up with this. This discussion is unproductive, because in the end, we are ending up discussing the CAN'Ts when bitching about how much could have been possible when all SNES signals would have been put on the cartridge connector.

The fact remains: they aren't. I see the possibilities with a flexible DMA system, you refuse to see them and cling to a fantasy.

You know what? You should start developing on the Neo Geo then. This seems to be the perfect architecture for you. But then I guess you would find lots of other things which don't suit your taste.

by byuu on 2010-06-08 (#62675)

tomaitheous wrote:
How does TDADDR work relative to MODE 7 and direct color mode?

The memory layout is hard-coded for Mode7, so TDADDR does nothing :(

by tomaitheous on 2010-06-08 (#62679)

6502freak: Wow, that is really petty. Nerd rage is never a pretty thing. I'm not going to even touch that reply (too bad, there is some good stuff/topics to talk about there and you're obviously a pretty intelligent guy). You need to seriously calm down/take a chill pill (and you're presumptions about me couldn't be more wrong, not that you care though). ;>_>

Quote:
The memory layout is hard-coded for Mode7, so TDADDR does nothing

Ahh ok. I thought I was missing something there for a minute.

by mic_ on 2010-06-08 (#62688)

Quote:
DMA on the other hand, may be used for purposes far beyond graphics transfer. I think it's a much more elegant design than then NES custom mapper chaos.

SNES has a general purpose DMA controller. It can be used for way more.

Isn't DMA also used by the SNES Powerpack for very short loading times?

I was under the impression that the SNES' DMA (if you're talking about the 8 channels at $42xx/$43xx) only could transfer data between the CPU and PPU. I.e. either the source or destination has to be $21xx. I don't see how that would be useful for the PowerPak when loading ROMs.

by ReaperSMS on 2010-06-08 (#62689)

$21xx hits everything on the B bus, which includes the PPU, WRAM, expansion, and cart edge. The A bus hits the cart edge and S-APU.

WRAM has two sets of pins on it, one for talking to it via the A bus, and others for talking to it via the B bus at $80..$83 with the streaming reads/writes. If both are enabled, the A bus pins take precedence, and the B side is tristated (CPU sees open bus).

Thus, carefully managed DMA can blast from {ROM, WRAM, SAPU, anything that pipes up on the cart} <-> {VRAM, WRAM, anything that pipes up on the cart}

by 6502freak on 2010-06-09 (#62695)

tomaitheous wrote:
6502freak: Wow, that is really petty. Nerd rage is never a pretty thing.

Honestly? This is a nerd forum, the whole topic of the thread is nerdy, and sorry, but you also started (and continued) by being nerdy. Glass house, stone.

Quote:
I'm not going to even touch that reply (too bad, there is some good stuff/topics to talk about there and you're obviously a pretty intelligent guy). You need to seriously calm down/take a chill pill (and you're presumptions about me couldn't be more wrong, not that you care though). ;>_>

And you are obviously a pretty intelligent guy, too. However, I was under the impression you took some things I said out of context in order to make your point look stronger, or implying things which I never said.

Plus, I am also right now losing my hair over the Cell Broadband Architecture. One really nasty memory bug in my code I can not find.

I am sorry if I offended you. Nevertheless, I hope you realize it often takes two to make a debate heated.

by 6502freak on 2010-06-09 (#62696)

mic_ wrote:
I don't see how that would be useful for the PowerPak when loading ROMs.

Transferring sectors from Compact Flash card into RAM. With DMA, you can come very close to 2.68MB/s transfer speed. With the CPU polling the CF registers, it would be much less. I also think that the SDRAM controller is hooked to the DMA in the Powerpak.

by Memblers on 2010-06-09 (#62727)

I always figured the reason the PCE/TG16 was so much faster was because it was by NEC, and they also make memory chips. What if Nintendo wasn't always able to get a competitive pricing/availability on fast memories? If they need to have them in every cartridge, they could basically get screwed over at any minute.

It is a shame though that they didn't bring the PPU bus to the cartridge port, other than extra connector cost (either because of size or smaller pitch) I guess it's just too many pins. Could have been just like the NES, where the /CE line for the internal memory comes out to the cartridge port. The NES cartridge port has plenty of wasted pins, and they seem to have done just fine regardless of that.

by ReaperSMS on 2010-06-09 (#62733)

The TG16 ran at 7MHz, and packed all sorts of instructions that should have been on the 6502 to begin with, and had some block move instructions to cover for DMA.

Only the PRG made it to the cart there IIRC, and it was a vram based console more like the snes, though with fewer colors, only one BG layer, one sprite layer (with switchable priority a la the NES), and 64 sprites.

by psycopathicteen on 2010-06-10 (#62785)

I've heard that the 65816 requires memory clocked twice as fast because it only accesses memory for half a cycle instead of the whole cycle like the majority of other cpus, forcing 5.37 Mhz memory to be used like 2.68 Mhz, and 7.16 Mhz to be used like 3.58 Mhz. I don't understand why Nintendo/Ricoh didn't fix the problem for the Snes.

5.37 Mhz dma would be really helpful at sprite animation, so I wouldn't have to rely on stupid tricks like "every enemy walks with synchronized footsteps" and "alternate between animating the giant robot's front legs and back legs."

by ReaperSMS on 2010-06-10 (#62786)

That would be due to how the clocking works on the 6502 and 65816. The input clock is turned into two mutually exclusive clocks, phi1 and phi2. phi1 controls the address bus and data out latches, instruction register, and most of the internal control signals, including the various register loads. phi2 controls the data input latches (one for the main dbus, one for the instruction decoder), the program counter, and precharges all the internal busses to +5V.

External devices see a stable address while phi2 is high, and must have data valid before phi2 goes low. "Fixing" this would have required a more complex bus cycle, akin to the z80 probably, where it takes 4+ cycles to access memory.

In addition, some of the expansion chips took advantage of this. The SA-1 accesses the ROM in the dead time in between 5A22 accesses, but only works when the 5A22 is running at SlowROM speeds.

by tomaitheous on 2010-06-10 (#62788)

ReaperSMS wrote:
External devices see a stable address while phi2 is high, and must have data valid before phi2 goes low. "Fixing" this would have required a more complex bus cycle, akin to the z80 probably, where it takes 4+ cycles to access memory.

PCE's 65x variant runs 1:1 (processor speed to data bus). It isn't anything like the z80 address system. Having a non multiplexed address scheme would have fixed the problem on the '816, unless there's something else I'm missing? I also had an idea of a next byte prefetch system (like a linear burst), for running memory at the same speed (processor divide clock speed) instead of the required 2x requirements. Though I didn't work out all the details. (This wasn't for snes, but a MCU project)

by ReaperSMS on 2010-06-10 (#62791)

Haven't seen timing diagrams for the 6280, but I'm betting the address bus didn't quite work like that. Clock speed isn't really the right term for these memories anyways, since they're all async. It's more likely it still had the 2x requirement, and used the off-duty half of the CPU cycle for refresh. I would be rather suprised if it turned out they redid the entire inner workings of the core, rather than the tweaked up 65C02 it looked like.

The 5A22 doesn't multiplex the bus, at least, it doesn't appear to from the pinout. It's possible the 816 inside is multiplexed, and part of the DMA/external bolt-ons hide that.

Really it comes down to the basic issue of things not happening instantly. The memory needs to have a stable address, and the CPU needs to have a reliable point to latch the incoming data. If the CPU has to compute the next address from the incoming data, there's going to be some dead time on the address bus between the ROM providing data and the new address showing up. A prefetch system might pull that off, but then you need more logic to have the next address computed in time, and the only "benefit" you get is theoretically cheaper ROM chips, in a world where the bulk of the chips avaliable are going to be fast enough, given the competition.

by tomaitheous on 2010-06-10 (#62793)

ReaperSMS wrote:
Haven't seen timing diagrams for the 6280, but I'm betting the address bus didn't quite work like that. Clock speed isn't really the right term for these memories anyways, since they're all async. It's more likely it still had the 2x requirement, and used the off-duty half of the CPU cycle for refresh. I would be rather suprised if it turned out they redid the entire inner workings of the core, rather than the tweaked up 65C02 it looked like.

Not sure what you mean by using the off-duty cpu cycle for fresh. And I shouldn't have said 1:1 for the 6280, because it needs a rom/ram/bus device to be a little faster than the CPU cycle of 140ns. 120ns is found for the internal ram and is what I've used for external (rom zif board).

Quote:
The 5A22 doesn't multiplex the bus, at least, it doesn't appear to from the pinout. It's possible the 816 inside is multiplexed, and part of the DMA/external bolt-ons hide that.

I just assumed the kept it (internally, wouldn't be much of a problem to have the 8bit latch in the same chip) because of the address being setup on the first half of the phase and the data bus window on the second phase like that of the stock '816.

What about the SA-1. Were any changes made in regards to that '816 variant? Regarding memory timings and such.

by ReaperSMS on 2010-06-10 (#62794)

The 6280 is probably using a rather skewed duty cycle for access then, or they went with overlapping phases and hoped for the best.

As for the SA-1, the rom there was 90-100ns, 10.7MHz access cycle, or 2 master clocks. The 5A22 gets two cycles for one access, the SA-1 then gets two cycles for two accesses, though I think it's an x16 rom and they're cheating a bit. The 5A22 runs at 2.68MHz (21.5/8), SA-1 at 10.7, and if the access requests collide, the SA-1 waits.

by tomaitheous on 2010-06-11 (#62864)

ReaperSMS wrote:
The 6280 is probably using a rather skewed duty cycle for access then, or they went with overlapping phases and hoped for the best.

Well, how long after the starting point of phase 1 is are the address lines valid, on the original 6502 and the NES variant? I can't imagine it being at the end of phase 1.

by Memblers on 2010-06-11 (#62865)

tomaitheous wrote:
ReaperSMS wrote:
The 6280 is probably using a rather skewed duty cycle for access then, or they went with overlapping phases and hoped for the best.

Well, how long after the starting point of phase 1 is are the address lines valid, on the original 6502 and the NES variant? I can't imagine it being at the end of phase 1.

6502 timing info is in this PDF, skip to page 3:
http://archive.6502.org/datasheets/mos_6500_mpu_nov_1985.pdf

by tomaitheous on 2010-06-11 (#62869)

Thanks, I see it. 1/4th in on Tcycle, or 1/2 in on phase 1. Thanks for the link

by psycopathicteen on 2010-06-12 (#62878)

6502 said:

Quote:
And no, we are not being content with what is possible, we bitch constantly about what is NOT possible.

Eventhough I'm with Tomaitheous with the idea of a PPU to cart bus, you bring up a good point about bitching about what is not possible and not being happy about what is possible. I can't wait until the day I can shout "the Super Nintendo's cpu is so dang fast!" without some jerk asking me for "citation needed."

by smkd on 2010-06-12 (#62879)

psycopathicteen wrote:
I can't wait until the day I can shout "the Super Nintendo's cpu is so dang fast!" without some jerk asking me for "citation needed."

I'm sure every programmer here knows the S-CPU is capable is plenty, especially if the homebrew programmer is not bound by the limitations of a commercial developer (not talking about enhancement chips or even FastROM). I don't see much difficulty in getting a fast paced action game like gunstar heroes or metal slug running at 60FPS with some optimised code. If you're talking about non-programmers and their view of a slow SNES CPU, why does it bug you? Their opinion isn't really qualified to begin with so it's no big deal.

@ReaperSMS: I think I saw a 16bit ROM with selectable 8bit/16bit outputs on an SA-1 cart so you might be right about that.

by tepples on 2010-06-12 (#62881)

Case in point: If the original Contra (not Contra Force) and Recca run on an NES, a game like Gunstar Heroes could certainly run on a Super NES with fast ROM. The lack of MMC3-style bankswitching isn't much of a problem because you can just dump a 64-tile bank in with DMA copy and still have time for OAM DMA and nametable updates. It won't handle crazy mid-frame shit like in Cosmic Epsilon, but HyperZone demonstrates that Mode 7 reduces the need for that.

by psycopathicteen on 2010-06-12 (#62894)

Eventhough I understand that programmers had a limited time to program games, I still don't understand what exactly they cut corners to finish their games on time.

by ReaperSMS on 2010-06-12 (#62898)

Because programmers like eating.

by Jeroen on 2010-06-12 (#62899)

psycopathicteen wrote:
Eventhough I understand that programmers had a limited time to program games, I still don't understand what exactly they cut corners to finish their games on time.

Because if they don't please asshat executive producer who wants it out BEFORE christmas wants it out before christmas, you try and please him in fear of ya know.....getting fired?

by psycopathicteen on 2010-06-12 (#62901)

I know WHY they cut corners, I asked WHAT corners do they cut?

Yes, I get it, programmers don't spend time optimizing their codes, but intentionally slowing your codes down doesn't make the clock in your office run backwards either?

by 6502freak on 2010-06-12 (#62904)

psycopathicteen wrote:
Eventhough I'm with Tomaitheous with the idea of a PPU to cart bus, you bring up a good point about bitching about what is not possible and not being happy about what is possible. I can't wait until the day I can shout "the Super Nintendo's cpu is so dang fast!" without some jerk asking me for "citation needed."

I think the biggest appeal of retrocoding is to figure out how a system works and to explore its boundaries. To code FOR the architecture, not AGAINST it.

SNES is pretty tame compared to some other architectures. Like I said, if you want some REAL coding challenge, do something for the Atari VCS. There is no other system out there where your coding skills and inventiveness ultimately determines how well your game looks, and what your game can do at all. Take a very primive, but also very flexible graphics chip and make the 6502 do practically all the work.

I think during the SNES lifetime, the hardware was explored pretty well. It was the most popular system of its era and the developers were quite competitive. They HAD to be.

by 6502freak on 2010-06-12 (#62906)

Quote:
What if Nintendo wasn't always able to get a competitive pricing/availability on fast memories? If they need to have them in every cartridge, they could basically get screwed over at any minute.

The problem is not the access speed of the ROMS, but the broken 65816 design and some other dubious choices. WRAM is a huge bottleneck. If they could have thrown out their custom DRAM design, and hooked the 65816 directly to a 100ns SRAM, then 5.37Mhz CPU speed wouldn't have been a problem.

But then again, there are still those 2 mysterious TCKSEL pins at the CPU.....

I think that the SNES was, from day one, regarded by Nintendo as a system, which should be expanded by additional chips in the cartridges. Always the goal to make some extra bucks and milk the developers.

Quote:
Could have been just like the NES, where the /CE line for the internal memory comes out to the cartridge port. The NES cartridge port has plenty of wasted pins, and they seem to have done just fine regardless of that.

As we already said: for full functionality, a whopping 50 aditional pins (the PPUs have TWO address buses for each 8 bit data part).

by psycopathicteen on 2010-06-12 (#62908)

6502freak wrote:
I think during the SNES lifetime, the hardware was explored pretty well. It was the most popular system of its era and the developers were quite competitive. They HAD to be.

If you consider "well explored" as in using hacked on hardware special effects just to make use of hacked on hardware special effects, then I agree it was well explored. But if you consider "well explored" as in programming original special effects through creative use of hacked on hardware special effects, I disagree.

by whicker on 2010-06-12 (#62920)

psycopathicteen wrote:
6502freak wrote:
I think during the SNES lifetime, the hardware was explored pretty well. It was the most popular system of its era and the developers were quite competitive. They HAD to be.

If you consider "well explored" as in using hacked on hardware special effects just to make use of hacked on hardware special effects, then I agree it was well explored. But if you consider "well explored" as in programming original special effects through creative use of hacked on hardware special effects, I disagree.

Oh please,

Play through Soul Blazer. Yes the fighting sucks, but there's so many neat effects they do. (Soul of Reality predating Ocarina of Time's Lens of truth, the Northern Lights, the palette cycling animations, the "underwater effect", fog and torchlight effects, invisible sprites in the model city).

by smkd on 2010-06-13 (#62923)

psycopathicteen wrote:
I know WHY they cut corners, I asked WHAT corners do they cut?

Yes, I get it, programmers don't spend time optimizing their codes, but intentionally slowing your codes down doesn't make the clock in your office run backwards either?

Making modular / reusable code would probably be the aim of a team of commercial developers. It won't be the quickest, but it'd probably be the most maintainable and easiest to debug, especially if you're not working alone and others have to deal with your code. It'd also be the most compact. The typical SNES game was 8mbits and if it was small enough to shoe-horn into a 4mbit ROM, they'd definitely try. Having stuff like dedicated macros for all your sprite drawing, huge tables for quick lookups, unrolled loops for building tilemaps to update with the screen would eat up space in an 8mbit or 4mbit ROM very quickly. Although with 32mbit or even 16mbit ROMs for free (including fastrom), there's really no reason why a homebrew programmer wouldn't take advantage of those to get enormous speedups.

Some time back (November or something) I optimised SMW's tilemap building code which was a pretty poorly written loop that ran 32 times for each layer that had to be updated. The unrolled versions took up about 20KB of code after trimming all the fat. It ran much, much faster than the original and with some optimal memory layout by the original game it would've run even faster by getting the DP register in there. But if I was trying to cram everything I could into an 8mbit ROM (or 4mbit in SMW's case) I wouldn't be trying that at all. 20KB just for one part of the game and there's many more to do after that. SMW does actually make use of unrolled loops, although it only does it for one case and it's not even stored in ROM. They just generated the code in RAM using a small routine in ROM.

Giant tables, unrolled loops and all of that wouldn't really work when you're pressed for ROM space. Although with 32mbit ROMs for free, there's no reason not to go that route in modern hacks or homebrew (with 8Mbyte possible with enhancement chips). The performance gains are huge but may or may not worth it if you're paying for every megabit. Having a functional, but not optimally coded game with more graphics or levels etc. probably would've been more appealing to a game developer depending on how much they're willing to spend.

by psycopathicteen on 2010-06-13 (#62928)

whicker wrote:
psycopathicteen wrote:
6502freak wrote:
I think during the SNES lifetime, the hardware was explored pretty well. It was the most popular system of its era and the developers were quite competitive. They HAD to be.

If you consider "well explored" as in using hacked on hardware special effects just to make use of hacked on hardware special effects, then I agree it was well explored. But if you consider "well explored" as in programming original special effects through creative use of hacked on hardware special effects, I disagree.

Oh please,

Play through Soul Blazer. Yes the fighting sucks, but there's so many neat effects they do. (Soul of Reality predating Ocarina of Time's Lens of truth, the Northern Lights, the palette cycling animations, the "underwater effect", fog and torchlight effects, invisible sprites in the model city).

All those effects are common place for Super Nintendo games.

by 6502freak on 2010-06-13 (#62929)

psycopathicteen wrote:
If you consider "well explored" as in using hacked on hardware special effects just to make use of hacked on hardware special effects, then I agree it was well explored. But if you consider "well explored" as in programming original special effects through creative use of hacked on hardware special effects, I disagree.

Strong words, which of course, in order to be credible, need some backing up. What area do you think the SNES wasn't particularly well explored?

Some titles even featured 3D software raycasting (Wolfenstein 3D, Jurassic Park and... *sigh* Super Noah's Ark 3D). Something you'd never expect the SNES to do well enough without special chips in order to be playable.

by psycopathicteen on 2010-06-13 (#62933)

6502freak wrote:
psycopathicteen wrote:
If you consider "well explored" as in using hacked on hardware special effects just to make use of hacked on hardware special effects, then I agree it was well explored. But if you consider "well explored" as in programming original special effects through creative use of hacked on hardware special effects, I disagree.

Strong words, which of course, in order to be credible, need some backing up. What area do you think the SNES wasn't particularly well explored?

Some titles even featured 3D software raycasting (Wolfenstein 3D, Jurassic Park and... *sigh* Super Noah's Ark 3D). Something you'd never expect the SNES to do well enough without special chips in order to be playable.

Sure

-fake scaling and rotation
-tile per offset mode
-multijointed sprites
-animation
-dual layer collision
-collision with wavy or tilting background layers
-tile grid animation with collision
-Mode-7 with waves

Yes, some of these might've been used in a couple games, but none of them were used nearly as much as they should've.