50Hz Smooth Scrolling On Pandora?


thewool

Still Fresh
Joined
Nov 5, 2009
Messages
6
Please move/delete this topic if is has already been discussed... I've searched the forum and can't find an answer.

I was just wondering if the Pandora will be able to achieve a 50hz refresh rate on its LCD, to allow Commodore 64 and Amiga emulators to perform with smooth scrolling?

I'm particulalrly interested in running scene demos on both platforms, they are hindered by judder on 60hz displays.

Cheers.
 
...another question in the same vein:

Will the Pandora be able to output 50hz using the s-video output?

Thanks.
 
Don't take my word as doctrine, but I remember seeing somewhere that the screen's refresh rate is something above 60hz, like 63~69 or so. It was apparently throwing off PSX emulation speeds. :lol:
 
The hardware refresh rate can be adjusted. Whether or not there will be an easy way to do this in software at launch is not something I can tell you, but if it isn't then it's bound to happen sooner or later. I think allowing 60Hz is a priority, but easy access to both is something notaz has been pushing for and since he's one of the two biggest kernel developers on Pandora I think it'll be there.
 
Exophase said:
The hardware refresh rate can be adjusted. Whether or not there will be an easy way to do this in software at launch is not something I can tell you, but if it isn't then it's bound to happen sooner or later. I think allowing 60Hz is a priority, but easy access to both is something notaz has been pushing for and since he's one of the two biggest kernel developers on Pandora I think it'll be there.

it might be possible to sync the LCD to the emulator when running fullscreen rather than the usual emu-vsync-to-LCD.

set the LCD for 30Hz refresh with a long vblank period and restart the LCD controller on screen updates / GL buffer swaps.

if the vblank's scanline comparator can be reset live while running that's another solution.

a countdown/reload type of controller state machine wouldn't be easy to mess with but its still possible: temporarily change the horizontal interval to something very short so the left-over vblank scanlines will pass by very quickly and then restore the horizontal interval just before it starts the next frame.

normally during VBLANK the LCD is just idle so changing the horizontal interval wont bother it as long as its restored before the next frame.

it depend on the LCD control circuit, some can be reprogrammed only when they're taken offline and take a long time to reset or else they go unstable and freeze.
 
Last edited by a moderator:
Stephane Hockenhull said:
Exophase said:
The hardware refresh rate can be adjusted. Whether or not there will be an easy way to do this in software at launch is not something I can tell you, but if it isn't then it's bound to happen sooner or later. I think allowing 60Hz is a priority, but easy access to both is something notaz has been pushing for and since he's one of the two biggest kernel developers on Pandora I think it'll be there.

it might be possible to sync the LCD to the emulator when running fullscreen rather than the usual emu-vsync-to-LCD.

set the LCD for 30Hz refresh with a long vblank period and restart the LCD controller on screen updates / GL buffer swaps.

if the vblank's scanline comparator can be reset live while running that's another solution.

a countdown/reload type of controller state machine wouldn't be easy to mess with but its still possible: temporarily change the horizontal interval to something very short so the left-over vblank scanlines will pass by very quickly and then restore the horizontal interval just before it starts the next frame.

normally during VBLANK the LCD is just idle so changing the horizontal interval wont bother it as long as its restored before the next frame.

it depend on the LCD control circuit, some can be reprogrammed only when they're taken offline and take a long time to reset or else they go unstable and freeze.


This all sounds very interesting. I like it.
I think it's a VERY IMPORTANT feature, making sure we have perfect 2D scrolling. As I mentioned in another thread, my game suffers horribly from screen-tearing thankfully, smooth scrolling isn't essential.

I've noticed nothing but crap scrolling on all emulators and all games (just look at supertux - horrible scrolling, SDL to blame?) on the PC, so if the pandy is basically a PC and I see the same crap scrolling I will be VERY dissapointed. I also think that it would make DS/PSP/etc. owners look at it and poke fun.

I think ensuring we have smooth scrolling is a priority*


* okay, so maybe getting the device functional is more of a priority but you get my drift.
 
Last edited by a moderator:
Cheers for the replies people, especially the techy ones which I'll admit I don't understand a word of - but they are making me feel excited all the same as it sounds like it's definitely achievable.

I totally agree with Miner49er. Everyone is looking for different features in the Pandora to suit their needs, smooth 2d scrolling is a deal-breaker for me. It's still the reason I cart my trusty 64 and disk drive down the stairs every now and then for the authentic experience. Fingers crossed that the emulation on Pandora means this will happen less and less (which will keep the Mrs happy...) :)
 
