FPGA VGA Controller for 8-bit computer

[BrianHG]

Code: [Select]

           sample_pulse       <= ( I2S_counter == 0 )     ; // Pulse the output reference sample clock.

Just a quick question about the quoted line of code above.  Would the following also be a valid method of testing for a zero value?

Code: [Select]

sample_pulse <= ( !I2S_counter ) ;
And if so, which would be best and why?

Hmm, !I2S_counter has multiple bits.  I guess what you wrote is acceptable, but what if you want to change it to (I2S_counter == 63) to give you a pulse ahead of time by 1 clock?  Or 2, or give you a pulse after the sample period giving you a bunch of time to fetch the data and get it ready for the next sample.

I guess what I am saying is the ' == ' illustrates a specific singular value regardless of the source bit count, or the output will be guaranteed to be a 1 bit result.  You could have also placed it inside the 'if()', but then you need to remember to un-set it in the 'else'.

[nockieboy]

Hmm, okay, here's a testbench simulation with the fixed 16-bit values 0xAAAA on the LEFT channel and 0x5555 on the RIGHT channel.  Doesn't look right to me - should it be sending 32 bits per L/R channel or 16 bits?



Also, in this block of code below:

Code: [Select]

            if ( I2S_counter == 0 ) begin

                DAC_right_buffer   <= DAC_Right             ; // Keep a copy of the Right channel data to be transmitted during the second half.
                                                              // This was done to make sure both left and right channel data are captured in parallel on the same clock.
                DAC_serial_buffer  <= DAC_Left              ; // Transfer the left channel for immediate transmission.

            end else if ( I2S_counter == 32 ) begin

                DAC_serial_buffer <= DAC_right_buffer       ; // Transfer the right channel's sample for immediate transmission.
           
            end else begin

                DAC_serial_buffer <= DAC_serial_buffer << 1 ; // Left shift the serial out data.

            end
Shouldn't the module be sending out a bit of data when I2S_counter equals 0 and 32?  At the moment, if it equals either of those two values no bit of data is sent to the DAC_serial_buffer.  Is that right?

[BrianHG]

This looks correct.  The I2S standard is up to 32bits per channel.
Look here:


Your pattern looks correct.

Now, say we want 3 dacs in our system, a cheap 16 bit one with a headphone output and a 20 bit line level one and 24 bit for the HDMI, all with the same sound.  Notice how the MSB is at the beginning.  What would happen if we feed all 3 digital sources the same signal, all expecting 32 clocks per channel, but each outputting the most bits they can?

Also, look at it the other way around, say we can only generate 8 bit audio, meaning after our 8th bit lsb, we just send a bunch of blank zeros until the 32nd clock when the right channel begins and we send it's msb?  Will all 3 dacs on our bus still work OK?

There is one thing we should change, change line 43 to:

Code: [Select]

            sample_pulse <= ( I2S_counter == 63 ) ; // Pulse the output reference sample clock.
It is a good idea to have the active sample pulse be at the right time when we sample the left and right inputs.

[nockieboy]

Now, say we want 3 dacs in our system, a cheap 16 bit one with a headphone output and a 20 bit line level one and 24 bit for the HDMI, all with the same sound.  Notice how the MSB is at the beginning.  What would happen if we feed all 3 digital sources the same signal, all expecting 32 clocks per channel, but each outputting the most bits they can?

Ah of course, yes, I understand.

Right, so what's next?  Wire up the sine table to this?

[BrianHG]

Yes, wire up the sine table, test, and wire it up to HDMI out to verify a clean sine sound at full volume.  Once good, we will add a volume boost to the PSG's output, add a low pass filter to round the edges, then place it into you GPU.  Then you will decide if you are done, or you want to improve the DC filter with a few new lines of code.

Extra, here is the I2S spec from TI's audio dac's datasheet app-notes:



It's the same story, though, they do have I2C register controls to invert the bit-clock input sensitivity and the ability to shift the MSB further to the right by a second clock.

[BrianHG]

