@Heater
I suppose one could argue that on the lowest of levels or smallest of Forths it is not much more than an 'machine-code shell' with a characteristic minimum of two stacks.
Forth can also define all assembler terms as words and be an 'assembler shell'. And of course it can be an accumulaton of more lexicon of actual tasks and routines.
I kinda of like that idea.
But the fact that it avoids the write-compie-load cycle of other powerful and useful languages is what really attracts me to it.
Is there an interactive C? Interactivity is a great tool for exploring and learning quickly. I got a lot out of using 'peek' and 'poke' on a TRS80 Color computer, though I never really liked the machine or the interactive Basic that it provided.
Forth is more powerful that an interactive Basic in that there might be no need to upgrade to a better language to gain more speed or functionality.
Is Forth as fast as assembler? Given a specific complex task that has been 'completely' optimized in assembler, I suspect that Forth will always be slower as dictionary threading are going to add some length to the execution time.
But Wikipedia's Forth entry does mention new enhancements to optimize Forth that may just collate any time critical task into one perfectly optimized word. To me, that would merely be all assembler that has been robotically optimized in Forth; but because it was optimized in Forth, others might claim it to be Forth.
I hate speed tests. Back in the 1970-80s when Byte magazine and Doctor Dobbs Journal were in there full glory, everyone with a new language or a new chip would assert theirs was the fastest and jump into the fray. It all became a wild West show of gunslinger versus gunslinger - many casualties, not much proven.
PropForth does NOT have a Forth stack machine and an asynch serial port working at the same time on one cog. If that model could be done or if a dedicated cog serial driver could handle 8 or more serial configurations and multiplex to other cogs, you would have a quite useful model.
I guess that 3mbits over Bluetooth is useful if you use Bluetooth. My own interests lie in hardware and impedances in hardwire slow things do.
Prof Braino says that he and Sal 'tripped over a wire' in their speed tests. But it just could be his way of saying that he never considered wireless applications that offer higher baud rates than wire might ever do. Rather amusing..........
I'm not sure how you came to this conclusion. Hook up the bluetooth module and watch it run at 230400. I got it to work from two houses down. Crank it up to 3M and watch it continue to work, from about 1 house down. It doesn't go through walls or floors so well, so it was derated. Its still faster than bat snot. Hook it up wired, you will see it run fine at whatever you set it all the way up to 3M for as long as your wire is. You MIGHT see an error at 3M, but I bet you won't. I haven't. Sal derated it just because he might have seen an error and it is generally better to be cautious.
Run the channels test, watch it run seven terminal sessions at once. Type the words command on each terminal to see the what happens when the channel is saturated. At 230400 over a sing async serial connection, its still really fast, faster than 19.2 on a single connection. AND it can support over 32 separate channels to one prop. You have to figure out a way to have something to send over that many channels, so maybe you should wait for the next demo. This is will involve multiple props going through a single physical connection to the workstation, but you don't know how to do this yet, maybe Rick could, but I'm going to wait for Sal since I am lazy.
It makes me uncomfortable to heard blanket statements about what propforth does and doesn't do (and its incorrect), when you simply haven't run the demos and examples. You can't expect to learn about propforth without using the propforth materials, starting forth is a general reference, but is not applicable to most of the prop stuff.
Relax! Take it easy. Start with the simple stuff, master that, then move on to the next task. It much more fun, and you build a solid foundation for the advanced stuff.
Yes. The whole point of forth is to provide an interactive way to get to doing the assembler stuff. If the automatic forth over head is not fast enmough, you remove it and replace it with optimized assembler. Nobody cares about how it is classified, only about getting the job done.
But perhaps we must agree to disagree if the distinction is something you hold dear.
I stand corrected, only the assembler parts are fast as assembler, the other parts are as fast as forth, which has a significant overhead, which in turn does not matter in most cases except those that call for assembler optimization. This is the cost of interactivity supplied by forth.
I'm not sure how you came to this conclusion. Hook up the bluetooth module and watch it run at 230400. I got it to work from two houses down. Crank it up to 3M and watch it continue to work, from about 1 house down. It doesn't go through walls or floors so well, so it was derated. Its still faster than bat snot. Hook it up wired, you will see it run fine at whatever you set it all the way up to 3M for as long as your wire is. You MIGHT see an error at 3M, but I bet you won't. I haven't. Sal derated it just because he might have seen an error and it is generally better to be cautious.
Run the channels test, watch it run seven terminal sessions at once. Type the words command on each terminal to see the what happens when the channel is saturated. At 230400 over a sing async serial connection, its still really fast, faster than 19.2 on a single connection. AND it can support over 32 separate channels to one prop. You have to figure out a way to have something to send over that many channels, so maybe you should wait for the next demo. This is will involve multiple props going through a single physical connection to the workstation, but you don't know how to do this yet, maybe Rick could, but I'm going to wait for Sal since I am lazy.
It makes me uncomfortable to heard blanket statements about what propforth does and doesn't do (and its incorrect), when you simply haven't run the demos and examples. You can't expect to learn about propforth without using the propforth materials, starting forth is a general reference, but is not applicable to most of the prop stuff.
Relax! Take it easy. Start with the simple stuff, master that, then move on to the next task. It much more fun, and you build a solid foundation for the advanced stuff.
You know, I am not interested in bluetooth and don't have the hardware. I barely want 57600 baud. That speed war is between you and Peter.
And yet... I have run the examples and the tutorial that apply.
Whenever I use serial or _serial the assigned cog converts from a Forth stack machine to a serial port.
In the Serial loopback, you actually have Cog 0 as a Forth stack machine connected to Cog 1 as a dedicated serial i/o. And then you have Cog 2 as a dedicated serial i/o connected to the Cog 7 serial in a direct output, while Cog 7 input goes to Cog 6 where 'term' is active, and passed on to Cog 2.
That is where I get the idea that PF does not have a serial port and a Forth stack machine working at the same time on one cog. And thought I did see a flag in the source code somewhere that appeared to switch between the two. Even if I am wrong about that, the only way to revive a serial i/o cog is to reboot it.
I am not sure what you mean by 'blanket statements'.
BTW, I am taking it easy, PropForth isn't worth my doing otherwise. But I still am trying to get the serial port to work the way I need it to in full duplex, and then maybe in half duplex. I don't need simplex. But I might need to use the serial without the 'term' word.
As far as implementing WHILE and REPEAT they are so simple that I don't understand why PropForth wouldn't include them.
there are many common words that are not included in the basic kernel because they are either expensive in terms off speed or memory, or are inefficient and can be done better with existing words, or simply are not needed. this is from experts, like charles moore. each implement determine to what extent this is applicable.
that being said, anyone is free to write and submit extensions, and we can all try them out and use them as desired. PM me with you email and you can submit anything you want (if you want the hassle of another project). it would be very handy to have (for at least one known user), and sal would not mind, although it goes against "minimum necessary and suffucuent" in his context.
the kernel must be maintained as flexible as possible, and users can add any extensions to the development environment. having an integrated dev kernel was a huge favor to me, as it can be completely remved and repleced with the smaller non dev kernel, for a properly written application. this was significant amount of effort.
Doug, it doesn't seem that speed and memory were the deciding factors on which words to include in PropForth. PropForth contains 441 pre-defined words, and takes up over half the hub RAM when booted up. It seems to run at about the same speed as PASM pfth, which hasn't really been optimized for speed yet. I count 31 assembly words, which is what I would call the kernel words. Unless PropForth works differently than other Forths, the remaining 410 words are built from the 31 kernel words, so I wouldn't define them as being part of the kernel.
I don't see much point in contributing words to PropForth if you, Sal and Charles Moore don't think they should be in there. I'm content with adding them to pfth.
You know, I am not interested in bluetooth and don't have the hardware. I barely want 57600 baud. That speed war is between you and Peter.
LOL! Then what are you arguing about?
I have no "war" with anyone. Peter has a different project, making a different forth using a different method, and making cool progress. His tool is for a different purpose, and it fit Peters purpose very well (I imagine that's why he wrote it that way). I don't know if Tachyon fits my needs, I'm too busy with my own stuff to play with it. But I just run tests and publish the notes, and try to answer simple questions.
I think your problems come from a misunderstanding of the example. Since there is only one physical serial connection on the standard prop boards, all the tests have to be routed through the same physical connection to get to the PC screen. Each cog has a standard interface in software. We plug the out from one cog into the in of another, and they just go. This is how each cog appears to have its own serial port, even though there is only one physical serial port and it it being handled by cog7. Cog 7 just talk to the serial connection (FTDI chip or MAX232 serial, what ever is on pins 30 & 31).
You want \V5.0\kernels\doc\tutorials\tutorial-3.2 Serial Loopback.txt
Cog1 and cog 2 are talking directly to each other over pins 0 and 1.
In step 6, the example has us route the terminal (on Cog6) into the other cogs 1 & 2, to get the chars to display on the screen. To do this, our cog (cog6) has to plug in to cog 2 (to do the serial loopback on pins 0 & 1 to cog 1) , and to cog 7 to get to the terjminal display on the PC.
All you have to do (I think) is connect your device to pin 0 so cog 1 can talk to [chopstick printer], or pin 1 so cog 1 can listen to [chostick printer]. After you prove cogs 1 & 2 were talking in the first place, eliminate the cog 2 parts, . I think if you connect you printer to BOTH pins 0 and 1, the display will automatically echo your transimssions to the screen, as it is listening to what its transmitting in addition to listening to your printer.
The whole point of forth is to provide an interactive way to get to doing the assembler stuff.
I thought the whole point of Forth was to be a high level language. Indeed I don't recall there is any assembler in the classic text "Starting Forth" by Leo Brodie.
Ah well, we'll have to let this little side debate rest now I think.
I thought the whole point of Forth was for everyone to create their own private language. ANS Forth does provide a CODE word, which allows inserting assembly code. PropForth may provide a similar feature.
@Doug, I've been reading up on Charles Moore, and it seems like he's is not entirely against supporting the ANS standard. SwiftForth is an ANS compliant interpreter, which was developed by his company, Forth Inc.
Doug, it doesn't seem that speed and memory were the deciding factors on which words to include in PropForth.
That is because you don't understand. If you wish to understand, I can try to explain, if not, please ignore the rest of this post.
PropForth contains 441 pre-defined words, and takes up over half the hub RAM when booted up.
Are you looking at the dev kernel, or the boot kernel? The dev kernel contains tons of developer extensions that are generally not needed in a final application, but are found to be handy in dev.
The reason we don't want to add every possible forth word is that there is not so much space in the prop, and the line was drawn where it was drawn. If you must have WHILE, PICK, CASE, please add them. Use your resources as you see fit. You can even create a new kernel that has them by default.
It seems to run at about the same speed as PASM pfth, which hasn't really been optimized for speed yet.
Great! you are a very capable programmer, and I applaud your work.
I count 31 assembly words, which is what I would call the kernel words. Unless PropForth works differently than other Forths, the remaining 410 words are built from the 31 kernel words, so I wouldn't define them as being part of the kernel.
Propforth does work differently from other forths. One big different is that we still use the proptool to generaate the initial spin file. This resolves forward references and addresses other inconvenient stuff. It can be considered cheating, but propforth cannot regenerate itself directly.
You can define words varioulsy as "part of the kernel" or not as you see fit, it has no affect on speed or memory footprint. Sal defines the kernel as what you see, Sal's definition only affects Sal's kernel. Use it or change it.
I don't see much point in contributing words to PropForth if you, Sal and Charles Moore don't think they should be in there. I'm content with adding them to pfth.
I seem to be communicating poorly again. Convenient words can be added as extensions. The purpose of the kernel is to make a STARTING POINT, nothing more. From which we add whatever we need, and even subtract what ever we don't need.
Is it an affront to you that this project has a slightly different direction than yours? Just because they are different doesn't force one to be "wrong". It just makes one suitable for one purpose, and the other suitable for a slightly different purpose. If one can benefit from insights gained from the other, that is great. That is my goal, if engaging all the forth contributors to see what we can get out of it. The differences are a good thing.
But I have to be careful, as we made many of the beginner decisions a few years ago, and decided that we wound go a different direction. We don't want to pain ourselves into the same corners again. You will likely find different solutions for the same issues, this is what we want to see.
For example, can pfth be used to create an application? Peter has done a bunch of stepper motor stuff, we know Tachyon is very good for that. It happens to be faster than we can actually use with our motors, etc; so it's "good to know" but does not warrant a change in propforth.
Propforth has drivers for a bunch of parts, and the logic analyzer, and the multichannel, etc. Does pfth support an of those? We should compare notes and see if one is good for something and the other is good for other things.
I am arguing about what you are arguing about. But may be you didn't realize that. What are you arguing about?
It all gets rather circular and doesn't accomplish much, doesn't it? Let's argue some more...............
\V5.0\kernels\doc\tutorials\tutorial-3.2 Serial Loopback.txt has been dissected line by line and word for word, the code runs and the chain of events is clear. The PropForth word term been dissected word-by-word and particular focus on the (iolink) as been studied in detail.
This whole thing may have not worked because of the 'dup key' phrase was not fully understood until today.
I have been hoping to use the following for configuration
c" 1 1 9600 serial " 1 cogx
1 1 sersetflag
After all, it is one wire bi-directional half-duplex ---- using pin 0 and pin 1 for rx and tx or vise versa will not directly support the Serial Inkjet Printer Board. (But if I did use separate rs and tx pins I guess I could just wire them together.)
After I actually have a connection that works properly, I had planned to NOT have me communicate with the serial i/o.
I want to load one cog with a routine and be able to trigger it to handshake with the inkjet printer board and send the right output. This is critical as the same trigger or one immediately before it is going to rotate the chopstick via a stepper driver in another cog as the printhead is stationary during the printing of each character.
In other words, just having my notebook computer keyboard sending ASCII to the inkjet printer board and receiving the > prompt from the inkjet printer board is useful............. but not enough to finish the project.
Tutorial 3.2 doesn't anticipate and demonstrate these things.
The communication system can be classified into three categories
Simplex
Full Duplex
Half Duplex
Simplex
A simplex system is a communication system in which the message can be send in one direction only.
Radio and TV boardcasting are eg
User – Transmitter – Receiver – User
Full Duplex
A full duplex system is one in which the link is capable of transmitting in both the direction, at the same.
Eg : telephone system.
Half Duplex
In a half duplex system, each end may transmit, but only one at a time. This requires both transmitting and receiving circuitary at each end, but the actual link between the two ends may be shared.
Eg : A citizen’s band radio where a frequency channel is shared and each party has to say “over” to switch the direction of the communication.
~~~~~
I need to wait for a message, when a prompt is received I can then send a message. If I don't wait, I have no way of knowing if the device is ready to properly receive.
The 441 words are in the non-SD, non-EEPROM Dev version. I haven't looked at the boot version. I see the words in PropForth that are defined in PASM using the SpinTool to resolve addresses. I use a similar technique in pfth for the assembly words and a small number of Forth words. The rest of the dictionary for pfth is written in Forth, and included in the pfth binary using the PASM FILE directive. This requires compiling most of the dictionary on bootup, but it only takes a few seconds. It will be quicker once I remove the debug prints.
As it stands currently, pfth could be used to create some simple applications. It only has two Prop-specific words, which are cog@ and cog!. These can be used to access the Prop's special registers. I need to add a few more words to fully utilize all of the Prop's features. I have ported a few ANS programs that I've found on the internet. A few nights ago I got a 668-line chess program working. It takes a few minutes for it to compute it's moves, so it's not quite practical yet. I'm planning on doing more optimizations, and improve the speed some more.
I'm also looking at porting some of the more popular Spin/PASM object from the OBEX. It will be a while before I get to that.
This whole thing may have not worked because of the 'dup key' phrase was not fully understood until today.
c" 1 1 9600 serial " 1 cogx
1 1 sersetflag
.
looks like you have what you need at last.
remember, the docs are only intended to cover what prpforth does, not necessarily anticipate any future request. any additional docs are to be addressed per specific request. Hopefully by the asker. This is the only reasonable way to address documentation.
remember, the docs are only intended to cover what prpforth does, not necessarily anticipate any future request. any additional docs are to be addressed per specific request. Hopefully by the asker. This is the only reasonable way to address documentation.
So no documentation should be written prior to turning something over to the users and then you only need to answer and document the things that pertain to the questions they ask?
“You are standing in an open field west of a white house, with a boarded front door. There is a small mailbox here.”
Ahh, now I understand!!!
Q: So, this pack is the parachute?
A: Yes.
Q: I put it on my back?
A: Yes
Q: How do I open it?
A: Pull the ring on your chest.
ok, I'm ready
{Jumps from plane with friend. His main chute doesn't open, the friend's main chute does}
Q: Dude, my friend's main chute didn't open, why didn't you tell him about his reserve?
A: He didn't ask but now that you have, we can document that in the Reserve Chute Testing and Verification Tutorial.
So no documentation should be written prior to turning something over to the users and then you only need to answer and document the things that pertain to the questions they ask?
Ok, Mr Scharty Pantses, You asked so I answer:
I have about 100 wiki pages that yeilded practically no response. I spend hours trying to anticipate what a new kid would likely ask, this effort was largely wasted. The conclusion of this experiment was that second guessing future questions is a lot of effort with little benefit.
Next I tried to simply log what I actually did to get something working, for example the SD adapter hack. This was useful to me on the three occasions I had to go back and make more, and Sal used it. So at least I found something not exactly useless. Answering specific questions and recording them well at least gives answers to questions that actually get asked.
The next experiment was to get folks to record there own questions and answers and post them on the wiki. This is on going, but it seems that not everyone is equipped to perform this function. The tendency is to assume the read has certain knowledge, that assumption tends to be wrong unless the material is presented very carefully.
I asked Sal to make the tutorials, and construct them such that they could be automated. He did but the result is still pretty difficult to follow, although at least the automation can be show to test every possible function in propforth. To my knowledge, only two people have run these tests. The significance of this ability appear to be lost on the remainder of the software community in general, it seems to be too far ahead of its time. Most folk don't understand testing, let alone automated testing.
Finally, I asked Sal how much it would cost to actually write his book on propforth. I can't afford the 6 months of his time at this point in my fortunes. And even if all 300 people bought it (unlikely), it would still be negative profit. But he did compromise by constructing and spending the time to write propforth.htm.
So far the data suggests:
* Anticipation every possible question in advance is a fools errand, it costs a lost, generates a huge pile of noise, its very difficult to maintain, and only a faction will ever be used, even if it can be found.
* Answering questions when asked yields 100% "used" material, but generates a small amount of material. People are shy about asking in the first place, and don't ask clear complete questions. I.E. asking about a function when the question is really about design. It takes days to dig through to get to the actual issue.
* Doing a complete requirements trace is the only exhaustive method that completely addresses all capabilities. But, each person has different highest level requirements. So we must start in the middle at the software functional requirements. We can list the functions, and their inputs and outputs. Details on the inner working of each function are needed, but this requires an understanding (by the reader) of the code in the first place, which we cannot assume. Rather than fight this, we decided to fill this in as asked, if ever.
The bottom line is, its too much work for one or two guys to do alone. But there is not well defined way to get additional hands on board. Without a consensus of goals, methods, terminology, and content; and a bunch of volunteers, we have to proceed with what we have until more alternatives become available.
When forth was "popular" there was a large group of users at a university, I think it was Keio University or Waseba University. But I didn't know much Japanese at the time, and lost contact with all the people. I wonder if any of those folks will pop up...
How do I put propforth.HTM (from the archive) so it displays on the wiki?
I tried pasting the HTML into a wiki page, but it choked, and pasting in the text requires endless reformatiing.
There's got to be an easy way?
PB,
Here's what the Help for wiki page creation says: "HTML support
To aid in the presentation of a wiki page there is some support for HTML. HTML tags are only supported in wiki pages, not in page comments.
HTML syntax can be used in conjunction with wiki syntax, but it is recommended against doing so where possible."
This would make me think it's not easy to do without a lot of creation and linking and relinking.
Google site should support your own generated HTML pages - haven't tried this yet.
Either way, the trick is creating the subpages or additional HTML files for each link. If you have each PropForth word as a linkable item, then there needs to be a wiki page or .html file created containing the details for that word. Lots and lots of work as you are aware, especially on a still dynamic vocabulary. I would think this could be automated but just don't know the best tool to use. I would love to be able to create pages like arduino.cc has for their reference doc but don't know how. I'm wondering is doxygen or something like that would be embeddable inside Forth code?
The other alternative is to write your own program to chop up a .f file and create the .html files needed and the links to them. This would be like the big brother to the program I wrote to create the word index.
All is doable but this is all related to documentation which is the last thing most people want to do or even worse related to documentation maintenance which I don't think there has ever been a documented case of a programmer EVER doing!!
Wonderful. I am still working on asynchonous serial ports and will soon have some added material to help those that may also been having difficulty with these useful and important connections to other devices.
I still have not gotten my Chopstick Printer working but a good document may just have to come first. If anyone needs a dumb terminal for the PropForth on Propeller, one can use another Propeller board with video and keyboard and software from PockeTerm for free.
Or if they want to support PockeTerm, they can buy their board and use the same software.
When forth was "popular" there was a large group of users at a university, I think it was Keio University or Waseba University. But I didn't know much Japanese at the time, and lost contact with all the people. I wonder if any of those folks will pop up...
Taiwan still has an active Forth Interest Group if you care to visit. It would help if you could type Chinese.
Europe has a lot of loyal avid Forth users as well. And Silicon Valley Forth Interest Group still is somewhat active. Considering that I cannot find the local Kaohsiung Linux Users Group (LUG) and the place they claimed to be meeting at never heard of them, this seems to demonstrate stronger interest in Forth than in Linux in Taiwan.
prof_braino,
I've probably missed a thing but where is that?
Well if you go to the PropForth download site, you will find them. But the last time I looked the total was 88 wiki and I think that some of them are Sal Sanci's work.
We all just have to overlook some of these inacuracies. Closer to 80. That is still a substantial amount of effort by Prof Braino.
Comments
It's recursive function.
Sal gave me hint about it.
fl hex lockdict : recurse lastnfa nfa>pfa w, ; immediate freedict \ ( n1 -- n2 ) n2 = n1 X (n1-1) X (n1-2) X . . . X 1 : func dup 0 <= if drop 1 else dup 1- recurse u* then ; \ ( n1 -- n2 ) n2 = n1 X (n1-1) X (n1-2) X . . . X 1 : func_test func . cr ; \ Print disc-move \ ( n1 n2 -- n1 n2 ) n1:to n2:from : hanoi_msg cr 2dup . ." --> " . ; \ Move disc \ ( n1 n2 n3 n4 -- n1 n2 n3 ) n1:to n2:tmp n3 from n4:discs : hanoi_move dup >r 0> if rot swap 0 RS@ 1- recurse hanoi_msg rot 0 RS@ 1- recurse swap then r> drop ; \ ( n1 n2 n3 n4 -- ) n1:to n2:tmp n3 from n4:discs : hanoi hanoi_move 3drop cr ; decimalResult;
I suppose one could argue that on the lowest of levels or smallest of Forths it is not much more than an 'machine-code shell' with a characteristic minimum of two stacks.
Forth can also define all assembler terms as words and be an 'assembler shell'. And of course it can be an accumulaton of more lexicon of actual tasks and routines.
I kinda of like that idea.
But the fact that it avoids the write-compie-load cycle of other powerful and useful languages is what really attracts me to it.
Is there an interactive C? Interactivity is a great tool for exploring and learning quickly. I got a lot out of using 'peek' and 'poke' on a TRS80 Color computer, though I never really liked the machine or the interactive Basic that it provided.
Forth is more powerful that an interactive Basic in that there might be no need to upgrade to a better language to gain more speed or functionality.
Is Forth as fast as assembler? Given a specific complex task that has been 'completely' optimized in assembler, I suspect that Forth will always be slower as dictionary threading are going to add some length to the execution time.
But Wikipedia's Forth entry does mention new enhancements to optimize Forth that may just collate any time critical task into one perfectly optimized word. To me, that would merely be all assembler that has been robotically optimized in Forth; but because it was optimized in Forth, others might claim it to be Forth.
I hate speed tests. Back in the 1970-80s when Byte magazine and Doctor Dobbs Journal were in there full glory, everyone with a new language or a new chip would assert theirs was the fastest and jump into the fray. It all became a wild West show of gunslinger versus gunslinger - many casualties, not much proven.
http://forums.parallax.com/showthread.php?143900-WINNER!!-Forthers-Thanksgiving-Challenge-it-s-all-about-the-projects-baby!!!&p=1145114&viewfull=1#post1145114
I'm not sure how you came to this conclusion. Hook up the bluetooth module and watch it run at 230400. I got it to work from two houses down. Crank it up to 3M and watch it continue to work, from about 1 house down. It doesn't go through walls or floors so well, so it was derated. Its still faster than bat snot. Hook it up wired, you will see it run fine at whatever you set it all the way up to 3M for as long as your wire is. You MIGHT see an error at 3M, but I bet you won't. I haven't. Sal derated it just because he might have seen an error and it is generally better to be cautious.
Run the channels test, watch it run seven terminal sessions at once. Type the words command on each terminal to see the what happens when the channel is saturated. At 230400 over a sing async serial connection, its still really fast, faster than 19.2 on a single connection. AND it can support over 32 separate channels to one prop. You have to figure out a way to have something to send over that many channels, so maybe you should wait for the next demo. This is will involve multiple props going through a single physical connection to the workstation, but you don't know how to do this yet, maybe Rick could, but I'm going to wait for Sal since I am lazy.
It makes me uncomfortable to heard blanket statements about what propforth does and doesn't do (and its incorrect), when you simply haven't run the demos and examples. You can't expect to learn about propforth without using the propforth materials, starting forth is a general reference, but is not applicable to most of the prop stuff.
Relax! Take it easy. Start with the simple stuff, master that, then move on to the next task. It much more fun, and you build a solid foundation for the advanced stuff.
Yes. The whole point of forth is to provide an interactive way to get to doing the assembler stuff. If the automatic forth over head is not fast enmough, you remove it and replace it with optimized assembler. Nobody cares about how it is classified, only about getting the job done.
But perhaps we must agree to disagree if the distinction is something you hold dear.
I stand corrected, only the assembler parts are fast as assembler, the other parts are as fast as forth, which has a significant overhead, which in turn does not matter in most cases except those that call for assembler optimization. This is the cost of interactivity supplied by forth.
You know, I am not interested in bluetooth and don't have the hardware. I barely want 57600 baud. That speed war is between you and Peter.
And yet... I have run the examples and the tutorial that apply.
Whenever I use serial or _serial the assigned cog converts from a Forth stack machine to a serial port.
In the Serial loopback, you actually have Cog 0 as a Forth stack machine connected to Cog 1 as a dedicated serial i/o. And then you have Cog 2 as a dedicated serial i/o connected to the Cog 7 serial in a direct output, while Cog 7 input goes to Cog 6 where 'term' is active, and passed on to Cog 2.
That is where I get the idea that PF does not have a serial port and a Forth stack machine working at the same time on one cog. And thought I did see a flag in the source code somewhere that appeared to switch between the two. Even if I am wrong about that, the only way to revive a serial i/o cog is to reboot it.
I am not sure what you mean by 'blanket statements'.
BTW, I am taking it easy, PropForth isn't worth my doing otherwise. But I still am trying to get the serial port to work the way I need it to in full duplex, and then maybe in half duplex. I don't need simplex. But I might need to use the serial without the 'term' word.
there are many common words that are not included in the basic kernel because they are either expensive in terms off speed or memory, or are inefficient and can be done better with existing words, or simply are not needed. this is from experts, like charles moore. each implement determine to what extent this is applicable.
that being said, anyone is free to write and submit extensions, and we can all try them out and use them as desired. PM me with you email and you can submit anything you want (if you want the hassle of another project). it would be very handy to have (for at least one known user), and sal would not mind, although it goes against "minimum necessary and suffucuent" in his context.
the kernel must be maintained as flexible as possible, and users can add any extensions to the development environment. having an integrated dev kernel was a huge favor to me, as it can be completely remved and repleced with the smaller non dev kernel, for a properly written application. this was significant amount of effort.
I don't see much point in contributing words to PropForth if you, Sal and Charles Moore don't think they should be in there. I'm content with adding them to pfth.
LOL! Then what are you arguing about?
I have no "war" with anyone. Peter has a different project, making a different forth using a different method, and making cool progress. His tool is for a different purpose, and it fit Peters purpose very well (I imagine that's why he wrote it that way). I don't know if Tachyon fits my needs, I'm too busy with my own stuff to play with it. But I just run tests and publish the notes, and try to answer simple questions.
I think your problems come from a misunderstanding of the example. Since there is only one physical serial connection on the standard prop boards, all the tests have to be routed through the same physical connection to get to the PC screen. Each cog has a standard interface in software. We plug the out from one cog into the in of another, and they just go. This is how each cog appears to have its own serial port, even though there is only one physical serial port and it it being handled by cog7. Cog 7 just talk to the serial connection (FTDI chip or MAX232 serial, what ever is on pins 30 & 31).
You want \V5.0\kernels\doc\tutorials\tutorial-3.2 Serial Loopback.txt
Cog1 and cog 2 are talking directly to each other over pins 0 and 1.
In step 6, the example has us route the terminal (on Cog6) into the other cogs 1 & 2, to get the chars to display on the screen. To do this, our cog (cog6) has to plug in to cog 2 (to do the serial loopback on pins 0 & 1 to cog 1) , and to cog 7 to get to the terjminal display on the PC.
All you have to do (I think) is connect your device to pin 0 so cog 1 can talk to [chopstick printer], or pin 1 so cog 1 can listen to [chostick printer]. After you prove cogs 1 & 2 were talking in the first place, eliminate the cog 2 parts, . I think if you connect you printer to BOTH pins 0 and 1, the display will automatically echo your transimssions to the screen, as it is listening to what its transmitting in addition to listening to your printer.
I thought the whole point of Forth was to be a high level language. Indeed I don't recall there is any assembler in the classic text "Starting Forth" by Leo Brodie.
Ah well, we'll have to let this little side debate rest now I think.
@Doug, I've been reading up on Charles Moore, and it seems like he's is not entirely against supporting the ANS standard. SwiftForth is an ANS compliant interpreter, which was developed by his company, Forth Inc.
That is because you don't understand. If you wish to understand, I can try to explain, if not, please ignore the rest of this post.
Are you looking at the dev kernel, or the boot kernel? The dev kernel contains tons of developer extensions that are generally not needed in a final application, but are found to be handy in dev.
The reason we don't want to add every possible forth word is that there is not so much space in the prop, and the line was drawn where it was drawn. If you must have WHILE, PICK, CASE, please add them. Use your resources as you see fit. You can even create a new kernel that has them by default.
Great! you are a very capable programmer, and I applaud your work.
Propforth does work differently from other forths. One big different is that we still use the proptool to generaate the initial spin file. This resolves forward references and addresses other inconvenient stuff. It can be considered cheating, but propforth cannot regenerate itself directly.
You can define words varioulsy as "part of the kernel" or not as you see fit, it has no affect on speed or memory footprint. Sal defines the kernel as what you see, Sal's definition only affects Sal's kernel. Use it or change it.
I seem to be communicating poorly again. Convenient words can be added as extensions. The purpose of the kernel is to make a STARTING POINT, nothing more. From which we add whatever we need, and even subtract what ever we don't need.
Is it an affront to you that this project has a slightly different direction than yours? Just because they are different doesn't force one to be "wrong". It just makes one suitable for one purpose, and the other suitable for a slightly different purpose. If one can benefit from insights gained from the other, that is great. That is my goal, if engaging all the forth contributors to see what we can get out of it. The differences are a good thing.
But I have to be careful, as we made many of the beginner decisions a few years ago, and decided that we wound go a different direction. We don't want to pain ourselves into the same corners again. You will likely find different solutions for the same issues, this is what we want to see.
For example, can pfth be used to create an application? Peter has done a bunch of stepper motor stuff, we know Tachyon is very good for that. It happens to be faster than we can actually use with our motors, etc; so it's "good to know" but does not warrant a change in propforth.
Propforth has drivers for a bunch of parts, and the logic analyzer, and the multichannel, etc. Does pfth support an of those? We should compare notes and see if one is good for something and the other is good for other things.
I am arguing about what you are arguing about. But may be you didn't realize that. What are you arguing about?
It all gets rather circular and doesn't accomplish much, doesn't it? Let's argue some more...............
\V5.0\kernels\doc\tutorials\tutorial-3.2 Serial Loopback.txt has been dissected line by line and word for word, the code runs and the chain of events is clear. The PropForth word term been dissected word-by-word and particular focus on the (iolink) as been studied in detail.
This whole thing may have not worked because of the 'dup key' phrase was not fully understood until today.
I have been hoping to use the following for configuration
c" 1 1 9600 serial " 1 cogx
1 1 sersetflag
After all, it is one wire bi-directional half-duplex ---- using pin 0 and pin 1 for rx and tx or vise versa will not directly support the Serial Inkjet Printer Board. (But if I did use separate rs and tx pins I guess I could just wire them together.)
After I actually have a connection that works properly, I had planned to NOT have me communicate with the serial i/o.
I want to load one cog with a routine and be able to trigger it to handshake with the inkjet printer board and send the right output. This is critical as the same trigger or one immediately before it is going to rotate the chopstick via a stepper driver in another cog as the printhead is stationary during the printing of each character.
In other words, just having my notebook computer keyboard sending ASCII to the inkjet printer board and receiving the > prompt from the inkjet printer board is useful............. but not enough to finish the project.
Tutorial 3.2 doesn't anticipate and demonstrate these things.
Type of Communication Systems
The communication system can be classified into three categories
Simplex
Full Duplex
Half Duplex
Simplex
A simplex system is a communication system in which the message can be send in one direction only.
Radio and TV boardcasting are eg
User – Transmitter – Receiver – User
Full Duplex
A full duplex system is one in which the link is capable of transmitting in both the direction, at the same.
Eg : telephone system.
Half Duplex
In a half duplex system, each end may transmit, but only one at a time. This requires both transmitting and receiving circuitary at each end, but the actual link between the two ends may be shared.
Eg : A citizen’s band radio where a frequency channel is shared and each party has to say “over” to switch the direction of the communication.
~~~~~
I need to wait for a message, when a prompt is received I can then send a message. If I don't wait, I have no way of knowing if the device is ready to properly receive.
As it stands currently, pfth could be used to create some simple applications. It only has two Prop-specific words, which are cog@ and cog!. These can be used to access the Prop's special registers. I need to add a few more words to fully utilize all of the Prop's features. I have ported a few ANS programs that I've found on the internet. A few nights ago I got a 668-line chess program working. It takes a few minutes for it to compute it's moves, so it's not quite practical yet. I'm planning on doing more optimizations, and improve the speed some more.
I'm also looking at porting some of the more popular Spin/PASM object from the OBEX. It will be a while before I get to that.
looks like you have what you need at last.
remember, the docs are only intended to cover what prpforth does, not necessarily anticipate any future request. any additional docs are to be addressed per specific request. Hopefully by the asker. This is the only reasonable way to address documentation.
So no documentation should be written prior to turning something over to the users and then you only need to answer and document the things that pertain to the questions they ask?
Ahh, now I understand!!!
Q: So, this pack is the parachute?
A: Yes.
Q: I put it on my back?
A: Yes
Q: How do I open it?
A: Pull the ring on your chest.
ok, I'm ready
{Jumps from plane with friend. His main chute doesn't open, the friend's main chute does}
Q: Dude, my friend's main chute didn't open, why didn't you tell him about his reserve?
A: He didn't ask but now that you have, we can document that in the Reserve Chute Testing and Verification Tutorial.
It is simple, ignore the docs - read the source (if you can).
Ok, Mr Scharty Pantses, You asked so I answer:
I have about 100 wiki pages that yeilded practically no response. I spend hours trying to anticipate what a new kid would likely ask, this effort was largely wasted. The conclusion of this experiment was that second guessing future questions is a lot of effort with little benefit.
Next I tried to simply log what I actually did to get something working, for example the SD adapter hack. This was useful to me on the three occasions I had to go back and make more, and Sal used it. So at least I found something not exactly useless. Answering specific questions and recording them well at least gives answers to questions that actually get asked.
The next experiment was to get folks to record there own questions and answers and post them on the wiki. This is on going, but it seems that not everyone is equipped to perform this function. The tendency is to assume the read has certain knowledge, that assumption tends to be wrong unless the material is presented very carefully.
I asked Sal to make the tutorials, and construct them such that they could be automated. He did but the result is still pretty difficult to follow, although at least the automation can be show to test every possible function in propforth. To my knowledge, only two people have run these tests. The significance of this ability appear to be lost on the remainder of the software community in general, it seems to be too far ahead of its time. Most folk don't understand testing, let alone automated testing.
Finally, I asked Sal how much it would cost to actually write his book on propforth. I can't afford the 6 months of his time at this point in my fortunes. And even if all 300 people bought it (unlikely), it would still be negative profit. But he did compromise by constructing and spending the time to write propforth.htm.
So far the data suggests:
* Anticipation every possible question in advance is a fools errand, it costs a lost, generates a huge pile of noise, its very difficult to maintain, and only a faction will ever be used, even if it can be found.
* Answering questions when asked yields 100% "used" material, but generates a small amount of material. People are shy about asking in the first place, and don't ask clear complete questions. I.E. asking about a function when the question is really about design. It takes days to dig through to get to the actual issue.
* Doing a complete requirements trace is the only exhaustive method that completely addresses all capabilities. But, each person has different highest level requirements. So we must start in the middle at the software functional requirements. We can list the functions, and their inputs and outputs. Details on the inner working of each function are needed, but this requires an understanding (by the reader) of the code in the first place, which we cannot assume. Rather than fight this, we decided to fill this in as asked, if ever.
The bottom line is, its too much work for one or two guys to do alone. But there is not well defined way to get additional hands on board. Without a consensus of goals, methods, terminology, and content; and a bunch of volunteers, we have to proceed with what we have until more alternatives become available.
Its not the best situation, but its free.
I've probably missed a thing but where is that?
In the search box, select All Pages to show the the deprecated pages as well, to get the full count
http://code.google.com/p/propforth/w/list
How do I put propforth.HTM (from the archive) so it displays on the wiki?
I tried pasting the HTML into a wiki page, but it choked, and pasting in the text requires endless reformatiing.
There's got to be an easy way?
I have news.
Forth study meeting will take place at 12/23.
If you live at Osaka in Japan, please join to study meeting.
If you join to it, please enter below;
http://atnd.org/events/34669
Can we dial in? I'd like to listen and watch even if I can't talk.
Sorry, it cannot do.
There is not equipments(Ustream) in this place.
To be honest, nobody might join in Forth study meeting.
PB,
Here's what the Help for wiki page creation says:
"HTML support
To aid in the presentation of a wiki page there is some support for HTML. HTML tags are only supported in wiki pages, not in page comments.
HTML syntax can be used in conjunction with wiki syntax, but it is recommended against doing so where possible."
This would make me think it's not easy to do without a lot of creation and linking and relinking.
Google site should support your own generated HTML pages - haven't tried this yet.
Either way, the trick is creating the subpages or additional HTML files for each link. If you have each PropForth word as a linkable item, then there needs to be a wiki page or .html file created containing the details for that word. Lots and lots of work as you are aware, especially on a still dynamic vocabulary. I would think this could be automated but just don't know the best tool to use. I would love to be able to create pages like arduino.cc has for their reference doc but don't know how. I'm wondering is doxygen or something like that would be embeddable inside Forth code?
The other alternative is to write your own program to chop up a .f file and create the .html files needed and the links to them. This would be like the big brother to the program I wrote to create the word index.
All is doable but this is all related to documentation which is the last thing most people want to do or even worse related to documentation maintenance which I don't think there has ever been a documented case of a programmer EVER doing!!
Wonderful. I am still working on asynchonous serial ports and will soon have some added material to help those that may also been having difficulty with these useful and important connections to other devices.
I still have not gotten my Chopstick Printer working but a good document may just have to come first. If anyone needs a dumb terminal for the PropForth on Propeller, one can use another Propeller board with video and keyboard and software from PockeTerm for free.
Or if they want to support PockeTerm, they can buy their board and use the same software.
PockeTerm PockeTerm PockeTerm PockeTerm
The Spin Files are at the link below - look at the bottom of the page
http://www.brielcomputers.com/wordpress/?cat=25
Taiwan still has an active Forth Interest Group if you care to visit. It would help if you could type Chinese.
http://www.figtaiwan.org/
Europe has a lot of loyal avid Forth users as well. And Silicon Valley Forth Interest Group still is somewhat active. Considering that I cannot find the local Kaohsiung Linux Users Group (LUG) and the place they claimed to be meeting at never heard of them, this seems to demonstrate stronger interest in Forth than in Linux in Taiwan.
Well if you go to the PropForth download site, you will find them. But the last time I looked the total was 88 wiki and I think that some of them are Sal Sanci's work.
We all just have to overlook some of these inacuracies. Closer to 80. That is still a substantial amount of effort by Prof Braino.
http://code.google.com/p/propforth/w/list