A little off topic, but people were talking about video out... Is the small faction of a second lag still there? I remember seeing a video, and there was a very tiny, but noticeable, delay from what was displayed on the Pandora and the TV.
 
Stephane Hockenhull said:
it might be possible to sync the LCD to the emulator when running fullscreen rather than the usual emu-vsync-to-LCD.

set the LCD for 30Hz refresh with a long vblank period and restart the LCD controller on screen updates / GL buffer swaps.

if the vblank's scanline comparator can be reset live while running that's another solution.

a countdown/reload type of controller state machine wouldn't be easy to mess with but its still possible: temporarily change the horizontal interval to something very short so the left-over vblank scanlines will pass by very quickly and then restore the horizontal interval just before it starts the next frame.

normally during VBLANK the LCD is just idle so changing the horizontal interval wont bother it as long as its restored before the next frame.

it depend on the LCD control circuit, some can be reprogrammed only when they're taken offline and take a long time to reset or else they go unstable and freeze.

Okay, no offense, but this sounds completely preposterous to me. Why would you want to do that when you could call a set_refresh_rate(50.0) syscall and then wait_for_vsync() each frame? Your solution already assumes you can set the refresh rate so I'm pretty dumbfounded.
 
Last edited by a moderator:
Exophase said:
Stephane Hockenhull said:
it might be possible to sync the LCD to the emulator when running fullscreen rather than the usual emu-vsync-to-LCD.

set the LCD for 30Hz refresh with a long vblank period and restart the LCD controller on screen updates / GL buffer swaps.

if the vblank's scanline comparator can be reset live while running that's another solution.

a countdown/reload type of controller state machine wouldn't be easy to mess with but its still possible: temporarily change the horizontal interval to something very short so the left-over vblank scanlines will pass by very quickly and then restore the horizontal interval just before it starts the next frame.

normally during VBLANK the LCD is just idle so changing the horizontal interval wont bother it as long as its restored before the next frame.

it depend on the LCD control circuit, some can be reprogrammed only when they're taken offline and take a long time to reset or else they go unstable and freeze.

Okay, no offense, but this sounds completely preposterous to me. Why would you want to do that when you could call a set_refresh_rate(50.0) syscall and then wait_for_vsync() each frame? Your solution already assumes you can set the refresh rate so I'm pretty dumbfounded.

the mighty Exophase has spoken!
let the word be known to NVIDIA, Matrox, ATI and the likes that Genlock (wikipedia) is completely useless and so unworthy that no one would need this feature ever.

its so useless that they still sell GenLock devices for Amiga even today:
G-Lock Genlock for Amiga $349.95

preposterous indeed.
 
Last edited by a moderator:
Stephane Hockenhull said:
the mighty Exophase has spoken!
let the word be known to NVIDIA, Matrox, ATI and the likes that Genlock (wikipedia) is completely useless and so unworthy that no one would need this feature ever.

its so useless that they still sell GenLock devices for Amiga even today:
G-Lock Genlock for Amiga $349.95

preposterous indeed.

And of course none of that explains how this is helpful for emulating something at a given refresh rate. Maybe you see something I don't, but please explain why an emulator would want to do more than specify a given refresh rate...

This has nothing to do with synchronizing two different hardware sources...
 
Last edited by a moderator:
Exophase said:
And of course none of that explains how this is helpful for emulating something at a given refresh rate. Maybe you see something I don't, but please explain why an emulator would want to do more than specify a given refresh rate...

This has nothing to do with synchronizing two different hardware sources...

For one thing: It is helpful to make it easier to emulate computers and consoles. Sound output frequencies might not match exactly with refresh rate if both are specified independently. There are lots of old chip music players which rely on there being a correlation between number of cycles on the sound chip and the number of cycles for a screen refresh.

By being able to trigger a screen refresh, the refresh can be synced to the sound output. Thus yielding sound and video in perfect harmony.

Otherwise precious cpu resources needs to be spent to re sample sound to match refresh rate, and quality re sampling of these kinds of almost, but not exactly, matching frequencies are non trivial.
 
Last edited by a moderator:
Tokiopop said:
A little off topic, but people were talking about video out... Is the small faction of a second lag still there? I remember seeing a video, and there was a very tiny, but noticeable, delay from what was displayed on the Pandora and the TV.
The lag was guessed to be due to the TV. Modern HD TVs do some post processing to standard def signals to make it look better on the sharper TV, but have the adverse effect of slowing down a bit. Plugging it into a regular TV, or somehow turning off the post processing on the HDTV should eliminate the lag.
If this is the case (and it most likely is) then it's not a problem with the Pandora, but a problem with the TV and affects all game consoles.

Regarding LCD refresh rates, I wonder how it will handle differences between PAL and NTSC. I know PAL video doesn't always look as... sharp?.. as NTSC on my 60 hz monitor, but that could just be psychological bias.
 
Last edited by a moderator:
macke said:
For one thing: It is helpful to make it easier to emulate computers and consoles. Sound output frequencies might not match exactly with refresh rate if both are specified independently. There are lots of old chip music players which rely on there being a correlation between number of cycles on the sound chip and the number of cycles for a screen refresh.

By being able to trigger a screen refresh, the refresh can be synced to the sound output. Thus yielding sound and video in perfect harmony.

Otherwise precious cpu resources needs to be spent to re sample sound to match refresh rate, and quality re sampling of these kinds of almost, but not exactly, matching frequencies are non trivial.

But you've just drifted the (miniscule) problem from the video to the audio. The audio may not allow as fine tune adjustment, much less would it allow 1MHz+ rates that a lot of consoles output at. So resampling is unavoidable and almost all emulators do it. Now, if you can set the video refresh rate with any precision then you'll come pretty close to a proper ratio and at worst will occasionally have a doubled frame. This is a lot less noticable than the audio falling behind and stuttering.
 
Last edited by a moderator:
PAL is 50hz and not 60hz as NTSC, its also a higher resolution for some reason.

NTSC is capable of either 640x480 or 720x480, i think.
PAL is 768x576.

That could be why PAL looks less sharp for you, just a thought though.
 
Exophase said:
But you've just drifted the (miniscule) problem from the video to the audio. The audio may not allow as fine tune adjustment, much less would it allow 1MHz+ rates that a lot of consoles output at. So resampling is unavoidable and almost all emulators do it. Now, if you can set the video refresh rate with any precision then you'll come pretty close to a proper ratio and at worst will occasionally have a doubled frame. This is a lot less noticable than the audio falling behind and stuttering.

The audio does not need fine tune adjustment, just use audio as main timer. The problem is that there are two timers (audio and video) which may slide out of sync. If video can be set to follow audio timer, then you wouldn't get two out of sync timers, and nothing would need to be adjusted. This way you would get perfect audio without re sampling and perfect video without any dropped/doubled frames. This is would be ideal.

However, it might not be practical considering existing emulator code, and changes needed (I assume) to kernel code.
 
Last edited by a moderator:
macke said:
The audio does not need fine tune adjustment, just use audio as main timer. The problem is that there are two timers (audio and video) which may slide out of sync. If video can be set to follow audio timer, then you wouldn't get two out of sync timers, and nothing would need to be adjusted. This way you would get perfect audio without re sampling and perfect video without any dropped/doubled frames. This is would be ideal.

However, it might not be practical considering existing emulator code, and changes needed (I assume) to kernel code.

Dude, no.

You're assuming that the audio can be clocked close enough to the original, which may not be the case. If your audio can only be output at 48KHz and the emulator calls for 32KHz then I think people are going to notice if you synchronize everything to the audio rate you can set. Your pitch will be way off and your game speed will be way off. Unless you can time the audio to what it's SUPPOSED to be then you're going to have synchronization problems. I used 32KHz since I'm sure it's familiar to you, since no doubt you're citing BSNES here (the only emulator I know of that really tries to synchronize like this, of course not trying any weird scanline tricks), but MOST platforms use not very standard output rates, often well into the hundreds of KHz or MHz.

Having an occasional doubled frame is not actually a big deal to most people who aren't obsessive compulsive. You can avoid dropped frames if you set it so it drifts on the right side. You'll have to sample the audio to whatever target rate anyway in almost all cases, which uses much less CPU than sampling at native rate for these platforms. Anyway, your solution may theoretically allow better audio/video synchronization, but the tradeoff is that you will drift in absolute time. The emulator's sense of time will fall more out of sync with what the real world's is.

Remember, we're talking about applications done in Linux. Do you really want to even try to override the low level video synchronization signals on a per-frame basis? Do you really think you'll have a system that's hard real-time enough in the first place?
 