After applying these 2 patches which are missing in the latest I2S _tb:
https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/msg4326349/#msg4326349

Make this change at the top:

Code: [Select]

localparam bit QUICK_SIM = 0                                  ; // When running long simulations, turning this on will multiply the sim speed.
localparam  CLK_PSG_HZ   = 1789000                            ; // PSG of simulated clock
localparam  CLK_I2S_HZ   = 3072000                            ; // I2S bit clock rate of simulated clock
localparam  CLK_IN_HZ    = QUICK_SIM ? CLK_PSG_HZ : 100000000 ; // Select operating frequency of simulation.

localparam  CLK_PERIOD = 1000000000/CLK_IN_HZ        ; // Period of simulated clock.
localparam  CMD_COUNT  = 8                           ; // Number of commands to send to PSG.
localparam  ENDTIME    = (1000 * 1000 * 10) + 20    ; // Number of ns to stop simulation at.

We need accurate timing to check that my low pass filter wont be too strong.

[BrianHG]

@nockieboy, are you sure this PSG was meant to run at 1.789MHz?

For example, a frequency setting of 11 = ~10.165 Khz while a setting of 10 = ~11.181 Khz.  That's a 1khz jump and the jumps get larger the lower the frequency number, IE higher frequency.

Wouldn't a faster chip at least give you some more granularity at the higher pitches?

[BrianHG]

We had to wire the PSG's .sample() output as the new clock strobe for the DC filter.
Like this:

Code: [Select]

    wire sample_stb ; // A new strobe for when the sample is ready.

    // Instantiate PSG
    BHG_jt49 #(

        .DAC_BITS   ( DAC_BITS   ),
        .VOL_ATT_DB ( VOL_ATT_DB )

    ) PSG (

        .rst_n    ( reset      ),
        .clk      ( clk        ),
        .clk_en   ( p_stb      ),
        .addr     ( addr[step] ),
        .cs_n     ( 1'b0       ),
        .wr_n     ( wr_n       ),
        .din      ( data[step] ),
        .sel      ( 1'b1       ),
        .dout     ( dout       ),
        .sound    ( sound_mix  ),
        .A        (            ),
        .B        (            ),
        .C        (            ),
        .sample   ( sample_stb ),
        .IOA_in   (            ),
        .IOA_out  (            ),
        .IOB_in   (            ),
        .IOB_out  (            )

    );

    jt49_dcrm2 #(

        .sw    (  DAC_BITS+2   )

    ) PSG_DCFILT (

        .clk   (  clk         ),
        .cen   (  sample_stb  ),
        .rst   (  ~reset      ),
        .din   (  sound_mix   ),
        .dout  (  sound       )
    );
This should further improve sound quality with better low frequencies.

[BrianHG]

Ok, every file has been changed.  So, anything you have done on your side should be backed up and replaced.

Damn, those jt49 filters were buggy.
I also increased the core DAC bits to an adjustable parameter setting with a volume attenuation dynamic range setting.

I added the low pass filter, see: (parameter LPFILTER_DEPTH = 4)



That should be more comfortable to the ears, though you might want to tune the LPFILTER_DEPTH parameter to your liking.  It is like a treble control.

Download the updates.
Also, when the new QUICK_SIM=1, the I2S transmitter is a chunky mess.  Turning off the quick_sim fixes the problem, but simulations are ~10x slower, so you would need to shrink the 'endtime'.


First get the 1khz sine test going.

Then make a new PSG_TOP module to the name of your liking and stuff lines 25 through 152 of your TB inside and make the used relevant parameters & IO for that module and replace lines 25 through 152 in the TB with that one new module as it is your complete PSG ready to place in your GPU.


EDIT:
LPFILTER_DEPTH = 5 or 6 might be the sweet spot.  My sim snapshot above used 4.

[nockieboy]

That's looking really good!  Fortunately, even with QUICK_SIM set to 0, it only takes about 10 seconds to simulate without changing the length of the simulation.

I'm keeping about seventeen plates spinning at the moment and I'm going to be away for a week next week, so there's going to be a big(ger than usual) delay in getting anything done and it'll be even harder for me to focus for the rest of this week/weekend.

I'm marvelling at what you've done with the filters, the simulation output and trying to get my head around all these audio-related terms, and failing miserably.  Then I realised I need to be doing something...

So I need to wire the sine table to the HDMI serialiser to make sure that's working okay?  In simulation or actual HDL?  Or wire the sine table through the new filters in place of the PSG output and test that in simulation?

Sorry for the confusion, I've only got small pockets of time to work on this this week so I probably need a little more basic instruction than usual.

[BrianHG]

So I need to wire the sine table to the HDMI serialiser to make sure that's working okay?  In simulation or actual HDL?  Or wire the sine table through the new filters in place of the PSG output and test that in simulation?

Sorry for the confusion, I've only got small pockets of time to work on this this week so I probably need a little more basic instruction than usual.

You don't need to sim, just wire the sine table to the i2s transmitter in a test hdmi out project to see if you get the clean tone.

Dont forget to get rid of the audio pll and use the fp_div, and, the sine's input .clk_ena() needs to be the (fp_strobe && i2s_sample_pulse) so it only increments once every 48khz sample.

(I do not have a monitor with HDMI input and speakers to test this I2S transmitter myself, so you have to do it...)

If that works at a clean full volume, then my latest sim should sound correct, or as intended.

[BrianHG]

I'm marvelling at what you've done with the filters, the simulation output and trying to get my head around all these audio-related terms, and failing miserably.  Then I realised I need to be doing something...

What the filters are doing:

The jt49 output sample speed is really fast.  It is running at the (1.789Mhz / 4).

The low pass filter, which removes the high frequencies basically takes in the sound samples and 'averages' a small number of these samples (2^LPFILTER_DEPTH) from left to right, removing the sharp edges on it's output.

The dc filter is a high pass filter.  It does the opposite of the low pass filter.  It looks at the average of the past few thousands of samples (a large number means low frequencies are still allowed), and if the average is too high, it subtracts the output offset, position.  If the average is too low, then it adds to the output offset position.  The end result is generating a continuous corrective push, centering the output waveform around the mid 0 point.

[nockieboy]

You don't need to sim, just wire the sine table to the i2s transmitter in a test hdmi out project to see if you get the clean tone.

Dont forget to get rid of the audio pll and use the fp_div, and, the sine's input .clk_ena() needs to be the (fp_strobe && i2s_sample_pulse) so it only increments once every 48khz sample.

Uh, still lost on this.  Instead of messing about creating a new project, I'm just using the existing GPU_DECA project and tweaking the GPU_DECA_DDR3_top file to get this sine wave table set up.

I've gotten rid of u_sys_pll which produced the pll_1536k signal and replaced it with an fp_div instance.  Does this need to output the 1536k clock signal or a 3072k one?  Will I need to change the HDMI transmitter's mode at all if I switch to a double-speed clock for the audio_i2s module?

I'm guessing I need another fp_div to create a 48k clock signal to feed a strobe to the clk_ena input of the sine table module?

Code: [Select]

fp_div #(

   .INPUT_CLK_HZ        ( 100000000 ),
   .OUTPUT_CLK_HZ       (   3072000 ),
   .USE_FLOATING_DIVIDE (         1 ) 

) fp_div_i2s (

   .clk_in     ( CLK_IN    ),
   .clk_out    ( i2s_3072k ),
   .strobe_out ( i2s_stb   )

);

// ***************************************************************************************************************
// Test Sine Wave Table Generator
// ***************************************************************************************************************
wire [15:0] aud_test ;

Sine_1KHz_16b_48ksps test_audio(

   .clk     ( CLK_IN   ),
   .clk_ena ( (i2s_stb && i2s_sample_pulse) ),
   .audio   ( aud_test )

);

