Something in the tens up to a hundred ohms might be okay. It's meant to be able to source up 50mA I think, but that's mainly for speciality electronics in cables etc. Going direct would only have to power the EEPROM which won't need much.
Spec says 55mA. There are certainly some "bus-powered" kinda devices (such as those dubious "HDMI to AV" boxes), but they usually have an external input specifically because some sources don't supply enough power.
I've been using 56Ω (green-blue-black-gold), but that's just a random one I found on the (metaphorical) side of the road.
Since the VSYNC version of the regen packet is only needed during, uh, VSYNC, I think I can regenerate it during blanking, so as to not use those 32 extra LUT longs (checksums can be pre-computed, saving some time)
There's one additional case where the 0 sample packet could occur (when the "dejitter" counter rolls over - should also rename that, it's more like "anti-drift"), handle that
Clean up the resampler setup so it automatically bypasses when the input rate is close enough to one of the standard rates (+/- 1 cycle range? Of course using correct N/CTS)
What to do if the input rate is low-ish, like 22.5kHz? (ideally, upsample to 48k, but that might cause severe timing jank?)
Not directly related to the driver: Start audio cog immediately when menu is loading so sink is already synchronized when the startup jingle is playing
Development is now merged back to the video-nextgen branch. Already done: detection of standard sample rates (not tested at all, probably broken), counter roll-over check, early start of audio cog so audio can synchronize during loading, some minor cleanup.
I think the way the jitter reduction check works needs to be changed though, as written currently it would break if the ratio was closer to 2 (i.e. 80 kHz input or so), since in such a case the fractional part overflows almost every sample. Though maybe in that case the problem wouldn't happen to begin with? Maybe I'll just kill that check if the rate fraction has its MSB set (or is zero)
EDIT: Now also working: different resolution submodes for DVI/HDMI. 640x480 is used as default, but you can set 854x480,800x480 or 768x480, perfect if you have a monitor that just loves to stretch the image out to the whole screen. 854x480 is ideal for 16:9, 768x480 is ideal for 16:10. These should hopefully all work the same wrt. to audio.
EDIT: Now also working: different resolution submodes for DVI/HDMI. 640x480 is used as default, but you can set 854x480,800x480 or 768x480, perfect if you have a monitor that just loves to stretch the image out to the whole screen. 854x480 is ideal for 16:9, 768x480 is ideal for 16:10. These should hopefully all work the same wrt. to audio.
Widescreen modes are good. The 800x480 res would be nice for those cheap LCDs. I have also 1024x600 LCDs but that's not gonna work at a 60Hz frame rate unless you used VGA. That particular resolution is not a good match for the NeoYume emulator application in the vertical dimension, but might be okay for other applications. Horizontal could be okay if you pixel tripled NeoYume (320x3) and black pillarbox it slightly, but with vertical you either lose 24 active lines if tripling or about 25% of the screen real estate if doubled which I guess could still be done if you had to use one of these LCD panels - would look a bit stretchy though.
@Wuerfel_21 said:
Such LCDs don't have a controller board with scaling capability? 820 wide should match the aspect ratio.
Yeah an external controller could sort that out, it's only if you went direct to the HDMI input on these cheap LCDs that have one fixed resolution where there would be a issue.
Somewhat OT: I bought one of those "Retroscaler 2x" chinatink devices. It's essentially an NTSC/PAL to HDMI converter without internal buffering (therefore usable with game consoles, unlike most generic ones). Works for P1 NTSC capture alright (PAL is iffy as usual). But knowing what I do now, I wonder how messed up the TMDS signal out of this thing is? It somehow has to keep the output in sync with whatever analog wobbles are coming in. So certainly the scanlines will have at least a +/-1 length difference... (in blanking)
Yeah it would be interesting to capture the output of such a thing to see how it varies.
I wrote some code to use a smartpin to measure the DE/VSYNC/HSYNC widths and pixel rate. You can figure out quite a lot from that too and could probably look for deviations from the average without even decoding any of the TMDS stuff. Assuming you get one of those TFP401 boards at some point.
So I've been doing more work on NeoYume's video-nextgen branch to get it ready to replace the master. Current work is getting all the lowres analog modes in order. Got NTSC/PAL composite and S-Vid working. Haven't tackled the proper short/long serrated sync yet. I want to say that's only needed when doing real interlace, which NeoYume never needs to (but the other emulators do). I'm not sure what interlace sync is supposed to look like on RGBHV.
So instead here's a random framegrab of Sakura from Money Puzzle Exchanger T-posing to assert dominance or something - PAL composite through the RetroScaler box.
@Wuerfel_21 said:
I'm not sure what interlace sync is supposed to look like on RGBHV.
Same here and I never put interlacing into my driver in VGA mode, only TV modes. One day I need to try dig up an old PC and try to run in that weird 43Hz interlaced format for 1024x768 and scope the sync signals to see what it does exactly. http://tinyvga.com/vga-timing/1024x768@43Hz
Comments
I do see power coming from TVs and trying to power up P2 when P2 has no power.
Maybe a resistor is a good idea...
How big can it be?
Something in the tens up to a hundred ohms might be okay. It's meant to be able to source up 50mA I think, but that's mainly for speciality electronics in cables etc. Going direct would only have to power the EEPROM which won't need much.
Spec says 55mA. There are certainly some "bus-powered" kinda devices (such as those dubious "HDMI to AV" boxes), but they usually have an external input specifically because some sources don't supply enough power.
I've been using 56Ω (green-blue-black-gold), but that's just a random one I found on the (metaphorical) side of the road.
So for refactoring all the hacks to be nice..
Development is now merged back to the
video-nextgenbranch. Already done: detection of standard sample rates (not tested at all, probably broken), counter roll-over check, early start of audio cog so audio can synchronize during loading, some minor cleanup.I think the way the jitter reduction check works needs to be changed though, as written currently it would break if the ratio was closer to 2 (i.e. 80 kHz input or so), since in such a case the fractional part overflows almost every sample. Though maybe in that case the problem wouldn't happen to begin with? Maybe I'll just kill that check if the rate fraction has its MSB set (or is zero)
EDIT: Now also working: different resolution submodes for DVI/HDMI. 640x480 is used as default, but you can set 854x480,800x480 or 768x480, perfect if you have a monitor that just loves to stretch the image out to the whole screen. 854x480 is ideal for 16:9, 768x480 is ideal for 16:10. These should hopefully all work the same wrt. to audio.
Widescreen modes are good. The 800x480 res would be nice for those cheap LCDs. I have also 1024x600 LCDs but that's not gonna work at a 60Hz frame rate unless you used VGA. That particular resolution is not a good match for the NeoYume emulator application in the vertical dimension, but might be okay for other applications. Horizontal could be okay if you pixel tripled NeoYume (320x3) and black pillarbox it slightly, but with vertical you either lose 24 active lines if tripling or about 25% of the screen real estate if doubled which I guess could still be done if you had to use one of these LCD panels - would look a bit stretchy though.
Such LCDs don't have a controller board with scaling capability? 820 wide should match the aspect ratio.
Yeah an external controller could sort that out, it's only if you went direct to the HDMI input on these cheap LCDs that have one fixed resolution where there would be a issue.
LCD interfaces are not HDMI. You'd be bypassing HDMI and using the lower level LVDS then.
Somewhat OT: I bought one of those "Retroscaler 2x" chinatink devices. It's essentially an NTSC/PAL to HDMI converter without internal buffering (therefore usable with game consoles, unlike most generic ones). Works for P1 NTSC capture alright (PAL is iffy as usual). But knowing what I do now, I wonder how messed up the TMDS signal out of this thing is? It somehow has to keep the output in sync with whatever analog wobbles are coming in. So certainly the scanlines will have at least a +/-1 length difference... (in blanking)
Yeah it would be interesting to capture the output of such a thing to see how it varies.
I wrote some code to use a smartpin to measure the DE/VSYNC/HSYNC widths and pixel rate. You can figure out quite a lot from that too and could probably look for deviations from the average without even decoding any of the TMDS stuff. Assuming you get one of those TFP401 boards at some point.
So I've been doing more work on NeoYume's
video-nextgenbranch to get it ready to replace the master. Current work is getting all the lowres analog modes in order. Got NTSC/PAL composite and S-Vid working. Haven't tackled the proper short/long serrated sync yet. I want to say that's only needed when doing real interlace, which NeoYume never needs to (but the other emulators do). I'm not sure what interlace sync is supposed to look like on RGBHV.So instead here's a random framegrab of Sakura from Money Puzzle Exchanger T-posing to assert dominance or something - PAL composite through the RetroScaler box.
Same here and I never put interlacing into my driver in VGA mode, only TV modes. One day I need to try dig up an old PC and try to run in that weird 43Hz interlaced format for 1024x768 and scope the sync signals to see what it does exactly.
http://tinyvga.com/vga-timing/1024x768@43Hz