So I finally managed to properly get that pesky VisionRGB capture card set up. Had to hack up a full size PCI bracket to mount it safely in the computer. Also had edit the driver a bunch to keep up with Linux kernel bitrot, including hex-editing a binary blob so it doesn't use a strlcpy function that apparently got deleted. Still doesn't work quite right, fails to allocate certain sizes of framebuffer. Changing between 24 and 32 bit format can help, but urrrgh.
Anyways, here are some real P2 screenshots, running MisoYume with HDMI output.
Yeah, maybe not the most interesting thing to screenshot... Tempest doesn't want to do HDMI capture right now, but VGA works:
beta02 is old, 06 should be current I think.
If your room is hot it might die. Or maybe RAM timing isn't ideal.
SMW only saves progress after a castle or switch palace.
Also, git versions of MegaYume/NeoYume have been patched to use P_DAC_DITHER_PWM mode for higher quality audio. (As discovered during MisoYume development, the clock divider does not need to be a multiple of 256). The improvement is mostly lost on MegaYume since it has rather hot output levels to begin with and simulates characteristic YM2612 DAC distortion in software, but NeoYume sounds a good bit nicer.
I find myself embroiled in an attempt to rewrite the emulator video driver to hopefully make it more flexible and eventually support the long yearned for HDMI audio.
Current status: VGA works, DVI/HDMI at the stage where the monitor screams "OUT OF RANGE". Everything else not yet put in.
HDMI with audio would be awesome. I have a version of SimpleP2 around somewhere with VGA/headphone replaced by HDMI.
Doesn't really make sense unless can do HDMI audio though...
I've got DVI and VGA working right now (including simultaneously! Though the timing is constrained to what DVI can do, which means the VGA output is squished)
Now wrenching the audio stuff in there! The complexity difference between the basic DVI mode driver (which is arguably a bit easier even than VGA) and wrenching all this HDMI stuff in there is staggering.
Afterwards (in no particular order):
Add all the other analog formats back in (just need serrated sync functions and some definitions I think...)
Add 6bit LCD support back (does anyone even care?)
Port to MegaYume and fix features that needs (256-wide and interlace). I'm currently building this for NeoYume first.
Port it to Tempest 2000
Port it to MisoYume (audio may cause additional issues once I start hard-syncing the audio to the CPU though)
Mind that it's super unfinished and most of the apparently available configs do nothing or break, but setting MODE_HDMI, MODE_DVI or MODE_VGA should give you expected output (MODE_HDMI_VGA does dual output, rarely useful). Submodes are currently ignored. MODE_HDMI is of course the salient one, since that will enable embedded PCM audio.
Do note that the normal DAC audio pins still need to exist and weird things will happen if you accidentally set them to share with the HDMI pins.
On the upstairs TV it's not so good yet. Video is good (with overscan flag set it crops it down perfectly to 640x448), but audio cuts out every few seconds. I'm guessing it's very slowly underrunning the TV's buffer. So either the resampler math is bung or input samples are being skipped (likely if polls are too far apart or the input buffer overruns - though neither should really happen, there's at most 2 new samples posted to the MB per scanline). Could in theory also be the YM2610 core lagging behind, but I don't think that's happening at 338 MHz.
Though there's some other oddities with the TV. It actually crops to 608x448, which is fine for NeoGeo I guess, but odd that it overscans horizontally even when pillarboxing. But also there's frame pacing problems?!?! The shadows in fighting games usually flash on and off at 30Hz. On a proper monitor this should be perfectly smooth (unless the game has slowdown - note that Last Blade updates the shadows even when paused, so that's a good test), but on the TV it seems to sometimes duplicate a frame. How do you mess something like that up? (Capture card preview windows also tend to do this, for they are beholden to the PCs desktop refresh rate)
Strange observation: The VisionRGB really does not like the P_LOW_15K|P_HIGH_1K5 TMDS drive mode (this is what Chip uses in his demos, btw). BITDAC isn't available because of P_REPOSITORY. However I found P_LOW_FAST|P_HIGH_1K5 to work. What gives? I have no idea about high-speed differential transmission lines.
But yea, with that change the new driver is now VisionRGB compliant or smth (take note that it's called a Vision RGB, it does nothing with audio)
Interesting. If there was an audio related underrun bug before with buffer you just fixed I should retest your code on my Pioneer Plasma HDTV's HDMI input again. Maybe it will work for me now? It seems particularly strict with its audio so if something was wrong there it might just give up decoding audio. I'll try again later.
@rogloh said:
Interesting. If there was an audio related underrun bug before with buffer you just fixed I should retest your code on my Pioneer Plasma HDTV's HDMI input again. Maybe it will work for me now? It seems particularly strict with its audio so if something was wrong there it might just give up decoding audio. I'll try again later.
Nope, no luck. Still no HDMI audio on this TV. I think I had configured it correctly to expect that to work with you latest code test branch I just downloaded today. I put the AV board on P24, USB board on P16, and HDMI board on P32. Config.spin2 snipped below.
HDMI video looks fine . Also messed about with TV audio related settings and nothing seemed to get it to output. Starting to wonder if audio into this TV might work only with YUV style video content perhaps which is what my PVR feeds it? Nah, I guess my Playstation 3 could feed RGB and Apple TV does work too so that doesn't make sense given they've likely worked before with sound on this device in RGB modes. I really need to capture some HDMI bitstreams and see what the audio is doing to know what is different and why it doesn't accept it. Especially since my own HDMI audio code was so close and should have worked in theory too. Maybe the sample rate has to be 100% rock solid for it to lock on and those fiddly N/CTS values and audio timing regen packet data probably need to be perfect and arrive on time, etc. If I can capture the output of my PVR and decipher it I'll have some hope of figuring it out one day or just wait to get another PC/MAC monitor which I have absolutely zero room for on my desk. Only 6 large monitors in this room right now plus laptop screens none of which accept actual HDMI (all DVI based) except for my plasma TV and Home theatre AVR stuff in a different room. Ok maybe I should try the AVR input again too. EDIT: nah the AVR doesn't show/output any AV at all. Don't think it likes this signal type. Everything I try is hosed.
'{ ' NEW NEW NEW
VIDEO_MODE = vconst.MODE_HDMI
VIDEO_SUBMODE = vconst.SUBMODE_2X ' CURRENTLY IGNORED
ANALOG_BASEPIN = 24
VSYNC_PIN = 24+4
DIGITAL_BASEPIN = 32 ' MUST be -1 if not present
DIGITAL_REVERSED = false
Update: By the way @Wuerfel_21 , I'm still deciphering what you are doing but I think for outputting 48kHz PCM audio you are meant to just set N to a fixed known value of 6144 and then compute CTS based on the number of TMDS clocks that arrive in an (or each?) N/(128 * sample_rate) time period. How frequently this needs to be sent I'm not entirely sure however. I am thinking it might be at this same rate as the CTS accumulation period occurring or (128 * sample_rate)/N. So it may need to be compensated for (by varying CTS) if it gets delayed in relation to the actual expected transmission time, ie. if the packet is delayed by actual video pixels or by audio sample packets etc and doesn't happen right at the CTS accumulation interval time. If you are not doing this it may explain why my TV is not working, but I'm not really that sure myself. I may have to do some experimenting here.
For your AVR, have you tried connecting the 5V pin on the HDMI board? My upstairs TV needs that to even be able to select the input. Also, try setting TMDS_DRIVE_MODE = P_REPOSITORY|P_OE|P_LOW_FAST|P_HIGH_1K5 (In NeoVGA) as per the observation above. My VisionRGB doesn't detect anything with the current repo value. Should maybe push that change.
As for the N/CTS stuff:
N/CTS is the ratio between the audio clock(=sample rate*128) and the video clock (TMDS clock pin = P2 sysclk/10). Since the sample rate is itself constrained to be sysclk/some integer, constant a constant N/CTS value can be used (you'd only need to do the counting if you're getting data from an asynchronous input)
So for CLKFREQ = 338_349_606 and 48000 kHz, we get:
SAMPLE_OUT_PERIOD: 7049
N: 6400
CTS: 35240
These values are correct and satisfy the spec requirement that 128·fS / 1500Hz ≤ N ≤ 128·fS / 300Hz (4096 ≤ 6400 ≤ 20480)
(note that SAMPLE_OUT_PERIOD comes out to 48006 Hz - try setting it to 7050 and see if just being closer to the standard rate fixes it?)
Being able to capture some working traffic would make it easier to debug for sure, but you'd need some sort of super fancy quad-channel ultra-high-speed scope to do that, I think.
@Wuerfel_21 said:
For your AVR, have you tried connecting the 5V pin on the HDMI board? My upstairs TV needs that to even be able to select the input. Also, try setting TMDS_DRIVE_MODE = P_REPOSITORY|P_OE|P_LOW_FAST|P_HIGH_1K5 (In NeoVGA) as per the observation above. My VisionRGB doesn't detect anything with the current repo value. Should maybe push that change.
Yeah I will give that a try too next time around.
As for the N/CTS stuff:
N/CTS is the ratio between the audio clock(=sample rate*128) and the video clock (TMDS clock pin = P2 sysclk/10). Since the sample rate is itself constrained to be sysclk/some integer, constant a constant N/CTS value can be used (you'd only need to do the counting if you're getting data from an asynchronous input)
So for CLKFREQ = 338_349_606 and 48000 kHz, we get:
SAMPLE_OUT_PERIOD: 7049
N: 6400
CTS: 35240
These values are correct and satisfy the spec requirement that 128·fS / 1500Hz ≤ N ≤ 128·fS / 300Hz (4096 ≤ 6400 ≤ 20480)
(note that SAMPLE_OUT_PERIOD comes out to 48006 Hz - try setting it to 7050 and see if just being closer to the standard rate fixes it?)
I have a feeling you are meant to send one regen packet each time the interval expires and update the CTS value depending on any deviation from the last time it was sent. This way a receiver can look at the arrival time of each CTS packet and update its counters/divisors/multipliers to derive a PLL locked frequency for audio and stream out samples at the expected rate. If your regen packet is only ever computed once with static data inside and you send it out with some timing variation between packets instead of the exact number of TMDS clocks specified by the CTS value, that could upset the clock regeneration at a receiver and potentially under/overrun buffers which may make it mute the output. This is my theory as to why things aren't yet working for my gear. A monitor is likely much less stringent vs a TV/AVR and may not care if this happens.
In my old HDMI audio test code running at 32kHz I was trying to setup N=4096 and send out one regen packet every 32 audio samples (~1msec intervals) with pixel clock at 27MHz and a notional CTS of 27000 (1ms) but there would always be some jitter due to the scan line frequency being separated from the audio sampling rate and only having select times that the data island can carry packets. I also didn't update this CTS value each time the packet was sent, but I'm now thinking if I read in the interval duration in P2 clocks since the last clock regen packet was sent and divide it by 10 (sysclk = 10x TMDS clocks) and used that for the CTS value before encoding it, it may actually work. My code already TERC encoded on the fly but just used constant data.
Being able to capture some working traffic would make it easier to debug for sure, but you'd need some sort of super fancy quad-channel ultra-high-speed scope to do that, I think.
It'd be neat if there were devices like that TVP7002TFP401 part I found that could output the 10 bit TMDS symbols to be captured on each channel at the pixel clock rate instead of pure RGB/YCrCb 8 bit data. Then the P2 could capture that and try to decode the bitstream offline.
@rogloh said:
I have a feeling you are meant to send one regen packet each time the interval expires and update the CTS value depending on any deviation from the last time it was sent. This way a receiver can look at the arrival time of each CTS packet and update its counters/divisors/multipliers to derive a PLL locked frequency for audio and stream out samples at the expected rate. If your regen packet is only ever computed once with static data inside and you send it out with some timing variation between packets instead of the exact number of TMDS clocks specified by the CTS value, that could upset the clock regeneration at a receiver and potentially under/overrun buffers which may make it mute the output. This is my theory as to why things aren't yet working for my gear. A monitor is likely much less stringent vs a TV/AVR and may not care if this happens.
Yeah, you are supposed to send it at a particular interval (every N audio clocks). I'm only sending it once per frame. I'm thinking that it really shouldn't matter if CTS is constant.
Transmitting them at exactly the right rate is tricky, have to think about that.
I did see that my TV was more picky than my monitor. Though idk about your AVR, if it doesn't pick up the signal at all, something else is wrong. Audio errors shouldn't affect video at all.
@rogloh said:
I have a feeling you are meant to send one regen packet each time the interval expires and update the CTS value depending on any deviation from the last time it was sent. This way a receiver can look at the arrival time of each CTS packet and update its counters/divisors/multipliers to derive a PLL locked frequency for audio and stream out samples at the expected rate. If your regen packet is only ever computed once with static data inside and you send it out with some timing variation between packets instead of the exact number of TMDS clocks specified by the CTS value, that could upset the clock regeneration at a receiver and potentially under/overrun buffers which may make it mute the output. This is my theory as to why things aren't yet working for my gear. A monitor is likely much less stringent vs a TV/AVR and may not care if this happens.
Yeah, you are supposed to send it at a particular interval (every N audio clocks). I'm only sending it once per frame. I'm thinking that it really shouldn't matter if CTS is constant.
Transmitting them at exactly the right rate is tricky, have to think about that.
The rate could vary a bit, but the CTS might have to change dynamically based on the measured jitter at tx time vs last tx time.
I did see that my TV was more picky than my monitor. Though idk about your AVR, if it doesn't pick up the signal at all, something else is wrong. Audio errors shouldn't affect video at all.
Maybe it's the electrical stuff - I will retest with your change and the 5V, however maybe it's also the resolution if you are sending something funky it doesn't support in its EDID from my Epson projector that it drives. It's probably intended for TV video sources although I do think it can take some PC resolution stuff too.
No, CTS should not change because samples are generated at an exact rate that is perfectly expressed by the N/CTS ratio (this explicitly should NOT be affected by the transmission time of packets, the whole goal of this ordeal is to remove the jitter introduced by pushing data to the next blanking area).
Given the way I calculate N/CTS, there's always an integer number of samples per interval (in this case 50), so that's useful. Will look into transmitting more CTS packets I guess.
The video timing by necessity has to far removed from any sort of standard-specified mode. But IME weird modes just work. My monitor here is perfectly happy to sync to very cool and normal modes like 642x480. The current NeoVGA hardcoded mode is PC-style 640x480 with a really elongated back porch and a slightly off frame-rate (off from a 60/59.94 standard, that is, but close to the real NeoGeo AES speed)
Just tried the two things on the AVR (5V and signal strength change). The projector info screen reported getting a signal of RGB 640x480 at 59.60 Hz refresh but it was black and still no audio either. No dice.
Can you please give more information how to make you magic stuf working.
I do not understand the flexspin build.sh as explained on you github page?.
Where do I have to "Run build.sh"
Can I use an IDE on a apple or windows pc to run you console?
I use to run propeller stuf inside "spin tools" "flexprop" "Pnut"... In a normal spin, spin2 code.
The part of SDsetup, config.spin2 and ram I understand, but how to build it, not.
You console looks great and just want to try it on a P2 edge & 32ram
Comments
Yeah it does that! There's a SAV file it creates to store the save data. It's tiny!
So I finally managed to properly get that pesky VisionRGB capture card set up. Had to hack up a full size PCI bracket to mount it safely in the computer. Also had edit the driver a bunch to keep up with Linux kernel bitrot, including hex-editing a binary blob so it doesn't use a
strlcpyfunction that apparently got deleted. Still doesn't work quite right, fails to allocate certain sizes of framebuffer. Changing between 24 and 32 bit format can help, but urrrgh.Anyways, here are some real P2 screenshots, running MisoYume with HDMI output.
Yeah, maybe not the most interesting thing to screenshot... Tempest doesn't want to do HDMI capture right now, but VGA works:
@Wuerfel_21 Did you get HDMI audio working with these?
Not yet, that sort of went on a shelf.
Just tried Super Mario World with beta2 of misoyume using Eval and 96 MB board.
Everything looks good!
Have a beta tester on it now
Uh oh, went dark after ~10 minutes. Guess even Eval needs cooling...
Also, seems we don't understand how progress saving works...
beta02 is old, 06 should be current I think.
If your room is hot it might die. Or maybe RAM timing isn't ideal.
SMW only saves progress after a castle or switch palace.
Ok, think it was just a sketchy hardware connection and not overheating...
Tester made it to first boss without any issues...
Nice.
Also, git versions of MegaYume/NeoYume have been patched to use
P_DAC_DITHER_PWMmode for higher quality audio. (As discovered during MisoYume development, the clock divider does not need to be a multiple of 256). The improvement is mostly lost on MegaYume since it has rather hot output levels to begin with and simulates characteristic YM2612 DAC distortion in software, but NeoYume sounds a good bit nicer.I find myself embroiled in an attempt to rewrite the emulator video driver to hopefully make it more flexible and eventually support the long yearned for HDMI audio.
Current status: VGA works, DVI/HDMI at the stage where the monitor screams "OUT OF RANGE". Everything else not yet put in.
HDMI with audio would be awesome. I have a version of SimpleP2 around somewhere with VGA/headphone replaced by HDMI.
Doesn't really make sense unless can do HDMI audio though...
I've got DVI and VGA working right now (including simultaneously! Though the timing is constrained to what DVI can do, which means the VGA output is squished)
Now wrenching the audio stuff in there! The complexity difference between the basic DVI mode driver (which is arguably a bit easier even than VGA) and wrenching all this HDMI stuff in there is staggering.
Afterwards (in no particular order):
HDMI audio now working in my "controlled test environment"(TM).
If someone wants to play with it, work is uploaded to branch
video-nextgenon the github: https://github.com/IRQsome/neoyume/tree/video-nextgenMind that it's super unfinished and most of the apparently available configs do nothing or break, but setting MODE_HDMI, MODE_DVI or MODE_VGA should give you expected output (MODE_HDMI_VGA does dual output, rarely useful). Submodes are currently ignored. MODE_HDMI is of course the salient one, since that will enable embedded PCM audio.
Do note that the normal DAC audio pins still need to exist and weird things will happen if you accidentally set them to share with the HDMI pins.
Suppose another option is spdif audio if that’s easier…
Just needs one pin…
But hdmi audio is awesome
No, S/PDIF is not really easier at all.
On the upstairs TV it's not so good yet. Video is good (with overscan flag set it crops it down perfectly to 640x448), but audio cuts out every few seconds. I'm guessing it's very slowly underrunning the TV's buffer. So either the resampler math is bung or input samples are being skipped (likely if polls are too far apart or the input buffer overruns - though neither should really happen, there's at most 2 new samples posted to the MB per scanline). Could in theory also be the YM2610 core lagging behind, but I don't think that's happening at 338 MHz.
Okay, I fixed it. T'was a mere typo: https://github.com/IRQsome/neoyume/commit/c849f0f8a451252df81cd79079238a0d425f4f95 of course. I think these variables are poorly named, anyways...
HDMI audio in NeoYume preview still at https://github.com/IRQsome/neoyume/tree/video-nextgen
Though there's some other oddities with the TV. It actually crops to 608x448, which is fine for NeoGeo I guess, but odd that it overscans horizontally even when pillarboxing. But also there's frame pacing problems?!?! The shadows in fighting games usually flash on and off at 30Hz. On a proper monitor this should be perfectly smooth (unless the game has slowdown - note that Last Blade updates the shadows even when paused, so that's a good test), but on the TV it seems to sometimes duplicate a frame. How do you mess something like that up? (Capture card preview windows also tend to do this, for they are beholden to the PCs desktop refresh rate)
Strange observation: The VisionRGB really does not like the
P_LOW_15K|P_HIGH_1K5TMDS drive mode (this is what Chip uses in his demos, btw). BITDAC isn't available because of P_REPOSITORY. However I foundP_LOW_FAST|P_HIGH_1K5to work. What gives? I have no idea about high-speed differential transmission lines.But yea, with that change the new driver is now VisionRGB compliant or smth (take note that it's called a Vision RGB, it does nothing with audio)
Interesting. If there was an audio related underrun bug before with buffer you just fixed I should retest your code on my Pioneer Plasma HDTV's HDMI input again. Maybe it will work for me now? It seems particularly strict with its audio so if something was wrong there it might just give up decoding audio. I'll try again later.
Nope, no luck. Still no HDMI audio on this TV. I think I had configured it correctly to expect that to work with you latest code test branch I just downloaded today. I put the AV board on P24, USB board on P16, and HDMI board on P32. Config.spin2 snipped below.
HDMI video looks fine . Also messed about with TV audio related settings and nothing seemed to get it to output. Starting to wonder if audio into this TV might work only with YUV style video content perhaps which is what my PVR feeds it? Nah, I guess my Playstation 3 could feed RGB and Apple TV does work too so that doesn't make sense given they've likely worked before with sound on this device in RGB modes. I really need to capture some HDMI bitstreams and see what the audio is doing to know what is different and why it doesn't accept it. Especially since my own HDMI audio code was so close and should have worked in theory too. Maybe the sample rate has to be 100% rock solid for it to lock on and those fiddly N/CTS values and audio timing regen packet data probably need to be perfect and arrive on time, etc. If I can capture the output of my PVR and decipher it I'll have some hope of figuring it out one day or just wait to get another PC/MAC monitor which I have absolutely zero room for on my desk.
Only 6 large monitors in this room right now plus laptop screens none of which accept actual HDMI (all DVI based) except for my plasma TV and Home theatre AVR stuff in a different room. Ok maybe I should try the AVR input again too. EDIT: nah the AVR doesn't show/output any AV at all. Don't think it likes this signal type. Everything I try is hosed.
'{ ' NEW NEW NEW VIDEO_MODE = vconst.MODE_HDMI VIDEO_SUBMODE = vconst.SUBMODE_2X ' CURRENTLY IGNORED ANALOG_BASEPIN = 24 VSYNC_PIN = 24+4 DIGITAL_BASEPIN = 32 ' MUST be -1 if not present DIGITAL_REVERSED = falseUpdate: By the way @Wuerfel_21 , I'm still deciphering what you are doing but I think for outputting 48kHz PCM audio you are meant to just set N to a fixed known value of 6144 and then compute CTS based on the number of TMDS clocks that arrive in an (or each?) N/(128 * sample_rate) time period. How frequently this needs to be sent I'm not entirely sure however. I am thinking it might be at this same rate as the CTS accumulation period occurring or (128 * sample_rate)/N. So it may need to be compensated for (by varying CTS) if it gets delayed in relation to the actual expected transmission time, ie. if the packet is delayed by actual video pixels or by audio sample packets etc and doesn't happen right at the CTS accumulation interval time. If you are not doing this it may explain why my TV is not working, but I'm not really that sure myself. I may have to do some experimenting here.
For your AVR, have you tried connecting the 5V pin on the HDMI board? My upstairs TV needs that to even be able to select the input. Also, try setting
TMDS_DRIVE_MODE = P_REPOSITORY|P_OE|P_LOW_FAST|P_HIGH_1K5(In NeoVGA) as per the observation above. My VisionRGB doesn't detect anything with the current repo value. Should maybe push that change.As for the N/CTS stuff:
N/CTS is the ratio between the audio clock(=sample rate*128) and the video clock (TMDS clock pin = P2 sysclk/10). Since the sample rate is itself constrained to be sysclk/some integer, constant a constant N/CTS value can be used (you'd only need to do the counting if you're getting data from an asynchronous input)
So for CLKFREQ = 338_349_606 and 48000 kHz, we get:
SAMPLE_OUT_PERIOD: 7049
N: 6400
CTS: 35240
These values are correct and satisfy the spec requirement that 128·fS / 1500Hz ≤ N ≤ 128·fS / 300Hz (4096 ≤ 6400 ≤ 20480)
(note that SAMPLE_OUT_PERIOD comes out to 48006 Hz - try setting it to 7050 and see if just being closer to the standard rate fixes it?)
Being able to capture some working traffic would make it easier to debug for sure, but you'd need some sort of super fancy quad-channel ultra-high-speed scope to do that, I think.
Yeah I will give that a try too next time around.
I have a feeling you are meant to send one regen packet each time the interval expires and update the CTS value depending on any deviation from the last time it was sent. This way a receiver can look at the arrival time of each CTS packet and update its counters/divisors/multipliers to derive a PLL locked frequency for audio and stream out samples at the expected rate. If your regen packet is only ever computed once with static data inside and you send it out with some timing variation between packets instead of the exact number of TMDS clocks specified by the CTS value, that could upset the clock regeneration at a receiver and potentially under/overrun buffers which may make it mute the output. This is my theory as to why things aren't yet working for my gear. A monitor is likely much less stringent vs a TV/AVR and may not care if this happens.
In my old HDMI audio test code running at 32kHz I was trying to setup N=4096 and send out one regen packet every 32 audio samples (~1msec intervals) with pixel clock at 27MHz and a notional CTS of 27000 (1ms) but there would always be some jitter due to the scan line frequency being separated from the audio sampling rate and only having select times that the data island can carry packets. I also didn't update this CTS value each time the packet was sent, but I'm now thinking if I read in the interval duration in P2 clocks since the last clock regen packet was sent and divide it by 10 (sysclk = 10x TMDS clocks) and used that for the CTS value before encoding it, it may actually work. My code already TERC encoded on the fly but just used constant data.
It'd be neat if there were devices like that TVP7002TFP401 part I found that could output the 10 bit TMDS symbols to be captured on each channel at the pixel clock rate instead of pure RGB/YCrCb 8 bit data. Then the P2 could capture that and try to decode the bitstream offline.
Yeah, you are supposed to send it at a particular interval (every N audio clocks). I'm only sending it once per frame. I'm thinking that it really shouldn't matter if CTS is constant.
Transmitting them at exactly the right rate is tricky, have to think about that.
I did see that my TV was more picky than my monitor. Though idk about your AVR, if it doesn't pick up the signal at all, something else is wrong. Audio errors shouldn't affect video at all.
The rate could vary a bit, but the CTS might have to change dynamically based on the measured jitter at tx time vs last tx time.
Maybe it's the electrical stuff - I will retest with your change and the 5V, however maybe it's also the resolution if you are sending something funky it doesn't support in its EDID from my Epson projector that it drives. It's probably intended for TV video sources although I do think it can take some PC resolution stuff too.
No, CTS should not change because samples are generated at an exact rate that is perfectly expressed by the N/CTS ratio (this explicitly should NOT be affected by the transmission time of packets, the whole goal of this ordeal is to remove the jitter introduced by pushing data to the next blanking area).
Given the way I calculate N/CTS, there's always an integer number of samples per interval (in this case 50), so that's useful. Will look into transmitting more CTS packets I guess.
The video timing by necessity has to far removed from any sort of standard-specified mode. But IME weird modes just work. My monitor here is perfectly happy to sync to very cool and normal modes like 642x480. The current NeoVGA hardcoded mode is PC-style 640x480 with a really elongated back porch and a slightly off frame-rate (off from a 60/59.94 standard, that is, but close to the real NeoGeo AES speed)
Just tried the two things on the AVR (5V and signal strength change). The projector info screen reported getting a signal of RGB 640x480 at 59.60 Hz refresh but it was black and still no audio either. No dice.
If you plug into the projector directly, does that work?
Wurfel_21,
Can you please give more information how to make you magic stuf working.
I do not understand the flexspin build.sh as explained on you github page?.
Where do I have to "Run build.sh"
Can I use an IDE on a apple or windows pc to run you console?
I use to run propeller stuf inside "spin tools" "flexprop" "Pnut"... In a normal spin, spin2 code.
The part of SDsetup, config.spin2 and ram I understand, but how to build it, not.
You console looks great and just want to try it on a P2 edge & 32ram
Thank-you