Thanks! Looks like it will require a bit of conversion to run on the Mac or Linux to convert the Windows file API calls to stdio. Doesn't look like a big job though.
Ummm... Maybe I spoke too soon. Looks like the entire point of this is to write to a COM port. I'll have to convert it to use the same serial I/O code that p2load uses. Might take a while.
By the way, I tried to run P2Prep.exe under WinXP and got an error related to the VC runtime library. Should this run under WinXP?
I converted p2prep to run on the Mac or Linux but it doesn't seem to work for me. Maybe it's because the 460800 as a baud rate. Anyway, I guess I'm not going to be able to run this demo. Any chance of posting a video?
I believe on the FPGA boards the refresh is being handled by the board and not the fpga logic that is the P2 in our case. I think the current driver will need to be updated for the real P2 in order to do the refreshing signals, right Chip?
No. The current driver does refresh, already, and way too much of it. After every command and every time it resets the command list pointer, it does an 'auto refresh' which affects all 4 banks.
Nice idea. Guess it depends on the default state of the programmed pull-ups after cogstop. Chip?
I don't remember if it's pin states or a simple sequence that puts the SDRAM in self-refresh mode. Getting the chip into self-refresh mode would be the best to get its contents to survive a cog change.
I converted p2prep to run on the Mac or Linux but it doesn't seem to work for me. Maybe it's because the 460800 as a baud rate. Anyway, I guess I'm not going to be able to run this demo. Any chance of posting a video?
What does "JB_TO_SDRAM_32BIT_TV.obj" do? Is the source available? I don't think I'm going to be able to figure out how to get the WireWorld program to run without being able to debug the download of the SDRAM. I'm sure I must have broken something while trying to port it to the Mac/Linux but it's hard to know what without knowing the code it's talking to on the P2.
I noticed that the first program to be loaded has "TV" in its name so I switched to the AV input on my monitor while doing the load to see if it was displaying anything on the TV screen. It looks like it is displaying an image during that first stage load. It's just that the image goes away and nothing appears on the VGA screen after the second load of WiredComputer.obj. It does look like it is driving the VGA monitor though but the screen is entirely black. Any idea what could be going wrong in the transition between the load and the starting of WiredComputer.obj?
Yeah, sorry matey, the JB_TO_SDRAM_32BIT_TV.obj waits for the sending computer to send J and B then a long for SDRAM address, then a long for length, then the data
Yeah, sorry matey, the JB_TO_SDRAM_32BIT_TV.obj waits for the sending computer to send J and B then a long for SDRAM address, then a long for length, then the data
I don't remember if it's pin states or a simple sequence that puts the SDRAM in self-refresh mode. Getting the chip into self-refresh mode would be the best to get its contents to survive a cog change.
It's not so much a cog change, but a Reset of the Prop2 that the RAM content must survive. If we have a big C code loaded to the SDRAM and then make a Reset to load a new VM which interpretes this SDRAM code, then the SDRAM should refresh itself while loading the new VM code.
I think the Reset makes all pins floating so we will need at least a PullDown resistor at CKE to keep the SDRAM in SelfRefresh mode. (Something to consider for the Prop2 - module).
I don't remember if it's pin states or a simple sequence that puts the SDRAM in self-refresh mode. Getting the chip into self-refresh mode would be the best to get its contents to survive a cog change.
My question is : do the P2 pull-up/down resistor programming states survive a cogstop or a reset. I'm guessing not.
My question is : do the P2 pull-up/down resistor programming states survive a cogstop or a reset. I'm guessing not.
The pins actually have their own state memories. After a pin is configured by a cog, that cog holds the config line high. The config lines are OR'd together across cogs, just like DIR's and OUT's. So, once a cog has configured a pin, another cog can configure it, with the only effect being that that cog becomes the new one to hold the config line high. The prior cog is then free to stop/restart (its config output goes low), while the pin maintains its mode.
Yes David, that's a great idea, then I can ask you nicely if you could add SDRAM loading into P2Load pretty please with bells on
If you want a hand I'll send you the source for mine, and talk you through it, but it's pretty easy, especially with Chip's SDRAM drivers!
Okay, I think I now have all of the pieces I need to load SDRAM from data written to flash. I'll try to put the pieces together in the next few days. I'm determined to see this demo running on my DE2-115! :-)
Baggers: Do you have a standalone version of this VGA driver? I'd like to launch it from C and want a version of the driver that isn't also the main program. Is there a version that can be started with COGINIT in another COG? I understand that I'll have to run it in COG 0 on the DE2-115 board but that's not a problem. Or is there one of your other drivers that you'd recommend instead?
Thanks! I'll try this later tonight. Do you know what I did wrong with my attempt to separate out the VGA driver?
Okay, I tried this and it produces the same black screen that my attempt to port your driver produced. What should I see? I'm assuming I should see random stuff since nothing every initializes the frame buffer in SDRAM. What is the format of the frame buffer? Is it one byte per pixel? How are RGB encoded into that byte?
I wouldn't assume the SDRAM is full of garbage at power up, it is very likely to be zeroed out because it is a DRAM. The HUB memory is persistent across resets, but is initialized to ROM + zero on power up.
There is a GETLFSR instruction that is very useful at generating noise for testing, I'd put a loop in to initialize the memory before going any further. Or initialize it with a specific sequence.
Can you say what the data format is for the pixels in the frame buffer?
The mode value defines the pixel format. It is set to %1010 which is the luma8 mode, so 1 byte per pixel: 8 colors with 5bit luma each.
You can change the mode to %1100 to get a RGB 3:3:2 format (or other 8bit modes).
It can be that your monitor does no like the wrong pixel frequency of 45 MHz. Try to set frqa_ to "long $1555_5555" instead of $1800_0000, this results in 40 MHz which is the standard.
The mode value defines the pixel format. It is set to %1010 which is the luma8 mode, so 1 byte per pixel: 8 colors with 5bit luma each.
You can change the mode to %1100 to get a RGB 3:3:2 format (or other 8bit modes).
It can be that your monitor does no like the wrong pixel frequency of 45 MHz. Try to set frqa_ to "long $1555_5555" instead of $1800_0000, this results in 40 MHz which is the standard.
Andy
That was it! Thanks!! I wonder why Baggers used a non-standard frequency?
Comments
By the way, I tried to run P2Prep.exe under WinXP and got an error related to the VC runtime library. Should this run under WinXP?
Btw, what are other people using to upload to SDRAM?
No. The current driver does refresh, already, and way too much of it. After every command and every time it resets the command list pointer, it does an 'auto refresh' which affects all 4 banks.
I don't remember if it's pin states or a simple sequence that puts the SDRAM in self-refresh mode. Getting the chip into self-refresh mode would be the best to get its contents to survive a cog change.
edit: added source.
JB_TO_SDRAM_32BIT_TV.spin
It's not so much a cog change, but a Reset of the Prop2 that the RAM content must survive. If we have a big C code loaded to the SDRAM and then make a Reset to load a new VM which interpretes this SDRAM code, then the SDRAM should refresh itself while loading the new VM code.
I think the Reset makes all pins floating so we will need at least a PullDown resistor at CKE to keep the SDRAM in SelfRefresh mode. (Something to consider for the Prop2 - module).
Andy
My question is : do the P2 pull-up/down resistor programming states survive a cogstop or a reset. I'm guessing not.
The pins actually have their own state memories. After a pin is configured by a cog, that cog holds the config line high. The config lines are OR'd together across cogs, just like DIR's and OUT's. So, once a cog has configured a pin, another cog can configure it, with the only effect being that that cog becomes the new one to hold the config line high. The prior cog is then free to stop/restart (its config output goes low), while the pin maintains its mode.
Thanks,
David
It's attached in case you want a good laugh.
VGA_Driver.spin
How's this?
I also spotted a duplicate
mov x,#23
call #blank
Which I've now removed in this driver.
VGADriver.spin
Thanks! I'll try this later tonight. Do you know what I did wrong with my attempt to separate out the VGA driver?
Thanks!
David
There is a GETLFSR instruction that is very useful at generating noise for testing, I'd put a loop in to initialize the memory before going any further. Or initialize it with a specific sequence.
The mode value defines the pixel format. It is set to %1010 which is the luma8 mode, so 1 byte per pixel: 8 colors with 5bit luma each.
You can change the mode to %1100 to get a RGB 3:3:2 format (or other 8bit modes).
It can be that your monitor does no like the wrong pixel frequency of 45 MHz. Try to set frqa_ to "long $1555_5555" instead of $1800_0000, this results in 40 MHz which is the standard.
Andy