Neat to be able to run more with PSRAM4. On one of my old projects in this thread here I have a 4 bit PSRAM (and parallel LCD or VGA) plus USB so it might be a candidate for some retro gaming one day too. The LCD is 800x480 however so is probably not that nice a resolution to target. https://forums.parallax.com/discussion/169431/p2-voyager-project-was-new-toy/p3
@rogloh said:
Neat to be able to run more with PSRAM4.
It's not a PSRAM4-exclusive fix, that one's just the absolute worst for ROM->VRAM DMA. Wolf3D does tons of WRAM->VRAM, that one was busted regardless of RAM speed. The new DMA code properly grabs the ROM data for the upcoming transfer block in one go, so a lot less overhead on that.
On one of my old projects in this thread here I have a 4 bit PSRAM (and parallel LCD or VGA) plus USB so it might be a candidate for some retro gaming one day too. The LCD is 800x480 however so is probably not that nice a resolution to target. https://forums.parallax.com/discussion/169431/p2-voyager-project-was-new-toy/p3
800x480 should be fine, I can do that on HDMI, so parallel LCD shouldn't be a problem on that front. You just get big bars on the games.
Hmm, so I can find 2 games that definitely don't work anymore with the new DMA code: Donkey Kong Country and Jurassic Park. Former is a big pain, I just fixed that one in beta07!
Also, there's timing problems in Demon's Crest that are still not fixed with this. Though I'd assume that's regular "where does the IRQ go" type problems.
EDIT: Fixed it, just went into an infinite loop based on difference of opinion on when exactly events should happen between DMA setup and everything else.
Appears that actual 480p resolution games can gain a lot. Not clear about these games that are more like QVGA though.
Does mention sega genesis though, so maybe...
Nothing worthwhile. The HDMI output from the P2 is already as good as it gets.
These kinds of things tend to just attempt to apply an FXAA-type algorithm to smooth edges.
As previously mentioned, this release is an optimizations-only one, This means games that previously had graphical glitches due to the CPU cog falling behind (especially on slow 4-bit PSRAM boards) are now FIXED.
This notably includes:
The Legend of Zelda: A Link to the Past
Super Metroid
Super Mario All-Stars
Wolfenstein 3D
I did not find any regressions, though there's potential for those, as the entire DMA code got re-written and certain A-Bus areas can no longer be DMA source/destination (notably, DMA from/to cartridge RAM is currently not implemented due to lack of test cases).
I also added some extra info to the file browser.
@Rayman said:
Those sound like good titles to have working. Thanks!
Technically they were already working, just with some amount of flickering.
Reminds me that still want to make full sized console for TV…
Could really just drop a P2Platform into a nice box for that one. It's got the goods.
The P2 game box thing from @MXX is basically like that, though it has 96MB PSRAM and a built-in USB hub. (I actually have his schematics for that, but don't know if it's ok to share them)
(added on afterwards)
The next big thing missing from MisoYume is CPU/SPC synchronization. This is the leading cause of broken games. Basically, most games use explicit handshakes when communicating with the sound board. Those work. But some games rely on implicit timing to reduce overhead (or just because they're busted) and that doesn't work. Basically the CPU emulation works on ~64µs time slices (one video scanline) and the SPC emulation works on ~31µs slices (one audio sample). Within each slice the actual work is done at the beginning and the rest is spent waiting.
So the difficulty now is to figure out a scheme that allows synchronizing the mailbox accesses to simulate the processors running in tight lock-step (tigh-ish anyways - the real SNES sound board is clocked by it's own ceramic resonator circuit, so it's not in a very stable relationship with the main clock)
The DMA optimization was a blocker for this, because having the CPU be 100s of µs late to its own time is not conducive to that sort of time-sync effort.
@Wuerfel_21 said:
Could really just drop a P2Platform into a nice box for that one. It's got the goods.
@Wuerfel_21 That is exactly the plan. But, need to make some more of these breakouts with HDMI and USB. Had a few, but lost them somewhere...
Have some with VGA+Audio+USB, but thinking HDMI is better, now that you have sound for everything over HDMI.
Also debating whether to include a 4-port USB hub in the box, or just let it be external, if needed...
@Rayman said:
That is exactly the plan. But, need to make some more of these breakouts with HDMI and USB. Had a few, but lost them somewhere...
Have some with VGA+Audio+USB, but thinking HDMI is better, now that you have sound for everything over HDMI.
Remember that the HDMI audio currently relies on having analog outputs somewhere to provide the timing reference. If you don't have 2 unused pins to send DAC output to, I'd need to engage in major refactoring.
Also not everything, Spin Hexagon still doesn't have it.
Also debating whether to include a 4-port USB hub in the box, or just let it be external, if needed...
PC-Engine type situation where the "multitap" is required for more than 1 player
Unrelatedly, I would consider putting the Rayslogic StoreTM link more prominently somewhere, I think people don't know it exists. Need to seed more 96MB PSRAM and P2Plat among the populace for our nefarious schemes. Maybe more aggressive forum signature ad like "Rayslogic Store: [link] - P2 SwAP, P2 Platform, PSRAM expanders and more" added as a 2nd line.
(Also, is a 640x480 RGB816 LCD board still happening?)
Yet unrelatedly to any of those things, but to pad out this post with some non-nonsense of general interest, a "sneak preview" of that alleged WIP software I'd mentioned elsewhere :
(I actually had this on discord days ago, I guess it's go there to get the real (low-effort) scoops?)
(You can tell it's old because for P1CC it doesn't build @zx81vga games yet, which were finished last)
The idea is that you just have to write 1 config and then run this script on it and it will grab all the softwares from their git remotes, configure them, build them (including any tools required) and stuff them into a ready-made directory structure (assuming we had a working SD IPL... of course one can also just load the BIX files from there manually).
Grabbing, configuring and building are mostly working, but I need to find a good way to ingest a machine configuration in a hassle-free manner (i.e. where you can say "A/V accessory on basepin 8" and it automatically figures out the analog audio and video pins) and convert that into project-specific config values. Also PSRAM latency settings are ??? (will definitely need a way both to guess the correct setting and to override that when it goes badly). Also need a way to reject building stuff that can't possibly be configured (e.g. can't configure NeoYume on a PSRAM-less machine no matter how hard you try).
Also need to figure out how to best get the prerequisites and turn that into a guide for Linux/Win/Mac/etc (currently: ruby, git, bison and gcc/build-essentials).
@Wuerfel_21 said:
(Also, is a 640x480 RGB816 LCD board still happening?)
Hmm. Seems dropped the ball on that one. Found some 24-bit ones that were made, but seems we decided at some point that 16-bit would be better.
Also, had to redo connection for pin-35 as that was actually a demo mode switch. Also, wanted to redo header so could work with edge...
Found a new layout, but have to see if it was ever made...
Guess sort of lost interest when found hdmi based lcd modules for decent price...
Why would one want this that uses 16 pins when could just use HDMI with just 8 pins and use a standard cable?
@Wuerfel_21 said:
Unrelatedly, I would consider putting the Rayslogic StoreTM
But one can't have their inventory and sell it too
Sure, but I just feel the sales are entirely synchronized with me making mention of it. (I think another one just went?)
@Rayman said:
Guess sort of lost interest when found hdmi based lcd modules for decent price...
Why would one want this that uses 16 pins when could just use HDMI with just 8 pins and use a standard cable?
Fair, but they don't offer these with pin header connections, just bothersome HDMI connectors.
@Rayman said:
Not really sure what is going on there, but guess this is wireless I2C?
No, the controller just sends out whatever signals it does, likely one-way, then the receivers put up a USB HID / I2C front end (respectively) for the system to poll. I wouldn't be surprised if both types of receiver would happen to work simultaneously from the same pad.
You can get one that does the same trick with a variety of Bluetooth controllers: https://www.8bitdo.com/retro-receiver-snes-sfc-classic/ (or the plain old SNES version of this that simulates a shift register... I have that one).
Though wired is always better to me. Less hassle, less latency.
(EDIT) Currently I'd be in a bit of a pickle recommending one, as both of my favorite retro-ish USB controllers have died on me. Those would've been the "Retro-Bit SEGA 8-Button Arcade Pad with USB" (cable went bad) and the "8bitdo SN30 Pro USB" (firmware bricked itself under mysterious circumstances - while connected to my PC, no experimental HW/SW involved). The newer "8bitdo Ultimate 2C Wired" has been good to me so far, but it's a more modern-style layout (and also has trouble with usbnew on P2 sometimes).
So, I went to stay at someone else's place last week. I decided to bring the @MXX Thing with me for entertainment, allocating valueable backpack space to it. I built all the emulators with HDMI support and then flashed them to the board.
When I arrived I found that neither of 2 TVs available would accept the signal. One was some crappy new-age thing where everything was really slow, the other was a Samsung very similar to the one I have here at home. (same remote and OS / menu structure)
After some mucking about I found out the following:
Roger's text driver works. (at least with the settings I have in the usbnew samples)
My VNG driver (NeoVGA etc) works in DVI mode, but NOT in HDMI mode. The TV totally rejects the signal, no "invalid mode" or video-but-no-audio stuff.
My HDMI scan2x proof-of-concept driver (that plays OPN2Cog audio + static picture) also works (incl. audio).
Trying different cables or pin drive modes made no particular difference
Considering two TVs failed, one apparently being extremely similar to the one I have at home, I mentally filed this as a code regression introduced because I only ever test with the ASUS monitor and the VisionRGB card, which both take aaaanything you throw at them. I had Better ThingsTM to do than to thoroughly live-debug this stuff on the scene with my thinkpad and thought I'd be just able to reproduce this at home.
Turns, out, no. It just works on the Samsung TV I have here. So I'm at a loss now as to what would cause this and unable to repro it without spending a day riding stinky trains up north (and bothering my poor hosts by futzing around with their TV).
Possible ideas in order of decreasing likelihood:
Something wrong with the preamble or guard band signalling that these newer(?) TVs don't like
Something wrong with the AVI InfoFrame and these TVs are more picky
Something wrong with the audio packets (unlikely, that usually just kills the audio and leaves the video alone)
Divine intervention, higher forces really wanted us to watch TV shows instead (honestly can't rule it out at this point)
So the best thing I can do now is ask if any of y'all on here can test NeoYume on a bunch of different TVs and similar devices. I know I went on a whole bit with @rogloh on debugging it previously on his Pioneer Plasma (can you re-check that still works? I'm going mad out here and need some assurance), so I think I can remote debug these things. Just need someone with a similar repro case (MODE_DVI works but MODE_HDMI does not). (also try the usbnew sample programs with roger's driver, they're less of a hassle to set up)
@evanh said:
I found that blanking can easily become too small for some displays. Minimum Hblank of 80 and minimum Vblank of 20 did well on many DVI and HDMI.
EDIT: I guess that's always DVI mode. What is HDMI mode? I didn't know there was a difference.
HDMI mode is HDMI signalling. This allows "data islands" to be sent during blanking (audio packets live here! and that's the main reason to use it over DVI) but the video signalling also changes slightly (presumably to help the sink lock on easier?)
HBlank is plenty large because it needs to fit that whole [data preamble -> data guard -> 2x data packet (audio data + audio clock) -> data guard -> video preamble -> video guard] sequence. I was also using the 640x480 mode, which has really wide blanking to accomodate the high clock speed. Maybe I should re-check this, but all the preambles ought to be sufficiently long (as per HDMI spec). VBlank is NTSC quasi-standard stuff (so plently lines).
EDIT: oh yeah btw HDMI and DVI modes are almost the same in my code, the only thing that really changes is the function pointers that handle sync and blank lines. So the timing should be the same between them. HDMI also enables the audio processing overlay to run during active video, but I don't think it's that, it wouldn't work anywhere at all or introduce visible glitches if that was causing e.g. timing issues.
@Rayman said:
Maybe needs the 5v ?
Guess would be weird if needed for hdmi but not dvi
No, it's not that thing. It's all properly wired on the MXX thing. But good to note about that for other people trying to test it.
If nothing works at all and you're using the Parallax Digital Video Accessory, try connecting ACC 5V to the 5V out pin next to it (ideally with a resistor, but for testing you can just jam a dupont wire in there). Some TVs need this to even let you switch to the input at all (is greyed out otherwise)
@Rayman said:
I’ve tried the emulators with several tvs and it always worked.
With the recent-ish digital audio feature? Well, at this point it's not so recent anymore (V1.4 was released many months ago), but point is that that was a full rewrite of the video code to add that. Maybe time to retry.
Seem to recall that @rogloh also had a very picky TV
Yeah we figured that one out, but IIRC the problem always was with the audio not coming through, the video was fine. We fixed the audio by setting word length in channel status appropriately and reducing sample transmit timing jitter. Both very "soft" issues.
HDMI is definitely worth it over VGA. No phase/alignment issues, no signal distortion, just bit-exactly the pixels you put in. Audio, despite needing resampling in some cases, is also much cleaner than analog.
It's definitely a hill to climb to implement it and there's a lot of these nasty edge-cases (though they mostly apply to the HDMI/audio part, DVI is pretty simple, just needs the 8/10 modulation encoder that Chip wisely added in Rev. B )
@Wuerfel_21 Once I get a chance this weekend I'll try it out again on the Pioneer plasma to see if you have a regression. My problem was a combination of multiple effects that also included lack of 5V presence when tested with audio output - all had to work to have audio work.
I wonder if these TVs were somehow being far pickier in their supported resolutions? Did you try out anything really generic like true VGA over HDMI at 25.175 MHz with 800 total pixels / line or 576p/480p etc using standard N/CTS values and without any custom/non-standard timings using shorter blanking intervals etc? i.e Modes associated with VIC values in the various CEA-861 docs.
I also wonder if it could be somehow confused with the Infoframes being sent or their frequency? I vaguely recall there were some minimum settings there - but hopefully your code is already following that.
@rogloh said:
@Wuerfel_21 Once I get a chance this weekend I'll try it out again on the Pioneer plasma to see if you have a regression. My problem was a combination of multiple effects that also included lack of 5V presence when tested with audio output - all had to work to have audio work.
I wonder if these TVs were somehow being far pickier in their supported resolutions? Did you try out anything really generic like true VGA over HDMI at 25.175 MHz with 800 total pixels / line or 576p/480p etc using standard N/CTS values and without any custom/non-standard timings using shorter blanking intervals etc? i.e Modes associated with VIC values in the various CEA-861 docs.
The DVI versions of the same timings worked, so I'd hope that's not the problem. The PoC driver also worked (incl. audio).
IIRC the main differences between the PoC driver and the final VNG driver used in NeoYume etc (from memory, already went to sleep):
PoC runs at standard 252 MHz, VNG runs at big much 300+MHz with appropriately elongated blanks
I don't remember what the N/CTS value for the PoC driver was, but that one fully worked, so ???
PoC treats preamble as own sync command, VNG just extends it backwards (i.e. entire front porch is video preamble)
All the parts that aren't the audio processing aren't the same code, so bugs might have snuck in
I think there may be cases where the sync bits (especially during data period) go bad? Need to double-check this
minor edit: note that the PoC driver never got the pioneer fixes, VNG started development before we did that.
I also wonder if it could be somehow confused with the Infoframes being sent or their frequency? I vaguely recall there were some minimum settings there - but hopefully your code is already following that.
Once per frame - that should be fine.
The big thing I need is someone who can repro this bug.
So the best thing I can do now is ask if any of y'all on here can test NeoYume on a bunch of different TVs and similar devices. I know I went on a whole bit with @rogloh on debugging it previously on his Pioneer Plasma (can you re-check that still works? I'm going mad out here and need some assurance), so I think I can remote debug these things. Just need someone with a similar repro case (MODE_DVI works but MODE_HDMI does not). (also try the usbnew sample programs with roger's driver, they're less of a hassle to set up)
I tried NeoYume MODE_HDMI on two different monitors.
One worked (video+audio) while the other is not working (no signal message).
As expected, using MODE_DVI, works on both monitors.
Nice to see that HDMI works together with VGA using MODE_HDMI_VGA. On VGA the image is a little stretched.
.
.
.
(MODE_DVI_VGA: same monitor DVI on the left, VGA on the right. MODE_DVI also working)
.
.
.
(MODE_HDMI_VGA: same monitor HDMI on the left, VGA on the right. MODE_HDMI also not working)
.
.
.
(MODE_HDMI: on a brand new, huge, ultrawide philips monitor. It works with audio. The image is doubled by a "special" mode of the monitor itself, but it's the same hdmi signal on both sides. Also MODE_HDMI_VGA is ok)
Do these monitors that don't work have speakers in the first place? (They in theory should still accept the HDMI-encoded signal, anyways, all the ones I've seen do, but there's a valid chance of being plain DVI devices that just don't like the extended signalling, full-stop)
Also, here is the aforementioned PoC driver (compile opn2test_top.spin2, should already have the right pins) to try out. This one didn't have the no signal issue for me, but beware that the audio handling on this is missing some bugfixes the VNG driver did get (as discussed above) so it's ok if it's just picture and no sound.
BTW: The simultaneous VGA output being stretched is just how it has to be. If you try a game from P1 Classics Collection, you'll notice that those all have a non-stretched VGA output because they use a more relaxed timing. (Note: I didn't have any of these flashed last week and didn't bother testing it, woe is me)
Comments
Neat to be able to run more with PSRAM4. On one of my old projects in this thread here I have a 4 bit PSRAM (and parallel LCD or VGA) plus USB so it might be a candidate for some retro gaming one day too. The LCD is 800x480 however so is probably not that nice a resolution to target.
https://forums.parallax.com/discussion/169431/p2-voyager-project-was-new-toy/p3
It's not a PSRAM4-exclusive fix, that one's just the absolute worst for ROM->VRAM DMA. Wolf3D does tons of WRAM->VRAM, that one was busted regardless of RAM speed. The new DMA code properly grabs the ROM data for the upcoming transfer block in one go, so a lot less overhead on that.
800x480 should be fine, I can do that on HDMI, so parallel LCD shouldn't be a problem on that front. You just get big bars on the games.
Hmm, so I can find 2 games that definitely don't work anymore with the new DMA code: Donkey Kong Country and Jurassic Park. Former is a big pain, I just fixed that one in beta07!
Also, there's timing problems in Demon's Crest that are still not fixed with this. Though I'd assume that's regular "where does the IRQ go" type problems.
EDIT: Fixed it, just went into an infinite loop based on difference of opinion on when exactly events should happen between DMA setup and everything else.
Curious about what this gizmo would do for Sega Genesis emulator:
https://marseilleinc.com/products/buy-mclassic
Appears that actual 480p resolution games can gain a lot. Not clear about these games that are more like QVGA though.
Does mention sega genesis though, so maybe...
Nothing worthwhile. The HDMI output from the P2 is already as good as it gets.
These kinds of things tend to just attempt to apply an FXAA-type algorithm to smooth edges.
Yeah, think my monitors and tv already do up scaling. Works well on actual 480p or better input. But this is just too blocky to work…
Do wonder though if output were to just one corner of screen, maybe upscaler would work and then maybe could zoom into that area on screen…
You can not squeeze blood from a stone
With no further ado,
MisoYume beta11
As previously mentioned, this release is an optimizations-only one, This means games that previously had graphical glitches due to the CPU cog falling behind (especially on slow 4-bit PSRAM boards) are now FIXED.
This notably includes:
I did not find any regressions, though there's potential for those, as the entire DMA code got re-written and certain A-Bus areas can no longer be DMA source/destination (notably, DMA from/to cartridge RAM is currently not implemented due to lack of test cases).
I also added some extra info to the file browser.
Get it at SourceHut, GitHub or grab the attached ZIP file!
Those sound like good titles to have working. Thanks!
Reminds me that still want to make full sized console for TV…
Technically they were already working, just with some amount of flickering.
Could really just drop a P2Platform into a nice box for that one. It's got the goods.
The P2 game box thing from @MXX is basically like that, though it has 96MB PSRAM and a built-in USB hub. (I actually have his schematics for that, but don't know if it's ok to share them)
(added on afterwards)
The next big thing missing from MisoYume is CPU/SPC synchronization. This is the leading cause of broken games. Basically, most games use explicit handshakes when communicating with the sound board. Those work. But some games rely on implicit timing to reduce overhead (or just because they're busted) and that doesn't work. Basically the CPU emulation works on ~64µs time slices (one video scanline) and the SPC emulation works on ~31µs slices (one audio sample). Within each slice the actual work is done at the beginning and the rest is spent waiting.
So the difficulty now is to figure out a scheme that allows synchronizing the mailbox accesses to simulate the processors running in tight lock-step (tigh-ish anyways - the real SNES sound board is clocked by it's own ceramic resonator circuit, so it's not in a very stable relationship with the main clock)
The DMA optimization was a blocker for this, because having the CPU be 100s of µs late to its own time is not conducive to that sort of time-sync effort.
@Wuerfel_21 That is exactly the plan. But, need to make some more of these breakouts with HDMI and USB. Had a few, but lost them somewhere...
Have some with VGA+Audio+USB, but thinking HDMI is better, now that you have sound for everything over HDMI.
Also debating whether to include a 4-port USB hub in the box, or just let it be external, if needed...
Remember that the HDMI audio currently relies on having analog outputs somewhere to provide the timing reference. If you don't have 2 unused pins to send DAC output to, I'd need to engage in major refactoring.
Also not everything, Spin Hexagon still doesn't have it.
PC-Engine type situation where the "multitap" is required for more than 1 player
Unrelatedly, I would consider putting the Rayslogic StoreTM link more prominently somewhere, I think people don't know it exists. Need to seed more 96MB PSRAM and P2Plat among the populace for our nefarious schemes. Maybe more aggressive forum signature ad like "Rayslogic Store: [link] - P2 SwAP, P2 Platform, PSRAM expanders and more" added as a 2nd line.
(Also, is a 640x480 RGB816 LCD board still happening?)
Yet unrelatedly to any of those things, but to pad out this post with some non-nonsense of general interest, a "sneak preview" of that alleged WIP software I'd mentioned elsewhere :
(I actually had this on discord days ago, I guess it's go there to get the real (low-effort) scoops?)
(You can tell it's old because for P1CC it doesn't build @zx81vga games yet, which were finished last)
The idea is that you just have to write 1 config and then run this script on it and it will grab all the softwares from their git remotes, configure them, build them (including any tools required) and stuff them into a ready-made directory structure (assuming we had a working SD IPL... of course one can also just load the BIX files from there manually).
Grabbing, configuring and building are mostly working, but I need to find a good way to ingest a machine configuration in a hassle-free manner (i.e. where you can say "A/V accessory on basepin 8" and it automatically figures out the analog audio and video pins) and convert that into project-specific config values. Also PSRAM latency settings are ??? (will definitely need a way both to guess the correct setting and to override that when it goes badly). Also need a way to reject building stuff that can't possibly be configured (e.g. can't configure NeoYume on a PSRAM-less machine no matter how hard you try).
Also need to figure out how to best get the prerequisites and turn that into a guide for Linux/Win/Mac/etc (currently: ruby, git, bison and gcc/build-essentials).
But one can't have their inventory and sell it too
Hmm. Seems dropped the ball on that one. Found some 24-bit ones that were made, but seems we decided at some point that 16-bit would be better.
Also, had to redo connection for pin-35 as that was actually a demo mode switch. Also, wanted to redo header so could work with edge...
Found a new layout, but have to see if it was ever made...
Guess sort of lost interest when found hdmi based lcd modules for decent price...
Why would one want this that uses 16 pins when could just use HDMI with just 8 pins and use a standard cable?
BTW: Got some more wireless controllers for the set top version:
https://www.amazon.com/dp/B0BWY5CJFR?
These are interesting because also come with Nunchuk type adapters.
Not really sure what is going on there, but guess this is wireless I2C?
Sure, but I just feel the sales are entirely synchronized with me making mention of it. (I think another one just went?)
Fair, but they don't offer these with pin header connections, just bothersome HDMI connectors.
No, the controller just sends out whatever signals it does, likely one-way, then the receivers put up a USB HID / I2C front end (respectively) for the system to poll. I wouldn't be surprised if both types of receiver would happen to work simultaneously from the same pad.
You can get one that does the same trick with a variety of Bluetooth controllers: https://www.8bitdo.com/retro-receiver-snes-sfc-classic/ (or the plain old SNES version of this that simulates a shift register... I have that one).
Though wired is always better to me. Less hassle, less latency.
(EDIT) Currently I'd be in a bit of a pickle recommending one, as both of my favorite retro-ish USB controllers have died on me. Those would've been the "Retro-Bit SEGA 8-Button Arcade Pad with USB" (cable went bad) and the "8bitdo SN30 Pro USB" (firmware bricked itself under mysterious circumstances - while connected to my PC, no experimental HW/SW involved). The newer "8bitdo Ultimate 2C Wired" has been good to me so far, but it's a more modern-style layout (and also has trouble with usbnew on P2 sometimes).
Okay, something very interesting just happened.
So, I went to stay at someone else's place last week. I decided to bring the @MXX Thing with me for entertainment, allocating valueable backpack space to it. I built all the emulators with HDMI support and then flashed them to the board.
When I arrived I found that neither of 2 TVs available would accept the signal. One was some crappy new-age thing where everything was really slow, the other was a Samsung very similar to the one I have here at home. (same remote and OS / menu structure)
After some mucking about I found out the following:
Considering two TVs failed, one apparently being extremely similar to the one I have at home, I mentally filed this as a code regression introduced because I only ever test with the ASUS monitor and the VisionRGB card, which both take aaaanything you throw at them. I had Better ThingsTM to do than to thoroughly live-debug this stuff on the scene with my thinkpad and thought I'd be just able to reproduce this at home.
Turns, out, no. It just works on the Samsung TV I have here. So I'm at a loss now as to what would cause this and unable to repro it without spending a day riding stinky trains up north (and bothering my poor hosts by futzing around with their TV).
Possible ideas in order of decreasing likelihood:
So the best thing I can do now is ask if any of y'all on here can test NeoYume on a bunch of different TVs and similar devices. I know I went on a whole bit with @rogloh on debugging it previously on his Pioneer Plasma (can you re-check that still works? I'm going mad out here and need some assurance), so I think I can remote debug these things. Just need someone with a similar repro case (MODE_DVI works but MODE_HDMI does not). (also try the usbnew sample programs with roger's driver, they're less of a hassle to set up)
I found that blanking can easily become too small for some displays. Minimum Hblank of 80 and minimum Vblank of 20 did well on many DVI and HDMI.
EDIT: I guess that's always DVI mode. What is HDMI mode? I didn't know there was a difference.
HDMI mode is HDMI signalling. This allows "data islands" to be sent during blanking (audio packets live here! and that's the main reason to use it over DVI) but the video signalling also changes slightly (presumably to help the sink lock on easier?)
HBlank is plenty large because it needs to fit that whole [data preamble -> data guard -> 2x data packet (audio data + audio clock) -> data guard -> video preamble -> video guard] sequence. I was also using the 640x480 mode, which has really wide blanking to accomodate the high clock speed. Maybe I should re-check this, but all the preambles ought to be sufficiently long (as per HDMI spec). VBlank is NTSC quasi-standard stuff (so plently lines).
EDIT: oh yeah btw HDMI and DVI modes are almost the same in my code, the only thing that really changes is the function pointers that handle sync and blank lines. So the timing should be the same between them. HDMI also enables the audio processing overlay to run during active video, but I don't think it's that, it wouldn't work anywhere at all or introduce visible glitches if that was causing e.g. timing issues.
Maybe needs the 5v ?
Guess would be weird if needed for hdmi but not dvi
No, it's not that thing. It's all properly wired on the MXX thing. But good to note about that for other people trying to test it.
If nothing works at all and you're using the Parallax Digital Video Accessory, try connecting
ACC 5Vto the 5V out pin next to it (ideally with a resistor, but for testing you can just jam a dupont wire in there). Some TVs need this to even let you switch to the input at all (is greyed out otherwise)I’ve tried the emulators with several tvs and it always worked.
Seem to recall that @rogloh also had a very picky TV
With the recent-ish digital audio feature? Well, at this point it's not so recent anymore (V1.4 was released many months ago), but point is that that was a full rewrite of the video code to add that. Maybe time to retry.
Yeah we figured that one out, but IIRC the problem always was with the audio not coming through, the video was fine. We fixed the audio by setting word length in channel status appropriately and reducing sample transmit timing jitter. Both very "soft" issues.
Does make one wonder if it's better to use VGA connector and external converter cable. One needs a cable anyway...
But, VGA just seems so dated at this point that HDMI is nice, especially for this low resolution stuff that works with P2 directly.
HDMI is definitely worth it over VGA. No phase/alignment issues, no signal distortion, just bit-exactly the pixels you put in. Audio, despite needing resampling in some cases, is also much cleaner than analog.
It's definitely a hill to climb to implement it and there's a lot of these nasty edge-cases (though they mostly apply to the HDMI/audio part, DVI is pretty simple, just needs the 8/10 modulation encoder that Chip wisely added in Rev. B )
@Wuerfel_21 Once I get a chance this weekend I'll try it out again on the Pioneer plasma to see if you have a regression. My problem was a combination of multiple effects that also included lack of 5V presence when tested with audio output - all had to work to have audio work.
I wonder if these TVs were somehow being far pickier in their supported resolutions? Did you try out anything really generic like true VGA over HDMI at 25.175 MHz with 800 total pixels / line or 576p/480p etc using standard N/CTS values and without any custom/non-standard timings using shorter blanking intervals etc? i.e Modes associated with VIC values in the various CEA-861 docs.
I also wonder if it could be somehow confused with the Infoframes being sent or their frequency? I vaguely recall there were some minimum settings there - but hopefully your code is already following that.
The DVI versions of the same timings worked, so I'd hope that's not the problem. The PoC driver also worked (incl. audio).
IIRC the main differences between the PoC driver and the final VNG driver used in NeoYume etc (from memory, already went to sleep):
PoC runs at standard 252 MHz, VNG runs at big much 300+MHz with appropriately elongated blanks
PoC treats preamble as own sync command, VNG just extends it backwards (i.e. entire front porch is video preamble)
minor edit: note that the PoC driver never got the pioneer fixes, VNG started development before we did that.
Once per frame - that should be fine.
The big thing I need is someone who can repro this bug.
Yeah that might be part of it if the blanking got massively changed.
Hmm, maybe some TVs don't like that if they are hunting for a FP.
TVs probably need stable sync bits to not get confused.
Yeah I only have the Pioneer unfortunately.
I tried NeoYume MODE_HDMI on two different monitors.
One worked (video+audio) while the other is not working (no signal message).
As expected, using MODE_DVI, works on both monitors.
Nice to see that HDMI works together with VGA using MODE_HDMI_VGA. On VGA the image is a little stretched.
.
.
.
(MODE_DVI_VGA: same monitor DVI on the left, VGA on the right. MODE_DVI also working)
.
.
.
(MODE_HDMI_VGA: same monitor HDMI on the left, VGA on the right. MODE_HDMI also not working)
.
.
.
(MODE_HDMI: on a brand new, huge, ultrawide philips monitor. It works with audio. The image is doubled by a "special" mode of the monitor itself, but it's the same hdmi signal on both sides. Also MODE_HDMI_VGA is ok)
Okay huge thank you @MXX.
Do these monitors that don't work have speakers in the first place? (They in theory should still accept the HDMI-encoded signal, anyways, all the ones I've seen do, but there's a valid chance of being plain DVI devices that just don't like the extended signalling, full-stop)
Also, here is the aforementioned PoC driver (compile
opn2test_top.spin2, should already have the right pins) to try out. This one didn't have the no signal issue for me, but beware that the audio handling on this is missing some bugfixes the VNG driver did get (as discussed above) so it's ok if it's just picture and no sound.BTW: The simultaneous VGA output being stretched is just how it has to be. If you try a game from P1 Classics Collection, you'll notice that those all have a non-stretched VGA output because they use a more relaxed timing. (Note: I didn't have any of these flashed last week and didn't bother testing it, woe is me)