It's still small, but there are some loose signals on the bitmap module (trigger/odd) that need to be connected to the cs4954 module.

Ok, the size issue should be fixed now.

I see I missed those 3 signals. I have more than a few questions on how to properly hook this up, so please bear with me.

1) Is the vid_we signal from the bitmap module routed correctly?
2) The pixel clock (pclk) from the CS4954 module goes to the bitmap module. The system/cpu clock goes to the clk inputs of the CS4954, SDRAM, and SDRAMIF modules?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

The vid_we signal should go to the CS4954 module. It controls the vid_addr/vid_data bus.

The bitmap module runs on the system/cpu clock. The same clock goes to the clk input of the CS4954. A 54 MHz clock goes into the clk54 input, and a 27 MHz clock comes out of the pclk signal, which needs to go to the video clock output of the FPGA to the CS4954 chip.

Excellent, thanks!

3) In the code for sdramif.v, there's a comment for the 'ctrl' input saying it's used for window control. It's related to the DI_CTRL[15:0]? How does this output work?

EDIT: N/M, I see 'ctrl' is related to the section you said to comment out for interfacing to an 16-bit cpu. So I don't need to use the DI_CTRL output? What is AB[15:0] used for?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

An 8 bit CPU, like the 6502, would first perform two byte writes to special control registers. These would be stored in ABH[15:8] and ABH[7:0], and set the SDRAM page. Then the CPU could do a bunch of accesses to page $A0xx, where the lower 8 bits of the address would be concatenated as follows:

With a 32 bit address bus, you could map the SDRAM to $A0xxxxxx instead. Remove ABH, and use:

I have enough information to hook it all up now, thanks again for the help.

My project is reaching proportions now, that I can see I am going to have trouble fitting this video portion into my project in schematic form. My next challenge will have to be to learn how to create a top level in Verilog, instead of schematic before I can see any graphics. I can get some clues from ISE's HDL translation of my schematic, and also your main.v file.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Sorry, so many things going on in the summer months, with kids off from school I must keep them entertained for part of the day on my days off... Today I should be able to complete adding the 65Org16.b core, ZPRAM, STackRAM and a simple OSROM to your modules and hopefully see some video output. I've abandoned trying to merge my TFT project for now, with it's top level schematic. I think what will happen is I will slowly add parts of it in verilog to this new project...

Could you perchance post me your register settings for the CS4954 to save me some time?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Here's my NTSC init:

Thanks for the quick response!
Just got done soldering in the SDRAM and .1uF bypass caps. Old TFT project, which was still loaded in FPGA FLASH, still boots up the TFT and color bars for S-Video meaning no power distribution/noise errors on this board. All other signals from FPGA to SDRAM are unused and therefore hi-impedance, except for the SDRAM /CS which I was forcing high. Taking baby steps here...

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

I see your values are identical to the ones I used for the color bar test pattern. But, I thought the resolution had to be specified in order to set the appropriate HSYNC and VSYNC frequencies?

My design has passed synthesis, except for the timing constraint for the CPU. Looks close though... Running smartXplorer made it pass the 10ns constraint!

I guess this is a good initial observation that with this new design with your modules, the CS4954 is outputting color bar test pattern. So at least I know the address decoding is good, the CPU is running fine with your I2C routine, and the StackRAM and ZeroPageRAM are functioning.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

The resolution from the CS4954 is always the same. I reduce the resolution in my test by adding a border, and/or pixel doubling (sending the same pixel twice).

Ok, I suspected that as I didn't see any obvious registers to program. So anyway, when I disabled colorbar generation I have the beginning of graphics!!!! This is awesome when things come together so quickly. It's not perfect but most definately something to work with. I see the green border. The right half of the screen is black. Most of the left side is purple shades of pixels and on the very top, maybe 16 pixels tall, looks like regular random colored pixels one would expect. Working on getting a pic to post...

EDIT: Here it is. Bottom border is missing...

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

This is looking like something! So, is the SDRAM involved at this point?

I suspect the right half of the screen is black, because the bitmap is only 256 pixels wide. In your schematic you didn't hook up the 'hstretch' input to the cs4954.v module. If you tie that input to '1', the bitmap will be stretch horizontally, and it should fill the entire screen.

As far as the missing bottom, that's probably because NTSC has fewer scanlines than PAL. You should be able to fix that by adjust 'height' in the cs4954.v module. Similarly, you can adjust 'top' and 'left' to adjust the borders, so you can center the active screen on your TV/monitor.

After that, you should try to write to SDRAM from the CPU, and see if you can write on the screen.

It certainly looks like the data is coming from SDRAM. If you compare the image to my first bitmap, it looks quite similar.