FPGA VGA Controller for 8-bit computer

[BrianHG]

Ok, no problem.

     I would call it the 'YM2149_PSG_system'.

     Now, just make sure your latest PSG works and upload the new GPU & testbench.  There are a bunch of things I want to clean and need to create the new stereo filter/mixer.  It will take a 2-3 days and I would like to get started tonight.

[nockieboy]

Ah this is annoying.  I've wired-in the YM2149_PSG_system into the GPU's top module and connected it up, but I'm getting no sound at all from the hardware.  I've obviously made a mistake in the connections somewhere, but I've got no time left tonight to hunt it down and I'm mindful that you want to get started tonight, so I've attached the current GPU project.  I'll take a look at this tomorrow and get it working, I just haven't had the time tonight.  I haven't done the testbench for the new module either, again I'll get that done tomorrow hopefully.

[BrianHG]

Try lines 939 -> 942:

Code: [Select]

logic        [  3:0] psg_addr   ;
logic        [  7:0] psg_data_i ;
logic        [  7:0] psg_data_o ;
logic                psg_wr_en  ;
Maybe need to be moved to 673 so that they are available when first used up by the Z80_bridge.
Everything else looks ok.  However, the simulations are for proofing.

It's sad that you haven't begun to use the unified output arrays 'WRITE_PORT_STROBE, WRITE_PORT_DATA' everywhere with a [parameter_address] when wiring modules instead of all these random names.  All those port names on the Z80_bus have gotten absurd.

[BrianHG]

(No sound) Quartus is having trouble with 'real' or floating point parameters.
I'm making a temporary work around...

[nockieboy]

(No sound) Quartus is having trouble with 'real' or floating point parameters.
I'm making a temporary work around...

   Good old Quartus.  I wonder if these issues are fixed in later versions?  I'm using 20.1.1.

It's sad that you haven't begun to use the unified output arrays 'WRITE_PORT_STROBE, WRITE_PORT_DATA' everywhere with a [parameter_address] when wiring modules instead of all these random names.  All those port names on the Z80_bus have gotten absurd.

Yeah, that's just me being belligerent and stubborn.     I'll get around to doing it at some point in the future when I have the time.

In the meantime, here's the latest testbench with integrated YM2149_PSG_system module, all apparently working fine.  Note that I haven't yet added any waveforms for the I2S top-level outputs.

[BrianHG]

Ok, I just finished the Floating point work around.
I have yet to sleep since yesterday.
Update coming in 5 minutes.

The floating point bug is in all Quartus as it just ignore 'real' parameters.  So I had to write a program to render the audio dac volume look-up tables manually from Modelsim.

[BrianHG]

Here you go, this took a good bunch of hours, so please follow the instructions and test...

A) Question, why are you doing this in the Z80 bridge>
Lines 598 to 609:

Code: [Select]

        // PSG writes
        if (WRITE_PORT_STROBE[PSG_LATCH]) psg_addr   <= WRITE_PORT_DATA[PSG_LATCH] ;
        if (WRITE_PORT_STROBE[PSG_WRITE]) psg_data_o <= WRITE_PORT_DATA[PSG_WRITE] ;
        psg_wr_en <= WRITE_PORT_STROBE[PSG_LATCH] | WRITE_PORT_STROBE[PSG_WRITE]   ;

You do know I went through the trouble of latching and holding everything for you...

Why didn't you just do this located right at the top, just after the IO port definitions? :

Code: [Select]

        // PSG writes
        assign  psg_addr   = WRITE_PORT_DATA[PSG_LATCH] ;
        assign  psg_data_o = WRITE_PORT_DATA[PSG_WRITE] ;
        assign  psg_wr_en  = WRITE_PORT_STROBE[PSG_LATCH] | WRITE_PORT_STROBE[PSG_WRITE]   ;
Also, isn't this all wrong?  Shouldn't it be:

Code: [Select]

        // PSG writes
        assign  psg_addr   = WRITE_PORT_DATA[PSG_ADDR][3:0]  ; // Wire out the PSG address, just the bottom 4 bits.
        assign  psg_data_o = WRITE_PORT_DATA[PSG_DATA] ; // Wire out the PSG data, all 8 bits.
        assign  psg_wr_en  = WRITE_PORT_STROBE[PSG_DATA]; // Only perform the write enable when the data is sent and not when the address is sent.
//  IE, set the address, PSG wont do anything, then set the data, the PSG will use the previously sent address and the data strobe will tell it to write that data at the address which was already set prior.
(I changed the port names because what you had is confusing.)

The only thing I can think of is some sort of required reset value.  If so, then you can add this line to the reset:

Code: [Select]

        WRITE_PORT_DATA   <= '{default:0} ;
Now, when a reset comes in, all the write ports will be 0'ed out.  I hope this clears thing up.
I've attached an updated code.  I did not touch the Z80 stuff as you will need to fix that.


Ok, hopefully the sound should work, but it is still the jt49 audio filters which do occasionally clip-invert making a nasty crackle buzz noise when all 3 channels are at full volume (something I saw in Modelsim).  The one I am working on tomorrow should not have this problem.

Everything has changed as I moved to using `include "xxxx.v' instead of Quartuses include files in project.  (Just for the audio right now...)  So, update everything and take a look at the Z80 bridge for the audio stuff above.

[nockieboy]

Here you go, this took a good bunch of hours, so please follow the instructions and test...

Thank you.

A) Question, why are you doing this in the Z80 bridge>
Lines 598 to 609:

Code: [Select]

        // PSG writes
        if (WRITE_PORT_STROBE[PSG_LATCH]) psg_addr   <= WRITE_PORT_DATA[PSG_LATCH] ;
        if (WRITE_PORT_STROBE[PSG_WRITE]) psg_data_o <= WRITE_PORT_DATA[PSG_WRITE] ;
        psg_wr_en <= WRITE_PORT_STROBE[PSG_LATCH] | WRITE_PORT_STROBE[PSG_WRITE]   ;

You do know I went through the trouble of latching and holding everything for you...

Oooohhh...    I'd probably forgotten that, then got into the routine of adding latches for the data and not thinking about why. 

When I get round to it, I'll just remove all these ports from the Z80_Bridge and have the other modules in GPU_DECA_DDR3_top use the correct WRITE_PORT_DATA value and WRITE_PORT_STROBE signal directly.

Also, isn't this all wrong?  Shouldn't it be:

Code: [Select]

        // PSG writes
        assign  psg_addr   = WRITE_PORT_DATA[PSG_ADDR][3:0]  ; // Wire out the PSG address, just the bottom 4 bits.
        assign  psg_data_o = WRITE_PORT_DATA[PSG_DATA] ; // Wire out the PSG data, all 8 bits.
        assign  psg_wr_en  = WRITE_PORT_STROBE[PSG_DATA]; // Only perform the write enable when the data is sent and not when the address is sent.
//  IE, set the address, PSG wont do anything, then set the data, the PSG will use the previously sent address and the data strobe will tell it to write that data at the address which was already set prior.
(I changed the port names because what you had is confusing.)

Ah, the port names.  Yes, they may be confusing but they match what is on the AY-3-891x and YM2149, and therefore make sense to me.  The way those old chips are interfaced, you can write a register address to the LATCH port, then write data to the WRITE port.  But for some strange reason, you read data back from the LATCH port, not the WRITE port, so I can't just rename the WRITE port to the (more sensible) DATA port.  I can't change the functioning of the interface either, as I have some very complex software (to me, anyway) that plays PT3 and MYM music files in CP/M and if I change how the interface works, I'd either have no way of playing those music files or I'd have to mess with the source code.  Admittedly, I'm going to have to do that anyway as the player isn't working at the moment, but I suspect that's to do with some error in the PSG interface - probably the one you've identified already where psg_wr_en was being assigned to either PSG_WRITE OR PSG_LATCH strobes.

Ok, hopefully the sound should work, but it is still the jt49 audio filters which do occasionally clip-invert making a nasty crackle buzz noise when all 3 channels are at full volume (something I saw in Modelsim).  The one I am working on tomorrow should not have this problem.

Everything has changed as I moved to using `include "xxxx.v' instead of Quartuses include files in project.  (Just for the audio right now...)  So, update everything and take a look at the Z80 bridge for the audio stuff above.

