A couple of you told me that ptra is the equivalent of par in p1. I have a simple thing that I want to do which is just to take a value and transfer it to another variable and print. Not working here is the simple code from spin2 code. I am not an engineer. Please tell me what I am missing. This is my jump start.
thanks
That's a binary (compiled) not source. The source would be more helpful
So I'm going through the new instructions and I just want to make sure I understand these right.. if I start a cog (fastspin)
PUB start_explicit( DO, CLK, DI, CS ) : card_type
stop
long[@cmd] := "i" 'set flag to know if the started cog has read its parameters
long[@cmd][1] := do | (clk << 8) |( di << 16) | (cs << 24)
long[@cmd][2] := clkfreq
cog := cognew(@_asm_start,@cmd) + 1
if cog
repeat until long[@cmd] <> "i" ' wait until cog is done reading parameter
card_type := long[@cmd][1] ' arg1 returns card type or aborts with ptr to error from low level driver
else ' we don't have a cog?
return @nocogmsg ' probably not a problem so waste of bytes
…
DAT org
_asm_start mov ptr_to_mbox, ptra ' save mbox address for later??
' call #do_pasm_init ' and do all inits
do_pasm_init '' decode pins from first par, 1s from 2nd for init or pin change / clkset
mov ptra, ptr_to_mbox ' return ptra back to mbox
rdlong tmp1, ptra++ ' dummy read, already have ptr to mbox and this won't change
rdlong tmp1, ptra++ ' get pins because these might
mov ptrb,0 ' pins 0 -3
altgb ptrb++, #tmp1 ' set next S field to s+d[10:2], next N to d[1:0]
getbyte pinDO 'get byte into value ('GETBYTE D' = 'GETBYTE D,0,#0')
altgb ptrb++, #tmp1 ' set next S field to s+d[10:2], next N to d[1:0]
getbyte pinCLK 'get byte into value ('GETBYTE D' = 'GETBYTE D,0,#0')
altgb ptrb++, #tmp1 ' set next S field to s+d[10:2], next N to d[1:0]
getbyte pinDI 'get byte into value ('GETBYTE D' = 'GETBYTE D,0,#0')
altgb ptrb++, #tmp1 ' set next S field to s+d[10:2], next N to d[1:0]
getbyte pinCS 'get byte into value ('GETBYTE D' = 'GETBYTE D,0,#0')
rdlong delay1s, ptra++ ' get 1s because this might change
'' got 1 more par
drvh pinCS
drvh pinDI
drvh pinCK
do_pasm_init_ret
ret
'call #do_card_init
_ret_from_cmd
getcmd rdlong cmd_in, ptra wz '
if_z jmp #getcmd 'no cmd so handle time
rdlong arg1_in, ++ptra '
rdlong arg2_in, ++ptra '
rdlong arg3_in, ++ptra '
..
mov cmd_in, #0
wrlong cmd_in, ptr_to_mbox
jmp #getcmd
Is there something i'm missing?? The getbyte example seems messy but I'm rewriting it to use a pointer anyway. Just trying to get some theory on the new instructions.
That's an intuitive idea with PTRA++ but I don't think it's valid. I've just tried it out and am getting assembly errors. Those operations like ++ are exclusive to hubRAM accesses, eg: RDLONG/WRLONG. I'll guess Chip has considered the viability of what you've tried - Presumably the timing of cogRAM accesses will preclude having it without significant redesign of the processor pipeline.
What I've done for the equivalent is to use DJNZ/IJNZ and the likes on the indexing variable. Here's my hexadecimal print routine:
itoh
mov bcdi, #7 'most significant nibble first (zero extended)
.emit
altgn bcdi, #pa '(instruction prefix)
getnib pb 'retrieve next hex digit from pa register: pb = pa[bcdi]
cmp pb, #10 wcz 'test if below 10, C = borrow of (D - S)
if_c add pb, #"0" 'ASCII encode 0-9
if_nc add pb, #"a"-10 'ASCII encode a-f
call #putch
djnf bcdi, #.emit
ret wcz 'restore C/Z flags of calling routine
"... peers into the actual workings of a quantum jump for the first time. The results
reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
—the jumps are neither abrupt nor as random as previously thought."
That's an intuitive idea with PTRA++ but I don't think it's valid.
You mean PRTB right? I'm pretty sure all the PTRA's are right, other than the MOV... I couldn't find any examples of presetting the ptr registers, but since they're just cog ram the move should be valid right? Here's where I'm at now.
PUB start_explicit( DO, CLK, DI, CS ) : card_type
stop
long[@cmd] := "i" 'set flag to know if the started cog has read its parameters
long[@cmd][1] := @DO
long[@cmd][2] := clkfreq
cog := cognew(@_asm_start,@cmd) + 1
if cog
repeat until long[@cmd] <> "i" ' wait until cog is done reading parameter
card_type := long[@cmd][1] ' arg1 returns card type or aborts with ptr to error from low level driver
else ' we don't have a cog?
return @nocogmsg ' probably not a problem so waste of bytes
DAT org
_asm_start mov ptr_to_mbox, ptra ' save mbox address for later
' call #do_pasm_init ' and do all inits
do_pasm_init '' decode pins from first par, 1s from 2nd for init or pin change / clkset
mov ptra, ptr_to_mbox ' return ptra back to mbox
rdlong ptrb, ptra++ ' dummy read, already have ptr to mbox and this won't change
rdlong tmp1, ptrb++ ' get pins because these might
mov pinDO, tmp1
rdlong tmp1, ptrb++ ' get pins because these might
mov pinCLK, tmp1
rdlong tmp1, ptrb++ ' get pins because these might
mov pinDI, tmp1
rdlong tmp1, ptrb++ ' get pins because these might
mov pinCS, tmp1
rdlong delay1s, ptra++ ' get 1s because this might change
'' got 1 more par
drvh pinCS
drvh pinDI
drvh pinCLK
do_pasm_init_ret
' ret
Err, yep, I should have said PTRB, I hadn't even noticed you'd used both.
"... peers into the actual workings of a quantum jump for the first time. The results
reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
—the jumps are neither abrupt nor as random as previously thought."
Comments
That's a binary (compiled) not source. The source would be more helpful
Is there something i'm missing?? The getbyte example seems messy but I'm rewriting it to use a pointer anyway. Just trying to get some theory on the new instructions.
Thanks as always!
What I've done for the equivalent is to use DJNZ/IJNZ and the likes on the indexing variable. Here's my hexadecimal print routine:
reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
—the jumps are neither abrupt nor as random as previously thought."
You mean PRTB right? I'm pretty sure all the PTRA's are right, other than the MOV... I couldn't find any examples of presetting the ptr registers, but since they're just cog ram the move should be valid right? Here's where I'm at now.
reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
—the jumps are neither abrupt nor as random as previously thought."