New P2 FPGA Release (link)

Cluso99 · 2014-03-20 03:34

For those of you not following the large thread, Chip has released new FPGA code here...
http://forums.parallax.com/showthread.php/125543-Propeller-II-update-BLOG?p=1251927&viewfull=1#post1251927

cgracey · 2014-03-20 03:36

Cluso99 wrote: »

For those of you not following the large thread, Chip has released new FPGA code here...
http://forums.parallax.com/showthread.php/125543-Propeller-II-update-BLOG?p=1251927&viewfull=1#post1251927

It's only for daredevils, at this point, until the documentation gets updated over the next few days.

ozpropdev · 2014-03-20 03:56

cgracey wrote: »

It's only for daredevils, at this point, until the documentation gets updated over the next few days.

Thanks Chip!

Playing with the new stuff right now.... looks good!

TARG is a TOPONE!

cgracey · 2014-03-20 03:58

ozpropdev wrote: »

Thanks Chip!
Playing with the new stuff right now.... looks good!

TARG is a TOPONE!

TARG instructions redirect the result writing. The names changed, I think, since we last discussed them.

ozpropdev · 2014-03-20 05:13

Hi Chip,
Is the LIFO stack only 18 bits now?

			push	##$FFFFFFFF
			pop	ax

Returns AX = $3FFFF

Baggers · 2014-03-20 05:41

ozpropdev, is that because the #number has to fit into the instruction also?

ozpropdev · 2014-03-20 06:04

Baggers wrote: »

ozpropdev, is that because the #number has to fit into the instruction also?

Hi Baggers

I get the same result for PUSH myreg instead of PUSH ##value.
The last FPGA release allowed 32 bit values to be Push'ed onto the LIFO stack.
ICheers
Brian

Edit: I'm guessing the change was made so LIFO just holds a 16 bit address and the ZC flags.

mindrobots · 2014-03-20 16:06

EDIT: Nevermind, nothing to see here, move along.....problem with the source file versions across multiple PC and a failing memory. Everything works fine.....DON'T PANIC!!!!!

Anybody finding code that ran under the 2/6/14 emulator doesn't run under the 3/20/14 emulator?

It assembles and loads (no changed mnemonic issues, causing unrecognized instructions) but then goes off into the weeds somewhere.

It's the p2pfth that I modified.

I hadn't thought there were any functional changes in the existing instructions (other than the possible PUSH issue above) with this emulation, just additional instructions.

I don't PUSH/POP, I do use PUSHX/POPX/PUSHY/POPY, SERIN/SEROUT.

I checked Dave Hein's original pfth port to the P2 and it didn't appear to work.

I'll go back and recheck things to make sure it's not stupidity (no guarantees there).

Any thoughts?

Thanks!

Bill Henning · 2014-03-20 16:11

Chip reminded me in the other thread that COGINIT/COGNEW have changed to COGRUN / COGRUNX... I don't know if that change was already made on the 2/6/14 image.

I am about to flash the 3/20/14 image, as soon as I find my notes on how to do so

mindrobots wrote: »

Anybody finding code that ran under the 2/6/14 emulator doesn't run under the 3/20/14 emulator?

It assembles and loads (no changed mnemonic issues, causing unrecognized instructions) but then goes off into the weeds somewhere.

It's the p2pfth that I modified.

I hadn't thought there were any functional changes in the existing instructions (other than the possible PUSH issue above) with this emulation, just additional instructions.

I don't PUSH/POP, I do use PUSHX/POPX/PUSHY/POPY, SERIN/SEROUT.

I checked Dave Hein's original pfth port to the P2 and it didn't appear to work.

I'll go back and recheck things to make sure it's not stupidity (no guarantees there).

Any thoughts?

Thanks!

mindrobots · 2014-03-20 16:29

Bill Henning wrote: »

Chip reminded me in the other thread that COGINIT/COGNEW have changed to COGRUN / COGRUNX... I don't know if that change was already made on the 2/6/14 image.

I am about to flash the 3/20/14 image, as soon as I find my notes on how to do so

Bill, do these help for the DE2? It's a REAL product now!

If it's a DE0, I can write something up for you real quick that should jog your memory.

mindrobots · 2014-03-20 16:35

There are 2 blocks of instructions in the document startign with TARGOFF and ending with TARGNX, all are opcode 1111111, the first block start with a S Field of 011100x00 and the second set starts with an S Field of 110100x00.

OK, so the first block allows a D or a # value. the second block doesn't.

I need to go dig through the BLOG thread to find the differences.

Dang, this being adventuresome really taxes the memory!!

FOUND IT!! Except it is TARG instead of RESD

cgracey wrote: »

I have a question for you guys.

You know we have this new RESD D/# instruction that lets you redirect the next result to another register.

