NMI vs IRQ

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: NMI vs IRQ

Post by 93143 »

An NTSC PSX in 320-wide mode has a 32:35 PAR, meaning the video should display with an aspect ratio of 1.66. An NTSC SNES in 256-wide mode has an 8:7 PAR, meaning the video as you've converted it shows up with an AR of 2.06. You could get an exact match with 256x176, but of course that wouldn't fit in VRAM without tearing; getting the correct aspect ratio at 8bpp would involve narrowing the image. Here's a reasonably good comparison; 240x160 apparently fits, and gives an aspect ratio of 1.71.

(If one were to make the assumption that the original video was prepared without taking the PAR into account, the SNES resolution closest to recovering the animation's natural aspect ratio with full screen width would be 256x161. But based on the shape of the sun in that first frame, I don't think this is true.)
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: NMI vs IRQ

Post by tepples »

You wouldn't need the bottom of the video to fit in VRAM twice. You can double buffer all but the last block and single buffer the last block, and you still won't get tearing.
qwertymodo
Posts: 775
Joined: Mon Jul 02, 2012 7:46 am

Re: NMI vs IRQ

Post by qwertymodo »

That's what I'm doing, it's the last block that's the limiting factor, since you need to upload it all in one frame. The larger your visible window, the more data you need to upload in the last frame, while at the same time having fewer lines to do it. I'm not sure how much more data I can pull off, if any (at least in terms of full lines of tiles).
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: NMI vs IRQ

Post by 93143 »

256x152 (aspect ratio ~16% too wide)

38912 B + 64 B (black tile*) + 2x1344 B (168 high*) = 41664 B for a single frame, including two tilemaps
65536 B - 41664 B = 23872 B max buffer (roughly 8 KB per frame for 3 frames)
38912 B - 23872 B + 512 B = 15552 B to transfer on last frame
15552/165.5 = 93.97 scanlines of DMA, resulting in about 16 scanlines of wiggle room

*not necessary with precise IRQ timing
[...actually, it occurs to me that a blank line of the tilemap could be reused as a black tile...]

256x160 (aspect ratio 10% too wide)

40960 B + Nx1280 B (160 high) = 42240+1280(N=2) B for a single frame, including N tilemaps
65536 B - (42240+1280(N=2)) B = 23296-1280(N=2) B max buffer
(40960+1280(N=1)) B - (23296 B-1280(N=2)) B + 512 B = 19456 B to transfer on last frame
19456/165.5 = 117.56 scanlines of DMA, resulting in about 16 scanlines of overload

(also note that it does not matter whether the tilemap is duplicated and switched or overwritten during the final frame)

240x160 (aspect ratio ~3% too wide)

38400 B + 64 B (black tile**) + 2x1408 B (176 high*) = 41280 B for a single frame, including two tilemaps
65536 B - 41280 B = 24256 B max buffer
38400 B - 24256 B + 512 B = 14656 B to transfer on last frame
14656/165.5 = 88.56 scanlines of DMA, resulting in about 13 scanlines of wiggle room

**not necessary with window masking and precise IRQ timing

240x165 (aspect ratio exactly correct)

40320 B (240x168 data) + 2x1344 B = 43008 B for a single frame, including two tilemaps
65536 B - 43008 B = 22528 B max buffer
40320 B - 22528 B + 512 B = 18304 B to transfer on last frame
18304/165.5 = 110.60 scanlines of DMA, resulting in about 14 scanlines of overload


256x176 Quantomatic (aspect ratio exactly correct)

22528 B + 1408 B = 23936 B for a single frame, including one tilemap (Quantomatic requires a tilemap refresh every frame)
(22528 B + 704 B + 256 B)/4 = 5872 B per frame, resulting in about 50 scanlines of wiggle room (ie: it fits in normal VBlank)

with sprites

22528 B + 1408 B = 23936 B for a single frame
(22528 B + 1408 B + 512 B + 544 B)/4 = 6248 B per frame, resulting in about 48 scanlines of wiggle room (ie: it still might fit in normal VBlank if you're careful/clever)
Last edited by 93143 on Thu Oct 20, 2016 10:55 am, edited 1 time in total.
qwertymodo
Posts: 775
Joined: Mon Jul 02, 2012 7:46 am

Re: NMI vs IRQ

Post by qwertymodo »

I really don't want to do 240x160, the side bars always looked weird to me in smkdan's original. However, I will definitely look into 256x152. I'll have to scroll BG1 to recenter it, but that's pretty straightforward, right?
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: NMI vs IRQ

Post by 93143 »

Yes, scroll registers are single-byte dual write, accessible any time (even during active rendering, though the PPU won't notice for a couple of slivers). Just remember that neutral position is actually FFFFh (or 03FFh, since the underlying value is only 10-bit for non-Mode 7 layers) because line 0 is for sprite caching and isn't displayed.

To me, the aspect ratio is a bigger issue than the sidebars, but it's your project...

I just wish Quantomatic were at a more sophisticated stage of development; right now it doesn't use sprites and has issues with colour fidelity in certain situations. Mind you, it still wouldn't look quite as good as true 8bpp... I'm thinking that combining it with CGRAM HDMA would be a fun task for a quantum computer...
qwertymodo
Posts: 775
Joined: Mon Jul 02, 2012 7:46 am

Re: NMI vs IRQ

Post by qwertymodo »

93143 wrote:To me, the aspect ratio is a bigger issue than the sidebars, but it's your project...
Yes, I understand that objectively 240x160 is better, but in practice, aspect ratio isn't really that noticeable unless 1) it's an actual photograph where you can tell proportions of real objects are off, or 2) you are looking at it side-by-side with the original (or are very familiar with it) or 3) it's completely and horribly off

