July 9, 2013

microNitel : A homebrew video card for your PIC projects (and others)

Filed under: PIC progs and schematics — Tags: , , , , , , — admin @ 7:46 am

This article in in writing progress.

I’m going to explain the basic idea and principles of a home-made simple video card.
Many old VGA cards coming from old PCs are available, but it’s always painfull to get something of that devices, because it’s originally designed to be used on a PC bus , which has complicated protocols for read/write accesses, and specific clock frequencies for the timing side.
I came across the idea of designing a simple video adapter for my electronic projects because there is almost no simple hardware anywhere, to generate rather ‘good’ quality graphics on a tv set like screen, or even on a PC monitor.

Because i’m living in France, i choosed for this project, to try re-using a Minitel-1 video screen.
The minitel-1 is not anymore used here, in france, and one can find many of that device for a very low price here.
But this project’s hardware and explanations can be used to get video image for many other screens, once adapted to the correct timings, specific to the screen you are going to use.

So, let’s talk of the Minitel-1 video :

Inside the Minitel, one finds 2 boards :

The minitel-1 CPU board

The minitel-1 CPU board : Thats the board wich is removed and replaced by the Nitel Hardware

The minitel-1 video board

The minitel-1 video board ( top ) with the CRT

The first one is dedicated to the power supplies, and all ‘hi voltage’ things : THT generation, vertical and horizontal deviation for the CRT , synchronization , electron-beam focus and brightness modulation and so on.

The second board,the CPU board, onto wich is connected the keyboard, is a micro-computer based on a 8052AH microcontroller, in conjonction with a 4168C static ram and an EF9345 video controller.This board is removed from the minitel and replaced by this project’s , pic18F4520 based board.

A carefull reading of the EF9345 datasheet, combinated with some real-life measurements on the minitel-1 powered-on, reveals that the EF9345 is sending the video signal to the video board in a non-interlaced mode.

This non-interlaced mode video signal is composed of :

  1. The video signal : inverted logic, 0 to 5V amplitude. ( 5V=dark level, 0V=full brightness )
  2. The separate sync. signal ( 0 or 5V amplitude ) : A mix of the vertical and horizontal syncs, with :
    - horizontal line : 64us length , inverted logic ( the pulse is active low, 4.5us )
    - vertical sync : each 310 lines, the vertical sync pulse takes 2 lines more , inverted logic
You better take a look at the datasheet’s chronograms : ef9345_video_generator_datasheet (.PDF file 559Ko )

So :

To use the minitel-1 video screen display board, we need to generate a video picture wich has 312 lines of height, and a 64us horizontal line timing.
I’ll keep the non-interlaced mode for my project.
maybe later i’ll take a closer look at the minitel-1’s video board to check if it’s able to support interlaced frames, or not, but the 9″ size of this CRT is small enough to generate non-interlaced video without annoying flickering of the picture.

Because this article is in writing progress, let’s take a look at a ‘teaser’ video :
This is a small footage of this project’s homemade video card @ work.
The image displayed on the minitel-1 CRT is one generated by my video-card.
My project’s video RAM has a double buffer. in this demonstration and test program running on the video card, each time the little ’sprite’ is hitting the right or left of the screen, the video buffer displayed is swapped, alternating between a blank(dark) background (video frame buffer 2 ) and a background with some test characters and picture on it (the frame buffer 1 ) .
All the video signal is generated by a pic18F4520 running at 40MHz with some additional hardware ( external static video RAM ).
Notice that the  PIC18F is generating the video signal + hsync&vsync signals and in the available time is also able to move the sprite and update it’s display position.
In the actual design’s step, the PIC18F has about 4ms ‘free-time’ to do “additional jobs” in addition to the time needed to generate the picture’s videosignal datas.
The video signal generated is monochrome, 1bit signal. resolution is 480×312 , with about 400×256 ‘useable’ (inside the viewable frame) user display.
A character generator is embedded into the PIC18 to generate the texts, based on the ASCII standard.

july 9, continued :
Here is the schematic of the hardware used for the demo video (NITEL , V1.0) :

The power supply pins are not visible to simplify the view.
Notice how many external components the hardware needs : only the static RAM, and some resistors.
This version of the hardware, the simpliest ever, has the drawback to let only a few pins available for I/O or communication with the outer world.( i’ll talk about another , with more free pins, later ).
The oscillator is a 40MHz clock generator (Golledge - like , pin format is like a DIL14 ).

Now, another video movie , demonstrating that this hardware can display up to 10 numbers composed of 5 chars each, in the 4ms time available between each picture frame generation :

Now, some theory of operation, and explanations about the hardware used :
Each of the 312 lines are generated by software.
Because the active lines are 256 , the pic18 has free time to do additional job , like updating the video ram datas for example, to display changing numbers, moving graphics and so on.
The hard part of the programming job here, is to get all the things running in exact time. for a video monitor (CRT) and, moreover, for a LCD monitor, timing must be EXACTLY into the specs, else you get garbage on the displayed picture, or even no display at all.

Each line is 64us long. Each line has a horizontal sync pulse of 4.5us, and each line has a front-pulse, back-pulse blanking time that must be in the specs. the front and back pulse blankings are used by the video board to hide the CRT’s electron beam’s return path (to the next line), and frequency synchronization time, from one line to the next other.