Last edited by a moderator:
Exophase said:
You're assuming that the audio can be clocked close enough to the original, which may not be the case. If your audio can only be output at 48KHz and the emulator calls for 32KHz then I think people are going to notice if you synchronize everything to the audio rate you can set. Your pitch will be way off and your game speed will be way off. Unless you can time the audio to what it's SUPPOSED to be then you're going to have synchronization problems. I used 32KHz since I'm sure it's familiar to you, since no doubt you're citing BSNES here (the only emulator I know of that really tries to synchronize like this, of course not trying any weird scanline tricks), but MOST platforms use not very standard output rates, often well into the hundreds of KHz or MHz.

I just need set the audio to be close to any convenient multiple for simple re sampling, like x2 or x3/2. I don't know about BSNES, but I'm speaking from my own experience having implemented a proprietary mobile phone emulator. I used audio timer to synchronise with realtime, but there where no way for me to to get any synchronisation for video or even being able to set refresh rate (output to win32 window). I've also written realtime audio filters needing to adjust to two slightly different frequencies (two different soundcards). Getting the re sampling to work did not come easy considering the low latency requirements. I would imagine similar problems while writing en emulator.

Exophase said:
Having an occasional doubled frame is not actually a big deal to most people who aren't obsessive compulsive. You can avoid dropped frames if you set it so it drifts on the right side. You'll have to sample the audio to whatever target rate anyway in almost all cases, which uses much less CPU than sampling at native rate for these platforms. Anyway, your solution may theoretically allow better audio/video synchronization, but the tradeoff is that you will drift in absolute time. The emulator's sense of time will fall more out of sync with what the real world's is.

Well maybe I'm obsessive compulsive ;-). For example: I known I don't like dropped frames while watching video. Normally you get movies encoded in 23hz, while my tv expects 50hz. Direct show normally uses audio timer for synchronising a/v, but I usually install a direct show filter that lets the movie being played in 25hz while re sampling audio to match screen refresh. This means the the audio is slightly out of pitch, but not enough to be noticed. This is how I would prefer emulators to work unless being able to trigger vblank by hand. I appreciate video quality over audio quality.

Exophase said:
Remember, we're talking about applications done in Linux. Do you really want to even try to override the low level video synchronization signals on a per-frame basis? Do you really think you'll have a system that's hard real-time enough in the first place?

Yes. By pulling a number out of my ass, I would guesstimate one would need to trigger the within +-1ms, 50zh being 20ms per frame. Being able to trigger something within a 2ms accuracy does not seem too bad to me, considering one sample of 48khz is just 0.02ms.

But to be honest, I don't rely expect the Pandora linux kernel to be patched for just this. Maybe if there already exist some standard ioctl for doing this. I'm happy just as long we are able to set the refresh rate.
 
Last edited by a moderator:
macke said:
I just need set the audio to be close to any convenient multiple for simple re sampling, like x2 or x3/2. I don't know about BSNES, but I'm speaking from my own experience having implemented a proprietary mobile phone emulator. I used audio timer to synchronise with realtime, but there where no way for me to to get any synchronisation for video or even being able to set refresh rate (output to win32 window). I've also written realtime audio filters needing to adjust to two slightly different frequencies (two different soundcards). Getting the re sampling to work did not come easy considering the low latency requirements. I would imagine similar problems while writing en emulator.

What were you emulating, what was the native output rate? I have always sampled straight to 44KHz with simple filtering and it has always sounded sufficiently good IMO. I actually think it looks pretty decent even w/o video synchronization, if the refresh rate is high enough. But I was able to synchronize against vsync.

macke said:
Well maybe I'm obsessive compulsive ;-). For example: I known I don't like dropped frames while watching video. Normally you get movies encoded in 23hz, while my tv expects 50hz. Direct show normally uses audio timer for synchronising a/v, but I usually install a direct show filter that lets the movie being played in 25hz while re sampling audio to match screen refresh. This means the the audio is slightly out of pitch, but not enough to be noticed. This is how I would prefer emulators to work unless being able to trigger vblank by hand. I appreciate video quality over audio quality.

That's not the same scale. You're talking about four frames per second being doubled, and it's reasonable to not be okay with that. Nonetheless, I don't think I understand how your solution works - if you go to 25Hz without frame doubling then the video will play 8.7% faster. Are you saying that resampling the audio to retain synchronization still sounds okay to you, not to mention the overall difference in speed? I don't think making an emulator that much faster or slower is ever going to be an acceptable solution. People have called clone GBAs unplayable at 5% difference in speed. I certainly don't think 8.7% is too small of a pitch shift to be noticed.

