nesdev.org

Arg what a shame :'( The fact it reads back old values for sometime before reading garbage can be even more confusing to understand what happen...

tepples wrote:That's exactly what you'd do. On Atari 7800, you write a sprite to the display list of all 16-pixel-tall zones it crosses.

What if there is a sprite D that gets cut off between the first DMA set and the second DMA set?

The zone list on the 7800 is a software-defined counterpart to the sprite evaluation in the NES PPU or any other TMS9918-style VDP. Because it's software-defined, it's not as efficient, but it's more flexible. For example, if you want sprite D to show up in one zone but not the adjacent one, such as if you're making a split screen or a "behind the background" type thing, then don't write the sprite to the other zone.

Re: SNES, if you can guarantee that there are no sprites on a particular line, you should be able to just force blank during the HBlank preceding that line and go nuts (unless there's a substantial delay before the OAM address becomes usable - I haven't tested this). Obviously that's not representative of the general case...

tepples wrote:The zone list on the 7800 is a software-defined counterpart to the sprite evaluation in the NES PPU or any other TMS9918-style VDP. Because it's software-defined, it's not as efficient, but it's more flexible. For example, if you want sprite D to show up in one zone but not the adjacent one, such as if you're making a split screen or a "behind the background" type thing, then don't write the sprite to the other zone.

But between the "zones" you need several lines to fill up the OAM, which must be arranged carefully to avoid flickering and priority issues in the transitional region.

That is, unless you can write to oam before hblank starts.

The 7800 has 4K of unified memory. The zone list and the display lists it points to are inside main RAM, and MARIA (the video chip) pauses the CPU (by pulling RDY low) while it fetches display lists and patterns. CHR can be pointed at RAM or ROM.

But on the SNES, you'd probably would only be able to update 8 sprites per scanline, and you'd probably want at least 16 per zone.

lidnariq wrote:

Espozo wrote:if your TV is able to vertically stretch the display

I assume you mean "the input is letterboxed, remove the letterboxing" with a proportional scaling. Tepples has pointed out in the past that the SNES/NES could have an active area of ≈256x164 to be 16:9 friendly.

That said, 160 pixels is kinda painfully low.

