FPGA VGA Controller for 8-bit computer

[nockieboy]

Okay, 12-bit DAC is up and running.  Well, aside from the additional outputs from the FPGA - there's no signals to put out yet, but it's ready to go when needed. 

[BrianHG]

Okay, 12-bit DAC is up and running.  Well, aside from the additional outputs from the FPGA - there's no signals to put out yet, but it's ready to go when needed. 

Ok, I've attached a 12bit color version + with a test RS232 debugger.

Select 2 IOs and use your FTDI TTL RS232 transceiver.
Use 115200 baud, 8N1.  No handshaking, no xon/xoff.  Full duplex.

Go into a terminal software and type.  Your typing should appear on the OSD, plus, it should also be echoed back to your terminal software.  Hitting the reset button will reset the invisible cursor to the home position.

If this works, I'll add the control commands and send you a small basic program with windows compiler which will allow you to read and write any memory addresses.  You can setup the Basic software read or dump files as well.

[SiliconWizard]

For the new year, I'm leaving electronic engineering and heading into management.

Congrats!
Get ready for a complete change in your daily activities, and learn to say "no", which is one of the hardest parts of management. (Another one is sometimes being "compressed" between the doers and the deciders. )

[asmi]

For the new year, I'm leaving electronic engineering and heading into management.  I'll never have time left to do electronic ever again.

It's going to be the complete opposite. Sitting your pants off in endless stupid meetings talking about stuff nobody cares about is what's the average manager's work day looks like in a large company. And pretending to be super-busy to his/her boss by sending insane amount of emails that few people read or even care about. So yeah - you'll probably have all the time in the world to think about (and maybe even read about) electronics during those meetings because a lot of them won't even be designed to be useful or productive. I know I had. And you will also have higher-quality spare time because if something in your systems breaks down during off-work time, you won't be the one rushing into the office/firing up your laptop and connecting to your office network and sitting there long past midnight trying to get things to work again.
Just remember one thing - talking about stuff never gets anything done, only doing does. So don't bring your engineers into meetings unless you're absolutely sure this is going to be that unicorn of a meeting where something relevant is going to be discussed and decided (the last part is super-important!).
I used to be a manager, but returned into engineering after I realized what that job was all about, and was bored to death in those meetings, which I now hate with passion and always demand a crystal-clear agenda before I even consider attending one. This does not apply to engineers-only meetings - they tend to be useful, but you won't be participating in them anymore.

[nockieboy]

Okay, have downloaded the latest project, put it in a new folder, compiled it, assigned pins to the 12-bit RGB output, clock, reset, hsync and vsync, and connected my USB-TTL lead to the board, connecting Tx and Rx and setting up the serial port in PuTTY according to your instructions.  Have not changed anything else.

Am getting this:



As you can see, what I'm typing in PuTTY is getting echoed back to the terminal (have tried it with Tx/Rx reversed on the board to make sure it's wired up correctly - obviously nothing comes back at all), but nothing is appearing on the screen.

I'm just hunting through the code to see if there's any obvious reason it's not working for me, but it's going to be something I've done wrong...

EDIT:  Also, just a thought, but isn't the output of the USB-TTL a 5v signal?  If that's the case, isn't there a chance I could be damaging the IO on the board?  (Note: I have only got the Rx/Tx and GND connected to the board - RTS and CTS are 'connected' to inactive (tri-stated) IO pins, as I don't want to pull the connector apart to isolate just Tx, Rx and GND, if that makes sense.

gpu_16K_RAM.mif wasn't included in the list of project files, but since I've added that it hasn't made any difference either.

[jhpadjustable]

EDIT:  Also, just a thought, but isn't the output of the USB-TTL a 5v signal?  If that's the case, isn't there a chance I could be damaging the IO on the board?

It's possible. It depends on the USB-to-serial adapter in your hand. Some might be switchable. Some might default to 3.3V. Some might be designed by someone for easy money who just doesn't care. The only way to know for sure is to check it with a meter.

(MAGGIE. I like that. Very Simpsons.  )

[nockieboy]

EDIT:  Also, just a thought, but isn't the output of the USB-TTL a 5v signal?  If that's the case, isn't there a chance I could be damaging the IO on the board?

It's possible. It depends on the USB-to-serial adapter in your hand. Some might be switchable. Some might default to 3.3V. Some might be designed by someone for easy money who just doesn't care. The only way to know for sure is to check it with a meter.