Still, with audio resampling you can synchronize on both audio and video and you will only very occasionally fall so far behind that you have to double a frame. Not four times a second, probably closer to once every few minutes. The frame rate can be set and synchronized against, the audio can be resampled with good quality and very little overhead compared to everything else that needs to be done in an emulator. IF the system wants an audio rate that the machine's sound can give then you can try to that instead of resampling.

I just don't think that trying to manually set vblank per-frame is going to win you anything when you can already program the frame rate. I suppose it would let you get slightly finer control over what the effective rate over time is, by jittering the scanlines where it's triggered, but w/o hard realtime polling (this is a preemptive OS people, stuff can interrupt you and you might get the CPU back several scanlines later..) I don't see it working very well. Hell, even hardware-based delays like TLB and L2 cache misses could possibly cause you to miss an hblank. It just doesn't seem worth it.

macke said:
Yes. By pulling a number out of my ass, I would guesstimate one would need to trigger the within +-1ms, 50zh being 20ms per frame. Being able to trigger something within a 2ms accuracy does not seem too bad to me, considering one sample of 48khz is just 0.02ms.

Oh wow, no, that'd give you much less accuracy than what you can already get by TELLING the screen what refresh rate you want. What kind of hardware do you guys think we're working with, that can have vsync manually triggered but not at a programmable interval? We have a display controller for this purpose...
 
Last edited by a moderator:
Exophase said:
What were you emulating, what was the native output rate? I have always sampled straight to 44KHz with simple filtering and it has always sounded sufficiently good IMO. I actually think it looks pretty decent even w/o video synchronization, if the refresh rate is high enough. But I was able to synchronize against vsync.

I was emulating some inhouse bytecode. Trying to get as close as possible to the byte code interpeters implemented on the phones.

Exophase said:
That's not the same scale. You're talking about four frames per second being doubled, and it's reasonable to not be okay with that. Nonetheless, I don't think I understand how your solution works - if you go to 25Hz without frame doubling then the video will play 8.7% faster. Are you saying that resampling the audio to retain synchronization still sounds okay to you, not to mention the overall difference in speed? I don't think making an emulator that much faster or slower is ever going to be an acceptable solution. People have called clone GBAs unplayable at 5% difference in speed. I certainly don't think 8.7% is too small of a pitch shift to be noticed.

I think it was 23.9hz run at 25hz + frame doubleing. That makes it 4.3% difference. Locking at the filter now it implements timestretching, so that why I couldn't hear any pitch shift. But the 4.3% difference in framerate where not noticeable. So I would say that would work for viewing emulated demos. But if you say that 5% is to much for games, then I must trust you on that one.

Exophase said:
Still, with audio resampling you can synchronize on both audio and video and you will only very occasionally fall so far behind that you have to double a frame. Not four times a second, probably closer to once every few minutes. The frame rate can be set and synchronized against, the audio can be resampled with good quality and very little overhead compared to everything else that needs to be done in an emulator. IF the system wants an audio rate that the machine's sound can give then you can try to that instead of resampling.

High quality resampling is usually hard work, but decent resampling shouldn't be that much of a problem. just use a few taps of a sinc functions with some nice short windowing function. But I still haven't seen any emulator with a good video resampler, only ones resorting to simple double/tripple pixel schemas.

Exophase said:
I just don't think that trying to manually set vblank per-frame is going to win you anything when you can already program the frame rate. I suppose it would let you get slightly finer control over what the effective rate over time is, by jittering the scanlines where it's triggered, but w/o hard realtime polling (this is a preemptive OS people, stuff can interrupt you and you might get the CPU back several scanlines later..) I don't see it working very well. Hell, even hardware-based delays like TLB and L2 cache misses could possibly cause you to miss an hblank. It just doesn't seem worth it.

I'm only talking about vblank here, not hblank. What I was hoping to gain was to remove the dependency of one of two timers (audio and video) which will probably drift when compared to the other. When drifting too much this will need to be adjusted either by skipping/doubling frames or by slightly adjusting resample rate.

It would be possible to achieve the same thing by allowing the frame rate to be adjusted slightly every frame (like between 49 and 51hz). To keep the drift minimal.

But as long as the display is adjustable to 50hz, I would be satisfied. And if writing a crossplatform emulator, these syncronisations/resamplings would be needed for other platforms anyway.
 
Last edited by a moderator:
Back
Top