cognew weirdness

mpark

The following code works (it displays a white "2" on a blue screen), but if I change the 64 to 65, it breaks (the screen remains black). I don't understand why an additional long should cause a problem. Any ideas?

_clkfreq = 80_000_000
_clkmode = xtal1 + pll8x

obj term : "tv_text"

pub blah | i
  term.start( 24 )
  term.dec( cognew( @nada, 0 ) )

dat  
              long      0[noparse][[/noparse] [b]64[/b] ]  '<== change this to 65
nada          org       0
              jmp       #nada

Beau Schwabe

mpark,

All DAT variables should be defined after any Propeller Assembly routines. This includes all res definitions which should proceed any long,word, or byte declarations.

_clkfreq = 80_000_000
_clkmode = xtal1 + pll16x

obj term : "tv_text"

pub blah | i
  term.start( 12 )
  term.dec( cognew( @nada, 0 ) )

dat  
nada          org       0
              jmp       #nada

long      0[noparse][[/noparse] 65 ]  '<== change this to 65

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

Phil Pilgrim (PhiPi)

Wow, this is really bizzaro. The problem is the jmp to the org. You can start the cog with that label, but you can't jump to it? At least when I move the label down to the next line, or add a different label there to jump to, it always works.

But things get weirder yet. If I use my tv_wtext or a different version of tv_text, it works okay, too, even with the label on the org. There's a really odd interaction going on here, but it's certainly not clear yet what it is.

Beau,

BTW, it's okay to declare variables ahead of an assembly program, as long as you include the org where it needs to be and don't try to use those variables in the assembly code: they won't be loaded into the cog.

This works:

_clkfreq = 80_000_000
_clkmode = xtal1 + pll16x

obj term : "tv_text"

pub blah | i
  term.start( 12 )
  term.dec( cognew( @nada0, 0 ) )
  'repeat

dat  
              long      0[noparse][[/noparse] 65 ]  '<== change this to 65
nada0         org       0
nada1         jmp       #nada1

This doesn't:

_clkfreq = 80_000_000
_clkmode = xtal1 + pll16x

obj term : "tv_text"

pub blah | i
  term.start( 12 )
  term.dec( cognew( @nada0, 0 ) )
  'repeat

dat  
              long      0[noparse][[/noparse] 65 ]  '<== change this to 65
nada0         org       0
nada1         jmp       #nada0

-Phil

Post Edited (Phil Pilgrim (PhiPi)) : 6/4/2009 8:29:11 PM GMT

Phil Pilgrim (PhiPi)

Okay, I think I understand this now. The hub addresses of nada0 and nada1 are the same. The cog addresses are different, though. In the case cited above, nada0 is at 65, and nada1 is at zero. When you jump to nada0, you're jumping to location 65 in the cog, which may contain who-knows-what from subsequent hub ram and is screwing with the video. Location 64 is, apparently, more benign.

The best rule to follow is this: Never put a label on an org. An org is not an executable assembly statement.

-Phil

Post Edited (Phil Pilgrim (PhiPi)) : 6/4/2009 8:38:37 PM GMT

MagIO2

Labels have two different meanings. If you use them in SPIN it's a HUB-RAM adress. If you use them in PASM it's an adress relative to the DAT or any ORG which comes before the label. If you have the label in line with the ORG I guess it's still relative to the DAT before. So, depending on the number of longs defined before, you have different adresses in the JMP.
As we all know the COG-RAM is always filled with 512 longs. So it's unpredictable what code will be there. Or maybe you have NOPs up to the end of the COG-RAM where we find the special registers. At least the INA will give use a surprise instruction then ;o)

You could easily check if it jumps where you expect it to jump to by toggling an pin instead of doing nothing.

mpark

Phil Pilgrim (PhiPi) said...
Never put a label on an org.

OK, that's embarrassing. I know and obey that rule. Except today.

Thank you, Phil!