FPGA VGA Controller for 8-bit computer

[nockieboy]

... I can only attach one mp3 zip at a time due to their size... 

[nockieboy]

Last one.

[nockieboy]

Before making the .mp3, give this a try:

On the left and right channels, assuming that a volume of 64 is our 100% default reference...

Change channel B on the left and right to 90% volume.
Change channel A on the right to INVerted 80% volume.
Change channel C on the left to INVerted 80% volume.

Now give a listen, especially with headphones and compare to the default mono.

Pseudo (or actual) stereo? 

[BrianHG]

Pulse 2 is in actual surround stereo (usually just the accent instruments/voices), though a few large portions of it are mono since they are done using all channel B.  The effect works out good for that tune.  Just listen with headphones and it will be clear.  Pulse 1 is nothing but center mono.

Since there is so little bass, you might increase my BASS setting default of 3 to something like 8 or 16 at this will better center the waveform.  If you take a look at the waveforms in an audio editor, you will notice that a lot of it looks unbalanced 'high'.  Some of this is normal as some sound effects are tiny single vertical spikes and there isn't much we can do unless I re-write my filter specifically for those circumstances.

[BrianHG]

b) A 'legacy' Z80 port which would allow you to access the PSG the old way instead of the current direct access.  Yes, we can have both access methods running in parallel as you can use a group of 2 separate Z80 ports, one old, one new to do this.
...
For ' b) ', I need an example of a read/write sequence used to make this work for you.

Are you talking about a legacy YM2149 port, with BDIR and BC1 pins?  I've not changed any host code at all to access the PSG - the music I've been playing (and recorded as mp3s) are being played in a generic CP/M MYM/PT2/PT3 player - all I had to change was the IO port addresses for the PSG specific to my uCOM.  Bridgette already does the job of interfacing to the PSG module?

It was only an option for music players which you cannot edit the source code to use our current better direct access.  If you do not need it, then we do not bother.

Well, with 2 PSG in the system, you can now play one of these chiptunes in your home brew video games, while having a second PSG dedicated to sound effects with external mixer volume controls allowing channel placement and lower volume for the background music VS player sound effects.  LOL, we could probably throw in 2 Atari Pokeys, and 2 commodore SID chips as well giving you a total of 20 sound channels, with the compatibility of any 8 bit system sound out there.

[BrianHG]

Here is how to adjust your 'bass' settings.  Currently in 'PULSE2.mp3', this is what the middle of your sample looks like:


I want you to increase the 'BASS' setting until it is almost looks like this:


You wont hear a difference, but it is more natural for the audio equipment you will be feeding.
Overshooting what I illustrated above will begin to lower the volume of some of the lower frequency notes.
My guess is that it will be around 15-25.

[nockieboy]

Well, with 2 PSG in the system, you can now play one of these chiptunes in your home brew video games, while having a second PSG dedicated to sound effects with external mixer volume controls allowing channel placement and lower volume for the background music VS player sound effects.  LOL, we could probably throw in 2 Atari Pokeys, and 2 commodore SID chips as well giving you a total of 20 sound channels, with the compatibility of any 8 bit system sound out there.

Haha - don't tempt me with the SID chip!   It would be awesome to have one of those in the system, but I think it would create an awful lot of work for me writing software to use it that could read whatever format Commodore 64s (or their modern-day emulators) saved their music in.  Not impossible, though... 

I've adjusted the bass settings to 25 and got the waveform below for the same section of 'PULSE' that you've focused on:

[BrianHG]

That looks fine.
You are done.
I'll just clean up a line or 2 in the source HDL and update it tonight.
What else do you need?


I think the sid music players just had a table being sent to the sid addresses, using the system timer interrupts for delays for when to copy the next control bytes.

[nockieboy]

  

Now that the sound reproduction is so good, I've realised everything is too high pitched.  I've done some digging into schematics and old forums and found that the AY-3-8912 PSG in the Amstrad was clocked at 1Mhz, not 1.789MHz (which I think was what the Sinclair Spectrum was running at)...

So I've recompiled the project with the ARYA clock generator set to 1MHz, and the sound is just sublime.  Really takes me back. 

[nockieboy]

That looks fine.
You are done.
I'll just clean up a line or 2 in the source HDL and update it tonight.
What else do you need?

In terms of additional functionality, I just really need to get the USB keyboard working.  I've got a working hardware interface that uses a CH559 which I created and outputs keycodes on a serial interface, but I've not had any time to think about linking it up to the uCOM yet.  I've found a project for the DECA that implements a basic HID from the USB2GO port on the DECA board, but that uses a softcore CPU.  I really just want an easy way to plug a USB keyboard in and get keycodes out that the host can read via Bridgette in the GPU core.  I figure the CH559 is probably the cheapest and easiest route to go, but it involves an additional chip on the board.  Any thoughts?

