Rookie

I was looking at information on the SNES' GPU and from what I understand most games started out at a resolution 256x224--From there does a television set blow the graphics up to 512x448 to fit into the tv screen? I've also heard that there were SNES games that started out at 512x448--is this true, and if so, which games are these?
And finally, since all standard def tv's have a vertical resolution of 480 lines and the SNES only puts out 448 lines (32 lines less than a regular tv) shouldn't there be some missing lines on the top and bottom of a SNES' picture? (16 on top and 16 on bottom) If there is, I haven't noticed them, does the tv simply stretch the picture to fit? If that's the case than you think the picture would look more distorted!

Development forum?
1) the horizontal resolution on TVs vary wildly, especially on size. Higher widths just blur the 'pixels' more (eg it gets crushed to fit).
2) vertical resolution 224 -> 448 is the difference between progressive (draw every other scanline each frame) and interlace (draw even scanlines one frame, odd the next).
3) 448 -> 480 difference is the TV clipping off 16 pixels from the top and bottom of the image in the overscan regions.
4) RPM Racing is a 512x448 game. And yes, it looks a lot worse; with the lower bandwidth for detail, the extra blurring and interlacing artifacts.
Note: none of that is scientific. I assume you wanted a basic overview, which is what I provided. I'm sure resident TV experts could nitpick all of that.

Joined: Wed Jul 28, 2004 4:15 pm
Posts: 5615
Location: PAL50, dood !

The SNES has independent parameters to 'double' H/V resolution.
Base is 256x224 (extendable to 256x239 [see DQ5]), 'hires' doubles H to 512 with the price of major colour bleeding [see SoM menus and some others], and 'interlace' doubles V to 448 with the price of half frame rate (extendable to 478).
Some games use 512x448, but I can't remember any that stay at 256x448, although it's possible.
TVs have a fun thing called analog stretch and sync bursts. Basically the data fed to the TV is synced per screen and per line, so every line is automagically widened (or crushed) to roughly fit the horizontal size of the screen. From there, you have a given number of lines depending which format TV you have (PAL/NTSC).
In its basic mode, the SNES sends only even fields every half-frame (for an effective 224p [read: @60/50Hz]), causing clear scanlines on NTSC sets due to the already smaller number of lines of that format. PAL scanlines aren't anything as clear.
In interlace mode, even/odd fields are sent like classic broadcasts, and you get 448i [@30/25Hz].

Joined: Mon Jan 03, 2005 5:04 pm
Posts: 2302
Location: Germany

Re: How did SNES render graphics?

