6502.org

Still working on the IOBDELAY...

But today I've successfully run a test where the cpu section and SyncRAM is running 30MHz writing to the screen when the display is at 320x200 running @15MHz.

EDIT: Also working when cpu&RAM running @60MHz!
The speed is very impressive @640x480, 25MHz with cpu@50MHz. It is painting almost 32 screens a sec ~9MB/sec! (I can tell 32 because I'm incrementing through RGB values and blue resets after xxxxx_xxxxxx_11111)

Good job...

I got my sandbox board in today, so pretty soon I'll also need to turn on the SRAM. It's a different board, and a different RAM device, but there's probably still useful information we can exchange.

Excellent. I would like to ask some questions. I'll do that on that thread.

This is hard to believe, but I just ran smartexplorer and it was able to fit the design into a 100MHz constraint for the cpu. A few random dots though when clearing the screen with a software delay. The SRAM getting abit toasty to the touch. I will back down the speed for reliability.

So with this speed I am thinking of buffering the video now and staying with the 640x480 resolution. With a 2MB SyncRAM that would allow almost 7 pages, but I will stick with 4 to keep things simple. I am going to try to have the page bits go into the cpu 'P' status register. On the 65Org16.b, there are 11 bits unused. This way the cpu will know which page is currently being used by the video module, and not to write to it. Also I will have another bit tied into the pixel clock, so the cpu will also know if the current screen is less than half painted or more than half.

Strange that your SRAM is getting warm. Maybe you have conflicts from switching the direction of the data signals ?

It does take 290mA @100MHz, so I would think this is normal heat dissipation.

EDIT: BTW, now thinking, those random dots may be because I have still not soldered in the smaller bypass caps!

tsk, tsk, tsk. I already have my SRAM bypass caps in place, and the SRAM hasn't even been mounted yet

Time is coming soon for me to add these cap's...

I made a character ROM and added it to the project. Now I have to port over the 65Org16.b software I made for plotting characters on a 800x480 TFT from an old project.

EDIT: Bah, this is going to be a major rewrite. I'll have to start from scratch.

In cycling through the 16 colors with a large software delay, (C64 style) that I'll be using for the font attributes, and painting the entire screen there is a problem with white. The screen is flickering bad. Then as soon as I power off, even before the picture fades, the flickering disappears. I thought it was a software or core issue at first, but then I changed the program to paint the screen white only, and it flickers. Hopefully bypass caps will help stop the effect. If not I'll experiment the FPGA output 'DRIVE' and 'SLEW' constraints. Currently 'DRIVE' is @12mA and 'SLEW' is slow.
Incidentally, the flickering stops with a value of '1110011110011100'.

This is a valuable clue, not to be ignored. "Why just white?" is probably not the best question to ask. Could be the flickering is present with all colors, and merely happens to be more noticeable with white. In any case, your remark suggests:

• one of your (supposedly) DC supplies has line-frequency ripple on it, for instance as caused by a linear regulator when its input falls to too low a voltage
• there's some sort of issue with electrostatic (or, less likely, magnetic) fields. A floating high-impedance input in your circuit could produce a response to an electrostatic field.
• there may be a ground loop if your power supply and the video monitor both have connections to the safety ground of the building wiring.

Just my $.02 worth... Happy hunting!
Jeff

ps- when you say "as soon as I power off," you're referring to the power on your VGA rig, right? (Not the monitor?)

With a scope, you should be able to see if the flickering is present on the analog outputs as analog noise, or on the digital inputs.

That's correct.

This isn't just flickering. This is major noise in the form of thick bands of incorrect color scrolling vertically up, and it was preset with yellow '1111111111100000' for about 10 seconds until the system warmed up then disappeared, but was still plainly visible when '1111111111111111' was painted no matter the length of time. I'm pretty sure it has to do with bypass cap's. I've just been lazy to solder all those 1mm things in. There's at least 20 I have to solder in. I've been settling for a light grey for my software development today.

I really should track this down though in order to be thorough. I'll try adjusting the FPGA drive strength first and observing some signals on the scope for the rest of today.

Next week I'll dedicate 1 day to soldering the bypass caps and be done with it already! Thanks for your input.

Observations:
The noise disappeared after dialing the FPGA drive current to the SyncRAM pins down to 6mA.
The circuit still worked even after going all the way down to the lowest setting of 2mA, which is where I'll keep it for now.

On my SRAM, I'm getting the best results with DRIVE = 4. See picture from scope with top trace = OE, and bottom trace = D0.

PS: the edges are probably not really accurate due to limited scope bandwidth (200 MHz), but with DRIVE=6, there are more jiggles after a transition, and with DRIVE=2, the edges are clearly slower.

Interesting!
For comparisons sake, what does your scope see with a drive strength of 12mA?

Same OE pulse, but now with 12mA drive strength. Doesn't look like it would cause problems, though...