Propforth4.0a available for download
prof_braino
Posts: 4,313
PLEASE NOTE: 4.0 is no longer the current version of propforth
See this post for details:
http://forums.parallax.com/showthread.php?132332-PropForth-4.5-Available-for-download&p=1010215&viewfull=1#post1010215
Propforth4.0a re-organized by including numbering in the file names, and has corrections for several typos, and more (hopefully better) comments.
http://code.google.com/p/propforth/downloads/list
It also includes a sub-directory with versions of the code that run with less than 64k EEPROM; i.e. does NOT use EEPROM files system by default.
Please post whether this version is clearer than the previous version.
NOTICE: a version that is compatible with the demo board hardware will be posted separately, time permitting. Probably will be v4.0B. Does anybody else even use the Demo board with propforth?
See this post for details:
http://forums.parallax.com/showthread.php?132332-PropForth-4.5-Available-for-download&p=1010215&viewfull=1#post1010215
Propforth4.0a re-organized by including numbering in the file names, and has corrections for several typos, and more (hopefully better) comments.
http://code.google.com/p/propforth/downloads/list
It also includes a sub-directory with versions of the code that run with less than 64k EEPROM; i.e. does NOT use EEPROM files system by default.
Please post whether this version is clearer than the previous version.
NOTICE: a version that is compatible with the demo board hardware will be posted separately, time permitting. Probably will be v4.0B. Does anybody else even use the Demo board with propforth?
Comments
Yes. The number is incremented when Sal (the author) makes a new release that involves new features, internal code changes or corrections, or new or different hardware support.
The letter is appended and incremented if in testing we find that there are errors in the documentation etc.
In this case, we didn't follow one of our rules, which is that propforth always runs on all props. Because propforth.f contains "fswrite" it need the EEPROM file system, and so it doesn't really work out on the demo board which only has 32k. So I made this here A version that has a subdirectory where the files do not contain "fswrite". I have yet to make the version with the pin out for the demoboard, so there will be at least one more B release.
The only differences between 4.0 and 4.0a are the typo corrections in propforth.f, fs.f, and the readme.txt files, and the file names that sort in the order used.
If the numbers in front of the files names is too stoopid, I can take them out. I thought it would help at the time, now I'm not so sure.
Thanks for the input. The original assumption was the most users would use only protoboards/custom configurations. Now it looks like 50/50 standard (i.e. demo board) vs curtstom (i.e. proto board). The other assumption was that old style TV's would be rare. Now its starting to look like TV is used when available.
I'll work on an example for comnorom.f (MASTER emulates SLAVE EEPROM) and spineret using the demoboard (pins 0-7).
Anybody want to take a stab at TV support?
At the Propforth4.0/4.0a prompt, hit F1, then hit <enter>
Although no characters are displayed, propforth responds with UNDEFINED WORD
If you fumble and wack your keyboard, sometimes invisible characters (F1, esc, control chars) enter the input stream.
In pre-v4.0 versions, non-print characters (esc, tab, null) were converted to spaces by scan in the interpreter. In 4.0, Sal had a need to recognize these characters, and changed scan. But now we think its the cause of a bunch of intermittent errors.
The behavior of scan will revert to replacing non-printable character with space in the next version 4.1.
key and emit will continue to operate as always, and were/are/will be unaffected by these change(s)
So far this is a minor issue does not require an immediate correction, just be aware of it
Also, I posted a far more complete PF4 Setup/EEPROM File Management document at
http://code.google.com/p/propforth/wiki/PropForth4BrianRiley
Thanks
hinv has the zipit 2 which he's hacking to run linux to provide a field programming terminal for his prop. Last I saw they were modding to add a serial chip. I don't know how far the project has progress, apparently they had a run on zipits after the link was posted; but it looks like most of the pieces you need are out there or at least in progress.
http://forums.parallax.com/showthread.php?119733-ZipIt-Z2-Propeller/page8
Your documentation looks great!
The first rule of thumb (previous team consensus) is that propforth runs on _any_ propchip. Specific hardware configurations are add-on extensions whenever possible. The exception that proves the rule is high resolution vga support.
The role of the demo board is to provide a reference example for alternate pin-out, just as with the Hive board, etc. So the only "work" that has to be done is to move the pins from 31, 30, 29, 28 etc to 7-0 as available on the demo. Same for SRAM: The SRAM on the Hive will be one example, and the SRAM on the C3 another. At least that has been the idea so far.
I'll be making the demo board examples (unless somebody beats me to it) but Sal is doing the real work of designing the reference config for N-Slaves. This arrangement has given us a division of labor and steady progress. (Your input can modify this how ever you suggest)
So don't worry, we already agree with your intent, we have felt up to this point that the demo is still worth keeping since we have them in the labs. If you get your hands on any early C3's by all means let the team know! Andre did not send me any; the prototypes were too expensive and it was pretty clear the port to the C3 will take less than an afternoon. (of course the additional hardware might take a couple weeks longer)
I made sd_loader. A few people may wait?
sd_loader load forth-codes inside SD-card to ram(dictionary).
Maybe there still are bugs.
Usage:
getting list inside SD
sdls
1 LOGICA~1.F (LogicAnalyzer.f)
2 DUMP.F (Dump.f)
3 SD_VIE~1.F (sd_viewer_2.4.f)
Still not display LFN. Fist saving file to SD-card is small number.
sd_viewer_2.4.f is same as sd_viewer_2.3.f.
Usage refer sd_viewer_2.3's document I had posted on PropForth3.5-thread.
Loading file to ram.
1 sdload
No file number cause stack underflow error because no error trap.
Please report bugs.
Nice work. I will give it a try.
All
I will have some basic building blocks for a generic forth text editor shortly. I will see if I can include a simple one line demo to run on a serial terminal. It should be possible to demonstrate the following features> insert and slide right, overwrite, backspace, delete and slide left etc.... a cr will write the line to Hub ( for demo , xmem for full version). Up arrow will return the previous line, down arrow will return line below the current line. To do this I will have to rewrite the line every time it changes but it should be possible to demostrate the general idea. It won't happen before Christmas so don't hold you breath
A full version will have to wait until I have worked through the PASM drivers for the C3 because that's likely to be my target platform. Thats not to say that it will not run on any prop board but the xmem and vga drivers will have to be modified. Row and Col max length can be defined.
Ron
Hey Ron
This is great! I started work in this direction based on Frank Sargent's Pygmy forth. The version I started from was for the PC but the forth code on top of the assembler stuff is fairly generic. I got bogged down at the command line history stuff when I started my new job, but it was fairly quick progress. Look at his material if you want another point of view, some of his stuff is really nice.
Have you chosen a xmem model? The Hive board (in the lab) use 512k of SRAM and latch, there is a rumor we can run it without latch? I think the C3 has SPI memory? Hopefully one method will leand itself to the other.
If you want to post, we can look at you intermediate work. My focus is code review and documentation, but I don't actually get around to it much these days.
V4.0 was the big change. Now we are just cleaning up the documentation, adding examples, and making the extensions. So now is as go a time as any, Just as the VGA extension are stable in themselves, work on the TV port should not be affected much by any kernel tweaks, nor by any extensions as those are on top of the kernel
Access to xmem is col_max_len bytes(definable), 40 being the likely minimum number of bytes read or written at any one time. If latches are an issue the PASM driver could fit into aslicer.
Ramblade, 512k, does not use latches. Hydra 512k does, but with Auto increment set it should be fine. (don't like it though)
Jazzed's 2M Dram board is by far the best Xmem available (IMO) but more suited to C . I will get one, it could be used for Forth Media Projects. It will get a lot of use here with Catalina also. Others boards by Bill Henning and Dr_A are also available
The reason for using a C3 box is that it a complete package. It would be a good starting point for people new to Forth, but unfortunately SAL's Forth is crippled by Docs that target people with a good working knowledge of PASM and the Standard Forth Kernel.
There is nothing wrong with that, but it means that Forth only gets used by a handful of people.
If there are any readers who would like to look at Forth, then Getting Started with Forth is great reading with lots of exercises which you can try out on Propforth interactively. The book is free online. NOTE> PropForth uses st? and not s for viewing the stack. You could change that of course. Just for fun try this word : s st? ; That's a new propforth words folks.
Seasons greeting to one and all.
@Steve, nice to catch up, should be around for few months now
Ron
The solution supports 32MB SDRAM (2M was a typo I'm sure). The SDRAM is used with a cache which makes it equally suited for any language that offers support. The GNU based Zog C/C++ project is coming along well, but Catalina support is not available just yet.
Anyone who wants to port their functional language offering (yes even Forth) to use SDRAM should send me a PM to discuss a discount. That's all I'll say about it here. Thanks for your patience.
Merry Christmas.
--Steve
The telnet code I posted earlier was from the very old spinforth code, Sal's work from 2008. I misunderstood, thinking he had redone the same for v4.0
This is not the case. The snet.f is just code for MASTER to TALK to SPINERET over SERIAL same using a terminal program on PC. This is how Sal does his development; I think it does not use the prop-plug.
The spineret_eth.f is the very raw development he's doing. It does not do anything all the way yet. I propably should not have put it in the package, but I thought it was further along. If you want to play with it please go ahead, or wait till after Xmas. The 4.1 release should have something for spineret that is more fun.
Sal said something about being able to use the latches but they are unnecessary with the prop; I don't know what his plans are but I imagine we will start without the latch and if that doesn't work use the latch. I image a lot depends on what one wants to do for a particular application and how one plans to do it.
I don't have ramblade or hydra; if you say jazzed's board is best, thats good enough for me. I'll be looking forward to seeing the code.
Interesting that you say Sal's forth is "crippled". I don't know any more PASM than the average prop user and have no problems (aside from having to figure out the prop assembler when I need to use it). I would guess that anybody that wants to use forth would pretty much rely on the standard forth kernel. Since the C3 isn't available yet, I would think it desireable to have a kernel that can be extended to any hardware, and enable people like you and me to add support for additional peripherals as they become pertinent. A "complete package" is the goal, I intend to use it for my kid's robot club if it gets to that point before the leave grad school (they are in elementary school now).
I have asked about putting into the kernel, but the does specific things that Sal needs during development, so my words are an extension. I am a bit behind, but if you would like to start I would like to post it and get other folks contributions in there too.
I just used a prop-plug and loaded the kernel as usual, just to show that the board was alive. I didn't get any farther before i ran out of time.
I think the snet.f / spineret_eth.f maybe an example of doing what you suggest, as there had been a user question on that topic; Sal said it was pretty straight forward. But I didn't try it, straight forward to Sal usually means not so straight forward the first couple dozen times to this braino.
http://www.shaels.net/index.php/mv4th-forth/mv4thgeneralcat/96-mv4th-project-overview
I stumbled across it while, unsuccessfully trying to track down "Getting Started with Forth." Ron ... link to it, please??????
http://www.forth.com/starting-forth/ It's a fun read, will get you up and running in no time
For those wishing to write a Forth compiler try JonesForth. An open source compiler with a step by step tutorial for those wishing to write a Forth from the ground up. The reason I mention Joneforth is that its a real insight into Interactive Forth.
@Steve I will do just that. Don't worry about the discount, cheers.
That link does not appear to have been updated since July. He does site the same existing forths that I was looking to use as references. Of course, you can only use those to a certain extent, since the prop architecture makes any prop forth necessarily different in at least some respects then those other forths listed.
He's got a good link to http://galileo.phys.virginia.edu/classes/551.jvn.fall01/primer.htm
The VIBE block editor he points to might be a good starting point for a editor.
http://www.complang.tuwien.ac.at/forth/vibe-2.1ans.fs
He also point to the reference for stephen pelc http://www.mpeltd.demon.co.uk/arena/ProgramForth.pdf
Also, he has a reference to propellerforth, cliff biffle's work from a few years ago that stopped with out me ever finding any code. I usd to think Cliff's stuff was the only forth out there for the prop, and was going to make my own, when I ran across Sal's work. Seem like he might have had a similar thought, but did not find us.
It seems like he is doing the same work, maybe he has some perspective to share. I'll try to reach him.
This post is bothering me for some reason. First as mentioned earlier, it suggests basing propforth on hardware that does not exist, and will not be available for some time. Also, it is very specific hardware, and not not likely be used by the majority of applications that do need all the hardware on the C3 and instead need something else.
Second is the statement that propforth is "crippled" because it targets "target people with a good working knowledge of PASM and the Standard Forth Kernel". Disagreement with the PASM bit is already stated, now here's disagreement with 'crippled because it target people with a good working knowledge the Standard Forth Kernel'.
The only folks that will ever use forth of any kind are the people that already want to, and that means they either have or are willing to achive "a good working knowledge the Standard Forth Kernel". If it only gets used by a handful of people, that's fine, that's whats supposed to happen. Forth is only a tool in your tool box, you use it or you don't. The vast maority of the folks that don't want to use forth should not be using it anyway; they wouldn't be happy.
Personally, I wouldn't want to write windows vista in forth (unless I got paid) nor would I put vista on an interplanetary space probe. I would use the proper tool for the job. Forth just happens to be my "favorite screw driver".
I appreciate that you want to "spread the word" about forth goodness, but that's not this. This is just the forth for those that want to use it. For those that do, we are making is as flexible as possible for folks like you can do exactly what you describe, should you so choose. I guess I don't want you to mis-interprete this major strength as a weakness, the focus of the kernel is just different than your personal focus. There is no contradiction or conflict with these foci. One is core development, one is user applications development.
Does that make sense? Its still early here.
Cliffe Biffle has created an open source complete Forth development system for the Propeller, called PropellerForth. If you are not familiar with what Forth is about, its basically a programming language and development environment that runs entirely on the Propeller. You do not need a PC to program your Propeller board (Prop Demo, Hydra supported) anymore. Once you use the Propeller Tool to upload the single binary image all your other development tasks are performed on the Propeller directly. Simply plug in a keyboard, hook up a TV, and off you go!