That was it! Thanks!! I wonder why Baggers used a non-standard frequency?
Because he took the value from Chips driver. Chip seems to have a very forgiving multisync monitor that does not care much about the right frequencies as long as the ratio of the vertical and horizontal timing is correct.
My monitor is very picky and insits on the right frequencies.
The problem is that if you use the right pixel-frequency most resolutions show some jitter in the pixels because the PLL makes not a smooth signal. But for 800x600 (40MHz) it seems to work well. This will be better on the real chip.
Because he took the value from Chips driver. Chip seems to have a very forgiving multisync monitor that does not care much about the right frequencies as long as the ratio of the vertical and horizontal timing is correct.
My monitor is very picky and insits on the right frequencies.
The problem is that if you use the right pixel-frequency most resolutions show some jitter in the pixels because the PLL makes not a smooth signal. But for 800x600 (40MHz) it seems to work well. This will be better on the real chip.
Andy
This was a problem I always had working with Andre's boards. He always used non-standard timings that worked fine on the CRT monitors he used but almost always gave me trouble. He kept telling me to just us a CRT monitor myself. Unfortunately, I don't have one anymore. Thanks for the alternate timing!
Chip supplied that frequency. On the P1 the rule with the PLL is to try and use values with as few on bits as possible within the top 5 bits. This is because the counter is cycling on an off and generating sub-frequencies for each 1 bit below the top bit. This creates jitter and sidebands on the outputs. I don't know if the P2 has the same exact restrictions, but Chip picked values that were the next highest modulus fore the dot clocks. The VGA demo uses 30MHz when 25.175Mhz is standard.
40MHz is sort of the opposite, $1600_0000 is the next "even" iteration bigger than 40MHz and yields 41.25 Mhz. I found that the analog output was more noisy with $1555_5555.
Chip supplied that frequency. On the P1 the rule with the PLL is to try and use values with as few on bits as possible within the top 5 bits. This is because the counter is cycling on an off and generating sub-frequencies for each 1 bit below the top bit. This creates jitter and sidebands on the outputs. I don't know if the P2 has the same exact restrictions, but Chip picked values that were the next highest modulus fore the dot clocks. The VGA demo uses 30MHz when 25.175Mhz is standard.
40MHz is sort of the opposite, $1600_0000 is the next "even" iteration bigger than 40MHz and yields 41.25 Mhz. I found that the analog output was more noisy with $1555_5555.
Hmmm... I guess this means that only some monitors will work with the P1 and maybe also the P2? Or maybe I just have bad luck in choosing monitors and always pick ones that are intolerant of timing deviations. Is there no way to generate accurate timing or must we always rely on monitors not being that picky?
Thanks to Andy I got my VGA output working and am now able to load the "ww1024x600.bin" (well, really "WW1024~1.BIN") from an SD card. Now I just have to get the actual Wired driver working and I should finally be able to see this demo run. I had some trouble along the way because p2load doesn't know how to patch images before downloading them like propeller-load. Variable patching is how propeller-load tells the program being loaded what pins are used for things like the SD card. I fixed that by adding rather ugly explicit code to mount the SD card in my main program. I either need to add variable patching to p2load or merge the p2load features into propeller-load.
Merge, don't re-invent. I knew this was the point at which you would reach the precipice.
Yeah but I kind of like p2load better. It's a lot simpler. Unfortunately, propeller-load has grown into kind of a monster. It tries to do too many things I think.
I converted the Wired driver itself but it doesn't seem to work. Maybe Baggers will take a look at it to see if he can spot what I did wrong. All I tried to do was pass all of the parameters into the driver using ptra rather than having them hard coded. I'm sure I messed something up in the process though.
Yeah but I kind of like p2load better. It's a lot simpler. Unfortunately, propeller-load has grown into kind of a monster. It tries to do too many things I think.
Ahh, well then that is what spawn forks and competing projects!
Can it be broken apart into separate shared object libraries so the useful stuff can be reused in p2load?
Ahh, well then that is what spawn forks and competing projects!
Can it be broken apart into separate shared object libraries so the useful stuff can be reused in p2load?
Probably. Some of it is fairly clean but some of it is pretty crufty. It would take some work to split it apart. One thing I'd kind of like to remove is SD card writing. I think it would be better to have a separate program that could read/write SD cards over the serial interface to the Propeller.
I converted the Wired driver itself but it doesn't seem to work. Maybe Baggers will take a look at it to see if he can spot what I did wrong. All I tried to do was pass all of the parameters into the driver using ptra rather than having them hard coded. I'm sure I messed something up in the process though.
What are you doing with vbptr? I see it's declared and passed to the Wired Driver, but the driver spins until there is something written, who writes to it?
The Video Driver sets it to 1, signifying a vertical blank ( well, the end of the displayed frame, for maximum time between that and the start of the new frame )
As for the timing, yes, it was used from Chip's driver.
The Video Driver sets it to 1, signifying a vertical blank ( well, the end of the displayed frame, for maximum time between that and the start of the new frame )
As for the timing, yes, it was used from Chip's driver.
I'll have a look at the C wire-world later today.
Do you have a project zip?
I'm attaching a zip file containing all of the source as well as a built .elf file. The C code loads the SDRAM driver, loads the image from the SD card into SDRAM, loads the VGA driver, and then finally overwrites the C code with the Wired driver. By the time the demo is running there is no C code running anymore.
Okay, I think I have Baggers' demo working. I misread the original code and modified it to using dynamic parameters incorrectly.
Original code:
hub_loc long SDRAM_COMMANDS+$08
sd_loc long SDRAM_COMMANDS+$0c
hub0_rd long WORKRAM+$000+7
hub1_rd long WORKRAM+$400+7
hub2_rd long WORKRAM+$800+7
hub1_wr long WORKRAM+$c00+8+7
I essentially translated the last line to this:
hub1_wr long WORKRAM+$400+8+7
I did this because I figured hub1_wr was just a variant on hub1_rd but was mistaken.
In any case, the program is now doing something. I'm seeing one row of pixels at the bottom of the display that seems to be displaying garbage. Otherwise, the original image is changing with each frame although I'm not sure what I should expect to see so I don't know if it is working correctly. The digital display at the top shows "00019". Is this a counter demo? Should I expect it to change to "00020" if I let it run long enough?
Otherwise, the original image is changing with each frame although I'm not sure what I should expect to see so I don't know if it is working correctly. The digital display at the top shows "00019". Is this a counter demo? Should I expect it to change to "00020" if I let it run long enough?
I followed the link in the top post and found that this is computing prime numbers. How long should it take to go from 19 to 23?
Yes, you're right, it's a prime number counter, apparently, the start image, is from about 4 million iterations of the thing, so it's a bit slow, but does work, on a fast PC, maybe when we get the final P2 chips, I'll multi-cog it, and see how fast we can get it
Yes, you're right, it's a prime number counter, apparently, the start image, is from about 4 million iterations of the thing, so it's a bit slow, but does work, on a fast PC, maybe when we get the final P2 chips, I'll multi-cog it, and see how fast we can get it
Have you ever run it long enough to reach 23? How long did it take? I'm wondering if mine is really working correctly. Also, this C wrapper might be of use to some of you PASM driver developers since it can load images from an SD card a lot faster than you can send them over a serial link.
If it's animating ie the electrons are moving around the circuit, then it's working, it will take a long time, as even on a fast PC it took a while to go from 19 to the next digit, so we need to speed it up, before realistically watching it, unless you want to leave it on overnight lol
If it's animating ie the electrons are moving around the circuit, then it's working, it will take a long time, as even on a fast PC it took a while to go from 19 to the next digit, so we need to speed it up, before realistically watching it, unless you want to leave it on overnight lol
Yes, the electrons are moving around the circuit. I guess I'll just leave it for a while to see if it ever moves to the next prime. Maybe Parallax will send me a second DE2-115 board so I don't have to disturb this program! :-)
My coworker had this running on his PC for a few hours. I can't tell you how fast it runs as we never saw the display change to the next prime.
We could see lots of gates gating and flip-flops flip-flopping but no change in output.
I might not expect to live long enough to see it change on a Prop.
I let my version of Baggers' WireWorld demo run for over 24 hours and it finally switched from 19 to 23 so it *is* working.
I guess I've had enough fun with that demo now and will move on to other things. Is anyone here interested in the framework I setup for loading and starting PASM drivers built using PNut? The main program I wrote for this WireWorld demo can load an image and then start drivers. It's written in C so I image that will make it unappealing to some here but it does serve a useful purpose. I've noticed that a number of the drivers here are awkward to use because they have demo code built in that must be removed to use the simply as drivers. This is why it took me a while to get the WireWorld demo working. Using the C framework lets you write drivers that can be compiled independently with PNut and merge them with a main program that allocates memory and loads these drivers. Since C has support for the FAT filesystem on the SD card it is also possible to load data from the SD card which I imagine is much faster than sending it across the serial port. It would also allow for standalone operation combined with flashing the main program into the SPI flash.
Comments
Because he took the value from Chips driver. Chip seems to have a very forgiving multisync monitor that does not care much about the right frequencies as long as the ratio of the vertical and horizontal timing is correct.
My monitor is very picky and insits on the right frequencies.
The problem is that if you use the right pixel-frequency most resolutions show some jitter in the pixels because the PLL makes not a smooth signal. But for 800x600 (40MHz) it seems to work well. This will be better on the real chip.
Andy
40MHz is sort of the opposite, $1600_0000 is the next "even" iteration bigger than 40MHz and yields 41.25 Mhz. I found that the analog output was more noisy with $1555_5555.
FWIW:
$1555_5555 = 1_0101_0101_0101_0101_0101_0101_0101
$1600_0000 = 1_0110_0000_0000_0000_0000_0000_0000
$1800_0000 = 1_1000_0000_0000_0000_0000_0000_0000
Here's the ugly code:
#include <stdio.h> #include <stdint.h> #include <dirent.h> #include <propeller.h> #include <sys/sd.h> #define LEN_16 0x00000001 #define LEN_32 0x00000002 #define LEN_64 0x00000003 #define LEN_128 0x00000004 #define LEN_256 0x00000005 #define LEN_512 0x00000006 #define LEN_1024 0x00000007 #define READ 0x00000000 #define WRITE 0x00000008 #define MEMORY_SIZE (16 * 1024 * 1024) #define BLOCK_SIZE 64 #define BLOCK_SIZE_IN_LONGS (BLOCK_SIZE / sizeof(uint32_t)) #define ALIGN 16 #define FILE_NAME "WW1024~1.BIN" // "ww1024x600.bin" typedef struct { volatile uint32_t **p_vbptr; volatile uint32_t *p_vidramptr; volatile uint32_t *sdram_cmd_entry; void *hubram_addr; } VGA_PARAMS; extern _Driver _SimpleSerialDriver; extern _Driver _FileDriver; _Driver *_driverlist[] = { &_SimpleSerialDriver, &_FileDriver, NULL }; #define DO 44 #define DI 45 #define CLK 46 #define CS 47 int main (int argc, char* argv[]) { extern char binary_SDRAM_Driver_obj_start[]; extern char binary_VGA_Driver_obj_start[]; volatile uint32_t sdram_cmds[5] = { 0, 0, 0, 0, 8 }; uint8_t buffer[BLOCK_SIZE + ALIGN]; uint32_t *bufferp = (uint32_t *)(((uint32_t)buffer + ALIGN) & ~(ALIGN - 1)); uint32_t addr, data, data_start; int count, errors, i; FILE *fp; volatile uint32_t *vbptr; volatile uint32_t vidramptr = 0x00000000; uint8_t vgawork[4096 + ALIGN]; uint8_t *vgaworkp = (uint8_t *)(((uint32_t)vgawork + ALIGN) & ~(ALIGN - 1)); VGA_PARAMS vga_params = { &vbptr, &vidramptr, &sdram_cmds[2], vgaworkp }; _SD_Params sd_config; sd_config.AttachmentType = _SDA_ConfigWords; sd_config.pins.ConfigWords.CONFIG1 = (DI<<24) | (DO<<16) | (CLK<<8) | 1; sd_config.pins.ConfigWords.CONFIG2 = CS<<24; coginit(2, binary_SDRAM_Driver_obj_start, (void *)sdram_cmds); coginit(0, binary_VGA_Driver_obj_start, (void *)&vga_params); if (dfs_mount(&sd_config) != 0) { printf("SD mount failed\n"); return 1; } if ((fp = fopen(FILE_NAME, "rb")) == NULL) { printf("Open of '%s' failed\n", FILE_NAME); return 1; } addr = 0x00000000; while (fread(bufferp, 1, BLOCK_SIZE, fp) == BLOCK_SIZE) { sdram_cmds[1] = addr; sdram_cmds[0] = (uint32_t)bufferp | LEN_64 | WRITE; while (sdram_cmds[0]) ; addr += BLOCK_SIZE; } fclose(fp); for (;;) ; return 0; }Wired_Driver.spin
Here is the ugly C code that launches this driver. I'll try to clean it up and add some comments tomorrow.
#include <stdio.h> #include <stdint.h> #include <dirent.h> #include <propeller.h> #include <sys/sd.h> #define LEN_16 0x00000001 #define LEN_32 0x00000002 #define LEN_64 0x00000003 #define LEN_128 0x00000004 #define LEN_256 0x00000005 #define LEN_512 0x00000006 #define LEN_1024 0x00000007 #define READ 0x00000000 #define WRITE 0x00000008 #define MEMORY_SIZE (16 * 1024 * 1024) #define BLOCK_SIZE 64 #define BLOCK_SIZE_IN_LONGS (BLOCK_SIZE / sizeof(uint32_t)) #define ALIGN 16 #define FRAME_SIZE (1024 * 600) #define FILE_NAME "WW1024~1.BIN" // "ww1024x600.bin" typedef struct { volatile uint32_t **p_vbptr; volatile uint32_t *p_vidramptr; volatile uint32_t *sdram_cmd_entry; void *hubram_addr; } VGA_PARAMS; typedef struct { volatile uint32_t **p_vbptr; volatile uint32_t *p_vidramptr; volatile uint32_t *sdram_cmd_entry; void *workram; uint32_t sdram_frame0; uint32_t sdram_frame1; } WIRED_PARAMS; extern _Driver _SimpleSerialDriver; extern _Driver _FileDriver; _Driver *_driverlist[] = { &_SimpleSerialDriver, &_FileDriver, NULL }; #define DO 44 #define DI 45 #define CLK 46 #define CS 47 void LoadSDDriver(uint32_t configwords[]); int main (int argc, char* argv[]) { extern char binary_SDRAM_Driver_obj_start[]; extern char binary_VGA_Driver_obj_start[]; extern char binary_Wired_Driver_obj_start[]; volatile uint32_t sdram_cmds[5] = { 0, 0, 0, 0, 8 }; uint8_t buffer[BLOCK_SIZE + ALIGN]; uint32_t *bufferp = (uint32_t *)(((uint32_t)buffer + ALIGN) & ~(ALIGN - 1)); uint32_t addr, data, data_start; int count, errors, i; FILE *fp; volatile uint32_t *vbptr; volatile uint32_t vidramptr = 0x00000000; uint8_t vgawork[4096 + ALIGN]; uint8_t *vgaworkp = (uint8_t *)(((uint32_t)vgawork + ALIGN) & ~(ALIGN - 1)); VGA_PARAMS vga_params = { &vbptr, &vidramptr, &sdram_cmds[2], vgaworkp }; uint8_t workram[4*1024 + ALIGN]; uint8_t *workramp = (uint8_t *)(((uint32_t)workram + ALIGN) & ~(ALIGN - 1)); WIRED_PARAMS wired_params = { &vbptr, &vidramptr, &sdram_cmds[0], workramp, 0, FRAME_SIZE }; _SD_Params sd_config; sd_config.AttachmentType = _SDA_ConfigWords; sd_config.pins.ConfigWords.CONFIG1 = (DI<<24) | (DO<<16) | (CLK<<8) | 1; sd_config.pins.ConfigWords.CONFIG2 = CS<<24; coginit(2, binary_SDRAM_Driver_obj_start, (void *)sdram_cmds); if (dfs_mount(&sd_config) != 0) { printf("SD mount failed\n"); return 1; } if ((fp = fopen(FILE_NAME, "rb")) == NULL) { printf("Open of '%s' failed\n", FILE_NAME); return 1; } addr = 0x00000000; while (fread(bufferp, 1, BLOCK_SIZE, fp) == BLOCK_SIZE) { sdram_cmds[1] = addr; sdram_cmds[0] = (uint32_t)bufferp | LEN_64 | WRITE; while (sdram_cmds[0]) ; addr += BLOCK_SIZE; } fclose(fp); coginit(0, binary_VGA_Driver_obj_start, (void *)&vga_params); coginit(cogid(), binary_Wired_Driver_obj_start, (void *)&wired_params); return 0; }Ahh, well then that is what spawn forks and competing projects!
Can it be broken apart into separate shared object libraries so the useful stuff can be reused in p2load?
What are you doing with vbptr? I see it's declared and passed to the Wired Driver, but the driver spins until there is something written, who writes to it?
As for the timing, yes, it was used from Chip's driver.
I'll have a look at the C wire-world later today.
Do you have a project zip?
I'm attaching a zip file containing all of the source as well as a built .elf file. The C code loads the SDRAM driver, loads the image from the SD card into SDRAM, loads the VGA driver, and then finally overwrites the C code with the Wired driver. By the time the demo is running there is no C code running anymore.
sdramtest.zip
Thanks for offering to take a look at this!
David
Edit: I introduced a typo when I added comments to my C code. I've replaced the attached file with updated code fixing that bug.
Original code:
I essentially translated the last line to this: I did this because I figured hub1_wr was just a variant on hub1_rd but was mistaken.
In any case, the program is now doing something. I'm seeing one row of pixels at the bottom of the display that seems to be displaying garbage. Otherwise, the original image is changing with each frame although I'm not sure what I should expect to see so I don't know if it is working correctly. The digital display at the top shows "00019". Is this a counter demo? Should I expect it to change to "00020" if I let it run long enough?
Anyway, I've attached the working code.
Thanks Baggers!
sdramtest.zip
Yes, you're right, it's a prime number counter, apparently, the start image, is from about 4 million iterations of the thing, so it's a bit slow, but does work, on a fast PC, maybe when we get the final P2 chips, I'll multi-cog it, and see how fast we can get it
We could see lots of gates gating and flip-flops flip-flopping but no change in output.
I might not expect to live long enough to see it change on a Prop.
I guess I've had enough fun with that demo now and will move on to other things. Is anyone here interested in the framework I setup for loading and starting PASM drivers built using PNut? The main program I wrote for this WireWorld demo can load an image and then start drivers. It's written in C so I image that will make it unappealing to some here but it does serve a useful purpose. I've noticed that a number of the drivers here are awkward to use because they have demo code built in that must be removed to use the simply as drivers. This is why it took me a while to get the WireWorld demo working. Using the C framework lets you write drivers that can be compiled independently with PNut and merge them with a main program that allocates memory and loads these drivers. Since C has support for the FAT filesystem on the SD card it is also possible to load data from the SD card which I imagine is much faster than sending it across the serial port. It would also allow for standalone operation combined with flashing the main program into the SPI flash.
I'll start looking at working with C too.
or do you just use the makefile to build it?
make run
I get
propeller-elf-gcc -mlmm -mp2 -Os -c -o sdramtest.o sdramtest.c
make: *** [sdramtest.o] Segmentation fault: 11
Any ideas?