@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...?
I added a DEBUG line next to the WRLUT that writes the encoded data. Then i wrote a script to convert that to binary data and fed it into your program.
Looks something like this (I think this is the regen test branch, after the fix):
Ugg, still same RGB colors with your latest build and this one line change to NeoVGA.spin2. Are you sure this is the correct bit pattern for the YUV change?
EDIT: YUV select bit position seems okay but I just read this:
"When the IT content bit is set to 1 and the Graphics type is indicated, downstream processors should pass Pixel Data unfiltered and without analog reconstruction."
You seem to be setting this bit and graphics type is 00 in data byte 5 if that is zeroed. So it may be preventing the conversion into YUV. I'll try to set this IT bit to 0 to see if that helps.
EDIT2: Nope no help. Still same RGB colours being presented.
EDIT3: Also tested on the projector and it didn't switch into YUV mode either.
Actually I just built that with MODE_DVI_VGA , because I was messing with that, but normally I do set it to HDMI. I will update the above in a sec. Done.
I've got Version 7.0.0-alpha-v6.9.7-52-gada40c8f Compiled on: Jul 2 2024 or Version 6.9.8-HEAD-v6.9.8 Compiled on: Aug 7 2024
Though if your machine has 32 bit longs, this might also be one of our favorite platform dependent oopsies.
Maybe I should take another full clean update from your regen branch to make sure it is fully up to date? I've mainly been updating NeoVGA.spin2 and vgatest.spin2 in the last two days since they seem to be the only files you are committing recently. Will do that and then re-diff the listing files of both builds of vgatest.spin2 locally.
No, only difference in the build is this single line which is the YUV change vs fresh tree. Ugh can't format it nicely.
`
❯ diff vgatest.lst ../NeoYume-hdmi-clock-regen-test
2347,2348c2347,2348
< 01a00 00 44 44 FF
I've made progress in the capture to PSRAM code but seem to be having a problem with the IO pins and the streamer. For some reason I can't seem to read back the upper nibble of the HDMI pins with the streamer (with or without readback remapping). Just coded it all up today and its not working correctly if I read the HDMI pins but at one point it seemed to sample pins ok if I chose another uncommitted IO nibble on pins 0..3 which has some incrementing numbers being written to them as a test pattern, so I know the overall capture logic should be working. I also modified your NeoVGA code to ensure it only setup the Repo mode mailbox on the bottom pin of the 8 pin group (DIGITAL_BASEPIN) in case that had any effect, no help.
I'm starting to wonder if you can't read back correctly the input pin states of pins being streamed to in another COG and I'm trying to remember what @cgracey said about this.
Hacked code attached. You might have more luck than me @Wuerfel_21 . It's very close to working IMO. Right now it messes with P0-P3 so disable that spew() routine if you have boards fitted on those pins.
Serial port console controls capture @115200.
Enter starts capture - it automatically stops after 2MB is captured to PSRAM.
Space reads a screenful of nibble data from the capture start buffer and increments read address by 64 samples.
ESC resets read pointer back to 0 in PSRAM
Obviously still needs a file writer to SD or bulk upload of data to serial port.
Comments
I added a DEBUG line next to the WRLUT that writes the encoded data. Then i wrote a script to convert that to binary data and fed it into your program.
Looks something like this (I think this is the regen test branch, after the fix):
Channel status also seems to read OK (very far into the file).
Also, attached my hastily 64 bit fixed version of your program.
Ugg, still same RGB colors with your latest build and this one line change to NeoVGA.spin2. Are you sure this is the correct bit pattern for the YUV change?
' mov packet_data0,##%1_000_10_00___10_00_1000___0_10_0_00_01 << 8'
EDIT: YUV select bit position seems okay but I just read this:
"When the IT content bit is set to 1 and the Graphics type is indicated, downstream processors should pass Pixel Data unfiltered and without analog reconstruction."
You seem to be setting this bit and graphics type is 00 in data byte 5 if that is zeroed. So it may be preventing the conversion into YUV. I'll try to set this IT bit to 0 to see if that helps.
EDIT2: Nope no help. Still same RGB colours being presented.
EDIT3: Also tested on the projector and it didn't switch into YUV mode either.
Can you build vgatest with listing enabled(-l)? Just to make sure we're actually running the same thing.
Ok, do you want the listing file posted somehow?
Which file do you want? I modified the ./build.sh to add -l to each step.
Yea, just attach it
Here were the output files...
Actually I just built that with MODE_DVI_VGA , because I was messing with that, but normally I do set it to HDMI. I will update the above in a sec. Done.
Here's the vgatest listing file too. Sorry did full NeoYume first.
??? Yeah this is what I wanted(?) to see, random 1 bit difference in output.
What the hell is that?
I think that's the branch offset for the callpa being off by one. How does that happen?
Different compiler version? I'm using:
Version 7.0.0-beta-v6.9.7-31-g7643e936 Compiled on: May 18 2024
I've got
Version 7.0.0-alpha-v6.9.7-52-gada40c8f Compiled on: Jul 2 2024
orVersion 6.9.8-HEAD-v6.9.8 Compiled on: Aug 7 2024
Though if your machine has 32 bit longs, this might also be one of our favorite platform dependent oopsies.
No this is a newer 64 bit machine, MacMini M2 Pro
Maybe I should take another full clean update from your regen branch to make sure it is fully up to date? I've mainly been updating NeoVGA.spin2 and vgatest.spin2 in the last two days since they seem to be the only files you are committing recently. Will do that and then re-diff the listing files of both builds of vgatest.spin2 locally.
No, only difference in the build is this single line which is the YUV change vs fresh tree. Ugh can't format it nicely.
`
❯ diff vgatest.lst ../NeoYume-hdmi-clock-regen-test
2347,2348c2347,2348
< 01a00 00 44 44 FF
< 01a04 00 69 07 F6 | mov packet_data0,##%1_000_10_00___10_00_1000___0_00_0_00_01 << 8
`
Update flexspin. Bug was fixed in b08d41bee0581a7b0b2a67eb36e27f746b371b21
Okay, pulled in latest spin2cpp and made flexspin again:
Version 7.0.0-beta-v6.9.7-65-g3914edfd Compiled on: Sep 9 2024
Here's the listing of vgatest.lst with the YUV change back in.
Yes, code now matches.
Ok, this is what the YUV change seems to be showing on the plasma. EDIT: Still no audio though disappointingly.
Yea that's about right for that.
Can you try the plain video-nextgen branch again? That has a lot more of those CALLPAs
Yeah that branch also works in the video test, without audio. Here it is running in RGB mode this time.
Well that's back to square one.
It also works okay in YUV mode on the next-gen branch when I patched that in just now.
Try this (in either branch, but the regen test one has a slightly higher chance of working ig):
Add this just before
call #util_infoframe_chksum
Apparently most of the values need to be zero, anyways.
I've made progress in the capture to PSRAM code but seem to be having a problem with the IO pins and the streamer. For some reason I can't seem to read back the upper nibble of the HDMI pins with the streamer (with or without readback remapping). Just coded it all up today and its not working correctly if I read the HDMI pins but at one point it seemed to sample pins ok if I chose another uncommitted IO nibble on pins 0..3 which has some incrementing numbers being written to them as a test pattern, so I know the overall capture logic should be working. I also modified your NeoVGA code to ensure it only setup the Repo mode mailbox on the bottom pin of the 8 pin group (DIGITAL_BASEPIN) in case that had any effect, no help.
I'm starting to wonder if you can't read back correctly the input pin states of pins being streamed to in another COG and I'm trying to remember what @cgracey said about this.
Hacked code attached. You might have more luck than me @Wuerfel_21 . It's very close to working IMO. Right now it messes with P0-P3 so disable that spew() routine if you have boards fitted on those pins.
Serial port console controls capture @115200.
Enter starts capture - it automatically stops after 2MB is captured to PSRAM.
Space reads a screenful of nibble data from the capture start buffer and increments read address by 64 samples.
ESC resets read pointer back to 0 in PSRAM
Obviously still needs a file writer to SD or bulk upload of data to serial port.
You probably want to use these modes:
(I think P_OE is nonsense in non-smart modes?)
Tried. Didn't help. Something weird is going on, maybe with the streamer or FIFO, can't tell.
Did you run this yet?
Hadn't but just tried it now. No improvement on sound on Plasma.