during the display time of the line, the program sets up the corresponding Y adress on PORTD and X adress on PORT C bits 0..4 (+bit5 for the page),  for the data to be displayed.
Each byte of the RAM represents 8 pixels, in monochrome format.
So, a complete line could be, at maximum : 2^6 x 8 = 64 x8 bits) = 512 pixels .
Another bit (PORTC,5), called ‘PAGE’ is also used : it enables to select the line from 2 possible buffer. this allows that hardware to have a mechanism like double buffering : One can write into the hidden video ram while the other page, the visible one, is displayed.
using that mechanism in software, its possible to update large parts of pictures, taking more than 20ms to be done, without bad flickering of the displayed picture : until the next picture is completly updated, the displayed picture remains on the previous ‘complete and clean’ frame buffer.
Googling for that will help you understand that basics, if needed.

Once the correct adress has been set up,
the video ram byte is then read on PORTB, and immediatly shifted out ( video_shift_output Pin ), by using the internal shift register of the PIC18F4520 that’s usually devoted to slave serial TX/RX .
The shift rate of this internal register is depending on the clock speed that’s present at the PORTC,Bit6 pin (wich is the serial slave clock in pin ).

I’ve used the main OSC freq divided by 4, to clock it up, just connecting the PORTA,6 (fosc/4 out) to PORTC,6. ( 40Mhz / 4 = 10MHz Pixel clock = 1.25MHz Byte clock. )
This computations allows a theoretical 640 pixels line , if the line time is 64us.

In C code speaking, a line can be displayed using that portion of code :
supposing that LATC initial value was Zero ( first column) : LATC++;TXREG=PORTB;asm nop;asm nop;asm nop;asm nop; LATC++;TXREG=PORTB;asm nop;asm nop;asm nop;asm nop; .. and so on until the 60th col has been reached

Practicaly speaking, the line can’t be composed of 640 pixels, because in the 64us time is included the sync pulse time (4.5us) and the front/back pulse blanking times. thats the reason why the RAM line len is 512 pixels maximum.

Practice of this hardware on the Minitel-1 CRT has shown that only the bytes 0 to 60 can be used ( even if 64 accessible bytes are available in ram )

When coding C for that kind of hardware job, its often necessary to switch to ASM code, because timing is critical.
the asm NOP is usefull to keep the timings as precise as 100ns exactly when needed (and it IS needed ).
Looking at the asm code generated by the C compiler is a must do, if you dont want to have unexpected results once compiled.
For example, doing

LATC=0; // c code
will be compiled like ASM ( supposing there is no 'optimize' option as directive for the compiler ) :
MOVW 0;   // asm code
this set of instruction, compiled like this, will take 4 cycles to execute. It could have been written directly in ASM like this :
CLRF LATC; // asm code for 'clear file'
INCF LATC; // asm code for 'increment file'
Wich will take only 2 cycles to execute, and do the same. ASM rules :D ...

Now, lets take a look at the front and back porch blanking.
This time lapses are very important for CRT electron beam. if that 2 blankings are not correct, you can have your picture damaged when displayed.

Here is a real-life exemple of a bad blank timing :
This is the picture with the problem : the right and left part are the same : a grayscale , from total black to full white brightness (with some additional graphics, but we dont care for that )
As you can see, on the left part of the picture, the dark side of the grayscale is not dark enough. in fact, while the electron beam is getting back to the start of the line, it’s not blanked for sufficient time. this lack of blanking generates the ”whitey’ cloud on the left of the screen :

Now, here is the scope capture of the signals :

Top : SYNC signal, Bottom trace : VIDEO SIGNAL

Top : SYNC signal, Bottom trace : VIDEO SIGNAL

The video signal of the minitel’s video board is inverted. thats why, when ‘blanked’, it has to get ‘high’ (5V).
Notice what happends during the sync pulse : the video signal gets right after the end of the pulse to a low level, wich is ‘bright white’ level, for the minitel. But thats the reason of the problem : after the sync pulse, the ‘back porch’ blanking is not executed, creating the ‘whitey’ artifact, on the screen.

Now, you can check the difference with this 2 new pictures :

Now the grayscales are fine for each sides of the screen

Now the grayscales are fine for each sides of the screen

and here , one can see the blanking signal after the SYNC pulse

and here , one can see the blanking signal after the SYNC pulse

If you have looked carefully at the scope’s traces, you have noticed that the video signal looks like analogic.
And you’re right.

That scope traces come from the hardware version ‘2.0′.
If you understood the theory of operation of the v1.0, then you’ll understand most of the hardware V2.0 schematic.

For now, its a prototype, i’m working on these days…
Here is the schematic of that new circuit :

Take a look at that movie and check by yourself ..

after some adjustements , the full capabilities of this hardware version is now visible...

after some adjustements , the full capabilities of this hardware version 2.0 is now visible...

to be continued..

Stay tuned for more theory coming soon :D !

No Comments

No comments yet.

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.


cat{ } { post_373 } { } 2009-2015 EIhIS Powered by WordPress