@Wuerfel_21 said:
You don't even need a block transfer, regular streamer DMA will do it. That's what my experimental code did. The real problem (and this is NeoYume specific) is that the lower code will obliterate all our upper hub memory as soon as the game starts. It all has to be in cog/lut.
Yeah the run-time environment for testing is not ideal. If the video driver was separate it might be easier to instrument and debug. EDIT: you'd probably need some audio source too.
@rogloh said:
I wish I could capture your output for analysis with my decoder program to see what is wrong with the video bitstream but this mailbox thing makes a mess of it and it can't be logged.
What/how are you trying to log? The mailbox should really not get in the way. If you make the whole thing run slow, it will just fill up the audio packets with too many samples, but that ought to be fine.
@rogloh said:
I wish I could capture your output for analysis with my decoder program to see what is wrong with the video bitstream but this mailbox thing makes a mess of it and it can't be logged.
What/how are you trying to log? The mailbox should really not get in the way. If you make the whole thing run slow, it will just fill up the audio packets with too many samples, but that ought to be fine.
I want to log the 8 bit output pattern on the HDMI port at the 10x pixel rate.
@Wuerfel_21 said:
You don't even need a block transfer, regular streamer DMA will do it. That's what my experimental code did. The real problem (and this is NeoYume specific) is that the lower code will obliterate all our upper hub memory as soon as the game starts. It all has to be in cog/lut.
Yeah the run-time environment for testing is not ideal. If the video driver was separate it might be easier to instrument and debug. EDIT: you'd probably need some audio source too.
There's a vgatest.spin2 file I use for that, but there's no sound source. I guess I can add the usual sine wave nonsense.
@rogloh said:
I wish I could capture your output for analysis with my decoder program to see what is wrong with the video bitstream but this mailbox thing makes a mess of it and it can't be logged.
What/how are you trying to log? The mailbox should really not get in the way. If you make the whole thing run slow, it will just fill up the audio packets with too many samples, but that ought to be fine.
I want to log the 8 bit output pattern on the HDMI port at the 10x pixel rate.
Ah, then just move the mailbox pin somewhere else, needs a few lines of change.
This conversation is very asynchronous and mailbox-like.
If there was a simple test program you had that feeds some audio and a static RGB pattern to your driver, with some free COGs left over I might be able to take it and add my PSRAM driver and then capture some HDMI port bytes for a couple of frames. I'd need at least 2 free COGs, ideally 3 to do this.
@rogloh said:
If there was a simple test program you had that feeds some audio and a static RGB pattern to your driver, with some free COGs left over I might be able to take it and add my PSRAM driver and then capture some HDMI port bytes for a couple of frames. I'd need at least 2 free COGs, ideally 3 to do this.
See vgatest.spin2 in latest commit (I've put it on both branches). I added a nicer test pattern and a sine wave oscillator to stand in for OPNBcog.
@rogloh said:
If there was a simple test program you had that feeds some audio and a static RGB pattern to your driver, with some free COGs left over I might be able to take it and add my PSRAM driver and then capture some HDMI port bytes for a couple of frames. I'd need at least 2 free COGs, ideally 3 to do this.
See vgatest.spin2 in latest commit (I've put it on both branches). I added a nicer test pattern and a sine wave oscillator to stand in for OPNBcog.
Ok cool. Thanks. I'll try take a look in a little while after dinner.
@Wuerfel_21 said:
@rogloh I found a typo that may have caused the sync issues, checkout latest commit.
Yes this image works on my projector (direct) and plasma TV like the other branch did. So some bug was certainly fixed with your latest change. Still no audio on either device, and blank video if I try to pass it through the AVR.
I found when I turned up the volume on my plasma TV really loud, I could hear a semi-random periodic ticking/crackling sound ~2Hz as if it was trying to play samples from something arriving to it but not able to and sort of resetting regularly.
Ok so it turns out I was doing something silly with the resistor to try to feed 5V into the HDMI sink and I had incorrectly installed the resistor between 5V and HPD signals on the HDMI/DVI breakout board. Once I strapped 5V from the JohnnyMac header pins to the 5V the AVR then allowed the video signal through to the projector. Still no sound output though unfortunately on the AVR.
I think the S/PDIF channel status might be off. The sample rate field might need to be 0100 instead of 0010 ? Have to find the actual spec for that. Try changing that (and maybe replacing the AVI with an audio infoframe)
Also, further observation on the upstairs TV: It will not let me switch into stereoscopic mode at 640x480, but 854x480 is totally fine and cool. However, any attempt to automatically switch it with an HDMI infoframe have failed.
@Wuerfel_21 said:
No, 0010 is correct. I think I found the source of confusion though, some idiot decided to print the spec LSB-first
LOL, yeah this is some serious dejavu for me. I jumped over the same hurdles. I've been digging through the EDID for my plasma in case that unearthed anything. I should try to grab one from the AVR too. Here's the decode.
I don't think the EDID is very interesting to this. If the video comes through, it really shouldn't have trouble extracting audio packets from it. Support for 48kHz stereo is mandatory.
@Wuerfel_21 said:
Also, further observation on the upstairs TV: It will not let me switch into stereoscopic mode at 640x480, but 854x480 is totally fine and cool. However, any attempt to automatically switch it with an HDMI infoframe have failed.
I wonder if they are being generated correctly if they don't have an effect. What happens if you stop sending the HDMI infoframe, does it still work at all? If there is corruption but the packet is ignored to begin with this problem could be getting masked.
Well if there's no infoframe it will obviously do nothing. I had it set up wrong. Not spending any excess time on that, just something I wondered (I have some texture mapping nonsense on the back burner, when I hook up proper T&L and rasterization to that, might be funny to render 3D...).
Incidentally, can you try changing mov packet_data0,##%1_000_10_00___10_00_1000___0_00_0_00_01 << 8 to mov packet_data0,##%1_000_10_00___10_00_1000___0_10_0_00_01 << 8?
If the colors go funny (YUV mode), that means the AVI Infoframe is actually being received. Not sure if we had that confirmed already.
@Wuerfel_21 said:
No, 0010 is correct. I think I found the source of confusion though, some idiot decided to print the spec LSB-first
That's the way all little-endian documentation should have been done from the start. It would've fixed a lot of bugs if everyone viewed LE bit order as LSB first - matching its byte order.
@evanh said:
That's the way all little-endian documentation should have been done from the start. It would've fixed a lot of bugs if everyone viewed LE bit order as LSB first - matching its byte order.
And assemblers, compilers and debuggers followed suit of course.
@rogloh said:
Hmm, just changed to this line and rebuilt and reloaded - same RGB output colours. Weird. Maybe the data is corrupted or my TV doesn't like it.
Ok, that's a huge lead. YCbCr mode is a mandatory feature, so if it doesn't make a difference the packets aren't being received correctly. (That's why I like using it as a litmus test for packet reception)
I want to say the CRCs are correct, so uhhh maybe some thought is needed about start bits and guard bands and stuff.
If I can capture the raw HDMI port data and decode with my TMDS program it will show the sequence of the symbols per scan line and we can compare that to the spec. Getting too late for trying all that tonight but I'll try to look tomorrow. I just need to figure out how to output to the port at a byte rate slower than sysclk, ideally scale the output down by 1/2 or 1/4 with different NCO values all over the place so I can capture it to PSRAM at up to sysclk MB/sec peak. It might mess up the audio a bit though.
The latest version of the code I have locally after posting it to the thread is attached here too, not sure what state it was left in but I think it was updated from the original.
I think you generally can't slow down the TMDS encoder. Though IDK what it actually does when it runs out its 10 cycles.
I could try capturing the output with my crappy logic analyzer, but that seems like a headache and a half to get going in the right format. I'll gladly leave that to you.
If you wanted to capture on the P2 itself to PSRAM, you could just change the pin registers so that the inputs map to a single nibble (since the differential pairs are redundant):
1 byte every 2 cycles is sufficient for 16 bit PSRAM.
However, I think there's a far simpler method, you can just the debugger to grab the packet data into the terminal. That super messes up the actual output signal timing, but oh well.
Had to fix your program up (on my space-age workstation long is 64 bit...) but it helped me find a packet bug. The infoframe checksum byte was totally wrong. Weird that it worked at all. (Also: I don't think I explicitly noticed before, but it seems the VisionRGB does not handle any HDMI packets, full stop. It's really a DVI capture card after all - it can do YCbCr, but it needs to be set manually)
@Wuerfel_21 said:
Had to fix your program up (on my space-age workstation long is 64 bit...) but it helped me find a packet bug. The infoframe checksum byte was totally wrong. Weird that it worked at all.
Cool. Glad it was of some benefit. One other way would be to underclock a P2 and feed its 8 bit HDMI port to another P2 system to capture it at higher sampling speed like a logic analyzer would, but your terminal approach seems simpler, albeit slow. It's gonna be slow to get the data back out of the P2 anyway unless you go all upper class and get it to write out a large log file to an SD card.
Cute idea about the nibble pin remap, as otherwise each capture frame increases to 10 bytes per total pixel, so 640x480 probably becomes 800x525*10 bytes or something like that and it reduces the needed PSRAM bandwidth to a manageable amount at real time speeds. A PSRAM system can hold several frames which is useful if you wanted to capture for a longer time.
It's not like I need to look at more than a few packets. They all seem to come out just fine. See if the YCbCr mode works for you with the fixed checksum.
@Wuerfel_21 said:
It's not like I need to look at more than a few packets. They all seem to come out just fine.
Did you end up capturing the actual data to solve the issue you found (couldn't exactly tell by your 2nd post if you did), or did you figure it out by examining the logic of the decoder software etc...?
See if the YCbCr mode works for you with the fixed checksum.
Comments
Yeah the run-time environment for testing is not ideal. If the video driver was separate it might be easier to instrument and debug. EDIT: you'd probably need some audio source too.
What/how are you trying to log? The mailbox should really not get in the way. If you make the whole thing run slow, it will just fill up the audio packets with too many samples, but that ought to be fine.
I want to log the 8 bit output pattern on the HDMI port at the 10x pixel rate.
There's a vgatest.spin2 file I use for that, but there's no sound source. I guess I can add the usual sine wave nonsense.
Ah, then just move the mailbox pin somewhere else, needs a few lines of change.
This conversation is very asynchronous and mailbox-like.
Good idea.
Yeah gotta make the most of our time zone overlap. LOL.
If there was a simple test program you had that feeds some audio and a static RGB pattern to your driver, with some free COGs left over I might be able to take it and add my PSRAM driver and then capture some HDMI port bytes for a couple of frames. I'd need at least 2 free COGs, ideally 3 to do this.
See
vgatest.spin2in latest commit (I've put it on both branches). I added a nicer test pattern and a sine wave oscillator to stand in for OPNBcog.Ok cool. Thanks. I'll try take a look in a little while after dinner.
@rogloh I found a typo that may have caused the sync issues, checkout latest commit.
Yes this image works on my projector (direct) and plasma TV like the other branch did. So some bug was certainly fixed with your latest change. Still no audio on either device, and blank video if I try to pass it through the AVR.
I found when I turned up the volume on my plasma TV really loud, I could hear a semi-random periodic ticking/crackling sound ~2Hz as if it was trying to play samples from something arriving to it but not able to and sort of resetting regularly.
Ok so it turns out I was doing something silly with the resistor to try to feed 5V into the HDMI sink and I had incorrectly installed the resistor between 5V and HPD signals on the HDMI/DVI breakout board. Once I strapped 5V from the JohnnyMac header pins to the 5V the AVR then allowed the video signal through to the projector. Still no sound output though unfortunately on the AVR.
Ah, so one mystery is solved.
I think the S/PDIF channel status might be off. The sample rate field might need to be 0100 instead of 0010 ? Have to find the actual spec for that. Try changing that (and maybe replacing the AVI with an audio infoframe)
Also, further observation on the upstairs TV: It will not let me switch into stereoscopic mode at 640x480, but 854x480 is totally fine and cool. However, any attempt to automatically switch it with an HDMI infoframe have failed.
No, 0010 is correct. I think I found the source of confusion though, some idiot decided to print the spec LSB-first
LOL, yeah this is some serious dejavu for me. I jumped over the same hurdles. I've been digging through the EDID for my plasma in case that unearthed anything. I should try to grab one from the AVR too. Here's the decode.
`
❯ ./decode edid3.txt
Extracted contents:
header: 00 ff ff ff ff ff ff 00
serial number: 41 2f bd 00 00 00 00 00 00 11
version: 01 03
basic params: 80 6e 3e 78 2a
chroma info: d7 b3 ae 51 50 94 23 0c 4a 47
established: 21 08 00
standard: 81 80 01 01 01 01 01 01 01 01 01 01 01 01 01 01
descriptor 1: 66 21 50 b0 51 00 1b 30 40 70 36 00 4e 6c 42 00 00 1e
descriptor 2: 01 1d 80 d0 72 1c 16 20 10 2c 25 80 4e 6c 42 00 00 9e
descriptor 3: 00 00 00 fd 00 17 3d 0f 45 0f 00 0a 20 20 20 20 20 20
descriptor 4: 00 00 00 fc 00 50 49 4f 4e 45 45 52 5f 50 44 50 0a 20
extensions: 01
checksum: c7
EDID version: 1.3
Manufacturer: PIO Model bd Serial Number 0
Made in year 2007
Digital display
Maximum image size: 110 cm x 62 cm
Gamma: 2.20
DPMS levels: Off
RGB color display
First detailed timing is preferred timing
Display x,y Chromaticity:
Red: 0.6826, 0.3173
Green: 0.3134, 0.5810
Blue: 0.1386, 0.0498
White: 0.2890, 0.2802
Established timings supported:
640x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 25.175 MHz
800x600@60Hz 4:3 HorFreq: 37900 Hz Clock: 40.000 MHz
1024x768@60Hz 4:3 HorFreq: 48400 Hz Clock: 65.000 MHz
Standard timings supported:
1280x1024@60Hz 5:4 HorFreq: 64000 Hz Clock: 108.000 MHz
Detailed mode: Clock 85.500 MHz, 1102 mm x 620 mm
1360 1424 1536 1792 hborder 0
768 771 777 795 vborder 0
+hsync +vsync
VertFreq: 60 Hz, HorFreq: 47712 Hz
Detailed mode: Clock 74.250 MHz, 1102 mm x 620 mm
1920 2448 2492 2640 hborder 0
540 542 547 562 vborder 0
+hsync +vsync interlaced
VertFreq: 50 Hz, HorFreq: 28125 Hz
Monitor ranges (GTF): 23-61Hz V, 15-69kHz H, max dotclock 150MHz
Monitor name: PIONEER_PDP
Has 1 extension blocks
Checksum: 0xc7 (valid)
CTA extension block
Extension version: 3
41 bytes of CTA data
Video data block
VIC 20 1920x1080i@50Hz 16:9 HorFreq: 28125 Hz Clock: 74.250 MHz
VIC 5 1920x1080i@60Hz 16:9 HorFreq: 33750 Hz Clock: 74.250 MHz
VIC 31 1920x1080@50Hz 16:9 HorFreq: 56250 Hz Clock: 148.500 MHz
VIC 16 1920x1080@60Hz 16:9 HorFreq: 67500 Hz Clock: 148.500 MHz
VIC 18 720x576@50Hz 16:9 HorFreq: 31250 Hz Clock: 27.000 MHz
VIC 3 720x480@60Hz 16:9 HorFreq: 31469 Hz Clock: 27.000 MHz
VIC 19 1280x720@50Hz 16:9 HorFreq: 37500 Hz Clock: 74.250 MHz
VIC 4 1280x720@60Hz 16:9 HorFreq: 45000 Hz Clock: 74.250 MHz
VIC 17 720x576@50Hz 4:3 HorFreq: 31250 Hz Clock: 27.000 MHz
VIC 2 720x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 27.000 MHz
VIC 22 1440x576i@50Hz 16:9 HorFreq: 15625 Hz Clock: 27.000 MHz
VIC 7 1440x480i@60Hz 16:9 HorFreq: 15734 Hz Clock: 27.000 MHz
VIC 21 1440x576i@50Hz 4:3 HorFreq: 15625 Hz Clock: 27.000 MHz
VIC 6 1440x480i@60Hz 4:3 HorFreq: 15734 Hz Clock: 27.000 MHz
VIC 32 1920x1080@24Hz 16:9 HorFreq: 27000 Hz Clock: 74.250 MHz
VIC 1 640x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 25.175 MHz
Audio data block
Linear PCM, max channels 2
Supported sample rates (kHz): 48 44.1 32
Supported sample sizes (bits): 24 20 16
Speaker allocation data block
Speaker map:
FL/FR - Front Left/Right
Vendor-specific data block, OUI 000c03 (HDMI)
Source physical address 1.0.0.0
Supports_AI
DC_36bit
DC_30bit
DC_Y444
Maximum TMDS clock: 225MHz
Video latency: 17
Audio latency: 17
Interlaced video latency: 34
Interlaced audio latency: 34
Extended tag: Video capability data block
YCbCr quantization: No Data (0)
RGB quantization: Selectable (via AVI Q) (1)
PT scan behaviour: Support both over- and underscan (3)
IT scan behaviour: Always Underscanned (2)
CE scan behaviour: Always Overscannned (1)
Underscans PC formats by default
Basic audio support
Supports YCbCr 4:4:4
Supports YCbCr 4:2:2
1 native detailed modes
Detailed mode: Clock 74.250 MHz, 1102 mm x 620 mm
1920 2008 2052 2200 hborder 0
540 542 547 562 vborder 0
+hsync +vsync interlaced
VertFreq: 60 Hz, HorFreq: 33750 Hz
Detailed mode: Clock 27.000 MHz, 1102 mm x 620 mm
720 732 796 864 hborder 0
576 581 586 625 vborder 0
-hsync -vsync
VertFreq: 50 Hz, HorFreq: 31250 Hz
Detailed mode: Clock 27.000 MHz, 1102 mm x 620 mm
720 736 798 858 hborder 0
480 489 495 525 vborder 0
-hsync -vsync
VertFreq: 59 Hz, HorFreq: 31468 Hz
Checksum: 0xc1 (valid)
`
The AVR EDID is more comprehensive as expected. Not sure it gives much of a hint up front as to what is wrong.
`
./edid-decode edid.txt
Extracted contents:
header: 00 ff ff ff ff ff ff 00
serial number: 35 49 16 00 00 00 00 00 00 12
version: 01 03
basic params: 80 a0 5a 78 0e
chroma info: de 50 a3 54 4c 99 26 0f 50 54
established: 20 00 00
standard: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
descriptor 1: 02 3a 80 18 71 38 2d 40 58 2c 45 00 40 84 63 00 00 1e
descriptor 2: 01 1d 80 18 71 1c 16 20 58 2c 25 00 c4 8e 21 00 00 9e
descriptor 3: 00 00 00 fd 00 32 55 0f 5c 10 00 0a 20 20 20 20 20 20
descriptor 4: 00 00 00 fc 00 53 52 35 30 30 33 20 48 44 4d 49 31 0a
extensions: 01
checksum: 6e
EDID version: 1.3
Manufacturer: MJI Model 16 Serial Number 0
Made in year 2008
Digital display
Maximum image size: 160 cm x 90 cm
Gamma: 2.20
RGB color display
Default (sRGB) color space is primary color space
First detailed timing is preferred timing
Display x,y Chromaticity:
Red: 0.6396, 0.3291
Green: 0.2998, 0.5996
Blue: 0.1494, 0.0595
White: 0.3125, 0.3281
Established timings supported:
640x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 25.175 MHz
Standard timings supported:
Detailed mode: Clock 148.500 MHz, 1600 mm x 900 mm
1920 2008 2052 2200 hborder 0
1080 1084 1089 1125 vborder 0
+hsync +vsync
VertFreq: 60 Hz, HorFreq: 67500 Hz
Detailed mode: Clock 74.250 MHz, 708 mm x 398 mm
1920 2008 2052 2200 hborder 0
540 542 547 562 vborder 0
+hsync +vsync interlaced
VertFreq: 60 Hz, HorFreq: 33750 Hz
Monitor ranges (GTF): 50-85Hz V, 15-92kHz H, max dotclock 160MHz
Monitor name: SR5003 HDMI1
Has 1 extension blocks
Checksum: 0x6e (valid)
CTA extension block
Extension version: 3
77 bytes of CTA data
Video data block
VIC 16 1920x1080@60Hz 16:9 (native) HorFreq: 67500 Hz Clock: 148.500 MHz
VIC 31 1920x1080@50Hz 16:9 HorFreq: 56250 Hz Clock: 148.500 MHz
VIC 32 1920x1080@24Hz 16:9 HorFreq: 27000 Hz Clock: 74.250 MHz
VIC 33 1920x1080@25Hz 16:9 HorFreq: 28125 Hz Clock: 74.250 MHz
VIC 34 1920x1080@30Hz 16:9 HorFreq: 33750 Hz Clock: 74.250 MHz
VIC 5 1920x1080i@60Hz 16:9 HorFreq: 33750 Hz Clock: 74.250 MHz
VIC 20 1920x1080i@50Hz 16:9 HorFreq: 28125 Hz Clock: 74.250 MHz
VIC 4 1280x720@60Hz 16:9 HorFreq: 45000 Hz Clock: 74.250 MHz
VIC 19 1280x720@50Hz 16:9 HorFreq: 37500 Hz Clock: 74.250 MHz
VIC 15 1440x480@60Hz 16:9 HorFreq: 31469 Hz Clock: 54.000 MHz
VIC 14 1440x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 54.000 MHz
VIC 30 1440x576@50Hz 16:9 HorFreq: 31250 Hz Clock: 54.000 MHz
VIC 29 1440x576@50Hz 4:3 HorFreq: 31250 Hz Clock: 54.000 MHz
VIC 3 720x480@60Hz 16:9 HorFreq: 31469 Hz Clock: 27.000 MHz
VIC 2 720x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 27.000 MHz
VIC 18 720x576@50Hz 16:9 HorFreq: 31250 Hz Clock: 27.000 MHz
VIC 17 720x576@50Hz 4:3 HorFreq: 31250 Hz Clock: 27.000 MHz
VIC 7 1440x480i@60Hz 16:9 HorFreq: 15734 Hz Clock: 27.000 MHz
VIC 6 1440x480i@60Hz 4:3 HorFreq: 15734 Hz Clock: 27.000 MHz
VIC 22 1440x576i@50Hz 16:9 HorFreq: 15625 Hz Clock: 27.000 MHz
VIC 21 1440x576i@50Hz 4:3 HorFreq: 15625 Hz Clock: 27.000 MHz
VIC 1 640x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 25.175 MHz
VIC 35 2880x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 108.000 MHz
VIC 36 2880x480@60Hz 16:9 HorFreq: 31469 Hz Clock: 108.000 MHz
VIC 10 2880x480i@60Hz 4:3 HorFreq: 15734 Hz Clock: 54.000 MHz
VIC 11 2880x480i@60Hz 16:9 HorFreq: 15734 Hz Clock: 54.000 MHz
VIC 37 2880x576@50Hz 4:3 HorFreq: 31250 Hz Clock: 108.000 MHz
VIC 38 2880x576@50Hz 16:9 HorFreq: 31250 Hz Clock: 108.000 MHz
VIC 25 2880x576i@50Hz 4:3 HorFreq: 15625 Hz Clock: 54.000 MHz
VIC 26 2880x576i@50Hz 16:9 HorFreq: 15625 Hz Clock: 54.000 MHz
Audio data block
Linear PCM, max channels 2
Supported sample rates (kHz): 192 176.4 96 88.2 48 44.1 32
Supported sample sizes (bits): 24 20 16
Linear PCM, max channels 8
Supported sample rates (kHz): 192 176.4 96 88.2 48 44.1 32
Supported sample sizes (bits): 24 20 16
AC-3, max channels 6
Supported sample rates (kHz): 48 44.1 32
Maximum bit rate: 640 kHz
DTS, max channels 6
Supported sample rates (kHz): 48 44.1 32
Maximum bit rate: 1536 kHz
One Bit Audio, max channels 6
Supported sample rates (kHz): 44.1
Dolby Digital+, max channels 8
Supported sample rates (kHz): 48 44.1
DTS-HD, max channels 8
Supported sample rates (kHz): 192 176.4 96 88.2 48 44.1
MAT (MLP), max channels 8
Supported sample rates (kHz): 192 176.4 96 88.2 48 44.1
Speaker allocation data block
Speaker map:
FL/FR - Front Left/Right
LFE - Low Frequency Effects
FC - Front Center
BL/BR - Back Left/Right
RLC/RRC - Rear Left/Right of Center
Extended tag: Colorimetry data block
xvYCC601
xvYCC709
Vendor-specific data block, OUI 000c03 (HDMI)
Source physical address 1.1.0.0
Supports_AI
DC_36bit
DC_30bit
DC_Y444
Maximum TMDS clock: 225MHz
Video latency: 23
Audio latency: 26
Interlaced video latency: 33
Interlaced audio latency: 33
Underscans PC formats by default
Basic audio support
Supports YCbCr 4:4:4
Supports YCbCr 4:2:2
1 native detailed modes
Detailed mode: Clock 74.250 MHz, 708 mm x 398 mm
1920 2448 2492 2640 hborder 0
540 542 547 562 vborder 0
+hsync +vsync interlaced
VertFreq: 50 Hz, HorFreq: 28125 Hz
Detailed mode: Clock 27.000 MHz, 708 mm x 398 mm
720 736 798 858 hborder 0
480 489 495 525 vborder 0
-hsync -vsync
VertFreq: 59 Hz, HorFreq: 31468 Hz
Checksum: 0x29 (valid)
`
I don't think the EDID is very interesting to this. If the video comes through, it really shouldn't have trouble extracting audio packets from it. Support for 48kHz stereo is mandatory.
I wonder if they are being generated correctly if they don't have an effect. What happens if you stop sending the HDMI infoframe, does it still work at all? If there is corruption but the packet is ignored to begin with this problem could be getting masked.
Well if there's no infoframe it will obviously do nothing. I had it set up wrong. Not spending any excess time on that, just something I wondered (I have some texture mapping nonsense on the back burner, when I hook up proper T&L and rasterization to that, might be funny to render 3D...).
Incidentally, can you try changing
mov packet_data0,##%1_000_10_00___10_00_1000___0_00_0_00_01 << 8tomov packet_data0,##%1_000_10_00___10_00_1000___0_10_0_00_01 << 8?If the colors go funny (YUV mode), that means the AVI Infoframe is actually being received. Not sure if we had that confirmed already.
That's the way all little-endian documentation should have been done from the start. It would've fixed a lot of bugs if everyone viewed LE bit order as LSB first - matching its byte order.
Hmm, just changed to this line and rebuilt and reloaded - same RGB output colours. Weird. Maybe the data is corrupted or my TV doesn't like it.
mov packet_data0,##%1_000_10_00___10_00_1000___0_10_0_00_01 << 8And assemblers, compilers and debuggers followed suit of course.
Ok, that's a huge lead. YCbCr mode is a mandatory feature, so if it doesn't make a difference the packets aren't being received correctly. (That's why I like using it as a litmus test for packet reception)
I want to say the CRCs are correct, so uhhh maybe some thought is needed about start bits and guard bands and stuff.
If I can capture the raw HDMI port data and decode with my TMDS program it will show the sequence of the symbols per scan line and we can compare that to the spec. Getting too late for trying all that tonight but I'll try to look tomorrow. I just need to figure out how to output to the port at a byte rate slower than sysclk, ideally scale the output down by 1/2 or 1/4 with different NCO values all over the place so I can capture it to PSRAM at up to sysclk MB/sec peak. It might mess up the audio a bit though.
Here's a link to the thread that discusses it along with the program attached, if you're keen enough and manage to capture the bytes and feed into this program while I'm asleep.
https://forums.parallax.com/discussion/comment/1478793/#Comment_1478793
The latest version of the code I have locally after posting it to the thread is attached here too, not sure what state it was left in but I think it was updated from the original.
I think you generally can't slow down the TMDS encoder. Though IDK what it actually does when it runs out its 10 cycles.
I could try capturing the output with my crappy logic analyzer, but that seems like a headache and a half to get going in the right format. I'll gladly leave that to you.
If you wanted to capture on the P2 itself to PSRAM, you could just change the pin registers so that the inputs map to a single nibble (since the differential pairs are redundant):
pin 0 (clk-) stays as mailbox
pin 1 (clk+) don't care
pin 2 (b-) don't care
pin 3 (b+) don't care
pin 4 (g-) P_MINUS3_A (capure clk+)
pin 5 (g+) P_MINUS2_A (capture b+)
pin 6 (r-) P_MINUS1_A (capture g+)
pin 7 (r+) P_LOCAL_A (capture r+)
1 byte every 2 cycles is sufficient for 16 bit PSRAM.
However, I think there's a far simpler method, you can just the debugger to grab the packet data into the terminal. That super messes up the actual output signal timing, but oh well.
Had to fix your program up (on my space-age workstation
longis 64 bit...) but it helped me find a packet bug. The infoframe checksum byte was totally wrong. Weird that it worked at all. (Also: I don't think I explicitly noticed before, but it seems the VisionRGB does not handle any HDMI packets, full stop. It's really a DVI capture card after all - it can do YCbCr, but it needs to be set manually)Cool. Glad it was of some benefit. One other way would be to underclock a P2 and feed its 8 bit HDMI port to another P2 system to capture it at higher sampling speed like a logic analyzer would, but your terminal approach seems simpler, albeit slow. It's gonna be slow to get the data back out of the P2 anyway unless you go all upper class and get it to write out a large log file to an SD card.
Cute idea about the nibble pin remap, as otherwise each capture frame increases to 10 bytes per total pixel, so 640x480 probably becomes 800x525*10 bytes or something like that and it reduces the needed PSRAM bandwidth to a manageable amount at real time speeds. A PSRAM system can hold several frames which is useful if you wanted to capture for a longer time.
It's not like I need to look at more than a few packets. They all seem to come out just fine. See if the YCbCr mode works for you with the fixed checksum.
Did you end up capturing the actual data to solve the issue you found (couldn't exactly tell by your 2nd post if you did), or did you figure it out by examining the logic of the decoder software etc...?
Yeah will do after breakfast.