FPGA VGA Controller for 8-bit computer

[nockieboy]

I'll keep plugging away at the side projects in the meantime - moving the MMU to HDL will be my first priority.  Once that's done I'll be able to read the MMU and discover the current bank mappings (it's write-only at the moment) without having to keep trace of them in a set of variables (which has hardly proved that accurate so far!)

Hmmph, well that didn't take me long. I guess I'll start playing with the AY-8910 PSG HDL and integrate that into the design.

Ok.  So quick and simple, care to share what you did?
What did the code look like?
Can you address all 512mb?

I've been able to address all 512MB for some time now, with a couple of additional registers accessible to the host via IO that give the host access to the full DDR3 memory space by changing the 512KB 'window' that is presented.  The changes I made today were more about upgrading my existing hardware MMU, the original one that gives the Z80 access to 4MB of memory space in 16KB pages using two 74LS670s (which seem to be getting more and more scarce).  The big problem with the existing MMU setup was that it was write-only, so I had no easy way of knowing which bank was mapped to which area without keeping track of every write to the MMU in four bytes of RAM.  I was still unable to work out exactly which ROM bank the DMI or Bootstrap was loading from at cold boot.

What I did this morning was more a quick hack than a true solution to the HDL MMU task, but it gives me the same results - I'm just copying the writes to the MMU's IO addresses in the Z80_Bridge and recording the bank values.  Any reads to the MMU's four Area addresses are responded to by Bridgette with the stored value (current Bank #).  Simples.

The github project has been updated with the latest project code, including the fully working SD interface (1-bit mode currently).

Now I'm fully aware that I haven't actually replaced the hardware MMU on the uCOM's memory card just yet, but what I've done in about 10 minutes work is provide all the benefits of the HDL MMU and none of the headaches (the HDL MMU will still be limited to 16KB banks because of how the EA bus is wired on the DECA interface card).  When I decide later that I've got to build another memory card and can't find any spare LS670s any more, I can just add a few lines of HDL to Bridgette swapping the direction of the EA bus buffer and where it intercepts memory read/writes I can tell it to output the appropriate additional address data according to the current mapping value for the 16KB Area being addressed and output the correct address lanes via the EA bus.

I did have the thought this morning that I could just get the HDL MMU to map the Z80's entire 64KB RAM space into the DDR3 and remove the memory card entirely from the stack- but at the moment I feel that's a step too far in reducing my hardware project that I have enjoyed learning about, designing and building to bland HDL.  I could also make the banks smaller - say 4KB instead of the current 16KB - which would provide more flexibility.  That's a job for another day, though.  My 'quick hit' objective was completed, so it's time to move on to the sound (hopefully!) 

[BrianHG]

Replicating the 74LS670 shouldn't be a problem to replicate in HDL with nothing more than a logic array: x bits by x words.

Feeding bank address bits position into that logic array, where the logic data output is wired to the upper address of the DDR3 controller to address all your ram bank by bank should also be easy.

Reset clears the array to 0,1,2,3.... to feed through the full Z80 upper address bits, 64k uninterrupted.
Also, I assume you have a write data or port into the array to fill the upper address for each bank group.

Code: [Select]

IE: to get the full rw addr:

// register to hold 16 banks of 4096 words each with an extra 16 address bits.
// (This is a 256 megabyte example)
logic [15:0] page_remap [0:15] = '{0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15} ; // Default passes through the Z80's upper address bits untouched.