The other thing that would be of immense use would be an FPU - either a general FP math unit or something geared towards matrix transformations for 3D graphics?  I know there's a couple of examples out there in HDL, think I saw at least one on OpenCores *shudder*, but haven't had time to look into them in any detail yet.  Again, any thoughts or advice would be appreciated.

Then there's the FPGA selection, PCB design and making a board.  That won't come for a while yet though, until the chip shortage really clears up.  I'm still waiting on an LFE5U-25F-6BG256C, which I ordered back in November 2021 and I think is due next month, so that I can have a go at designing a BGA-based FPGA dev board and have a go at soldering a BGA without busting the bank if it all goes horribly wrong.

The only other thing registering in my memory was something you mentioned ages ago when we were working on the GPU which sparked my interest - an instruction set for the GPU - but I think that was a big modification and upgrade to the GPU that would involve a lot of work.

I think the sid music players just had a table being sent to the sid addresses, using the system timer interrupts for delays for when to copy the next control bytes.

I'll take a look into them in a bit more detail when I get the chance - a friend had a C64 back in the day, but the odd rainy afternoon playing Booty was about as close as I got to the SID chip.

[BrianHG]

Ok, here we go.  This is the PSG system release.

Everything seems to work OK.
I changed the BASS default to 25.

One thing I didn't do was change the default Volume A-F to 85, which you may test to see if that works OK without generating distortion in the sound.  That level should generate a 'Full' volume 16bit audio.

All the documentation is in the header of the _tb.sv file.
Everything will simulate in Modelsim.

All the technical screenshots and specs begin here:
https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/msg4366420/#msg4366420

Let me know how it works.

[nockieboy]

That's working fine.  I haven't tested the volume change to 85 yet, but I'll add a comment to the repo about that.  Just setting it up now.

[nockieboy]

Github repo is up at https://github.com/nockieboy/YM2149_PSG_system/.

[BrianHG]

Github repo is up at https://github.com/nockieboy/YM2149_PSG_system/.

You need to fill in a relevant description.

Something like:
YM2149 / AY-3-8910 Programmable Sound Generator.  Offers Dual PSGs, programmable stereo mixer with bass and treble controls, standard I2S 44.1KHz or 48KHz 16 bit digital audio out, and built in floating system point clock divider / generator.

Add the tags - Verilog, System Verilog, Sound Generator, (and anything else you can think of...)

One think to change, in your 'Parameters and Ports':

Code: [Select]

   .CLK_IN_HZ       (    50000000 ),   // Input system clock frequency
   .CLK_I2S_IN_HZ   (   200000000 ),   // Input I2S clock frequency

and

   .clk             (      CLK_50m ),   // Master clock for interfacing with the PSG.
   .clk_i2s         (     CLK_200m ),  // Reference clock for the I2S generator's output.  Should be 148.5MHz or higher.
Also, in enhancements include:

Improved precision 8 thru 14 bit exponential DAC support. (10 bit almost exactly replicates the YM2149 normalized output voltage).

It actually only goes up to 12.  And I think maybe we should limit this to 10 as 12 will have super low volumes...

I would also add:
-  Included extensive Modelsim setup_xxx.do batch files and YM2149_PSG_system_tb_tb.sv which simulate multiple settings of the PSG and mixer with preset sounds to view the filter's effects and a  DAC ramp visualization to compare to the YM2149_dac_normalized_voltage.png.

[nockieboy]

Github readme updated.

[BrianHG]

Should add my short-form description to the right place, see:



When you do a Github search, this is what's shown along the project page's name in the search results.

[nockieboy]

Oh yes, forgot about that! D'oh! Sorted now.

[BrianHG]

Oh yes, forgot about that! D'oh! Sorted now.

[BrianHG]

Found a minor mistake in the your Github description:



It is not the 'include' you should be changing to switch which PSG system will be used.
It is here: YM2149_PSG_system_tb.sv Line 48.

Commenting in or out this line is the proper way to switch between our PSG system and the original jt49 one.


Also, no pinning of the project on your Git homepage?

Note that once again, include these comments:

  .clk             (      CLK_50m ),   // Master clock for interfacing with the PSG.
   .clk_i2s         (     CLK_200m ),  // Reference clock for the I2S generator's output.  Should be 148.5MHz or higher.

I would also add, if you want a 0 jitter for the clk_i2s, then you should use a source PLL generated clock which is 256x, or higher multiples thereof the source clock frequency.  This is the one case where you may use frequencies below 148.5MHz.