Remember that TVs don't receive bitmaps, they receive signals that control certain parameters.
An analog NTSC TV set always draws the picture with an electron beam that goes from top to bottom 60 times per second, drawing 224 lines from left to right. This is called a 'field'.
The number of pixels per line is simply how often the input signal changes the 'color' of the beam. Older consoles are slow and support only a limited number of these 'pixels'.
Normal operation ('interlaced') is that every second field is shifted vertically a bit, so the lines of that field end up between the lines of the previous field (which is still visible due to the phosphor's afterglow). This is how you get a 'frame' (448 lines) at 30 Hz.
The SNES modifies the TV's input signal so that the vertical shifting doesn't occur ('progressive'). Fields are drawn directly over each other, and you get 224 lines at 60 Hz. The gaps between the field's lines are the scanlines. There's also an 'Interlace' mode on the SNES that can be activated by games, which enables the shifting again.
The high-resolution mode (512 pixels per line) of the SNES shifts every second field horizontally a bit, so the pixels of the field end up between the pixels of the previous field. Naturally this causes some color bleeding though.
(...at least that's what I think is happening; please correct if wrong.)

It's only 6.67 percent less height; you'll not notice the difference without some side-by-side comparison.

Joined: Wed Jul 28, 2004 4:15 pm
Posts: 5615
Location: PAL50, dood !

Re: How did SNES render graphics?

I shall.
Hires doesn't use 2 frames to achieve double horizontal res. Standard hires is 512x224@60 (or 50) FPS, progressive using the same vertical anti-interlace trick.
Analog stretch then crushes the 512 changes into whatever it can, blurring things together (usually intended by the developers).
Fixed brainfart.

Joined: Mon Jan 03, 2005 5:04 pm
Posts: 2302
Location: Germany

Re: How did SNES render graphics?

So the SNES actually outputs 512 pixels per line in one go?
In other words, it's only the rest of the graphics system that mandates the 256-pixels-per-line limit? (buffer restrictions, byte-sized registers etc.)
That would explain how 512x448 is possible.

Joined: Wed Jul 28, 2004 4:15 pm
Posts: 5615
Location: PAL50, dood !

I don't know where you see a 256 ppl limit. The SNES doesn't count the pixels it outputs, and besides, is a 16-bit system.
Regarding 'buffer restrictions' [SNES has no buffer to store the frame in, the PPUs spit the data to the TV realtime], if you haven't noticed yet, mode 5 and 6 have access to a limited amount of BG layers to make hires possible (using 16 half-pixels, 8 from a first layer and 8 from a second, depends what layers you enable on the mainscreen and subscreen).

Joined: Mon Jan 03, 2005 5:04 pm
Posts: 2302
Location: Germany

Well, I've always seen the hires mode as a special quirk of the final output stage. The rest of the graphics system (sprite positions, horizontal BG positions) operates in full pixels, not these 512 half-pixels.
The data bus is still 8 bit.

Mmm... I've thought of the mainscreen and subscreen as arrays of 256 bytes (or something similar) that are filled before the first pixel appears on the screen, probably because that's how I would program it on the PC.

Joined: Wed Jul 28, 2004 4:15 pm
Posts: 5615
Location: PAL50, dood !

Better read the regs docs again... ^^
Hires is done before the rest, not after.
The data bus has as much to do with number of pixels per line as the size of a CD has to do with sampling rate.
There are no 'arrays' for mainscreen and subscreen. The layers themselves aren't put together anywhere in the SNES. Main and subscreen are just logic bits for any given accessible layer given the mode you're in, and the PPUs then use these bits to do the right operation before sending pixels to the unit that sends proper TV signals.
The only 'arrays' are CGRAM, VRAM, the OAM tables...
You've been working too much with emulators. ;p

Joined: Mon Jan 03, 2005 5:04 pm
Posts: 2302
Location: Germany

Yeah, seems so.

Joined: Thu Jun 30, 2005 1:54 pm
Posts: 327
Location: USA

Re: How did SNES render graphics?

You mean 60 FPS, right?

The duration of a scanline can vary somewhat, but it can't be twice normal and be displayed by most TVs. I'll have to do a test soon, but I imagine hires causes the SNES to output pixels at double the normal rate, rather than output scanlines at half the rate (both would result in 512 pixels per line, just with differing timings). Assuming the former, the TV wouldn't see any difference between hires and normal res.

Maybe because there is a 256-pixel limit in non-hires mode? And 'n-bit' system isn't a precise definition of what the system can do. It usually refers to the number of bits in the CPU's accumulator. The graphics subsystem is usually separate, and has its own bus(es). As a counter-example, I believe the Master System can do 320 pixels per scanline, even though it uses an 8-bit processor (Z-80).

Joined: Wed Jul 28, 2004 4:15 pm
Posts: 5615
Location: PAL50, dood !

Re: How did SNES render graphics?

Yeah, brainfart ¬_¬

Joined: Sun Mar 15, 2009 11:09 pm
Posts: 43
Location: Ireland

Can someone explain... why is it 30 frames per second and not 29.97? Is it just commonly referred to rounded, or does the NTSC SNES actually output video at exactly 30 (60?) frames per second?
Also, how does one calculate exactly how many master clock cycles each frame takes?

Joined: Mon Apr 28, 2008 10:54 pm
Posts: 77

Not an SNES person so others can probably answer better, but this might be helpful...
I don't know the exact framerate of SNES (probably not exactly 30 like you said), but I can tell you that TVs have some laxity in the timing of hsync, vsync, etc signals that allow the framerate to vary slightly. Different consoles tend to have very slightly different framerates. This is not just dependent on the scanline duration but also whether it does 'progressive' mode with 262 or 263 lines (even or odd).

Each scanline takes a certain number of master clocks (probably around 1365), although from what I understand, the number varies a bit on different scanlines, on the SNES. The master clock would drive the dot clock of the PPU, and the timing of the NTSC signals are derived from this. If you're asking how people found out what these timings are, then I guess a lot of clever software tests and possibly looking at the signals on an oscilloscope.

Spoiled us, we have a register that latches the video counters when read, and you can get the exact V/H counter positions from that. H only increments every four master clocks, but I'm sure you can guess how to get around that and get exact numbers for every possible cycle (sans the easily observable DRAM refresh.)
NTSC S-SMP was clocked with an oscilloscope via the alpha-ii guy, everything else has been taken from tech specs which are more 'ideals' than reality. PAL S-CPU is the most made up, I don't even know where the number we use (21281370hz) comes from.
Math: (1364*262*60)-4*30=21441960. Not quite 315/88*6MHz=21477272. Eg 21441960/21477272 ~= 60/60.09 ~= 0.9984
In my early days, I used to think there was some exact correlation, but really it's just that crystal clocks aren't anywhere near perfect. There's variance (tolerance) between every last one manufactured. It really doesn't matter so long as you're within the acceptable range.

Joined: Sun Mar 15, 2009 11:09 pm
Posts: 43
Location: Ireland

I wondered about that too.

This timing is still something that has me really confused. Actually it's a few different things...
I understand the 1364 master clocks per scanline comes from 341 H-positions * 4, but I also read I think a couple of different docs that quoted it as 0 to 339 (i.e., 340). Is 340 wrong or just for different configurations?

Is this where the extra -4*30 comes from in the formula?
And my final question, if a field takes (1364*262)-2 (?), that must leave many clock cycles (~588.5) spare before it's time to start the next field, so how does that appear to games on the SNES? Just an extra part of a V-blank line?

Joined: Mon Apr 28, 2008 10:54 pm
Posts: 77

That's slick, I wish PC-Engine had that. To find where in the cycle things get latched I have to generate code on the fly nudging nops forward to get an exact range (for finding where vblank fires I had this happen automatically with a binary search >_>)
The SNES's slow CPU probably makes it hard to poll in real time but I bet you can use DMA or something to do it for you instead.

It looks like that means one of the lines is missing a pixel every other frame/field (same thing in this case IMO). Someone else could clarify exactly where it's missing, of course I'd be more interested in knowing why, and if it happens in interlaced mode et al.
By the way, does hires mode (512 wide) increment the H counter at twice the rate (2 master cycles per increment)? Or is only the dot clock driving output twice the speed?

I think what byuu was getting at is that there are no missing clock cycles inbetween frames, it's just that the frame rate isn't exactly 60Hz and the master clock isn't exactly 21477272 Hz (and varies from unit to unit).

Man it's nice talking about technical stuff again. How I miss the days of talking to anomie and TRAC like this, but being on the receiving end of new information :(

This will be a long one. Let me start by saying you really don't need to worry about this unless you want as much accuracy as possible. I'll skip PAL timing except to say that I don't think it has a missing dot, and there are 625 scanlines to NTSC's 525. I've never run tests to be sure. Now for NTSC ...
Non-interlace, eg progressive mode:
There are 262 scanlines per field. Each scanline is 1364 clocks. There is a 40-clock DRAM refresh that triggers between cycle 530 and 538. The exact position varies per scanline and per CPU revision. Look at my source if you want to know exactly.
The PPU dot counter has what are known as 'long dots'. While almost every PPU counter dot is 4 clocks long, eg 1364/4=341, there are two long dots per scanline that are 6 cycles each (eg there are three positions where you'll get the same value from them). These are most often dots # 323 and 327 (starting from zero), but sometimes 322 and 326. When I setup a test that polls at a specific position, I realized they change on the fly. Get it right on that edge and 90% of the time you'll see one value, 10% of the time it's two clocks smaller. I have no idea what long dots are or why they exist. The S-CPU keeps its own internal H/V counter for IRQ testing that is not at all affected by long dots.
For emulation, I recommend keeping one true hclock position counter, and when HCOUNTER $213c is read, do the long dot adjustment there.
Next, there is the odd case of non-interlace scanline #240 (starting from zero). It does not have any long dots, and is 1360 clocks long. You'll note that this effectively means every scanline has 0 - 339 for possible HCOUNTER positions.
Interlace mode:
Even scanlines (where $213f.d7 = 0) has 263 scanlines, 1364 clocks per scanline. Odd scanlines ($213f.d7 = 1) has 262. The two fields make up 525 scanlines for one full frame. There is no one-dot-short scanline, and they all have long dots.
You can modify the interlace setting mid-frame, and it will affect tile indexing immediately, but it won't actually change the video mode until the start of the next frame. I don't know when this register is actually read to determine the next frame's mode (probably around V=0,HC=0), or if it's every field (~60 times a second), or every frame (~30 times a second).
For both modes, there exists a 'dead dot' for CPU IRQs. If you set VTIME=last possible scanline, and HTIME=339; even though it's a valid dot, an IRQ will never trigger. I assume this is because the PPU's Vblank pin is four clocks mis-aligned against its' Hblank pin, so the CPU's internal counters are getting reset too soon.
Even more bizarre, when you first power on the SNES, for the very first field, the S-CPU's VTIME cached counter is off by one. If you set a VIRQ for line 200, it will trigger on line 201. It auto-corrects itself after the first field and works as expected from then on.
I don't know of a single game that relies on any of the above to function properly, and I only emulate ~80% of it. It's a major speed-up to share the PPU and CPU counters, and the only easy way to run them out of order without a state machine.

That's from the NTSC 'short' scanline mentioned above.

That was my point, the 'spare cycles' don't exist. It's erased by the fluidity of oscillators and flexibility of NTSC signal timing. Progressive mode completely erases the '525th' scanline, as you get 0-261 * 2. Only interlace has the extra scanline. This also explains why progressive = ~60.09fps and interlace = ~59.97fps (and anything in between if you switch during a second). Good luck accounting for that when you want to sync video and audio to get smooth video + crackle/pitch-shift-free audio.
I should also note, what the TV is drawing and what the PPU tells you its at are two different things. I suspect that PPU HCOUNTER = 0 is really the TV in the left porch / H-retrace position. I believe pixels actually start getting written at HCOUNTER = ~22 or so. Explains why Vblank is at ~278 or so nicely. Extra time helps with fetching OAM and setting up the scanline states.

DMA is too slow, and the DMA / CPU synchronization timing is so ridiculously complex that you could probably never figure it out on your own to be useful. I doubt anyone besides me and anomie even understand it.
What I did was write a special function that checks counter positions twice with a special offset to determine if we're on a half-dot (HCOUNTER is divisible by clock rate by four, but S-CPU can step by two clocks), seek within ~250-350 cycles of V=0,H=0 relying on VCOUNTER, compensating for all of the overhead of the function itself after the above sync, and then jumping into a computer-generated table of functions that execute between 200-400 cycles and return. The end result is when you call:
... you are at exactly V=0,HC=0. I also wrote a function that you can put lda #anything>800 or so. Call it plus jsl seek_cycles and you go exactly that far ahead from the current cycle position.
With those two functions, I write tests that poll whatever I want every single clock tick possible and store results in RAM. I run it on real hardware and in my emulator until the two sync up perfectly.
This is the other part of the reason I don't release my test ROMs. Nobody else gets the timing exactly perfect, so the jsl seek_frame function fails and is something like V=0,H=12. This instantly causes all of my S-CPU timing tests to fail, even if their implementations are otherwise correct. So a fail isn't really a fail.

It only happens in non-interlace mode odd frames. My understanding is that it's to cause an NTSC color sub-carrier pulse, which does something involving the 'staggering' effect you see with NTSC video in progressive mode.
I know the NES had the same thing, but it was possible to override it. Battletoads did this (intentionally or not), and subsequently stopped this effect. With the SNES, there's no way to override it.

Nope. Hires mode just fetches more data at lower BPP modes and tries to draw the main screen and sub screen pixel data separately, rather than blended together. The exact details are ungodly complex and took me many months to get exactly right.

Joined: Sun Mar 15, 2009 11:09 pm
Posts: 43
Location: Ireland

Thanks byuu for the very long and detailed answer.
With the major exception of having atomic opcodes, I'm aiming for timing perfection. I've followed every datasheet precisely (or tried to, though there are probably still mistakes).

I thought it was just 18 master clocks overhead per invocation, plus 8 overhead per enabled channel per invocation, plus 8 per byte (i.e., transfers at 2.68 MHz), plus the possible 40 for DRAM refresh if it happens during DMA. I think it must have been one of Anomie's docs I got that from. Is there more to it? Also, sorry for all these questions, but (does anyone know) what happens to a scheduled IRQ or NMI if DMA is active? Does the interrupt get ignored or delayed?
By the way byuu, your source uses 21,477,272. If it's 1.89E9/88, isn't it closer to 21,477,273 after rounding?

I wish you luck with that approach. Not going to be easy.

A lot more. 18 comes from an average of the possible 12 - 24 cycle CPU->DMA sync rate. DMA runs at clock / 8 always. It also synchronizes back to the CPU's last executed cycle speed once finished (-- you execute one more cycle after DMA begins and record that cycle speed.)
It's going to be really tough to support that with atomic opcodes and DMAs that can last up to 1/6th of an emulated second.
Might be somewhere on this board history, or anomie's advanced timing notes. Otherwise:
src/cpu/scpu/timing/timing.cpp:(pre)cycle_edge(). It's tough to read, because it's really tough to emulate :/
Another thing no game relies on*, but if you want to get the counters perfect, you'll need to worry about this.
(* Mecarobot Golf relies on proper HDMA order-of-operations once you get timing close to perfect. The docs are pretty much all wrong on that.)

Delayed. It also won't occur on the next cycle test immediately after DMA ends. Don't know why that is, probably something to do with the two-stage pipeline. If you don't support that one cycle delay, Wild Guns will flicker like crazy in-game.
DRAM refresh > HDMA > DMA* > interrupts > opcodes.
(* HDMA on the same channel cancels active DMA -- needed for Bugs Bunny + Marko's Magic Football)

It's easier to state it as 315/88*6MHz (I don't even know what E9 means, honestly). And yes, but 21477272 is divisible by eight. Since the exact number doesn't matter, I went with something more friendly.

Joined: Wed Jan 25, 2006 7:57 am
Posts: 2081

scientific notation. 1.89E9 1.89 * 10^9 ~= 1890000000 (accurate to three significant figures).

JSNES Developer

Joined: Sun Mar 15, 2009 11:09 pm
Posts: 43
Location: Ireland

Yikes all mighty. I think I'll just shove that into a /* FIXME */ comment for now and move on.