Forum Update - Announcement about May 10th, 2018 update and your password.

P2 Documentation TODO's


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

  • 10 Comments sorted by Date Added Votes
  • cgraceycgracey Posts: 9,139
    edited April 20 Vote Up0Vote Down
    Next thing up in the documentation is the debug stuff.

    Thanks for bringing up these things.
  • 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
  • That input lag will probably not be present in the final silicon. Test using 20 MHz sysclock will prove this.


    "Are we alone in the universe?"
    "Yes," said the Oracle.
    "So there's no other life out there?"
    "There is. They're alone too."
  • 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
  • Good to know.
    "Are we alone in the universe?"
    "Yes," said the Oracle.
    "So there's no other life out there?"
    "There is. They're alone too."
  • 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
  • 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.
  • 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
    	bmask	dirb,#15
    	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
    	bmask	dirb,#15
    	loc	ptra,#@pattern	'<<< Doesn't error but fails if hub address < $400
    	rdlong	outb,ptra
    	jmp	#$
    
    	orgh	'$400
    pattern	long	7
    
    Melbourne, Australia
  • Cluso99Cluso99 Posts: 13,769
    edited May 10 Vote Up0Vote Down
    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
    	bmask	dirb,#15
    	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
    	bmask	dirb,#15
    	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
    Another problem is JMP #\label from cog/LUT to a label within cog/LUT range. If there is an ORGH between the JMP and label, then a hub absolute address is usually used, and if the ORGH is removed, a cog/LUT absolute address is used. But I have found errors in this process.

    Code outside cog/LUT range seems to work fine, even with just a #label.

    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.
  • Cluso99 wrote: »
    The djnf to #loop will work correctly as a relative.
    As my code demonstrates ONLY if the hub address is > $3FF.
    The point was to highlight the domain crossing gotcha.
    Pnut generates this error otherwise.

    1143 x 611 - 83K
    Melbourne, Australia
Sign In or Register to comment.