Page 1 of 4

The VGA Test Box

Posted: Mon Nov 12, 2007 10:21 pm
by ThePyroElectro
The VGA Test Box Project Write-up

The Test Box is a primitive VGA controller that uses a ┬ÁController and runs at
4 MHz. The ┬ÁController outputs VGA signals; the monitor receives them &
displays what is sent.

Questions & Comments?

Posted: Fri Mar 07, 2008 10:26 pm
by Mansor
if i changed 4 MHz to (20 MHz ) so as to make resolution bigger it will be 5 times faster than 4 MHz (0.2 micro second for each instruction )
but my question is how we can translate it in assemply language?
what are the differences in code?
thanx alot
Sender : Mansor

Posted: Sat Mar 08, 2008 1:01 am
by ThePyroElectro
Hi Mansor,

The change will be seen in the horizontal timing :idea:

Right now in the assembly code you see 25 'Point' or 'Blank' to show where color should be on the screen.


Code: Select all

   blank      ; 1 
   blank      ; 2 
   blank      ; 3 
   blank      ; 4   
   blank      ; 5 
   blank      ; 6 
   blank      ; 7   
   point      ; 8  *
   point      ; 9  *
   blank      ; 10
   blank      ; 11
   blank      ; 12
   blank      ; 13 
   blank      ; 14 
   point      ; 15 *
   point      ; 16 *
   blank      ; 17
   blank      ; 18
   blank      ; 19 
   blank      ; 20
   blank      ; 21
   blank      ; 22
   blank      ; 23
   blank      ; 24
   blank      ; 25 
   blank      ; 26   

   HSync               ; 27-29
   decfsz  tri9         ; 30
   goto    x9     ; 31

If you increase the clock speed from 4MHz to 20MHz (5x faster) you can now have 125 'Point' or 'Blank' statements across the screen which means 125 pixels.

So the code for this might look like the following example. I counted each instruction in microSeconds.

Code: Select all


   blank      ; 0.2 uS  --DATA--
   blank      ; 0.4 uS
   blank      ; 0.6 uS
   blank      ; 0.8 uS
   blank      ; 1   uS 
   blank      ; 1.2 uS 
   blank      ; 1.4 uS   
   point      ; 1.6 uS *
   point      ; 1.8 uS *
   blank      ; 2  uS
   blank      ; 2.2 uS
   blank      ; 2.4 uS
   blank      ; 2.6 uS
   blank      ; 2.8 uS
   point      ; 3  uS *
   point      ; 3.2 uS *
   blank      ; 3.4 uS
   blank      ; 3.6 uS
   blank      ; 3.8 uS 
   blank      ; 4  uS
   blank      ; 4.2 uS
   blank      ; 4.4 uS
   blank      ; 24.4 uS
   blank      ; 24.6 uS
   blank      ; 24.8 uS
   blank      ; 25  uS

   nop        ;  25.2 uS  --Blank Time #1--
   nop        ;  25.4 uS
   nop        ;  25.6 uS
   nop        ;  25.8 uS
   nop        ;  26  uS

   HSync     ; 26.2 uS -> 30  uS --HSYNC--

   nop                ;30.2 uS  --Blank Time #2--
   nop                ;30.4 uS
   nop                ;30.6 uS
   nop                ;30.8 uS
   decfsz  tri9     ;31.0 uS
   nop                ;31.2 uS
   nop                ;31.4 uS
   goto    x9        ; 31.6

The actual timing for the four different sections is as follows:
Horizontal Sync (HSYNC) - 3.77 uS
Blank Time #1 - 0.94 uS
Blank Time #2 - 1.89 uS
Data - 25.17 uS

You cannot achieve these times precisely with a 20MHz clock, but you can get close. That is why the system still works on CRT monitors. The optimal clock for this system is a 25.175 MHz clock.

Hope this helps. :D


Posted: Sat Mar 08, 2008 7:40 pm
by Mansor
Thnx too much MR.Chris
but what about vsync macro in 20 MHz?????

Posted: Sun Mar 09, 2008 5:15 am
by ThePyroElectro
The vertical sync will be the same as you see in the program. The only real difference will be each instruction with 4 MHz clock will become 5 instructions with 20 MHz clock.