With 192 of vertical resolution you will have 5KB extra of bandwidth. In total, almost 11KB of data transfer (10,89KB), plus the bit you would have compressing (let's say a 20%, that is 2,17KB).

In total is 13,06KB. The resolution is sacrificeable if you don't shall to use all the surface of the screen (usually you have big zones of sky where nothing happens), and conversely you will have a true level of amazing animations.


Edit:

Just a question...

If i'm transfering tiles from ROM to VRAM, Can the DMA transfer tiles from WRAM to VRAM simultaneously?.

In this way maybe could be use the WRAM like a kind of caché for backgrounds animations (people walking, things exploding, etc).

Señor Ventura wrote:the bit you would have compressing (let's say a 20%, that is 2,17KB).

You can't send compressed graphics to VRAM, so you're stuck with 11KB. This is really more than enough though, sprites only have access to 16KB of VRAM and they're going to be what you're updating the most, and probably somewhere around 30fps, so you could probably get away with a vertical resolution of 208 which would give you 8.5KB per frame. I don't know what animation scheme you want to use, but I imagine you're not updating all of the VRAM available to sprites anyway.

Señor Ventura wrote:If i'm transfering tiles from ROM to VRAM, Can the DMA transfer tiles from WRAM to VRAM simultaneously?.

No. DMA transfers happen one at a time.

Señor Ventura wrote:In this way maybe could be use the WRAM like a kind of caché for backgrounds animations (people walking, things exploding, etc).

Why not just use DMA to VRAM from a different location in ROM?

Espozo wrote:

Señor Ventura wrote:If i'm transfering tiles from ROM to VRAM, Can the DMA transfer tiles from WRAM to VRAM simultaneously?.

No. DMA transfers happen one at a time.

But you can set up eight of them (minus however many HDMA channels you're using) before vblank and then have them all run consecutively.

Espozo wrote:

Señor Ventura wrote:In this way maybe could be use the WRAM like a kind of caché for backgrounds animations (people walking, things exploding, etc).

Why not just use DMA to VRAM from a different location in ROM?

If the background animations are compressed, you need to DMA them from WRAM.* I seem to remember reading that when Super Mario World shows "Nintendo Presents" before the title screen, it's decompressing a lot of graphics to WRAM.


Unless you're using a decompression ASIC like S-DD1, and you probably aren't.

tepples wrote:But you can set up eight of them (minus however many HDMA channels you're using) before vblank and then have them all run consecutively.

So, is the same thing, except for the fact that it's done automatically.

The reason of my question is, if the bandwidth of the tile graphics works ever at 5.72KB, while samples are being transferred to the SPC700's RAM.
But now i see that, when graphics are transferred to VRAM, nothing is happening with the samples going to the SPC700's RAM... and vice versa.

tepples wrote:If the background animations are compressed, you need to DMA them from WRAM.* I seem to remember reading that when Super Mario World shows "Nintendo Presents" before the title screen, it's decompressing a lot of graphics to WRAM.

Sounds logic, cause the cpu can't adressing to VRAM.

Señor Ventura wrote:

tepples wrote:But you can set up eight of them (minus however many HDMA channels you're using) before vblank and then have them all run consecutively.

So, is the same thing, except for the fact that it's done automatically.

And therefore without losing bandwidth to the CPU setting up the registers for another DMA transfer.

Señor Ventura wrote:The reason of my question is, if the bandwidth of the tile graphics works ever at 5.72KB, while samples are being transferred to the SPC700's RAM.
But now i see that, when graphics are transferred to VRAM, nothing is happening with the samples going to the SPC700's RAM... and vice versa.

Correct. As I understand it, the vast majority of Super NES games send audio data to the S-SMP using closed-loop programmed input and output (PIO). Block DMA works for graphics, but it's too fast for the S-SMP to receive. There are modern-day demos of using HDMA to send a few bytes each scanline open-loop, but I'm not aware of that being done in the Super NES's original commercial era (pre-1999). It's also possible to alternate between sending a few bytes of audio using PIO during draw time and sending 5.something kB of graphics using block DMA during the following vblank; I think this is what Jurassic Park does outside.

To emphasize: there is no reason at all why audio data would need to be transferred during VBlank. The APU doesn't even know about VBlank; it's on a completely separate clock and cannot receive interrupts. You can transfer data to it at any time during a frame.

The CPU can, in principle, poke data into VRAM manually, since there's a direct access port. It's just way faster to use DMA for anything more than a few sequential bytes.

You can also DMA from the cartridge to WRAM during active display - UNLESS you're using HDMA, because the earliest version of the S-CPU had a bug whereby DMA and HDMA could trip over each other and lock up the system. Very aggravating...

93143 wrote:You can also DMA from the cartridge to WRAM during active display - UNLESS you're using HDMA, because the earliest version of the S-CPU had a bug whereby DMA and HDMA could trip over each other and lock up the system. Very aggravating...

Attached are official details on that bug (because I'm certain someone will want details on it).

Summarized in my own words:

Problem
If a block DMA finishes immediately before HDMA starts, S-CPU version 1 might freeze. This may occur especially in the first 2.24 microseconds (48 master clocks) after the start of horizontal blanking.

Workarounds

1. Beginner: Don't enable block DMA while HDMA is enabled. If you use HDMA, do your block DMA during vertical blanking, or do it on a scanline when HDMA is inactive.
2. Advanced: Carefully time your block DMA to finish outside horizontal blanking. Wait for an H-count interrupt, and adjust the start time until it works without crashing on a 1/1/1 (the yellowest of the yellow).