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
Have started porting new video driver work to MegaYume. Same video-nextgen branch name. HDMI+audio should work, anything else is broken. Also games using H32 or interlace modes are slightly goofed.
H32 mode and various analog outputs should now all work on megayume video-nextgen, with the usual caveat that on DVI/HDMI, H32 is too skinny (256x224 doubles up to 512x448, but there's no obvious means of stretching it to 4:3) Still no interlace.
@Wuerfel_21 said:
H32 is too skinny (256x224 doubles up to 512x448, but there's no obvious means of stretching it to 4:3)
What could pixel tripling and pixel doubling to 768x448 do for you in DVI/HDMI mode? Have you tried playing with a blanking window wrapped around this resolution? I know it's non-standard but DVI monitors would probably still accept it while some HDMI AV gear might be more picky with unknown modes. Is the problem that this could need to change on the fly after the game starts perhaps, or is H32 usage known up front at emulator init time?
If you wanted to keep the total scan line count at 525 (or 625 in case of PAL) maybe something like this could work out:
33.835MHz pixel clock (sysclk/10)
525 total lines
60 Hz refresh
448 active lines (vertically doubled)
1074 total pixel per line
768 active pixels (horizontally tripled)
horizontal syncs distributed accordingly to center active region
Pixels won't be their correct aspect ratio afterwards but stretching is gonna do that regardless.
H32/H40 is just a register setting, can and does switch on the fly (thankfully not per-scanline, I think the resolution switch causes a minor glitch on the real HW, so you'd only do it on a blanked screen). Tripling up the pixels would be too wide, it ought to end up the same size as H40 (320x224).
EDIT: Also, due to lower sysclk and timing differences, MegaYume uses 1026 total pixels per line.
@Wuerfel_21 I found some useful information regarding the syncs for interlaced video like 1024x768i in the link below (finally not including all the usual PAL/NTSC SDTV half line equalization/serration nonsense but for actual hi-resolution VGA style video signals we are interested in). Seems to be just a matter of starting the vsync half way into the scan line every second field in the blanking interval. That's probably all that is needed. I don't expect the half lines need to be masked off at all like they sometimes are for PAL, as the vsync gets fully encapsulated in the vertical blanking period where DE=0 so nothing should be getting displayed then anyway. I recall for PAL you used to sometimes see those little half lines of active pixels at the top/bottom of the TV if it was under-scanned enough. https://electronics.stackexchange.com/questions/598789/how-to-determine-if-a-video-signal-is-interlaced
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
Have started porting new video driver work to MegaYume. Same
video-nextgenbranch name. HDMI+audio should work, anything else is broken. Also games using H32 or interlace modes are slightly goofed.H32 mode and various analog outputs should now all work on megayume video-nextgen, with the usual caveat that on DVI/HDMI, H32 is too skinny (256x224 doubles up to 512x448, but there's no obvious means of stretching it to 4:3) Still no interlace.
What could pixel tripling and pixel doubling to 768x448 do for you in DVI/HDMI mode? Have you tried playing with a blanking window wrapped around this resolution? I know it's non-standard but DVI monitors would probably still accept it while some HDMI AV gear might be more picky with unknown modes. Is the problem that this could need to change on the fly after the game starts perhaps, or is H32 usage known up front at emulator init time?
If you wanted to keep the total scan line count at 525 (or 625 in case of PAL) maybe something like this could work out:
33.835MHz pixel clock (sysclk/10)
525 total lines
60 Hz refresh
448 active lines (vertically doubled)
1074 total pixel per line
768 active pixels (horizontally tripled)
horizontal syncs distributed accordingly to center active region
Pixels won't be their correct aspect ratio afterwards but stretching is gonna do that regardless.
H32/H40 is just a register setting, can and does switch on the fly (thankfully not per-scanline, I think the resolution switch causes a minor glitch on the real HW, so you'd only do it on a blanked screen). Tripling up the pixels would be too wide, it ought to end up the same size as H40 (320x224).
EDIT: Also, due to lower sysclk and timing differences, MegaYume uses 1026 total pixels per line.
@Wuerfel_21 I found some useful information regarding the syncs for interlaced video like 1024x768i in the link below (finally not including all the usual PAL/NTSC SDTV half line equalization/serration nonsense but for actual hi-resolution VGA style video signals we are interested in). Seems to be just a matter of starting the vsync half way into the scan line every second field in the blanking interval. That's probably all that is needed. I don't expect the half lines need to be masked off at all like they sometimes are for PAL, as the vsync gets fully encapsulated in the vertical blanking period where DE=0 so nothing should be getting displayed then anyway. I recall for PAL you used to sometimes see those little half lines of active pixels at the top/bottom of the TV if it was under-scanned enough.
https://electronics.stackexchange.com/questions/598789/how-to-determine-if-a-video-signal-is-interlaced
As requested by @Wuerfel_21
Post split to new thread for HDMI chat here: https://forums.parallax.com/discussion/176008/hdmi-discussion
Console Emulation chat should carry on here!!