We have sound again and it sounds nice and clear!  I just need desperately to get the module player working in CP/M so I can listen to some chiptunes again. 

[nockieboy]

I seem to have gotten MYM module player working.  Still no progress on PT3s, but at least I can hear something other than beeps and boops.



Yeah, okay, so they're still beeps and boops but what do you expect from an 8-bit system?

Sorry about the sound quality, it's literally filmed on my mobile whilst it played on the TV via the HDMI connection, so it's not a perfect representation, but it sounds great to me!

[BrianHG]

For now, that sounds fine, though lack of bass.
The question is how does it sound on real hardware?
Since you do not have a HDMI capture card, we cannot hear if there supposed to be any bass/low frequencies, or, is it the DC filters?

Anyways, tonight I will do my audio mixer / filter module (no floating point 20*log(1/255) or 10^((Volume/20) *(2^DAC_BITS)) calculations to worry about...), so thing should be a bit easier.  I will also see about getting the 'Line Out' working.  If so, make sure you have headphones, then a 3.5mm - 3.5mm line patch cable so it may be possible to sample the stereo audio direct from your PC's line in and you can send us a full quality .mp3.

[nockieboy]

For now, that sounds fine, though lack of bass.
The question is how does it sound on real hardware?

I can't compare unfortunately, certainly not at the moment, as digging out the old sound card requires setting up all the old (version 1) uCOM cards, as the latest ones aren't compatible.  I don't have the time to do that this weekend, and I'll be away for a week from Monday, so it'll be a while before I can even think about it.

Since you do not have a HDMI capture card, we cannot hear if there supposed to be any bass/low frequencies, or, is it the DC filters?

Anyways, tonight I will do my audio mixer / filter module (no floating point 20*log(1/255) or 10^((Volume/20) *(2^DAC_BITS)) calculations to worry about...), so thing should be a bit easier.  I will also see about getting the 'Line Out' working.  If so, make sure you have headphones, then a 3.5mm - 3.5mm line patch cable so it may be possible to sample the stereo audio direct from your PC's line in and you can send us a full quality .mp3.

I certainly have some 3.5-3.5mm patch cables knocking about somewhere, so an MP3 shouldn't be outside the realms of possibility once the DECA's DAC is running sound through the line out.

[BrianHG]

Ok, 1 module left to do.  Here is the specification of our Github Repo:

Code: [Select]

