@MXX said:
You're welcome!
Just tested your "poc driver" on the "no signal" monitor used before.
It works ... I also hear the sound.
Bravo! We got it! Treat yourself to one of those sugary italian cookies!
Okay, I'll work on a modified NeoVGA driver that sends only 8 preamble clocks. I re-read the HDMI spec and CTS and it appears that elongating the preamble is not actually allowed (I don't remember where I got that one from?), so I'm trying that first.
Should be ready later today.
EDIT: ostensibly made it, but it's now more broken here, so I think I made a mistake, need to debug that first
I also put the new driver version on NeoYume's git repos. Ought to try porting this to the other driver variants if we can confirm it's good.
(Incidentally, for any testing, it's best (but certainly more annoying) to test all 3 drivers; old, new and the PoC thing from earlier - that way you can differentiate "it always worked" from "I just fixed it")
Other oddity: Apparently an old fix I did for Sonic 1 on MegaYume was left to rot on the dev branch. I noticed this because I just went to port the preamble fix and wanted to put it on dev first because I can't test it right now. Will have to re-test that one now, too. (both are on dev now)
EDIT: Preliminary HDMI preamble fix on dev branch for MisoYume and P1CC, too. On plain video-nextgen branch for Tempest 2000. Still need to re-test all those myself, but they're open for trying as well. If you're confused on wether you're on a branch with the fix, the hsync_preamble symbol got added with the fix, so if you don't have it you're on the old/stable version.
Update: Despite best efforts by The MatrixTM or other higher powers to stop me by way of multiple cancelled trains and traffic jams, I have managed to travel back up to where the problem TV was and test my fix (of course I came just for that purpose, you know my dedication to the mission)
It works now. Yay. 🎊
(I also tested MegaYume, MisoYume, P1CC and Tempest 2000 with the fix applied, all works)
So that settles the score, it was the preamble length thing.
So, updated list of not-quite-obvious things that need to be done for universal HDMI compatibility:
Drive mode should be P_LOW_FAST|P_HIGH_1K5|P_SYNC_IO (Not sure about bitDAC, I abandoned that because I can't use REPO mode with that, but idk if that works at all with SYNC_IO)
Preambles need to be exactly 8 characters/cycles/pixels
There always needs to be at least one data packet sent regularly (otherwise you may see a pink bar on the left edge - video guard band becomes visible because sink switches into DVI mode)
Audio data needs a valid SPDIF channel status. The word length must be set to a non-zero value (I use 24 bit -> check the spec)
Audio clock packets need to be sent at particular intervals (check spec, the details elude me, but if done right this can be a simple "send one every N samples")
Audio data has a maximum amount of allowable jitter. Consecutive packets should never have differing sample population count by more than +/- 1. (so 1-1-2-1-1 is ok, 1-2-2-0-1 is bad)
@evanh said:
PS: I'm pretty sure the fast DAC is wired registered always. The function block has a clock input:
good to know
@Rayman said:
@Wuerfel_21 Do you have something that could be turned into an HDMI .wav file player?
Not beyond the plain driver. If you have a regular program that does DAC audio, adding the digital audio mailbox thing is easy. Every time you write to the DAC pins, you also write a left/right packed sample into the HDMI basepin. The driver also needs to know the sampling period at startup. If you do that, it'll do the rest.
Consider the following snipped grabbed from NeoYume's sound code
mov opn_arg1,opn_dac_center
mov opn_arg2,opn_dac_center
add opn_arg1,opn_filter_left
add opn_arg2,opn_filter_right
' wait for DAC cycle
testp #AUDIO_LEFT wc
if_nc jmp #$-1
wypin opn_arg1,#AUDIO_LEFT
wypin opn_arg2,#AUDIO_RIGHT
setword opn_arg1,opn_filter_left,#0
setword opn_arg1,opn_filter_right,#1
if DIGITAL_BASEPIN >=0
_ret_ wxpin opn_arg1,#DIGITAL_BASEPIN
else
ret
end
The audio sample starts out in opn_filter_left/opn_filter_right and this writes it to both the DAC pins (unsigned $0000..$FF00 each) and the HDMI mailbox (upper/lower packed signed words).
@Wuerfel_21 said:
Update: Despite best efforts by The MatrixTM or other higher powers to stop me by way of multiple cancelled trains and traffic jams, I have managed to travel back up to where the problem TV was and test my fix (of course I came just for that purpose, you know my dedication to the mission)
It works now. Yay. 🎊
(I also tested MegaYume, MisoYume, P1CC and Tempest 2000 with the fix applied, all works)
So that settles the score, it was the preamble length thing.
So, updated list of not-quite-obvious things that need to be done for universal HDMI compatibility:
Drive mode should be P_LOW_FAST|P_HIGH_1K5|P_SYNC_IO (Not sure about bitDAC, I abandoned that because I can't use REPO mode with that, but idk if that works at all with SYNC_IO)
Preambles need to be exactly 8 characters/cycles/pixels
There always needs to be at least one data packet sent regularly (otherwise you may see a pink bar on the left edge - video guard band becomes visible because sink switches into DVI mode)
Audio data needs a valid SPDIF channel status. The word length must be set to a non-zero value (I use 24 bit -> check the spec)
Audio clock packets need to be sent at particular intervals (check spec, the details elude me, but if done right this can be a simple "send one every N samples")
Audio data has a maximum amount of allowable jitter. Consecutive packets should never have differing sample population count by more than +/- 1. (so 1-1-2-1-1 is ok, 1-2-2-0-1 is bad)
Glad you found your fix and created the list above of important things to be considered. I still haven't tested any of your recent changes but if/once I do retry it on the Pioneer I'll be sure to let you know if there's any regression there for me (I'm basically assuming not for now).
I think the Preamble was always specified as 8 pixels in the HDMI docs and after double checking the code I've already ensured sure my driver variant used that too.
x1 xcont m_imm8, video_preamble 'send preamble before active video
x2 xcont m_imm2, video_guard 'send video guard before active video
....
m_imm8 long X_IMM_1X32_4DAC8 | X_PINS_ON | 8
m_imm2 long X_IMM_1X32_4DAC8 | X_PINS_ON | 2
Comments
You're welcome!
Just tested your "poc driver" on the "no signal" monitor used before.
It works ... I also hear the sound.
Bravo! We got it! Treat yourself to one of those sugary italian cookies!
Okay, I'll work on a modified NeoVGA driver that sends only 8 preamble clocks. I re-read the HDMI spec and CTS and it appears that elongating the preamble is not actually allowed (I don't remember where I got that one from?), so I'm trying that first.
Should be ready later today.
EDIT: ostensibly made it, but it's now more broken here, so I think I made a mistake, need to debug that first
okay @MXX can you try NeoYume with this patched driver (more spec-compliant preamble timing)
Great, this works like a charm!
Will try on a few more monitors I have around and let you know
Awesome awesome awsome
I also put the new driver version on NeoYume's git repos. Ought to try porting this to the other driver variants if we can confirm it's good.
(Incidentally, for any testing, it's best (but certainly more annoying) to test all 3 drivers; old, new and the PoC thing from earlier - that way you can differentiate "it always worked" from "I just fixed it")
Other oddity: Apparently an old fix I did for Sonic 1 on MegaYume was left to rot on the
devbranch. I noticed this because I just went to port the preamble fix and wanted to put it on dev first because I can't test it right now. Will have to re-test that one now, too. (both are ondevnow)EDIT: Preliminary HDMI preamble fix on dev branch for MisoYume and P1CC, too. On plain video-nextgen branch for Tempest 2000. Still need to re-test all those myself, but they're open for trying as well. If you're confused on wether you're on a branch with the fix, the
hsync_preamblesymbol got added with the fix, so if you don't have it you're on the old/stable version.Update: Despite best efforts by The MatrixTM or other higher powers to stop me by way of multiple cancelled trains and traffic jams, I have managed to travel back up to where the problem TV was and test my fix (of course I came just for that purpose, you know my dedication to the mission)
It works now. Yay. 🎊
(I also tested MegaYume, MisoYume, P1CC and Tempest 2000 with the fix applied, all works)
So that settles the score, it was the preamble length thing.
So, updated list of not-quite-obvious things that need to be done for universal HDMI compatibility:
P_LOW_FAST|P_HIGH_1K5|P_SYNC_IO(Not sure about bitDAC, I abandoned that because I can't use REPO mode with that, but idk if that works at all with SYNC_IO)Cool, and quite the list.
PS: I'm pretty sure the fast DAC is wired registered always. The function block has a clock input:
@Wuerfel_21 Do you have something that could be turned into an HDMI .wav file player?
good to know
Not beyond the plain driver. If you have a regular program that does DAC audio, adding the digital audio mailbox thing is easy. Every time you write to the DAC pins, you also write a left/right packed sample into the HDMI basepin. The driver also needs to know the sampling period at startup. If you do that, it'll do the rest.
Consider the following snipped grabbed from NeoYume's sound code
mov opn_arg1,opn_dac_center mov opn_arg2,opn_dac_center add opn_arg1,opn_filter_left add opn_arg2,opn_filter_right ' wait for DAC cycle testp #AUDIO_LEFT wc if_nc jmp #$-1 wypin opn_arg1,#AUDIO_LEFT wypin opn_arg2,#AUDIO_RIGHT setword opn_arg1,opn_filter_left,#0 setword opn_arg1,opn_filter_right,#1 if DIGITAL_BASEPIN >=0 _ret_ wxpin opn_arg1,#DIGITAL_BASEPIN else ret endThe audio sample starts out in opn_filter_left/opn_filter_right and this writes it to both the DAC pins (unsigned $0000..$FF00 each) and the HDMI mailbox (upper/lower packed signed words).
Glad you found your fix and created the list above of important things to be considered. I still haven't tested any of your recent changes but if/once I do retry it on the Pioneer I'll be sure to let you know if there's any regression there for me (I'm basically assuming not for now).
I think the Preamble was always specified as 8 pixels in the HDMI docs and after double checking the code I've already ensured sure my driver variant used that too.
I've just bumped new versions of all the emulators that formally incorporate the HDMI preamble fix.
This is MegaYume V1.5, NeoYume V1.5 and MisoYume beta12.
Other included changes: