Well, YPbPr component video support added to NeoYume and MegaYume.
For some reason it breaks USB in NeoYume. It didn't when I first added it (and then I went to adapt it for MegaVGA), but now it does. I don't think I changed anything inbetween. How odd.
EDIT: Am idiot, managed to accidentally remove important part of code.
Looks reasonable to me, are you happy with that quality? Seems to soften it nicely. What type of display, is it a plasma?
I'll have to try it on mine when I get a chance. It's a 1366 x 768 panel but has a reasonably decent scaler for VGA IIRC. Maybe some line tripling would be nicer, though the video timing would likely be upset.
@rogloh said:
Looks reasonable to me, are you happy with that quality? Seems to soften it nicely. What type of display, is it a plasma?
Just the ususal large Philips CRT (by way of wakabavideo YPbPr to RGB converter box)
I'll have to try it on mine when I get a chance. It's a 1366 x 768 panel but has a reasonably decent scaler for VGA IIRC. Maybe some line tripling would be nicer, though the video timing would likely be upset.
VGA3X mode works out nicely with my 1024x768 VGA LCD. It does detect it as 1024x768 (as opposed to 960x720, which would make more sense), which means the pixels map 1:1 vertically, but there's a bit more border visible than on VGA2X. Aspect ratio is therefore also a bit wide, but for NeoGeo that's actually correct (don't remember correct PAR for megadrive right now)
Also just made MegaYume recognize the NeoGeo USB controller, too. Notable caveat: there's no way as of yet for the USB driver to signal to the emu core that the connected device doesn't support 6 button mode (or the presence of a device in general). So games with 6 button support will enable it and may be uncontrollable.
Also added DIRECT_BOOT config support, because why not.
Tried the new MegaYume from Github with HyperRam module and it's working nicely.
The menu system is good.
But, I seem to almost always need to remove and re-insert the uSD card to get it to work.
Rayman,
Try adding this one line to the file <include/filesys/fatfs/sdmm.cc>, in function disk_initialize()
... about line 575, just below if (send_cmd(CMD0, 0) == 1) { /* Enter Idle state */
add this: dly_us(100); // some SD cards need time to exit from data-transfer mode
Can't find no other reference to it, at least on the forums. Did you know anything about it?
Henrique
I'd used this on a FPGA project I did to help learn about HDMI, it was a useful starting point and helped me get video output into the right format. Audio was still a bit messed up though when I tried to get 48kHz, 44.1kHz working. This project used 32kHz, and I think my HDTV didn't like that IIRC, or I missed something else. Probably needs to be 100% bit perfect to be output correctly by my TV.
@rogloh said:
I'd used this on a FPGA project I did to help learn about HDMI, it was a useful starting point and helped me get video output into the right format. Audio was still a bit messed up though when I tried to get 48kHz, 44.1kHz working. This project used 32kHz, and I think my HDTV didn't like that IIRC, or I missed something else. Probably needs to be 100% bit perfect to be output correctly by my TV.
Audio overHDMI is/was ever a burden. One has to simultaneously deal with two standards (the aforementioned, and also CES/CTA-861-F), just to start figuring it all. In order to visually correlate all the info calls for a very large monitor, or two of reasonable size (none of them here).
I might not got the exact point of it all since I need to read and understand a lot more about it, but, IIRC, charcole's work seems to resort to a periodicall stretching of the audio sampling clock by one UI (in that case, UI = raw pixel clock), whenever the accumulation overflows, to keep it ~within the originally targeted value.
Remember here that the FM synth internally runs at some oddball ~55kHz, so converting to a standard rate without artifacts would require some sort of resampling filter.
@Wuerfel_21 said:
Remember here that the FM synth internally runs at some oddball ~55kHz, so converting to a standard rate without artifacts would require some sort of resampling filter.
Yeah I expect it's very unlikely that regular TVs would accept 55kHz as they can be fussy/restrictive, although monitors might. @Tubular found a cheap brand monitor that did output sound in one of my HDMI tests...
Comments
Not directly. Good for storage though ig.
Looks like it could do 104 MB/s, if I could figure out how to put it into DDR mode. Would that be fast enough?
No. (issue is latency much more than raw bandwidth)
[Moved me comment, better in relevant topic - https://forums.parallax.com/discussion/comment/1539904/#Comment_1539904 ]
Well, YPbPr component video support added to NeoYume and MegaYume.
For some reason it breaks USB in NeoYume. It didn't when I first added it (and then I went to adapt it for MegaVGA), but now it does. I don't think I changed anything inbetween. How odd.
EDIT: Am idiot, managed to accidentally remove important part of code.
Looks reasonable to me, are you happy with that quality? Seems to soften it nicely. What type of display, is it a plasma?
I'll have to try it on mine when I get a chance. It's a 1366 x 768 panel but has a reasonably decent scaler for VGA IIRC. Maybe some line tripling would be nicer, though the video timing would likely be upset.
Just the ususal large Philips CRT (by way of wakabavideo YPbPr to RGB converter box)
VGA3X mode works out nicely with my 1024x768 VGA LCD. It does detect it as 1024x768 (as opposed to 960x720, which would make more sense), which means the pixels map 1:1 vertically, but there's a bit more border visible than on VGA2X. Aspect ratio is therefore also a bit wide, but for NeoGeo that's actually correct (don't remember correct PAR for megadrive right now)
Ok, yeah the plasma does take in 1024x768 I think so that should work out okay over the analog VGA connector. Probably no need for component.
Also just made MegaYume recognize the NeoGeo USB controller, too. Notable caveat: there's no way as of yet for the USB driver to signal to the emu core that the connected device doesn't support 6 button mode (or the presence of a device in general). So games with 6 button support will enable it and may be uncontrollable.
Also added DIRECT_BOOT config support, because why not.
Tried the new MegaYume from Github with HyperRam module and it's working nicely.
The menu system is good.
But, I seem to almost always need to remove and re-insert the uSD card to get it to work.
Anybody else seeing this too?
When do you need to remove the card? Always on boot?
What does it do if you don't?
What brand of card do you use?
It's almost always giving me "Directory error!!!" screen unless I unplug and replug uSD...
I think it is just on boot.
Well idk, the SD code is just flexspin's VFS driver. Try different card ig. sandisk ultra is ultra good (and ultra noisy).
Rayman,
Try adding this one line to the file <include/filesys/fatfs/sdmm.cc>, in function
disk_initialize()... about line 575, just below
if (send_cmd(CMD0, 0) == 1) { /* Enter Idle state */add this:
dly_us(100); // some SD cards need time to exit from data-transfer modeHi Ada
While looking for a totally unrelated thing, I'd stepped on this:
https://github.com/charcole
and, consequently, on this:
https://github.com/charcole/NeoGeoHDMI
Can't find no other reference to it, at least on the forums. Did you know anything about it?
Henrique
I'd used this on a FPGA project I did to help learn about HDMI, it was a useful starting point and helped me get video output into the right format. Audio was still a bit messed up though when I tried to get 48kHz, 44.1kHz working. This project used 32kHz, and I think my HDTV didn't like that IIRC, or I missed something else. Probably needs to be 100% bit perfect to be output correctly by my TV.
Audio overHDMI is/was ever a burden. One has to simultaneously deal with two standards (the aforementioned, and also CES/CTA-861-F), just to start figuring it all. In order to visually correlate all the info calls for a very large monitor, or two of reasonable size (none of them here).
I might not got the exact point of it all since I need to read and understand a lot more about it, but, IIRC, charcole's work seems to resort to a periodicall stretching of the audio sampling clock by one UI (in that case, UI = raw pixel clock), whenever the accumulation overflows, to keep it ~within the originally targeted value.
Remember here that the FM synth internally runs at some oddball ~55kHz, so converting to a standard rate without artifacts would require some sort of resampling filter.
Yeah I expect it's very unlikely that regular TVs would accept 55kHz as they can be fussy/restrictive, although monitors might. @Tubular found a cheap brand monitor that did output sound in one of my HDMI tests...
I just use a VGA to HDMI adapter cable with audio input. Seems to be the best way. Things only cost ~$10...
My cheap TV has has no issue with 55 kHz hsync over HDMI. Its HDMI refresh limits are 24..75 Hz but I've not hit a line frequency limit.
Is there a way to have uSD on different pins?
I tried this:
#define uSD_MISO 44 #define uSD_MOSI 46 #define uSD_SS 47 #define uSD_CLK 45 _mount("/sd", c._vfs_open_sdcardx(uSD_CLK, uSD_SS, uSD_MOSI, uSD_MISO))But, the display says "Function not implemented"
That should work. IDK where it'd get that error from?
It's
mount(). Ditch the underscore.No, it is _mount with underscore. But you need to use
@"/sd"That gives "error: unknown identifier mount used in function call" when building...
Smile! I see, it's Spin code.
I see "function not implemented" is also what you get if you comment out the "mount" line...
I see the problem now... Left off an "@". Works now.
_mount(@"/sd", c._vfs_open_sdcardx(uSD_CLK, uSD_SS, uSD_MOSI, uSD_MISO))