Being able to interact with the hardware is always rewarding and you can investigate, discover and understand more about the hardware. Take for instance the counters, what happens if we do this....or that. Yes, of course we could write some code in Spin, compile, download and find out. But that's slow. Here's how we do it in Tachyon Forth:
: CTR ( -- addr ) CTRA #29 REG C@ + ;
: CTR! ( val -- ) CTR COG! ;
: CTR@ ( -- val ) CTR COG@ ;
: A 0 #29 REG C! ;
: B 1 #29 REG C! ;
: CTRMODE ( n -- ) #26 SHL CTR@ $1F #26 SHL ANDN OR CTR! ;
: PLLDIV ( n -- ) #23 SHL CTR@ 7 #23 SHL ANDN OR CTR! ;
: APIN ( pin -- ) DUP MASK OUTPUTS CTR@ $1F ANDN OR CTR! ;
: BPIN ( pin -- ) DUP MASK OUTPUTS 9 SHL CTR@ $1F 9 SHL ANDN OR CTR! ;
: FRQ ( n -- ) FRQA #29 REG C@ + COG! ;
: NCO 4 CTRMODE ;
: DUTY 6 CTRMODE ;
{ Some sample code here that you can type in interactively.
A 4 CTRMODE #100,000 FRQ #19 APIN
B 4 CTRMODE #100,100 FRQ #19 APIN
BEGIN #90,000 #20,000 ADO I FRQ LOOP KEY? AND UNTIL
\ to turn them off
OFF A CTR!
OFF B CTR!
}
I connected a piezo transducer (or connect to your audio amp) onto pin 19, typed in the code I have in curlys and I had to run outside to check for aliens. Then my wife came rushing in all alarmed! (she thought I was being abducted)
Yes, of course we could write some code in Spin, compile, download and find out.
I am using PropForth, but the question pertains to both Forth's. How do you write some code in Forth, compile, download and watch the LED blink? Can something like that be done, or are you locked into the interactive mode? If you are locked into the interactive mode, then it seems like you would have to have a Forth run like an OS.
I am using PropForth, but the question pertains to both Forth's. How do you write some code in Forth, compile, download and watch the LED blink? Can something like that be done, or are you locked into the interactive mode? If you are locked into the interactive mode, then it seems like you would have to have a Forth run like an OS.
Ray
Well you can't blink the LED from the "command line" in PropForth because looping is involved. However since Tachyon compiles each word as it arrives then executes the built-up code once the line is entered we can "cheat" and have loops while still in interactive mode. Normally you would have to create a word (new definition) and then invoke the word by it's name. Now to blinking leds, did you read that section in my Intro page? You should get a pretty good idea about how it works. I'm not sure why you think Forth is locked in interactive mode though??? Haven't there been scores of examples here and there? So don't just check the Intro page, go and read it and better still load Tachyon into a board and follow along.
I've been reading your posts on the development of TACHYON with great interest and just want to commend you on a tremendous and remarkable effort - please continue :-)
Alas, I don't get a lot of "play" time and haven't for quite a long time now but I try to keep up with what's happing in and around this most clever silicon chip. I have alse been experimenting with Sal's PropForth to a limited degree and this too is remarkable - well done Sal.
In any case, just thought I'd throw these comments into the mix because it seems to me that many folk (like me) seem to have a large hurdle getting Forth to do anything so to follow on like a few earlier posts - here's a A$0.02 sample:
My own interpretation of Forth is that it is neither an OS or a language per se but a functional development environment with which the user/programmer develops their own vocabulary to address the specific needs of the project at hand. Having said this it seems most important to understand what the issue being addressed is and therefore what "words" are chosen to perform the required task-at-hand. I feel this is why many folk shy away because most programming disciplines are based on a more "formal" set of language specific semantics. Forth doesn't really have any but can if this is how the programmer designed their system - the system being the implementation of the project.
In addition to your code in post 152, specifically the set up of the counters and so forth, an earlier version of PropForth included a set of definitions, using the counters like you have, to define easy access for use with the COG counters (these can still be defined just as they were but are not in the current version I have loaded).
These words were "setHza" and "setHzb" and as their names imply:
16 5 setHza
20 15 setHzb
would set pin 16 pulsing at 5 Hertz and pin 20 at 15 Hertz concurrently using both counters in a single COG. Rather cool I must say :-)
Anyway, in response to Rsadeika's post # 153: here is a sample that I came up with - hopefully fairly self explanatory - apologies if not. I was thinking maybe a new Subject called "Forth Code Snippets" may be appropriate so feel free to move this post elsewhere.
The following is for a Parallax RPM (Rapid Prototype Module) using PropForth - it's a bit different to the usual demo board - in particular, the included LED's - 10 of them are inverted WRT their signalling so for the following, the "on" and "off" definitions need to be swapped.
: on dup pinout pinlo ; \ ( n -- ) Set pin to output and enable
: off dup pinhi pinin ; \ ( n -- ) Disable pin and set to input
: delay 500 delms ; \ ( -- ) Delay for 500 milliseconds
: flash dup on delay off delay ; \ ( pin -- ) Pulse PIN once with 500 ms duration
: flashes 0 do dup flash loop drop ; \ ( pin iterations -- ) Pulse PIN for number of ITERATIONS
: sweepup 16 10 0 do dup i + flash loop drop ; \ ( -- ) Pulse pins from pin 16 through 16 + 9
: sweepdn 25 10 0 do dup i - flash loop drop ; \ ( -- ) Opposite of sweepup
: sweepupdn sweepup sweepdn ; \ ( -- ) Guess what this does
Usage:
Any word as above - provide the indicated parameter(s).
Example: 16 5 flashes
Will flash pin 16 5 times with a 500 ms cycle time
Finally for this the PropForth "saveforth" words would write the above back to EEPROM so they survive reset/power cycles.
Peter, apologies for not providing this in TACHYON but ... :-)
I've been reading your posts on the development of TACHYON with great interest and just want to commend you on a tremendous and remarkable effort - please continue :-)
Alas, I don't get a lot of "play" time and haven't for quite a long time now but I try to keep up with what's happing in and around this most clever silicon chip. I have alse been experimenting with Sal's PropForth to a limited degree and this too is remarkable - well done Sal.
In any case, just thought I'd throw these comments into the mix because it seems to me that many folk (like me) seem to have a large hurdle getting Forth to do anything so to follow on like a few earlier posts - here's a A$0.02 sample:
My own interpretation of Forth is that it is neither an OS or a language per se but a functional development environment with which the user/programmer develops their own vocabulary to address the specific needs of the project at hand. Having said this it seems most important to understand what the issue being addressed is and therefore what "words" are chosen to perform the required task-at-hand. I feel this is why many folk shy away because most programming disciplines are based on a more "formal" set of language specific semantics. Forth doesn't really have any but can if this is how the programmer designed their system - the system being the implementation of the project.
In addition to your code in post 152, specifically the set up of the counters and so forth, an earlier version of PropForth included a set of definitions, using the counters like you have, to define easy access for use with the COG counters (these can still be defined just as they were but are not in the current version I have loaded).
These words were "setHza" and "setHzb" and as their names imply:
16 5 setHza
20 15 setHzb
would set pin 16 pulsing at 5 Hertz and pin 20 at 15 Hertz concurrently using both counters in a single COG. Rather cool I must say :-)
Anyway, in response to Rsadeika's post # 153: here is a sample that I came up with - hopefully fairly self explanatory - apologies if not. I was thinking maybe a new Subject called "Forth Code Snippets" may be appropriate so feel free to move this post elsewhere.
The following is for a Parallax RPM (Rapid Prototype Module) using PropForth - it's a bit different to the usual demo board - in particular, the included LED's - 10 of them are inverted WRT their signalling so for the following, the "on" and "off" definitions need to be swapped.
: on dup pinout pinlo ; \ ( n -- ) Set pin to output and enable
: off dup pinhi pinin ; \ ( n -- ) Disable pin and set to input
: delay 500 delms ; \ ( -- ) Delay for 500 milliseconds
: flash dup on delay off delay ; \ ( pin -- ) Pulse PIN once with 500 ms duration
: flashes 0 do dup flash loop drop ; \ ( pin iterations -- ) Pulse PIN for number of ITERATIONS
: sweepup 16 10 0 do dup i + flash loop drop ; \ ( -- ) Pulse pins from pin 16 through 16 + 9
: sweepdn 25 10 0 do dup i - flash loop drop ; \ ( -- ) Opposite of sweepup
: sweepupdn sweepup sweepdn ; \ ( -- ) Guess what this does
Usage:
Any word as above - provide the indicated parameter(s).
Example: 16 5 flashes
Will flash pin 16 5 times with a 500 ms cycle time
Finally for this the PropForth "saveforth" words would write the above back to EEPROM so they survive reset/power cycles.
Peter, apologies for not providing this in TACHYON but ... :-)
Kind regards,
Thanks for your comments.
Looking at the way PropForth is coded and how it would be done in Tachyon one of the immediate things many might notice is that I use a lot of UPPERCASE words. I like to reserve UPPERCASE for action words and lowercase for variables and subroutines of functions etc. The other thing is that if I can choose a word that's short and sweet and understandable then I do so. For instance you have a word just for delay whereas I would just code in "500d ms" right where I need it although I do understand why you might direct it to one word but then that could benefit with a variable. Also you have words "on" and "off" just for setting and clearing an I/O pin. Rather a waste of a good general-purpose modifier so I already have ON and OFF as constants passed to action words. So I would perhaps say things like "ON I OUT" or "OFF I OUT" to turn an output on or off or anything else. That is also why I have words such as OUTSET and OUTCLR in that we should be able to see that they SET or CLR the OUTPUTS. If they are OUTPUTS then it also makes sense to make sure that the DIR register is set which is what they do automatically (after writing to the OUT register).
Also do loops could very well be simplified like this:
: SWEEPUP ... 16 8 ADO I FLASH LOOP ;
This is a much better way to code as it avoids unnecessary clutter and is also more efficient. I made up ADO for the sake of a better word at present rather than continually writing BOUNDS DO which converts "from for" into a "to from" form. Notice that the index is the value rather than added to the value, much simpler and clearer.
BTW, my counter words are expanded upon in EXTEND.fth and rather than typing in a rather awkward word such as "decimal 1000 setHzA" as you would in PropForth I type in "1000d KHZ" which is readily understood and the selection of A and B are latched with "A" or "B" anywhere before the action wordas is the output pin (APIN). Unless some thought is given as to how others might read it rather than just getting it functional then Forth (not the programmer) will be criticized for it's readability as a "write-only" language.
EDIT: If you try the toggle pin exercise I described earlier in PropForth rather than Tachyon you will find that it runs very slow compared even to Spin so it's probably best to show Tachyon code on this thread.
How compatible are the PropForth and Tachyon Forth dialects? Last fall I spent time learning gforth and PropForth and while they are similar, a porting effort is required due to dialect differences.
Forth seems interesting, but I haven't really done anything major with it yet. Unfortunately I know Algol family languages too well and it is easier for me to work with Spin than to think Forth. The self hosting remote programmability is pretty neat, especially when coupled with a wireless link.
If this was a PC Forth then there should be a very high degree of compatibility as there are also the ANSI standards. But since this is the Propeller we are talking about then there are aspects of the Prop that Forth needs to take into account just as Spin does also. I have my own philosophy which influences Tachyon too as does the Propeller. My initial reasons and goals for Tachyon was not to sacrifice any low-level speed in trying to introduce more advanced features. Forth is advantageous for direct low-level access which is also why the I/O words are tweaked to suit the Prop and implementing bit-bashed interfaces. The other requirement I had was to be able to compile a complete kernel in seconds with one simple keystroke with any further enhancements being loaded in the normal Forth fashion by means of the kernel itself. PropForth although being rather slow for my use is really neat though with it's advanced features and serial channels for multiprocessing.
What I find more amazing than Forth on the Propeller though is why more people have not taken the time to discover it's huge potential for us Prop heads. I'm only talking about one lousy hour here, not months. (Stop kicking the tires, jump in and take it for a drive)
That's all I do...which reminds me, I need to go and double check the VGA side of things again. If you do happen to leave the VGA active then it doesn't really matter for the moment unless you need access to P16..23. So it might be a good idea if I can make the VGA switchable.
If this was a PC Forth then there should be a very high degree of compatibility as there are also the ANSI standards. But since this is the Propeller we are talking about then there are aspects of the Prop that Forth needs to take into account just as Spin does also. I have my own philosophy which influences Tachyon too as does the Propeller.
I understand PC Forth compatibility, but PropForth and Tachyon are both on the Propeller. Do they have a similar dialect given the same architecture?
I admit it, I use and like SimpleIDE. So, what does that have to do with anything, especially this thread? I went past the "tire kicking" stage, and decided to give TACHYON a run. I used SimpleIDE to compile, and burn the EEPROM, which occurred without any problems. The big problem is, it is not behaving very well with the serial terminal, even when set to the required 57600 BAUD. I used PST, and I get nothing, it takes a key press, but nothing happens which includes the typing of a few gibberish characters, and expecting an error message. When I run PropForth with identical conditions, it works. I also have a personal serial terminal program, which works with PropForth, but all I get with TACHYON is a screen that has '??????' symbols.
If I can make a suggestion, if you could setup TACHYON in such a way that it would run on SimpleIDE, using the built in Console window, it could simplify the interaction with TACHYON, maybe more people would be willing to take it for a test run. Or maybe I am having a big problem with trying to get your program to work, and it is my own personal problem. Just a suggestion.
I understand PC Forth compatibility, but PropForth and Tachyon are both on the Propeller. Do they have a similar dialect given the same architecture?
Yes ... and No ... There are hard core Forth manipulatives that are the same ... DROP, DUP, ROT, IF, AND, OR and so on. But then something simple like a pause, PropForth says "100 delms" to wait 100 msecs where as Tachyon says "100 ms" ... a small issue, but in my rarely very humble opinion point to Tachyon, in this case I think more readable. Then there are the Propellor uniquenesses, different names. Both sets of names pretty much obvious, but different approaches.
Sal and the Prof have delivered to us a vast package that I think most any noob can follow the tutorials and get running and learn from ... a Rolls Royce if you will. Peter on the other hand has given us a lean fast Jaguar with a seat almost right on top of the engine. Its a little short on features compared to PF but it has a strong foundation on which to build.
I have finally been able to spend time with TACHYON. I very much like the features you have built in this forth version. However, I
have some questions relating to cog usage.
For example, suppose I wished to run two different versions of the UFO counter example in two different cogs. How would I do this?
PropForth has the cogx word which allows one to specify cogs and assign them to specific words. While you have a STOP cog word,
I can find no equivalent START cog word in the dictionary.
I have finally been able to spend time with TACHYON. I very much like the features you have built in this forth version. However, I
have some questions relating to cog usage.
For example, suppose I wished to run two different versions of the UFO counter example in two different cogs. How would I do this?
PropForth has the cogx word which allows one to specify cogs and assign them to specific words. While you have a STOP cog word,
I can find no equivalent START cog word in the dictionary.
NickL
Since Tachyon is still a baby it hasn't yet developed the ability to run in multiple cogs. It's easy enough to have it launch into several cogs at startup, I just have have to make sure that all the controls are in place to have them idling until I pass control to them. Perhaps Tachyon will develop this ability after the next feeding and burping
Hi.
I think TACHYON is very interesting.
Sorry, but I don't use TACHYON, because many basic word is UPPERCASE letter.
English(alphabet) is foreign langauge for me.
I cannot continue to read statement using all UPPERCASE letter.
So I cannot write codes on TACHYON.
Hi.
I think TACHYON is very interesting.
Sorry, but I don't use TACHYON, because many basic word is UPPERCASE letter.
I cannot continue to read statement using UPPERCASE letter.
So I cannot write codes on TACHYON.
Maybe English is foreign langauge for me.
You don't have to use Tachyon at all, that's up to you. If it really is for the reason you stated then perhaps it's better that you don't, Tachyon will still be what it is. Perhaps because of the influence of C and other languages we seem to have "lost" the use of uppercase, why is that? I have previously mentioned why I use uppercase and this immediately allows me to see a word like "WASH" vs "wash" and know that one is an action while the other is a variable. Should we also document in lower case without bold headings and color etc? I'm glad we don't.
BTW, Tachyon is not just interesting, it is very fast, especially compared to PropForth. Languages are not a matter of loyalty or tradition, they are a matter of necessity.
Since Tachyon is still a baby it hasn't yet developed the ability to run in multiple cogs. It's easy enough to have it launch into several cogs at startup, I just have have to make sure that all the controls are in place to have them idling until I pass control to them. Perhaps Tachyon will develop this ability after the next feeding and burping
OK, since the forth kernel resides in cog 1, the cog words and registers only apply to cog 1. This means a that cogdump, for example, only dumps data from cog 1.
If I wanted to add words which would control servos, I could include an existing spin/pasm servo object in the Tachyon spin program as well as the required global variables.
The necessary servo control words could then be written in forth.
Yes, just as the serial and VGA object have been included but with Forth controls. I don't envisage any problems in running Forth from multiple cogs and I may look into it in the next few days.
I spoke with Sal about Tachyon at yesterday's meeting, we are winding down development as we near release. He has some free time, so he said he can give comments if you are interested. In the few minutes we looked at it, he got a better understanding than I got in the last several weeks.
He's most interested in the design decisions you made in Tachyon that are different from propforth, and how they pan out. Sal had examined Cliffe Biffle's propellerforth and decided to do many things different, as Sal's goals were different from Cliffe's. Tachyon has made some choices more similar to propellerforth, and it will be interested to compare the benefits and drawbacks of each method. Currently the assumption is that both tools are designed for different purposes and this accounts for differences. For us it would be best to determine if we ought to do something "a better way" now before we get much further in the release. Review is a good way to find the reasoning behind the choices.
His first comment was"Well, this is going to be fast as all get out for the bit-banging stuff!".
Are you interested in getting more comments and questions? I think he said he'd send some by email if you want.
I made a point of not looking at any other code too closely, or even much at all. I wasn't too sure how it would all pan out, I just basically jumped in feet first and got the VM running and built on that. Along the way I changed things both from a runtime point of view and also from a Spin tool compile point of view. The Spin tool is one of our many constraints besides the Prop's architecture and I didn't want to fight it too much, just work along with it.
So okay, go shoot, but please be gentle, I might cry like a 6 week old baby
Scenario #1 - Demo Board, fresh load 120810.1730, fresh load of EXTEND.fth 120810.2150, fresh load of VGA.fth (No date but most recent)
Observations
1 - while VGA.fth was loading. Screen turned blue then two bands of white appeared ... the bottom fixed, the top grew pixel by pixel while the code was loading,
2 - when done I typed "DEMO" and it reset.
...
: VGA ' VEMIT >PFA uemit W! ; ok
ok
ok
END
End of source code, there were 0 errors found
CODE @$3174 - bytes used in this load = 846
NAMES @$1A31 - bytes used in this load = 174
XCALLS @ 30 entries free (not including YCALLS) ok
ok
DEMO
Propeller .:.:--TACHYON--:.:. Forth V1.0 rev120810.1730
----------------------------------------------------------------
ok
* * * * * * * * * * * * * *
Scenario #2 - All the same except Prop Board was a PPDB
Observations - same as above
* * * * * * * * * * * * * * *
Scenario #3 - same as #1 and #2 except board was a Propeller platform, with Wulfden VGA-A/V board
I spoke with Sal about Tachyon at yesterday's meeting, we are winding down development as we near release. He has some free time, so he said he can give comments if you are interested. In the few minutes we looked at it, he got a better understanding than I got in the last several weeks.
He's most interested in the design decisions you made in Tachyon that are different from propforth, and how they pan out. Sal had examined Cliffe Biffle's propellerforth and decided to do many things different, as Sal's goals were different from Cliffe's. Tachyon has made some choices more similar to propellerforth, and it will be interested to compare the benefits and drawbacks of each method. Currently the assumption is that both tools are designed for different purposes and this accounts for differences. For us it would be best to determine if we ought to do something "a better way" now before we get much further in the release. Review is a good way to find the reasoning behind the choices.
His first comment was"Well, this is going to be fast as all get out for the bit-banging stuff!".
Are you interested in getting more comments and questions? I think he said he'd send some by email if you want.
Hi Prof, are you gonna gives us the skinny on the Sunday Call with Sal, (in the propforth thread) it's been required reading for me ever since it started. I want both versions: Full blown Forth, PropForth, and peddle to the metal Tachyon.
So, I finally got Tachyon working. For some of the beginners, you want to download the binary, and have it auto downloaded to the EEPROM, it took me awhile but I figured it out. Now, do I like it ...
Scenario #1 - Demo Board, fresh load 120810.1730, fresh load of EXTEND.fth 120810.2150, fresh load of VGA.fth (No date but most recent)
Observations
1 - while VGA.fth was loading. Screen turned blue then two bands of white appeared ... the bottom fixed, the top grew pixel by pixel while the code was loading,
<snip>
Hi Brian, welcome to the bleeding edge, it's a fun ride but it gets a little bumpy! I had said that I would get around to it but unfortunately that didn't happen until now. The main problem is that I need more memory, especially as I am developing and I haven't yet squeezed the kernel up. So at the present now that I have expanded both the kernel and extensions without any optimizations I end up with free space from about $3700. Obviously the VGA.fth DEMO sets the pixel buffer at $3000 and what is happening is that this directly overwrites the code. So I've changed the calculation for the pixel buffer and made it relative to the current free space. There's also been a change in the kernel since in that the PLOT primitive used to be locked to 64 bytes per line as a shift constant of 6 but now that setting is programmable and is set via 3 COGREG! (I will come up with a better name). So I have updated the DEMO with these two small changes and it works fine on the latest kernel although of course there will be junk at the top and bottom of the screen which can be blanked by setting this tiles to the same foreground and background color.
The junk at the bottom of the screen is actually the ROM has the VGA driver reads pixels from memory sequentially and the pixel buffer overlaps ROM. The kernel has been growing as I have been adding more and more functions yet it is still very lean and faster and smaller than Spin code. So as I mentioned, the kernel will be compacted through reuse and keeping the user part of the dictionary in EEPROM etc and then there will be more memory again for the VGA display.
So, I finally got Tachyon working. For some of the beginners, you want to download the binary, and have it auto downloaded to the EEPROM, it took me awhile but I figured it out. Now, do I like it ...
Ray
I did a bit of a walk through video with compiling the source from the online pages but do you think there were some tricks to compiling even just the binary? What happened that it wasn't so smooth? Now do you like it.....??? (Remember this will eventually be a complete stand-alone as well as a lean target kernel)
There's been quite a few more features as I go through my testing and improvements which concentrates on porting applications across to TACHYON and then looking at what I need to do to make the kernel better etc. As I am still testing my CASE .... OTHER features I did however introduce a VECTORS word which very simply takes an index and executes the nth+1 word following the VECTORS. There is also a default vector if the index is over the limit. Here's how it looks:
There's also all the ++ -- ~ ~~ operators that we like in Spin although they are just there for convenience really. Under the hood the TACHYON compiler now handles double the number of vectors via XCALLs and YCALLs which internally are used to point to bytecode using just a single byte index to keep it compact. All the common or looped operations are as lean and mean as possible and the I/O operations are many times faster than Spin.
You can glean a lot of information too just from studying the Forth sources (vs the Spin tool compiled kernel) such as EXTEND.fth etc.
New EXTEND.fth and VGA.fth work fine. The 'bleeding edge' code is on the Intro links, not in the dropbox folders.
THANK YOU for putting dates in the .fth files!
The command "6 3 COGREG!" has to be run for VGA to work, so for now If you do not run DEMO the various VGA commands do not work.
VGA is stilll a little shakey. I think some commands are still waltzing into forbidden territory and quietly getting lost. That said it is still good and DEMO is impressive.
Yes, now that I am going over the VGA code I have already made some improvements since possibly you have loaded this. Once that is done I will update the dropbox files and binaries as well. So I guess I should rename it VGA DEMO.fth as that is what it really is. So that also means that I will have a separate source for the VGA BITMAP driver which can be relied upon for applications. I will see if I can set it so you don't have to tell it to set the COGREG for plotting unless you want to change it for other devices such as LCDs.
I've cleaned up the VGA DEMO.fth source and improved the speed as well. Interesting effect if you have loaded EXTEND.fth and VGA DEMO.fth and after running DEMO try this:
DECIMAL 19 APIN 2249 HZ
then try different RGB pins such as
21 APIN
then try
1 MHZ
etc
Just a little interactive fun.
EDIT: Oh, and this slow moving mesh using counters A & B
DEMO ok
ok
DECIMAL ok
23 APIN 4390 HZ ok
B 23 APIN 3,999,985 HZ ok
I did a bit of a walk through video with compiling the source from the online pages but do you think there were some tricks to compiling even just the binary?
I mentioned, in a post, that my objective was to have SimpleIDE for Spin compile the source code and burn the EEPROM. For whatever reason it compiled and loaded but Tachyon was not working. The same thing happened when I used the Propeller tool to compile the source code. The problem was solved when I just downloaded the Tachyon binary and had the Propeller tool burn the EEPROM. A side note, I am not sure if a lot of the beginners know how to load a bin file from within the Propeller tool, I sure don't.
What happened that it wasn't so smooth?
I sort of described it already.
Now do you like it.....??? (Remember this will eventually be a complete stand-alone as well as a lean target kernel)
I am still playing around with it, so will hold back on my thoughts about that. I must say it is a barebones setup, so it may be a struggle to really get a good feel for it. I would mention that I did not find a write up about your version of the "dictionary" of words, maybe a brief description of the "words" may be in order. Keep in mind the people that will be trying this have no idea as to what Forth is, or what the existing "words" do.
Since I have a DNA-RTC board, at some point I will want to be able to use everything on the board, RTC, Flash ram, and whatever "shield" becomes available(RPi). I also have some Xbee modules laying around, hopefully Tachyon would be able to handle that. And so I travel into the new(old) frontier ...
Comments
: CTR ( -- addr ) CTRA #29 REG C@ + ; : CTR! ( val -- ) CTR COG! ; : CTR@ ( -- val ) CTR COG@ ; : A 0 #29 REG C! ; : B 1 #29 REG C! ; : CTRMODE ( n -- ) #26 SHL CTR@ $1F #26 SHL ANDN OR CTR! ; : PLLDIV ( n -- ) #23 SHL CTR@ 7 #23 SHL ANDN OR CTR! ; : APIN ( pin -- ) DUP MASK OUTPUTS CTR@ $1F ANDN OR CTR! ; : BPIN ( pin -- ) DUP MASK OUTPUTS 9 SHL CTR@ $1F 9 SHL ANDN OR CTR! ; : FRQ ( n -- ) FRQA #29 REG C@ + COG! ; : NCO 4 CTRMODE ; : DUTY 6 CTRMODE ; { Some sample code here that you can type in interactively. A 4 CTRMODE #100,000 FRQ #19 APIN B 4 CTRMODE #100,100 FRQ #19 APIN BEGIN #90,000 #20,000 ADO I FRQ LOOP KEY? AND UNTIL \ to turn them off OFF A CTR! OFF B CTR! }I connected a piezo transducer (or connect to your audio amp) onto pin 19, typed in the code I have in curlys and I had to run outside to check for aliens. Then my wife came rushing in all alarmed! (she thought I was being abducted)
I am using PropForth, but the question pertains to both Forth's. How do you write some code in Forth, compile, download and watch the LED blink? Can something like that be done, or are you locked into the interactive mode? If you are locked into the interactive mode, then it seems like you would have to have a Forth run like an OS.
Ray
Well you can't blink the LED from the "command line" in PropForth because looping is involved. However since Tachyon compiles each word as it arrives then executes the built-up code once the line is entered we can "cheat" and have loops while still in interactive mode. Normally you would have to create a word (new definition) and then invoke the word by it's name. Now to blinking leds, did you read that section in my Intro page? You should get a pretty good idea about how it works. I'm not sure why you think Forth is locked in interactive mode though??? Haven't there been scores of examples here and there? So don't just check the Intro page, go and read it and better still load Tachyon into a board and follow along.
I've been reading your posts on the development of TACHYON with great interest and just want to commend you on a tremendous and remarkable effort - please continue :-)
Alas, I don't get a lot of "play" time and haven't for quite a long time now but I try to keep up with what's happing in and around this most clever silicon chip. I have alse been experimenting with Sal's PropForth to a limited degree and this too is remarkable - well done Sal.
In any case, just thought I'd throw these comments into the mix because it seems to me that many folk (like me) seem to have a large hurdle getting Forth to do anything so to follow on like a few earlier posts - here's a A$0.02 sample:
My own interpretation of Forth is that it is neither an OS or a language per se but a functional development environment with which the user/programmer develops their own vocabulary to address the specific needs of the project at hand. Having said this it seems most important to understand what the issue being addressed is and therefore what "words" are chosen to perform the required task-at-hand. I feel this is why many folk shy away because most programming disciplines are based on a more "formal" set of language specific semantics. Forth doesn't really have any but can if this is how the programmer designed their system - the system being the implementation of the project.
In addition to your code in post 152, specifically the set up of the counters and so forth, an earlier version of PropForth included a set of definitions, using the counters like you have, to define easy access for use with the COG counters (these can still be defined just as they were but are not in the current version I have loaded).
These words were "setHza" and "setHzb" and as their names imply:
16 5 setHza
20 15 setHzb
would set pin 16 pulsing at 5 Hertz and pin 20 at 15 Hertz concurrently using both counters in a single COG. Rather cool I must say :-)
Anyway, in response to Rsadeika's post # 153: here is a sample that I came up with - hopefully fairly self explanatory - apologies if not. I was thinking maybe a new Subject called "Forth Code Snippets" may be appropriate so feel free to move this post elsewhere.
The following is for a Parallax RPM (Rapid Prototype Module) using PropForth - it's a bit different to the usual demo board - in particular, the included LED's - 10 of them are inverted WRT their signalling so for the following, the "on" and "off" definitions need to be swapped.
Finally for this the PropForth "saveforth" words would write the above back to EEPROM so they survive reset/power cycles.
Peter, apologies for not providing this in TACHYON but ... :-)
Kind regards,
Thanks for your comments.
Looking at the way PropForth is coded and how it would be done in Tachyon one of the immediate things many might notice is that I use a lot of UPPERCASE words. I like to reserve UPPERCASE for action words and lowercase for variables and subroutines of functions etc. The other thing is that if I can choose a word that's short and sweet and understandable then I do so. For instance you have a word just for delay whereas I would just code in "500d ms" right where I need it although I do understand why you might direct it to one word but then that could benefit with a variable. Also you have words "on" and "off" just for setting and clearing an I/O pin. Rather a waste of a good general-purpose modifier so I already have ON and OFF as constants passed to action words. So I would perhaps say things like "ON I OUT" or "OFF I OUT" to turn an output on or off or anything else. That is also why I have words such as OUTSET and OUTCLR in that we should be able to see that they SET or CLR the OUTPUTS. If they are OUTPUTS then it also makes sense to make sure that the DIR register is set which is what they do automatically (after writing to the OUT register).
Also do loops could very well be simplified like this:
: SWEEPUP ... 16 8 ADO I FLASH LOOP ;
This is a much better way to code as it avoids unnecessary clutter and is also more efficient. I made up ADO for the sake of a better word at present rather than continually writing BOUNDS DO which converts "from for" into a "to from" form. Notice that the index is the value rather than added to the value, much simpler and clearer.
BTW, my counter words are expanded upon in EXTEND.fth and rather than typing in a rather awkward word such as "decimal 1000 setHzA" as you would in PropForth I type in "1000d KHZ" which is readily understood and the selection of A and B are latched with "A" or "B" anywhere before the action wordas is the output pin (APIN). Unless some thought is given as to how others might read it rather than just getting it functional then Forth (not the programmer) will be criticized for it's readability as a "write-only" language.
EDIT: If you try the toggle pin exercise I described earlier in PropForth rather than Tachyon you will find that it runs very slow compared even to Spin so it's probably best to show Tachyon code on this thread.
Forth seems interesting, but I haven't really done anything major with it yet. Unfortunately I know Algol family languages too well and it is easier for me to work with Spin than to think Forth. The self hosting remote programmability is pretty neat, especially when coupled with a wireless link.
What I find more amazing than Forth on the Propeller though is why more people have not taken the time to discover it's huge potential for us Prop heads. I'm only talking about one lousy hour here, not months. (Stop kicking the tires, jump in and take it for a drive)
I understand PC Forth compatibility, but PropForth and Tachyon are both on the Propeller. Do they have a similar dialect given the same architecture?
If I can make a suggestion, if you could setup TACHYON in such a way that it would run on SimpleIDE, using the built in Console window, it could simplify the interaction with TACHYON, maybe more people would be willing to take it for a test run. Or maybe I am having a big problem with trying to get your program to work, and it is my own personal problem. Just a suggestion.
Ray
Yes ... and No ... There are hard core Forth manipulatives that are the same ... DROP, DUP, ROT, IF, AND, OR and so on. But then something simple like a pause, PropForth says "100 delms" to wait 100 msecs where as Tachyon says "100 ms" ... a small issue, but in my rarely very humble opinion point to Tachyon, in this case I think more readable. Then there are the Propellor uniquenesses, different names. Both sets of names pretty much obvious, but different approaches.
Sal and the Prof have delivered to us a vast package that I think most any noob can follow the tutorials and get running and learn from ... a Rolls Royce if you will. Peter on the other hand has given us a lean fast Jaguar with a seat almost right on top of the engine. Its a little short on features compared to PF but it has a strong foundation on which to build.
I have finally been able to spend time with TACHYON. I very much like the features you have built in this forth version. However, I
have some questions relating to cog usage.
For example, suppose I wished to run two different versions of the UFO counter example in two different cogs. How would I do this?
PropForth has the cogx word which allows one to specify cogs and assign them to specific words. While you have a STOP cog word,
I can find no equivalent START cog word in the dictionary.
NickL
Since Tachyon is still a baby it hasn't yet developed the ability to run in multiple cogs. It's easy enough to have it launch into several cogs at startup, I just have have to make sure that all the controls are in place to have them idling until I pass control to them. Perhaps Tachyon will develop this ability after the next feeding and burping
I think TACHYON is very interesting.
Sorry, but I don't use TACHYON, because many basic word is UPPERCASE letter.
English(alphabet) is foreign langauge for me.
I cannot continue to read statement using all UPPERCASE letter.
So I cannot write codes on TACHYON.
You don't have to use Tachyon at all, that's up to you. If it really is for the reason you stated then perhaps it's better that you don't, Tachyon will still be what it is. Perhaps because of the influence of C and other languages we seem to have "lost" the use of uppercase, why is that? I have previously mentioned why I use uppercase and this immediately allows me to see a word like "WASH" vs "wash" and know that one is an action while the other is a variable. Should we also document in lower case without bold headings and color etc? I'm glad we don't.
BTW, Tachyon is not just interesting, it is very fast, especially compared to PropForth. Languages are not a matter of loyalty or tradition, they are a matter of necessity.
OK, since the forth kernel resides in cog 1, the cog words and registers only apply to cog 1. This means a that cogdump, for example, only dumps data from cog 1.
If I wanted to add words which would control servos, I could include an existing spin/pasm servo object in the Tachyon spin program as well as the required global variables.
The necessary servo control words could then be written in forth.
NickL
He's most interested in the design decisions you made in Tachyon that are different from propforth, and how they pan out. Sal had examined Cliffe Biffle's propellerforth and decided to do many things different, as Sal's goals were different from Cliffe's. Tachyon has made some choices more similar to propellerforth, and it will be interested to compare the benefits and drawbacks of each method. Currently the assumption is that both tools are designed for different purposes and this accounts for differences. For us it would be best to determine if we ought to do something "a better way" now before we get much further in the release. Review is a good way to find the reasoning behind the choices.
His first comment was"Well, this is going to be fast as all get out for the bit-banging stuff!".
Are you interested in getting more comments and questions? I think he said he'd send some by email if you want.
So okay, go shoot, but please be gentle, I might cry like a 6 week old baby
Scenario #1 - Demo Board, fresh load 120810.1730, fresh load of EXTEND.fth 120810.2150, fresh load of VGA.fth (No date but most recent)
Observations
1 - while VGA.fth was loading. Screen turned blue then two bands of white appeared ... the bottom fixed, the top grew pixel by pixel while the code was loading,
2 - when done I typed "DEMO" and it reset.
* * * * * * * * * * * * * *
Scenario #2 - All the same except Prop Board was a PPDB
Observations - same as above
* * * * * * * * * * * * * * *
Scenario #3 - same as #1 and #2 except board was a Propeller platform, with Wulfden VGA-A/V board
Observations - same as #1 and #2
Hi Prof, are you gonna gives us the skinny on the Sunday Call with Sal, (in the propforth thread) it's been required reading for me ever since it started. I want both versions: Full blown Forth, PropForth, and peddle to the metal Tachyon.
Ray
Hi Brian, welcome to the bleeding edge, it's a fun ride but it gets a little bumpy! I had said that I would get around to it but unfortunately that didn't happen until now. The main problem is that I need more memory, especially as I am developing and I haven't yet squeezed the kernel up. So at the present now that I have expanded both the kernel and extensions without any optimizations I end up with free space from about $3700. Obviously the VGA.fth DEMO sets the pixel buffer at $3000 and what is happening is that this directly overwrites the code. So I've changed the calculation for the pixel buffer and made it relative to the current free space. There's also been a change in the kernel since in that the PLOT primitive used to be locked to 64 bytes per line as a shift constant of 6 but now that setting is programmable and is set via 3 COGREG! (I will come up with a better name). So I have updated the DEMO with these two small changes and it works fine on the latest kernel although of course there will be junk at the top and bottom of the screen which can be blanked by setting this tiles to the same foreground and background color.
The junk at the bottom of the screen is actually the ROM has the VGA driver reads pixels from memory sequentially and the pixel buffer overlaps ROM. The kernel has been growing as I have been adding more and more functions yet it is still very lean and faster and smaller than Spin code. So as I mentioned, the kernel will be compacted through reuse and keeping the user part of the dictionary in EEPROM etc and then there will be more memory again for the VGA display.
I did a bit of a walk through video with compiling the source from the online pages but do you think there were some tricks to compiling even just the binary? What happened that it wasn't so smooth? Now do you like it.....??? (Remember this will eventually be a complete stand-alone as well as a lean target kernel)
: LCDCtrls $10 VECTORS LCDchar \ Default vector if above $10 LCDchar LCDHOME LCDchar LCDchar LCDchar LCDchar LCDchar BEEP LCDchar LCDchar LCDLF LCDchar LCDCLS LCDCR LCDchar LCDchar ; : LCDEMIT DUP BL < IF DUP 0 REG C! LCDCtrls ELSE LCDData THEN ;There's also all the ++ -- ~ ~~ operators that we like in Spin although they are just there for convenience really. Under the hood the TACHYON compiler now handles double the number of vectors via XCALLs and YCALLs which internally are used to point to bytecode using just a single byte index to keep it compact. All the common or looped operations are as lean and mean as possible and the I/O operations are many times faster than Spin.You can glean a lot of information too just from studying the Forth sources (vs the Spin tool compiled kernel) such as EXTEND.fth etc.
Thanks for the feedback everyone.
New EXTEND.fth and VGA.fth work fine. The 'bleeding edge' code is on the Intro links, not in the dropbox folders.
THANK YOU for putting dates in the .fth files!
The command "6 3 COGREG!" has to be run for VGA to work, so for now If you do not run DEMO the various VGA commands do not work.
VGA is stilll a little shakey. I think some commands are still waltzing into forbidden territory and quietly getting lost. That said it is still good and DEMO is impressive.
DECIMAL 19 APIN 2249 HZ
then try different RGB pins such as
21 APIN
then try
1 MHZ
etc
Just a little interactive fun.
EDIT: Oh, and this slow moving mesh using counters A & B
DEMO ok
ok
DECIMAL ok
23 APIN 4390 HZ ok
B 23 APIN 3,999,985 HZ ok
I sort of described it already.
I am still playing around with it, so will hold back on my thoughts about that. I must say it is a barebones setup, so it may be a struggle to really get a good feel for it. I would mention that I did not find a write up about your version of the "dictionary" of words, maybe a brief description of the "words" may be in order. Keep in mind the people that will be trying this have no idea as to what Forth is, or what the existing "words" do.
Since I have a DNA-RTC board, at some point I will want to be able to use everything on the board, RTC, Flash ram, and whatever "shield" becomes available(RPi). I also have some Xbee modules laying around, hopefully Tachyon would be able to handle that. And so I travel into the new(old) frontier ...
Ray