So vertical timing for VGA goes as follows:

--Blank Time #1--
1.02 milliseconds

--Horizontal Data Time--
15.25 milliseconds

--Blank Time #2--
0.35 milliseconds

--Vertical Sync--
64 microseconds

Since 20 MHz executes 1 instruction every .2 microseconds you can create code to match these timing requirements exactly.

Let me know if you need any other help.

hello sir

Posted: Sun Mar 09, 2008 9:06 am
by Mansor
what about these instructions in 20MHZ
movlw D'240'
movwf TopCount
movwf BotCount
movlw D'6'
movwf LCount0
movwf LCount1
movwf LCount2
movwf LCount3
movwf LCount4
movwf LCount5
does each instruction replaced with 5 instructions?
do these instructions affect the vertical time?
thanx alot

Posted: Mon Mar 10, 2008 6:48 am
by ThePyroElectro
The code below will be part of the entire refresh cycle so you don't necessarily have to make it put 120 into those two variables (TopCount, BotCount) several times. You can just put a series of nop instructions or blank instructions. The important thing is that the blanking time (#1) (before the horizontal data time) is 1.02 milliseconds.

Code: Select all

   movlw   D'120'         ;Blank Upper and Lower 120 Lines
   movwf   TopCount
   movwf   BotCount

The following code is not from the program I wrote:

Code: Select all

movlw D'6'
movwf LCount0
movwf LCount1
movwf LCount2
movwf LCount3
movwf LCount4
movwf LCount5

I recognize it from somewhere but I'm not entirely sure how to help you there.

One thing is for sure, everything you do will affect the timing! This means you will need to count out instructions on your program to make sure everything is correct.

about VSync and Hsync

Posted: Mon Mar 10, 2008 9:07 pm
by Mansor
Hii mr chris
plz can you write to me the macros Vsync and Hsync in 20 MHz??? coz i tried to write them and there is no results

about Hsync and Vsync

Posted: Tue Mar 11, 2008 1:36 pm
by Mansor
How we can write Hsync and Vsync macros in 20 MHz? waiting your reply

Posted: Tue Mar 11, 2008 6:49 pm
by ThePyroElectro
The 4 MHz code you sent me for the Hsync macro:

Code: Select all

HSync:   macro
   bcf     PORTB, 3      ; horiz sync
   bsf     PORTB, 3      ; horiz sync

The macro call itself uses no instruction cycles. Inside the macro there are 5 instruction, each instruction takes 1 uS to execute. This means that the Hsync Macro takes a total 5 uS to execute.

For a 20 MHz clock we still need the macro to take 5 uS. To do this we'll need to modify the code and add more instructions.

Code: Select all

HSync:   macro;                       Begin Macro 0.0 uS
   bcf     PORTB, 3          ;0.2 uS horiz sync
   nop                       ;0.4 uS
   nop                       ;0.6 uS
   nop                       ;0.8 uS
   nop                       ;4.4 uS
   nop                       ;4.6 uS
   bsf     PORTB, 3          ;4.8 uS horiz sync
   endm                    ;End Macro 5.0 uS

With the code you sent me you cannot just plug this Hsync in and expect it to work. You need to add this 5 uS Hsync time into your total horizontal line timing to see if the total timing matches up to the specifics I told you earlier.

For the Vsync code the same methodology is applied:

Code: Select all

VSync:   macro
   bcf     PORTB, 4    ; vert sync;1
   call Delay10mkS
   call Delay10mkS
    call Delay10mkS
   call Delay10mkS

   ;upto 36 works

   bsf     PORTB, 4   ; vert sync//48

This macro uses a total of 48 uS with a 4MHz clock. In order to convert it for use with a 20 MHz clock instead of just 48 instructions, 48*5 = 240 instructions will need to be in the macro. It will look the same as the Hsync code but with many more delay statements. Perhaps you might think about modifying the Delay10mkS macro for use with the 20 MHz clock to simplify the code.

Again, just modifying these Sync macros will not make the code work, you have to go through your entire program and be sure that the timing matches up as close as possible to the specifications i said in my previous post, only then will it work.

