@Wuerfel_21 said:
I just did a dummy WYPIN on startup to get it going
Hooked it up to the next-best 5.1 amp box thing (notably not the upstairs Yamaha, but my basement Pioneer). Yep, sure is playing audio.
Just tried this out on my Logitech THX 5.1 Z-5500 speakers using the coax input (same setup I had working with my own code previously). Works fine, can hear the audio okay. Nice. Is your ultimate plan to output analog plus HDMI sound plus S/PDIF, all while doing pixel replication?
I wanna roll this with all the analog/LCD/whatever modes into a combo driver. So when doing analog video (or plain DVI), S/PDIF would be the only way to get digital audio. The analog audio is the domain of the synthesizer cog. Adding the digital capability is "free" from its POV, just needs to write the sample into the repository after servicing the DACs.
Thid work ought to end up in the console emulators, but maybe I can spin a generic driver. Hard to say what the feature-set (wrt to video modes) there should be though.
By the way I was thinking that I just recently made a board for another application which already works (essentially a Z80 video card interface using P2-Edge). I was wondering if I ripped out the bus translation logic and replaced it with PSRAM in a modified bottom layer, this could be a quite good board for Neo-Yume and HDMI/SPDIF experiments because it already has HDMI, USB, VGA and TRRS audio outputs. This board is relatively easy to solder too with all connectors being through hole parts. It would use the non-PSRAM version of the P2 Edge (e.g RevD) so it could access more than 32MB of PSRAM.
Currently:
P0-P39 - Z80 bus access signals right now, but could be repurposed for PSRAM
P40-47 - HDMI
P48-P52 - VGA
P53 - Ring2 of jack could be used for composite video, or SPDIF, or USB power enable option (seems your driver doesn't need a PWR enable but it's a nice to have)
P54 - Ring1 of TRRS jack for audio/video use
P55 - Tip of TRRS jack for audio/video use
P56 - USB_N
P57 - USB_P (also available with P56 on a 5 pin external IO header with 5V/3.3V/GND for alternative PS/2 or I2C interface use if USB is not fitted).
P62,63 - PropPlug
This board has a parallel Z80 bus interface but that would be changed to use PSRAM. If there's room for 16 chips then it could be 4x16 bit banks with 2 parallel devices feeding each data bit (for higher performance and 128MB total) or possibly even used as 32 bit wide PSRAM if that makes any sense even though we don't have a driver for that bus width at this point and that could complicate things. Another option is have less PSRAM pins and put a double wide P2 breakout header down one side and keep all PSRAM devices on the same 16 bit bus - at the risk of incurring performance penalties.
I put a USB power switch (TPD3S014) on this board which has its enable pin pulled high with a resistor and can also be jumpered to P53 or the switch can be bypassed entirely with a solder jumper if not fitted.
Only limitation right now is that it needs 5V fed via the green plug terminal, there's no regulator on board (or any reverse voltage protection) as power was fed by the Z80 motherboard. The plug terminal was really just for me to use during bringup but could be used for standalone purposes as well. In theory with the newer higher input voltage capable P2-Edge and no 5V logic chips required you could feed in higher than 5V, although using the USB/PS/2 or optional HDMI resistor/link would need 5V if you wanted those. The PSRAM could take 3.3V from the P2-Edge along with powering a 3.3V WII joystick or any keyboards/mice that work at 3.3V. But it's probably best to just stick with 5V to avoid problems.
Gonna think more about this layout and see how easy or not it is to modify.
The risk with this idea is the PSRAM performance that can be attained by going off-module and then to the PSRAM chips might be degraded vs direct connection to PSRAM on P2-EC32MB. IIRC I had decent results with P2-EVAL and my own 64MB PSRAM board, but NeoYume does clock the P2 rather high though.
Update: Actually looking at the PCB layout, it's not ideal for changing in the way as I had originally thought. It would be best to rotate the P2-Edge connector 90 degrees and face the P2 Edge module outwards from the video connectors (pointing it downwards in the picture above). It would need a different pin allocation then too. So it becomes a different layout but just would retain a similar choice of connectors. Not sure if I'll make it or not now.
I think I figured out the case of the awful S/PDIF noises:
OPN2cog has inherent DC bias when idle due to simulating distortion of the original 9-bit YM2612 DAC
the linear interpolation code is bung and adds the sample phase into the left channel twice (????)
due to the signals always being in the $000000-$00FFFF range, the Pioneer box presumably tries to decode it as right-justified 16 bit PCM (a cursed non-standard that allegedly exists)
Now to try and fix it...
Another note: whoever wrote the S/PDIF decoder in sigrok/pulseview is almost as much of an idiot as whoever decided to use slow python scripting for decoding logic traces. All around horrible.
Fixed SPDIF-only version. Also upgraded to cubic interpolation.
I realize there's a slight problem with the S/PDIF + analog video idea: DAC pins can't be put into repository mode. That also prevents usage of BITDAC for the TMDS pins (1K5 drive mode seems to work fine though). For VGA, the VSync pin could be used, so that's good, but for other video types, I guess it will only be available if a pin is sacrificed to that end. For the EVAL A/V board, I guess we can count on just using the same VSync pin in all analog modes, it's not like it's hooked up to anything else. The other option would be to change the system to go through RAM instead, but that seems annoying compared to how clean the repository method is.
@Wuerfel_21 said:
... but that seems annoying compared to how clean the repository method is.
The fact that the smartpins are so equally accessible at speed tells me they have to be physically bunched together in the middle of the die area.
On the flipside, the physical blocks of hubRAM are ringed around the outer areas. As is CogRAM/LutRAM. This wasn't something that could be any different. They are very large blocks of SRAM. Which probably explains the high power draw for hubRAM operations. The crosspoint "eggbeater" switch has to span most of the die area. Such long travel is a capacitive burden when at frequency.
@Wuerfel_21 said:
Fixed SPDIF-only version. Also upgraded to cubic interpolation.
I realize there's a slight problem with the S/PDIF + analog video idea: DAC pins can't be put into repository mode. That also prevents usage of BITDAC for the TMDS pins (1K5 drive mode seems to work fine though). For VGA, the VSync pin could be used, so that's good, but for other video types, I guess it will only be available if a pin is sacrificed to that end. For the EVAL A/V board, I guess we can count on just using the same VSync pin in all analog modes, it's not like it's hooked up to anything else. The other option would be to change the system to go through RAM instead, but that seems annoying compared to how clean the repository method is.
Repo mode is handy & fast certainly. A pity we can't share the pins with other DAC purposes but any sharing was always just a bonus anyway. Downside with single repo mode is that its 32 bit size locks you into just passing 16 bit (plus stereo) samples only unless you were to signal L/R with other bits and read & write 20 or 24 bit samples twice which complicates the transfer. I know you only intended to support 16 bits for now anyway, but having the possibility of multiple repository pins could have enabled multi-channel data passing with a consistent framework. If we ever want multi-channel audio and we don't all have the repo pins available we'd need HUB RAM sample variant using block reads or something, though maybe that will be a different driver down the track. Single repo mode could potentially be used to just signal sample readiness and a block of HUB RAM locations could then be read for data although using a COGATN could also suffice for achieving that too, assuming it is free to use in your COG.
Something else that comes to mind that I don't think I've seen anyone do before: Simultaneously driving DVI and VGA video. Should be doable, since the VGA Hsync bit is bit 0, which the TMDS encoder ignores.
This of course would become mildly silly when doing the extended blanking kinda modes, but I think it's basically free to do, so...
Hmm, doing simultaneous S/PDIF and HDMI audio may be a bit of a crapshoot. They both need quite a lot of time and memory. Plain DVI + S/PDIF will certainly work though.
Maybe if I implement that idea where the second two subpackets are hardcoded to zero there'll be room for both though. A lot of time is spent just encoding the bits into TERC codes and this can be cheated if only the two LSBs actually have data.
@Wuerfel_21 said:
Something else that comes to mind that I don't think I've seen anyone do before: Simultaneously driving DVI and VGA video. Should be doable, since the VGA Hsync bit is bit 0, which the TMDS encoder ignores.
From memory I think this is not possible without a (simple) design change and silicon respin.
@Wuerfel_21 said:
Something else that comes to mind that I don't think I've seen anyone do before: Simultaneously driving DVI and VGA video. Should be doable, since the VGA Hsync bit is bit 0, which the TMDS encoder ignores.
From memory I think this is not possible without a (simple) design change and silicon respin.
Why would that be? I haven't tried it yet, but allegedly the TMDS encoder only replaces the pin outputs, so it should leave the entire DAC section alone.
@Wuerfel_21 said:
Something else that comes to mind that I don't think I've seen anyone do before: Simultaneously driving DVI and VGA video. Should be doable, since the VGA Hsync bit is bit 0, which the TMDS encoder ignores.
From memory I think this is not possible without a (simple) design change and silicon respin.
Why would that be? I haven't tried it yet, but allegedly the TMDS encoder only replaces the pin outputs, so it should leave the entire DAC section alone.
It's years ago now and I've forgotten the details.
@Wuerfel_21 said:
Hmm, doing simultaneous S/PDIF and HDMI audio may be a bit of a crapshoot. They both need quite a lot of time and memory. Plain DVI + S/PDIF will certainly work though.
Maybe if I implement that idea where the second two subpackets are hardcoded to zero there'll be room for both though. A lot of time is spent just encoding the bits into TERC codes and this can be cheated if only the two LSBs actually have data.
My initial method was going to be to encode it all in the blanking interval when you have more time, however that incurs a lot of latency and messes up the whole repo mode thing too as it required a fifo from the source.
@Wuerfel_21 said:
Something else that comes to mind that I don't think I've seen anyone do before: Simultaneously driving DVI and VGA video. Should be doable, since the VGA Hsync bit is bit 0, which the TMDS encoder ignores.
This of course would become mildly silly when doing the extended blanking kinda modes, but I think it's basically free to do, so...
When I first started my video driver this was my intent as well but it worked out simpler to just keep them independent and selectable at startup and allowed custom sync timing for each type of output to be developed and patched into the COG as it starts. I had a feeling there was some issue limiting this too, but can't recall what offhand. It would be good if you had a real DVI-I plug on your board and wanted analog and digital outputs present on the connector, like older PC's used to do before switching over to DVI-D and then HDMI.
@Wuerfel_21 said:
Something else that comes to mind that I don't think I've seen anyone do before: Simultaneously driving DVI and VGA video. Should be doable, since the VGA Hsync bit is bit 0, which the TMDS encoder ignores.
From memory I think this is not possible without a (simple) design change and silicon respin.
Why would that be? I haven't tried it yet, but allegedly the TMDS encoder only replaces the pin outputs, so it should leave the entire DAC section alone.
It's years ago now and I've forgotten the details.
Ah yes, that. I think the streamer command can disable some of the DAC channels though, so the unused ones return to their SETDACS value. Not sure if that was tried.
Good hunting TonyB_. I had a vague feeling there was some issue that limited me doing simultaneous output but couldn't recall it precisely. You must have remembered something about it too as you responded back then with suggestions as well, so did Wuerfel_21 and Chip. It's hard to keep little details like this front of mind for many years (over 4 years now, what's happened to the time?).
I think I decided the fix wasn't going to be worth it in my own driver and wanted to move on to other things, but there may be some scope to try various solutions if they don't consume too many resources or you can figure out the precise timing required. Mixing that plus extra HDMI work might make it harder though, not sure.
@Wuerfel_21 said:
Ah yes, that. I think the streamer command can disable some of the DAC channels though, so the unused ones return to their SETDACS value. Not sure if that was tried.
A preliminary SETDACS then disabling RGB DACs during blanking seems to be the solution to simultaneous VGA and DVI outputs. Have you tested this yet? I don't have the DVI board for the Eval.
Ok, dual DVI + VGA, just works, here's @cgracey 's 640x480 Spiral demo hacked to do that. It really just works. Annoyingly, I don't think that's the case for other analog formats.
(and of course, if you start doing the weird modes with massive blanking, you better have a monitor with proper geometry controls.)
Yeah, when I first thought about that, I feely quickly realised I was using a lot of reduced blanking for my DVI modes. So that immediately put me off thinking more about enabling both channels.
@Wuerfel_21 said:
Ok, dual DVI + VGA, just works, here's @cgracey 's 640x480 Spiral demo hacked to do that. It really just works. Annoyingly, I don't think that's the case for other analog formats.
(and of course, if you start doing the weird modes with massive blanking, you better have a monitor with proper geometry controls.)
Are the hacks just adding setdacs #0 and changing m_bs..m_vi?
@Wuerfel_21 said:
Ok, dual DVI + VGA, just works, here's @cgracey 's 640x480 Spiral demo hacked to do that. It really just works. Annoyingly, I don't think that's the case for other analog formats.
(and of course, if you start doing the weird modes with massive blanking, you better have a monitor with proper geometry controls.)
Are the hacks just adding setdacs #0 and changing m_bs..m_vi?
Possibly don't even need the SETDACS, might just default to zero.
Actually needed:
- change SETCMOD to enable VGA mode (and TMDS encoding at the same time)
- do the usual VGA DAC and colorspace setup
- change the streamer commands to have the correct DAC channel modes (X_DACS_3_2_1_0 for visible commands, X_DACS_X_X_X_0 for blanking/sync)
- set bit 0 in control characters that signal HSync
- add instructions to toggle VSync pin
For more detail, diff with the original version that comes with PNut.
This is good work @Wuerfel_21 . Seems like the real key might be using X_DACS_X_X_X_0 during sync. I may not have tried that myself.
Maybe there is scope to add this capability to my driver if I can configure it appropriately and it doesn't take extra instructions at run time. It sort of needs multiple pins defined now, with two different pin bases and their different flags. But there may be some potential down the line for this. I do already support both SVIDEO + composite as dual outputs in my code so it's not without a precedent. It does of course lock the VGA and DVI/HDMI to the same scan rate, so VGA resolutions would remain limited in this case.
@Wuerfel_21 said:
Ok, dual DVI + VGA, just works, here's @cgracey 's 640x480 Spiral demo hacked to do that. It really just works. Annoyingly, I don't think that's the case for other analog formats.
(and of course, if you start doing the weird modes with massive blanking, you better have a monitor with proper geometry controls.)
Thanks for testing this and congrats. 720 x 480 might work on a CRT VGA monitor as line frequency the same; 858 pixels @ 27 MHz vs 800 @ 25.175 MHz for 640 x 480.
Comments
In hindsight, a hack of the pin drive to mute the dummy initial character would've solved that annoyance.
Just tried this out on my Logitech THX 5.1 Z-5500 speakers using the coax input (same setup I had working with my own code previously). Works fine, can hear the audio okay. Nice. Is your ultimate plan to output analog plus HDMI sound plus S/PDIF, all while doing pixel replication?
That's the idea. Will be a squeeze though.
I wanna roll this with all the analog/LCD/whatever modes into a combo driver. So when doing analog video (or plain DVI), S/PDIF would be the only way to get digital audio. The analog audio is the domain of the synthesizer cog. Adding the digital capability is "free" from its POV, just needs to write the sample into the repository after servicing the DACs.
Thid work ought to end up in the console emulators, but maybe I can spin a generic driver. Hard to say what the feature-set (wrt to video modes) there should be though.
By the way I was thinking that I just recently made a board for another application which already works (essentially a Z80 video card interface using P2-Edge). I was wondering if I ripped out the bus translation logic and replaced it with PSRAM in a modified bottom layer, this could be a quite good board for Neo-Yume and HDMI/SPDIF experiments because it already has HDMI, USB, VGA and TRRS audio outputs. This board is relatively easy to solder too with all connectors being through hole parts. It would use the non-PSRAM version of the P2 Edge (e.g RevD) so it could access more than 32MB of PSRAM.
Currently:
P0-P39 - Z80 bus access signals right now, but could be repurposed for PSRAM
P40-47 - HDMI
P48-P52 - VGA
P53 - Ring2 of jack could be used for composite video, or SPDIF, or USB power enable option (seems your driver doesn't need a PWR enable but it's a nice to have)
P54 - Ring1 of TRRS jack for audio/video use
P55 - Tip of TRRS jack for audio/video use
P56 - USB_N
P57 - USB_P (also available with P56 on a 5 pin external IO header with 5V/3.3V/GND for alternative PS/2 or I2C interface use if USB is not fitted).
P62,63 - PropPlug
This board has a parallel Z80 bus interface but that would be changed to use PSRAM. If there's room for 16 chips then it could be 4x16 bit banks with 2 parallel devices feeding each data bit (for higher performance and 128MB total) or possibly even used as 32 bit wide PSRAM if that makes any sense even though we don't have a driver for that bus width at this point and that could complicate things. Another option is have less PSRAM pins and put a double wide P2 breakout header down one side and keep all PSRAM devices on the same 16 bit bus - at the risk of incurring performance penalties.
I put a USB power switch (TPD3S014) on this board which has its enable pin pulled high with a resistor and can also be jumpered to P53 or the switch can be bypassed entirely with a solder jumper if not fitted.
Only limitation right now is that it needs 5V fed via the green plug terminal, there's no regulator on board (or any reverse voltage protection) as power was fed by the Z80 motherboard. The plug terminal was really just for me to use during bringup but could be used for standalone purposes as well. In theory with the newer higher input voltage capable P2-Edge and no 5V logic chips required you could feed in higher than 5V, although using the USB/PS/2 or optional HDMI resistor/link would need 5V if you wanted those. The PSRAM could take 3.3V from the P2-Edge along with powering a 3.3V WII joystick or any keyboards/mice that work at 3.3V. But it's probably best to just stick with 5V to avoid problems.
Gonna think more about this layout and see how easy or not it is to modify.
The risk with this idea is the PSRAM performance that can be attained by going off-module and then to the PSRAM chips might be degraded vs direct connection to PSRAM on P2-EC32MB. IIRC I had decent results with P2-EVAL and my own 64MB PSRAM board, but NeoYume does clock the P2 rather high though.
Update: Actually looking at the PCB layout, it's not ideal for changing in the way as I had originally thought. It would be best to rotate the P2-Edge connector 90 degrees and face the P2 Edge module outwards from the video connectors (pointing it downwards in the picture above). It would need a different pin allocation then too. So it becomes a different layout but just would retain a similar choice of connectors. Not sure if I'll make it or not now.
I think I figured out the case of the awful S/PDIF noises:
Now to try and fix it...
Another note: whoever wrote the S/PDIF decoder in sigrok/pulseview is almost as much of an idiot as whoever decided to use slow python scripting for decoding logic traces. All around horrible.
Fixed SPDIF-only version. Also upgraded to cubic interpolation.
I realize there's a slight problem with the S/PDIF + analog video idea: DAC pins can't be put into repository mode. That also prevents usage of BITDAC for the TMDS pins (1K5 drive mode seems to work fine though). For VGA, the VSync pin could be used, so that's good, but for other video types, I guess it will only be available if a pin is sacrificed to that end. For the EVAL A/V board, I guess we can count on just using the same VSync pin in all analog modes, it's not like it's hooked up to anything else. The other option would be to change the system to go through RAM instead, but that seems annoying compared to how clean the repository method is.
The fact that the smartpins are so equally accessible at speed tells me they have to be physically bunched together in the middle of the die area.
On the flipside, the physical blocks of hubRAM are ringed around the outer areas. As is CogRAM/LutRAM. This wasn't something that could be any different. They are very large blocks of SRAM. Which probably explains the high power draw for hubRAM operations. The crosspoint "eggbeater" switch has to span most of the die area. Such long travel is a capacitive burden when at frequency.
Repo mode is handy & fast certainly. A pity we can't share the pins with other DAC purposes but any sharing was always just a bonus anyway. Downside with single repo mode is that its 32 bit size locks you into just passing 16 bit (plus stereo) samples only unless you were to signal L/R with other bits and read & write 20 or 24 bit samples twice which complicates the transfer. I know you only intended to support 16 bits for now anyway, but having the possibility of multiple repository pins could have enabled multi-channel data passing with a consistent framework. If we ever want multi-channel audio and we don't all have the repo pins available we'd need HUB RAM sample variant using block reads or something, though maybe that will be a different driver down the track. Single repo mode could potentially be used to just signal sample readiness and a block of HUB RAM locations could then be read for data although using a COGATN could also suffice for achieving that too, assuming it is free to use in your COG.
Something else that comes to mind that I don't think I've seen anyone do before: Simultaneously driving DVI and VGA video. Should be doable, since the VGA Hsync bit is bit 0, which the TMDS encoder ignores.
This of course would become mildly silly when doing the extended blanking kinda modes, but I think it's basically free to do, so...
Hmm, doing simultaneous S/PDIF and HDMI audio may be a bit of a crapshoot. They both need quite a lot of time and memory. Plain DVI + S/PDIF will certainly work though.
Maybe if I implement that idea where the second two subpackets are hardcoded to zero there'll be room for both though. A lot of time is spent just encoding the bits into TERC codes and this can be cheated if only the two LSBs actually have data.
I've found I can display 1080p at 10Hz with DLP projector. Might be interesting to see if can do that with audio....
@Wuerfel_21 Figuring out HDMI audio with P2 has inspired me to create an HDMI variant of my Simple (TM) board...
This is a real breakthough!
From memory I think this is not possible without a (simple) design change and silicon respin.
Why would that be? I haven't tried it yet, but allegedly the TMDS encoder only replaces the pin outputs, so it should leave the entire DAC section alone.
It's years ago now and I've forgotten the details.
My initial method was going to be to encode it all in the blanking interval when you have more time, however that incurs a lot of latency and messes up the whole repo mode thing too as it required a fifo from the source.
When I first started my video driver this was my intent as well but it worked out simpler to just keep them independent and selectable at startup and allowed custom sync timing for each type of output to be developed and patched into the COG as it starts. I had a feeling there was some issue limiting this too, but can't recall what offhand. It would be good if you had a real DVI-I plug on your board and wanted analog and digital outputs present on the connector, like older PC's used to do before switching over to DVI-D and then HDMI.
I have used bitdac mode with digital video out.
Read rest of thread. Point is that BITDAC and repository mode don't mix
After hours and hours of searching, I've found the issue in the All PASM2 gurus - help optimizing a text driver over DVI? thread from post 300 onwards:
https://forums.parallax.com/discussion/comment/1480497/#Comment_1480497
Ah yes, that. I think the streamer command can disable some of the DAC channels though, so the unused ones return to their SETDACS value. Not sure if that was tried.
Good hunting TonyB_. I had a vague feeling there was some issue that limited me doing simultaneous output but couldn't recall it precisely. You must have remembered something about it too as you responded back then with suggestions as well, so did Wuerfel_21 and Chip. It's hard to keep little details like this front of mind for many years (over 4 years now, what's happened to the time?).
I think I decided the fix wasn't going to be worth it in my own driver and wanted to move on to other things, but there may be some scope to try various solutions if they don't consume too many resources or you can figure out the precise timing required. Mixing that plus extra HDMI work might make it harder though, not sure.
A preliminary SETDACS then disabling RGB DACs during blanking seems to be the solution to simultaneous VGA and DVI outputs. Have you tested this yet? I don't have the DVI board for the Eval.
Not yet.
Ok, dual DVI + VGA, just works, here's @cgracey 's 640x480 Spiral demo hacked to do that. It really just works. Annoyingly, I don't think that's the case for other analog formats.
(and of course, if you start doing the weird modes with massive blanking, you better have a monitor with proper geometry controls.)
Yeah, when I first thought about that, I feely quickly realised I was using a lot of reduced blanking for my DVI modes. So that immediately put me off thinking more about enabling both channels.
Are the hacks just adding
setdacs #0and changingm_bs..m_vi?Possibly don't even need the SETDACS, might just default to zero.
Actually needed:
- change SETCMOD to enable VGA mode (and TMDS encoding at the same time)
- do the usual VGA DAC and colorspace setup
- change the streamer commands to have the correct DAC channel modes (X_DACS_3_2_1_0 for visible commands, X_DACS_X_X_X_0 for blanking/sync)
- set bit 0 in control characters that signal HSync
- add instructions to toggle VSync pin
For more detail, diff with the original version that comes with PNut.
This is good work @Wuerfel_21 . Seems like the real key might be using X_DACS_X_X_X_0 during sync. I may not have tried that myself.
Maybe there is scope to add this capability to my driver if I can configure it appropriately and it doesn't take extra instructions at run time. It sort of needs multiple pins defined now, with two different pin bases and their different flags. But there may be some potential down the line for this. I do already support both SVIDEO + composite as dual outputs in my code so it's not without a precedent. It does of course lock the VGA and DVI/HDMI to the same scan rate, so VGA resolutions would remain limited in this case.
Thanks for testing this and congrats. 720 x 480 might work on a CRT VGA monitor as line frequency the same; 858 pixels @ 27 MHz vs 800 @ 25.175 MHz for 640 x 480.