What about expanding this capability a little (rdr = task's redirection register):

RESD    D/#    'set rdr to D/#, redirect next write to [rdr]
RESDP    D/#    'set rdr to D/#, redirect next write to [rdr++]
RESDN    D/#    'set rdr to D/#, redirect next write to [rdr--]

RESDX    D/#    'set rdr to D/#, redirect all subsequent writes to [rdr]   until RESDOFF
RESDPX    D/#    'set rdr to D/#, redirect all subsequent writes to [rdr++] until RESDOFF
RESDNX    D/#    'set rdr to D/#, redirect all subsequent writes to [rdr--] until RESDOFF

RESDOFF D/#    'set rdr to D/#, cancel write redirection


RESD        '         redirect next write to [rdr]
RESDP        '         redirect next write to [rdr++]
RESDN        '         redirect next write to [rdr--]

RESDX        '         redirect all subsequent writes to [rdr]   until RESDOFF
RESDPX        '         redirect all subsequent writes to [rdr++] until RESDOFF
RESDNX        '         redirect all subsequent writes to [rdr--] until RESDOFF

RESDOFF        '         cancel write redirection

This scheme takes two more state bits and an incrementer/decrementer on the task's redirection register.

EDIT2: A Question for Chip: Why did the second set not get conditional execution bits (cccc)? If you are conditionally executing the initial set rdr and write, might you not want to conditionally execute the subsequent uses rdr and write operations? Just wondering at this point more than anything.

cgracey · 2014-03-20 16:44

It's true that the LIFO stacks are only 18 bits wide now, for Z/C/PC storage. This reduced the logic by quite a bit (14 bits * 4 levels * 4 tasks = 224 flops per cog).

Bill Henning · 2014-03-20 16:55

THANK YOU!

(mindrobots & Parallax)

I am printing it right now, along with other goodies from the latest zip. Time for me to flash my DE2-115!!!

I am not likely to get to my nano's for a couple of days... so no burning hurry - however I am sure many would appreciate a 'cheat sheet'

Why would I use nano's when I have a DE2?

For hardware experiments. I'd much rather risk a DE0-Nano, of which I have three, instead of my single DE2-115.

mindrobots wrote: »

Bill, do these help for the DE2? It's a REAL product now!

If it's a DE0, I can write something up for you real quick that should jog your memory.

Bill Henning · 2014-03-20 16:57

Definitely worth the change... that's a lot of flops.

cgracey wrote: »

It's true that the LIFO stacks are only 18 bits wide now, for Z/C/PC storage. This reduced the logic by quite a bit (14 bits * 4 levels * 4 tasks = 224 flops per cog).

Bill Henning · 2014-03-20 18:54

Ok, I was able to burn the new fpga image.

Now I just have to convince PNut.exe to find com ports > com9 !

(I remember running into this before as well, but don't remember how to resolve it)

mindrobots · 2014-03-20 19:01

Bill Henning wrote: »

Ok, I was able to burn the new fpga image.

Now I just have to convince PNut.exe to find com ports > com9 !

(I remember running into this before as well, but don't remember how to resolve it)

Post it if you find a solution. I just deleted all my low number com ports and let the DE0s find ones below 9. Guess I'll have to delete a couple when my DE2 shows up to give it a slot.

ozpropdev · 2014-03-20 19:16

The ROM monitor shows the following

' Usage:	cognew($52C, rx_pin << 10 + tx_pin << 2)	'start monitor in new cog

From the Booter I used the following code

			cognew	monitor_pgm

monitor_pgm		long	91 << 24 + 90 << 16 + ($52c >> 2)

Bill Henning · 2014-03-20 19:34

Will do.

For now, I did the same thing - deleted a low number com port.

mindrobots wrote: »

Post it if you find a solution. I just deleted all my low number com ports and let the DE0s find ones below 9. Guess I'll have to delete a couple when my DE2 shows up to give it a slot.

Bill Henning · 2014-03-20 19:39

In preparation for resuming P2 development work, I improved my P2 test setup earlier today.

Here is my new setup:

(click for big pic)

I took a 8"x12" piece of 1/8" styrene

- drilled four 1/8" holes for the DE2-115
- drilled two 1/8" holes for two support standoffs for the P2 video emulation board
- then I added a SchoolBoard ][ to the P2 header (I had to trim longer leads on its bottom)

Now I can play in style :-)

potatohead · 2014-03-20 19:56

In the monitor document in my blog, there are instructions to set the COM port in Device Manager. I'll update that document to reflect changes, but that info is good.

Short story, go into Device Manager, connect your Prop Plug, refresh, and the new device that shows up is the one you want. Pick the properties and set the port.

ozpropdev · 2014-03-21 05:02

Hi All,
Here's some notes on changes I have found in the pin transfer function.
The PTRY initial value is now included in the instruction.

..old release used
			setptry	#$20	
			setxfr	#%1_110_111
..is now
			setxfr	#%1_110_111,#$20

A side effect of the change is when the SETXFR #0,#0 instruction is executed to stop the pin transfer the current PTRY value is lost.
Even issuing a GETPTRY before the SETXFR #0,#0 returns a zero value.
The previous F{GA release (6 Feb 2014) used to leave PTRY intact.
This was useful in determining the sample length by PTRY's current value.
Just FYI

cgracey · 2014-03-21 06:10

ozpropdev wrote: »
Hi All,
Here's some notes on changes I have found in the pin transfer function.
The PTRY initial value is now included in the instruction.
..old release used
			setptry	#$20	
			setxfr	#%1_110_111
..is now
			setxfr	#%1_110_111,#$20
A side effect of the change is when the SETXFR #0,#0 instruction is executed to stop the pin transfer the current PTRY value is lost.
Even issuing a GETPTRY before the SETXFR #0,#0 returns a zero value.
The previous F{GA release (6 Feb 2014) used to leave PTRY intact.
This was useful in determining the sample length by PTRY's current value.
Just FYI

It doesn't use PTRY, anymore. It maintains its own 8-bit counter which gets initialized on every SETXFR.

ozpropdev · 2014-03-21 06:23

cgracey wrote: »

It doesn't use PTRY, anymore. It maintains its own 8-bit counter which gets initialized on every SETXFR.

Thanks Chip.

That makes sense now.

mindrobots · 2014-03-21 14:19

I was trying to build ozpropdev's test tool and PNUT told me there was no longer an ENCOD instruction! Its not in the latest instruction list and I haven't found its replacement in the blog thread. Anybody know what it became?

Brian, do you have an update for your tool you'd like to share? Please??

Thanks, all!

ctwardell · 2014-03-21 14:40

mindrobots wrote: »

I was trying to build ozpropdev's test tool and PNUT told me there was no longer an ENCOD instruction! Its not in the latest instruction list and I haven't found its replacement in the blog thread. Anybody know what it became?

Brian, do you have an update for your tool you'd like to share? Please??

Thanks, all!

It looks like it is BLSIZE now. At least BLSIZE has the same opcode that was ENCOD.

C.W.

Bill Henning · 2014-03-21 15:56

I've run into a funny issue while trying hubexec.

CON

		_rx	= 91
		_tx	= 90

DAT		

		org

		clkset	#$FF		'set 80MHz
		setsera	ser_parms, bit_time
		clrp	#_tx		' Enable _tx pin

		jmp	#hubexec

ser_parms	long	%10 << 16 + _rx << 9 + %10 << 7 + _tx
bit_time	long	80_000_000 / 115200

ch		long	0

padding		long	0[200]

'----------------------------------------------------------------

		orgh

hubexec		locptra #hello_world	' tried both # and @ prefixes, no prefix hangs

'boo		serouta #64
'		jmp	#boo

loop		rdbyte	ch, ptra++ wz
	if_nz	serouta	ch
	if_nz	jmp	#loop

		jmp	#hubexec

hello_world	byte	"Hello World!",13,10,0

It prints garbage instead of "Hello World!"

The commented out "boo" loop works fine.

ozpropdev · 2014-03-21 16:02

mindrobots wrote: »

I was trying to build ozpropdev's test tool and PNUT told me there was no longer an ENCOD instruction! Its not in the latest instruction list and I haven't found its replacement in the blog thread. Anybody know what it became?

Brian, do you have an update for your tool you'd like to share? Please??

Thanks, all!

Hi Rick
The ENCOD instruction has been replaced with a new variant called TOPONE. See here
Because the LIFO is only 18 bits now I had to make a few changes.
I will post an updated version of Toolbox later today.

Cheers
Brian

Dave Hein · 2014-03-21 16:02

Bill, I think you need to use ##@ instead of just # in "locptra #hello_world".

Bill Henning · 2014-03-21 16:09

Thanks David, tried it, does not even compile - which makes sense, ## is used for AUGS/AUGD, and LOCPTR has an embedded 16 bit constant like JMPx/CALLx.

Given that the 'boo' with the constant character out works, I am left scratching my head.

Dave Hein wrote: »

Bill, I think you need to use ## instead of # in "locptra #hello_world".

Bill Henning · 2014-03-21 16:12

Replaced

locptra #hello_world

with

setptra ##hello_world

Still does not work.

ozpropdev · 2014-03-21 16:31

Bill,
Try these changes

after the LOCPTRA #hello_world follow with a ADDPTRA ##$E00

Also a JMP @ switches to HUB exec and a JMP # switches to COG mode.

New P2 FPGA Release (link)

Comments