Direct HDMI output for N64 (and other consoles)...

@OzOnE: thanks i got it. i forgot you were using an external vga-sync so of course the tv will show it is getting 480p whatever you input. it is great that your tv does the automatic deinterlacing though.

does N64DD mario intro has 626 horizontal lines? did you have a chance to try a low-res (320 horizontal lines game) to see if the sync is still valid? does TGR output 320 horizontal? do you have a way to know for sure? it would be good to test both low-res and high-res games to see if the sync is still valid, though i see no reason for your setup not to work in both situations.

 

Yep, it definitely dithers the output, but I think that can be disabled in the VI regs. I'll have to try a 640 game like Indy Jones and see how the LSB toggles?
I never thought about what it would do in 640 mode, it will be interesting to test.

Looking at the MESS source, the VI is fairly complex - it also buffers a couple of spans so it can do the coverage stuff / linear interp / gamma correction.

@reprep - It's using a block of "VGA" sync code inside the FPGA. This is purely to generate the correct video timing though.
I found that the best document for the timings is the CEA-861-E pdf because it's a bit clearer about the number of lines / pixels for blanking / sync etc.

The handy thing is that even if the input from the N64 partly screws up (due to my less-than solid test wiring), the HDMI output should at least be stable.
The code uses the "VCLK" from the N64 though, so if it loses that clock, the whole output stops. If I use a separate master clock, the output isn't phased-locked, so the quality is worse.

The 64DD intro is definitely 320x240, but it's roughly 626 pixels across a line, not 626 vertical lines.
Most N64 games use low-res, with a 16-bit framebuffer too.

The confusing thing is that NTSC is often referred to as being "525 lines", and PAL is "625 lines", but some of those lines are used for blanking, so they're never normally used for active video.
The standard now is that only 480 of the NTSC lines contain actual video, and 576 lines for PAL, hence the 480i / 576i labels.

When the N64 outputs low res, it doesn't need to change the output timing at all, it just repeats each pixel twice to fit the (up to) 640 possible pixels per line...

Framebuffer = 012345678
Pixels per line = 001122334455667788

(btw, I know 480i / 480p normally has up to 720 pixels per line, but many consoles would only consider NTSC to be around 640 due to overscan etc. This also helps for displaying "square" 4:3 frames like 640x480 on an NTSC TV. On a PAL TV, it was considered to be closer to 800x600, so this is what many PC-to-TV adapters output in PAL mode).

The main pixel clock on the N64 is ~12.5MHz. We can assume that because the digital vid bus updates at ~50MHz (VCLK) and there are four "bytes" output...
eg. SYNC / RED / GREEN / BLUE. So, it can only ever update a full pixel once every four VCLKs (AFAIK).

If it was outputting low-res at 60Hz progressive, then I guess it would also be duplicating each line twice to make 480 lines from the 240 framebuffer lines?

But because it outputs interlaced @60Hz, I think it takes the full 240 lines from one framebuffer frame (for the Odd field), then takes the full 240 lines from the next frame (for the Even field)??
(assuming the RCP was fast enough to update the framebuffer at 60 fps, otherwise it would just repeat the last rendered frame).

And that's what causes the interlacing artifacts. On a static animation the two fields should be fairly similar, but when something is moving, the two fields are different.

For 640x480 hi-res modes, I guess it would have 30fps internally? So, each field would then show the ODD and EVEN lines of the framebuffer for each frame.
That way, both fields together would contain the full 480 lines of the framebuffer??