// Drive the DDR3 address with the stored banks inserted above the first 12 address bits.
assign DDR3_addr[31:0] = {4'd0, page_remap[z80_addr[15:12]], z80_addr[11:0] };

// To set a bank :
if (reset) page_remap <= '{0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15} ; // After reset, everything runs as a direct address feed-through.
else if (port_data_bankset_pulse) page_remap[port_data_bankset[3:0]] <= {port_data_bankadr_h,port_data_bankadr_l} ;
If so, how is this so difficult to implement?
Obviously, you can parameterize the width and address bit locations, like making each bank size like 4 banks of 16k instead of 16 banks of 4k, leaving you with 1gbyte addressable space.

Also, you can make 2x page_remap arrays.  One for write data, and one for read data.

You can also pipe out an asynchronous EA bus with 1 line:

Code: [Select]

EA_bus <= page_remap[z80_addr[15:12]];generating your FPGA based MMU upper address bits for external use, just don't forget to move the address bits on your peripherals.

You can go extra dumb by just using 32 ports, every 2 ports being 16 bit word of your 'page_remap' saving Z80 cpu cycles when filling the MMU table.  The 'page_remap' could also be 32 bytes of writable ram, but this will leave a hole in your address space as the MMU needs access no matter what it's contents are whereas ports wont.  Also remember, you can read as well as write ports.  Just tie the 32 port outputs into 32 port inputs of the same port number.

IE:

Code: [Select]

wire [15:0] page_remap [0:15] = '{ // assign 16 banks of 4kb
{port0,port1},
{port2,port3},
{port4,port5},
{port6,port7},
{port8,port9},
{port10,port11},
{port12,port13},
{port14,port15},
{port16,port17},
{port18,port19},
{port20,port21},
{port22,port23},
{port24,port25},
{port26,port27},
{port28,port29},
{port30,port31}};

or:
IE:

Code: [Select]

wire [15:0] page_remap [0:3] = '{  // assign 4 banks of 16kb
{port0,port1},
{port2,port3},
{port4,port5},
{port6,port7}};

Only now your reset needs to be setting ports #0-31 or 0-7.

Dont forget you can also have a separate page_remap for data and another for OP-code since our Z80 bus already decodes the op-code VS data.

[nockieboy]

Replicating the 74LS670 shouldn't be a problem to replicate in HDL with nothing more than a logic array: x bits by x words.

Feeding bank address bits position into that logic array, where the logic data output is wired to the upper address of the DDR3 controller to address all your ram bank by bank should also be easy.

Reset clears the array to 0,1,2,3.... to feed through the full Z80 upper address bits, 64k uninterrupted.
Also, I assume you have a write data or port into the array to fill the upper address for each bank group.

....

If so, how is this so difficult to implement?

I didn't say it was, just that having thought through it all yesterday, there's no advantage to implementing it fully yet and my short gaps of time to work on this project are better spent elsewhere for the time being.

You can go extra dumb by just using 32 ports, every 2 ports being 16 bit word of your 'page_remap' saving Z80 cpu cycles when filling the MMU table.  The 'page_remap' could also be 32 bytes of writable ram, but this will leave a hole in your address space as the MMU needs access no matter what it's contents are whereas ports wont.  Also remember, you can read as well as write ports.  Just tie the 32 port outputs into 32 port inputs of the same port number.

...

Only now your reset needs to be setting ports #0-31 or 0-7.

I think ports are the way to go - no memory holes, I have the free ports etc.

Dont forget you can also have a separate page_remap for data and another for OP-code since our Z80 bus already decodes the op-code VS data.

Although the Z80 can differentiate opcodes from data, it is still a von Neumann processor; it doesn't separate commands from data like a Harvard processor does.  It has variable-length opcodes which would make the task of separating code from data an epically tedious process, requiring the writing of custom assemblers/disassemblers and so on, with no real benefit that I can perceive whilst writing this.

Off on a tangent now - is there any easy way to convert VHDL to Verilog other than manually?  Way back when I started this project, the choice of developing in Verilog or VHDL was a toss-of-a-coin for me as I had no experience (or knowledge) of either and I went with what the expert helping me out was familiar with.   I find myself now looking at some VHDL and really wishing I could translate it to Verilog so I could understand it better and, personal opinion, I'm glad I learned Verilog and not VHDL - it looks unnecessarily wordy!

[BrianHG]

