P2 Documentation TODO's

ozpropdev

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.

cgracey

Next thing up in the documentation is the debug stuff.

Thanks for bringing up these things.

ozpropdev

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

evanh

That input lag will probably not be present in the final silicon. Test using 20 MHz sysclock will prove this.

ozpropdev

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.

evanh

Good to know.

ozpropdev

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

cgracey

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.

ozpropdev

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

Cluso99

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.

ozpropdev

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.