// ********************************************************************************************************************************
// YM2149_PSG_system Programmable Sound Generator based on Jose Tejada's GitHub repository [url]https://github.com/jotego/jt49.[/url]
//
// Enhancements by BrianHG    : [url]https://github.com/BrianHGinc[/url]
//           and Nockieboy    : [url]https://github.com/nockieboy[/url]
// You can also find use here : [url]https://www.eevblog.com/forum/fpga/[/url]
//
//
// ***************************************************
// New included source code:
// ***************************************************
//
// BHG_clock_fp_div.sv      -> Precision floating point clock divider to generate any desired system clock down to the Hz.
// I2S_transmitter.sv       -> I2S digital audio transmitter for all Audio DACs/Codecs and HDMI transmitters.
// BHG_jt49.v               -> An enhanced modified version of the original jt49.v offering higher # of bits for the sound output channels.
// BHG_jt49_exp_tablegen.v  -> A generator the precision volumetric tables.  Generates the BHG_jt49_exp_lut.vh file.
// BHG_jt49_exp_lut.vh      -> The parameter table generated after Sim running the BHG_jt49_exp_tablegen.v.
// BHG_jt49_exp.v           -> A replacement for the original jt49_exp.v using the tables in BHG_jt49_exp_lut.vh.
// BHG_jt49_filter_mixer.sv -> Offers a programmable channel mixing levels (use 2 for custom stereo), DC filter with clamp, and treble control.
//
//
// Enhancements include:
// ----------------------
// Stereo sound with control registers for channel mixing volume and phase.
// Registers for Treble and Bass adjustments.
// Smart DC filtering allowing lower frequency output while managing peaks and switch on/off pops when necessary.
// Improved precision 8 thru 14 bit exponential DAC support.  (10 bit almost exactly replicates the YM2149 normalized output voltage).
// Precision floating point system clock divider offering parameter select-able PSG reference frequencies with accuracy down to the Hz.
// Integrated standard I2S transmitter output with resampling & floating point system clock divider offering DAC Khz settings down to the Hz.
//
// Functional simulation setup for Modelsim, with example YM2149 presets and full outputs with analog waveforms.
//
// *** Simulation also includes a switch to run Jose Tejada's original jt49 project for direct comparison.
//
// ********************************************************************************************************************************
//Only include one of the following:
//
`include "YM2149_PSG_system.sv" // This will simulate the new BrianHG & Nockieboy YM2149_PSG_system.
// or:
//`include "YM2149_PSG_jt49.sv"   // This will simulate the original jt49 YM2149 PSG source code
//                              // from Jose Tejada's GitHub repository [url]https://github.com/jotego/jt49[/url]
//                              // *** Remember, when using, parameter YM2149_DAC_BITS must be set to 8!
//
//                              // Patched files: 'jt49_dly.v', found a few bugs, see lines:
//                              // 29, 30, 31, & 39.
//
//                              // Also found clip-inversion overflow bug in jt49_mave.v & jt49_dcrm2.v, which the
//                              // DC filter seems to sometimes patch.  Though this may be looked at by Jose Tejada's,
//                              // it is no longer in use because of the new 'BHG_jt49_filter_mixer.sv' replacement.

Note that the ADDR input has been changes from 4bit to 8bit.  This way, you can add more YM2149 PSGs if you like, and I have reserved upper addresses to allow controls for our stereo mixer filter.  (LOL, place 10 of them and get 30 channel audio.  Can the Z80 fill all those registers fast enough?)

[nockieboy]

For now, that sounds fine, though lack of bass.
The question is how does it sound on real hardware?
Since you do not have a HDMI capture card, we cannot hear if there supposed to be any bass/low frequencies, or, is it the DC filters?

Yep, definitely lacking a little bass.  Really need to hear it from the DAC on the DECA first, but it certainly seems to be lacking punch.

So, what do I need to do next?  I'll set the github repo up once the PSG work is done, I think.

[BrianHG]

Ok,
     I attached a test which copies the audio to both HDMI and the green line out jack.

     Now, the engineers who made the ArrowDECA wired that jack to the Line out outputs of the audio codec instead of the high powered Headphone out pins.  This means headphone may not sound proper, but, it will have no problem feeding an audio amp or the line-in of you PC's sound card.

     Please test and let me know if it works.

     Not included, I've done a lot of work on the YM2149 module and only have my filters left to do.  If the attached project works, I'll incorporate my first simple test filter.

     As for the work done so far, here are the latest modules I've created and released on their own:

Verilog floating point clock divider:
https://github.com/BrianHGinc/Verilog-Floating-Point-Clock-Divider
https://www.eevblog.com/forum/fpga/verilog-floating-point-clock-divider-release/

And, I2C initializer with RS232 monitor/debugger: (used in the attached code.)
https://github.com/BrianHGinc/BHG_I2C_init_RS232_debugger
https://www.eevblog.com/forum/fpga/bhg_i2c_init_rs232_debugger-an-i2c-initializer-with-integrated-rs232-debugger/

[nockieboy]

I'm getting no video out from the new project above?  Haven't had a look for a patch cable yet, just thought I'd build the project and test that it works as expected in all aspects other than audio, but I'm getting no signal on the TV.

It looks like you've moved the content of I2C_HDMI_Config into GPU_DECA_DDR3_top, but as far as I can see you've got the right HDMI mode selected, so not sure just yet what's going wrong.