Off on a tangent now - is there any easy way to convert VHDL to Verilog other than manually?  Way back when I started this project, the choice of developing in Verilog or VHDL was a toss-of-a-coin for me as I had no experience (or knowledge) of either and I went with what the expert helping me out was familiar with.   I find myself now looking at some VHDL and really wishing I could translate it to Verilog so I could understand it better and, personal opinion, I'm glad I learned Verilog and not VHDL - it looks unnecessarily wordy!

First make sure you need to.  You can make a verilog module which calls / instantiates your VHDL modules in the same way as if it were another verilog module.  Otherwise you are in for a ride which either may lead you back to just using the VHDL as is, or debugging a tone of peculiarities if you do not understand what the VHDL is exactly supposed to do.

Read full example here: https://www.eevblog.com/forum/fpga/vhdl-code-to-verilog-code/msg4123399/#msg4123399

  Until I finally did the authentic translation here all the way at the bottom.  We had to simulate side-by-side and verify the 2 codes were returning the same results with a list of matched random inputs going to both modules.

  Comparing the original VHDL to my final Verilog shows it can be done.

[BrianHG]

In my above link, don't forget to download my final .zip showing you how to parallel simulate your VHDL vs Verilog to proof your design.

[nockieboy]

In my above link, don't forget to download my final .zip showing you how to parallel simulate your VHDL vs Verilog to proof your design.

I think I'll stick with the VHDL.  I don't think I'll gain much from translating it to Verilog, I was just wondering if there was an easy way to do it.

In other news, I seem to be hitting some glitches in the GPU.  I've noticed that the display on the TV keeps cutting out, quite frequently at first, almost as if the screen display is changing mode or the HDMI cable is loose (it's not).  After a few minutes it seems to stabilise and not do it any more.

Another glitch I noticed earlier today whilst writing some code to display a cursor caret in the DMI.  I noticed these vertical blue lines down the left edge of the screen - a little flickery, there for a short time, then disappeared, then reappeared briefly a few times then went completely.  Hadn't noticed these before.  Here's a pic:



Any ideas what could be causing this?

[BrianHG]

(Wait... before the rest, I used to get this problem before changing my HDMI cable as the plug on the DECA board keeps on eating a contact in my HDMI cable every time I plug one in and out a few times...)

If not the cable, then:

Strange.  What does your final timing report say?
It looks like a problem with the HDMI data or CLK line timing or noise.
Are you powering your project from USB alone, or using the power supply?  What happens if you insert or remove the SD card?
How warm is the FPGA getting?  What happens if you cool it?
Note that mine runs cool, however, my ellipse demo is a far simpler design.

If all else fails, send an update of your latest complete project with a 1mb RS232 debug capture file of your system where those blue dots appear to see if I can see them here.

[BrianHG]

Note that some of my above point may be that you could be overloading the onboard switcher PSU and you are seeing noise during my DDR3 video line buffer bursting which runs at the full 1600mb/sec once every H-sync.

The system limit of the DECA is ~2 watts when powered by the USB.
Are you powering any of you Z80 circuitry as well?