// ***************************************************************************************************************
// HDMI Audio I2S interface
// ***************************************************************************************************************
audio_i2s u_AVG(

   //.clk     ( pll_1536k  ),
   .clk     ( i2s_3072k  ),
   .reset_n ( !RST_IN    ),
   //.audio_i ( aud_16_o   ),
   .audio_i ( aud_test   ),
   .sclk    ( HDMI_SCLK  ),
   .lrclk   ( HDMI_LRCLK ),
   .i2s     ( HDMI_I2S   )

);
I'm probably going to give up on this today - I might have some time tomorrow, but I clearly can't put the time into this right now to understand what I need to be doing.

[BrianHG]

You don't need to sim, just wire the sine table to the i2s transmitter in a test hdmi out project to see if you get the clean tone.

Dont forget to get rid of the audio pll and use the fp_div, and, the sine's input .clk_ena() needs to be the (fp_strobe && i2s_sample_pulse) so it only increments once every 48khz sample.

Uh, still lost on this.  Instead of messing about creating a new project, I'm just using the existing GPU_DECA project and tweaking the GPU_DECA_DDR3_top file to get this sine wave table set up.

I've gotten rid of u_sys_pll which produced the pll_1536k signal and replaced it with an fp_div instance.  Does this need to output the 1536k clock signal or a 3072k one?  Will I need to change the HDMI transmitter's mode at all if I switch to a double-speed clock for the audio_i2s module?

I'm guessing I need another fp_div to create a 48k clock signal to feed a strobe to the clk_ena input of the sine table module?


I'm probably going to give up on this today - I might have some time tomorrow, but I clearly can't put the time into this right now to understand what I need to be doing.

Ok, take a look below...

Code: [Select]

// ------------------------------------------------------------------------------------------------------------
// -------- This little bit is a give-me, I did not expect you to work this out nor is it needed to test ------
// ------------------------------------------------------------------------------------------------------------
localparam DDR3_CLK_HZ = (CLK_KHZ_IN*CLK_IN_MULT/CLK_IN_DIV*1000); // Calculate the DDR3 hz speed.
localparam CMD_CLK_HZ  = INTERFACE_SPEED[0]=="Q" ? DDR3_CLK_HZ/4 :
                         INTERFACE_SPEED[0]=="q" ? DDR3_CLK_HZ/4 : DDR3_CLK_HZ/2 ; // Generate the correct CMD_CLK_HZ.
// ------------------------------------------------------------------------------------------------------------

wire i2s_3072k ;  <<<<<<<<<<< need these 2 wires...
wire i2s_stb ;

fp_div #(

   .INPUT_CLK_HZ        ( CMD_CLK_HZ ),   <<<< Choose one of the 2 below in case the tone isn't 1khz
//   .INPUT_CLK_HZ        ( 100000000 ),
   .OUTPUT_CLK_HZ       (   3072000 ),      <<<< You may optionally call this (48000 * 64), in case in the future you want to use 44100Hz and do not remember that I2S clock frequency.
   .USE_FLOATING_DIVIDE (         1 ) 

) fp_div_i2s (

   .clk_in     ( CMD_CLK   ),  <<<<<<<<<<<<<<
   .clk_out    ( i2s_3072k ),
   .strobe_out ( i2s_stb   )

);

// ***************************************************************************************************************
// Test Sine Wave Table Generator
// ***************************************************************************************************************
wire signed [15:0] aud_test ; <<<<< forgot signed.
wire i2s_sample_pulse ;         <<< Need this wire

Sine_1KHz_16b_48ksps test_audio(

   .clk     ( CMD_CLK   ),   <<<<<<<<<<<<<
   .clk_ena ( (i2s_stb && i2s_sample_pulse) ),
   .audio   ( aud_test )

);

