True "HDMI" with data packets...
All of the ususal (?) "HDMI" drivers actually just generate DVI-spec pure video. It'd be nice to figure out how to insert audio packets, but for now I'm just trying to generate an AVInfoFrame packet to set the monitor into YCbCr mode, just because that's easier: It only needs one packet that always stays the same and the result should be immediately obvious when it starts working.
But problematically, it seems that I only have junky HDMI devices. One is extremely flakey and now doesn't want to do with tests that worked an hour ago and the other I suspect may actually just be a "dumb" DVI device (looks like the video guard band is intruding into the picture on the left edge...). Might have to try some more with the upstairs TV tomorrow.
Anyways, after futzing around with packet encoding and the poorly described error correction code (it's just CRC...) I think I'm doing at least something right. See also: https://web.archive.org/web/20190520020602/http://hamsterworks.co.nz/mediawiki/index.php/Minimal_HDMI
I'm creating this thread to maybe get some ideas tossing, but you may also try the attached code and see what it does for you. The intent is to display the picture with wrong colors (RGB re-interpreted as YCbCr), so that's what it should do. If the colors are normal, it's not parsing the Info Frame.
Comments
I was able to get some HDMI audio working a once while back with a P1V solution but there was still a bug and I had mixed results - only one cheapo LCD monitor tested produced sound as I recall and I needed to fix the bitstream output somewhere as my consumer A/V devices were being far stricter than the the budget monitor in what they would tolerate. When I counted cycles for core parts I know a P2 COG can certainly do it with the resources available, but don't really want to go there mainly due to HDMI licensing issues which is a shame really. It would be great if Parallax could obtain an HDMI license somehow and we could then get audio and other HDMI features on the P2.
The interesting part is wether I can manage to generate the audio packets (including resampling to a non-whacky rate when required) while simultaneously doing pixel repeat (for 320-wide lowres modes). In general that takes 6 cycles every 20 cycles, though with the streamer buffer you can probably fudge it a bit back and forth.
As far as licensing goes, the license sharks better come to my door and ask for it. Then I pull their human masks off or something and then they die immediately because they are sharks and need water to breathe. Sounds fake but is more real then trying to claim a forever license over particular de-facto universal transmission formats.
Am so very tempted to send you my P2 test code as I'm sure it would be extremely useful to you right now @Wuerfel_21 but don't think it would be a good idea. I can send you this github project link though which is what I learned from. A real treasure trove.
https://github.com/charcole/NeoGeoHDMI/tree/master
ps. in the issues list there you can see some of my comments/questions to Charlie the original creator when I was doing the FPGA stuff which mentioned some problems I encountered.
Would be extremely cool if we had DVI with Audio (just don't call it HDMI).
I've tried the test1 code on two TVs:
1) a little Phillips TV, shows nothing and mostly says no Signal.
2) a Hitachi TV. Shows Reimu but in normal colors (I think - how do I know? She has red clothes and sits on a black chair).
This TV says the picture is 642 x 471 pixels @ 60 Hz.
Andy
Also tried @Wuerfel_21 's test code on my Pioneer plasma over HDMI. No image synced at all. I was driving via a long 10m cable from another room, so to validate it does work from a P2, I ran my own DVI driver code over the same cable and got a 640x480 picture fine. But in terms of HDMI compliance I believe my HDTV is very strict so if something is wrong with the signal then it gets ignored completely.
Roger.
It can be achieved on a P2.
Yea, I think that's the trick. Not sure what they can really get you on if you avoid the trademarks (same as SD cards etc)
Not sure where it's getting 471 from, but 642 sounds like it's eating the guard band, too. Maybe the preamble needs to be exactly 8px? Idk, will need to go upstairs to the proper TV and fool around.
Btw, YUV mode should be totally obvious when it engages, something like this (maybe not exactly, I think the channels would be remapped differently)
Seems like I used 8 pixels in my own code.
And immediately I realize I had made a typo in the data guard character and of course everything starts working, even on the crappy little screen.
Yep, got an image now. Green background, red/pink clothing colours. Well done.
Yes, works now also here on both TVs
Okay, I think audio works. At least on the one proper TV that I can try it on. "soundtest.spin2" should give you a nice sine wave (and normal-colored image). (DO NOT COMPILE WITH DEBUG IT WILL BREAK THE TIMING)
(I like that the P2 can just pull up sine waves using CORDIC instructions)
I also included a modified version of the YUV test because the TV didn't like where the VSYNC edges were happening (I think????), so I think this is more compatible. The other files also have that change. There's also a "reclocktest" that sends just the audio clock packet. It only exists to dump the packet out over debug so I could paste it in the other file.
Working on small Lenco screen.
But: The sine was low frequency, so did not passthrough the small speakers.
With headset, I get it.
So perhaps for testing generate a 1Khz
Nice work !
That probably is a good idea, here's a version with a 1 kHz tone.
Yes, loud and clear now on small speakers !
This work on all my HDMI monitors, right colors and sound
Keep going
Well, the next step is figuring out how to fit it into the framework of how P2 audio normally works, which is a cog producing samples at some interval. I forget, can I set a pin that's being used as an output into P_REPOSITORY mode? Could use that as a mailbox for samples, the video cog just needs to check it somewhat frequently. The other thing is that the audio needs to be a normal rate (32k, 44.1k or 48k), so I'll have to figure out a good-enough polyphase resampling algorithm (the yamaha FM emulator cogs use widely off-spec rates around 55kHz). Wonder if 4-point sinc is sufficient?
Though if there's time for that, you can probably also generate simple audio directly in the video cog.
I also am not yet taking advantage of a pretty big optimization: When using normal audio rates (32kHz to 48kHz) and VGA/EDTV Hsync rates (>= 31kHz), there are at most 2 samples in a scanline, which means that the second two subpackets are never used and can be hardcoded to zero, which could speed up packet encoding quite a lot.
This looks awesome! Having sound over HDMI would be very nice!
Same problem I encountered with my Pioneer plasma with my own code. Audio didn't work for me. It's very picky. This TV does support LPCM 32,44.1,48 kHz rates though according to the E-EDID report.
I'll need to look into your code but are you computing the proper channel status stuff as is in S/PDIF framing? I couldn't see it there at first glance. I think that may be required.
Yes this needs to be sorted. Would be very neat if you could put a pin into REPO mode and it'd still honour the streamer and bitDAC settings as an output...that needs to be tested. If so, you'd have up to 8 HDMI pins that could potentially act as repos for separate multichannel sound samples which would be very cool indeed, assuming there is enough processing time to encode them all. At this point however stereo is probably hard enough, and good enough.
I have the status word stuff, but not a lot of bits set in that:
Other thing I'm not doing is sending an audio infoframe. Apparently spec requires sending it.
Spent the rest of the evening writing up a utility to easily generate canned packets like that. Can probably add it in tomorrow. Though that's 3 packets now, Audio clock, AVI Info and audio info. That's 384 bytes when canned.
Yeah I sent these three packets. You can alternate two of them in a pair of frames but the timing one should go out much more frequently.
That github link I provided above used this as channel status for 32kHz LPCM. I was never able to modify it successfully for 44.1 or 48kHz even in the FPGA variant so I was sure I was doing something wrong, even though I couldn't pinpoint it.
localparam [191:0] channelStatus = 192'hc203004004; // 32KHz 16-bit LPCM audio
In my P2 version which never had working audio on my Pioneer TV but had some success on a cheapo monitor, the long term plan to solve this was to capture the TMDS differences between my (working) FPGA version @32kHz and the P2 version to narrow down what bit was wrong, but it was a lot of work to do and I sort of moved on to other things after that. As I recall I did make a tool that could capture the streamed TMDS code output directly from the P2 pins though back into HUB RAM using a separate COG which I could export for analysis later. I'll have to look for that.
Here's the decoder I wrote. I think I just had it analyze the captured 8 bit bytes at the HDMI pins on the P2 but can't recall everything it did as it was a while ago. You might be able to make use of it perhaps. YMMV.
I'll see if I can find the other PASM part that streamed the data back from the pins (might be lost, not sure), but that's probably something simple you'd be able to add to your own code if it's just a byte logger.
One thing I see is that the FPGA code you linked sends the clock regeneration packet more frequently. That might be it, allegedly it should be sent once per N period. Idk, you'd have to test that, it all just works for me.
Here's the capture/logging component which firstly spawned my HDMI cog plus the snippet from this HDMI cog that syncs to it so I can capture a line buffer for a given scanline for later analysis. This was written in the early days before tools had evolved and uses hard code addresses etc. Hopefully it still compiles, but you get the gist.
ps. by the way my code didn't use canned packets, it dynamically encoded them.
Yeah I found this comment in my own code...
If you're doing all that and none of it makes it work, the solution is probably somewhere else. Or your TV might just suck.
TV most certainly doesn't suck. Kicks booty which is why I'm still using it. However I think it must be following the standard to the letter and is probably HDMI 1.0 only or something too. Normal A/V gear works fine with it.
Update: just checked, it's actually HDMI1.3 and HDCP1.1. So old yeah, but not 1.0 old.
Well, if you ever figure it out, I can add the fix, but I'd rather focus on getting something going first. If the other guy is to be believed, it works more often than it doesn't as-is.
Just tested the examples on a cheap FireTV (that I despise) and it works.
Also works with my main 65" OLED TV and also a DLP projector