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
@Rayman Yes, loading is mostly limited by SD speed. There is some bit shuffling going on, too, but it's fairly optimized. Make sure you have this enabled in the config:
' \/ Uncomment for fast ROM loading
#define _SDHC_45MHZ
But 4bit would be even faster. Don't have a board with it yet, but it shouldn't be difficult to wrench in, just replace the mount call.
Though Crossed Swords is a fairly small game, so it shouldn't take that long. Is it just that one taking oddly long? The load times should be roughly correlated with the amount of dots on screen.
@Wuerfel_21 Might have the wrong name... It's the NeoYume one that takes up almost all of 32 MB.
Glad to hear that 4-bit mode will speed it up. I'll try your define too.
Also want to try that one again to see if newest version and/or memory settings can make it work on new board...
I just pushed a new commit wherein I unrolled the slow graphics loading code, so now it should really be limited by what the filesystem can bring on. Which maybe isn't used entirely optimally, it needs to read 16K blocks alternating from two files.
The SD's SPI driver is speed limited by the protection resistor on the boot pins of the Eval/Edge boards, it sits between the SPI Flash EEPROM and the SD slot in case of both attempting to drive at once.
That _SDHC_45MHZ switch raises the attempted SD frequency but at a higher risk of read data errors from that protection resistor.
Delay was 15 and clock and data were true. Does that mean it's faster? That'd be interesting...
Not specifically. None of those are the frequency.
However, through experience, Sync Data Clock is known to have narrower tolerances. Setting that to false gives slightly better margins. I don't have an explanation.
A smaller PSRAM_DELAY will result with the Syncs false. The absolute delay is actually equivalent to 16 if both Syncs were true.
One less delay is technically 1 cycle faster per transfer, for whatever that's worth.
EDIT: That's one (1) P2 cycle, so likely somewhere between 2% and nothing. (NeoYume's sprite graphics transfers are extremely optimized, I want to recall it being 68 cycles per sprite or something (on 16 bit + fast mode). Maybe off, it's been a while. (one sprite sliver is 8 bytes, for reference))
Though really MisoYume is the tough nut to crack. Clock speed is even higher.
Though right now it's been a bit neglected, would need to dig quite a bit to find the latest version. So I'm reposting it here now.
Should really finish up the remaining major problems (DMA block optimization and CPU/audio synchronization) and eventually release it properly. And add the new HDMI audio driver.
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!!
IT IS UPON US
NeoYume V1.4-RC1 - now with HDMI video + audio
V1.3 was actually a long while ago, so a lot of minor changes have accumulated on git under "V1.4-beta", this isn't even all of them
Change to new license: IESL v1
Rewritten video driver!!! The big ticket item!
Get it on GitHub or from the ZIP below. Other emulators will get a new numbered release when they're readyTM
@Wuerfel_21 curious about something… the loading time for crossed swords is a lot. Is that limited by uSD speed?
If so, maybe the new 4 bit sd driver from @evanh would speed loading?
@Rayman Yes, loading is mostly limited by SD speed. There is some bit shuffling going on, too, but it's fairly optimized. Make sure you have this enabled in the config:
But 4bit would be even faster. Don't have a board with it yet, but it shouldn't be difficult to wrench in, just replace the mount call.
Though Crossed Swords is a fairly small game, so it shouldn't take that long. Is it just that one taking oddly long? The load times should be roughly correlated with the amount of dots on screen.
@Wuerfel_21 Might have the wrong name... It's the NeoYume one that takes up almost all of 32 MB.
Glad to hear that 4-bit mode will speed it up. I'll try your define too.
Also want to try that one again to see if newest version and/or memory settings can make it work on new board...
I just pushed a new commit wherein I unrolled the slow graphics loading code, so now it should really be limited by what the filesystem can bring on. Which maybe isn't used entirely optimally, it needs to read 16K blocks alternating from two files.
The SD's SPI driver is speed limited by the protection resistor on the boot pins of the Eval/Edge boards, it sits between the SPI Flash EEPROM and the SD slot in case of both attempting to drive at once.
That _SDHC_45MHZ switch raises the attempted SD frequency but at a higher risk of read data errors from that protection resistor.
That's why it's a config setting
(only brought out for NeoYume because the other emulators just don't need so much speed)
"Last Blade" (this is the big one) works on new board with these settings:
Delay was 15 and clock and data were true. Does that mean it's faster? That'd be interesting...
The 45MHz thing was already defined
Seeing "Last Blade" work is really good news... Means memory is OK.
My opponent was fighting in pink bathrobe and wood shoes... Interesting...
Not specifically. None of those are the frequency.
However, through experience, Sync Data Clock is known to have narrower tolerances. Setting that to false gives slightly better margins. I don't have an explanation.
A smaller PSRAM_DELAY will result with the Syncs false. The absolute delay is actually equivalent to 16 if both Syncs were true.
EDIT: Correction to Sync Clock.
EDIT2: Evidence - https://forums.parallax.com/discussion/comment/1561510/#Comment_1561510
One less delay is technically 1 cycle faster per transfer, for whatever that's worth.
EDIT: That's one (1) P2 cycle, so likely somewhere between 2% and nothing. (NeoYume's sprite graphics transfers are extremely optimized, I want to recall it being 68 cycles per sprite or something (on 16 bit + fast mode). Maybe off, it's been a while. (one sprite sliver is 8 bytes, for reference))
Though really MisoYume is the tough nut to crack. Clock speed is even higher.
Though right now it's been a bit neglected, would need to dig quite a bit to find the latest version. So I'm reposting it here now.
Should really finish up the remaining major problems (DMA block optimization and CPU/audio synchronization) and eventually release it properly. And add the new HDMI audio driver.