(note that on my side, I found the DECA hdmi transmitter is really weak.  I even had to ensure that my monitor's AC plug when into the same power bar as my PC powering the DECA for 1080p to work.  (Most likely frame GND interference via a gigantic GND loop)  This is not a DDR3 issue as either an active HDMI cable amplifier or a really short cable would also solve the issue on my side.)

[nockieboy]

Note that some of my above point may be that you could be overloading the onboard switcher PSU and you are seeing noise during my DDR3 video line buffer bursting which runs at the full 1600mb/sec once every H-sync.

The system limit of the DECA is ~2 watts when powered by the USB.
Are you powering any of you Z80 circuitry as well?

(note that on my side, I found the DECA hdmi transmitter is really weak.  I even had to ensure that my monitor's AC plug when into the same power bar as my PC powering the DECA for 1080p to work.  (Most likely frame GND interference via a gigantic GND loop)  This is not a DDR3 issue as either an active HDMI cable amplifier or a really short cable would also solve the issue on my side.)

It's a really intermittent issue, which makes it hard to solve.  More often than not, there's no issue - perhaps one time in ten or more I see screen blanking, I saw the blue lines down the side for the first time when I took the picture yesterday.

I've tried wiggling (gently) the HDMI connector, haven't noticed any interference as a result and the image is rock-steady today.

I am currently powering both the DECA and the uCOM from the same USB 3.1 port for convenience.  The entire setup is drawing about 0.85A - which is close to the maximum 900mA for a standard USB 3 port.   I can always connect the DECA via another USB port (i.e. one off the back of the PC) to split the power demand, this takes the uCOM's power draw down to just under 2.5W.

I'll see if I can get temperatures and more information the next time the issue crops up.

[BrianHG]

It may not be the USB port limit, but DECA's the onboard PSP which may be designed for the 500ma limit of USB1.

As for intermittent, remember to grab the RS232 debugger and capture 1mb snapshot when you see the problem.

The you TX the 1mb file lateron when the problem isn't there to see if it comes back.

You can also try changing the HDMI from HDMI mode to DVI mode in the I2C controls to see if that helps.

[nockieboy]

On a separate tangent,  I'm working on integrating an HDL PSG and, initially at least, am looking to output audio via the TV rather than the DECA's DAC.  What do I need to do to the project to get the audio output via HDMI again? (Just after the test audio tone we worked on some time ago?)

I've uncommented the two blocks that instantiate sys_pll and AUDIO_IF, and added those files back into the project from a previous version (though maybe not the working version of those files.. ).  Getting no audio at the moment.

[BrianHG]

Make sure that the I2C setup for your HDMI transmitter is set to HDMI instead of DVI to get audio through the HDMI out.

Line 141 in I2C_HDMI_config.v:

Code: [Select]

25 : LUT_DATA <= 16'haf14;  //*********************************16'haf14=Select DVI mode //16'haf16=Select HDMI mode


Once you get the 1kHz sine tone in the HDMI audio, you should tie the I2S audio lines of the HDMI audio to the audio DAC audio output and you should have parallel copy of the audio on the HDMI and line out jacks in parallel.  Though, check to see if the line out DAC has I2C controls of it's own, then you need to make sure it is set to the same audio bit depth and clock rate of the HDMI transmitter so both will be expecting the same data.

Worry about first getting the existing 1 khz tone generator working on both.

They worry about adapting your sound synthesizer HDL.

(Don't forget to try a new HDMI cable, or a different input on your monitor to see if that blue garbage disappears.  My old desktop garbage LG Flatron monitor is garbage with it's HDMI input and the DVI in wont even accept a HDMI encoded video signal.)

[BrianHG]

Get the data sheet on the 'TLV320AIC3254'.
Check the DECA .pdf.

It uses a 1 bit data I2S while the HDMI transmitter seems to have a 4 bit one.  However, this may be due to supporting more than 2 channel audio.

Wire up an IC2 transmitter with a configuration for 16bit 48khz audio in with a quality over-sampled sound out at full volume wired to the line-out or headphone jacks according to the DECA schematic.  Also use it to pass the reset line.

Make a module which will generate your 48khz pulse from the bclk and wclk, taking in 16 bit stereo sampled on that 48khz, and sending out the serial data to the audio codec.

Go to my HDMI serialize and get the 1khz test tone generator to make the 16 bit data using the 1khz pulse.

Also remember that my 'BrianHG_GFX_PLL_i50_o297  VGA_PLL', ~line 1121 in the GPU top.sv has a 54MHz output you can use.

You probably want an MCLK of 48000 x ( 16bit L + 16bit R ) = 1536000 Hz for the BCLK
For your serializer, use 4x that clock so you may plan the clk and data bit outputs at timing edges, ie: 6.144 Mhz exactly, where the 48khz pulse is generated once every 128 clocks.

Or, just use the DECA HDMI example which runs their audio serializer exactly at 1536000Hz and use their serializer code tied to the 'TLV320AIC3254' I2S inputs noting that you only need 1 data bit.
(Note that their dumb serializer uses posedge and negedge clocks instead of a 2x/4x source clock to set the outputs, but they have the right PLL for you potentially wasting a valuable clock which may be needed for the FM synthesizer, or you may generate your own compatible PLL if needed...)

[nockieboy]

Yes, that was it - had to update line 141 in I2C_HDMI_config.v.   I have tone. 



Good suggestion re: getting audio out to the DAC before worrying about the PSG.

I'll hopefully have time tomorrow to hit the datasheets, manuals and guides but, in the meantime, do any of these outputs from the sound generator HDL appear to be usable?

* unsigned 12-bit output x 3 channels
* unsigned 14-bit summation of the channels
* signed 14-bit PCM summation of the channels, with each channel converted to -/+ zero-centred level or -/+ full-range level

Which will be best to use, bearing in mind I'll need to take a look at how to convert it to I2S (won't look at conversion right now, want to get some sleep and not have my brain working all night!)

Ah, you beat me to it whilst I was writing the above reply!

Get the data sheet on the 'TLV320AIC3254'.
Check the DECA .pdf.

It uses a 1 bit data I2S while the HDMI transmitter seems to have a 4 bit one.  However, this may be due to supporting more than 2 channel audio.

Wire up an IC2 transmitter with a configuration for 16bit 48khz audio in with a quality over-sampled sound out at full volume wired to the line-out or headphone jacks according to the DECA schematic.  Also use it to pass the reset line.

Make a module which will generate your 48khz pulse from the bclk and wclk, taking in 16 bit stereo sampled on that 48khz, and sending out the serial data to the audio codec.

Go to my HDMI serialize and get the 1khz test tone generator to make the 16 bit data using the 1khz pulse.

Also remember that my 'BrianHG_GFX_PLL_i50_o297  VGA_PLL', ~line 1121 in the GPU top.sv has a 54MHz output you can use.

You probably want an MCLK of 48000 x ( 16bit L + 16bit R ) = 1536000 Hz for the BCLK
For your serializer, use 4x that clock so you may plan the clk and data bit outputs at timing edges, ie: 6.144 Mhz exactly, where the 48khz pulse is generated once every 128 clocks.

Or, just use the DECA HDMI example which runs their audio serializer exactly at 1536000Hz and use their serializer code tied to the 'TLV320AIC3254' I2S inputs noting that you only need 1 data bit.

I'll make a start on all this tomorrow, hopefully, if work allows.

At the moment, I've only got two questions - the first is the one asked above - which is the best output from the synthesizer to use, and the second is easier perhaps - I need a 1.789MHz clock, or as close as possible to it for accuracy of tone, for the sound generator module.  I know there's the 1.536MHz signal from the HDMI's audio PLL, but just wondered as you'd mentioned a 54MHz clock I'd not known about, if there were any other clocks in the project I could use/divide down?  That 54MHz clock will divide down to 1.6875MHz, which is even closer than the HDMI audio PLL I was intending to use, but is there anything I could use that would get me closer to 1.789MHz?

[nockieboy]

Oh, one last thing - putting the output into HDMI mode seems to cause the layering to fail.  In DVI mode, the display is 720x480, but with a layer 40 pixels thinner and shorter than the display resolution, centred on the screen to show a 20-pixel wide border around the edge.  When I switch to HDMI mode, it's as if the layer becomes 720 pixels wide and the border disappears except for a thin strip and the top and bottom.

Any ideas?

[BrianHG]

Take the 14bit parallel output.  Add 2'b00 as the bottom 2 bits and you got a 16bit parallel output.

You can also use the 3 separate output and place channel 1 on left added to channel 2, and channel 3 on right added to channel 2, making 2 a mono center channel.

Or, make 2 synths, one on left, one on right.

Make 3 control ports.  control port A would drive both synths in parallel meaning a fallback mono audio.  Control port B and C do the same as A, but B exclusively drives the left synth and C exclusively drives the right synth for stereo sound.  Or, do whatever you like.  Add 4 synths, 1 left, 1 center, 1 right, 1 rear offering 12 audio channels.

[BrianHG]

Oh, one last thing - putting the output into HDMI mode seems to cause the layering to fail.  In DVI mode, the display is 720x480, but with a layer 40 pixels thinner and shorter than the display resolution, centred on the screen to show a 20-pixel wide border around the edge.  When I switch to HDMI mode, it's as if the layer becomes 720 pixels wide and the border disappears except for a thin strip and the top and bottom.

Any ideas?

When in HDMI mode, some monitors may be applying an overscan-scale.  Look for a 1:1 pixel setting on the monitor, or, maybe there is an automatic border set by the HDMI transmitter IC as we are basically adding dummy borders around the image to make the 148.5MHz pixel clock appear as a 108MHz clock.  IE: try 720p or mode 0 instead of mode 7 480p and see if the problem persists.  (Because of the fixed pixel clock, mode 0 480p will be at a higher framerate than 60hz.  IE: 66hz instead of 60hz when using pixel divide by 5.)

[nockieboy]

When in HDMI mode, some monitors may be applying an overscan-scale.  Look for a 1:1 pixel setting on the monitor, or, maybe there is an automatic border set by the HDMI transmitter IC as we are basically adding dummy borders around the image to make the 148.5MHz pixel clock appear as a 108MHz clock.  IE: try 720p or mode 0 instead of mode 7 480p and see if the problem persists.  (Because of the fixed pixel clock, mode 0 480p will be at a higher framerate than 60hz.  IE: 66hz instead of 60hz when using pixel divide by 5.)

Can't find a 1:1 pixel setting, but if I switch modes to 1080p, the border is preserved and all is good, so it looks like the monitor is doing some kind of scaling/overscan as you've suggested. Will just have to live with it for the time being in the lower-res modes.

[BrianHG]

When in HDMI mode, some monitors may be applying an overscan-scale.  Look for a 1:1 pixel setting on the monitor, or, maybe there is an automatic border set by the HDMI transmitter IC as we are basically adding dummy borders around the image to make the 148.5MHz pixel clock appear as a 108MHz clock.  IE: try 720p or mode 0 instead of mode 7 480p and see if the problem persists.  (Because of the fixed pixel clock, mode 0 480p will be at a higher framerate than 60hz.  IE: 66hz instead of 60hz when using pixel divide by 5.)

Can't find a 1:1 pixel setting, but if I switch modes to 1080p, the border is preserved and all is good, so it looks like the monitor is doing some kind of scaling/overscan as you've suggested. Will just have to live with it for the time being in the lower-res modes.

So, the authentic mode 0 480p doesn't work?

[BrianHG]

Also, what happened to the speckle dots?
Did you get the line-out to run with the 1khz tone from copying the HDMI I2S output to the audio codec?
Note that since the line out is only stereo, you should only be using data bit 0, but the Mclk, Wclk, Sclk should match and there might be 1 high frequency control clock added to that.

You should be able to re-configure or make your own PLL clock replacement to match the HDMI audio PLL clock rate, but, add a few extra clock outputs for your sound generator module.

The HDMI audio serializer has a parallel data LUT table in it.  You will be taking that table, making sure you separate out the left and right, and make a new parallel 16bit stereo input port with said serializer to send raw parallel digital audio through the HDMI.

[nockieboy]

So, the authentic mode 0 480p doesn't work?

I actually haven't tested that mode yet.  Have a lot going on, so am having to prioritise.  I'll get to this soon, hopefully.

Also, what happened to the speckle dots?

I saw the blue lines again briefly yesterday, but that was for 2 seconds and haven't seen them since.  Like I said, they're very infrequent.

Did you get the line-out to run with the 1khz tone from copying the HDMI I2S output to the audio codec?
Note that since the line out is only stereo, you should only be using data bit 0, but the Mclk, Wclk, Sclk should match and there might be 1 high frequency control clock added to that.

You should be able to re-configure or make your own PLL clock replacement to match the HDMI audio PLL clock rate, but, add a few extra clock outputs for your sound generator module.

The HDMI audio serializer has a parallel data LUT table in it.  You will be taking that table, making sure you separate out the left and right, and make a new parallel 16bit stereo input port with said serializer to send raw parallel digital audio through the HDMI.

Okay, I've deviated from the plan very slightly in terms of the order of doing things.  I had a successful couple of hours yesterday, and got the synthesiser output wired into the HDMI audio feed and now get beeps out of the TV when I try to delete past the start of the screen (so basic audio is working in the DMI).  I figured that was an easy hit (and my end goal, ultimately), so I haven't yet started on linking the synth up to the DAC on the DECA board, as that looks to be a little more involved and will take me more time.

My focus today has been on trying to sort out the tuning/timing issues and getting music to play.  I'm able to play notes in the DMI, but can't get the CP/M program to play PT3s at the moment, which is a pain - so I'm debugging that.  Once that's done, I'll turn my attention to the DAC output.

The YM2149 module has some pretty specific requirements - some of which may still cause me issues.  Here's a snip of the text at the start of the module:

Code: [Select]

-- Clock, Clock-enable, and Sel.
--
-- The clk_i input should be the full-speed clock of the system, and
-- en_clk_psg_i must be a strobe (single clk_i tick) at the PSG operating
-- frequency.
--
-- This core can use a much faster clock-enable than the original PSG, however
-- the clock-enable frequency affects the output audio frequency directly.  If
-- producing sounds similar to the original ICs is desired, then using an
-- accurate input clock-enable is important.
The clk_i input is fed by CMD_CLK.  The clock-enable is created by a module I wrote that takes the CLK_54 output from the VGA_PLL and divides it down to get a 1.78 MHz clock signal.  It then creates a strobe (with a pulse width of CLK_54) at 1.78 MHz frequency which is passed to the YM2149 module via en_clk_psg_i.

One issue is that the YM2149 module won't do anything until the rising edge of one of these strobes at 1.78 MHz.  This means it can miss entire I/O reads or writes from the host when a rising edge on en_clk_psg_i doesn't perfectly coincide with the right part of the host's I/O cycle.  To get around this, I've just OR'd the strobe with the control signal from the host to the synth, so a pulse is always generated at the start of an I/O op and is never missed.  This pulse is obviously out of frequency and the pulse width is wider than the normal strobe, but it seems to get the job done for the moment.

EDIT: I've added a zip with some key files in it used in the project to produce sound, including the updated project _top file linking the major parts together.

[BrianHG]

If you wanted verilog, then look here: https://github.com/jotego/jt49
Includes test-benches.

[BrianHG]

Code: [Select]

-- Clock, Clock-enable, and Sel.
--
-- The clk_i input should be the full-speed clock of the system, and
-- en_clk_psg_i must be a strobe (single clk_i tick) at the PSG operating
-- frequency.
--
-- This core can use a much faster clock-enable than the original PSG, however
-- the clock-enable frequency affects the output audio frequency directly.  If
-- producing sounds similar to the original ICs is desired, then using an
-- accurate input clock-enable is important.
The clk_i input is fed by CMD_CLK.  The clock-enable is created by a module I wrote that takes the CLK_54 output from the VGA_PLL and divides it down to get a 1.78 MHz clock signal.  It then creates a strobe (with a pulse width of CLK_54) at 1.78 MHz frequency which is passed to the YM2149 module via en_clk_psg_i.

One issue is that the YM2149 module won't do anything until the rising edge of one of these strobes at 1.78 MHz.  This means it can miss entire I/O reads or writes from the host when a rising edge on en_clk_psg_i doesn't perfectly coincide with the right part of the host's I/O cycle.  To get around this, I've just OR'd the strobe with the control signal from the host to the synth, so a pulse is always generated at the start of an I/O op and is never missed.  This pulse is obviously out of frequency and the pulse width is wider than the normal strobe, but it seems to get the job done for the moment.

EDIT: I've added a zip with some key files in it used in the project to produce sound, including the updated project _top file linking the major parts together.

I'll help you out here if you setup a modelsim workbench with these 2 modules with a 100mhz source clock.
No pll, just the divider plus a means of entering a few test sound commands.

Then we will worry about the precision reference 1.78 mhz needed for it internal tone generator from a 100MHz clock without a PLL as I have already created the fractional divider code in our HDMI serializer project.  In fact, that divider can be used multiple times to generate the second sample clock of 1.536/1.4112 MHz needed for the I2S sclk signal and it's shifter used for the 48/44.1khz sample rate of the HDMI audio and audio codec/dac.

Other methods exist to approach this, but everything on the 100MHz clock will operate the best.

An audio filter may be needed when going from the YM2149's 1.78Mhz sample rate to the 48KHz rate to prevent son weird tones, but this isn't a problem.

Our other choice is to run all the PSG at 54 MHz, with the same above code, to achieve decimal perfect clock dividers,

[nockieboy]

I'll help you out here if you setup a modelsim workbench with these 2 modules with a 100mhz source clock.
No pll, just the divider plus a means of entering a few test sound commands.

Okay, no worries, it might take me some time to set up as I'm still extremely inexperienced with Modelsim, but I'll see what I can get done.

Then we will worry about the precision reference 1.78 mhz needed for it internal tone generator from a 100MHz clock without a PLL as I have already created the fractional divider code in our HDMI serializer project.  In fact, that divider can be used multiple times to generate the second sample clock of 1.536/1.4112 MHz needed for the I2S sclk signal and it's shifter used for the 48/44.1khz sample rate of the HDMI audio and audio codec/dac.

Other methods exist to approach this, but everything on the 100MHz clock will operate the best.

An audio filter may be needed when going from the YM2149's 1.78Mhz sample rate to the 48KHz rate to prevent son weird tones, but this isn't a problem.

Our other choice is to run all the PSG at 54 MHz, with the same above code, to achieve decimal perfect clock dividers,

I just threw together a divider based on a 28-bit counter, so I fully expect you'll have a better solution up your sleeve.

[BrianHG]

I'll help you out here if you setup a modelsim workbench with these 2 modules with a 100mhz source clock.
No pll, just the divider plus a means of entering a few test sound commands.

Okay, no worries, it might take me some time to set up as I'm still extremely inexperienced with Modelsim, but I'll see what I can get done.

Then we will worry about the precision reference 1.78 mhz needed for it internal tone generator from a 100MHz clock without a PLL as I have already created the fractional divider code in our HDMI serializer project.  In fact, that divider can be used multiple times to generate the second sample clock of 1.536/1.4112 MHz needed for the I2S sclk signal and it's shifter used for the 48/44.1khz sample rate of the HDMI audio and audio codec/dac.

Other methods exist to approach this, but everything on the 100MHz clock will operate the best.

An audio filter may be needed when going from the YM2149's 1.78Mhz sample rate to the 48KHz rate to prevent son weird tones, but this isn't a problem.

Our other choice is to run all the PSG at 54 MHz, with the same above code, to achieve decimal perfect clock dividers,

I just threw together a divider based on a 28-bit counter, so I fully expect you'll have a better solution up your sleeve.

I have linked here : https://www.eevblog.com/forum/fpga/vhdl-code-to-verilog-code/msg4129318/#msg4129318

Begin by downloading the .zip I posted and editing the setup/run.do to have the new file names and rename/edit the _tb file wire together and feed your sound modules.  You will notice that in the setup_xxx.do files, there is a different compile command for the .vhd VS the .sv files.

Get a waveform on the display and then we will work from there.