I suppose that there are a lot of different ways of using that PAR register, and your Forth is certainly going to be a different architecture than the others.
For PropForth, the PAR points to the beginning of 224 bytes that are tied into a rather interesting internal serial communications structure.
You might download a copy of PropForth v5.03 and look that the beginning portions of the .spin files to see how it is all set up.
There is a one byte register that does the passing, another byte that does signaling ready, two amply circular buffers for i/o, and more.
In PropForth, the PAR appears to point to the same locations that SPIN used for 8 hub ram segments. I wonder a bit how the dictionary weaves its way around these to be contiguous - but it seems that there is actually the optimized kernel dictionary to start with and then quite a few 'pre-allocated' slots for new words that have empty data.
Of course, I may be wrong. It just looks that way to me right now.
You might to a similar peek at Tachyon source code. I have no idea how it does its magic.
Here's the latest update of pfth. This version allows starting additional Forth cogs. The additional cogs should not perform any compilation, and should only execute precompiled words. A Forth cog is started by using the COGNEW or COGINIT word with a pointer to the Forth cog image. The PAR register points to a 5-long structure that specifies the address of the word to be executed, the initial stack pointer and return stack pointer, and the starting addresses of the stack and return stack.
I removed the LMM word and now use a COGX1 word to execute Prop instructions such as COGINIT, COGID, LOCKNEW and LOCKRET. These words are defined in propwords.fth.
I ported Mike Green's basic_i2c_driver to Forth, and this code is in i2c.fth.
I added a demo program that starts up a Forth cog and toggles a pin. This is in toggle.fth.
David
That's ....fantastic
I really got lost in the woods. I could not see a way clear to do it the way you have.
It never occured to me to have a forground cog and have all other cogs running a forth script.
Can space allocated in the dictionary , (by the FG cog) be used to pass data between forground and background cogs. Maye two variables one for data in and one for data out.
I just dowloaded the latesr version, I will try later>
Everything is global in Forth, except for information on the data and return stacks. This allows a variable to be designated as a shared variable, where information could be passed back and forth, or you could use two variables as you suggested. Or you could define a variable space that contains command and data values that are used as a mailbox. Forth is kind of like a Spin program that contains everything in a single object. All variables and functions are global, except for stuff on the stacks.
The toggle demo uses the variable DELAYCNT to control the number of cycles between a toggle. It is initialized to 80 million, but it can be changed by the main cog by doing something like "40000000 delaycnt !". You can also preload the data stack or return stack to do useful things. In the toggle demo I could have loaded a parameter on the toggle cog's stack to tell it how many times to loop before quiting. Since there is nothing on the return stack initially it would have to quit by doing something like "cogid cogstop".
Another possibility is to define a word that stops a cog such as ": stopthiscog cogid cogstop ;", and then put the address of the code for stopthiscog on the return stack. You may have noticed that I have been using the address of a word's entry in the dictionary for its execution token. However, the real execution token should be the address of the body of the word in the case of non-kernel words. I will probably clean this up in the next release. For now, the execution address that is used when starting a Forth cog is obtained by using a combination of TICK and >BODY, such as " ' toggle >body " instead of just " ' toggle ".
Here's the latest update of pfth. This version allows starting additional Forth cogs. The additional cogs should not perform any compilation, and should only execute precompiled words. A Forth cog is started by using the COGNEW or COGINIT word with a pointer to the Forth cog image. The PAR register points to a 5-long structure that specifies the address of the word to be executed, the initial stack pointer and return stack pointer, and the starting addresses of the stack and return stack.
I removed the LMM word and now use a COGX1 word to execute Prop instructions such as COGINIT, COGID, LOCKNEW and LOCKRET. These words are defined in propwords.fth.
I ported Mike Green's basic_i2c_driver to Forth, and this code is in i2c.fth.
I added a demo program that starts up a Forth cog and toggles a pin. This is in toggle.fth.
David
I cannot get 059 to do anything. I use SimpleIDE on an iMac under OSX.... there seems to be no .side file . I had no problem getting 022 and 045 up and running ...
Oh, I forgot to mention an important item in my latest update. I am no longer supporting the C version of pfth. Version 0.59 contains only the PASM version, and it no longer contains the C files or the .side file. The PASM version is much faster and it fits in hub memory. Forth source files are included by adding them to the end of pfth.spin using the FILE directive.
I've been working on adding SD card support. I hope to have that in the next version so that files can be loaded from an SD card. The SPI driver will be loaded by the Spin code prior to starting the Forth cog. pfth will support the FAT file system, and be able to access files written by the host computer. My current code can list the files in the root directory of an SD card, and open a file and print it to the console.
Oh, I forgot to mention an important item in my latest update. I am no longer supporting the C version of pfth. Version 0.59 contains only the PASM version, and it no longer contains the C files or the .side file.
Can you generate the PASM file for pfth using pfth already? Man, that was quick!
Oh, I forgot to mention an important item in my latest update. I am no longer supporting the C version of pfth. Version 0.59 contains only the PASM version, and it no longer contains the C files or the .side file. The PASM version is much faster and it fits in hub memory. Forth source files are included by adding them to the end of pfth.spin using the FILE directive.
I've been working on adding SD card support. I hope to have that in the next version so that files can be loaded from an SD card. The SPI driver will be loaded by the Spin code prior to starting the Forth cog. pfth will support the FAT file system, and be able to access files written by the host computer. My current code can list the files in the root directory of an SD card, and open a file and print it to the console.
Wow! I had missed this transition. I was still thinking that pfth was a C program. I'll have to download the new PASM version and try it out!
@prof_braino, I'm not sure what you mean by generating the PASM file. PASM pfth implements around 45 primitive words in assembly. It starts up a simple Forth interpreter that uses 20 of the 45 words to compile the remaining ANS core words plus several other ANS words. It then adds some Prop-specific words and COMUS words, which are non-standard commonly used words. Since this process only takes about one-half second I've decided not to generate a binary image of the compiled interpreter. Basically, it compiles itself every time it boots up.
@David, I posted the first version of PASM pfth about 2 weeks ago. I decided to drop the C version because it was just too slow and requires and SD card.
Take a look at the readme.txt file if you're interested about how pfth works.
@prof_braino, I'm not sure what you mean by generating the PASM file. PASM pfth implements around 45 primitive words in assembly. It starts up a simple Forth interpreter that uses 20 of the 45 words to compile the remaining ANS core words plus several other ANS words. It then adds some Prop-specific words and COMUS words, which are non-standard commonly used words. Since this process only takes about one-half second I've decided not to generate a binary image of the compiled interpreter. Basically, it compiles itself every time it boots up.
@David, I posted the first version of PASM pfth about 2 weeks ago. I decided to drop the C version because it was just too slow and requires and SD card.
Take a look at the readme.txt file if you're interested about how pfth works.
Thanks Dave! I'm looking over pfth.spin and I can't figure out where you set the TX pin as an output. I don't see any references to dira. What am I missing?
Well, I tried to get pfth working on P2 but without much luck so far. Here is what I got when I loaded and started it:
david-betzs-macbook-pro:pfth-p2 dbetz$ p2load -v pfth.obj -t
Trying /dev/cu.usbserial-A700fKXl
Found propeller version 32
Loading 'pfth.obj' on port /dev/cu.usbserial-A700fKXl
................................
[ Entering terminal mode. Type ESC or Control-C to exit. ]
st @ 0c + c! ;
My guess is that I got the addressing wrong. The first thing I did was move the configuration block down in the file to near where the words are defined. I needed to make the start address the first location in the DAT block. I guess I must have converted the serial code correctly though since I am getting some output. It looks like the stuff at the start of init.fth. What am I supposed to see when pfth starts up?
David
There is a need for front end. ATM it is not possible to edit a line from the console. Parsing space delimited words from TIB should not start until reciept of 0d.
BTW I can't do anything on SDcard, my card slot appears to be damged so SD stuff will have to wait until we go home
after xmas.
I like things like this, especially, since pfth is the simplest version of forth I've ever run across.
I of course compiled it on my osx 10.4 (tiger) system, and immediately started hacking away.
I also went to starting forth by Leo Brodie, and began working my way through the tutorial (again) I do this with every version of forth I find, to see how much it works, and how much it doesn't. So far, except for my needing to put a few definitions into the words.c file, (I didn't load any of the 4th files that are included, I wanted to see how much it could do by itself) I've had very little issues, and in 50+K, this is excellent.
The speed on a pc is not an issue, and I love this thing, especially considering it's mit license, that's just icing on the cake.
I'm no forth guru by any means, but I sure do love a good forth system, and I have a lot of fun with them.
Personally, I'd love to see an os that is written in forth, (not just an interpreter, but an entire os) (maybe a forth stamp?) This pfth is simple, easy to understand, and because of it's simplicity, easy to port.
I for one love it, and thank Dave for releasing it.
I don't expect it to happen, but can you imagine an entire os that is written in forth? Need a word processor, just string some words together in the order of your choice, and poof, instant word processor, spreadsheets, databases, web browsers, anything at all, anyone who wants to can write their own, and there's nothing to lock anyone into anything, because anyone who wants to know how something works has only to view the dictionary, and poof, instant "source" to any program they like.
How more open can it get than that?
Talk about a system specially designed for each individual, every person could have their os designed exactly the way they want, and nobody to tell them the interface must be this way or that way. You want the toolbar on top, change one parameter, and poof, it's on the top, want it on the left, well, move the words around, and there you go.
It's a dream of mine to have something like that. A pipe dream maybe, but still, it doesn't hurt to dream right?
Of course, when you begin talking on an os scale, there'd be no such thing as ansi compatibility, though I guess the base system *could* be ansi compliant, then just toss on all the parts that make an os, and you're all set.
The only other language I've seen that comes close to forth's ability to do this sort of thing is abc, but I've never seen any commercial applications written in abc, though it'd be just as easy to do so. Unfortunately, my abc executable is 350K+, which is nowhere near the 50K pfth comes to, so for now, I'm going to continue to play with pfth and see what I can get it to do.
This fun, Thank you for posting this one Dave.
Well, I tried to get pfth working on P2 but without much luck so far. Here is what I got when I loaded and started it:
david-betzs-macbook-pro:pfth-p2 dbetz$ p2load -v pfth.obj -t
Trying /dev/cu.usbserial-A700fKXl
Found propeller version 32
Loading 'pfth.obj' on port /dev/cu.usbserial-A700fKXl
................................
[ Entering terminal mode. Type ESC or Control-C to exit. ]
st @ 0c + c! ;
My guess is that I got the addressing wrong. The first thing I did was move the configuration block down in the file to near where the words are defined. I needed to make the start address the first location in the DAT block. I guess I must have converted the serial code correctly though since I am getting some output. It looks like the stuff at the start of init.fth. What am I supposed to see when pfth starts up?
Thanks,
David
I'm guessing that the Prop-specific words are messing things up. Comment out the 'file "propwords.fth"' and the 'file "i2c.fth" lines at the end of the pfth.spin.
EDIT: The character string "st @ 0c + c! ;" is from the first line in init.fth, which is the first line that is compiled. It looks like it's reading the line and printing it out, but hangs when it tries to parse it. I'll look at the PASM code to see if any of the pipeline assumptions are violated on the P2.
EDIT2: The code assumes that the object offset is 16, so all hub addresses are stored with "+16" added. If you look at the pfthconfig block at the beginning of the program is contains addesses, such as "long @_xboot1+16". If the object offset is not 16 all of the "+16"s need to be changed to the correct offset.
I'm guessing that the Prop-specific words are messing things up. Comment out the 'file "propwords.fth"' and the 'file "i2c.fth" lines at the end of the pfth.spin.
Good suggestion but there is something more serious wrong with what I did. I moved your configuration structure. Could that have cause a problem? The program now starts like this:
fit $1f0
pfthconfig long @_xboot1+16 ' Initial word to execute
long @stack+16+16 ' Starting stack pointer
long @stack+16+16 ' Empty stack pointer value
long @retstk+16 ' Starting return pointer
long @retstk+16 ' Empty return pointer value
stack long 0[200] ' Data stack
retstk long 0[200] ' Return stack
'*******************************************************************************
' Data stack, return stack, input buffer and hex table
'*******************************************************************************
hexstr byte "0123456789abcdef"
inputbuf byte 0[200]
The "+16" adds the Spin object offset for the top object on P1. I don't know what the object offset would be on the P2. It may be zero, or might be 16, or it might be something else. Whatever it is pfthconfig_addr should use the same offset that is used everywhere else. BTW, the stack pointers in the config structure add an additional 16 bytes to handle stack underflows. These should be "@stack+16+OFFSET", where OFFSET is the object offset.
The "+16" adds the Spin object offset for the top object on P1. I don't know what the object offset would be on the P2. It may be zero, or might be 16, or it might be something else. Whatever it is pfthconfig_addr should use the same offset that is used everywhere else. BTW, the stack pointers in the config structure add an additional 16 bytes to handle stack underflows. These should be "@stack+16+OFFSET", where OFFSET is the object offset.
Okay, I see part of the problem. There is no Spin code in the P2 version so the COG image starts at hub address $0e80. I removed all of the +16 expressions and now I get this output:
david-betzs-macbook-pro:pfth-p2 dbetz$ p2load -v -s pfth.obj -t
Trying /dev/cu.usbserial-A700fKXl
Found propeller version 32
Loading 'pfth.obj' on port /dev/cu.usbserial-A700fKXl
.....................
[ Entering terminal mode. Type ESC or Control-C to exit. ]
okM pfth 0.59
It looks like I'm not handling CR/LF correctly or something because the "ok" prompt is overlaying the initial program banner. Also, I must have messed up the getch function because input characters are not echoing correctly. I guess I'm getting further though. Thanks for your help.
A demo front end taken from my editor, in PF. It may be useful.
fl
hex
80 constant col_max
5 constant line_min
15 constant line_max
variable edbuf 80 allot
wvariable line
wvariable col
: W-! dup W@ rot - swap W! ;
: .digits dup 9 > if a u/mod 30 + emit then 30 + emit ; \ still does not trap chr f > TOFIX)
: cursor 1b emit 5b emit .digits ." ;" .digits ." f" ; \ set cursor, get col and row data from TOS
: cls 1b emit 5b emit ." 2J" ; \ ANSI VT100 clear screen
: db st? key drop ; \ my break point routine to check stack
: clr_buffer col_max 0 do 20 edbuf i + C! loop ; \ clear Editor line buffer in Hub
: cln 0 line W@ cursor col_max 0 do 20 emit loop 0 line W@ cursor ; \ clear next VT100 line
: inc_col 1 col W+! ;
: dec_col 1 col W-! ;
: disp_ln 0 line W@ cursor col W@ 0 do edbuf 1 + i + C@ emit loop
col W@ 1 + line W@ cursor ;
: clr_cursor_eol inc_col line W@ cursor
col_max col W@ - 0 do space loop ;
: wrline edbuf col C@ 2 + hex dump ;
: save_xmem col W@ 1 - edbuf C! edbuf col W@ + line W@ swap C! ;
: <slide col_max col W@ - 0 do edbuf col W@ + 1 + i + dup C@ swap 1 - C! loop ;
: slide> col_max col W@ - 0 do edbuf col_max + 1 - i - C@ edbuf col_max + i - C! loop ;
: esc key dup 5B = if drop key dup
43 = if inc_col else dup
44 = if dec_col then
then
then ;
: sv_chr dup d <> if edbuf col W@ + 1 + C! else drop then ;
: save_chr dup dup dup
0 <> if dup
7F = if col W@ 0 > if drop space <slide dec_col then
else slide> sv_chr inc_col
then
else drop
then ;
: keyin key dup 1B = if esc else save_chr then ;
: ed_accept col_max 0 do keyin dup
d = if leave else dup
1b = if col W@ line W@ cursor
else disp_ln then drop then drop
loop drop ;
: init_edit cls 10 0 cursor c"Front End Demo " .cstr
clr_buffer
0 dup col W!
5 dup line W! cursor
ed_accept
save_xmem ;
A demo front end taken from my editor, in PF. It may be useful.
Okay, I fired up pfth on a C3 and now I think I see what you mean. For one thing, the bad behavior with CR vs CR/LF that I observed on the P2 seems also be true on the C3 with unchanged pfth.spin. So, I assume what you mean by "front end" is something that provides translation from CR to CR/LF as well as providing line editing on input. Those certainly seem to be needed and I'll have to look into your code once I get the pfth.spin code working.
One odd thing though when I loaded pfth.spin on my C3 is that it came up and echoed the entire of the i2c driver source to my terminal. Is that normal?
Here is the getch function that I converted to P2. It doesn't work. Can any of you P2 gurus out there tell me what's wrong?
Dave Hein: Can you tell me if it is okay for getch to trash c and z?
'*******************************************************************************
' Get one character from the input port.
' Input none
' Changes parm, temp, temp1, temp2
' Output parm
'*******************************************************************************
getch rdbyte parm, infileptr wz
if_z jmp #getch1
add infileptr, #1
jmp getch_ret
getch1 getp #RX_PIN wz
if_nz jmp #getch
getcnt temp2
mov temp, bitcycles
shr temp, #1
add temp2, temp
mov temp1, #10
mov parm, #0
:loop waitcnt temp2, bitcycles
ror parm, #1
getp #RX_PIN wc
if_c or parm, #1
djnz temp1, #:loop
rol parm, #8 ' <<<< I originally had 7 here not remembering about the stop bit
and parm, #255
getch_ret ret
bitcycles long CLOCK_FREQ / BAUDRATE
Never mind this question. The rol at the end needs to be by 8 not 7. I had forgotten about the stop bit. Sorry for the false alarm. My getch code works now. However, I still need to know if trashing c in getch and putch is okay. I guess trashing z is because the original version does that.
The problem may be caused by using the WZ with RDBYTE in the first line. Maybe this no longer works on P2. You could add a line after this to check for a zero byte, such as "cmp parm, #0 wz". pfth switches to serial input when it encounters a zero byte in the FILE data.
The word "cr" is defined as " : cr 0d emit ; ". You can change this to " : cr 0a emit ; " or " : cr 0d emit 0a emit ; ". This is defined in init.fth.
On boot up, pfth disables serial out by not setting P30 to an output. P30 is set to an output pin in the first line of version.fth, so that anything after that will be displayed. i2c.fth follows version.fth, which is why it is displayed. You should delete the first line of version.fth in your code.
The problem may be caused by using the WZ with RDBYTE in the first line. Maybe this no longer works on P2. You could add a line after this to check for a zero byte, such as "cmp parm, #0 wz". pfth switches to serial input when it encounters a zero byte in the FILE data.
The word "cr" is defined as " : cr 0d emit ; ". You can change this to " : cr 0a emit ; " or " : cr 0d emit 0a emit ; ". This is defined in init.fth.
On boot up, pfth disables serial out by not setting P30 to an output. P30 is set to an output pin in the first line of version.fth, so that anything after that will be displayed. i2c.fth follows version.fth, which is why it is displayed. You should delete the first line of version.fth in your code.
Great! That solved my problem. Here is pfth running on the DE0-Nano P2 emulation:
david-betzs-macbook-pro:pfth-p2 dbetz$ p2load -v -s pfth.obj -t
Trying /dev/cu.usbserial-A700fKXl
Found propeller version 32
Loading 'pfth.obj' on port /dev/cu.usbserial-A700fKXl
.....................
[ Entering terminal mode. Type ESC or Control-C to exit. ]
PASM pfth 0.59
ok
1 2 + .
3 ok .
And you all thought I wasn't a Forth programmer! :-)
Great! That solved my problem. Here is pfth running on the DE0-Nano P2 emulation:
david-betzs-macbook-pro:pfth-p2 dbetz$ p2load -v -s pfth.obj -t
Trying /dev/cu.usbserial-A700fKXl
Found propeller version 32
Loading 'pfth.obj' on port /dev/cu.usbserial-A700fKXl
.....................
[ Entering terminal mode. Type ESC or Control-C to exit. ]
PASM pfth 0.59
ok
1 2 + .
3 ok .
And you all thought I wasn't a Forth programmer! :-)
Now, to be completely honest, I edited the terminal transcript I posted here. I need another fix similar to the one Dave gave me to make the "cr" word output both CR and LF. It seems when you hit RETURN to complete a Forth expression, no corresponding LF is echoed so the result of evaluating the expression overwrites the original input line. Is there a quick fix for that like the one for the "cr" word?
OK, now you guys have sweetened the P2 Emulation pot a bit too much....
So for development tools on the P2, we now have:
Peanut
pfth
...and possibly Tachyon (Peter's been way too quiet)
interesting....too bad Forth isn't a language!
Well done, David & Dave!!
Well, I've only done minimal work to port pfth to P2. There will have to be new words added to access the new hardware. I also have not yet replaced the multiply and divide code with P2 instructions. That should be pretty easy though.
But, as far as I know, pfth is the first high-level language to run on the Propeller II.
Comments
For PropForth, the PAR points to the beginning of 224 bytes that are tied into a rather interesting internal serial communications structure.
You might download a copy of PropForth v5.03 and look that the beginning portions of the .spin files to see how it is all set up.
There is a one byte register that does the passing, another byte that does signaling ready, two amply circular buffers for i/o, and more.
In PropForth, the PAR appears to point to the same locations that SPIN used for 8 hub ram segments. I wonder a bit how the dictionary weaves its way around these to be contiguous - but it seems that there is actually the optimized kernel dictionary to start with and then quite a few 'pre-allocated' slots for new words that have empty data.
Of course, I may be wrong. It just looks that way to me right now.
You might to a similar peek at Tachyon source code. I have no idea how it does its magic.
I removed the LMM word and now use a COGX1 word to execute Prop instructions such as COGINIT, COGID, LOCKNEW and LOCKRET. These words are defined in propwords.fth.
I ported Mike Green's basic_i2c_driver to Forth, and this code is in i2c.fth.
I added a demo program that starts up a Forth cog and toggles a pin. This is in toggle.fth.
That's ....fantastic
I really got lost in the woods. I could not see a way clear to do it the way you have.
It never occured to me to have a forground cog and have all other cogs running a forth script.
Can space allocated in the dictionary , (by the FG cog) be used to pass data between forground and background cogs. Maye two variables one for data in and one for data out.
I just dowloaded the latesr version, I will try later>
Ron
The toggle demo uses the variable DELAYCNT to control the number of cycles between a toggle. It is initialized to 80 million, but it can be changed by the main cog by doing something like "40000000 delaycnt !". You can also preload the data stack or return stack to do useful things. In the toggle demo I could have loaded a parameter on the toggle cog's stack to tell it how many times to loop before quiting. Since there is nothing on the return stack initially it would have to quit by doing something like "cogid cogstop".
Another possibility is to define a word that stops a cog such as ": stopthiscog cogid cogstop ;", and then put the address of the code for stopthiscog on the return stack. You may have noticed that I have been using the address of a word's entry in the dictionary for its execution token. However, the real execution token should be the address of the body of the word in the case of non-kernel words. I will probably clean this up in the next release. For now, the execution address that is used when starting a Forth cog is obtained by using a combination of TICK and >BODY, such as " ' toggle >body " instead of just " ' toggle ".
David
I cannot get 059 to do anything. I use SimpleIDE on an iMac under OSX.... there seems to be no .side file . I had no problem getting 022 and 045 up and running ...
cheers ... BBR
I've been working on adding SD card support. I hope to have that in the next version so that files can be loaded from an SD card. The SPI driver will be loaded by the Spin code prior to starting the Forth cog. pfth will support the FAT file system, and be able to access files written by the host computer. My current code can list the files in the root directory of an SD card, and open a file and print it to the console.
Can you generate the PASM file for pfth using pfth already? Man, that was quick!
@David, I posted the first version of PASM pfth about 2 weeks ago. I decided to drop the C version because it was just too slow and requires and SD card.
Take a look at the readme.txt file if you're interested about how pfth works.
Thanks,
David
There is a need for front end. ATM it is not possible to edit a line from the console. Parsing space delimited words from TIB should not start until reciept of 0d.
BTW I can't do anything on SDcard, my card slot appears to be damged so SD stuff will have to wait until we go home
after xmas.
Ron
I of course compiled it on my osx 10.4 (tiger) system, and immediately started hacking away.
I also went to starting forth by Leo Brodie, and began working my way through the tutorial (again) I do this with every version of forth I find, to see how much it works, and how much it doesn't. So far, except for my needing to put a few definitions into the words.c file, (I didn't load any of the 4th files that are included, I wanted to see how much it could do by itself) I've had very little issues, and in 50+K, this is excellent.
The speed on a pc is not an issue, and I love this thing, especially considering it's mit license, that's just icing on the cake.
I'm no forth guru by any means, but I sure do love a good forth system, and I have a lot of fun with them.
Personally, I'd love to see an os that is written in forth, (not just an interpreter, but an entire os) (maybe a forth stamp?) This pfth is simple, easy to understand, and because of it's simplicity, easy to port.
I for one love it, and thank Dave for releasing it.
I don't expect it to happen, but can you imagine an entire os that is written in forth? Need a word processor, just string some words together in the order of your choice, and poof, instant word processor, spreadsheets, databases, web browsers, anything at all, anyone who wants to can write their own, and there's nothing to lock anyone into anything, because anyone who wants to know how something works has only to view the dictionary, and poof, instant "source" to any program they like.
How more open can it get than that?
Talk about a system specially designed for each individual, every person could have their os designed exactly the way they want, and nobody to tell them the interface must be this way or that way. You want the toolbar on top, change one parameter, and poof, it's on the top, want it on the left, well, move the words around, and there you go.
It's a dream of mine to have something like that. A pipe dream maybe, but still, it doesn't hurt to dream right?
Of course, when you begin talking on an os scale, there'd be no such thing as ansi compatibility, though I guess the base system *could* be ansi compliant, then just toss on all the parts that make an os, and you're all set.
The only other language I've seen that comes close to forth's ability to do this sort of thing is abc, but I've never seen any commercial applications written in abc, though it'd be just as easy to do so. Unfortunately, my abc executable is 350K+, which is nowhere near the 50K pfth comes to, so for now, I'm going to continue to play with pfth and see what I can get it to do.
This fun, Thank you for posting this one Dave.
EDIT: The character string "st @ 0c + c! ;" is from the first line in init.fth, which is the first line that is compiled. It looks like it's reading the line and printing it out, but hangs when it tries to parse it. I'll look at the PASM code to see if any of the pipeline assumptions are violated on the P2.
EDIT2: The code assumes that the object offset is 16, so all hub addresses are stored with "+16" added. If you look at the pfthconfig block at the beginning of the program is contains addesses, such as "long @_xboot1+16". If the object offset is not 16 all of the "+16"s need to be changed to the correct offset.
And later the configuration structure is here:
fit $1f0 pfthconfig long @_xboot1+16 ' Initial word to execute long @stack+16+16 ' Starting stack pointer long @stack+16+16 ' Empty stack pointer value long @retstk+16 ' Starting return pointer long @retstk+16 ' Empty return pointer value stack long 0[200] ' Data stack retstk long 0[200] ' Return stack '******************************************************************************* ' Data stack, return stack, input buffer and hex table '******************************************************************************* hexstr byte "0123456789abcdef" inputbuf byte 0[200]'******************************************************************************* ' pfth cog code '******************************************************************************* org 0 forth parm mov parm, pfthconfig_addr parm1 rdlong pc, parm parm2 add parm, #4 parm3 rdlong stackptr, parm parm4 add parm, #4 temp rdlong stackptr0, parm temp1 add parm, #4 temp2 rdlong returnptr, parm temp3 add parm, #4 temp4 rdlong returnptr0, parm or dirc, tx_mask jmp #innerloop ' Begin execution pfthconfig_addr long @pfthconfig tx_mask long 1 << (64 - TX_PIN) ' must be in dircDave Hein: Can you tell me if it is okay for getch to trash c and z?
'******************************************************************************* ' Get one character from the input port. ' Input none ' Changes parm, temp, temp1, temp2 ' Output parm '******************************************************************************* getch rdbyte parm, infileptr wz if_z jmp #getch1 add infileptr, #1 jmp getch_ret getch1 getp #RX_PIN wz if_nz jmp #getch getcnt temp2 mov temp, bitcycles shr temp, #1 add temp2, temp mov temp1, #10 mov parm, #0 :loop waitcnt temp2, bitcycles ror parm, #1 getp #RX_PIN wc if_c or parm, #1 djnz temp1, #:loop rol parm, #7 and parm, #255 getch_ret ret bitcycles long CLOCK_FREQ / BAUDRATEA demo front end taken from my editor, in PF. It may be useful.
fl hex 80 constant col_max 5 constant line_min 15 constant line_max variable edbuf 80 allot wvariable line wvariable col : W-! dup W@ rot - swap W! ; : .digits dup 9 > if a u/mod 30 + emit then 30 + emit ; \ still does not trap chr f > TOFIX) : cursor 1b emit 5b emit .digits ." ;" .digits ." f" ; \ set cursor, get col and row data from TOS : cls 1b emit 5b emit ." 2J" ; \ ANSI VT100 clear screen : db st? key drop ; \ my break point routine to check stack : clr_buffer col_max 0 do 20 edbuf i + C! loop ; \ clear Editor line buffer in Hub : cln 0 line W@ cursor col_max 0 do 20 emit loop 0 line W@ cursor ; \ clear next VT100 line : inc_col 1 col W+! ; : dec_col 1 col W-! ; : disp_ln 0 line W@ cursor col W@ 0 do edbuf 1 + i + C@ emit loop col W@ 1 + line W@ cursor ; : clr_cursor_eol inc_col line W@ cursor col_max col W@ - 0 do space loop ; : wrline edbuf col C@ 2 + hex dump ; : save_xmem col W@ 1 - edbuf C! edbuf col W@ + line W@ swap C! ; : <slide col_max col W@ - 0 do edbuf col W@ + 1 + i + dup C@ swap 1 - C! loop ; : slide> col_max col W@ - 0 do edbuf col_max + 1 - i - C@ edbuf col_max + i - C! loop ; : esc key dup 5B = if drop key dup 43 = if inc_col else dup 44 = if dec_col then then then ; : sv_chr dup d <> if edbuf col W@ + 1 + C! else drop then ; : save_chr dup dup dup 0 <> if dup 7F = if col W@ 0 > if drop space <slide dec_col then else slide> sv_chr inc_col then else drop then ; : keyin key dup 1B = if esc else save_chr then ; : ed_accept col_max 0 do keyin dup d = if leave else dup 1b = if col W@ line W@ cursor else disp_ln then drop then drop loop drop ; : init_edit cls 10 0 cursor c"Front End Demo " .cstr clr_buffer 0 dup col W! 5 dup line W! cursor ed_accept save_xmem ;code saves in edbuf.
Okay, I fired up pfth on a C3 and now I think I see what you mean. For one thing, the bad behavior with CR vs CR/LF that I observed on the P2 seems also be true on the C3 with unchanged pfth.spin. So, I assume what you mean by "front end" is something that provides translation from CR to CR/LF as well as providing line editing on input. Those certainly seem to be needed and I'll have to look into your code once I get the pfth.spin code working.
One odd thing though when I loaded pfth.spin on my C3 is that it came up and echoed the entire of the i2c driver source to my terminal. Is that normal?
Never mind this question. The rol at the end needs to be by 8 not 7. I had forgotten about the stop bit. Sorry for the false alarm. My getch code works now. However, I still need to know if trashing c in getch and putch is okay. I guess trashing z is because the original version does that.
The word "cr" is defined as " : cr 0d emit ; ". You can change this to " : cr 0a emit ; " or " : cr 0d emit 0a emit ; ". This is defined in init.fth.
On boot up, pfth disables serial out by not setting P30 to an output. P30 is set to an output pin in the first line of version.fth, so that anything after that will be displayed. i2c.fth follows version.fth, which is why it is displayed. You should delete the first line of version.fth in your code.
So for development tools on the P2, we now have:
Peanut
pfth
...and possibly Tachyon (Peter's been way too quiet)
interesting....too bad Forth isn't a language!
Well done, David & Dave!!
Well, I've only done minimal work to port pfth to P2. There will have to be new words added to access the new hardware. I also have not yet replaced the multiply and divide code with P2 instructions. That should be pretty easy though.
But, as far as I know, pfth is the first high-level language to run on the Propeller II.
Not bad considering this thread started on 10/31 as a try at a C based ANS Forth...and now it's a viable tool to start developing on the P2.