// ***************************************************************************************************************
// HDMI Audio I2S interface
// ***************************************************************************************************************
audio_i2s u_AVG(   <<<<<<<<<<<<<<<<<<<<   W...?   THIS IS NOT OUR I2S TRANSMITTER

   //.clk     ( pll_1536k  ),
   .clk     ( i2s_3072k  ),
   .reset_n ( !RST_IN    ),
   //.audio_i ( aud_16_o   ),
   .audio_i ( aud_test   ),
   .sclk    ( HDMI_SCLK  ),
   .lrclk   ( HDMI_LRCLK ),
   .i2s     ( HDMI_I2S   )

-------------------------------------------------------------------
THIS DOWN HERE
------------------------------------------------------------------

wire     i2s_data ; <<<< need this temporary wire.

    I2S_transmitter #(

        .BITS     ( 16 ),  <<<<<< the size of the wire 'aud_test'.
        .INV_BCLK (  0 )

    ) I2S_TX (

        .clk_in         ( CMD_CLK   ), // High speed clock
        .clk_i2s        ( i2s_3072k ), // 50/50 duty cycle serial audio clock
        .clk_i2s_pulse  ( i2s_stb   ), // Strobe for 1 clk_in cycle at the beginning of each clk_i2s
        .sample_in      ( 1'b0      ), // Optional input to reset the sample position.  This should either be tied to GND or only pulse once every 64 'clk_i2s_pulse's
        .DAC_Left       ( aud_test  ),  // Left channel digital audio sampled once every 'sample_pulse' output
        .DAC_Right      ( aud_test  ),  // Right channel digital audio sampled once every 'sample_pulse' output

        .sample_pulse   ( i2s_sample_pulse ), // Pulses once when a new stereo sample is taken from the DAC_Left/Right inputs.  Hint: once every 64 clk_i2s_pulse's
        .I2S_BCLK       ( HDMI_SCLK   ), // I2S serial bit clock output (SCLK), basically the clk_i2s input in the correct phase
        .I2S_WCLK       ( HDMI_LRCLK  ), // I2S !left / right output (LRCLK)
        .I2S_DATA       ( i2s_data    )  // Serial data output   

    );

// Wire all 4 stereo channels together.
// We must BLAST that incredible YM2149 sound on every speaker possible so that we are bathed in its infinite beauty!
assign HDMI_I2S[0] = i2s_data  ; // (front left and right)
assign HDMI_I2S[1] = i2s_data  ; // (rear left and right)
assign HDMI_I2S[2] = i2s_data  ; // (Front Center and Sub-woofer)
assign HDMI_I2S[3] = i2s_data  ; // (side left and right)


[BrianHG]

If you achieve a nice clean 1khz tone, ignore the rest of this message... (Don't forget to patch line 141 of the I2C_HDMI_Config.v first in case you are running in DVI mode.)

If you fail to get any sound, there is a slight chance you might need to set the HDMI transmitter's I2C config address 0x0A with 0x00, or 0x03.

See: I2C_HDMI_Config,

You will need to add a new entry to the bottom of the table:

Code: [Select]

31 : LUT_DATA <= 16'h0A00;  // or 16'h0A03, default 16'h0A01   MCLK Ratio The ratio between the audio sampling frequency and the clock described using N and CTS
And adjust the parameter on line 32,  LUT_SIZE = 31 to 32.

Do not do this until all other avenues of bugs have been worked out.

[BrianHG]

@nockieboy, I need to see a schematic of how the analog outputs for the YM2149 are wired to the audio jack.  Since it has 3 individual outputs, 1 per channel, depending on the wiring, I believe that the jt49 filters we are using and the way they are wired will not generate the appropriate sound.  We want to include the proper math formula to replicate the circuit's analog sound.

See attached example filters:

[nockieboy]

@nockieboy, I need to see a schematic of how the analog outputs for the YM2149 are wired to the audio jack.  Since it has 3 individual outputs, 1 per channel, depending on the wiring, I believe that the jt49 filters we are using and the way they are wired will not generate the appropriate sound.  We want to include the proper math formula to replicate the circuit's analog sound.

Below is a section of my hardware soundcard schematic that I made a few years ago for the uCOM using a real AY-8910 chip and analogue output stage.  The output mirrors almost exactly the channel mix setup of the Amstrad computers that I wanted to reproduce (apart from having an amplifier built-in too, ignore the volume control (R7-R9) and LM386 that sits off-shot for that):

[BrianHG]

Ok, I can throw something together on the weekend.

The way you have that circuit, if you plug the headphone out to an audio amp or powered speakers, the bass should seem ok.  But, if you plug in headphones, the bass should become crapped out and the volume should suffer.

Also, there is no low pass filter.  Doesn't that output have a high pitched tin sound?

Anyways, copy my code from here: https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/msg4339420/#msg4339420 and get the 1khz sine test working.  Make sure the tone is soft and pure without any clicks or pops.

[nockieboy]

Ok, I can throw something together on the weekend.

The way you have that circuit, if you plug the headphone out to an audio amp or powered speakers, the bass should seem ok.  But, if you plug in headphones, the bass should become crapped out and the volume should suffer.

Also, there is no low pass filter.  Doesn't that output have a high pitched tin sound?

Anyways, copy my code from here: https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/msg4339420/#msg4339420 and get the 1khz sine test working.  Make sure the tone is soft and pure without any clicks or pops.

It sounded pretty authentic to be fair, but I literally just copied existing (old) schematics and referred to modern schematics for the amp stage, wired it together and hoped it worked.  I'm not an audiophile by any stretch of the imagination, I certainly know nothing about audio/analogue electronics (apart from the need for decoupling, I understand that!) and am probably tone-deaf too, so there's that. 

[nockieboy]

Yes, getting a nice clear 1KHz tone from the TV now.

[BrianHG]

Yes, getting a nice clear 1KHz tone from the TV now.

It seems it's ok.  If the sine had the wrong bit position, or not being 'signed' representation, you would have heard a tin-sounding effect like a square or saw-tooth wave.

Now, bundle all the '_tb' PSG core with filters and clock dividers into a new PSG system .sv module with just the clk, command and parameter inputs, and I2S outputs.  Then use that 1 module to replace the current sine test section only keeping my 'localparam' CMD_CLK_HZ calculator so the new PSG system will automatically receive the CMD_CLK frequency no matter how you configure the DDR3 system clock.

Then make a new PSG_TOP module to the name of your liking and stuff lines 25 through 152 of your TB inside and make the used relevant parameters & IO for that module and replace lines 25 through 152 in the TB with that one new module as it is your complete PSG ready to place in your GPU.

[BrianHG]

Once working and sounding good, replace lines 25 through 152 in your _tb with the new PSG system like it is wired in your GPU.  Upload the new tb so I may engineer the new stereo output mixer with the new singular 'PSG system' module.

As for the DECA audio codec, I have the programmer's app notes data sheet and it has a few I2C registers which need to be set 1ms after reset.  Then with nothing more than a hard-wired I2S signal, you should get both HDMI and line out audio simultaneously working.

[nockieboy]

Here's my PSG _top module.  Haven't had time to merge it into the DECA_DDR3_top module yet, so there's probably mistakes and errors in it.  Just wondering about the DAC_BITS parameter.  This determines the width of the sound output to the I2S transmitter, as well as the depth of the DAC I guess.

If I understand it all correctly, I'm going to need a 16-bit output to the I2S transmitter, which means DAC_BITS can only be 15, unless I add in some code to automatically 'make up' the width to 16 bits no matter what DAC_BITS value is entered - is that right?

[BrianHG]

Ok, only a minor error:

Line 60:
.INPUT_CLK_HZ        ( CMD_CLK_HZ ),
Change to: CLK_IN_HZ

The parameter 'CMD_CLK_HZ' is outside this module feeding this module's parameter 'CLK_IN_HZ'.

Line 61:
.OUTPUT_CLK_HZ       ( (48000*64) ),   // 48KHz signal
Change to: CLK_I2S_HZ.

You may place the '(48000*64)' in place of the '3072000' on parameter line 5.

Or, even better, rename parameter on line 5 from 'CLK_I2S_HZ' to 'I2S_DAC_HZ' and just place 48000 there.

Then on line 61, change it's output clock setting to this:
.OUTPUT_CLK_HZ       ( I2S_DAC_HZ*64 ),   // 48KHz signal


We don't need line 27, that is specifically for the _tb.sv module and its simulated master clock.


That's it.  You did very well.

If I understand it all correctly, I'm going to need a 16-bit output to the I2S transmitter, which means DAC_BITS can only be 15, unless I add in some code to automatically 'make up' the width to 16 bits no matter what DAC_BITS value is entered - is that right?

The 'DAC_BITS' (currently set to 10) now defines the depth of each channel's, A-B-C audio output.
When mixing/adding the 3 together, we then need at least 12 bits for the mixed sound output.

As I told you earlier, the I2S transmitter can operate anywhere between 8 bits and 32 bits in, so for the way the system is currently setup, the PSG's output is feeding 12bit audio through the I2S TX.

Remember the second half of what you missed to acknowledge here:

Now, say we want 3 dacs in our system, a cheap 16 bit one with a headphone output and a 20 bit line level one and 24 bit for the HDMI, all with the same sound.  Notice how the MSB is at the beginning.  What would happen if we feed all 3 digital sources the same signal, all expecting 32 clocks per channel, but each outputting the most bits they can?

Ah of course, yes, I understand.

The paragraph right after that one I wrote:

Also, look at it the other way around, say we can only generate 8 bit audio, meaning after our 8th bit lsb, we just send a bunch of blank zeros until the 32nd clock when the right channel begins and we send it's msb?  Will all 3 dacs on our bus still work OK?

So setting the I2S DAC_BITS to 12 bits is the correct action and it will just shove the 12 data bits from the left and right inputs all the way up to the left-most on the output, and if the DAC's is actually a 16bit one, it will just receive a bunch of zeroes for it's LSBs.

That should do it for your 'arya_top'.  Once you placed it in your GPU and verify that it sounds ok, next place it in your 'jt49_tb.sv', replacing lines 28 through 151 and polish the setup_psg.do.  Upload everything here and I will make my own new proper output stereo mixer and filter module from scratch, then we will close up this part of the project.


QUESTION: Why did you call it 'arya_top', what does 'arya' stand for?
Keep in mind that after we finish the filter, we will Github publish this customized fork of jt49's original.  Maybe you should more carefully think about the name.

Too bad you didn't want to do this the right way.  You could have had a 16-64 voice stereo HD audio experience with full stereo sampled instruments held in DDR3.  Anyways... The stereo 8 channel YM2151 would have been a much nicer PSG.

[nockieboy]

QUESTION: Why did you call it 'arya_top', what does 'arya' stand for?
Keep in mind that after we finish the filter, we will Github publish this customized fork of jt49's original.  Maybe you should more carefully think about the name.

Erm... no reason in particular, to be honest.  I may have been thinking along the lines of an 'aria', being to do with music etc, and the Y instead of an I because it emulated the YM2149...    I'm more than happy for better suggestions!

Too bad you didn't want to do this the right way.  You could have had a 16-64 voice stereo HD audio experience with full stereo sampled instruments held in DDR3.  Anyways... The stereo 8 channel YM2151 would have been a much nicer PSG.

Well, now this 8-bit lobotomised version of that fantastic PSG system is done, perhaps we could move on to the all-singing and dancing version?  It'll likely benefit somebody somewhere who is more musically-minded than I am, and may even benefit me if I get around to building my 16-bit 68010 DIY computer.

The reason I wanted it done 'the wrong way' was so that I could use it with my uCOM.  There is a pool of music available in CP/M compatible with the AY-3-8910 / YM2149 which I have, so I'm able to test the PSG and listen to stuff with virtually no effort at all (I have a bug in the CP/M player program I'm needing to fix, but that shouldn't be impossible).  But I literally am not joking or overstating things when I say I don't have a musical bone in my body.  A fancy PSG that can do all those marvellous things will be wasted on my current host system as I have absolutely no music, in any format, that can make use of all those features/channels/voices and I absolutely do not have - nor will I ever have - the skill necessary to write a musical piece to test those features.