I wrote a simple one COG program that blinks the 6 LEDs and that seems to be working fine so there isn't a problem with the LED itself or the connection of the LED to the Propeller pin.
My multi-cog demo uses a funky token passing scheme to pass control from one COG to the next. When a COG gets the token it changes its blink rate. That isn't happening even with the COGs that are sucessfully blinking LEDs. Is there any chance that COG 5 isn't working? That would explain why LED 4 isn't blinking and also why the other LEDs don't change blink rates.
Edit: I just modified my multi-cog demo to use only 5 COGs and it is working fine including flashing LED4. I think I'm having trouble with COG 5.
I've done some more experimenting including running my multi-cog program again on the old DE2-115 configuration file and I'm pretty sure that COG 5 does not work with this new configuration. I've even tried a simpler program that does nothing except load an LED blinking program into COG 5 using coginit so I'm sure it's really loading COG 5. It doesn't work. The exact same code loaded into COG 4 works fine. Does this new configuration file support only 5 COGs?
I noticed some changes. Are the old I/O pins still connected? I used to plug two Prop Plugs into the DE2, one for programming, the other for an instance of the monitor for observing results and moving data into and out of the chip. I can't do that anymore. I'm assuming those were moved out into the break out board.
If so, I need to get some header pins to enable that workflow to continue. What is output on those pins, if anything now?
Normally, I just leave the P2 on and running. I'll upload a new program, then jump into the monitor window to go poking around. Takes just a tap on the space bar to get communicating again. In this case, since I don't have two physical connections to the second Prop Plug, I decided to just run instances of the monitor on one COG at a time with this code, which is just my two monitor template with one stripped out:
'Start the monitor on a COG
'For NANO FPGA, use COG 0
'For DE2, use any COG, but make sure only one monitor is running
DAT
org
setcog #4 'set target COG 0
coginit monitor_pgm, monitor_ptr1 'start monitor on target COG
cogstop 0
monitor_pgm long $70C 'ROM entry point for monitor
monitor_ptr long 15<<9 + 13 'Pins for one monitor
monitor_ptr1 long 90<<9 + 91 'Pins for the other one
Steps were:
1. Power on P2
2. Verify monitor on COG 0
3. Edit code to pick another COG
4. Use PNUT to upload new program
5. Verify monitor on designated COG
6. Repeat for all COGS
Worked great, until COG 5. When I try this with COG 5, the monitor does not run. I was going to write that accessing COG 5 sort of locks up the emulation, but it turns out that was just me. It's just as if COG 5 isn't there anymore, except the LED does light up anyway. And that's true for any COG ID it seems. Not sure this was the old behavior because I never ran more than a few COGS, and didn't pay attention to the LED when asking for the higher numbered COGS.
Perhaps adding the logic for the DAC emulation required a bit more of the FPGA and running 6 COGS was right on the edge?
Worked great, until COG 5. When I try this with COG 5, the monitor does not run. I was going to write that accessing COG 5 sort of locks up the emulation, but it turns out that was just me. It's just as if COG 5 isn't there anymore, except the LED does light up anyway. And that's true for any COG ID it seems. Not sure this was the old behavior because I never ran more than a few COGS, and didn't pay attention to the LED when asking for the higher numbered COGS.
Perhaps adding the logic for the DAC emulation required a bit more of the FPGA and running 6 COGS was right on the edge?
All 6 COGs worked with the previous configuration file that added support for the SD card. I tried both of my test programs on that and both were successful in loading COG 5 but both fail on the new configuration file. If the new one was configured for only 5 COGs that's fine with me. I don't need all 6 COGs for the code I'm writing. I was just surprised that they didn't all work.
Here is an ordinary SD YPbPr 256x192 demo program. This is component on ordinary TV sets, not HD, though it should display on all component video capable TV displays. It's a modification of the NTSC one to use the component signals, not the composite / s-video ones. This one with interlace added would equal 420i, in other words. On the display I'm using, 640 pixels would be getting close to the high end of what the TV is capable of.
I'll add interlace later on. Just wanted something that runs on my older SD component display to experiment a little.
Spent some of the day just getting my mind wrapped around the new color space capability. I'm kind of stunned over how easy it is to change displays and signal setup overall. Sheesh! Nice work Chip!
I forgot to mention that the latest DE2-115 configuration only yields 5 cogs (0..4). Six would not fit! This was stated in the pinout.txt file. Also, all the pin connections were listed there.
I forgot to mention that the latest DE2-115 configuration only yields 5 cogs (0..4). Six would not fit! This was stated in the pinout.txt file. Also, all the pin connections were listed there.
Thanks Chip! At least now I know I'm not going crazy! :-)
Oh, this is too cool! So I'm working on various display options, just checking out the core features. The way VID works now is vastly more friendly than it is on P1. Pixels per waitvid locks in the max clocks for the scan line! This means changing pixel sizes, even on the fly, is cake now. Easy.
Mode 8 is a very nice, simple 16 color display...
Doing a whole scan line from one waitvid, streaming pixels in yields a lot of cycles for processing the next.
It's actually a 60Hz display, 240 lines old school NTSC, like Apple 2 / Atari type display with no half-scan line included. So nice to have that component input. Really wanted that on the P1.
Have you guys been tinkering with different display mappings? One can take an 800 pixel display, render it on VGA, HDTV, NTSC, even composite with just a few changes. (Of course, lots of pixels get lost on composite.)
Scratch that, there won't be any. Forgot. I'll have to do an animation test of some sort to see whether or not the display is doubling up frames... I know my LCD VGA display does that with lower scan rates. Things that are supposed to flicker just don't...
Today I had time to play a bit with the Nano AddOn board I received - thank you Parallax.
I don't have a TV with component input here, so concentrated me on VGA.
All the posted VGA drivers show a picture on my monitor, but not always at the right position and with warnings about non standard frequencies. (Yes a have a picky Monitor).
If I set the pixel clock for the 640x480 driver from 30 to the standard 25 MHz, I can see why Chip has choosen 30MHz. The timing is right with 25MHz but you get a lot of jitter in the picture. I think with the real Prop2 with 3 times higher clock rate this will not be such a problem.
Anyway after I figured out how this color bars are generated by streaming out of the CLUT ram, I tried out other Video shifter modes. One of them, mode 7, lets you stream 1bit pixels from the CLUT, and I thought this can be used for a simple Text display. Just hold the font data in the CLUT and stream out 8 pixels from the right position in the CLUT for every character row.
Attached is my first VGA-Text experiment, it holds a font with 128 8x8 characters in the CLUT and allows 80x60 characters - not bad for the first try and on an Emulator that has only 1/3 of the speed of the real Prop2. This may not be the best approach for a text driver, but it is intresting anyway. It would be no problem to allow a different color for every character, this would just need a word per character in the screen buffer.
It uses the timing for 640x480 VGA, so if your Monitor don't show the picture correct, you can change a constant at begin of the source to choose 25MHz pixel clock. The picture will then be a bit jittery.
The font is a bit bold, it is made for TV monitors, but I had only this one around..
Interesting about the 30 MHz VGA... I think I've seen that the Prop PLL is less jittery when the output is an even factor or multiple
of the main crystal. But, the DE0-nano seems to have a 50 MHz oscillator, right? I'd think it would be pretty good at 25 MHz...
Had a few minutes to get started today... Didn't quite get there today...
I followed the instructions in the Cluso sticky thread and installed the stand-alone installer...
Found the USB-Blaster driver in that install directory and installed it.
Ran the programmer and programmed the DE0 sucessfully.
But, no luck connecting via PropPlug...
After floundering for several minutes, I think I figured out that I should have programmed the DE0
with the Saphieha... code instead of the one in the stick thread. Can this be?
It depends on the hardware you use.
There are 3 possibilities:
1) DE0-Nano without AddOn board: you need the code from the sticky thread
2) DE0-Nano with Chips AddOn board: you need the code from post #38 in this thread
3) DE0-Nano with Sapieha's AddOn board: You need the code posted in Sapieha's thread.
Backing up a step... after you load the Altera DE0 JIC file in, do you get the single green light on (indicating cog 0 running)?
If you connect the prop plug and hit F7 in the Prop Tool does it recognise a propeller version 32?
I think Pnut possibly only covers com ports up to 9, perhaps that is an issue
Comments
Just ran Chip's 1080p demo - worked fine
Next: World Domination...
I noticed some changes. Are the old I/O pins still connected? I used to plug two Prop Plugs into the DE2, one for programming, the other for an instance of the monitor for observing results and moving data into and out of the chip. I can't do that anymore. I'm assuming those were moved out into the break out board.
If so, I need to get some header pins to enable that workflow to continue. What is output on those pins, if anything now?
Normally, I just leave the P2 on and running. I'll upload a new program, then jump into the monitor window to go poking around. Takes just a tap on the space bar to get communicating again. In this case, since I don't have two physical connections to the second Prop Plug, I decided to just run instances of the monitor on one COG at a time with this code, which is just my two monitor template with one stripped out:
'Start the monitor on a COG 'For NANO FPGA, use COG 0 'For DE2, use any COG, but make sure only one monitor is running DAT org setcog #4 'set target COG 0 coginit monitor_pgm, monitor_ptr1 'start monitor on target COG cogstop 0 monitor_pgm long $70C 'ROM entry point for monitor monitor_ptr long 15<<9 + 13 'Pins for one monitor monitor_ptr1 long 90<<9 + 91 'Pins for the other oneSteps were:
1. Power on P2
2. Verify monitor on COG 0
3. Edit code to pick another COG
4. Use PNUT to upload new program
5. Verify monitor on designated COG
6. Repeat for all COGS
Worked great, until COG 5. When I try this with COG 5, the monitor does not run. I was going to write that accessing COG 5 sort of locks up the emulation, but it turns out that was just me. It's just as if COG 5 isn't there anymore, except the LED does light up anyway. And that's true for any COG ID it seems. Not sure this was the old behavior because I never ran more than a few COGS, and didn't pay attention to the LED when asking for the higher numbered COGS.
Perhaps adding the logic for the DAC emulation required a bit more of the FPGA and running 6 COGS was right on the edge?
All 6 COGs worked with the previous configuration file that added support for the SD card. I tried both of my test programs on that and both were successful in loading COG 5 but both fail on the new configuration file. If the new one was configured for only 5 COGs that's fine with me. I don't need all 6 COGs for the code I'm writing. I was just surprised that they didn't all work.
I'll add interlace later on. Just wanted something that runs on my older SD component display to experiment a little.
Spent some of the day just getting my mind wrapped around the new color space capability. I'm kind of stunned over how easy it is to change displays and signal setup overall. Sheesh! Nice work Chip!
Mode 8 is a very nice, simple 16 color display...
Doing a whole scan line from one waitvid, streaming pixels in yields a lot of cycles for processing the next.
BTW, your 480p mode worked fine on my Insignia 24"
I've not tested on anything else but the SONY. Really, the way it is right now is 240p (Is that even a term?)
It says it is 480p @ 30Hz ... but it does display it
It's actually a 60Hz display, 240 lines old school NTSC, like Apple 2 / Atari type display with no half-scan line included. So nice to have that component input. Really wanted that on the P1.
Have you guys been tinkering with different display mappings? One can take an 800 pixel display, render it on VGA, HDTV, NTSC, even composite with just a few changes. (Of course, lots of pixels get lost on composite.)
Either that, or my monitor is a VERY confused puppy.
Scratch that, there won't be any. Forgot. I'll have to do an animation test of some sort to see whether or not the display is doubling up frames... I know my LCD VGA display does that with lower scan rates. Things that are supposed to flicker just don't...
I don't have a TV with component input here, so concentrated me on VGA.
All the posted VGA drivers show a picture on my monitor, but not always at the right position and with warnings about non standard frequencies. (Yes a have a picky Monitor).
If I set the pixel clock for the 640x480 driver from 30 to the standard 25 MHz, I can see why Chip has choosen 30MHz. The timing is right with 25MHz but you get a lot of jitter in the picture. I think with the real Prop2 with 3 times higher clock rate this will not be such a problem.
Anyway after I figured out how this color bars are generated by streaming out of the CLUT ram, I tried out other Video shifter modes. One of them, mode 7, lets you stream 1bit pixels from the CLUT, and I thought this can be used for a simple Text display. Just hold the font data in the CLUT and stream out 8 pixels from the right position in the CLUT for every character row.
Attached is my first VGA-Text experiment, it holds a font with 128 8x8 characters in the CLUT and allows 80x60 characters - not bad for the first try and on an Emulator that has only 1/3 of the speed of the real Prop2. This may not be the best approach for a text driver, but it is intresting anyway. It would be no problem to allow a different color for every character, this would just need a word per character in the screen buffer.
It uses the timing for 640x480 VGA, so if your Monitor don't show the picture correct, you can change a constant at begin of the source to choose 25MHz pixel clock. The picture will then be a bit jittery.
The font is a bit bold, it is made for TV monitors, but I had only this one around..
Andy
It will be interesting to see what the maximum PLL output frequency will be with the actual chips - the higher the better...
of the main crystal. But, the DE0-nano seems to have a 50 MHz oscillator, right? I'd think it would be pretty good at 25 MHz...
I followed the instructions in the Cluso sticky thread and installed the stand-alone installer...
Found the USB-Blaster driver in that install directory and installed it.
Ran the programmer and programmed the DE0 sucessfully.
But, no luck connecting via PropPlug...
After floundering for several minutes, I think I figured out that I should have programmed the DE0
with the Saphieha... code instead of the one in the stick thread. Can this be?
It depends on the hardware you use.
There are 3 possibilities:
1) DE0-Nano without AddOn board: you need the code from the sticky thread
2) DE0-Nano with Chips AddOn board: you need the code from post #38 in this thread
3) DE0-Nano with Sapieha's AddOn board: You need the code posted in Sapieha's thread.
Andy
You need a jumper across pins 3 & 5 of the 26 pin connector. (adjacent to the square pad of pin 1)
... and remove the flash chip to the breadboard ...
NTSC composite video out on DAC0, Component output is DAC 1/2/3
I did forget the jumper, but remembered, but it didn't help...
I was under the impression that Saphieha's and Chip's boards were the same thing, guess not.
Thanks for the tips.
If you connect the prop plug and hit F7 in the Prop Tool does it recognise a propeller version 32?
I think Pnut possibly only covers com ports up to 9, perhaps that is an issue