EihiS

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
LATC=1;
will be compiled like ASM ( supposing there is no 'optimize' option as directive for the compiler ) :
MOVW 0;   // asm code
MOVF LATC;
MOVW 1;
MOVF LATC;
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 !

314159265358979323846264338327950288
419716939937510582097494459230781640
628620899862803482534211706798214808

December 14, 2012

Videopac C-52 : The SCART way ( R.G.B peritel Mod )

Filed under: Hobby Electronics — Tags: , , , , , , , , , , , — admin @ 4:39 pm

Inside the videopac c-52 ( bottom cover removed ) :

The VHF modulator is the board at the bottom of the picture.
It has to be replaced with a little electronic board, to convert the signals incoming from the main cpu ( the one at the center).

The RGB adapter board takes Red, Green, Blue , Composite synchronisation, Luminance, and BF (audio) signals from the CPU.

  • The composite sync signal has to be inverted before it can be sent to the TV set thru the scart (peritel) plug. To do so, we pick up the Vertical and Horizontal Sync signals on the pcb (they are allready inverted at that particular points) then use a classic diode based OR gate.
  • R,G,B and sound signals have to be lowered before getting into the scart.
  • RGB signals, also, have to be mixed with the luminance signal, to get the correct RGB levels at the peritel’s intputs (in the right proportions ).Depending on the combination of said color signal added to the luminance signal , the RGB output voltage will have the following values : 0mv, 200mv, 400mv , 600 mv (approximatively)
  • The RGB signals have to be blanked during the Horizontal blank and Vertical Blank time.
    That point is important ::
    The front porch/back porch for lines is necessary. If the RGB signal is not correctly blanked, the TV set will not show permanently coloured lines ( for example, a blue background of a game ).
  • Pin 8 of the scart can be left ‘floating’, but if you want your TV set to automaticaly switch to the scart, you ‘ll have to put a 12V to that pin. (Unfortunatly, it’s not present at the pins on the edge of the CPU board. Only 5V is available there.) So you will have to turn your TV to ’scart’ mode manually with the remote, or add a diode-pump doubler electronic assembly ( for example you could use the line sync as the working clock for it …)
  • Pin 16 of the scart must be set to the correct voltage to switch the TV to RGB input instead of Composite Video input .
    If  pin 16 is driven between 1 and 3V , the TV set will switch to RGB input. (good )
    If pin 16 is lower than 1V , the TV set will switch to Composite Video Input (bad)
    ->> We have 5V coming from the videopac’s CPU board, then a simple Resistor bridge will be sufficient to lower that input voltage to ~3V .
  • For the audio part, a resistor bridge (divider) is enough to lower the level of the Audio coming from the CPU board then feed it into pins 2 and 6 of the SCART plug ( left + right will play the same MONO signal coming from the videopac ), while pin4 (audio ground) can be joined to the other ground pins.

All scart’s pin name terminated with ‘ground’ can be joined to a common ground, connected to the ground of the Videopac’s CPU board , allthough in about all TV sets, that pins are tied together inside the TV, at pcb level.

Now, here is the schematic  of the C-52’s CPU board, viewed from solder side (bottom cover removed).
I have added important signal’s names for the CPU on this figure.

Now, for information, the SCART plug pinout ( VGA pinout here for comparison ) ( french named PERITEL )

The RGB adapter can be built on a prototype PCB. that’s what i did to create a correct electronic adapter from scratch. Here is how mine looks : (yes, it looks ugly with some components out, but that was a prototype, remember ! )

That module fits in to the bottom left of the videopac, right in place of the removed uhf modulator :


And finally, the result you get : the RGB adapter @ work . (the moire is not visible, actually. it’s just a photo shoot artefact ). The Colours are vivid and fine ! let’s play…


Following a request , here is the .PDF file of the schematic :
Hope this will help you into moding the Videopac: rgb_videopac_c52_adapter-78v (pdf)

  • Notice : IC4 ( U4:A on the schematic ) , on my pcb version, was replaced by a 2 x 1n4148 diodes based OR gate, so the final circuit has only 2 TTL IC on it, and VSYNC/HSYNC signals are taken from IC669 instead of IC652 , as you can see on the picture of the cpu’s bottom pcb.
  • Also, IC652-pin27’s connection (sound) is directly available at P6-3, as you may have noticed.
Finally, here is a partial schematic , extracted from the JET25 service manual. the pcb/IC , as i can judge, is similar to the one on the C-52.It may help you understanding the how-why of the SCART adapter described on this website.

————————————

314159265358979323846264338327950288
419716939937510582097494459230781640
628620899862803482534211706798214808

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