The problem...

The SOCoCo-80 Project

The Problem

This is my first project status post. It’s a little awkward because the project has been moving slowly forward for quite some time. In an effort to catch the blogosphere up with what I’m doing, I will use this dilemma as a starting point.   I spent quite allot of time learning and understanding the video side of the project. I’ve written and re-written driver test code to get it working. The base of the code was in the form of the Altera DE-1 demo program that comes with the DE-1 package. Altera sent the source code and I studied it to nauseum.  I researched the VGA specification and used the Altera code to generate the signals up to 1600x1200. I first used code to generate the RGB signals to create a blank screen. I then started using the SRAM on board as my data source. This presented a problem.   For some reason, I was getting an offset of one pixel using the Altera modified code. It was driving me crazy for months. Again this is a project for fun so the total time I spent wasn’t that much. I couldn’t figure it out. I finally decided to abort using Altera’s code base. I really didn’t like the way it worked. It was written for a specific purpose which worked well but it just fell short for my project.   We moved on to a Finite State Machine. The code posted on this site was the result of the Finite State Machine conversion. During the development of this method, I found my missing bit. It actually wasn’t in the code at all. I downloaded some photos off the internet that were 640x480. I used Photoshop to convert them to BMP indexed color files. Using a custom palette, I saved these files out and removed the BMP header data. This left just the color information. Unfortunately, I miscounted the number of BMP metadata by one byte. Eureka!!! There’s that stupid 1 pixel I was going crazy over. The original code worked all along. No matter, my code is cleaner anyway…. Plus… It’s mine!!!   Moving on… Now the video is working I need to connect it to the CPU. This part of the design is the most difficult. I was dreading it. I knew my headaches were going to get worse. Wait!!! Could it be that simple? I already had the Soft CPU running on the SRAM for quite some time. I noticed that the CPU is active on the falling edge of the clock. All activity for the Video is on the rising edge. The plan expands. I will do all the video on the top side and all the CPU control on the bottom side… I will run the CPU at the same rate as the video clock.  Well, that was the plan.   Weeks of struggle (again part time project). Last week, I found that based on the clock frequency, we have a problem. At 25.175 MHz out cycle time is 1/freq or 39.73 nsec. As we are only accessing the video memory for ½ a clock cycle, that leaves 19.86 usec for video access and 19.86 nsec for CPU access. Here’s the problem!!!!... The chip is rated at 15 nsec. It looks like the SRAM isn’t fast enough for split access.   We’re almost up to date on the status.   So from this point forward I plan on going back to my original concept and using the SRAM for the video and the DDR RAM for the CPU. I’ve started the investigation into this and acquired a Verilog DDR ram driver that works. Now I need to marry them together. One problem is now, how does the CPU talk to the video RAM…. Oh, decisions, decisions, decisions!!!   I knew this was going to be difficult. Maybe Dual Port Ram?

© 2013 Franklin Laboratories www.franklinlabs.com