[BrianHG]

  You got to be FN kidding me.... 

     I spent all day trying to fix this.  Thankfully, my new I2C initializer with RS232 monitor/debugger had all the tools built in to see what was going on and play with the ADV7513 HDMI transmitter in real-time to see why it sometimes fails.

     The ADV7513 HDMI transmitter needs to be sent and I2C command to power-up the transmitter after a monitor has been disconnected and reconnected.  Thankfully, it sends an 'INTERRUPT'.  But wait, around 50% of the time you freshly power up the IC, the interrupt actually does nothing.  And yes, all the proper I2C commands have been sent to enable it.

     So, how did the original DECA's I2C HDMI initializer work?  They did have the interrupt wire wired in.

   Believe it or not, they inverted the signal, meaning, the powerup I2C sequence is being transmitted non-stop.  So, after disconnecting the monitor, or on a lemon power-up where the interrupt would never trigger to turn on the HDMI output, they just blasted away the 'enable output' command.  And, if an interrupt did come in pulsing for a few milliseconds, during those few milliseconds they would actually stop sending the script, then continue sending away bypassing the 'non' problem in that instance.

     Well, I've attached a patched GPU_DECA_DDR3_top.sv replicating the same thing.  Please let me know if this one works and you get sound out of both the HDMI and Line Out analog jack.

[BrianHG]

Besides the above fix, my new FP logs the ppm error of the output clocks.

Integer divider mode PPM results for the YM2149:

Code: [Select]

#   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
#   XXX   BHG_FP_clk_divider.v settings/results.   XXX
#   XXX   https://github.com/BrianHGinc            XXX
#   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
#   XXX   USE_FLOATING_DIVIDE = 0
#   XXX   Set INPUT_CLK_HZ    = 100000000 Hz.
#   XXX   Set OUTPUT_CLK_HZ   = 1789000 Hz.
#   XXX   --------------------------------------------- (Floats only accurate to 2 decimal places)
#   XXX   True output freq    = 1785714.280000 Hz.
#   XXX   Frequency error     = -5878.150000 ppm.
#   XXX   Periodic jitter     = +/- 0.000000 ns.
#   XXX   ---------------------------------------------
#   XXX   Integer Divider     = 56.
#   XXX   Divider Fraction    = 0/65536.           OutHz = InHz/(ID+(DF/65536))
#   XXX   ~Divider to 6dp.    = 56.000000.
#   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Floating point divider mode PPM error:

Code: [Select]

#   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
#   XXX   BHG_FP_clk_divider.v settings/results.   XXX
#   XXX   https://github.com/BrianHGinc            XXX
#   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
#   XXX   USE_FLOATING_DIVIDE = 1
#   XXX   Set INPUT_CLK_HZ    = 100000000 Hz.
#   XXX   Set OUTPUT_CLK_HZ   = 1789000 Hz.
#   XXX   --------------------------------------------- (Floats only accurate to 2 decimal places)
#   XXX   True output freq    = 1788999.790000 Hz.
#   XXX   Frequency error     = -0.370000 ppm.
#   XXX   Periodic jitter     = +/- 5.000000 ns.
#   XXX   ---------------------------------------------
#   XXX   Integer Divider     = 55.
#   XXX   Divider Fraction    = 58796/65536.           OutHz = InHz/(ID+(DF/65536))
#   XXX   ~Divider to 6dp.    = 55.897156.
#   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
-0.370000 ppm VS -5878.150000 ppm, well, its not as bad as the I2S audio clock in integer mode:

Code: [Select]

#   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
#   XXX   BHG_FP_clk_divider.v settings/results.   XXX
#   XXX   https://github.com/BrianHGinc            XXX
#   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
#   XXX   USE_FLOATING_DIVIDE = 0
#   XXX   Set INPUT_CLK_HZ    = 100000000 Hz.
#   XXX   Set OUTPUT_CLK_HZ   = 3072000 Hz.
#   XXX   --------------------------------------------- (Floats only accurate to 2 decimal places)
#   XXX   True output freq    = 3030303.030000 Hz.
#   XXX   Frequency error     = -128093.090000 ppm.
#   XXX   Periodic jitter     = +/- 0.000000 ns.
#   XXX   ---------------------------------------------
#   XXX   Integer Divider     = 33.
#   XXX   Divider Fraction    = 0/65536.           OutHz = InHz/(ID+(DF/65536))
#   XXX   ~Divider to 6dp.    = 33.000000.
#   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX-128kppm...