Yeah, it was more of a rhetorical question I guess; I knew the answer before I even wrote it.  I've stopped using the TTL-USB cable, will dig out a TTL-USB board from my box of bits - I know they have a jumper on them to set the voltage to 5v or 3v3.  Will look at trying that tomorrow.  Also, must stop 'writing out loud'... 

(MAGGIE. I like that. Very Simpsons.  )

Thought you would.    And getting the Simpsons reference as well. 

Now if we can name another module 'BART', we're on to something. Blitter And Raster Timer? If we integrate audio into the FPGA, that module will definitely be 'LISA'.  Linear Integrated Stereo Audio?

I'm open to better suggestions. 

[BrianHG]

Okay, have downloaded the latest project, put it in a new folder, compiled it, assigned pins to the 12-bit RGB output, clock, reset, hsync and vsync, and connected my USB-TTL lead to the board, connecting Tx and Rx and setting up the serial port in PuTTY according to your instructions.  Have not changed anything else.

Am getting this:

(Attachment Link)

As you can see, what I'm typing in PuTTY is getting echoed back to the terminal (have tried it with Tx/Rx reversed on the board to make sure it's wired up correctly - obviously nothing comes back at all), but nothing is appearing on the screen.

I'm just hunting through the code to see if there's any obvious reason it's not working for me, but it's going to be something I've done wrong...

EDIT:  Also, just a thought, but isn't the output of the USB-TTL a 5v signal?  If that's the case, isn't there a chance I could be damaging the IO on the board?  (Note: I have only got the Rx/Tx and GND connected to the board - RTS and CTS are 'connected' to inactive (tri-stated) IO pins, as I don't want to pull the connector apart to isolate just Tx, Rx and GND, if that makes sense.

Funny, with no rs232 text into the board, you should still have the original test text.  Your typing should overwrite the test text as you type.
If your echo is coming from the FPGA you didn't kill your FPGA since the echo of the text I made goes through IP code.
If you see your text still and your terminal software doesn't have local echo enabled, or half duplex enabled, this means my RS232 baud rate is correct and the UART, fifos, status flags are all 100% functional as all these need to work correctly to pass a character through.  It's just for some reason, at least 16k worth of writes somehow made it through the com port erasing your font and everything else.

Test #1, disconnect the 'host_wr_ena' like so:

This will stop the write and show the original text font test pattern.  Otherwise, something else went wrong.
Your color palette looks wrong.  Could be you need a pull-down resistors on the RGB, or decoupling caps as well, or the RGB ports are wired wrong.  Remember, R(3:0), not R(1:0).  Check your pin assignments as these may be assigned to the wrong pins.

gpu_16K_RAM.mif wasn't included in the list of project files, but since I've added that it hasn't made any difference either.

Yes, i just downloaded the 'GPU_12bitcolor_rs232debugger_test.zip' and checked.  The 'gpu_16K_RAM.mif' is in there.

Test #2, put back the 'host_wr_ena' and change this 1 line in my source code: (Line 56, rs232_DEBUGGER.v')

Code: [Select]

if (ena_rxd_dly) host_addr_reg   <= <= DEBUG_RST_ADR ; //host_addr_reg + 1;
This should stick any writes to cursor position 1, so, every key you hit should only show the new letter pressed at that 1 top left cursor position.  The letter should stay, not blink.  If this works, don't worry, my actual writes will be protected by a setup string preventing + a write enable lock which will be on by default during powerup.

[jhpadjustable]

Thought you would.    And getting the Simpsons reference as well. 

Now if we can name another module 'BART', we're on to something. Blitter And Raster Timer?

Block Area/Alpha Renderer/Rotator and Translator, depending on how far you want to push it.

If we integrate audio into the FPGA, that module will definitely be 'LISA'.  Linear Integrated Stereo Audio?

Paula and other simple sample engines transition instantly between one frame of the sample and the next. The decimation in the time domain and the loop ticks are audible, and may be undesirable (or not). We'll build NCOs, use phase accumulators to set playback rate (like SID), and use the fractional part to Linearly Interpolate between the previous and current value over the sample period. But that's for later. BrianHG appears to be on a deadline and I don't want to get in his way.

[BrianHG]

I've attached 2 dumb terminal programs.  Termite and Hexcom.
Note that in termite, I switched off local echo and append CL/LF in the transmit setting.
Try these guys.  I think Putty may be flushing the com port with junk and as my test software checks nothing at all, all it doe is dump incoming characters to adjacent memory addresses, Putty might have been a bad choice.


