Congratulations Dave - fantastic news!
Is this the first proper high level language to run on the P2? I don't think Spin2 is running properly to claim this title and neither is GCC - is this true guys?
BTW I will update the first post - let me know if it runs on DE0 (no time to test yet). I will also update the latest fpga code link too.
Peter had Tachyon running on the first FPGA release but I don't think he's done any more with it. Waiting for the dust to settle and the paint to dry...or at least get a little tacky.
This is all really exciting having Forth(s), Propgcc and Spin should make for some really great testing of the FPGA and first run chips.
pfth103_p2 works on the Nano as long as I talk to it with the Parallax Serial Terminal (part of Propeller Tool) or puTTY. YAY!!!
If I use TeraTerm, it loads to the Nano and comes up running but set at 115200/8/n/1 the text comes out garbled. If you type in lowercase words you see strange characters and the word list comes back as garbage but it does some back. If you type in numbers, they are fine and +,-, "." all are displayed. I was able to do this ": ADD + . ;" and I saw what I keyed in and the words was defined. When I typed in "34 3 ADD", it came back with the correct answer.
I'll have to look more at how my TeraTerm is configured, it certainly isn't a pfth issue!
That's all I've had time to look at since it's bedtime!
Has anyone implemented an SD driver on P2? I would be interested in using that with the SD version of pfth.
I have been thinking about this too. I thought that Kye's driver might be the best to convert.
IIRC spin 2 is not ready for prime time so I wondered about running the spin to pasm (there is one isn't there?) and then converting to P2 pasm. The pasm driver could be converted relatively easily I think.
I'm puzzled by the mapping of outc to the output pins. The code that drives the serial out pin uses the following bit mask to setup the dirc and outc.
con
tx_pin = 90
...
dat
tx_mask long 1 << (64 - TX_PIN) ' must be in dirc
This results in tx_mask being set to (1 << 6). Why is it defined this way instead of (1 << (90-64)) = (1 < 26)? Is outc bit-reversed with respect to output pins 64 to 95? Is bit 6 in outc mapped to P90?
I'm puzzled by the mapping of outc to the output pins. The code that drives the serial out pin uses the following bit mask to setup the dirc and outc.
con
tx_pin = 90
...
dat
tx_mask long 1 << (64 - TX_PIN) ' must be in dirc
This results in tx_mask being set to (1 << 6). Why is it defined this way instead of (1 << (90-64)) = (1 < 26)? Is outc bit-reversed with respect to output pins 64 to 95? Is bit 6 in outc mapped to P90?
What is the origin of your code example?
Yes, it does not look right.
I'm puzzled by the mapping of outc to the output pins. The code that drives the serial out pin uses the following bit mask to setup the dirc and outc.
con
tx_pin = 90
...
dat
tx_mask long 1 << (64 - TX_PIN) ' must be in dirc
This results in tx_mask being set to (1 << 6). Why is it defined this way instead of (1 << (90-64)) = (1 < 26)? Is outc bit-reversed with respect to output pins 64 to 95? Is bit 6 in outc mapped to P90?
What's stranger is when you look in the Pnut listing , you see $40000000 where this long is which is the correct value for pin 90......
at least it seems to me to be what you get.
00E00- 07 F4 3F 24 07 FC 3F 24 04 20 3C FE 08 20 3C 50 ..?$..?$. <.. <P
00E10- 00 20 7C 9F 09 00 BC FC A0 15 00 00 40 00 00 00 . |.........@...
I think I got the serial code from the original port of pfth that David Betz did. Since the Prop is little endian, I believe the listing is showing 0x00000040.
I think I got the serial code from the original port of pfth that David Betz did. Since the Prop is little endian, I believe the listing is showing 0x00000040.
I think that the serial code I used for my port of pfth came from Chip's monitor.
The latest monitor uses the serial I/O instructions, and it doesn't seem to access the DIRC or OUTC registers. I'm just trying to figure out if "or outc, #1" is the same as "setp #64", or "setp #95". Anybody know the answer? Are the LEDs wired up to the P2 pins on the DE2 board? I guess I can try setting some registers to see what happens.
con
rx_pin = 91
tx_pin = 90
DAT
org 0
tx_shift long (64 - TX_PIN)
tx_mask long 1 << (64 - TX_PIN) ' must be in dirc
tx_shift2 long (TX_PIN - 64)
tx_mask2 long 1 << (TX_PIN - 64)
The first pair, the working mask, give you $00_00_00_40 if you go little-endian (which makes sense as shown by the next example) The second pair (little endian) generates $04_00_00_00 which is what you would expect for pin 90.
I didn't see that code in Chip's monitor sincehe passes tx and rx in the PARM register and shifts them from there for both the bit banged version and the SERIN/SEROUT version. But I remember seeing the code under discussion as an example some place.
The latest monitor uses the serial I/O instructions, and it doesn't seem to access the DIRC or OUTC registers. I'm just trying to figure out if "or outc, #1" is the same as "setp #64", or "setp #95". Anybody know the answer? Are the LEDs wired up to the P2 pins on the DE2 board? I guess I can try setting some registers to see what happens.
Ah yes, I had forgotten that Chip had added the serial I/O instructions after I did that port. Best to use those now I guess.
Well my main question was about how dirx, outx, pinx and setpx map to the pins. I implemented some pin I/O words in pfth, and I think I understand it now. One nice thing about Forth is that it can be used as a programmable monitor that can be used to probe the processor.
I found that LEDs 0 through 11 on the DE2 board are connected to bits 0 through 11 in port B. The OUTB and DIRB registers seem to work as expected. "SETP 32" sets bit 0 in port B. However, it appears that "SETP 32" not only sets bit 0 of OUTB, but also sets bit 0 of DIRB. "CLRP 32" will clear bit 0 in OUTB, and set bit 0 in DIRB. So it appears that the SETPx and CLRPx instructions control both OUTx and DIRx.
I'm not sure where "tx_mask long 1 << (64 - TX_PIN)" came from originally, but it seems to be unnecessary when used with SETPx and CLRPx, and is probably incorrect anyhow. Maybe there was a bit-reversal in an early version of the FPGA.
EDIT: Now I understand what OFFP does. It clears the bit in both OUTx and DIRx, whereas CLRP will clear the bit in OUTx, but set the bit in DIRx. We should add some text in the Prop2_Docs file to describe this.
It's a little late for that. I think we already finished the discussion. Anyhow, I'm not sure where else I would discuss results I was getting from running the code on the FPGA board. I guess from now on I'll avoid this thread and start another one.
Here's a tip for those that are receiving used DE0-Nano breakout boards. If you want to use the prop plug to talk to the terminal app, make sure to remove the eeprom first.
Regardless of the name used most people would figure it out because it's the only chip that's in a socket on the board. I was asking because I thought that with the last release, that problem was fixed and we didn't have to pull out the SPI Flash chip anymore. I can't find reference to that info , so maybe I just dreamed it LOL
I just got a DE0 nano board from Mouser they got them for $86.25, is their somewhere I can get the Emulator add on board for it.
Roadster, as of last report, Parallax wasn't going to make any more of the DE0 add on boards. They had just completed a batch of 20 or so for the DE2 about a month ago.
I had a DE0 add-on and sent it along to someone else since I wasn't really doing video with it and it was needed for the P2 emulations to do video.
The DE0 with the P1+ (new P2) emulation MAY be able to do video without a board - I don't think that's been decided yet.
So, you can currently run the P2 emulations without video (still lots of fun!!), go soliciting to see if anyone has a DE0 add-on they aren't using (Ken may know of some, he was collecting names) if you want to do video with P2 emulations or sit back and wait and see what unfolds wit the new emulations.
The 2014_02_06 P2 emulation is tha latest with full docs.
The 2014_03_24 is the latest but it has minimal docs - basically an up to date instruction list.
I tried the P2 design, I'm able to program the nano board, but I can't get pnut to find the P2, I tried connecting the prop plug with the 2 different drawings that I found I but both don't seem to work, I'll try again tonight
I tried the P2 design, I'm able to program the nano board, but I can't get pnut to find the P2, I tried connecting the prop plug with the 2 different drawings that I found I but both don't seem to work, I'll try again tonight
Comments
Peter had Tachyon running on the first FPGA release but I don't think he's done any more with it. Waiting for the dust to settle and the paint to dry...or at least get a little tacky.
This is all really exciting having Forth(s), Propgcc and Spin should make for some really great testing of the FPGA and first run chips.
pfth103_p2 works on the Nano as long as I talk to it with the Parallax Serial Terminal (part of Propeller Tool) or puTTY. YAY!!!
If I use TeraTerm, it loads to the Nano and comes up running but set at 115200/8/n/1 the text comes out garbled. If you type in lowercase words you see strange characters and the word list comes back as garbage but it does some back. If you type in numbers, they are fine and +,-, "." all are displayed. I was able to do this ": ADD + . ;" and I saw what I keyed in and the words was defined. When I typed in "34 3 ADD", it came back with the correct answer.
I'll have to look more at how my TeraTerm is configured, it certainly isn't a pfth issue!
That's all I've had time to look at since it's bedtime!
Great job!!!
IIRC spin 2 is not ready for prime time so I wondered about running the spin to pasm (there is one isn't there?) and then converting to P2 pasm. The pasm driver could be converted relatively easily I think.
Your thoughts?
Andy
Terasic_DE0_Nano_Prop2_Emulator.pdf
C.W.
What is the origin of your code example?
Yes, it does not look right.
What's stranger is when you look in the Pnut listing , you see $40000000 where this long is which is the correct value for pin 90......
at least it seems to me to be what you get.
Thid code:
con rx_pin = 91 tx_pin = 90 DAT org 0 tx_shift long (64 - TX_PIN) tx_mask long 1 << (64 - TX_PIN) ' must be in dirc tx_shift2 long (TX_PIN - 64) tx_mask2 long 1 << (TX_PIN - 64)Produces:The first pair, the working mask, give you $00_00_00_40 if you go little-endian (which makes sense as shown by the next example) The second pair (little endian) generates $04_00_00_00 which is what you would expect for pin 90.
I didn't see that code in Chip's monitor sincehe passes tx and rx in the PARM register and shifts them from there for both the bit banged version and the SERIN/SEROUT version. But I remember seeing the code under discussion as an example some place.
I found that LEDs 0 through 11 on the DE2 board are connected to bits 0 through 11 in port B. The OUTB and DIRB registers seem to work as expected. "SETP 32" sets bit 0 in port B. However, it appears that "SETP 32" not only sets bit 0 of OUTB, but also sets bit 0 of DIRB. "CLRP 32" will clear bit 0 in OUTB, and set bit 0 in DIRB. So it appears that the SETPx and CLRPx instructions control both OUTx and DIRx.
I'm not sure where "tx_mask long 1 << (64 - TX_PIN)" came from originally, but it seems to be unnecessary when used with SETPx and CLRPx, and is probably incorrect anyhow. Maybe there was a bit-reversal in an early version of the FPGA.
EDIT: Now I understand what OFFP does. It clears the bit in both OUTx and DIRx, whereas CLRP will clear the bit in OUTx, but set the bit in DIRx. We should add some text in the Prop2_Docs file to describe this.
Are you referring to the SPI Flash chip?
As Cluso99 says, yes. SPI Flash, not EEPROM. I'm not sure if that was a habitual mistake or me just being lazy. Either way, sorry for the confusion.
Regardless of the name used most people would figure it out because it's the only chip that's in a socket on the board. I was asking because I thought that with the last release, that problem was fixed and we didn't have to pull out the SPI Flash chip anymore. I can't find reference to that info , so maybe I just dreamed it LOL
Roadster, as of last report, Parallax wasn't going to make any more of the DE0 add on boards. They had just completed a batch of 20 or so for the DE2 about a month ago.
I had a DE0 add-on and sent it along to someone else since I wasn't really doing video with it and it was needed for the P2 emulations to do video.
The DE0 with the P1+ (new P2) emulation MAY be able to do video without a board - I don't think that's been decided yet.
So, you can currently run the P2 emulations without video (still lots of fun!!), go soliciting to see if anyone has a DE0 add-on they aren't using (Ken may know of some, he was collecting names) if you want to do video with P2 emulations or sit back and wait and see what unfolds wit the new emulations.
The 2014_02_06 P2 emulation is tha latest with full docs.
The 2014_03_24 is the latest but it has minimal docs - basically an up to date instruction list.
Aww, shucks! Don't wait! Play with the P2 designs- it's all good fun.
These connections work (thanks to all the contributors)
[h=2]Testing with DE0-Nano without adapter board[/h]