Posted: Tue Mar 11, 2008 8:23 pm
by JuggaloStoopid
I am making a simular project based off the idea of your project and Rickard Gundee Tetris project. (For School)

I am making a VGA Etch-A-Sketch.

I am required to use the 16F877A chip. I am still in the concept stage. I am running into problems with how I could have screen memory. Since the chip only has 368 bytes. The teacher told me to look into the idea of having SRAM, but do you think that would mess up the sync.
One Idea I had was to have 1 pixel be 1 nibble of a register. (on/off,R,G,B) therefore I could cut the memory required in half. Since I only want one color at a time. But the chip still doesnt have enough memory to hold a screen, even if each pixel is 10*10. Do you have any ideas?

Another question I have is since the output has to be synced with the screen, where do I have time to mess with the input from the user and change the memory.

Posted: Wed Mar 12, 2008 10:49 pm
by ThePyroElectro
Hey JuggaloStoopid,

That's quite a task you've got :o but don't despair as it's definitely not an impossible one.

So I'll give you some high level approaches to how you can solve this problem:

First off, use the fastest crystal oscillator you can get for it that produces accurate timing (yea even the pic can be over clocked :P ), the datasheet says max of 20Mhz for cpu speed. I would start at that speed for a clock. The reason for this is that the more instruction cycles per vga refresh you can get the more you can do...the more freedom you have.

Next, I'm sure what you want to do is to store every single pixel in ram and then access (read/write) to it when you need it. This approach makes things much easier when you can do it. Depending on the resolution you desire to create this may or may not be possible for you using the pic's internal ram (368 bytes). The resolution you choose to use is really what will determine the difficulty of your project.

:arrow: Can you tell me what resolution your teacher wants the PIC to generate?

I'll be able to answer your other questions more accurately once I know the working resolution for your project.

:arrow: Just so I know your level of experience, how long have you been working with the pic microcontroller & programming?

Sounds like a cool project, be interested to hear your response.

Posted: Wed Mar 12, 2008 11:27 pm
by JuggaloStoopid
I have just learned assembly and been excelling in it this quarter of school. It has been very easy for me due to past experience with programming in Basic, Pascal, C, C++, then learned some other smaller languages.

The resolution don't matter at all. I just dont want to make each pixel too huge cause that will take away from the drawings that the user makes. I was originally going to make this work on a tv(320x240) until I saw your project.

By over clocking the chip, do you mean changing the oscillator frequency with caps? Or using an external oscillator chip?

Posted: Thu Mar 13, 2008 7:57 pm
by ThePyroElectro
Hi JuggaloStoopid,

Sounds good, the 16f877a only has 36 asm instructions and if you continue with this project you'll get very comfortable with them reguardless :) .

By overclocking the chip I do mean using an external clock. That is typically what I do in my projects(use an external crystal, not over-clock the pic), the internal clock is slow & has potential for creating various hazards. Not to say its terrible, just easier to use a $0.15 crytstal at 2x+ the speed =D.

So back to the problem at hand. My first suggestion to you is to get a very simple, very low resolution project working on vga and then move forward. This means developing code that executes within the timing parameters of vga. Then afterward worry about the input 'etcha-sketch' and better resolution

The picture on this page:
:arrow: ... eory2.html

Is probably the best reference you'll ever find for standard 640x480 timing. All the required times to meet are there.

To address your previous questions about when you'll have time to mess with memory access...The best time to stick this stuff from 'off-chip' ram onto your internal ram is during the blanking times. There are some pretty fast ram read/write devices that you can get. During Horizontal & Vertical Syncs with a 20MHz clock you also have time enough to load some registers, or stick stuff in internal ram. Granted not much time, but enough to get going.

The main problem during implemenation that you will run into will be getting a maximum horizontal resolution. So plan on something on the order of 200x200 or less.

I'm just spitting out a few tid bits here and there, feel free to point in a direction if you have a certain question. :wink:

please please please

Posted: Sun Mar 16, 2008 12:25 pm
by Mansor
Dear Chris
i tried too many times writing test codes for 20MHZ but no result ,please
can you write to me a test code for 20MHZ,thanks too much and waiting your reply.