Prof Braino, I was great to meet you. Thanks for the presentation, it has me thinking about Fourth. I'm still not completely sure what it is, but I'm more inclined to check it out now.
Thanks Ray. That was my first presentation on forth. I should demonstrated more about testing interactively from the command line, didn't think of this till I got home. Its a handy tool for quickly testing the hardware as you read the datasheet, so it has its uses.
Thanks! I tried again. It works fine after power cycle.
So is your SD up and running? Was it the the issue omitting the mount words, or did you have SD V1 and/or MMC cards?
Do I have to make any SD changes for the next release? Sal and kuroneko have found and fixed two items already (Issue 27), one in LogicAnalyzer and one in MCS; soo we can have a new release as soon as the SD changes are identified. .
Nobody has needed I2C yet so I nominate YOU to start.
I'm pleased to report that this is well underway. A sudden need for a Propeller to act as a fast I2C Slave prompted the creation today of a version in PASM that consists mostly of CALLs. Because of this, I expect its conversion to FORTH will be straightforward. Of course this is bassackwards; typically one would use FORTH to avoid assembly. But assembly has been the gateway to every other language I've learned, so why not FORTH?
I'm pleased to report that this is well underway.
...
But assembly has been the gateway to every other language I've learned, so why not FORTH?
Very good to hear! Will this be something that can be used on the C3?
Even better to hear is that you have extensive experience with assembler, as I do not.
I further nominate you to be a beta tester for the assembler optimzations in v5.0 later this summer. I don't have the proper insights to offer many comments on Sal's assembler code, someone with your perspective would be VERY valuable to have looking at the code early on, before its released. Please consider doing this if its your idea of fun, it would help greatly.
PM me if you would like to be added to the contributors list.
... tinkering with Forth a little.. I'm not sure I'm a "Forther" yet, but I did post this today.
... combine all of the recent useful links regarding PropForth 4.5 into one place.
Have no doubt, you are now a fully qualified forth cultist. Feel any different?
Thanks for the write up. If you see any problems in the docs, let me know and I will try to correct them.
ALSO, if you have any more bare chips, try adding a slave to the slave. Once the wires, resistors and capacitor are connected, it should run as many as you have, no code changes.
PropForth 4.6 should be out this week. It has changes based on kuronekko's analysis, which resulted in a significant increase in throughput in the Multi-Channel High Speed Synchronous Serial (MCS). Thanks Marko! Also a bug fix to the software Logic Analyzer.
PropForth 5.0 is coming along nicely. This could be game changer. Do I sound excited? I'm excited.
FYI, I have posted C3SPI on the Google website. I have also posted all three 3 spi forth applications on the Propeller Forth Interest Group thread.
In order to make the C3 an effective platform for PropForth, we need to develop forth versions of the PS2 keyboard and TV drivers. Has there been any attempts to do this?
C3SPI ... posted all three 3 spi forth applications on the Propeller Forth Interest Group thread.
C3 ... forth versions of the PS2 keyboard and TV drivers. Has there been any attempts to do this?
Excellent news! I have been anxious to get the JupiterACE working on C3 peripherals.
The original Jupiter ACE and the most recent version 3.6 JupiterACE have PS/2 and VGA support. The assembler VGA and keyboard support from the OBEX are added to the forth kernel. However, the assembler support is changing for v5.0, so bringing VGA forward is scheduled for after 5.0 comes out. Whether used as is or written in forth, TV support still has to be in assembler for speed. Of course one could birng it forward to v4.5 using the lasm word as in caskaz examples, and the majority of the support will be in place for 5.0
Earlier Sal decided that TV was not a primary development path for the kernel, and left TV implementation as an execrsice for users. There have been a couple of users asking about TV, so I'm sure it would get used, but Sal's bandwidth is filled by kernel work. TV has been on my list but its still a bit beyond my abilities, I was hoping somebody familliar with TV would give it a try. Phil Pilgrim had expressed interest forth and has done TV, but has not join this small playground yet.
I suggest starting with JupiterACE from 3.6, which has HiRes VGA + keyboard, and LowResVGA.f which uses the standard kernel and adds VGA + keyboard.
Please give it a look and let me know if I left anything off or got something wrong.
Caskaz - Do you read the docs in English or do you use a translate program? Do the translate programs work very well? If I remember correctly, Forth was once popular at a Tokyo (Keio?) univeristy. I'm wondering if any of those folks will be able to use this material...
Is there a way to delete, replace or overwrite a file on the SD? I've been playing with the TELNET server and making config changes in ipconfig.f - each time I want to change something, I need to wipe the SD card and reload ipconfig.f, ipserver.f and ipscripts.f ......it's starting to drive me nuts (nuttier, anyway)
Is there a way to delete, replace or overwrite a file on the SD? I've been playing with the TELNET server and making config changes in ipconfig.f - each time I want to change something, I need to wipe the SD card and reload ipconfig.f, ipserver.f and ipscripts.f ......it's starting to drive me nuts (nuttier, anyway)
OK, this is kind of weird. The design is that the SD is internal to the prop system. The intent is that the sdfs support is for a "microcontroler file system" not a "general file system" as found on a PC or workstations. So the usage model is that you already know what files you need on the sd for your application, and those start out with a name and a size and never go away. This is the MINIMUM necessary and sufficient for the microcontroller file system as designed (for Sal's use, since he is the only one using it at the time).
So, for the time being: Yes, if you want a file to go away, you have to wipe the card. Otherwise support would be required for defragementation, delete, verification, etc, and Sal didn't do this.
IF YOU REALLY WANT FILE DELETE (and I think at least some of use will want this, but Sal will want it last), we have to write it ourselves. Its not so hard, but it will be a bit slower and a bit larger memory foot print. The assembler optimizations are not ready; so we don't know the best way to fit it into the kernel.
So you and I and caskaz (and Nick and Brian and Ron) need to talk about how we want to do this and what we want it do do, in detail.
Comments
Thanks Ray. That was my first presentation on forth. I should demonstrated more about testing interactively from the command line, didn't think of this till I got home. Its a handy tool for quickly testing the hardware as you read the datasheet, so it has its uses.
If you have any questions, post here or PM.
So is your SD up and running? Was it the the issue omitting the mount words, or did you have SD V1 and/or MMC cards?
Do I have to make any SD changes for the next release? Sal and kuroneko have found and fixed two items already (Issue 27), one in LogicAnalyzer and one in MCS; soo we can have a new release as soon as the SD changes are identified. .
I'm pleased to report that this is well underway. A sudden need for a Propeller to act as a fast I2C Slave prompted the creation today of a version in PASM that consists mostly of CALLs. Because of this, I expect its conversion to FORTH will be straightforward. Of course this is bassackwards; typically one would use FORTH to avoid assembly. But assembly has been the gateway to every other language I've learned, so why not FORTH?
Very good to hear! Will this be something that can be used on the C3?
Even better to hear is that you have extensive experience with assembler, as I do not.
I further nominate you to be a beta tester for the assembler optimzations in v5.0 later this summer. I don't have the proper insights to offer many comments on Sal's assembler code, someone with your perspective would be VERY valuable to have looking at the code early on, before its released. Please consider doing this if its your idea of fun, it would help greatly.
PM me if you would like to be added to the contributors list.
Since the eeprom is an I2C device, the _eeprom words in the PropForth core form the basis for an I2C word set.
FYI, I am currently testing a C3 specific SPI word set. I hope to post it next week.
NickL
You might want to let these guys know about your forth. They still have Cliff's Propeller Forth up there, but not PropForth
http://www.forth.org/compilers.html
I sent an email to the webmaster. It looks like the site has not had much activity since 2005(?)
I also tried to update the forth freaks kwiki http://www.forthfreak.net/ but my edits don't seem to stick.
Since your demonstration at UPEC, I've been tinkering with Forth a little.. I'm not sure I'm a "Forther" yet, but I did post this today.
http://www.gadgetgangster.com/news/45-designer-news/419-weekend-projects-propforth.html
I tried to combine all of the recent useful links regarding PropForth 4.5 into one place.
OBC
-Tor
OBC
Have no doubt, you are now a fully qualified forth cultist.
Thanks for the write up. If you see any problems in the docs, let me know and I will try to correct them.
ALSO, if you have any more bare chips, try adding a slave to the slave. Once the wires, resistors and capacitor are connected, it should run as many as you have, no code changes.
http://code.google.com/p/propforth/wiki/PropForthStatus
PropForth 4.6 should be out this week. It has changes based on kuronekko's analysis, which resulted in a significant increase in throughput in the Multi-Channel High Speed Synchronous Serial (MCS). Thanks Marko! Also a bug fix to the software Logic Analyzer.
PropForth 5.0 is coming along nicely. This could be game changer. Do I sound excited? I'm excited.
I got a response back from the FIG webmaster. Thanks for reminding me to do this hinv!
In order to make the C3 an effective platform for PropForth, we need to develop forth versions of the PS2 keyboard and TV drivers. Has there been any attempts to do this?
NickL
Excellent news! I have been anxious to get the JupiterACE working on C3 peripherals.
The original Jupiter ACE and the most recent version 3.6 JupiterACE have PS/2 and VGA support. The assembler VGA and keyboard support from the OBEX are added to the forth kernel. However, the assembler support is changing for v5.0, so bringing VGA forward is scheduled for after 5.0 comes out. Whether used as is or written in forth, TV support still has to be in assembler for speed. Of course one could birng it forward to v4.5 using the lasm word as in caskaz examples, and the majority of the support will be in place for 5.0
Earlier Sal decided that TV was not a primary development path for the kernel, and left TV implementation as an execrsice for users. There have been a couple of users asking about TV, so I'm sure it would get used, but Sal's bandwidth is filled by kernel work. TV has been on my list but its still a bit beyond my abilities, I was hoping somebody familliar with TV would give it a try. Phil Pilgrim had expressed interest forth and has done TV, but has not join this small playground yet.
I suggest starting with JupiterACE from 3.6, which has HiRes VGA + keyboard, and LowResVGA.f which uses the standard kernel and adds VGA + keyboard.
http://code.google.com/p/propforth/wiki/PropForthExtensions
Please give it a look and let me know if I left anything off or got something wrong.
Caskaz - Do you read the docs in English or do you use a translate program? Do the translate programs work very well? If I remember correctly, Forth was once popular at a Tokyo (Keio?) univeristy. I'm wondering if any of those folks will be able to use this material...
Is there a way to delete, replace or overwrite a file on the SD? I've been playing with the TELNET server and making config changes in ipconfig.f - each time I want to change something, I need to wipe the SD card and reload ipconfig.f, ipserver.f and ipscripts.f ......it's starting to drive me nuts (nuttier, anyway)
OK, this is kind of weird. The design is that the SD is internal to the prop system. The intent is that the sdfs support is for a "microcontroler file system" not a "general file system" as found on a PC or workstations. So the usage model is that you already know what files you need on the sd for your application, and those start out with a name and a size and never go away. This is the MINIMUM necessary and sufficient for the microcontroller file system as designed (for Sal's use, since he is the only one using it at the time).
So, for the time being: Yes, if you want a file to go away, you have to wipe the card. Otherwise support would be required for defragementation, delete, verification, etc, and Sal didn't do this.
IF YOU REALLY WANT FILE DELETE (and I think at least some of use will want this, but Sal will want it last), we have to write it ourselves. Its not so hard, but it will be a bit slower and a bit larger memory foot print. The assembler optimizations are not ready; so we don't know the best way to fit it into the kernel.
So you and I and caskaz (and Nick and Brian and Ron) need to talk about how we want to do this and what we want it do do, in detail.
For the time being, I say leave it until fall.
Maybe not a full blown file system (too much overhead). I'll play with it and see if I come up with any good ideas!
Playing is the key to my learning!
PropForth 4.6 is now the current release, please continue conversations to this thread:
http://forums.parallax.com/showthread.php?133312-PropForth4.6-is-available-for-download