If you read "Starting Forth" on line, the third chapter is about Blocks and editors. It mentions them but also discussed 'newer' alternatives of using a resident file system. Leo Brodie also claims that Forth is not really much of anything without 'disk storage'.
Remember, this was when 8086 was new. Read that as "Forth doesn't have much room without more storage"
Then if you move on to GForth and its provided tutorial, you find that while one can still use Blocks, they are again 'depreciated' in favor of the resident OS's file system. And then there is the SDcard Association's assertion that for cards that are 2Gbyte or less, they support 512byte sectors with FAT16 file system as the best means for wear leveling. Okay, okay! I know this is a micro-controller, not a micro-computer. But if you are going to use SDcards, why not follow SDcard Association guidelines until the reasons not to do so become obvious to the enduser?
Remember the sd AS USED INTERNALLY IN PROPFORTH is internal and not removed ever, unless it goes bad, in which case its handy we used a socket, like the EEMPROM.
IF YOU WANT FAT, YOU CAN implement it and use it as an extension, or as part of a custom kernel (which we will get to later, custom kernels are totally easy in v5.3 compared to ealier releases).
BUT, this is Sal's tool, so Sal's purposes, and FAT support for th SD is not in the default kernel, his choise. Its his decision to make, and you decision to change, but you can't tell him what to do with his on tool, you'll break his design for the thinng in his basement that doesn't work that way.
Again, you can add SD, and then we can talk about how slow it got and where all your resources went. We were going to save this conversation till more folks caught up, but we can start now if we must. I advise against starting this topic too soon.
IF you do support FAT16, you don't have to waste much needed storage on a Block Text Editor in Forth. The text editing can be done on any generic editor and the SDcard can move from PC to Propeller as needed. Backups on the PC are easier too.
You got this backwards.
Forth really was developed at a time when ASCII was the main text code (along with IBM''s EBDIC) and interface was generally a dumb terminal connected by RS232. All the 'need to bit-bang sensors' and fancy displays were not really part of the early Forth concept.
PropForth has some missing words, like PAGE that clears the terminal screen. I guess my complaining about SEE missing has added that or Decompile to PropForth. But 'Starting Forth' doesn't mention SEE or Decompile.
SEe ANSII escape sequnces for PAGE - but we don't use the arcde page, I used CLS because thats what we used that day.
See and Decompile were always part of propforth, they just got pushed off the table by newer work, Sal is going to bring those forward now that he knows somebody still wants them. (the advise is that you only use them to get started, after a certain level you don't ned them anymore, my brain is not so big yet...)
About the only word in the 'Starting Forth' that I personally consider useless is OCTAL. Why so? I think more programmers have gotten confused and hit snags when looking at OCTAL. For one, is it 0 through 7 or 1 through 8?. For another, each digit only represents 3 bits in a word where we usally group bits by 4, 8, 16, 32, and 64. And, when you look at a string of OCTAL, there are very few visual clues that it is not Decimal. I personally avoid OCTAL if I can.
OCTAL is 0 thru 7, just as we roll over after 9 in base ten. But we don't need it in the kernel, since we are 32 bit.
And be forewarned that it is just a list at this point. I have not added definitions at this point. The exercise of having the new learner write those in will bring him up to speed, at least I hope so. If you want it in .txt file for easy editing I will have to get cracking.
This is the key, Implementing extensions gives experience, practice is how we gain skillz anything.
... Page as an example ... I just take a teacher's perspective that students should not be unnecessarily daunted, especially in the beginning. Let them find documents
This is going to sound like my fourth grade English teacher, that the kernal is the STARTING point and we all must find and load our own DEVELOPMENT EXTENSIONS during development to fit our purposes. Start with the ANSII escape defs to see how loading extensions impacts size and functionality. Eventually, we may come to a consensus on an "Ideal" set of primary extensions, and an additional libbriary of secondary extesinsions, but for nowSal and I can't guess what these will be. You(se) are the guinea pig(s)
But consider, we and making huge progress, which seems to be increasing in velocity.
Hmm, I guess I really should solder up an old junk SDcard if this is to NEVER be removed from the PropForth system. Yes, it certain is up to Sal as much as Tachyon is up to Peter. I just offer input.
As it is, I really don't want to waste a 2Gbyte card for uses as a 32Mbyte storage device. I will locate something much smaller and save the 2G for the Spinnerette or my forthcomng Cubieboard.
If you are having problems getting the SD to work, please post your steps and results, the errors should be easy to spot.
Did you follow the SD tutorial? It initializes the card, and shows how to use all the words. IF you assume it works automagically like windows... It does but not until you set it up.
Also, if an SD is formatted with windows, propforth doesn't know or care. If you swap the same card for forth and FAT it will appear to work in both systems for a while until both try to use the same block, then one will start to step on the other. Then you will definitely have problems using the card on both systems until you reinitialize it.
After the card is formatted, and you set up a number of contiguous blocks as a "file" propforth just sees it as one big stretch of memory, like a big text file full of spaces (or nulls).
Yes, I followed the SD tutorial the first time out and it did not work. I have worked through all the tutorials at number 1 level and number 2 level with success. But the SD card didn't intialize.
I really wanted to deploy PropForth on the Propeller Demo Board because it has so much more hardware available than the Propeller Proto Board. I started to set up a microSDcard of 2Gbytes, but it makes little sense to have so much go to waste. Failure could have been due to the lack of an added capacitor as the SDcards are power hogs. And the bigger they are, the more power hungry.
Now that I have a better understanding of how to solder up an SDcard, I am going to switch to a 16Mcard that I have and dedicate that to PropForth use. Above you say that the usual switching back and forth of use with a PC will eventually overwrite areas that it doesn't know are already in use by PropForth.
So it seems that PropForth just uses the SDcard as a simple SPI RAM without any file system. I give up pondering the wear level issues. I'll just have to one day try to read the .spin file and see what it does.
I guess you have finally made it clear that once the SDcard is put to use with PropForth, it is not going to be much use for anything else. It seems rather silly to dedicate a microSDcard holder as well, so this is a whole new configuration.
First time out, it failed to intialize - Error 166, from what I've read is the Propeller can't see the SDcard to intialize for some reason - likely a wiring mistake. But I also had 4 warnings in the compiler that I had not seen in the 32k image or the 64k image.
So now I will get a couple of 4x 10Kohm single in line resistors for pull ups (the Vdd is in the middle of nine pins and I can bend up one tab to avoid Vss). IF THIS doesn't work out I can replace the 32K EEPROM with 64K easily enough. I just can't get anything larger that 64K in an SPI EEPROM at the local stores.
As it is now, the whole effort on my part is slowing down as it becomes obvious that I should read more of "Starting Forth" and work completely thorugh the problems at the end of each chapter to really have a good grasp of future Forth projects. A lot of time for the past week or so has been spent in just getting new versions of PropForth and TachyonForth loaded into various boards, but not much has been acquired in basic knowledge. It helped to list the Starting Forth Lexicon as I see where I don't quite understand certain chapters.
Starting Forth - Chapter 3 is about the least applicable to PropForth or TachyonForth as it discusses 'The Editor', which is the traditinal Block system and the alternative that uses INCLUDE for a resident file system. Neither of you are using the Block System or the Resident File System. I guess the SDcard is just an expanded memory with a modified 32K image retained therein while the original remains on the EEPROM with a boot.f added to divert the boot process.
In all honesty, I am trying to acquire Forth as PropForth and Tachyon do it. I have been working through lists of the dictionaries, but they are rather long and many of the words are unclear to me or are unnecessary to know for a novice.
So, I rely on Starting Forth Lexicon for a key short list and the GForth tutorial for a general overview of what I might use or want to create. I learn a lot through GForth that is generally transferable and I don't have to carry a Propeller board with me to study it. I am not trying to force compliance with ANS Forth. I just think that the closer you are to ANS Forth, the easier it is for a wide group of users to learn on their own.
I am NOT saying you should or you must provide anything. If I feel strongly about something, I'll develop my own added words in my own way. Having to fend off such presumptions is tiring and counter-productive. I am sure everyone feels that they have wasted a bit of their energy on such debate.
In other words if I say 'should' or 'must', I mean 'should' or 'must'. If I don't use such terms, 'should' or 'must' is NOT implied. I merely am making observations about what is where.
While I don't know if it is ever possible, I have some hope that I can do a comparative lexicon. But if it is going to upset everyone, I just keep the work for myself. I certainly need one in order to not be confused.
2GB SD cards are already very hard to get so why do you consider this such a precious resource that you would waste your time with an archaic and quite probably incompatible or worn out 16M byte card?????? What are we talking about here? I have 2GB cards that cost me less than $2 or maybe even as much as $5 if I buy them over the counter. Stop trying to cut millimeters off corners especially when you are trying to get things working for the first time.
I only mention this one point to highlight that the greatest impediment to learning can't always be blamed on the tools or the documentation etc. It can just simply be your own mindset. Step back and reevaluate, be practical, not picky, then dive in.
Hmm, I guess I really should solder up an old junk SDcard....
As it is, I really don't want to waste a 2Gbyte card for uses as a 32Mbyte storage device.
my input - just user 2G or 4Gig, whatever is most common in your desk. these are cheap. you will probably NOT be able to wear it out, but you WILL be able to fill it up. Sal's design is to support multiple high speed data streams, LOGGING, and preprocessing. The prototypes are very promising, you will love it.
plan on 2-4 gig sd as standard, and solder a socket if possible. save at least one "real" sd slot for the final project to be announced later.
2GB SD cards are already very hard to get so why do you consider this such a precious resource that you would waste your time with an archaic and quite probably incompatible or worn out 16M byte card?????? What are we talking about here? I have 2GB cards that cost me less than $2 or maybe even as much as $5 if I buy them over the counter. Stop trying to cut millimeters off corners especially when you are trying to get things working for the first time.
Thanks Peter for your clear and concise support.
I'll just skip the SDcard thing until you guys figure out what you are doing. It seems a huge waste of space for backing up 32K of ram. Even 16mbytes seems a huge waste of space for backing up 32k of ram.
And just maybe Peter, this isn't a Tachyon support issue. Why do I have to be berated by you?
It certain isn't about $2 in cost.
If 2GB SDcards are junk (which they are not to me), 16MB SDcards are even more junk. Why NOT use the junkiest junk if I am having trouble, rather than potentially damage useful and better components?
I happen to have other uses for the 2GB. Besides, the 2GB that I tried did NOT work, I have reformated two of them and confirmed that they are good to go for other thing. They were not formated and that may have had something to do with it.
Prof Braino hasn't really explained 'saveforth' methodology in any detail to me. It seems to work on a 64K EEPROM fine. I guess I should just stay with that as I distrust the SDcard setup.
I have no reason to collect 2Gb of raw data that is not in a FAT16 format. I'd want to transfer that file to a desktop for further work. I certain am not hanging on to every promise of a new feature just around the corner. I just wanted to get started with Forth in a reasonable fashion.
This has all gotten rather absurd.
I have wasted another hour in rebuttal to Peter when I am just trying to move leisurely along with learning Forth in PropForth.
Loopy, you might try running the FSRW demo program first to make sure your wriing is correct to the SD card. It does require a formatted SD card, but that's pretty easy to do on most computers. Also, I wouldn't worry about wasting space on a large SD card. Most Prop applications only use a megabyte or two at most. SD cards are cheap enough where it doesn't really matter if you use the whole thing.
Some drivers do have a problem with cards greater than 4G because these are SDHC cards, and not just SD. I know that Kye's driver had a problem with SDHC, but I think he has fixed that. Even most 2G SD cards available today use the SDHC protocol.
I think using GForth is a great way to learn. As you said, it doesn't tie you down to running just on the Prop.
Thanks Dave. This evening the mouse and the keyboard won't boot on my main desktop. That is upsetting me. It seems the +5 power goes down to the USB right after I select the OS from my dual boot menu.
And while I expected to get further on in learning Forth, I feel I have joined a debating society. I suppose some of it is my own doing, but not all.
Nobody wants to admit that the SD Association has hardware specific to sector size and FAT tables to provide wear leveling as they just want to prove who has the fastest PropForth.
There are SRAM SPI chips that can accomodate the speed if they want only that.
Thanks Dave. This evening the mouse and the keyboard won't boot on my main desktop. That is upsetting me. It seems the +5 power goes down to the USB right after I select the OS from my dual boot menu.
Try plugging your mouse and keyboard into a USB hub that has it's own power source. Maybe that will resolve the problem with your desktop computer.
I'll just skip the SDcard thing until you guys figure out what you are doing. It seems a huge waste of space for backing up 32K of ram. Even 16mbytes seems a huge waste of space for backing up 32k of ram.
And just maybe Peter, this isn't a Tachyon support issue. Why do I have to be berated by you?
It certain isn't about $2 in cost.
If 2GB SDcards are junk (which they are not to me), 16MB SDcards are even more junk. Why NOT use the junkiest junk if I am having trouble, rather than potentially damage useful and better components?
I happen to have other uses for the 2GB. Besides, the 2GB that I tried did NOT work, I have reformated two of them and confirmed that they are good to go for other thing. They were not formated and that may have had something to do with it.
Prof Braino hasn't really explained 'saveforth' methodology in any detail to me. It seems to work on a 64K EEPROM fine. I guess I should just stay with that as I distrust the SDcard setup.
I have no reason to collect 2Gb of raw data that is not in a FAT16 format. I'd want to transfer that file to a desktop for further work. I certain am not hanging on to every promise of a new feature just around the corner. I just wanted to get started with Forth in a reasonable fashion.
This has all gotten rather absurd.
I have wasted another hour in rebuttal to Peter when I am just trying to move leisurely along with learning Forth in PropForth.
Calm down Loopy, we miss a lot of body and tonal language in these posts, I am trying to help you and so I am employing the equivalent of hyperbole in my reasonings so that even if you only catch the fringes of what I am saying, it should help you to see what I am saying. It's not about a rebuttal or having a go at you, not at all. If you were sitting in a workshop that I was conducting you would have to keep up with it and do things the same way. There is plenty of time after that to ask questions and do your own thing.
My point about the ancient SD card is very clear because it may be well used and suffering from wear failure or at least slow to respond. I have seen this even with old 256M cards, they just don't respond correctly. If I don't throw them in the bin then I am simply wasting my own time but I know which is more valuable. SD cards do not benefit at all from FAT16, they only suffer it. Forth does not require a FS to be able to store information on the card. I would gladly use a 2GB card to store less than 1M byte. You are already using eight 32-bit RISC CPUs to do very little most of the time. Would you dig that old 8751 out of the junk box and use that instead?
We went through this with CD's. Gotta fill 'em up, because they were $2-$5 a pop. When they dropped to $.10, suddenly, they don't matter. Just burn it and go.
What you are attempting - learning three different Forth variants in parallel is ambitious at best and to me is very confusing. I'm trying something similar with PropForth (I have some experience), Tachyon and Factor ( which is a forth like PC language - Forth on steroids). It is difficult and I'm to a point where I need to make some decisions and clean off the plate a little bit and concentrate on just one...probably PropForth at this time since I have the most experience there...
AND 5.3 RELEASE IS JUST MINUTES AWAY!!!!!! :0)
Perspective Moment: Pardon me if I stray for a bit.....what if you look at C as a science, like chemistry and you look at Forth as a collection of religions having similar beliefs, like Christianity. C has a fixed set of elemental units and rules in how they can go together that really can't be changed. With this collection, you can put together all kinds of new things but you usually can't get more kinds of elemental pieces and you can't change the rules of how they get together. With Forth, you have a common set of fundamental beliefs that all Forth branches share but each branch has different ways to explain or express the belief. All Christian religions have God, Jesus, Christmas, Easter, death and resurrection,etc. you can look at the core beliefs of a religion and say it either looks pretty Christian or it doesn't. When you walk into a service on Sunday, you may feel out of place for a while but you'll get the general sense of things pretty soon. All Forths have a basic set of features, stack orientation, compiler words, extensibility, threaded, interpreted dictionary structure and so on. You can look at the core of the language and determine it is Forth-like. Wen you first sit down to use it the first time, it may throw you but you understand the basic mechanics and will learn it and adapt it to your application.
With that said, from a post a while back, I think you still have a misunderstanding of saveforth and what benefits the file systems offer to you and your application.
From what I understand of the code, saveforth simply copies the dictionary portion of your current executing Forth image from RAM to EEPROM. (This statement just made we think of an experiment I want to try.) that's really all it does. If you create a new word, DON'T do saveforth and reset the propeller, your new word is gone. Ifmyoumcreate a new word, do saveforth, reset the propeller, your word is there because it became a part of the kernel that saveforth copied to the lower 32k of EEPROM. That's it, all it does. It only ever uses the lower 32k of EEPROM and will work on ANY propeller with an EEPROM. You develop your application by cutting/pasting or typing new word definitions into the terminal. Whenever you want to save your work to EEPROM, you do saveforth. If you messed something up, you reload form the PC or reset and forget back to a marker word you created and star moving forward again. Once you hav eyour application done, you have your modified kernel in EEPROM and you have a file or files of word definitions that you can cut/paste to recreate it. Works great for small applications that fit in 32k and don't need any persistent data.
You can learn 95% of PropForth without ever going beyond a 32k EEPROM and cutting and pasting your way to a working application. Forget the upper EEPROM and the SD card and you have bunches to learn!!
When/if you have a larger application or need some data files, logging or other persistent data, you cango to the EEPROM kernel or the ad kernel. Both of these extensions to PropForth offer you the same features the difference is the size of the files pace area (EEPROM is typically just the upper 32k of EEPROM, SD support gives you the size of your SD card. There could be SDHC issues but I've never been there yet.
With a file system, instead of adding words to the kernel and doing a saveforth, you keep,the kernel as it was loaded and then though the Floyd and load (I think), you can load woes into the dictionary, run that part of your application, forget back to a marker, load a different part of the application, run it, forget it, etc. for as complicated an applications you can manage. Forth source files are copied out into the file system (don't worry about the details until you NEED it - you don't need to know to learn PropForth). Take small bites. You don't need to be able to write the history of Forth and debate comparative Forth features while you are learning your first couple of Forth implementations - it will drive you to madness!!!
The file systems only extend memory in the sense you can store source code in them and can load source form SD or EEPROM instead of typing it in. Both share the boot.fs concept. When booting, if either the EEPROM or SD kernel finds a boot.fs file in the file system, it will start executing the words in it before it goes to the interpreter loop. Nothing more, nothing less.
Don't fret over SD cards when you have a true need for them, you will know enough PropForth to make them work. I find the multi-COG and multi-Propeller features much more fun to play with. The I/O channels are really cool. The high speed channel interfaces back to a host PC or between Propellers are fascinating...all,this can be learned and played with without needing an SD card or a bigger EEPROM. Just cut and paste and saveforth to put your modified development kernel back into the lower 32k of EEPROM so you don't loose your work across resets.
Really, honest, I hardly ever do anything with the EEPROM or SD kernel. The SD I use if I'm building a Spinnerett image and that's about it.
Now, enough debating, comparing, dissecting, go load up PropForth and start playing!! If you want to focus on Tachyon instead, I would give ou the same advice. Try too many and you just get the words confused and get frustrated...that never helps learning.
Calm down Loopy, we miss a lot of body and tonal language in these posts, I am trying to help you and so I am employing the equivalent of hyperbole in my reasonings so that even if you only catch the fringes of what I am saying, it should help you to see what I am saying. It's not about a rebuttal or having a go at you, not at all. If you were sitting in a workshop that I was conducting you would have to keep up with it and do things the same way. There is plenty of time after that to ask questions and do your own thing.
My point about the ancient SD card is very clear because it may be well used and suffering from wear failure or at least slow to respond. I have seen this even with old 256M cards, they just don't respond correctly. If I don't throw them in the bin then I am simply wasting my own time but I know which is more valuable. SD cards do not benefit at all from FAT16, they only suffer it. Forth does not require a FS to be able to store information on the card. I would gladly use a 2GB card to store less than 1M byte. You are already using eight 32-bit RISC CPUs to do very little most of the time. Would you dig that old 8751 out of the junk box and use that instead?
@Peter
Maybe you should try learning a bit of linguistics - text, sub-text, and content.
You start out presumptive and berating, then turn argumentative and close with trying to tell me you are doing me a favor.
All I see is a fiercely competitive individual that wants to assert that he has the best and fastest Forth for the Propeller. If you do indeed have that, you undermine your credibility; if you don't, I have PropForth to use.
I am finished with TachyonForth. And I've decide to forget using SDcards until I like the way they are used.
@All
I am just going to use PropForth for 64KEEPROM until I have a better grasp of what Forth does on the Propeller. I am using V5.3, just because I loaded it this past week. But I am not going to chase an endless parade of upgrades and hang my hopes on promises of new features to come.
I could say a lot more. In fact, I did say a lot more, but that posting disappeared -- maybe blocked by a moderator or just dropped by the internet karma patrol.
We now have 3 Forth choices on the Propeller - pfth, PropForth, and Tachyon Forth. That bodes well for the new user that wants an easy entry to the Propeller. But be wary of all the hype that some of these rather ambitious Forth developers are trying to put over. Don't feel guilty for going slow and getting a good basis in Forth. Don't feel guilty for studying the widely accepted ANS Forth 94 in GForth.
@Peter
Maybe you should try learning a bit of linguistics - text, sub-text, and content.
You start out presumptive and berating, then turn argumentative and close with trying to tell me you are doing me a favor.
All I see is a fiercely competitive individual that wants to assert that he has the best and fastest Forth for the Propeller. If you do indeed have that, you undermine your credibility; if you don't, I have PropForth to use.
I am finished with TachyonForth. And I've decide to forget using SDcards until I like the way they are used.
@All
I am just going to use PropForth for 64KEEPROM until I have a better grasp of what Forth does on the Propeller. I am using V5.3, just because I loaded it this past week. But I am not going to chase an endless parade of upgrades and hang my hopes on promises of new features to come.
I could say a lot more. In fact, I did say a lot more, but that posting disappeared -- maybe blocked by a moderator or just dropped by the internet karma patrol.
We now have 3 Forth choices on the Propeller - pfth, PropForth, and Tachyon Forth. That bodes well for the new user that wants an easy entry to the Propeller. But be wary of all the hype that some of these rather ambitious Forth developers are trying to put over. Don't feel guilty for going slow and getting a good basis in Forth. Don't feel guilty for studying the widely accepted ANS Forth 94 in GForth.
Do what you feel is best for you.
If you recall my first post in this thread it was to correct a few complaints and "judgements" you had made and were making in your great wisdom. Do what you feel is best FOR YOU, I have not pushed anything on you that has not been freely given and taken, even if it amounts to a labor of open-source love, it has been given freely. If you choose to ignore or kick away any gems that have been dropped at your feet, then do what you feel is best for you.
@Peter
I try not to be coy with speech or my writing. And at times, a bit of banter and bluster is fun for all.
HOWEVER...
What you see as complaints and judgements were and still are intended to be the simple observations of a newcomer. Up until this got to be too much, I have tried to be not judgemental and factual. And I have not intended to be complaining, but was appealing to others to provide insights into what I didn't understand.t
And, I have avoid trying to make any demands of Tachyon out of fairness of the fact that I decide to try PropForth.
Enough already.
I've gotten told off by you just a bit too much. For every Parallax Forum member logged on, there happen to be more than ten others reading these pages at any given time - maybe more.
All along, the theme has been quite simple. Forth is a wonderful language for Propeller beginners. Try what you think is best for you. And I can only be candid about what works for me.
Nearly all my entries get written, thought about, revised, and rewritten to try to moderate the tone. Only about 25% of what I start out with gets posted as I find that when I try for 100% of what I write, I sound rather stupid. Nonetheless, you feel that even the 25% is unworthy.
OK, I'm gonna try this peacemaker role one more time and then I'm gonna start knocking some heads together!!
Peter, Loopy, you two need to head off to a virtual bar, have a couple beers and draw some ideas out on cocktail napkins. Settle it like engineers, for crying out loud!
Loopy, your questions, perspectives and investigations are helpful. Lots of people are trying to help you with a monumental task - learning 3 Forths at once! Some of your comparisons and statements have been wrong and possibly taken the wrong way by folks. Before you make a statement, such as "X appears to be only able to do Y.", please ask, it may just be an option, a preference or a work in progress. The Hex preference of Tachyon comes to mind. As Peter pointed out in civil terms, Tachyon has no Preference, Peter does, so he has the default as Hex but it is fully capable of doing any base you want, for all practical purposes. Any Forth can and will.
I'm going to defend Peter for a bit. He wrote Tachyon for his needs based on what I understand to be considerable experience in using Forths in various production and commercial environments. His experience, wants and needs are rolled into Tachyon. It's not not ANS standard Forth, most Forths aren't, most are pretty much like Tachyon in that they embody the needs and experiences of the designer/author. He's been developer, tech writer, help desk and defender of Tachyon. Yes, defender is a role that's needed so misunderstandings aren't propagated and making folks miss important features of Tachyon. It may not be for everyone, but in a short time, it has become an impressive implementation with some very creative and thoughful solutions to problems. It's also being developed and used in real applications. I want someone contributing to the Open Source community that has an ego and passion for their code. I'd rather get feedback as to why something can, can't or shouldn't be done rather than "yeah, whatever, dude, that's how it is."
As for the SD and Fat32 load leveling and unusual wear and tear, I just don't the point behind all that. I don't think the SD is that important to learning Tachyon or PropForth at this time. Until you have an application, I wouldn't be too concerned about the SD cards internal load balancing algorithms and how non-FAT32 support will impact the lifetime of the card. Seriously? I need that whole thing explained to me over a beer or two. If I had a need for a high lifetime SD application, I would probably set up a test to cycle through a card and see how long it takes before it fails compare that to a similar application using a FAT32 card...and then you need to do that across multiple cardds since you don't know if one failure is just a single card or indicative of the brand or the whole Fat32 thing...I do not have enough years left to worry about that for an SD card. That discussion seems to have opened up the can of worms and caused the tempers and egos to flair.
After all this debate and distraction, I'm going back to your original questions that started this thread.
i decided to start a new thread on PropForth as we wandered away from the title of the previous one.
At this point, I think I am ready to use an SDcard with PropForth, but I can't quite sort out how I want to go about this.
The Propeller Proto Board has a 64K EEPROM and I began with that. But it just seems to me that the images provided are either in support of a 32K EEPROM, a 64K EEPROM, or any EEPROM with an SDcard reader.
That 'any EEPROM' is the bugaboo. Am I right to guess that the SDcard image for PropForth will only used 32K of EEPROM even though more may be on board? The documentation doesn't really discuss this issue.
OR, is there an image that uses larger EEPROMs and the SDcard as two alternatives for storage? (This actually makes no sense to me personally, but I need to clarify for anyone reading this thread).
I still don't understand if the 'extended EEPROM' image is merely for 64K when 'saveforth' is used, or if it actually can handle bigger and bigger dictionaries. You might say that I am confused if the dictionary always resides in the Propeller's Hub ram or if it grows into other spaces or the whole dictionary just resides in the EEPROM or the SDcard in those models.
I hope I am making sense. I try to look at the code, but it is not helpful at this point.
At this time, PropForth's active dictionary can never exceed the 32K RAM boundary. Saveforth does one thing - it copies the running PropForth image (actually, just the dictionary, I believe) from RAM to the lower part of EEPROM. That's it! If you create a new word, DON'T do saveforth and reset the propeller, your new word is gone. Ifmyoumcreate a new word, do saveforth, reset the propeller, your word is there because it became a part of the kernel that saveforth copied to the lower 32k of EEPROM. That's it, all it does. It only ever uses the lower 32k of EEPROM and will work on ANY propeller with an EEPROM. You develop your application by cutting/pasting or typing new word definitions into the terminal. Whenever you want to save your work to EEPROM, you do saveforth. If you messed something up, you reload form the PC or reset and forget back to a marker word you created and star moving forward again. Once you have your application done, you have your modified kernel in EEPROM and you have a file or files of word definitions that you can cut/paste to recreate it. Works great for small applications that fit in 32k and don't need any persistent data.
As I stated earlier, you can learn 95% of PropForth and Tachyon without ever using an extended EEPROM or SD card. When you get to that bridge cross it but you don't need to race a head just to cross that bridge because it's there! Small bites. Learn DEEP and you'll be better prepared for when you need to start learning WIDE. When you need to use the EEPROM file system or put log files on an SD card, things will click and it will make more sense. (trust me, been there and done that).
I could probably play for years with PropForth and its multi-COG and multi-Prop features. It's really cool to hook another Propeller up via 6 pins and then boot it and load PRopForth from the master to the slave and then have 7 more COGs to play with 6 pins lost and you have a two propeller configuration that has 13 free usable COGs running the PropForth interpreter and the second Prop has 28 free pins to play with while the original Prop has 22 free pins.....that is cool! Did I need an SD card or extended EEPROM to do it....NOPE!
Go PLAY!!!! Forth isn't formal and disciplined, it free and fun!! If you want tit to do something in a different way, go change it, after a while you'll be wanting to, anyway!! I thought it was pretty neat how Peter added PUB and PRI as compiling words to make it more Spinnish. That's flexible, that's cool, that's Forth!!
When I learned Forth back in the late 80's, I used a commercial version with all the bells and whistles(CSI Forth for Atari ST). Why? Because it's easier. I would recommend the same today. All the personal Forths are just that - personal and quirky. Consider them advanced training.
Get a free eval version of Swift Forth for windows. It has everything included, such as good documentation and examples. It's ANS compliant as well.
What you are attempting - learning three different Forth variants in parallel is ambitious at best and to me is very confusing. I'm trying something similar with PropForth (I have some experience), Tachyon and Factor ( which is a forth like PC language - Forth on steroids). It is difficult .
I just read post 44. Except for the religion part, this is spot on. Upper EEPROM is only for EEPROM file system, if you have a few configuration value to store someplace that survives between power cycles.
But ,the SD stuff is too cool to miss. I made a new instruction,and pointed to it in a separate thread.
When I learned Forth back in the late 80's, I used a commercial version with all the bells and whistles(CSI Forth for Atari ST). Why? Because it's easier. I would recommend the same today. All the personal Forths are just that - personal and quirky. Consider them advanced training.
Get a free eval version of Swift Forth for windows. It has everything included, such as good documentation and examples. It's ANS compliant as well.
I agree with rod, as far as learning forth on a PC. However, to USE forth on the prop, you need to decide, do I want to bit bang (use Tachyon) do i want to use a micro controller as part of a distributed parallel multi platform system (use propforth), do I want to write my own (write your own). If you want to a "pro" version, you better have deep pockets. And be prepared that the "pro" versions are also personal and quirky, just more expensive. Ultimately all version are made by individuals.
And don't bother with the free eval version or a free trial version unless you plan to buy the real version.
Loopy: It has already been said in a variety of ways, but you don't have to know everything to do something. After a cursory reading of the first five or so words of Forth, I departed from the text and proceeded to create simple things, and then built up one or two words at a time from there...kind of like a kid might do. Perhaps your background explains some of your resistance to this approach. Nevertheless, it seems to be what is needed here. Hardly matters whose Forth it is. Just stick with your experimentation until you can do some cool things. Then read the rest of the text at your leisure - on the train or something.
I apologize in advance for yet another long posting, but it is for the good of Forth on the Propeller and all that want it to be.
In the for what it's worth department....
I have been curious about the three, or four different versions of Forth. I've never ever said that I am setting out to know everything. Others have presumed that, and it has been a source of friction.
I do admit that I have printed out lists of the 'words' listings in an effort to compare what is going on. For some of you that may seem a huge project, but I am used to working through vocabulary list as an English teacher. It just seemed natural to me to use this way to get some overview of which 'Forth Words' were commonly in use.
But I did soon learn the reality is that the dictionary of any Forth has a great deal (maybe 80% of the words) that a new learner is better off NOT trying to de-cypher. Just keep working with "Starting Forth" and if you are using PropForth - go through the .htm tutorial. If you are working with Tachyon, use the introductory thread, and ask Peter.
As far as playing with Forth and just picking it up.....
I tried that in the past and my interest dropped out. I got the impression it was not much more than a glorified RPN calculator (which is very NOT TRUE).
So this time around, I really have set out to know how to do all the micro-controller basics: meaning numerical calculation, bit manipulation, address pointers, construction and use of arrays, and more. In the past, I made the very serious mistake of thinking "Starting Forth" was a kiddie book (it just looks a bit like one, it is a serious introduction to computing in a fun loving format).
So what am I doing and is it working for me?
My own learning approach has been to use contrast between different solutions to discover what is important to me. Other have frowned upon this.
Admittedly at first I thought that working diligently through ANS Forth 94 was a good thing, but the corpus of information is rather large for a beginner and the tome is written in a style that is rather dry.
From there I shifted to "Starting Forth" by Leo Brodie as everyone who is anyone in Forth says this is the best book.
I continue to study it while actually doing things on the Propeller and am convinced this is necessary (Be careful -- reading Brodie's later book, "Thinking Forth" before you have mastered "Starting Forth" will make no sense - I tried some years ago).
But I did find that there are really three versions available of "Starting Forth" and feel strongly about getting the right one. The first edition that was based on Forth 79, the second edition that was based on Forth 83, and the current on line 'defacto' third edition that is based on ANS Forth.
So I figured to forget about Forth 79 or Forth 83 and to just focus on ANS Forth 94 and.... whatever has been provided for Forth on Propeller.
You now have the "Starting Forth Lexicon" PDF as a way to survey if you need to read the book and what chapters are hazy to you. Hopefully this will be good for everyone. It has been good for me personally. And I am revising that list as there are a few words that were missed and a mention of GForth's INCLUDED that is a bit wrong.
And since I am studying "Starting Forth" in ANS Forth 94, it was quite easy to load GForth as a study environment without having to boot up the Propeller Proto Board or Propeller Demo Board. It seems many feel this is a sin of betrayal for I am using a 'big bloated Forth', not a lean mean micro-controller version.
In conjunction with that I have loaded TachyonForth and PropForth just out of curiosity and in hopes of acquiring some insight into what more I needed to know to run Forth on a Propeller. I made a few observations and suddenly people are accusing me of trying to be a Forth Guru. Why would a Forth Guru title this thread "Poking along as a beginner to Forth"?
I NEVER meant for my postings to be judgemental and complaining. I do admit to being confused at times. Somehow we got off into the weeds where such assertions were made, along with a lot of other stuff of dubious merit, and just not fun. I have just been trying to explore and share one possible path for a new user of Forth to move rather easily into Forth on the Propeller.
I have learned a lot. I am enjoying Forth. And I am also reading from three PDFs on ANS Forth by recent writers. But I made not mention of them as I did not want to confuse other beginners with too many references. Not all of this reading is appropriate for Forth on a Propeller, but I wanted to learn the language in today's setting of 2012 - not just learn to use one or a few versions of Forth on the Propeller.
From the beginning, I was under the misconception that I required more than 32K of EEPROM to save my work in PropForth. I have said several times that I did NOT fully understand 'saveforth', but it seemed to work. That I suppose was a lot of the beginning of confusion. I thought that using the SDcard would clarify how 'saveforth' worked. And you all discovered that I have one particular personal preference - I'd like to use SDcards with FAT16 or FAT32 in accordance with SDcard Associations conventional formating (it is not about sector size, it is about a lot of other things).
I do understand that everyone just wants to exploit the SDcard as an SPI SRAM and not bother with FAT16/32 at this time and for the sake of more speed. And it just may eventually work as a way to extend the LMM (Large Memory Model) beyond the 32K of Hub RAM. At least the LMM according to Pacito's proposed specification is trying to do that. And this would be a wonderful thing for Forth on the Propeller as bigger fast dictionaries would be available.
Back to what I was doing...........
In the interim, I took a quick look at Tachyon, and mentioned it came up in Hex. I even said HEX was more handy for most of us, Peter took it as if I thought that HEX was somewhat inferior to DECIMAL. This is really a tempest in a teapot if you look back at what I said and how it was interpreted.
I have tried to welcome and include Peter's comments, but there is a limit to how much I feel that I should allow another person to cast me in the light of a fool and lecture me. So all this came to pass. (BTW, I do try to cut allowances for the Aussie persona. They are just a very competitive, energetic, aggressive bunch of blokes in anything they set their mind to.)
I think most of those that have been on this Forum for a while know that I feel "the more, the merrier" and that we can forget and move on. These mis-communications happen from time to time. But they aren't the end of the world.
I am making progress in Forth, and hope to welcome others that want to do so.
And it is indeed 'progress, not perfection' that I am after. So let's all just move on and have fun.
Comments
Remember, this was when 8086 was new. Read that as "Forth doesn't have much room without more storage"
Remember the sd AS USED INTERNALLY IN PROPFORTH is internal and not removed ever, unless it goes bad, in which case its handy we used a socket, like the EEMPROM.
IF YOU WANT FAT, YOU CAN implement it and use it as an extension, or as part of a custom kernel (which we will get to later, custom kernels are totally easy in v5.3 compared to ealier releases).
BUT, this is Sal's tool, so Sal's purposes, and FAT support for th SD is not in the default kernel, his choise. Its his decision to make, and you decision to change, but you can't tell him what to do with his on tool, you'll break his design for the thinng in his basement that doesn't work that way.
Again, you can add SD, and then we can talk about how slow it got and where all your resources went. We were going to save this conversation till more folks caught up, but we can start now if we must. I advise against starting this topic too soon.
You got this backwards.
SEe ANSII escape sequnces for PAGE - but we don't use the arcde page, I used CLS because thats what we used that day.
http://propforth.googlecode.com/files/ANSI%20Escape%20Sequences20120704-1652.f
See and Decompile were always part of propforth, they just got pushed off the table by newer work, Sal is going to bring those forward now that he knows somebody still wants them. (the advise is that you only use them to get started, after a certain level you don't ned them anymore, my brain is not so big yet...)
OCTAL is 0 thru 7, just as we roll over after 9 in base ten. But we don't need it in the kernel, since we are 32 bit.
This is the key, Implementing extensions gives experience, practice is how we gain skillz anything.
This is going to sound like my fourth grade English teacher, that the kernal is the STARTING point and we all must find and load our own DEVELOPMENT EXTENSIONS during development to fit our purposes. Start with the ANSII escape defs to see how loading extensions impacts size and functionality. Eventually, we may come to a consensus on an "Ideal" set of primary extensions, and an additional libbriary of secondary extesinsions, but for nowSal and I can't guess what these will be. You(se) are the guinea pig(s)
But consider, we and making huge progress, which seems to be increasing in velocity.
As it is, I really don't want to waste a 2Gbyte card for uses as a 32Mbyte storage device. I will locate something much smaller and save the 2G for the Spinnerette or my forthcomng Cubieboard.
Yes, I followed the SD tutorial the first time out and it did not work. I have worked through all the tutorials at number 1 level and number 2 level with success. But the SD card didn't intialize.
I really wanted to deploy PropForth on the Propeller Demo Board because it has so much more hardware available than the Propeller Proto Board. I started to set up a microSDcard of 2Gbytes, but it makes little sense to have so much go to waste. Failure could have been due to the lack of an added capacitor as the SDcards are power hogs. And the bigger they are, the more power hungry.
Now that I have a better understanding of how to solder up an SDcard, I am going to switch to a 16Mcard that I have and dedicate that to PropForth use. Above you say that the usual switching back and forth of use with a PC will eventually overwrite areas that it doesn't know are already in use by PropForth.
So it seems that PropForth just uses the SDcard as a simple SPI RAM without any file system. I give up pondering the wear level issues. I'll just have to one day try to read the .spin file and see what it does.
I guess you have finally made it clear that once the SDcard is put to use with PropForth, it is not going to be much use for anything else. It seems rather silly to dedicate a microSDcard holder as well, so this is a whole new configuration.
First time out, it failed to intialize - Error 166, from what I've read is the Propeller can't see the SDcard to intialize for some reason - likely a wiring mistake. But I also had 4 warnings in the compiler that I had not seen in the 32k image or the 64k image.
So now I will get a couple of 4x 10Kohm single in line resistors for pull ups (the Vdd is in the middle of nine pins and I can bend up one tab to avoid Vss). IF THIS doesn't work out I can replace the 32K EEPROM with 64K easily enough. I just can't get anything larger that 64K in an SPI EEPROM at the local stores.
As it is now, the whole effort on my part is slowing down as it becomes obvious that I should read more of "Starting Forth" and work completely thorugh the problems at the end of each chapter to really have a good grasp of future Forth projects. A lot of time for the past week or so has been spent in just getting new versions of PropForth and TachyonForth loaded into various boards, but not much has been acquired in basic knowledge. It helped to list the Starting Forth Lexicon as I see where I don't quite understand certain chapters.
Starting Forth - Chapter 3 is about the least applicable to PropForth or TachyonForth as it discusses 'The Editor', which is the traditinal Block system and the alternative that uses INCLUDE for a resident file system. Neither of you are using the Block System or the Resident File System. I guess the SDcard is just an expanded memory with a modified 32K image retained therein while the original remains on the EEPROM with a boot.f added to divert the boot process.
In all honesty, I am trying to acquire Forth as PropForth and Tachyon do it. I have been working through lists of the dictionaries, but they are rather long and many of the words are unclear to me or are unnecessary to know for a novice.
So, I rely on Starting Forth Lexicon for a key short list and the GForth tutorial for a general overview of what I might use or want to create. I learn a lot through GForth that is generally transferable and I don't have to carry a Propeller board with me to study it. I am not trying to force compliance with ANS Forth. I just think that the closer you are to ANS Forth, the easier it is for a wide group of users to learn on their own.
I am NOT saying you should or you must provide anything. If I feel strongly about something, I'll develop my own added words in my own way. Having to fend off such presumptions is tiring and counter-productive. I am sure everyone feels that they have wasted a bit of their energy on such debate.
In other words if I say 'should' or 'must', I mean 'should' or 'must'. If I don't use such terms, 'should' or 'must' is NOT implied. I merely am making observations about what is where.
While I don't know if it is ever possible, I have some hope that I can do a comparative lexicon. But if it is going to upset everyone, I just keep the work for myself. I certainly need one in order to not be confused.
I only mention this one point to highlight that the greatest impediment to learning can't always be blamed on the tools or the documentation etc. It can just simply be your own mindset. Step back and reevaluate, be practical, not picky, then dive in.
my input - just user 2G or 4Gig, whatever is most common in your desk. these are cheap. you will probably NOT be able to wear it out, but you WILL be able to fill it up. Sal's design is to support multiple high speed data streams, LOGGING, and preprocessing. The prototypes are very promising, you will love it.
plan on 2-4 gig sd as standard, and solder a socket if possible. save at least one "real" sd slot for the final project to be announced later.
Thanks Peter for your clear and concise support.
I'll just skip the SDcard thing until you guys figure out what you are doing. It seems a huge waste of space for backing up 32K of ram. Even 16mbytes seems a huge waste of space for backing up 32k of ram.
And just maybe Peter, this isn't a Tachyon support issue. Why do I have to be berated by you?
It certain isn't about $2 in cost.
If 2GB SDcards are junk (which they are not to me), 16MB SDcards are even more junk. Why NOT use the junkiest junk if I am having trouble, rather than potentially damage useful and better components?
I happen to have other uses for the 2GB. Besides, the 2GB that I tried did NOT work, I have reformated two of them and confirmed that they are good to go for other thing. They were not formated and that may have had something to do with it.
Prof Braino hasn't really explained 'saveforth' methodology in any detail to me. It seems to work on a 64K EEPROM fine. I guess I should just stay with that as I distrust the SDcard setup.
I have no reason to collect 2Gb of raw data that is not in a FAT16 format. I'd want to transfer that file to a desktop for further work. I certain am not hanging on to every promise of a new feature just around the corner. I just wanted to get started with Forth in a reasonable fashion.
This has all gotten rather absurd.
I have wasted another hour in rebuttal to Peter when I am just trying to move leisurely along with learning Forth in PropForth.
Some drivers do have a problem with cards greater than 4G because these are SDHC cards, and not just SD. I know that Kye's driver had a problem with SDHC, but I think he has fixed that. Even most 2G SD cards available today use the SDHC protocol.
I think using GForth is a great way to learn. As you said, it doesn't tie you down to running just on the Prop.
And while I expected to get further on in learning Forth, I feel I have joined a debating society. I suppose some of it is my own doing, but not all.
Nobody wants to admit that the SD Association has hardware specific to sector size and FAT tables to provide wear leveling as they just want to prove who has the fastest PropForth.
There are SRAM SPI chips that can accomodate the speed if they want only that.
Calm down Loopy, we miss a lot of body and tonal language in these posts, I am trying to help you and so I am employing the equivalent of hyperbole in my reasonings so that even if you only catch the fringes of what I am saying, it should help you to see what I am saying. It's not about a rebuttal or having a go at you, not at all. If you were sitting in a workshop that I was conducting you would have to keep up with it and do things the same way. There is plenty of time after that to ask questions and do your own thing.
My point about the ancient SD card is very clear because it may be well used and suffering from wear failure or at least slow to respond. I have seen this even with old 256M cards, they just don't respond correctly. If I don't throw them in the bin then I am simply wasting my own time but I know which is more valuable. SD cards do not benefit at all from FAT16, they only suffer it. Forth does not require a FS to be able to store information on the card. I would gladly use a 2GB card to store less than 1M byte. You are already using eight 32-bit RISC CPUs to do very little most of the time. Would you dig that old 8751 out of the junk box and use that instead?
These SD cards are getting cheap.
What you are attempting - learning three different Forth variants in parallel is ambitious at best and to me is very confusing. I'm trying something similar with PropForth (I have some experience), Tachyon and Factor ( which is a forth like PC language - Forth on steroids). It is difficult and I'm to a point where I need to make some decisions and clean off the plate a little bit and concentrate on just one...probably PropForth at this time since I have the most experience there...
AND 5.3 RELEASE IS JUST MINUTES AWAY!!!!!! :0)
Perspective Moment: Pardon me if I stray for a bit.....what if you look at C as a science, like chemistry and you look at Forth as a collection of religions having similar beliefs, like Christianity. C has a fixed set of elemental units and rules in how they can go together that really can't be changed. With this collection, you can put together all kinds of new things but you usually can't get more kinds of elemental pieces and you can't change the rules of how they get together. With Forth, you have a common set of fundamental beliefs that all Forth branches share but each branch has different ways to explain or express the belief. All Christian religions have God, Jesus, Christmas, Easter, death and resurrection,etc. you can look at the core beliefs of a religion and say it either looks pretty Christian or it doesn't. When you walk into a service on Sunday, you may feel out of place for a while but you'll get the general sense of things pretty soon. All Forths have a basic set of features, stack orientation, compiler words, extensibility, threaded, interpreted dictionary structure and so on. You can look at the core of the language and determine it is Forth-like. Wen you first sit down to use it the first time, it may throw you but you understand the basic mechanics and will learn it and adapt it to your application.
With that said, from a post a while back, I think you still have a misunderstanding of saveforth and what benefits the file systems offer to you and your application.
From what I understand of the code, saveforth simply copies the dictionary portion of your current executing Forth image from RAM to EEPROM. (This statement just made we think of an experiment I want to try.) that's really all it does. If you create a new word, DON'T do saveforth and reset the propeller, your new word is gone. Ifmyoumcreate a new word, do saveforth, reset the propeller, your word is there because it became a part of the kernel that saveforth copied to the lower 32k of EEPROM. That's it, all it does. It only ever uses the lower 32k of EEPROM and will work on ANY propeller with an EEPROM. You develop your application by cutting/pasting or typing new word definitions into the terminal. Whenever you want to save your work to EEPROM, you do saveforth. If you messed something up, you reload form the PC or reset and forget back to a marker word you created and star moving forward again. Once you hav eyour application done, you have your modified kernel in EEPROM and you have a file or files of word definitions that you can cut/paste to recreate it. Works great for small applications that fit in 32k and don't need any persistent data.
You can learn 95% of PropForth without ever going beyond a 32k EEPROM and cutting and pasting your way to a working application. Forget the upper EEPROM and the SD card and you have bunches to learn!!
When/if you have a larger application or need some data files, logging or other persistent data, you cango to the EEPROM kernel or the ad kernel. Both of these extensions to PropForth offer you the same features the difference is the size of the files pace area (EEPROM is typically just the upper 32k of EEPROM, SD support gives you the size of your SD card. There could be SDHC issues but I've never been there yet.
With a file system, instead of adding words to the kernel and doing a saveforth, you keep,the kernel as it was loaded and then though the Floyd and load (I think), you can load woes into the dictionary, run that part of your application, forget back to a marker, load a different part of the application, run it, forget it, etc. for as complicated an applications you can manage. Forth source files are copied out into the file system (don't worry about the details until you NEED it - you don't need to know to learn PropForth). Take small bites. You don't need to be able to write the history of Forth and debate comparative Forth features while you are learning your first couple of Forth implementations - it will drive you to madness!!!
The file systems only extend memory in the sense you can store source code in them and can load source form SD or EEPROM instead of typing it in. Both share the boot.fs concept. When booting, if either the EEPROM or SD kernel finds a boot.fs file in the file system, it will start executing the words in it before it goes to the interpreter loop. Nothing more, nothing less.
Don't fret over SD cards when you have a true need for them, you will know enough PropForth to make them work. I find the multi-COG and multi-Propeller features much more fun to play with. The I/O channels are really cool. The high speed channel interfaces back to a host PC or between Propellers are fascinating...all,this can be learned and played with without needing an SD card or a bigger EEPROM. Just cut and paste and saveforth to put your modified development kernel back into the lower 32k of EEPROM so you don't loose your work across resets.
Really, honest, I hardly ever do anything with the EEPROM or SD kernel. The SD I use if I'm building a Spinnerett image and that's about it.
Now, enough debating, comparing, dissecting, go load up PropForth and start playing!! If you want to focus on Tachyon instead, I would give ou the same advice. Try too many and you just get the words confused and get frustrated...that never helps learning.
@Peter
Maybe you should try learning a bit of linguistics - text, sub-text, and content.
You start out presumptive and berating, then turn argumentative and close with trying to tell me you are doing me a favor.
All I see is a fiercely competitive individual that wants to assert that he has the best and fastest Forth for the Propeller. If you do indeed have that, you undermine your credibility; if you don't, I have PropForth to use.
I am finished with TachyonForth. And I've decide to forget using SDcards until I like the way they are used.
@All
I am just going to use PropForth for 64KEEPROM until I have a better grasp of what Forth does on the Propeller. I am using V5.3, just because I loaded it this past week. But I am not going to chase an endless parade of upgrades and hang my hopes on promises of new features to come.
I could say a lot more. In fact, I did say a lot more, but that posting disappeared -- maybe blocked by a moderator or just dropped by the internet karma patrol.
We now have 3 Forth choices on the Propeller - pfth, PropForth, and Tachyon Forth. That bodes well for the new user that wants an easy entry to the Propeller. But be wary of all the hype that some of these rather ambitious Forth developers are trying to put over. Don't feel guilty for going slow and getting a good basis in Forth. Don't feel guilty for studying the widely accepted ANS Forth 94 in GForth.
Do what you feel is best for you.
If you recall my first post in this thread it was to correct a few complaints and "judgements" you had made and were making in your great wisdom. Do what you feel is best FOR YOU, I have not pushed anything on you that has not been freely given and taken, even if it amounts to a labor of open-source love, it has been given freely. If you choose to ignore or kick away any gems that have been dropped at your feet, then do what you feel is best for you.
I try not to be coy with speech or my writing. And at times, a bit of banter and bluster is fun for all.
HOWEVER...
What you see as complaints and judgements were and still are intended to be the simple observations of a newcomer. Up until this got to be too much, I have tried to be not judgemental and factual. And I have not intended to be complaining, but was appealing to others to provide insights into what I didn't understand.t
And, I have avoid trying to make any demands of Tachyon out of fairness of the fact that I decide to try PropForth.
Enough already.
I've gotten told off by you just a bit too much. For every Parallax Forum member logged on, there happen to be more than ten others reading these pages at any given time - maybe more.
All along, the theme has been quite simple. Forth is a wonderful language for Propeller beginners. Try what you think is best for you. And I can only be candid about what works for me.
Nearly all my entries get written, thought about, revised, and rewritten to try to moderate the tone. Only about 25% of what I start out with gets posted as I find that when I try for 100% of what I write, I sound rather stupid. Nonetheless, you feel that even the 25% is unworthy.
Peter, Loopy, you two need to head off to a virtual bar, have a couple beers and draw some ideas out on cocktail napkins. Settle it like engineers, for crying out loud!
Loopy, your questions, perspectives and investigations are helpful. Lots of people are trying to help you with a monumental task - learning 3 Forths at once! Some of your comparisons and statements have been wrong and possibly taken the wrong way by folks. Before you make a statement, such as "X appears to be only able to do Y.", please ask, it may just be an option, a preference or a work in progress. The Hex preference of Tachyon comes to mind. As Peter pointed out in civil terms, Tachyon has no Preference, Peter does, so he has the default as Hex but it is fully capable of doing any base you want, for all practical purposes. Any Forth can and will.
I'm going to defend Peter for a bit. He wrote Tachyon for his needs based on what I understand to be considerable experience in using Forths in various production and commercial environments. His experience, wants and needs are rolled into Tachyon. It's not not ANS standard Forth, most Forths aren't, most are pretty much like Tachyon in that they embody the needs and experiences of the designer/author. He's been developer, tech writer, help desk and defender of Tachyon. Yes, defender is a role that's needed so misunderstandings aren't propagated and making folks miss important features of Tachyon. It may not be for everyone, but in a short time, it has become an impressive implementation with some very creative and thoughful solutions to problems. It's also being developed and used in real applications. I want someone contributing to the Open Source community that has an ego and passion for their code. I'd rather get feedback as to why something can, can't or shouldn't be done rather than "yeah, whatever, dude, that's how it is."
As for the SD and Fat32 load leveling and unusual wear and tear, I just don't the point behind all that. I don't think the SD is that important to learning Tachyon or PropForth at this time. Until you have an application, I wouldn't be too concerned about the SD cards internal load balancing algorithms and how non-FAT32 support will impact the lifetime of the card. Seriously? I need that whole thing explained to me over a beer or two. If I had a need for a high lifetime SD application, I would probably set up a test to cycle through a card and see how long it takes before it fails compare that to a similar application using a FAT32 card...and then you need to do that across multiple cardds since you don't know if one failure is just a single card or indicative of the brand or the whole Fat32 thing...I do not have enough years left to worry about that for an SD card. That discussion seems to have opened up the can of worms and caused the tempers and egos to flair.
After all this debate and distraction, I'm going back to your original questions that started this thread.
At this time, PropForth's active dictionary can never exceed the 32K RAM boundary. Saveforth does one thing - it copies the running PropForth image (actually, just the dictionary, I believe) from RAM to the lower part of EEPROM. That's it! If you create a new word, DON'T do saveforth and reset the propeller, your new word is gone. Ifmyoumcreate a new word, do saveforth, reset the propeller, your word is there because it became a part of the kernel that saveforth copied to the lower 32k of EEPROM. That's it, all it does. It only ever uses the lower 32k of EEPROM and will work on ANY propeller with an EEPROM. You develop your application by cutting/pasting or typing new word definitions into the terminal. Whenever you want to save your work to EEPROM, you do saveforth. If you messed something up, you reload form the PC or reset and forget back to a marker word you created and star moving forward again. Once you have your application done, you have your modified kernel in EEPROM and you have a file or files of word definitions that you can cut/paste to recreate it. Works great for small applications that fit in 32k and don't need any persistent data.
As I stated earlier, you can learn 95% of PropForth and Tachyon without ever using an extended EEPROM or SD card. When you get to that bridge cross it but you don't need to race a head just to cross that bridge because it's there! Small bites. Learn DEEP and you'll be better prepared for when you need to start learning WIDE. When you need to use the EEPROM file system or put log files on an SD card, things will click and it will make more sense. (trust me, been there and done that).
I could probably play for years with PropForth and its multi-COG and multi-Prop features. It's really cool to hook another Propeller up via 6 pins and then boot it and load PRopForth from the master to the slave and then have 7 more COGs to play with 6 pins lost and you have a two propeller configuration that has 13 free usable COGs running the PropForth interpreter and the second Prop has 28 free pins to play with while the original Prop has 22 free pins.....that is cool! Did I need an SD card or extended EEPROM to do it....NOPE!
Go PLAY!!!! Forth isn't formal and disciplined, it free and fun!! If you want tit to do something in a different way, go change it, after a while you'll be wanting to, anyway!! I thought it was pretty neat how Peter added PUB and PRI as compiling words to make it more Spinnish. That's flexible, that's cool, that's Forth!!
Get a free eval version of Swift Forth for windows. It has everything included, such as good documentation and examples. It's ANS compliant as well.
I just read post 44. Except for the religion part, this is spot on. Upper EEPROM is only for EEPROM file system, if you have a few configuration value to store someplace that survives between power cycles.
But ,the SD stuff is too cool to miss. I made a new instruction,and pointed to it in a separate thread.
I agree with rod, as far as learning forth on a PC. However, to USE forth on the prop, you need to decide, do I want to bit bang (use Tachyon) do i want to use a micro controller as part of a distributed parallel multi platform system (use propforth), do I want to write my own (write your own). If you want to a "pro" version, you better have deep pockets. And be prepared that the "pro" versions are also personal and quirky, just more expensive. Ultimately all version are made by individuals.
And don't bother with the free eval version or a free trial version unless you plan to buy the real version.
In the for what it's worth department....
I have been curious about the three, or four different versions of Forth. I've never ever said that I am setting out to know everything. Others have presumed that, and it has been a source of friction.
I do admit that I have printed out lists of the 'words' listings in an effort to compare what is going on. For some of you that may seem a huge project, but I am used to working through vocabulary list as an English teacher. It just seemed natural to me to use this way to get some overview of which 'Forth Words' were commonly in use.
But I did soon learn the reality is that the dictionary of any Forth has a great deal (maybe 80% of the words) that a new learner is better off NOT trying to de-cypher. Just keep working with "Starting Forth" and if you are using PropForth - go through the .htm tutorial. If you are working with Tachyon, use the introductory thread, and ask Peter.
As far as playing with Forth and just picking it up.....
I tried that in the past and my interest dropped out. I got the impression it was not much more than a glorified RPN calculator (which is very NOT TRUE).
So this time around, I really have set out to know how to do all the micro-controller basics: meaning numerical calculation, bit manipulation, address pointers, construction and use of arrays, and more. In the past, I made the very serious mistake of thinking "Starting Forth" was a kiddie book (it just looks a bit like one, it is a serious introduction to computing in a fun loving format).
So what am I doing and is it working for me?
My own learning approach has been to use contrast between different solutions to discover what is important to me. Other have frowned upon this.
Admittedly at first I thought that working diligently through ANS Forth 94 was a good thing, but the corpus of information is rather large for a beginner and the tome is written in a style that is rather dry.
From there I shifted to "Starting Forth" by Leo Brodie as everyone who is anyone in Forth says this is the best book.
I continue to study it while actually doing things on the Propeller and am convinced this is necessary (Be careful -- reading Brodie's later book, "Thinking Forth" before you have mastered "Starting Forth" will make no sense - I tried some years ago).
But I did find that there are really three versions available of "Starting Forth" and feel strongly about getting the right one. The first edition that was based on Forth 79, the second edition that was based on Forth 83, and the current on line 'defacto' third edition that is based on ANS Forth.
So I figured to forget about Forth 79 or Forth 83 and to just focus on ANS Forth 94 and.... whatever has been provided for Forth on Propeller.
You now have the "Starting Forth Lexicon" PDF as a way to survey if you need to read the book and what chapters are hazy to you. Hopefully this will be good for everyone. It has been good for me personally. And I am revising that list as there are a few words that were missed and a mention of GForth's INCLUDED that is a bit wrong.
And since I am studying "Starting Forth" in ANS Forth 94, it was quite easy to load GForth as a study environment without having to boot up the Propeller Proto Board or Propeller Demo Board. It seems many feel this is a sin of betrayal for I am using a 'big bloated Forth', not a lean mean micro-controller version.
In conjunction with that I have loaded TachyonForth and PropForth just out of curiosity and in hopes of acquiring some insight into what more I needed to know to run Forth on a Propeller. I made a few observations and suddenly people are accusing me of trying to be a Forth Guru. Why would a Forth Guru title this thread "Poking along as a beginner to Forth"?
I NEVER meant for my postings to be judgemental and complaining. I do admit to being confused at times. Somehow we got off into the weeds where such assertions were made, along with a lot of other stuff of dubious merit, and just not fun. I have just been trying to explore and share one possible path for a new user of Forth to move rather easily into Forth on the Propeller.
I have learned a lot. I am enjoying Forth. And I am also reading from three PDFs on ANS Forth by recent writers. But I made not mention of them as I did not want to confuse other beginners with too many references. Not all of this reading is appropriate for Forth on a Propeller, but I wanted to learn the language in today's setting of 2012 - not just learn to use one or a few versions of Forth on the Propeller.
From the beginning, I was under the misconception that I required more than 32K of EEPROM to save my work in PropForth. I have said several times that I did NOT fully understand 'saveforth', but it seemed to work. That I suppose was a lot of the beginning of confusion. I thought that using the SDcard would clarify how 'saveforth' worked. And you all discovered that I have one particular personal preference - I'd like to use SDcards with FAT16 or FAT32 in accordance with SDcard Associations conventional formating (it is not about sector size, it is about a lot of other things).
I do understand that everyone just wants to exploit the SDcard as an SPI SRAM and not bother with FAT16/32 at this time and for the sake of more speed. And it just may eventually work as a way to extend the LMM (Large Memory Model) beyond the 32K of Hub RAM. At least the LMM according to Pacito's proposed specification is trying to do that. And this would be a wonderful thing for Forth on the Propeller as bigger fast dictionaries would be available.
Back to what I was doing...........
In the interim, I took a quick look at Tachyon, and mentioned it came up in Hex. I even said HEX was more handy for most of us, Peter took it as if I thought that HEX was somewhat inferior to DECIMAL. This is really a tempest in a teapot if you look back at what I said and how it was interpreted.
I have tried to welcome and include Peter's comments, but there is a limit to how much I feel that I should allow another person to cast me in the light of a fool and lecture me. So all this came to pass. (BTW, I do try to cut allowances for the Aussie persona. They are just a very competitive, energetic, aggressive bunch of blokes in anything they set their mind to.)
I think most of those that have been on this Forum for a while know that I feel "the more, the merrier" and that we can forget and move on. These mis-communications happen from time to time. But they aren't the end of the world.
I am making progress in Forth, and hope to welcome others that want to do so.
And it is indeed 'progress, not perfection' that I am after. So let's all just move on and have fun.