Or, more likely is that it just outputs the ODD lines from one frame, then the EVEN lines from the next frame.
If that's the case, then you'll only really see the benefit of the higher resolution when parts of the image are static over two frames?
(A modern TV can do a fairly go job at de-interlacing that sort of image, but I don't think it could ever recover the original quality on moving animation?)

AFAIK the output timing should not change depending on the internal game resolution??
I don't code for the N64, but surely the standard output timing is only ever NTSC or PAL or maybe PAL60?
A standard TV can only sync to one of those timing specs, and that's all the N64 was ever designed for.
There's always been lots of confusion around what "resolution" means on these older consoles?

Does the PSX change the actual output timing in any way? (other than NTSC / PAL / PAL60)??

These are all interesting questions 'cos I've never put too much thought into it before. :confused-new:

I don't think TGR is hi-res in the game itself, but the menu text looks hi-res?

I can look at some of the pixel data for each game, but it's hard to tell where pixels are being duplicated because the VI does all the extra magic like anti-aliasing / anti-flicker etc.
So in some ways, you could say that the VI is generating NEW pixel data from the original framebuffer image. I don't know exactly how this works across a line, or for each line?

There, that's the short answer. :cool-new: :highly_amused:
OzOnE.

EDIT: OK, I can confirm that in 320x240 games, both fields look identical. This means that it's doing simple pixel / line doubling (as expected).
Ironically, the only slight artifacting I'm seeing is due to the TV detecting the two fields and trying it's best to weave them together. It actually does need to do that for low-res games.
I'm now just putting the V64 back together to test some PAL and hi-res games.

I also want to try capturing the pixel data to SD card at some point.
It would probably be the first time the pixels are captured digitally from the video output (rather than from the framebuffer), so would be great to analyse the fields using the PC.

 

Only w/ (non-square pixel) BT.601 video, definitely not N64 video. Nothing to do with overscan, there are 720 active pixels w/ a 13.5 MHz pclk. N64 has nearly square pixels @ 6.0852265 MHz, there's no harm in representing them as perfectly square, as long as the two dissimilar line timings are are synchronized.

Huh? There's 240p or 480i, both have the same pixel clock and nearly the same timing.

I really doubt games render 640x480 interlaced with unique fields (so 60 fps in a way), it would have noticeable mouse teeth and motion interpolation is just too much for the 64 computationally.

More practical is to set the FB to physically scan out @ 30 Hz, (most games will have logical framerates<= 30 fps anyway) and the rasterizer should know to take even lines for the even field and odd lines for the odd field.

If 256 H mode exists then it has to, no way 256 H is interpolated into 320/640 H.

The PS has 3 or more pclks, and has programmable line timing, so yup.

 

My point exactly. His idea still doesn't make sense. I can't think of a good reason why N64 would interlace 240p before output, when properly behaved TVs will do that anyway for zero computational cost to the N64.

 

the output timing surely changes for PSX and PS2 for different modes. and for N64, it will surely change for 50 hz and 60 hz modes. about the difference between hi-rez and low-rez, i can't say but i guess it doesn't change.

also sorry for my last post. i meant 626 vertical lines (or 626 pixels for a line) not 626 horizontal lines.

 

Yep, I see what you mean now. This "full" horizontal res is normally only reserved for non-square stuff like DVD and STB decoders etc.
I guess the N64 would only ever output a maximum of 640 pixels across a line then. It doesn't make sense to use more.

Although, I'm wondering if the N64 could do some custom resolutions, or did Nintendo / SGI "cripple" the VI too much?

OK, but does an N64 ever actually OUTPUT 240p to the TV? I don't think it does?
Yes, the internal framebuffer might be "240p", but it outputs the two FIELDS to the TV by duplicating the same lines for both fields...

240p (320x240) Framebuffer lines...
1
2
3
4

Output for ODD Field...
1
2
3
4

Output for EVEN Field...
1
2
3
4

Effectively becomes this on the TV (480 lines, but representing the original 240 lines of the framebuffer)...
1
1
2
2
3
3
4
4

I don't know of any "standard" NTSC or PAL TV which accepts 240p as direct progressive frames?

I suppose technically you could call it a 240p "mode", but surely the console still has to output this as two separate fields?
In fact I know it does, I've just tested it. :encouragement:

Or are you saying that some console modes output 240p (still 60Hz vsync), but the fields overlap??

I don't profess to be an expert on all this stuff, that's why I posing the questions, but I'm certain the resulting output signal to a standard TV is always interlaced.

The N64 doesn't need to do any "processing" to the output to generate the fields, it's merely repeating the same framebuffer content for each field.
Almost all NTSC / PAL consoles do some sort of pixel / line doubling to display lower resolutions on the TV?

Agreed, I don't know why I thought it would be 60fps on the N64, I had a brain fart. lol
So, for high res games, the two fields really are different, and just represent the Odd / Even lines of a single 640x480 frame in the framebuffer.
(I'm still trying to get the V64 working, 'cos it would be nice to see how high-res looks on this thing.)

Interesting, can most standard TV's sync to these modes though?
I know there are some weird "extra" modes on some consoles that it may possible to display on a TV, but do any of those output progressive frames?

I don't know much about the PSX. So it can change the pixel clock to display more or fewer pixels per line, but does the sync timing stay similar to standard NTSC?

OzOnE.

 

Wikipedia: Low-definition television...

"Older video game console and home computers generated a nonstandard NTSC or PAL signal which placed both fields on top of each other.[SUP][1][/SUP][SUP][2][/SUP] This is equivalent to 240p and 288p respectively."

Ahh, see, it's not really a true progressive mode. I didn't think I was completely crazy. lol
Basically, it still outputs two Fields, but the timing is altered to get rid of the half-lines. This makes the fields overlap (and hence some nice "black" scanlines in between).

It can't be considered "standard" NTSC timing, hence "Conversely, the FCC forbade TV stations from broadcasting in this format.".

The point is, the N64 still outputs two fields no matter what the video mode (in any commercial game that I've seen that is).

OK, so we're all correct in some manner - for all intents, they might be named "240p" or "288p" modes, but really the timing is slightly modified to force the TV to overlap the two fields. :encouragement:

Mystery solved.

I'm not seeing any half-line type timing on the 64DD logo, so is this considered 480i?

OzOnE.

 

This is very interesting indeed, keep us updated OzOnE

Is it true that Resident Evil 2 would switch between low and high resolution depending on how many enemies are on the screen. It definitely did look that way when I played it- the screen would go black for a second between scenes, that is when going from one area to another. I could be wrong

 

Hi, Pikmin,

It's very confusing, I know that much. lol

No idea about Res Evil 2. I don't think I've played it since it was released on cart.
I guess it would make sense that it switches modes if it was between scenes?

Maybe this could be tested on an emulator with a LLE plugin?


Ooops, I meant 240p for the 64DD logo of course...

Actually I haven't played the N64 on a CRT screen for about nine years, and then it was mainly PAL games.
I remembered the scanlines being quite bad on NTSC games, so I tried to get the PAL games where possible.
On a modern TV it seems to smooth out the scanlines quite well, so it's not so harsh on the eyes.

I'd completely forgotten about these "240p" type modes, so that explains why NTSC games looked quite bad.

I've noticed since that NTSC TV broadcasts generally look better than I'd imagined.
Now it's clear that this is due to them being 480i vs "240p".

OzOnE.
P.S. I decree, from this day forth, that "240p" and "288p" should be enclosed in quotes. lol :sneakiness:

 

Ack there's way too much to reply to >_<

It sounds like you're confused about TV fields. Each field is 262.5 lines tall, with 240-243 of them being active video. Each field is rendered ~60 times/second. What you're describing sounds like 480 lines/field, which would be 960i. In progressive video a field is a frame, there's 0 difference.

The N64 does output "true" 240p. 240p can be considered "malformed" 480i, or on the flip side you could consider 480i augmented 240p, which is closer to the way analog television understands it. Either way it's very real, and unlike a lot of explanations progressive video isn't a trick that exploits the circuitry, really it's the other way around, interlacing is the trick.

The only time the N64 interlaces video is when the game instructs it to. If 240p was transmitted over 480i (it used interlaced line/sync timing) the TV couldn't tell the difference and it'd distort the video by interlacing fields inappropriately.

Analog TV is analog so the horizontal (and to a degree vertical) resolution is arbitrary. 720 pixels != "full resolution", 720 just represents the number of pixels roughly fitting into the analog active video period for a specific pixel clock -- 13.5 MHz, which is the most popular pixel clock for SDTV. For another pixel clock such as the N64's 12.16 MHz 640 pixels make up the same active video period.

I'm totally lost on the "overlapping fields" stuff. Progressive video paints each field exactly over the last. Interlaced video paints one field in between the other with the glow of the phosphors slightly overlapping so that your eye sees a gap/scanline free image.

Modern TVs don't smooth out scanlines since scanlines don't exist in a video signal. Scanlines are just the gaps between the raster from line to line, and the presence of them/how bad they are etc depends entirely on the display and how it's calibrated. You can either increase the raster thickness or decrease the vertical size so that the raster converges to get rid of them entirely. Or just use a modern fixed-pixel display where each line is flush against the line above it.

 

I realize what fields are, but as you say the 240p mode could be considered a "kludge" in order to show 240p on a display originally intended for interlaced display.

No, the board is outputting 240 lines/field, but I now realize that both fields contain the same image / data.

What I was pointing out is that 240p from the N64 is still output using a modified version of the original interlaced NTSC timing "framework", so technically there are still two fields, hence vsync is still ~60Hz.
The only difference is the modified timing causes the fields to overlap (ie, display as "progressive" frames, as you say), and so you effectively get a 240p display.

I understand the difference now, it's just been many years since I messed with video stuff.
(The whole 240p style scanlines thing seems to be more popular with people who did / do a lot of arcade gaming.)

240p / 288p is still a kludge really.
AFAIK, it wasn't exactly part of the design spec for the older CRT TV's to display these types of modes. :smile-new:

I see now that there are no half-lines on the 240p image I'm getting on the 64DD logo screen. Does it really have noticeable scanlines on a CRT, I can't remember??
But, I'm still storing and then displaying both "fields" of the 240p image and interleaving them before the VGA / HDMI output block (even though both fields contain the same data).

That means I'm not getting scanlines in-between because I'm not overlaying the two fields on top of each-other (should the term "fields" still apply with 240p, or would you just call them "frames")?

OK, so the effective "framerate" for 240p is 30fps, but vsync is still ~60Hz. hmmmm. lol
If it was a true progressive 240p signal @30 FPS then it would be outputting 240 lines at 30Hz, and that was my original point.
(the TV scans TWICE for every animation frame).

So, for 480i games, the design should still work and display the full resolution. The only problem is that the TV might get confused and try to de-interlace the fields again (since they contain different data, yet I'm outputting them in a single progressive frame).

I tried to get it to work with the VGA block running with 640x480 timings, but it messed it up for some reason?
It only seemed to work properly when I output at 480p (720x480) instead. Although, as expected, the image is a bit squashed. :moody:

Yes, you're correct, "overlapping fields" is what progressive modes always do, but with 240p / 288p they achieve the same thing by slightly abusing the NTSC / PAL standard.

I think it's important to note that with true interlaced source material, the fields are obviously taken at a different time offset (eg. with a TV camera etc.).

I didn't mean that the scanlines actually "exist" within the signal itself, but I'm assuming many modern TV's do in fact do a certain amount of processing when they detect a 240p signal.
At the very least, they would likely double the lines again to generate 480p frames (albeit with the same effective 240p resolution) before scaling it to the panel res.

I think this is all started as a misunderstanding of the terminology on my part (and the fact that I'd forgotten how the 240p / 288p type modes worked on older displays).

What I said about the "fields" still holds true though...
When people say 240p, you can't in all honesty call it a true "progressive" signal - There are still two fields being output per every original frame.
OK, so the end result is a progressive display, but it's the way that the signal is conveyed within the normal TV standards that I found confusing.

Interesting though. I've just tried enabling "scanlines" on the FPGA and it looks quite nice on the 64DD logo (a bit dark though).

OzOnE.

 

People say that, but that's not how the hardware sees it. All analog displays are capable of displaying progressive video, even if due to their phosphor persistence they aren't best suited to it. The raster wants to keep painting progressive video, but the interlaced sync signal shifts the vertical PLL to offset the line. What made 240p inappropriate for broadcast is that it's useless for natural camera video. Since each field coming out of a camera is technically different there's no downside interlaced video in high-motion scenes, until you try to deinterlace it.

You mean as a rule? N64 is definitely 60 Hz / 60 fps progressive. Many games however may have run at significantly lower logical frame rate because they have to. All consoles are like this, they either drop some frames here or there or they have slowdown or game logic runs at some fraction of 50/60 Hz.

? That's what 240p always does, it's one field painted over and over and over and over with consistent timing, instead of alternating the timing to "exploit" the PLL to offset the raster.

? Vsync is always ~60 Hz, even with interlaced video.

It makes absolutely no difference to an older CRT, they don't even realize they're displaying progressive
video, they're dumb, passive devices.

What's a half-line?

Whether 240p will have "scanlines" depends on your display.

Why? Interleaving them is basically deinterlacing them, and progressive fields aren't meant to be viewed as such. You're doing what thousands of retro gamers complain their fixed-pixel TVs do to 240p video, but electively.

As I said you're not getting scanlines because scanlines don't exist in the video signal. They're a CRT artifact. Fixed-pixel displays are nothing alike, they dont' even have a raster for there to be gaps between lines. To a fixed-pixel display each incoming video line is placed exactly 1 pixel below the last (until it's scaled to another resolution).

Either is correct as long as the distinction is made that each field has the same timing as the one before it, and that it may contain unique active video meant to be viewed sequential to the field before it instead of concurrently with it as in interlaced video.

No the framerate is 60 fps as well. The game may however run at 30 fps, or 20 fps, or 15 fps.

Vsync is always the physical field rate. But since each field in progressive video is also a unique frame, it's also the frame rate.

? Consoles output "true progressive 240p signals" @ 60 fps/60 Hz. What makes 30 Hz true opposed to 60 Hz? CRT TVs weren't made to sync that low, nor were their phosphors capable of glowing for (1/30)s.
240p30 is <1/4 the resolution of broadcast TV so it was introduced as a computer media format to save disk space/bandwidth/clock cycles.

This could be for so many reasons. N64 timing is dissimilar to broadcast timing, so either you have to bend the broadcast timing by giving the display timing synced to the 64, bend the N64 timing (not possible), or selectively add/drop blanked pixels from the N64 video using a high precision accumulation algorithm so that your buffers don't over/underflow.

Modern TVs typically do not add fake scanlines which is an artifact. Nobody but particular retro gamers cares about them and it's unlikely most TV engineers even take them into consideration.

Scanlines are analog so to view them properly takes a significantly higher resolution output, and it takes some video processing to get the look right.
Sure blanking every other line in 480p video is sorta kinda similar to the real artifact in principle, but it looks very different because the 480p version has none of the analog characteristics. You'd get a better effect if you scan-doubled the 240p image, then dimmed odd lines 10%, but that's still nothing like the real thing.

 

The N64 always displays values at a rate that is comparable to 640 pixels horizontally. It fetches one or more lines from the display buffer to fill those pixels - it may actually fetch from the line above and below the one currently being displayed in order to calculate a dithered display pixel, depending on the mode you've selected. Let's assume it simply fetches the line to be displayed.

All timing for a line is in terms of the 640 pixel clock... you specify where the line starts showing data, where the line stops showing data and starts blanking, where the sync is, and where the color burst is - all in terms of those 640 pixel units. You normally pick a start and end that shows 640 pixels in the center of the active area for a line. There's one more thing you specify - the horizontal magnification: this tells the display how much to scale the fetched line to fit in the display pixels. For a 320 wide display, the scale is 2:1. In the N64, it's set as 1/scale, or 0.5. This value is set as a 2.10 fixed point number, so it's 0x0200 in hexadecimal. This value can be ANYTHING within the limits of a 2.10 fixed point number. I made a 256 wide display using the value 0x019A, which is 0.4, or 2.5:1 for the scale. You use 1.0 for the scale/value for a 640 wide display, which is 0x0400. You can also do 512 wide using a value of 0x0334, or 0.8.

There's an example program for the N64 in the libdragon toolkit that shows the display modes 320x240, 640x480, 256x240, and 512x480. It draws a box and diagonals with text to help show the edges of the display so you can measure the overscan on your TV. It's called VidResTest. Here's a new build in v64 format:

http://www.mediafire.com/?5bbuo598lddmt4y

Press A to advance to the next resolution. I tested it on an NTSC N64 using the N64 Myth flash cart, but anything that can handle v64 format should be able to run it. If you get libdragon, look in the display.c file for all the timing values for the different display modes - it supports NTSC, PAL, and MPAL.

 

@Calpis - I understand what you're trying to say and you're being helpful, but I didn't really expect this to turn into a huge debate.

I've mentioned that I'd forgotten the 240p / 288p modes even existed, and I think this is what started the ball rolling.
I actually used to do TV / VCR repairs for many years, but that was a very long time ago and I have memory loss to a certain extent (medical).

So, with that in mind, you can see how I couldn't understand how 240p / 288p would work on a display which normally accepts an interlaced signal.
I knew there had to be a reason why this is, and as soon as I saw the wiki page I remembered how it worked.

Many of your questions can be answered by saying that: this is purely from what I've observed by doing the HDMI project.
So, I'll try to explain it from that point of view...

The original code I used was for taking a bt.656 stream from a TV decoder / ADC and writing it into an SDRAM buffer.
Naturally I just "plugged in" my N64 vid decode block into the SDRAM buffer, then let the VGA block read the data back out as usual.

The code is still seeing the same 60Hz vsync rate as before, and simply sampling the "fields" / "frames" as it did before...

The VGA output was then routed to the HDMI output block as well.
So, obviously it's going to be reading both "fields" into memory as it did for interlaced signals.

Just as a CRT doesn't seem to care about whether the image is interlaced or not, the code expects the "fields" / "frames" to be placed one after the other.

At this point, I'm only dealing with the usual 240p mode from the N64, so when I said...

...yes, of course this stands true for 240p that I'm seeing from the 64DD logo, but not as a strict "rule" obviously. It depends on which other modes may be used?

Also, I realize that most consoles need to drop frames etc. and this is what almost all consoles / PCs do if the GPU can't quite keep up.
It's also possible with 240p / 288p that each frame may be different, but this is not what I'm observing with the simple 64DD logo (both frames appear identical).

OK, technically you could say that it's "1.5 lines" or "262.5 lines" or whatever, but the term "half line" is quite common with interlaced signals.
I merely pointed out that 240p does NOT show these "half lines"?

Do you mean that some CRTs will offset the second 240p "frame" by one line, or are you talking about things like modern LCD / Plasmas?
That's exactly the point I was making earlier. Even with the second "frame" blanked on the FPGA, my modern Samsung LCD still appears to "blur" the scanlines quite a bit.

In contrast to an old CRT, which generally just displays the 240p / 288p content with resulting noticable "scanlines" in between, the modern TV seems to be doing extra
processing to attempt to merge the lines together a bit. (it's not just because the resolution doesn't match the panel 1-1, it genuinely looks like some interpolation is going on).

Precisely, but the difference is, I AM offsetting the second "frame" of the 240p data so it fills in the "gaps" between where the scanlines would normally appear on a CRT.
Obviously on a CRT there's no actual raster where the scanlines appear??

The reason it's offsetting the second "field" comes back to me using some code which was intended for capturing an interlaced signal.
So, when the VGA block outputs, it's alternating between the two "fields" in the SDRAM buffer on each alternate VGA line.
The result for the 240p input from the N64 looks fine, because the "fields" for the 64DD logo look identical between the alternate "frames".

I'm wondering how it will look with various games and 480i modes. That will be the interesting part.
The TV is only "seeing" a progressive VGA / HDMI signal, but as you know, the TV's scaler can detect many different interlacing and pull-down modes, then it will try to extract the "best" image from that info.
So, if it happens that the two fields of a 480i signal from the N64 do contain different data (even for short bursts), the TV will likely try to weave the fields together in some way (even if the data is presented as progressive frames).

Yep, and that's exactly what I meant - the internal "game" frame rate for 240p is generally 30 FPS. :wink-new:
Again, this is getting into semantics tbh. lol

It wasn't really "electively" as such. I just used the code blocks which I already had, and you can see the answer above as to why the "frames" get interleaved by the code.
The aim was simply to get the code working to an extent, then worry about the finer details afterwards.

What would you say is a good way to present the 240p frames as a signal with 60Hz VGA (640x480) or 720x480p timings?
I'm looking to add some sort of hq2x filter as well, but how would I go about detecting a 240p / 288p output to decide how to process it?

The other point is - when I get the V64 running again to try some "480i" games, the interleaving might lend itself nicely to the source.
With 240p and interleaving as it's doing now, it looks pretty damned good to my eyes. Do you think some 240p games will have different looking alternate "fields"?

I see your point, that's why I'm asking what would be considered the standard "naming" convention for such signals.

But, when you say

..that's what I meant by "true" progressive - if the internal animation framerate is 30fps and the 240p "framerate" is 60hz / 60fps, then surely each two adjacent TV "frames" are going to contain identical data (assuming it's doubling frames to produce the 60Hz output)??

I can see why many people like the "scanlines" appearance. As I say, I think it's mainly enjoyed by people who did a lot of arcade gaming back in the day.
It does seem to add a nice effect and some perceived "sharpness", but personally I'd only ever use it if the original source was at that resolution.

What I can't quite get my head around is actively wanting to throw away half of the vertical resolution from a machine which clearly outputs something like 480i or 480p. lol ?
eg. here is a nice vid about the SLG Scan Line "Generator" (quotes definitely required - Calpis, I'm sure you'll know how the SLG "works". hehe)...

Check around the 28:08 mark for the destruction of half the resolution from the Wii...

http://www.youtube.com/watch?v=nSQ3lmE6UuY&feature=plcp

OzOnE.

 

Thanks @Chilly Willy!

That will be a VERY handy app for all sorts of tests. :biggrin-new:

Do you know if it's possible to manipulate the VI reg values to get even higher resolutions out of the N64?
ie. does the VI_H_WIDTH / VI_H_VIDEO regs "max-out" around 640, or can they be pushed higher within the boundaries of the pixel clock (possibly with fewer lines?).

Also, do you know how the serrate flag operates? Does it enable / disable the serrated sync pulses as well as changing the vid timing for interlaced?

Would it be possible to patch a ROM image for 480p output, or is the pixel clock the limiting factor?

Regards,
OzOnE.

 

240p video is typically exactly 262 lines, the "half lines" only exist for interlaced video, they are the actual mechanism which causes video to become interlaced. Even in interlaced video they are not visible if that's what you mean. They're caused by vsync occuring a half a line early every other field, instead of at the same time as hsync, which results in the next field being painted between the raster of the last field. In progressive video vsync consistently occurs at the same time in relation to hsync.

http://www.sparkysworld.co.uk/images/interlace.gif

From that quote I meant that LCD/Plasma cannot have scanlines because they aren't CRTs.

Modern TVs don't need to because scanlines don't exist as far as they're concerned. They receive signal information, quantize it into a pixel buffer, then scale the quantized frame for display. Scanlines are the consequence of CRT rasters not being thick enough to converge because they're calibrated for interlaced video, CRTs "create" them as video is being painted.

Just line double them to 640x480.

Anytime the game has motion since you've combined fields there will be "mouse teeth".

http://www.dvcreators.net/wp-content/uploads/2008/08/interlacing-article-graphics-3.png

Maybe your TV is suppressing this. Don't take it for granted since not everyone uses a TV for viewing digital video, I personally use a DVI monitor that only displays exactly what's thrown at it.

240p? I don't get it.

There's no telling whether consecutive frames will contain identical information or not. Even if they did, there's no way to know which to synchronize with. Why is it a good thing to deinterlace progressive video anyway? There's no point.

 

Ahh, I see what you mean now. I think I've got it.

Basically, I was stupidly assuming that two consecutive 240p frames would have the same content if they are both taken from a 30fps "animation"...
Of course, there's no direct way to tell which TV frame comes from which framebuffer frame. 240p IS progressive in the truest sense. OK, I see now. :stupid:

Yep, got that. I was stating that when I realized the 240p output is NOT interlaced. :wink-new:
Do you think the 240p will still have serrated vsync pulses though, or is that only required for interlaced too?

I remember how the interlaced timing works, it's actually quite easy to see it on an old 4:3 CRT when in widescreen / anamorphic mode.
You can often see the half-line at the bottom of the image, and if you turn up the flyback voltage you can also see the retrace line going back to the half-line at the top of the image.

I realize that modern TV's don't have scanlines as such, but if they are fed a 240p source directly there's often a bit of scaling going on (ie. mild interpolation).

I think what I'm seeing on the Samsung is some cadence detection on movement (as you say).
ie. when the logo is static the picture is quite stable, but when Mario appears on screen again (and moving), the image "jiggles" up by one line with the same cadence you see from 3:2 pulldown.

Yep, it appears my TV is trying to weave the "frames" together to a large extent (when there is motion).
If I were just outputting 240p with each frame line doubled to each VGA frame (as you said), then I guess it should look even better?

(That will hopefully stop the TV trying to "deinterlace" the 640x480 frames.)

So we have 60Hz 240p framerate and 60Hz VGA refresh, so all I'll need to do is buffer each 240p line then do the doubling to 480p.
I already have some line buffers in place 'cos I'm going to attempt to add some hq2x type filters (often needs access to the pixel data from two or three lines).
I'll try doubling the lines later on, but I also need to add detection for 480i (which will probably involve detecting vsync happening part-way along a line).

I have counters for "n64_line" and "n64_samp" (pixel samples across a line), so it should be straightforward to detect between 240p / 480i / 288p / 576i.
There is also an "n64_total_lines" counter which is normally 525 for NTSC - I know that's correct for the total number of lines in 480i, but would that be the same for 240p too?

(btw, is it correct to say "480i" when referring to a standard interlaced NTSC signal?)

lol, sorry, that was a bit confusing.

What I meant was - in the context of a 60Hz 240p signal where the output frames are taken from a 30fps animation, I was wondering if a better naming convention existed which could help
differentiate it from a 60Hz 240p signal where the output frames come from a 60fps animation? Otherwise, it's fair to say that the former ("240p 60Hz" from 30fps) might suggest 60fps?

I know I'm nitpicking there tbh, but what I'm saying is that there are different methods for producing the output frames (as you also mentioned before)...

15fps animation
1-2-3-4
60Hz 240p output
1-1-1-1-2-2-2-2-3-3-3-3-4-4-4-4

30fps animation
1-2-3-4
60Hz 240p output
1-1-2-2-3-3-4-4

60fps animation
1-2-3-4
60Hz 240p output
1-2-3-4

All I'm saying is that it will be interesting to test which games use which methods of frame output vs their resolution / output mode.

Agreed. I know what you mean now.

OzOnE.

 

Yeah actually it was common practice on Playstation 2 for developers to interlace 240p games never intended to output 480i (disappointing fans who want the experience presented by original hardware). Compare things like Street Fighter Alpha Anthology or Mega Man Anniversary Collection, with PS1 versions of those same games.

 

The video_clock and 4*video_clock are fundamental values in the RCP. I don't see anything that changes those values in the video interface. It would need to be changed at the source of the clock frequencies.

You can set the N64 for 480p with the proper values, but you are limited by that video clock - this means you would need to cut the horizontal lines in half to get twice as many in the same time, so you'd have something like 320x480p instead of 640x480i.

Let's look at a mode to see how things are set:

static const uint32_t ntsc_640[] = {
0x00000000, 0x00000000, 0x00000280, 0x00000200,
0x00000000, 0x03e52239, 0x0000020c, 0x00000c15,
0x0c150c15, 0x006c02ec, 0x002301fd, 0x000e0204,
0x00000400, 0x02000800 };

These values are simply copied into the video interface (VI) registers.

The first value is the control register. The value is ORed with certain values according to the mode you are trying to set. For example, if you are trying to set an interlaced mode, the value is ORed with 0x40... and no, I don't know how the serrate operates. Sorry. The value is also ORed with 2 or 3 for 16 or 32 bit depth respectively. It's also ORed with 0x3000. This register also sets the anti-aliasing mode, with the default of 0 meaning to fetch extra lines for anti-aliasing. Libdragon allows you to pass in different anti-aliasing modes.

The second value is the buffer address. This value should be 0 when setting other registers to avoid flicker or garbage.

The third values is the horizontal width of the frame buffer that will be fetched from. It will be 256, 320, 512, 640, etc. Whatever the buffer you draw into is. In the case of this mode, we are using a 640 pixel wide frame buffer.

The fourth value is the half line on which an interrupt will be generated. It's set larger than the display size since it's not being used by libdragon, but if you needed a mid-screen change, this would be the value to set.

The fifth value is the current line number... you normally read this register to get the current line number. Writing it clears any interrupt pending due to the line number matching the fourth register, so libdragon goes ahead and writes 0 just to make sure the interrupt is cleared.

The sixth value controls some video timing:
b29-20 = 0x3e = offset of burst from hsync in pixels
b19-16 = 0x5 = vertical sync width in lines
b15-8 = 0x22 = burst width in pixels
b7-0 = 0x39 = horizontal sync width in pixels

The seventh value is the number of lines in the frame... and 0x20c is actually a minor bug... it should be 0x20d for NTSC. I should probably point that out to Sean for an update. Anywho, this is 525 (0x20d) for NTSC, and 625 (0x271) for PAL. Note that this should still be 525/625 for non-interlaced modes.

The eighth value controls the total line length and PAL hsync period.
b20-16 = hsync period used by PAL (0 for NTSC or MPAL)
b11-0 = total length of a horizontal line in 4*clock units - 0xc15 = 3093 => 773.25 pixels wide, this controls the horizontal scan rate

The ninth value sets some other line length settings... also in units of 4*clock. For NTSC, it's the same as the line length, but different for PAL or MPAL. Not sure why...

The tenth value sets the start of the visible region of the line, and the end of the visible region. For 640 NTSC, the value 0x006c02ec means we start at pixel 108, and end at pixel 748, giving a visible line region of 640 pixels. This sets where the frame buffer will be displayed. At the start pixel, the frame buffer is fetched and display at the horizontal magnification until the end pixel is reached.

The eleventh value sets the start and end of the active region in lines. The value 0x002301fd means the display starts at line 35 and ends at line 509. This only gives 474 lines instead of 480. This means the last three lines of the frame buffer (which is 640x480) are not displayed. This is well into the vertical overscan on most TVs, so I don't think it really matters. You have to be careful about not going too far - most NTSC CRTs can only take a max of 479 lines.

The twelveth value sets the range for the color burst in lines. Like the previous value, it's the start line and the end line.

The thirteenth value sets the horizontal offset and magnification.
b27-16 = 2.10 fixed point number used to offset the display
b11-0 = 2.10 fixed point number = inverse of the scale used to display the fetch frame buffer data

The fourteenth and last value sets the vertical offset and magnification.
b27-16 = 2.10 fixed point number used to offset the display
b11-0 = 2.10 fixed point number = inverse of the scale used when fetching lines. Note that the inverse scale for interlace is 2.0.

Let's look at 320x240 NTSC:
static const uint32_t ntsc_320[] = {
0x00000000, 0x00000000, 0x00000140, 0x00000200,
0x00000000, 0x03e52239, 0x0000020d, 0x00000c15,
0x0c150c15, 0x006c02ec, 0x002501ff, 0x000e0204,
0x00000200, 0x00000400 };

Note that the frame buffer width is 320, the hsync/burst timing is the same, the line length is the same, the start and end pixels for the line are the same (640 pixels), the active lines are the same height (474) but two lines further down, the inverse horizontal scale is 0.5 instead of 1.0, and the inverse vertical scale is 1.0. The vertical scale is in HALF lines, which is why the 320x240 mode is 1.0 for the vertical, while the 640x480 mode is 0.5.

I think most of the values were found by looking at what games set for different modes. I should check around to see if anyone already has values for VGA modes.

 

All CRT TV's I've used with non-interlaced signals have not had visible scan lines. They appear to make sure that the frames overlap each other, to reduce flicker on interlaced video.

Monitors on the other hand were designed to be much sharper as you'd be using them for displaying text and these do end up with scan lines with non interlaced and more obvious flicker with interlaced.

Officially non interlaced video is out of spec, but it works on all CRT TV's and most modern TV's (but apparently not all which has caused a problem for some retro games on modern consoles).

Some arcade monitors don't actually decode the odd/even frame field or have anything that offsets the beam on the odd frames, so interlaced video has visible scanlines and flickers like crazy.