PASD - variables in DAT - declaration

[nicolad76]

Hi,
I was using PASD to find out why my code does not work and I notice that variables values in COG memory do not mach the initial setting.
This as I strat PASD. Now..I compared with the demo coming with PASD and it looks ok...so it must be me...

this is ow I have declared the variables


m_OutPins·················long %00000000_11111111_01111100_00000000
m_DataPins··············· long %00000000_11111111_00000000_00000000

m_LoadPicture··········· long· %00000101
m_StopLoading·········· long· %10000101
m_DisplayPicture········ long· %01000101
m_Count·················· long· 60000
m_DisplaySize··········· long· %01000111
m_Reset·················· long· %01110111
m_SetDepth············· long· %11001111
m_Depth_BlackWhite·· long· %00000000
m_EraseDisplay········· long· %11000101
m_CLR_Black············ long· %00000000
m_CLR_White············long· %10000000
m_CLR_DarkGray········long· %01000000
m_CLR_LightGray·······long· %11000000
m_Orientation·········· long· %10101111
m_InitDisplay············ long· %00100101
m_Autorefresh·············· long %10011111
m_CancelAutorefresh········ long %01011111
m_ManualRefresh············ long %00111111
m_Orientation_00······· long· %00000000
m_Orientation_90······· long· %10000000
m_Orientation_180······ long· %01000000
m_Orientation_270······ long· %11000000
timer·················· long 0
m_FakeData·· byte %10011001
m_NRST······ long |<· H_NRST·
m_WUP······· long |<· H_WUP·
m_CD········ long |<· H_CD
m_DS········ long |<· H_DS
m_RW········ long |<· H_RW·
m_ACK······· long |<· H_ACK
m_DataByte·············· res 1
m_Cnt··················· res 1
tdelay·················· res 1
what is wrong here? could the problem depend on something else?
Thanks A LOT!!!

Post Edited (nicolad76) : 5/1/2008 11:49:36 AM GMT

[Rayman]

I don't know about that "byte" declaration... This is for an assembly program, right? I usually see everything declared in this case as longs...

[Cluso99]

The assembler should place 3 dummy bytes after your byte declaration to get back into sync with your longs, or have you made a byte declaration in error?

[nicolad76]

I have replaced byte to long just to make sure and what I see is that all values are (expletive)ed up by one row.
m_OutPins reads the value from m_DataPins and so on....I do not believe PASD is having hard time to go through my code :) ...

[nicolad76]

now it is confusing...pin viewer shows correct info...cog memory doesn't...
If you see attachment..output on pins is defined by m_DataByte.
In cog memeory...the value you see on the pins (16..23 which is my data bus) is assigned to variable m_FakeData.
Is this a bug of PASD or mine? :) .. ope mine so I can fix it ;)

[hippy]

It's hard to tell what's going on.

Firstly, isn't the highlighted line the one which will be executed next, not the one that just has been ?

Secondly, is the Pin display for the chip or for that Cog ? Other cogs may be affecting that.

The m_DS bit doesn't appear to have been set but then we cannot see what m_DataPins holds which may have cleared it, and DIRA bit may not be set.

It's not clear to me what relationship m_FakeData has to any of this. This is 'halfway through running a program', so it's hard to see what should or shouldn't be on the outputs at the time the capture was taken.

Something seems very wrong though because a "SHL m_DataByte,#16" has apparently just been executed, which should leave m_DataByte with 16 zeroed lsb's which they aren't. Unless execution got to $042 through some other route.

I've no idea why the instruction at $042 is showing as "00000000".

There are other anomalies ...

$03B A0FD2000 call #writebyteCMD

With writebyteCMD at $03F, the lsbs (src) in the instruction at $03B should be "03F" not "000".

Also, look at the instruction codes ( top 6 msb's ) and they don't match up, although I haven't checked what they should be ...

$039 A0...... mov
$03A 5C...... mov
$03B A0...... call

and on it goes

Post Edited (hippy) : 5/1/2008 1:13:43 PM GMT

[Ariba]

Hello Nicolad

Remember that PASD gets no Listing from the IDE and has also no integrated Assembler or Disassembler.
PASD reads the Code out of the cog and then tries(!) to assign the Source code lines to the code addresses with a simple algorithm. It uses some rules to decide if a source line produces an instruction or not and for long, word and byte also the number of datas is counted, but all is rounded to longs. So a single byte is not handled correct.
This means you can normally trust the addr - code column on the left, but the source in the second column can be displaced.
You can also trust the break address and the Pin states in the Pin viewer (but not always the blue/red direction) because all this is read from the cog.


nicolad76 said...
I have replaced byte to long just to make sure and what I see is that all values are (expletive)ed up by one row.
m_OutPins reads the value from m_DataPins and so on....


This is a clear indicator that the source is not assigned right. You can compare the values in the first column with a initalized long value in the data section. If they don't match the Parser has failed.

Your problem is somewhere in the code, not in the data section and it must be before the part which is shown in the screenshot. At that position the source is already displaced by 1 long. So go thru the code and look if for every valid instruction an address and a code is displayed in the first column. If not, then this is the problematic source line.

Andy

[nicolad76]

great!!! I'll try....
Thanks
Nicola

[jazzed]

Having braced comments within braced comments will cause the variable display to be wrong.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
jazzed·... about·living in·http://en.wikipedia.org/wiki/Silicon_Valley (http://en.wikipedia.org/wiki/Silicon_Valley)

Traffic is slow at times, but Parallax orders·always get here fast 8)