Hexcom, written by my friend, allows you to receive view and transmit both ascii and hexadecimal to RS-232 and a UDP port.

Termite is a third party software.

[BrianHG]

For the new year, I'm leaving electronic engineering and heading into management.  I'll never have time left to do electronic ever again.

It's going to be the complete opposite. Sitting your pants off in endless stupid meetings talking about stuff nobody cares about is what's the average manager's work day looks like in a large company. And pretending to be super-busy to his/her boss by sending insane amount of emails that few people read or even care about. So yeah - you'll probably have all the time in the world to think about (and maybe even read about) electronics during those meetings because a lot of them won't even be designed to be useful or productive. I know I had. And you will also have higher-quality spare time because if something in your system ;Ds breaks down during off-work time, you won't be the one rushing into the office/firing up your laptop and connecting to your office network and sitting there long past midnight trying to get things to work again.
Just remember one thing - talking about stuff never gets anything done, only doing does. So don't bring your engineers into meetings unless you're absolutely sure this is going to be that unicorn of a meeting where something relevant is going to be discussed and decided (the last part is super-important!).
I used to be a manager, but returned into engineering after I realized what that job was all about, and was bored to death in those meetings, which I now hate with passion and always demand a crystal-clear agenda before I even consider attending one. This does not apply to engineers-only meetings - they tend to be useful, but you won't be participating in them anymore.

I'm going to be at the top, with absolute authority & part owner of the new corp.  No one above me except my responsibilities to the investors.     I'm creating the 'agenda'.

[nockieboy]

Funny, with no rs232 text into the board, you should still have the original test text.  Your typing should overwrite the test text as you type.
If your echo is coming from the FPGA you didn't kill your FPGA since the echo of the text I made goes through IP code.
If you see your text still and your terminal software doesn't have local echo enabled, or half duplex enabled, this means my RS232 baud rate is correct and the UART, fifos, status flags are all 100% functional as all these need to work correctly to pass a character through.  It's just for some reason, at least 16k worth of writes somehow made it through the com port erasing your font and everything else.

Local echo is 'forced off' in the PuTTY settings.  There's definitely no text appearing on the screen, although it's being echoed back to the terminal.

Test #1, disconnect the 'host_wr_ena' like so:

This will stop the write and show the original text font test pattern.  Otherwise, something else went wrong.

.... no change.  I've been testing different USB-TTL adapters, trying it without one plugged in at all, checked all the connections to VGA 'ladder',

I've even loaded up the previous version of the GPU project and upped it to 4-bit RGB output, and it appears to be working fine:



... yes, the colours are out, but I can still see the text so something should be visible on the screen with the new project, especially if the serial port isn't connected.

Your color palette looks wrong.  Could be you need a pull-down resistors on the RGB, or decoupling caps as well, or the RGB ports are wired wrong.  Remember, R(3:0), not R(1:0).  Check your pin assignments as these may be assigned to the wrong pins.

Yes, they do.  I had arbitrarily wired up the resistor ladder and wasn't expecting perfect colours... I'm using something like 470R, 1.1K, 1.9K, 4K7 values - they were old resistors that I'd tested on my meter years ago and written the values on the sticker strips they were attached to (including the error margin on a couple of them by the looks of it!), but I'm not after colour perfection right now, just a visible output.  As I can see the text on the previous version of the GPU project, I'm more concerned about getting this new version working first.

If I'm going to be using this test bench for an extended length of time, I'll get a PCB made up with some 0802 resistors with proper values (or as close as) and make a proper VGA breakout board - for the moment, trusty breadboard is the medium of choice. 

Test #2, put back the 'host_wr_ena' and change this 1 line in my source code: (Line 56, rs232_DEBUGGER.v')

Code: [Select]

if (ena_rxd_dly) host_addr_reg   <= <= DEBUG_RST_ADR ; //host_addr_reg + 1;
This should stick any writes to cursor position 1, so, every key you hit should only show the new letter pressed at that 1 top left cursor position.  The letter should stay, not blink.  If this works, don't worry, my actual writes will be protected by a setup string preventing + a write enable lock which will be on by default during powerup.

Haven't tried this one yet as I've stalled on the first test.

[BrianHG]

For dac, all you need is 1 Kohm and 2Kohm resistors, good quality 1% or better.

For the MSB 3, tie 2x 1k in parallel, the equals 500Ohm.
For the bit    2, it's just a 1k.
For the bit    1, it's just a 2k.
For the LSB  0, it's 2 of the 2k in series, making 4k.

