31.77 ms - binary counter

Other Hardware General Electronics
1

Hi,

Im doing a project where 3bit color-data stored in SRAM should be "projected" (so to speak) onto a VGA screen. At the moment, the project has been built in such a way, that the SRAM will get hit on the address-pins by a binary counter - and the SRAM output directly to VGA through resistors. At first, it was meant to be the arduino hitting the SRAM address pins, however, 31.77 ms for 800 pixels, whereof 640 has to be unique data, is just too much for the little bugger.

So, the idea is to let a counter do the actual hard work of hitting the SRAM, controlled line by line, by the Arduino - which then only has to react 60hz * 525horizontal lines = 31,500 times every second - each time resetting the counter, and activating another SRAM hi-address pin.

I have been planning to work with the 74HC4060, but I have no idea how to use it to tick 800 times over a period of 31.77ms. Is it correctly understood, that it requires a ticker, at around 800/31.77 = 25.180988 MHz (wikipedia says 25.175MHz) ? And if so, how to I achieve this.

Can I achieve the same frequency in any other way than a crystal with these specs (my local hw-store doesn't have either in stock). Alternative IC modules other than 74HC4060 is also an option ! Im open for suggestions

2

If you need a reference frequency that accurate, you need a crystal. They're like 30 cents.

http://www.digikey.com/product-search/en/crystals-and-oscillators/crystals/852333?k=25.175mhz

However, you'll need a lot more than that to do what you want here.

3

Hello DrAzzy,

Yes thank you.. the 30 cent crystal is not the first thing I buy for this project - I have everything else, except the crystal.

I have no problem googling online shops with a 25.175mhz frequency. As I noted, my local hw-store doesn't have one in stock. As i wrote, can I achieve the same frequency in any other way than a crystal with these specs? Alternative modules and/or clocks.

4

Are you building a graphics card?

I did many of these back in the 70s. You need a digital time base. Start off with an oscillator and divid it down with a counter to give you the line sync pulses, then divide that down to give you the frame sync pulses. You will also need to tap into that counter chain to derive the blanking signals as well, those are the front and back porches.
You also need inverted line sync pulses for a duration of the frame sync pulse.
I found you could use a free running oscillator for the master clock, no need for a crystal as the monitors could lock onto a range of frequencies.

5

PLL. 4046 may be fine down to 1k accuracy, if you are suing UNO than divider /4 necessary.
Si5351 is excellent replacement

6

Grumpy_Mike:
Are you building a graphics card?

Yes. Its working atm with just the Arduino - however the resolution is horrible; even using very few cycles per pixel, the arduino cannot change output fast enough. I have also managed to place the SRAM between the arduino and vga, using the Arduino to trigger the correct data from the SRAM. The Uno from stock is 16mhz, an innerloop for outputting nothing but an address to the SRAM is a minimum of 4 cycles/address for up to 256 addresses. Thats 1024 cycles squeezed into 25.17micros of active video signal - in that time we only have just about 402 cycles available from the Arduino's 16mhz core.

Grumpy_Mike:
I did many of these back in the 70s. You need a digital time base.

This is the crystal I was thinking about.

Grumpy_Mike:
Start off with an oscillator and divid it down with a counter to give you the line sync pulses, then divide that down to give you the frame sync pulses. You will also need to tap into that counter chain to derive the blanking signals as well, those are the front and back porches.

I was thinking first to actually just rely on the Arduino to begin with, and making that control more or less all the vertical line sync begins of the clock, for a less automatic VGA card (I like to have code to play with - when its physical possible to actually code anything..)

I have read about this divine down; can you explain a bit how that works ? It this something one does to secure stability in the timer, at the cost of less frequency (like, using a 50mhz with 60ppm in accuracy, dividing it by 2 somehow, to reach a more stable 25mhz ?)

Grumpy_Mike:
You also need inverted line sync pulses for a duration of the frame sync pulse.
I found you could use a free running oscillator for the master clock, no need for a crystal as the monitors could lock onto a range of frequencies.

I recall monitors in the mid-90ies blowing up when using some smart XVGA mode for 32kb colors - I recall this being a frequency problem. However, Im not using a mid-90ies monitor, so, its not really a problem :slight_smile:

So, basically, you are saying, that if I find a 26mhz oscillator, that will work as well ?

Thank you for your input ! much appreciated !

7

One technique I've played with for using a different microcontroller is driving SDRAM whose
databus outputs RGB bits for digital VGA.

However you need something that can drive the SDRAM control bus fast enough (~20MHz+). The
nice property of SDRAM is that you can use one instruction to initiate a complete horizontal scanline
since the read-burst auto-sequences successive addresses within one row until cancelled.

I actually used the video-output hardware in the Parallax Propeller microcontroller to drive the
SDRAM control and addressing pins, which allowed upto 40MHz operation in the end. That and
access to a hot-air rework station to desolder 54 pin SDRAM chips from DIMMMs!

8

This is the crystal I was thinking about.

Not quite. A digital time base is a chain of counters that produce the digital signals you need for the display.

You need several divide by N counter chains. Basically you use logic gates to detect that the counter has the required value on the outputs ( you only need look at the logic ones ) and then use the output to reset the counter back to zero. Here is an example:-
www.techlib.com/files/161divdr.pdf

It this something one does to secure stability in the timer, at the cost of less frequency

No the stability is the same as the source what you get is the frequency you want locked to a master clock. In this way the frame sync pulse is locked to the line sync pulse.

I recall monitors in the mid-90ies blowing up when using some smart XVGA mode for 32kb colors

That was because XVGA used different frequencies to the normal VGA. At best they were never going to lock.

I have also managed to place the SRAM between the arduino and vga,

What was done normally was to have the RAM connected to a parallel input / serial output shift register. The shift register was clocked by the master clock ( fastest ) and then the Arduino would only have to change the address at one eighth of this rate.
However, the whole point about a digital time base is that it provides the logic signals to address the memory. You then only need to switch that memory address to the Arduino when the Arduino needs to change the memory contents. This produces a visual glitch on the screen so it was common to do this change over only during frame sync pulses where it would not be seen.

You could also look at a chip known as dual ported RAM. This allows two sets of address lines to access the RAM at the same time, one from the time base reading things out and the other from the controlling micro, in this case the Arduino.

9

Grumpy_Mike:
Not quite. A digital time base is a chain of counters that produce the digital signals you need for the display.

You need several divide by N counter chains. Basically you use logic gates to detect that the counter has the required value on the outputs ( you only need look at the logic ones ) and then use the output to reset the counter back to zero. Here is an example:-

www.techlib.com/files/161divdr.pdf

Ah I see. But since I need a pixel clock of ~25mhz, wouldn't that require my master clock (the one sending the actual pulses), no matter what my devide-by-N is (N>1 ofc) to be at least N times faster than
~25mhz ? Maybe that RAM burst mode helps-I am not really that much into that yet. My idea was just very simple to have a counter, activate all "screen"-addresses of the SRAM, then the counter resets every frame sync.

But I presume i can get a 25mhz clock and then divide-by-N to get the vertical/horizontal syncs, right?

Grumpy_Mike:
No the stability is the same as the source what you get is the frequency you want locked to a master clock. In this way the frame sync pulse is locked to the line sync pulse.

Right - I think that was what i meant :slight_smile:

Grumpy_Mike:
That was because XVGA used different frequencies to the normal VGA. At best they were never going to lock.

Yearh at best.. thats an advice my old monitor could have used.. sigh.. that was as fine 14" CRT that was..

Grumpy_Mike:
What was done normally was to have the RAM connected to a parallel input / serial output shift register. The shift register was clocked by the master clock ( fastest ) and then the Arduino would only have to change the address at one eighth of this rate.

However, the whole point about a digital time base is that it provides the logic signals to address the memory. You then only need to switch that memory address to the Arduino when the Arduino needs to change the memory contents. This produces a visual glitch on the screen so it was common to do this change over only during frame sync pulses where it would not be seen.

Actually, my idea, because this is kinda a real problem I think, with the syncing of frames, was to have a double buffer, in SRAM. That is, one ram is Write-to-ram, one ram is Read-From-Ram. Clock pulses activates one piece of RAM sending data to VGA, while the arduino has ability to write to the other block of RAM. When a screen is done being written by the arduino the arduino waits for frame-sync is present (60 times a second, should happend more often than a complete screen write on the arduino), the READ and WRITE ram is swapped, and both processes can continue. This limits the framerate of the arduino. But to be honest, I dont see that as a problem - right now :slight_smile:

Grumpy_Mike:
You could also look at a chip known as dual ported RAM. This allows two sets of address lines to access the RAM at the same time, one from the time base reading things out and the other from the controlling micro, in this case the Arduino.

Yes I have, they are quite expensive (and less fun to work with, since.. they work). I decided to go the doublebuffer way instead. Also, I looked into RAMDACs for that extra layer of fine all-inclusive experience, but decided that I wanted to go another way. At the moment I am working towards applying palette with a 8bit addressable, 16 bit word SRAM block, in goes the color from SRAM, out goes the 16 bit RGB instead. However, I am yet to finde one of these >8bit adress, 16bit word, SRAM, where i can access it :slight_smile:

10

You might want to have a look at this final year project done by a couple of students at Cornell. They used an ATMEL MEGA 644 micro.

Russell.

11

russellz:
You might want to have a look at this final year project done by a couple of students at Cornell. They used an ATMEL MEGA 644 micro.

Thanks! Thats a very very good resource !

12

the READ and WRITE ram is swapped, and both processes can continue..........

You can do that but it requires twice the amount of memory for a given resolution.

I am yet to finde one of these >8bit adress, 16bit word, SRAM, where i can access it

You cascade smaller memories to get the size you want.

no matter what my devide-by-N is (N>1 ofc) to be at least N times faster than ~25mhz ?

No your pixel rate is not going to be faster than 25MHz ( not mhz )

Do some sums on what frequency clock rate you actually need.