nesdev.org

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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.

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.

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

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.

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]

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.

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.

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.

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.

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.

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?

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

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.

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?

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

Yes I have.

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.

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.

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.

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.

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?

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.

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?

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.

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.

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.

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.

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.

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.

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.

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?

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.

*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?

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.

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.

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.

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.

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.

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.

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

Tedious work, isn't it?

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.

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.

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.

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 :(

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

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

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