This makes an exact 0.5k, 1k, 2k, 4k resistor dac.

Make sure you removed tho old 1k resistors.  You cannot use different outputs across different IO banks as each bank has different clock delay and even different current ratings for the IO pins.

[BrianHG]

Here, test this one.  you should see the original debug text plus some echoing characters on PUTTY.

type this exactly, match my case (or copy and paste):

Code: [Select]

WRI!These 34 letters should displayed.
If that worked then send this:

Code: [Select]

REA!
Your terminal should receive the next 34 characters which are already on the display after my text message.

If it works, I'll sen you the 4 different arguments and how they work, or let me know, I'll find/remake my old basic development utility which handles the com.

Setting the read/write address requires binary numbers, I just made these commands ascii compatible.

[asmi]

I'm going to be at the top, with absolute authority & part owner of the new corp.  No one above me except my responsibilities to the investors.     I'm creating the 'agenda'.

Ah, startup, I see. Good luck!

[SiliconWizard]

I'm going to be at the top, with absolute authority & part owner of the new corp.  No one above me except my responsibilities to the investors.     I'm creating the 'agenda'.

Oh, you won't be plagued with the problems common for middle-managers then.
Just keep in mind that the investors may/will be deciders at some point (it's always rosy at the beginning). But enjoy the ride and good luck!

[nockieboy]

I've reversed the RGB connection order and, with the new project, am now getting the text display as previously:

Here, test this one.  you should see the original debug text plus some echoing characters on PUTTY.

type this exactly, match my case (or copy and paste):

Code: [Select]

WRI!These 34 letters should displayed.

Okay, here's the result of pasting

Code: [Select]

WRI!These 34 letters should displayed. into the terminal:

In the terminal, I get:

Code: [Select]

WRI!▒▒e 34@▒ett▒▒s should ▒▒splayed.
On the screen, I get:



It's trying to work - seems like a timing problem?  I've just double-checked PuTTY's settings:

115200, 8N1, Flow control: None

If that worked then send this:

Code: [Select]

REA!
Your terminal should receive the next 34 characters which are already on the display after my text message.

That's more or less what happens, but the text is slightly corrupted.  I received one string with no errors out of about 5 attempts.

If it works, I'll sen you the 4 different arguments and how they work, or let me know, I'll find/remake my old basic development utility which handles the com.

Setting the read/write address requires binary numbers, I just made these commands ascii compatible.

Ah!    Looks like you've made a mistake on altpll0 in the project - you've got a clock source of 54 MHz??  My board is 50 MHz, so that'll throw the baud rate out enough to cause the glitches I'm seeing. Not sure how the display is okay - probably just within tolerances, I guess?

EDIT:

Yep, it's the baud rate that's the problem - I've upped UART_BAUD to 1088 (how does this relate to the clock speed?) in rs232_debugger, and am now getting almost 100% integrity on the Tx/Rx console contents:

[nockieboy]

Further to my last - have gone back to the GPU_test project and changed the PLL settings for a 50 MHz source clock, updated UART_BAUD to 1090 (serial seems 100% stable now) and have re-ordered the RGB outputs.  Am now able to write to the GPU RAM:

[BrianHG]

I've reversed the RGB connection order and, with the new project, am now getting the text display as previously:

So, blank text had nothing to do with my code....

Ok, the clk54 shouldn't be a problem as Altera allows huge play on the PLL.  I know you have a 50Mhz clock source and I said 54 in the PLL settings.  All that the FPGA is concerned is that what is coming in will be multiplied by 5 then divided by 2.  And it will do it with a clock anywhere between something like 40 and 65 Mhz with the settings I have made.  The '54' mhz is just so when you compile, Quartus will make sure the project is fast enough for 480p HDMI with audio which would have a 54MHz clock source.

However, yes, the 'baud' might need to be slowed down.  It's a period number.  IE:
Frequency / baudrate.  So, (125000000 / 115200)-1 = 1084. 

What number did I have?  Raising the baud number actually slightly slows down the baud rate.
-----------------------
Just checked, there was a bit of it which was hard wired for 27Mhz, and Im running it at 125Mhz in this project....  I'll patch it in the next release.
-------------------------

Note that the UART I used was a home-made 15 year old thing.  In the next update I'm giving you, I'm running the UART debugger section at 50Mhz instead of the 125MHz graphics clock, it was originally designed and used at 27Mhz.


I'm almost finished the PC software, an onscreen - keyboard & mouse point and click memory viewer/editor for the GPU.  It has hex view with ascii, binary, 8 & 16 bit decimal view and entry.  Load/Save memory blocks to binary files.  However, without a GPU, I cant test locally.  Will you be around tomorrow for testing?

With this out of the way, working on the raster memory pointer generator & with this tool, manipulating and testing both display controls and image data in real time will be easy.

[nockieboy]

I've reversed the RGB connection order and, with the new project, am now getting the text display as previously:

So, blank text had nothing to do with my code....

Well I didn't think the RGB order was an issue, as I tested the previous version of the project and it was showing the text just fine (albeit a little off-colour!) 

Ok, the clk54 shouldn't be a problem as Altera allows huge play on the PLL.  I know you have a 50Mhz clock source and I said 54 in the PLL settings.  All that the FPGA is concerned is that what is coming in will be multiplied by 5 then divided by 2.  And it will do it with a clock anywhere between something like 40 and 65 Mhz with the settings I have made.  The '54' mhz is just so when you compile, Quartus will make sure the project is fast enough for 480p HDMI with audio which would have a 54MHz clock source.

Ah, fair enough - well, remember I don't have years of experience with this stuff.  I was just pleased that I'd managed to fix the issue. 

However, yes, the 'baud' might need to be slowed down.  It's a period number.  IE:
Frequency / baudrate.  So, (125000000 / 115200)-1 = 1084.

What number did I have?  Raising the baud number actually slightly slows down the baud rate.

You had 1084 - I had to up it to 1090 to get a stable interface.

-----------------------
Just checked, there was a bit of it which was hard wired for 27Mhz, and Im running it at 125Mhz in this project....  I'll patch it in the next release.
-------------------------

No worries, I'll know what to do if we have the same problem again.

I'm almost finished the PC software, an onscreen - keyboard & mouse point and click memory viewer/editor for the GPU.  It has hex view with ascii, binary, 8 & 16 bit decimal view and entry.  Load/Save memory blocks to binary files.  However, without a GPU, I cant test locally.  Will you be around tomorrow for testing?

Jeez BrianHG, you've been busy!!    Yes, I'll try to be around as much as possible.  Will get up early and see what we can get done - though I've got Christmas shopping duties with the missus at some point, I'll try to keep the morning as clear as possible.    Out of interest, what are you using to write the PC software?

With this out of the way, working on the raster memory pointer generator & with this tool, manipulating and testing both display controls and image data in real time will be easy.

The serial interface is a pretty big thing for me - but I'm really excited about the next steps as well.  I'm going to keep thanking you constantly for all this help and support - seems Christmas has come early! 

[BrianHG]

Ok, I patched the UART's true baud problem.  I'm also now running the RS232 debugger at 50Mhz instead of 125Mhz.  This means the baud setting is (50000000/115200)-1 = 433.

I turned off the local echo of commands, so you wont see anything in putty unless you copy&paste the

Code: [Select]

REA!
Or, to print text on the screen, use the:

Code: [Select]

WRIaThis should work without issue.  I know it's taken much time and hassle, but, we will get there...
What time will you be available tomorrow?
Because the Basic software will need testing, we may need to use 'teamviewer' to debug it.

[BrianHG]

Preview of GPUtalk.exe.
It's a Win64 application.
Just hit enter when it asks for a com number.
It will work without any GPU connected.
It's a work in progress.

Just need entry, com, and load/save and it will be ready.

[nockieboy]

Preview of GPUtalk.exe.
It's a Win64 application.
Just hit enter when it asks for a com number.
It will work without any GPU connected.
It's a work in progress.

Just need entry, com, and load/save and it will be ready.

It seems to be reading memory, or at least the sample data?

[BrianHG]

Here we go with the text version.  I've attached the QuartusProject with a version which is compatible with the GPUtalk utility.

The GPUtalk utility for now only copies, displays and edits memory realtime from the GPU.  If it works ok, I'll add the bulk copy routines and fix up the load and save as they currently self erase.

@nockieboy, we will probably need to TeamView for me to certify the GPUtalk and program fixes.
Let me know when you want to hookup.

To make thing as fast as possible, I would recommend installing 'Freebasic' from here:
https://www.freebasic.net/

[BrianHG]

Ooops,a typo in the GUPtalk, I wasn't setting the read/write address correctly.

Here you go:
I've included a 115200 version in the zip just in case.  Well sort it out when we teamview.