I still havent gotten it do display in decimal though. Could you please supply a complete command line to add 8 and 9 and display it in decimal instead of hex?
If I could get it to do floating point decimal, I could use it as my calculator instead of bc.
forth evangelism is why folks don't admit to using forth in public, :turn: its the worst in techno-fan-boyism. Hopefully, this is just another cool tool to have fun with
The issue you are having is that the STACK DUMP word
st?
always displays in hex for the convenience of the developers.
What you want to use is the period which is the 'print the first value on the top of the stack' word, as in
21
st?
ST:0000021
8 9 + .
11 cog4 ok
decimal
8 9 + .
17 cog4 ok
st? .
ST:0000021
33 cog4 ok
NOTICE the period appears three times in the above, it doesn't show up well due to fonts
hex/decimal are define on PropForth below:
: hex 10 base W! ;
: decimal A base W! ;
: base C paret ;
: paret par COG@ + ;
There is value"10/A" in Hub memory to pointing by content of cog-memory-address.
Cog6 ok
par COG@ .
B70 Cog6 ok <-- Hub memory on hex (in case of cog6, not other cog)
par COG@ c + W@ . <-- hex (There is address of base value)
10 Cog6 ok <-- hex (base)
Cog6 ok
decimal
par COG@ .
2928 Cog6 ok <-- Hub memory on decimal
par COG@ 12 + W@ . <-- decimal
10 Cog6 ok <-- decimal (base)
I just checked it and tried to write a quick eeprom dump routine even though I found out later it already had one. I looked for number formatting words but couldn't see them from the words listing so I just wrote a quick one for forcing fixed places.
Having the ethernet running on the Prop even with a Wiznet is cool, I have done this before but cheated using an XPORT.
Good work with the Forth too, it's becoming more usable for real apps but I have to play with it a bit more to be able to speak with any authority. Is there a facility to hold all the headers and links in eeprom or elsewhere so as to free up the hub ram for code?
Cog1 ok
: u.n swap <# swap 0 do # loop #> .cstr ;
Cog1 ok
1234 2 u.n
34Cog1 ok
123456 3 u.n
456Cog1 ok
: edump over + swap do i 0f and 0= if cr i 4 u.n ." : " then
i EC@ 2 u.n space
loop ;
Cog1 ok
0 200 edump
0000: 00 B4 C4 04 6F C0 10 00 B0 7F B8 7F DC 7E C0 7F
0010: A0 7F 02 00 CC 7E 04 00 1B 90 FC A0 30 92 FC A0
0020: 43 EC BF 68 48 8E BC 5C F2 85 3C 62 03 00 54 5C
Is there a facility to hold all the headers and links in eeprom or elsewhere so as to free up the hub ram for code?
Cog1 ok
: u.n swap <# swap 0 do # loop #> .cstr ;
Cog1 ok
1234 2 u.n
34Cog1 ok
123456 3 u.n
456Cog1 ok
: edump over + swap do i 0f and 0= if cr i 4 u.n ." : " then
i EC@ 2 u.n space
loop ;
Cog1 ok
0 200 edump
0000: 00 B4 C4 04 6F C0 10 00 B0 7F B8 7F DC 7E C0 7F
0010: A0 7F 02 00 CC 7E 04 00 1B 90 FC A0 30 92 FC A0
0020: 43 EC BF 68 48 8E BC 5C F2 85 3C 62 03 00 54 5C
Thanks for the post. I was hoping you would join. I thought we has number formatting, but it might be in the extensions. As you see the kernel is getting crowded.
Sal has been considering putting parts of the dictionary in eeprom, but not everybody has the larger ones (main test bed is demo board with only 32k) so there is no decision on the best way to go.
I was hoping you could give a suggestion as to a nice way to divide the kernel to use the eprom, and a way to recognize eeprom size. Right now Sal just goes off the end I think.
The current plan to get more room in RAM is: after caskaz and I get SD working, we will put extensions and utilities on SD, and load things on the fly a-la colorFORTH. The kernel would be just enough to do I/O and access the SD, and everything else would be non-persistent/compiled-on-the-fly. I don't know if it will work, but it sounds cool, and Sal says it will be transparent to the user. But we don't have a scheduled availability date for this yet.
Putting stuff in EEPROM would be useful in any case. Any ideas would be appreciated!
My edump revealed that both 32K sections of the maximum 54K eeprom area were mirrored which indicated that you were only using a 32K device. This is always a simple test for eeprom size plus checking acks from eeprom I2C addresses will test for multiple devices (or devices with multiple addresses).
I think that since Forth is not just a runtime VM but a target resident compiler and text interpreter that we should always try to store the headers in anything but the precious hub RAM. My thinking has always been to use byte tokens but 16-bit words are ok. Compiling on the fly complicates things and may benefit from precompiling into intermediate code perhaps.
If someone wants to play with Forth on their demo board then it should work with a standard 32K eeprom but if someone wants to get serious then use at least 64K or SPI Flash chips or SD, the latter being favored for it's universality and huge storage.
Using Spin to compile high-level Forth source is very very messy but necessary for compiling standard library functions into the kernel. I think this aspect alone turns me off writing a Forth for this core(s). But seeing how the headers are defined inline in the Spin source makes it a bit harder to separate them into another file at compile time for inclusion into external memory whether that be outside the 32K of eeprom space or SD etc.
If we could get BradC involved somehow I am sure that he could tweak his BST with the inclusion of new directives etc that would allow us to build these headers into another file plus maybe even improve the writing of high-level code. No more would we have to code like this:
word @emitqNFA + $10
emitNFA byte $84,"emit"
emitPFA word @emitqPFA + $10
word (@a_zbranch - @a_base)/4
word $FFFC
word (@a_litw - @a_base)/4
word $00FF
word @andPFA + $10
word @emitptrPFA + $10
word @WatPFA + $10
word (@a_dup - @a_base)/4
word (@a_zbranch - @a_base)/4
word $0008
word @WbangPFA + $10
word (@a_branch - @a_base)/4
word $0004
word @twodropPFA + $10
word (@a_exit - @a_base)/4
Would then possibly become:
header "emit",emit ' create header in separate header file pointing to emit
' create forth runtime code - calculate branches - calculate kernel or interpreted word values
'
emit fword emitq,zbranch,@emit
fword litw,$00FF,and,emitptr,Wat
fword dup,zbranch,@emit_
fword Wbang,exit
emit_ fword twodrop,exit
These are just my quick thoughts for the moment as I will think further on these points but an improved kernel development environment would certainly make it a lot easier overall and also to create the structures we need to extend the kernel outside of 32K RAM.
Since you are already using the wiznet 5100, and the propeller, why not enter this telnet server, or something more souped up into the Spinernet Design contest?
Have you removed the timeout feature? I could only get into port 25, and now it seems locked up.
I was left connected from last night until this morning on a connection until it locked up.
Have you removed the timeout feature? I could only get into port 25, and now it seems locked up.
I was left connected from last night until this morning on a connection until it locked up.
It should timeout after two minutes of inactivity.
If you don't have "auto-close" on your telnet client, it (your window) might stay up all night
Its working now, so its not broken.
Maybe somebody else was on?
Since you are already using the wiznet 5100, and the propeller, why not enter this telnet server, or something more souped up into the Spinernet Design contest?
It's not really fair, since telnet is so simple and forth is so easy. But we might enter the telnet server if we can't come up with something more useful. Not may people are interested in interactive development and debugging over ethernet, and it wasn't much community colaboration. Sal suggested we (the forth users on the forum) come up with a project idea and work from there. In any case, we should wait until we actually get the spinneret hardware so we can see what it does before make big plans on how to use it. I don't know if the braino-labs purchasing department has ordered the parts yet.
If you (or anybody else) has an idea to explore, it would be fun to have a community project. Of course, I'll be doing my stuff in forth, but we can make low level assembler driver that are callable from spin, I think. The automated shopping list is a really cool idea. Something like that would be fun.
Just another quick thought :smilewinkgrin: but if we could place all the headers together in one contiguous area at the end of memory then we could always access the dictionary via eeprom at the same location but it wouldn't matter if we overwrite the area in RAM.
The headers would not even really need a link field but would need a code pointer instead. As we know the dictionary is only used during the evaluation stage when words are typed in either interactively or from a text file. So then there is no great penalty in reading from eeprom as the evaluate routine scans just the first byte or two of each word looking for a match. Having scanned the first byte with the string count it also knows how to jump to the next word assuming therefore that newer words are added to the descending start of the dictionary.
This method could be adapted to the current version of Forth maybe? I will look into this but Sal obviously knows best in this regard.
I think my thoughts are related. I found myself retyping forth code and was wishing for some persistent store for the dictionary. Maybe a standard one, and a personal one loaded from a file on uSD.
I would also like to see a history mechanism like tcsh has. It would be great to be able to go up to 10 commands back to recompile a word that depends on some other word you just changed.
Please forgive me if this capability is already in there or if I sound like an idiot. I'm only on the 2nd chapter in Starting Forth.
As for the spinnernet module goes, I guess I would be happy with a USB connected propForth environment rather than the more expensive(in price and pins) ethernet connected one.
There is persistent storage in the dictionary, external users (other than me) can't save on MY board over the ethernet, its just a demo. The forth kernel has the saveforth word, which save the entire dictionary so when you reboot, its all right where you left it.
For now, we use the PC to store code in text files, and load it using fast load as in the examples.
I'm working on a command line history, but we have to save it someplace, and caskaz is still working on SD support. Once SD is working, you can save every forth command you ever type in your LIFE on a single 2 gig SD card, along every program you ever write, every build you compile, and pictures of your dog. Unless you have lots of pictures of your dog. Forth code is very small.
Asking for useful functions does not make you sound like an idiot. Admitting you use forth does that by itself
Starting Forth is a good place to start, so you are on the right track.
If you get a demo board, a proto board, or a development board, you can run propforth over serial or USB/serial. The Ethernet is only a special case for remote monitoring and control point nodes on a network.
Thanks everybody that helped test my set up. I'll leave the telnet server running for a bit so folks can play with it.
The discussion is drifting, so the original topic is getting stale.
If anybody has further questions, please PM me. Or start a new thread.
Or If you have ideas for the spineret contest and want to use propforth. Most of the team are interested in participating in a community project (beyond kernel development). Please toss out any idea, no matter how whacky, we will give it consideration.
Comments
forth evangelism is why folks don't admit to using forth in public, :turn: its the worst in techno-fan-boyism.
The issue you are having is that the STACK DUMP word always displays in hex for the convenience of the developers.
What you want to use is the period which is the 'print the first value on the top of the stack' word, as in
NOTICE the period appears three times in the above, it doesn't show up well due to fonts
hex/decimal are define on PropForth below:
: hex 10 base W! ;
: decimal A base W! ;
: base C paret ;
: paret par COG@ + ;
There is value"10/A" in Hub memory to pointing by content of cog-memory-address.
Having the ethernet running on the Prop even with a Wiznet is cool, I have done this before but cheated using an XPORT.
Good work with the Forth too, it's becoming more usable for real apps but I have to play with it a bit more to be able to speak with any authority. Is there a facility to hold all the headers and links in eeprom or elsewhere so as to free up the hub ram for code?
Thanks for the post. I was hoping you would join. I thought we has number formatting, but it might be in the extensions. As you see the kernel is getting crowded.
Sal has been considering putting parts of the dictionary in eeprom, but not everybody has the larger ones (main test bed is demo board with only 32k) so there is no decision on the best way to go.
I was hoping you could give a suggestion as to a nice way to divide the kernel to use the eprom, and a way to recognize eeprom size. Right now Sal just goes off the end I think.
The current plan to get more room in RAM is: after caskaz and I get SD working, we will put extensions and utilities on SD, and load things on the fly a-la colorFORTH. The kernel would be just enough to do I/O and access the SD, and everything else would be non-persistent/compiled-on-the-fly. I don't know if it will work, but it sounds cool, and Sal says it will be transparent to the user. But we don't have a scheduled availability date for this yet.
Putting stuff in EEPROM would be useful in any case. Any ideas would be appreciated!
I just typed it, and left a prompt out. My test rig is not connected to the internet, so I couldn't cut and paste, but you get the general idea.
I think that since Forth is not just a runtime VM but a target resident compiler and text interpreter that we should always try to store the headers in anything but the precious hub RAM. My thinking has always been to use byte tokens but 16-bit words are ok. Compiling on the fly complicates things and may benefit from precompiling into intermediate code perhaps.
If someone wants to play with Forth on their demo board then it should work with a standard 32K eeprom but if someone wants to get serious then use at least 64K or SPI Flash chips or SD, the latter being favored for it's universality and huge storage.
Using Spin to compile high-level Forth source is very very messy but necessary for compiling standard library functions into the kernel. I think this aspect alone turns me off writing a Forth for this core(s). But seeing how the headers are defined inline in the Spin source makes it a bit harder to separate them into another file at compile time for inclusion into external memory whether that be outside the 32K of eeprom space or SD etc.
If we could get BradC involved somehow I am sure that he could tweak his BST with the inclusion of new directives etc that would allow us to build these headers into another file plus maybe even improve the writing of high-level code. No more would we have to code like this:
word @emitqNFA + $10 emitNFA byte $84,"emit" emitPFA word @emitqPFA + $10 word (@a_zbranch - @a_base)/4 word $FFFC word (@a_litw - @a_base)/4 word $00FF word @andPFA + $10 word @emitptrPFA + $10 word @WatPFA + $10 word (@a_dup - @a_base)/4 word (@a_zbranch - @a_base)/4 word $0008 word @WbangPFA + $10 word (@a_branch - @a_base)/4 word $0004 word @twodropPFA + $10 word (@a_exit - @a_base)/4Would then possibly become:header "emit",emit ' create header in separate header file pointing to emit ' create forth runtime code - calculate branches - calculate kernel or interpreted word values ' emit fword emitq,zbranch,@emit fword litw,$00FF,and,emitptr,Wat fword dup,zbranch,@emit_ fword Wbang,exit emit_ fword twodrop,exitThese are just my quick thoughts for the moment as I will think further on these points but an improved kernel development environment would certainly make it a lot easier overall and also to create the structures we need to extend the kernel outside of 32K RAM.I was left connected from last night until this morning on a connection until it locked up.
It should timeout after two minutes of inactivity.
If you don't have "auto-close" on your telnet client, it (your window) might stay up all night
Its working now, so its not broken.
Maybe somebody else was on?
It's not really fair, since telnet is so simple and forth is so easy. But we might enter the telnet server if we can't come up with something more useful. Not may people are interested in interactive development and debugging over ethernet, and it wasn't much community colaboration. Sal suggested we (the forth users on the forum) come up with a project idea and work from there. In any case, we should wait until we actually get the spinneret hardware so we can see what it does before make big plans on how to use it. I don't know if the braino-labs purchasing department has ordered the parts yet.
If you (or anybody else) has an idea to explore, it would be fun to have a community project. Of course, I'll be doing my stuff in forth, but we can make low level assembler driver that are callable from spin, I think. The automated shopping list is a really cool idea. Something like that would be fun.
Your quick thoughts are more on the mark than many of my "thinking about it all week" thoughts.
I'll forward you ideas to Sal, he has said similar things on some of those topics.
Thanks!
The headers would not even really need a link field but would need a code pointer instead. As we know the dictionary is only used during the evaluation stage when words are typed in either interactively or from a text file. So then there is no great penalty in reading from eeprom as the evaluate routine scans just the first byte or two of each word looking for a match. Having scanned the first byte with the string count it also knows how to jump to the next word assuming therefore that newer words are added to the descending start of the dictionary.
This method could be adapted to the current version of Forth maybe? I will look into this but Sal obviously knows best in this regard.
I would also like to see a history mechanism like tcsh has. It would be great to be able to go up to 10 commands back to recompile a word that depends on some other word you just changed.
Please forgive me if this capability is already in there or if I sound like an idiot. I'm only on the 2nd chapter in Starting Forth.
As for the spinnernet module goes, I guess I would be happy with a USB connected propForth environment rather than the more expensive(in price and pins) ethernet connected one.
Take Care,
Doug
There is persistent storage in the dictionary, external users (other than me) can't save on MY board over the ethernet, its just a demo. The forth kernel has the saveforth word, which save the entire dictionary so when you reboot, its all right where you left it.
For now, we use the PC to store code in text files, and load it using fast load as in the examples.
I'm working on a command line history, but we have to save it someplace, and caskaz is still working on SD support. Once SD is working, you can save every forth command you ever type in your LIFE on a single 2 gig SD card, along every program you ever write, every build you compile, and pictures of your dog. Unless you have lots of pictures of your dog. Forth code is very small.
Asking for useful functions does not make you sound like an idiot. Admitting you use forth does that by itself
Starting Forth is a good place to start, so you are on the right track.
If you get a demo board, a proto board, or a development board, you can run propforth over serial or USB/serial. The Ethernet is only a special case for remote monitoring and control point nodes on a network.
The discussion is drifting, so the original topic is getting stale.
If anybody has further questions, please PM me. Or start a new thread.
Or If you have ideas for the spineret contest and want to use propforth. Most of the team are interested in participating in a community project (beyond kernel development). Please toss out any idea, no matter how whacky, we will give it consideration.