IE: if you want 48000khz I2S audio with no jitter, use 12.288 MHz, or 2x that, or 4x that, ect...

[nockieboy]

Found a minor mistake in the your Github description:

It is not the 'include' you should be changing to switch which PSG system will be used.
It is here: YM2149_PSG_system_tb.sv Line 48.

Commenting in or out this line is the proper way to switch between our PSG system and the original jt49 one.

Also, no pinning of the project on your Git homepage?

Note that once again, include these comments:

  .clk             (      CLK_50m ),   // Master clock for interfacing with the PSG.
   .clk_i2s         (     CLK_200m ),  // Reference clock for the I2S generator's output.  Should be 148.5MHz or higher.

Okay, all updated - and I've cleared up some of the code comments on the inputs/outputs.

I would also add, if you want a 0 jitter for the clk_i2s, then you should use a source PLL generated clock which is 256x, or higher multiples thereof the source clock frequency.  This is the one case where you may use frequencies below 148.5MHz.

IE: if you want 48000khz I2S audio with no jitter, use 12.288 MHz, or 2x that, or 4x that, ect...

Not sure I fully understand what you're going for here, so I've updated the README.md with hopefully the right interpretation of the above.  Check the last paragraph in the 'HDL project notes' section, just to make sure the meaning hasn't been lost.  Shouldn't it be zero jitter we want on the I2S output clock?

[BrianHG]

I would also add, if you want a 0 jitter for the clk_i2s, then you should use a source PLL generated clock which is 256x, or higher multiples thereof the source clock frequency.  This is the one case where you may use frequencies below 148.5MHz.

IE: if you want 48000khz I2S audio with no jitter, use 12.288 MHz, or 2x that, or 4x that, ect...

Not sure I fully understand what you're going for here, so I've updated the README.md with hopefully the right interpretation of the above.  Check the last paragraph in the 'HDL project notes' section, just to make sure the meaning hasn't been lost.  Shouldn't it be zero jitter we want on the I2S output clock?

When my floating-point clock divider divides by a fraction, to do so, it must occasionally add a single clk input cycle delay to it's output to synthesize this fractional divided clock.  This delay, which is the period length of 1 clk input, is a type of output jitter.

When supplying my clock divider's input with a clock where it only needs to divide by a perfect integer, there is no occasional single clk delays added to it's output, meaning 0 added jitter.

[nockieboy]

As far as one of my replies to your 'what's next?' question you posed some posts back, I've plucked an FPU example from Github and have tidied it up a bit (see attached zip file).

I was thinking the best way to insert it into the GPU project was to have it sit as an instantiated module in GPU_DECA_DDR3_top, with its inputs (A, B and opcode) linked directly to GPU RAM addresses in memory, so that the host could write two 32-bit floating-point numbers to the correct memory addresses, write the desired 2-bit opcode (to specify an add, subtract, multiply, divide operation), then read the result memory location for the 32-bit result.  No IO ports used, no additional ports or HDL in Bridgette, just a few memory writes and a read (or 4, to get the full 32-bit value) for the host.

Now it looks like the module is pretty quick - as far as I can tell, as long as A, B and OPCODE are valid then so is the result, which is pretty darn fast (to me, anyway).  If that's the case, then I don't see the need for an 'enable' or strobe to tell the module to calculate the result, might as well just leave it running, with its inputs and outputs constantly reading/writing to the chosen memory locations.  The exactly memory addresses would be specified by parameters in the top level HDL.  It's the constant reading/writing DDR3 memory that is causing me the most concern, though, hence this post.

Questions: 

• Is this module any good?
• Is this a viable proposition (the module interface)?
• Is this the best way to implement this module in the project?
• If so, how should I go about linking its inputs/output to fixed memory addresses via the DDR3 memory controller?
• What's the best way to limit memory bandwidth hogging? Should I give in and use an IO port to signal to the FPU to do a calculation?

[FenTiger]

constant reading/writing DDR3 memory

It'll need input and output registers in the FPGA anyway. Why not expose them to the Z80 directly?

[nockieboy]

constant reading/writing DDR3 memory

It'll need input and output registers in the FPGA anyway. Why not expose them to the Z80 directly?

Intercept memory RD/WRs to 98 bits of memory and map them to the registers instead of the DDR3 controller?  Now there's an idea - I like it. Thanks FenTiger!

[BrianHG]

The code you attached would be slow as molasses.
It only has 4 opcode.
It doesn't doe INT <> FP conversion for you.
It has no integer 32bit math.


I would begin by making an MMU blitter for the DDR3 first, then make that MMU support 32bit INT & FP math within.