[nockieboy]

You got to be FN kidding me.... 

     I spent all day trying to fix this.  Thankfully, my new I2C initializer with RS232 monitor/debugger had all the tools built in to see what was going on and play with the ADV7513 HDMI transmitter in real-time to see why it sometimes fails.

     The ADV7513 HDMI transmitter needs to be sent and I2C command to power-up the transmitter after a monitor has been disconnected and reconnected.  Thankfully, it sends an 'INTERRUPT'.  But wait, around 50% of the time you freshly power up the IC, the interrupt actually does nothing.  And yes, all the proper I2C commands have been sent to enable it.

     So, how did the original DECA's I2C HDMI initializer work?  They did have the interrupt wire wired in.

   Believe it or not, they inverted the signal, meaning, the powerup I2C sequence is being transmitted non-stop.  So, after disconnecting the monitor, or on a lemon power-up where the interrupt would never trigger to turn on the HDMI output, they just blasted away the 'enable output' command.  And, if an interrupt did come in pulsing for a few milliseconds, during those few milliseconds they would actually stop sending the script, then continue sending away bypassing the 'non' problem in that instance.

     Well, I've attached a patched GPU_DECA_DDR3_top.sv replicating the same thing.  Please let me know if this one works and you get sound out of both the HDMI and Line Out analog jack.

Haven't had time to give this patch justice in testing, but I can confirm that the image is back on the TV, but no HDMI sound output.  Can't test line out yet as I'm having trouble finding a cable. 

[BrianHG]

Give these 2 alternate top .sv a try.
You know, you could try connecting a headphone to the line out.

Also, I've been working off of the 'GPU_DECA_DDR3_version_16_pre_BHG_audiofilter.zip' code from above.

[nockieboy]

Give these 2 alternate top .sv a try.
You know, you could try connecting a headphone to the line out.

I'll give them a try as soon as I can.

Also, I've been working off of the 'GPU_DECA_DDR3_version_16_pre_BHG_audiofilter.zip' code from above.

That's probably the issue then.  I've made a few changes since I last uploaded the project, I think.  Here's the latest version (not including your latest changes to duplicate sound out of the DECA's DAC).

[BrianHG]

Give these 2 alternate top .sv a try.
You know, you could try connecting a headphone to the line out.

I'll give them a try as soon as I can.

Also, I've been working off of the 'GPU_DECA_DDR3_version_16_pre_BHG_audiofilter.zip' code from above.

That's probably the issue then.  I've made a few changes since I last uploaded the project, I think.  Here's the latest version (not including your latest changes to duplicate sound out of the DECA's DAC).

Does that version have sound?
You should label your .zip with some info.  I have too many overwrites without knowing which does what.

[BrianHG]

   Copy over the 'YM2149_PSG_system' folder from your latest download to my last upload...

[nockieboy]

Give these 2 alternate top .sv a try.
You know, you could try connecting a headphone to the line out.

I'll give them a try as soon as I can.

Also, I've been working off of the 'GPU_DECA_DDR3_version_16_pre_BHG_audiofilter.zip' code from above.

That's probably the issue then.  I've made a few changes since I last uploaded the project, I think.  Here's the latest version (not including your latest changes to duplicate sound out of the DECA's DAC).

Does that version have sound?
You should label your .zip with some info.  I have too many overwrites without knowing which does what.

Yes, that version has working sound through the HDMI.

[BrianHG]

Ok, re-dooing everything for you 1 last time now...

[BrianHG]

Here you go:

If there is no sound, change this on 1260 of the _top.sv:

Code: [Select]

                                    .rst_in         ( RST_OUT || (HDMI_RESET && !HDMI_TX_INT)),  // Synchronous reset.
It will enable the intended interrupt based reprogramming of the HDMI's I2C registers instead of the circular constant re-programming.