In this case, it's close enough, and the fact that it's animated lends considerable wiggle room before it starts to look visibly off without the original to compare to, and stretching to 256x152 will get us closer. On the other hand, the sidebars are just *there*, obviously visible by themselves, regardless of whether or not you're looking at the original, which, to me, is a larger issue when viewed on its own, as it will be by 99% of everybody who is playing the game normally. It's like watching a widescreen video on YouTube where the uploader hardcoded the letterboxing into the actual video file so now you can't properly watch that widescreen video on a widescreen monitor.
I'm thinking that combining it with CGRAM HDMA would be a fun task for a quantum computer...
Then we'd have to rename it quantumatic, amirite? :P
qwertymodo
Posts: 775
Joined: Mon Jul 02, 2012 7:46 am

Re: NMI vs IRQ

Post by qwertymodo »

Ok, 256x152 it is. It definitely looks better, so there was certainly a point to be made about the old AR not looking good, but at this point, I don't think you can really argue that the remaining AR correction would make up for the eyesore that is vertical pillarboxing.

Image

Image
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: NMI vs IRQ

Post by tepples »

Would it be hard to make some tiles 8-bit and others 4-bit using BG1 and BG2 of mode 3? If you can recognize which tiles in each frame don't need the extra bit depth, that can save you some bandwidth.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: NMI vs IRQ

Post by 93143 »

qwertymodo wrote:at this point, I don't think you can really argue that the remaining AR correction would make up for the eyesore that is vertical pillarboxing.
Well... they do look good, but the AR is still noticeably off. If the SNES had square pixels, simply correcting for the Playstation's non-square pixels would result in an ideal resolution of 256x154, which is why your screenshots look so good without aspect correction. But the SNES does not have square pixels, as is popularly demonstrated by the famous pic of the full moon over Magus' castle (the developer really lived up to their name with this game). Scaled horizontally by 8:7, those screens look like this:
Yukud5jPAR.png
VzKgDlhPAR.png
And would the sidebars really be all that noticeable in a real use case? On an HDTV, or even a widescreen monitor, a SNES game running fullscreen will have sidebars anyway, and on a CRT the screen typically has a dark or black border that can even cover up some of the picture. And anyway lots of games with FMV and/or software rendering (Out Of This World, Star Fox, etc.) had black borders on all four sides.

Nevertheless I respect your decision. Full width does have its own appeal, and it does look basically perfect in an emulator with square pixels...

...

Also, why is the first image (the sky/sun) only 151 high? It seems to be missing a line off the bottom. The second one is 152 as expected...
qwertymodo wrote:Then we'd have to rename it quantumatic, amirite? :P
I wasn't going to say that, but I suppose somebody had to...
tepples wrote:Would it be hard to make some tiles 8-bit and others 4-bit using BG1 and BG2 of mode 3? If you can recognize which tiles in each frame don't need the extra bit depth, that can save you some bandwidth.
Yeah, but then you need two tilemaps, and they both need updating. Worst-case bandwidth is actually higher than with straight 8bpp. Unless you got really lucky with the material, the only reason to do that would be to save some space, and this hack is nowhere near the limits of the MSU1.
qwertymodo
Posts: 775
Joined: Mon Jul 02, 2012 7:46 am

Re: NMI vs IRQ

Post by qwertymodo »

93143 wrote:
tepples wrote:Would it be hard to make some tiles 8-bit and others 4-bit using BG1 and BG2 of mode 3? If you can recognize which tiles in each frame don't need the extra bit depth, that can save you some bandwidth.
Yeah, but then you need two tilemaps, and they both need updating. Worst-case bandwidth is actually higher than with straight 8bpp. Unless you got really lucky with the material, the only reason to do that would be to save some space, and this hack is nowhere near the limits of the MSU1.
The hard part is that right now every frame's tilemap is identical, so I can upload frame n, then upload tilemap n+1 and switch to it in the middle of uploading frame n+1, so I can overwrite tilemap n when I get to it and have that much less data to upload in the final frame. If I were to try and optimize with 2 different BG layers, not only is that 2 tilemaps to upload, it's 2 tilemaps worth of space I can't touch until the end of the frame, which is exactly when the bandwidth timing is already the tightest. Not to mention the vast increase in complexity converting the data.
Post Reply