Welcome to the Parallax Discussion Forums, sign-up to participate.

# P2 Documentation TODO's

Posts: 2,372

Now that the P2 silicon is being finalized I thought I would start this thread to assist in the finalizing of the documentation.

Here's a few additions discovered in my recent V32b testing.
DEBUG:
BRK #/D when used in breakpoint mode. (brk #$10 'enable breakpoint on 'brk' (stops after)) e.g. Conditional execution if_z brk #BRK_code BRK gets detected and acted upon when in the pipeline, just prior to the final 2-clock execution stage. This means that the breakpoint is unconditional, though writing the 8-bit BRK value IS conditional. and You can write a cog address to$1FE and the next debug interrupt will go there, bypassing the $1F8 ROM routine?  SKIPF Instruction: Be aware when reading the "skip_call_depth" counter that the value returned includes stack CALL/RET's made within the ISR. also Only these immediate-address branches/LOC are allowed in SKIPF/EXECF/XBYTE sequences where the instruction after may be skipped: JMP #\address CALL #\address CALLA #\address CALLB #\address CALLD PA/PB/PTRA/PTRB,#\address LOC PA/PB/PTRA/PTRB,#\address  TRGINTx instructions: These instructions will trigger an interrupt even if the interrupt is configured as "OFF".  BTW The TRGINTx can take advantage of unused iinterrupts and use them as "interrupt blocking, non stack disturning" CALL's. Melbourne, Australia ## Comments • Posts: 10,733 edited 2018-04-20 - 12:15:21 Next thing up in the documentation is the debug stuff. Thanks for bringing up these things. • Posts: 2,372 BRK modes:  brk ##$800	'make INA/INB read pin states, not RAM


Note: Allow 2 clocks before reading pin states.
		brk	##$800 nop mov pin_state,INB  Melbourne, Australia • Posts: 6,084 That input lag will probably not be present in the final silicon. Test using 20 MHz sysclock will prove this. "There's no huge amount of massive material hidden in the rings that we can't see, the rings are almost pure ice." • Posts: 2,372 evanh wrote: » That input lag will probably not be present in the final silicon. Test using 20 MHz sysclock will prove this. No it's a pipline thing. It's the same @ 20MHz. Melbourne, Australia • Posts: 6,084 Good to know. "There's no huge amount of massive material hidden in the rings that we can't see, the rings are almost pure ice." • Posts: 2,372 When using "fast block move" in a debug ISR to copy cogram contents, the pin state mode seems to be ignored. The INA/INB registers still reflect the debug return address and PC values. My guess this is a shadow ram operation difference. 'copy cogram contents to hub brk ##$800			'pin state mode
loc	ptra,#@cogram_buffer
setq	#511			'fast block move
wrlong	0,ptra
brk	#1

Howeve replacing the above code with a alternate method works fine.
'copy cogram contents to hub

brk	##$800 'pin state mode loc ptra,#@cogram_buffer mov index,#0 rep @.loop,##512 altd index wrlong 0-0,ptra++ add index,#1 .loop brk #1  Melbourne, Australia • Posts: 10,733 ozpropdev wrote: » When using "fast block move" in a debug ISR to copy cogram contents, the pin state mode seems to be ignored. The INA/INB registers still reflect the debug return address and PC values. My guess this is a shadow ram operation difference. 'copy cogram contents to hub brk ##$800			'pin state mode
loc	ptra,#@cogram_buffer
setq	#511			'fast block move
wrlong	0,ptra
brk	#1

Howeve replacing the above code with a alternate method works fine.
'copy cogram contents to hub

brk	##$800 'pin state mode loc ptra,#@cogram_buffer mov index,#0 rep @.loop,##512 altd index wrlong 0-0,ptra++ add index,#1 .loop brk #1  Yes, the fast block move only writes the cog RAM and doesn't pay attention to the INA/INB read status. You need to use discrete instructions for those INA/INB S and D mux's to come into play. Thanks for bringing this up. • Posts: 2,372 An addition to the explanation of relative addressing is needed: "Relative address cannot cross between cog and hub domains." So a hub address <$400 is considered to be in the cog/lut domain.
The two examples below demonstrate this.
'Example #1
dat	org
jmp	#main

orgh	'$400 'hubexec code main mov pa,#7 loop decod pb,pa mov outb,pb waitx ##1_000_000 djnf pa,#loop '<<< Error if hub address <$400
jmp	#main

and
'Example #2

dat	org
loc	ptra,#@pattern	'<<< Doesn't error but fails if hub address < $400 rdlong outb,ptra jmp #$

orgh	'$400 pattern long 7  Melbourne, Australia • Posts: 14,387 edited 2018-05-10 - 13:26:23 ozpropdev wrote: » An addition to the explanation of relative addressing is needed: "Relative address cannot cross between cog and hub domains." So a hub address <$400 is considered to be in the cog/lut domain.
The two examples below demonstrate this.
'Example #1
dat	org
jmp	#main

orgh	'$400 'hubexec code main mov pa,#7 loop decod pb,pa mov outb,pb waitx ##1_000_000 djnf pa,#loop '<<< Error if hub address <$400
jmp	#main

and
'Example #2

dat	org
loc	ptra,#@pattern	'<<< Doesn't error but fails if hub address < $400 rdlong outb,ptra jmp #$
orgh	'$400 pattern long 7  There is a lot more to this than what you have shown. The djnf to #loop will work correctly as a relative. One of the failure points is where the JMP #label is in cog/LUT and in an orgh$FC000 as an example, but the label is in a new DAT and ORGH, but is not out of reach for a relative JMP. Pnut compiles this in error
But the gotcha is if you have multiple blocks of code in hub that can be loaded and run in cog/LUT because they require an ORG 0 statement, and we don't want to waste space filling it up to $400 after the last block to the hubexec code. Also it is valid to have some code that will be further up in Hub that will also be loaded into cog/LUT to run. It's a solvable problem for the future, but it's causing a headache to get right for the final ROM. I am hoping that we've worked around it for now. My Prop boards: Prop OS (also see Sphinx, PropDos, PropCmd, Spinix) Website: www.clusos.com • Posts: 2,372 Cluso99 wrote: » The djnf to #loop will work correctly as a relative. As my code demonstrates ONLY if the hub address is >$3FF.