Hello everyone! It is good to be back on the forums after taking a break.
I have added an external sram chip; 512Kx8 bit cmos sram,
product #: AS6C4008. I basically send out 16 bit address data to the sram from my PIC microcontroller and then the sram puts out vga pixel data.

I have a 64MHz clock but all instructions take 4 cycles due to pipe lining and so forth so I have instructions executing at 16Mhz. With that in mind I am sending address data to the sram at 16MHz. I have a Hsync of 31.5KHz so I should be getting about 16MHz/31.5KHz = 507 pixels per line. I have blanking periods included which take about 100 cycles so I basically change the address buffer 403 times exactly. This should mean that I get 403 pixels per line. In reality I have counted the number of pixel draws on my monitor and it comes out to 201 give or take 1 because I had to count them .

The sram seems to be giving the vga every other pixel. Why? Because I have put a marker pixel in the hline and it is where it should be but it is twice the width.

I appreciate any advice and no suggestion is a bad one, it is possible I am overlooking something simple. Thanks for the read.

 

Obviously you are only "send out 16 bit address data to the sram from my PIC microcontroller" at an 8MHz rate and not a 16MHz rate. If you run your code inside the MPLAB simulator you could see the two instructions being executed per each pixel time.

Otherwise you have provided no information about how you are driving the AS6C4008. No schematic, no PIC p/n, no code.

 

What? I am using the instruction incf PORTD and PORTD sends the address data for the sram.
I believe that should take only one instruction.

The pixel clock does not have low and a rising edge. It sends an analog signal of rgb values to the display and that gets displayed.

I am confused how you are getting 8MHz.

PIC 18F45K20.
I have attached the sram data sheet and im using the address controlled read cycle.

My code is a bit confusing so I didn't put it up so people wouldn't be overwhelmed with a lot of code.

 

What? I am using the instruction incf PORTD and PORTD sends the address data for the sram.
I believe that should take only one instruction.

It is true the INCF instruction takes 1 cycle. So if you clock out the addresses via some 400 plus INCF instructions then you are on the right track to get your rate.

I am confused how you are getting 8MHz.

Actually, you are confused over how you are getting 8MHz.
8MHz comes from your limited information. If I assume your H rate is correct and a line is filled with half as many characters as it should be then you are sending them at half the rate.

My code is a bit confusing so I didn't put it up so people wouldn't be overwhelmed with a lot of code.

No reasoned comment on code not presented is possible.

How do you get 400 states out of one port (8 lines = 256 states)?

Did you triple check the address lines are correctly wired? If you slipped up on A0 then your data rate would half.

Have you measured the instruction rate? Is the device truly running a 64MHz clock?

 

Hi Peter, good to see you are back. I had not thought of using an SRAM to store the video map. It did not strike me that someone would want to do this today.

Many years ago I built a graphics display doing exactly this, SRAM, memory address register, data shift register, HSYNC, VSYNC, etc. Today, of course, we would delegate that to a graphics controller chip.

I know there is a desire to do this with a PIC. I believe a PIC does not have the capability of doing this efficiently and effectively.

I am almost complete with a demo of my VGA system that I will show to you some time. I can take photos of it now but I wanted to add a few finishing touches. It does 520 x 480 graphics and text. My demo is a digital scope + spectrum analyzer in real time, all on one MCU chip - no external components.

 

1. I know the device is running at 64Mhz because i wouldnt get any output on the display if hsync or vsync were incorrect. Hsync and vsync are dependent upon the PIC clock obviously which is 64MHz.

2. I said in my first post that I was displaying every other pixel it seemed because my marker pixel was located where it should be. That lead me to check my A0 pin from your suggestion but that did not work.

3. I am displaying 400 different colors per line at this point by incrementing my second port A8-A15 when A0-A7 goes from 255-0. I know it is a sketchy fix and wont result in a good output but I did it just to start out.

4. I will attach my code but I am slightly embarrassed at how crappy I am at commenting assembly ie I do not do it at all.

 

Well, the bad news is I poked thru your code some, even got it to compile and run on the simulator. The INCF's are truly executing in 1 cycle, so that doesn't seem to be the problem. The config bits seem OK too, with FOSC using the HS oscillator and the 4x PLL enabled.

So I don't see anything wrong with the code either. That sure doesn't help.

Your concept seems sound, I can't explain why your pixels come out too slow.

One thing I would advise you is the way you handle the high bits of the address (incf PORTB) will result in a delay of data output for those bits that may well be visible as a horizontal line down your display. If you upgrade to a PIC24 or a PIC32 they come with a 16 bit Parallel Master Port (PMP) that can be updated in a single instruction. I've used a PIC32 at 80MHz clock which is also the instruction rate (they do it all in 1 cycle not 4) so it can actually runs faster then you need.

What you are doing should prove your concept and may well work just fine, I'm just mentioning this so you don't put a lot of work into a PIC chip you may want to change sometime.

(And I've seen much worse code, your is neatly laid out and commented for major functions.)

 

In this design each pixel takes 6.26E-8 sec = 62ns. Your SRAM address change time is 55ns. Minus about 3ns of the hold time. So, if the SRAM chip was working to the specs it will give you only 10ns of displaying time per pixel. The rest of the time it legally can output some garbage. Can you get a faster SRAM (12ns for example)?

I am working on a computer, which would have about the same display module design. I am using PIC24HJ128GP506 (kinda overkill) and AS7C4096A-12JCN SRAM. Hopefully it will work.

 

One more thing. I don't know why did you go with a double frequency mode. Maybe you had a reason. But a standard HSYNC rate for a PAL/SECAM is 25 FPS * 625 Lines = 15625 Hz. And for NTSC 30 FPS * 525 Lines = 15750 Hz. Or if you calculate for 2 interleaved frames then it is 60 half frames per second and 262.5 lines. Which gives you the same 15750 Hz (NTSC). So, if you output to a TV then you can slow down your controller 2 times.

 

Does this faster SRAM chip you speak of have the same writing and reading access methods? Another words as long as I keep my same code template and just adjust pin locations I could easily transition to this faster SRAM?