PropForth - Poking along as a beginner to Forth.
LoopyByteloose
Posts: 12,537
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 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.
Comments
solder up an adapter socket like in the instructions
http://code.google.com/p/propforth/wiki/PropToSDconnection
load the SD kernel
read the comments and tutorial
Incorrect, The EEPROM kernel supports EEPROM files system, the SD kernel supports SD file system. Only the drivers have changed.
There's only one EEPROM kernel, use has to know how much big the part they soldered on is. It just goes until it runs out of room.
No, the first 32K is the prop's boot image, anything else is left for you. The kernel doesn't know or care, that's your job.
No, we did not make any complex kernels, EEPROM + SD was too confusing from name conlisions. This is a later task when we get some time and sort out the names and see if we actually need it. You can start on it, of course.
The SECOND 32K is for non boot image data.
Your getting there. If it was too brain dead it wouldn't be so fun. We just have to be aware of the design decisions, why there were selected, and what the impact is. It makes it even cooler to actually understand the details.
The EEPROM or SDcard file system seems to ring a bell. But while I see words to evoke such and comments about this, I don't see an introductory explaination.
The so-called Tutorial Files are not much more than verification proceedures to determine that the installation is correct - nothing about the care and use of file systems.
The core question is whether I need more than 32K EEPROM with the SDcard file system. If NO, I may switch to my Propeller Demo Board for SDcard PropForth, and retain the Propeller Proto Board for EEPROM PropForth.
Frankly, I am quite happy that you didn't make an EEPROM file system / SDcard file system combination. I have quite enough to deal with as is.
I guess the first item is resolved. I will set up the Propeller Demo Board with the SDcard file system.
But... I'd love to know more about using the file system. I have used 'saveforth' in EEPROM and it seems to work, but I've no idea what is doing in terms of booting.
too bad, i thought this would be easiest choice as adapters are included with micro sd, and gives you a free socket for the cost of a couple resistors
.... Parallax microSDcard holder ....
good choice
.....I don't see an introductory explaination....
then ask here, the others succeded with docs alone, i will update per your questions
....The so-called Tutorial Files are not much more than verification proceedures to determine that the installation is correct - nothing about the care and use of file systems.....
incorrect. please don't assume this until you have run the demo
....whether I need more than 32K EEPROM with SD.....
NO
i use demo for jupiterace and quickstart for all else since its smallest
.....Frankly, I am quite happy that you didn't make an EEPROM file system / SDcard file system combination. I have quite enough to deal with as is.
I guess the first item is resolved. I will set up the Propeller Demo Board with the SDcard file system.
....But... I'd love to know more about using the file system. I have used 'saveforth' in EEPROM and it seems to work, but I've no idea what is doing in terms of booting.[/QUOTE]
please run the demo in the tutorial, and ask here, i believe Rick also has SD working
It does look as though I did not pay close attention to what I was doing with the /kernels/doc/tutorials for EEPROM as I just had a lot to learn. That directory seems to have tutorials that get progressively more sophisticated.
BTW, I have tried to not ask at least until I am ready to use something AND have both read all I think I can find AND taken a few hours or a day to think about what I want to do and what I can't find.
Still, I am overlooking stuff.
you will never be able to provide the same input again.
the docs are NOT well organized or clear. the author already knows everything, and the editor doesn't and tries to guess what my questions were 30 years ago.
Sal would go through each item, in order, until it answers his question, or turns into a dead end. i do the same, but end up in a different place. due to different levels of experience.
in any case, ask often. the only bad question is the one left unasked
One agenda is to try to acquire some knowledge of all the words and their uses at a reasonable rate.
Another agenda is to try to comprehend the PropForth Kernel.
A third agenda is to try to comprehend the boot process.
A fourth agenda is to try to fully understand where the dictionary lies (in one place or more) and how it reaches the Cogs.
And I could go on.
Mostly I've tried to shut up, read and think, and mostly ask questions that seem to me to be useful to a rank begineer of Forth -- what those people would appreciate. All those agendas are overly greedy and ambitious and I may not get very far with them.
Creativity is chaotic. And above all what you and Sal and others have done is far more than I am capable of doing.
Your questions and comments about the documentation are all well founded and useful to the cause.
The various *.txt files in the tutorial folder are rough going. The info is mostly there tongetthroughthe various stages but the formatting is rough and confusing.
The .html file that Sal created as part of the PF 5.0 release and refined in the 5.03 package is really excellent and a big step toward having a reference document. I think I started this journey with 4.0 and there wasn't much to go on other than source code and the validation/testing scripts.
I'll take a crack at explaining some of this writing from my iPad and memory but will probably revisit when I'm back at a PC. (I'm having a kidney stone episode and PC time and concentration are taxed)
We can all agree that a basic, bootable Propeller must have at least a 32k EEPROM. For any language, an executable binary is put here to be reloaded when reset.
[edit] THE FOLLOWING IS INCORRECT- ignore this paragraph.
The job of saveforth for any kernel is to copy a compressed version of the dictionary and any executable code from the Propeller RAM to the 0-32k addresses of EEPROM so you can reset and reboot with any changes you make. From an earlier post by PB, it compresses the dictionary by removing any old duplicated words and just keeping the newest definition of a word. I didn't know this and want to do some experiments along these lines at some time.
[end edit]
The basic PF5.0 kernel is the Development kernel. It has the words that are the core of PF with only enough I2C and EEPROM support to do what saveforth needs to do to save an image. This kernel will run on any Propeller board and is the smallest offering the most dictionary space for user applications. Theoretically, you could go into the kernel source and prune out words you didn't need in your application or the new core you were making but that is fraught with peril.
At this point, let's PF discuss the dictionary. The dictionary that any PF interpreter sees is in RAM and can't be anywhere else. From what I understand, it is pretty much a standard Forth dictionary with the little chunks of threaded word addresses that make a Forth work. You'll see references to NFAs and PFAs and word addresses and such. For now, it's just important to know that it is in RAM and can never grow,bigger than RAM. There is a word 'free' if you want to see how much space is left for the dictionary to use.
When you start PF, each COG runs a copy of the Forth interpreter (which you can find the definition for in the .f files) except for COG7 which runs the serial I/O handler (which I believe is a Forth Assembler word). Then console I/O is set to pint to COG6 by default.
The EEPROM kernel has all of the above PLUS it has been extended to have words that provide support for an EEPROM file system that uses any EEPROM above the 32k line. With these words, you can create, read and load files using the EEPROM as non-volatile storage. This could be the perfect kernel for a medium sized application that had some data that needed to survive across resets or some possible configuration variations that could be tailored at boot time. Before PF5.0, you actually built this kernel by adding extension files if you needed it. I think you can do that still but the EEPROM kernel may be optimized some as Sal builds it. Anyway, check out fsrw.f if you want to see the EEPROM extension words.
The SD kernel has support for the SD card built in. For what PB says, it does not have EEPROM support anymore. Prior to PF5.0, you could build both into the kernel.
The booting process, I can't write about from memory, it will have to wait.
I do remember that both EEPROM and SD kernels will look for a boot.fs file and execute that if it exists and you aren't pressing escape on the terminal. There are also the onreset words that allow you to start certain COGs running certain words when the Propeller is reset. There are a couple boot words but I forget what they do right now.
As mentioned earlier, the active dictionary is in RAM and no place else. Each COG that is running Forth is running the interpreter loop (a Forth word). It works pretty much like the interpreter in Starting Forth. Getting input, checking to see if it is a word, execute word if it is, if it's a number, push it on the stake, if it's neither, complain and ask for more input.
still at work must keep this short:
EEPROM image loads into ram, this loads into forth cog6. also this loads into other forth cogs, by default cogs 0 to 5 are also loaded with forth but are not doing anything. cog7 handles serial IO. execute
cog?
to see what each is doing
each cog has its own dictionary, so you can define / load different extensions depending on each cogs duties
each cog also has its own number base, this is why we need explicite number base in all literals in source code.
I'm with mostly with you up until after cog?
There is only one dictionary - think about what happens when you load a .fs file for example. The fl changes to a different COG for loading, but the words you load end up being visible to any interpreter in any COG.
I also thought the number base was system wide but that can be tested easily enough.
Let 's not fight in front of the kids - this can all be tested when I 'm back to a PCM and prop board. :0)
There is only one dictionary.
In this example, I compile a word '6test' with the console attached to COG6, then change to COG5 and execute the word '6test' it is found and executed
The base is on a COG basis. The variable base is a COG variable defined in PropForthStartKernel.f
From what I could tell, by testing and looking at the code, 'saveforth' does no compression of the dictionary. I redefined a word several times which would create several entries for it in the dictionary - the interpreter finds the latest when searching for a word to execute from the command line. I did a saveforth of this dictionary and then reset the Propeller. I was able to forget my test word from the dictionary and execute the earlier copies, so they were carried forward with the saveforth.
This can be a great gotcha when developing Forth code and can lead to loss of hair:
wordb will execute the original worda because the address of that word is compiled into wordb you can modify and recompile worda all you want but until you recompile wordb you'll never pick up the latest worda. Just something to look out for.
Hope this helps more than this confuses!
I have not completely read through the above threads since my last entry above, but.....
I have loaded PropForth V5.3 into a Propeller Demo Board that has an SDcard reader. This is a modified .spin image to bring the SDcard pins down to the lower pin outs of the Propeller Demo Board.
I still have PropForth V5.0 loaded on a Propeller Proto Board to further explore using the EEPROM file system and that may soon be upgraded to V5.3.
I have loaded yet another Propeller ProtoBoard with TachyonForth V2.0 with SDcard support and just getting baby-steps in TachyonForth. It certainly is a different learning curve.
For NOW....
If anybody is a new Forth USER. Start with "Starting Forth" by Leo Brodie as provided on line by Forth, Inc. as it is ANS Forth 94 compliant and has a lot of good tasks and review. To do so, download a free copy of GForth.
Then, load PropForth into whatever you have operational for a Propeller Board and try to work through the .htm document to get up to speed. This is a bit tricky because at least some of the first few .txt tutorials may actually help you confirm that your system is set up properly. Above all, use a simple bare bones system to start, don't be too ambitious. But please be warned that the .txt files are a bit harder to read than .htm because there is no color and no special fonts to help you see what is a Forth word and what is not. More carefull noticing of what is trying to be communicated is required.
TachyonForth is interesting, but with a different dictionary - especially the i/o pins - it may confuse a completely new person to try to learn both Tachyon and PropForth at the same time.
Tachyon in general presumes the user knows more about Forth. Tachyon also prefers Hexidecimal number display over the more usual Decimal. You have been warned! Some will love it, others will not know what to do with it. Hexidecimal is very helpful with 32bit, whereas both Decimal and Binary are a bit of a blur to read. (PropForth can display Hexidecimal too, you just have to ask it to do so.)
And so....
I have a lot to study and do. I am very happy to see that the .txt files will take me deeper into the PropForth as the .htm tutorial is pretty much understood. And I have been helped greatly by using "Starting Forth" and GForth to get some ideal of what is what.
Kidney stone? Don't feel you have to keep up with PropForth and what I ask while you are resolving that. Thanks for the above. I didn't know about number base being able to be different on each and every PF Cog.
I may post another personal Blog entry soon for the rank begineer about what I've learned and what I've had to relearn in regards to getting started with PropForth.
I am very happy that I waited until V5.0 and I suppose all of you are lucky you didn't have me any sooner as I can be as dumb as a door post at times.
Interesting about saveforth. I can go either way - overwrite the old word or use the last redefinition. But I do see the eventual need to overwrite the old word for space. The dictionary will never grow beyond the 32K boundary in its present incarnation -- maybe one day, but not now. This makes me wonder why I really need an SDcard setup.
Sorry, I was typing quickly at work between tests, and the timer went off....I;m mixing the "old way" and the "new way" Let me try again (and I'll edit previous when I sort it out)
The dictionary arrangement and the cogs gets interesting. There's one dictionary, and it resides in HUB RAM, yes.
Here what I was attempting to communicate:
ASSEMBLER routines execute from COG memory. We can load a (page) of assembler code into a cog, that run it, this code is unique to only the cog that loaded it. When the assembler routine is done executing, we can take the rests and igonore the routine; we can call the routine over and over until we over write it; we can over write it with a new routine and execute that.
As long as we have a "library" of optimized routines, we can call as many routines as we can fit in external memory (SD, EEPROM, etc) and not increase the dictionary foot print.
This is not in standard forth, I believe; standard forth requires us to compile assembler word into the regular dictionary rather than a page buffer.
Meanwhile, I have upgraded the EEPROM version to 5.3, but am having trouble compiling in BST both V5.0 and V5.3 of the SDcard version. I will try using Parallax's IDE later tonight to determine if BST is PropForth unfriendly.
I'm impressed you are trying PropForth, Tachyon and gForth all at once. My brain gets fuddled with too many similar yet slightly different dialects knocking around in it.
Lately, I've been using SimpleIDE to compile my PropForth and Tachyon .spin files. It's been working fine. In the past, I had been using BST on my Mac and don't recall any problems. I don't use the SD kernel very much, so I may not be a good test case.
It is all about embracing your 'inner juggler'.
Maybe I should begin Japanese and Korean studies to add to the Mandarin Chinese and Taiwanese.
The truth is that I have learned very little Tachyon, just enough to know that it is different and may be fun for the adept Forth user.
this is different from what i understood.
test 1
should have been recovered from the dict after the saveforth. so something is not what i said......
ok i think i got it now. in the kernel genreation process is the word
SPINMAKER
this is the word that takes only the most recent definiton in the dictionary for each word.
saveforth writes the current 32k of RAM to the first 32k of EEPROM
there, that should fit reality better. i'll verify when i get back to the lab and update the posts tonite
Just a few comments as otherwise there would be no end to them! It's very obvious that you are making a lot of judgements from the point of view of an extreme novice. You are entitled but you may look back at some of your comments in the future and cringe. So here are a few heads up:
1. Any Forth does not "prefer" a particular number base. If you like to work with decimal by default in Tachyon (whereas I prefer hex) then simply say DECIMAL which can be followed by a BACKUP command if you wish to. Thereafter on every power-up you will find that Tachyon "prefers" decimal.
2. The I/O words in Tachyon are very efficient and very fast, you can get microsecond pulses without doing anything fancy if you want. This is one of the reasons I wrote Tachyon to overcome otherwise extremely poor performance in this regard. Once you finish blinking leds and start to interface to some chips you will really appreciate what can be done in Tachyon Forth without resorting to assembler. Output words shouldn't force you to handle each I/O pin by pin and also have to worry about the direction register. If I want to make P0..P7 all low outputs then I simply say $FF OUTCLR which clears the outputs and then makes sure that they are switched to outputs in the DIR register.
3. Rather than presume that the user knows about Forth, Tachyon addresses the way we program as well as Spin and PASM and looks at ways things can be made more sensible. For instance you may have noticed that you can force numbers to any base using mixed styles and prefixes or suffixes etc such as #P16 or $80:0000 or % 011 for example. You can also define variables in a similar way as we do in Spin by saying LONG myvariable,count,flags or BYTE errors,speed etc. Still, you have to know something about Forth but if it's fun then it can help a lot in learning it.
There is also a lot more to a Forth than what the user sees, it is what goes on under the hood as well. Plus there is the matter of source code which in Tachyon's case is one simple file which can be completely compiled from the Spin tool in one keystroke. In this case too the source is in a very readable and manageable form if you ever desire to delve into the kernel. The bytecode nature also means that code is very compact leaving more memory available for such things as video etc.
Considering too that Tachyon is not quite four months old and it already leaps tall buildings in a single bound. So where do you think it will be in another four months? A year? Although I have been concentrating on my Tachyon applications rather than the kernel for the past month or more it just means that there will be a whole lot of features unleashed soon. I see a need, I do something about it. There's the soon to be released help function which tells you all about a word interactively.
I'm working on the SD code at present which handles the SD as a huge virtual memory (working) plus I am building in FAT32 support as well as FAT16 of course.
I have to leave these comments for now as there is just too much to mention and clarify etc. Just know that you are going to have a more balanced view of what's what as you gradually gain experience and insight into Forth once you start writing real code. Then you take into account the application and other criteria and choose which you use for yourself at the time. Another time you may choose differently and so on.
BTW, I just received a copy of the original edition of "Starting Forth" and it's in really good condition. The many copies I had in the past of this book have been "borrowed" and I have lost track of who borrowed them. Now I have one that's in much better condition.
FYI, I waited months for V5.0 to be finished as I was too wary of trying Forth without a tutorial.
As far as the number base, "Starting Forth" starts with decimal. Later it does a wonderful presentation of other number bases and why one should not hang on to decimal when one is programming.
You start out presuming your audience has a much higher level of computer knowledge and specific Propeller knowledge that I do. That's okay, they are different people with different knowledge and skills.
I'd love to hear more about your SDcard interface - sounds useful. This evening I have been running down why my microSDcards won't work with either PropForth or TachyonForth. It seems none of them came with any formating and now I am running an SDcard association formater (in Windows7) that is doing FAT16 and 512 byte sectors. From what I understand this is ideal to make the cards last long, but we will see. Besides, two 512 byte sectors is the size of the traditional Forth block. That may come in handy down the road.
Above all Peter, please don't consider this a contest between PropForth and TachyonForth. Comparisons are inevitable, just because the two exist. I really don't have time to keep up with all of it. And I am sure that you never have enough time to devote to what you have taken on. So please enjoy the ride and consider me an admirer.
I will repeat --- AbeBooks.com is a world-wide used book vendor that has copies of both first and second edition "Starting Forth", but I am preferring the online Forth, Inc edition as it has again been revised, they provide answers to the problems at the end of each chapter, and there are not issues of which edition is better for 2012.
Not only am I rank begineer at Forth, I don't think I've ever properly learned Spin or PASM. But I do feel more confident that I can through using Forth on the Propeller.
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).
Funny thing is that when you say you are a begineer (rather than beginner ) it sounds a bit like a beginner engineer. A be'gin'eer, cool, new word!
Another thing I'd like to point out about Tachyon though is that to do that fast bit banging it's got to be fast under the hood in the first place. So to say that Tachyon is good at bit-banging should also imply that it is fast in general. There are some operations such as multiply and divide etc which can't run any faster than they already do but those operations do not represent the majority of code that is run anyway. My early bitmapped VGA demonstrations showed how fast Tachyon can run which would normally require PASM running in it's own cog to do the things it did at that speed.
As regards to FATxx it is a horrible kludge upon kludge as the standard evolved. The weird thing is that Microsoft actually thinks something like FAT32 is that important it should be proprietry. Yep, I'd agree with that because I wouldn't want anyone to see that mess either.
So we have to live with FAT because of the MS monopoly of enforcing their OS onto PCs by default. Enough of that gripe because we haven't got all day or all week to discuss that. FAT may not be a JFS but FAT and DIR sectors are continually rewritten leading to wear. Take for example a data logger which continually appends to a file. Well the file size is kept in the directory entry and you need to keep this updated to make the file valid. There are ways around this of course at a higher level but none of these file systems are friendly to Flash. Whole blocks have to be internally erased and rewritten just to change a single byte each time.
if you never need to unplug that SD card and put it into a PC then you wouldn't bother with FAT. If on occasion you need to remove the card and read it in a PC it might be better to have a utility that updates all the FAT structure to suit. I prefer having one large non-fragmented file in which my virtual memory and file system can exist and then have an EJECT command which worries about the FAT at that time. So much simpler and more efficient etc from the run-time perspective where it spends most of it's time.
I hope however that you are not considering Forth disk blocks! Tachyon will eventually have a built-in text editor that uses either a VGA screen or a fast ANSI serial terminal emulator for editing source code from it's own SD. Anything without an SD or serial Flash will work just like it does now.
That annoyance I had was that you were in effect comparing apples with oranges and mentioning that the orange wasn't as crisp as the apple so that therefore the apple must be better. Well, I like apples and oranges but they are not the same thing.
The reasons why I wrote Tachyon and my goals in this regard are all pretty well explained (and buried) in the volumes of posts which I won't bring up in this thread. Tachyon is doing everything I wanted it to and more which is why I am using it as my base for my many embedded commercial products from now on. It's not an academic exercise in writing a language, it's a powerful and practical tool that I use each day and keep improving upon as real life situations and new designs demand.
If use use the SD with FORTH (as designed) is is to be considered INTERNAL to the Forth system. This is the same way as the iPhone or any smart phone. You wouldn't de-solder the interanl memory of the phone and try to plug it into you PC then complain it works different. Rather, you plug THE WIRE from the phone to the PC and do a transfer. Same with the forth system. Just because the SD is in a socket, don't imaging it HAS to be plugged directly into the PC. The WIRE is how you comnnect to the PC, and the trasfer takes care of the data, and the PC stores in in whatever format it likes on SD IN THE PC. Just like your MP3 player.
Using forth blocks is on the SD is the same. You don't CARE how the forth system gets the data to the SD. You only care that the data gets there, and gets back. Its the same as writing to memory, or to EEPROM. You just call the function, and it happens. If you decide you won't use blocks, you can write something slower and more cumbersome, but you won't write anything faster. (is my guess). Peter will likely come up with something clever, we'll have to see what it will be and how it works out.
Regarding the SDcard....
Since I live in Taiwan and state of the art chips such as large SPI SRAM are not available over the counter in the retail electronic markets, the SDcard makes a wonder hack for large storage, even if it was never really intended to do so. It does end up a weird fit as I have to use a 2GByte micro card, just to store less than 1Mbyte of important data. But it is cost effective and ubiquitous. (Did I spell ubiquitous correctly?)
Moving on....
I have been trying to get the SDcard reader working in PropForth on a Propeller Demo Board, but I seem to have hit an obstacle in both PropForth V5.03 and V5.30. After a complete reboot, I get Cogs 1-5 coming up correctly, but Cog 6 outputs a message 'Error 166 - Unknown Error' and it both the Parallax Propeller IDE and the BST, I get 4 lines of compiler messages that I read as warnings. But I don't understand them
The PropForth .spin files for the regular 32Keeprom and the expanded 64K or more eeprom compile without messages and boot without error. So I am a bit uncertain what to do with this. I wonder if ignoring it will cause more trouble with the SDcard. I have two 2G microSDcards reformated last night to 512 sectors and FAT16. I presume these are okay as FAT16 is not controlled by MS and the SDcard associate prefers they have 512byte sectors.
I don't know much about Forth blocks. I suspect that they were part of the early Forth to edit and store words, but that we have moved beyond that. I haven't yet gotten into opening, closing, writing, and reading files in GForth - so I am not up to speed on any of this.
And....
I get a bit fuzzy about why I really need a bigger EEPROM or an SDcard if the image is always limited to the 32K EEPROM image. I had presumed the original image was kept in the first 32K, and higher 32K units were able to keep 'saveforth' images for a redirected boot or the SDcard kept a bootable 'saveforth' image for a redirected boot. But I still am not all that clear about this and haven't found much to read.
I haven't had time to get an SDcard operating in TachyonForth V2, but the software did load correctly. While I am curious about TachyonForth, this is becoming a bit of a paper chase to keep up with more than one 'Forth on the Propeller'. No joy in that. In other words, I may just still with PropForth for a while - speed be damned. I work at a snail's pace for the most part.
By the way, as far as being a beginning engineer, I do have a Professional Engineer's E.I.T certification that was issued by the State of California decades ago. I passed the two day exam on the first attempt in spite of my formal education being a B.S. in Fine Arts, major in painting. I never acquired a full P.E. in anything, but worked building and negotiating major office building construction in and around the San Francisco Bay Area. Then, I moved on to Taiwan for graduate studies in teaching English as a second language from the University of Edinburgh, Scotland. The electronics have been a hobby that I just picked up at 12 years old (circa 1960) and my only formal computer training was one university course in Fortran programming on an IBM360.
I am slowly reading though the Tachyon treads to try to get up to speed. After all, everything about 'Forth on the Propeller' is of interest to me, at least for now. It now seems that I should read through all the previous version of PropForth threads as well.
reading a block = reading a sector into ram buffer
writing a block = flushing a buffer to disk
FAT uses sectors, just with more Smile in the way, (to make it slower?)
Please don't change it, we like it as it is, we have a new word and you invented it. If we get picky with spelling it is not with ones where English is their second language, it's with the ones who should know better or they spell like they are texting teenagers (exceptions made for a certain moderator).
BTW, Unlike magnetic media which needed both high level formatting as in the case of FAT and also low level formatting as in the number of sectors per track and bytes per sector, preamble etc etc, you will find that Flash is very different. In the case of SD memory the "sectors" are 512 bytes, there is no low level format equivalent so you can treat it like a serial Flash if you want.
So with Forth you can have a completely erased card if you like and it still works the same with reading and writing "sectors". The original Forth blocks or screens just treated the disk as virtual memory so it didn't need to be high-level formatted. With SD cards FAT is simply for compatibility with PC readers.
This issue of FAT16 and file system comes at Forth from several directions.
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'.
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?
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.
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.
In other words, anything called Forth on the Propeller is not going to adhere faithfully to early Forth or to ANS Forth 94 if it really offers substantial utility for the micro-controller. But I still remain an advocate for the rank beginner that is stuck with a somewhat limited number of reliable options on how to learn and grow into using PropForth or TachyonForth.
I am enclosing a PDF that lists the entire vocabulary presented in 'Starting Forth'. This offers a smaller and more sensible entry lexicon over ANS Forth or anything else, and there are some notes at what GForth does that is not quite the same as that text. Anything NOT on the list, would need further clarification to the student of 'Starting Forth', though one can work through the text with GForth. AND, following up with GForth's own tutorial text may provide more oversight that would make it easier for learning PropForth or TachyonForth.
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.
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.
Whatever youall might think, the "Starting Forth Lexicon" is a good 'need to know all of them" list that puts a foundation under any other Forth that the new user might want or need to learn. So here is the list (see below).....
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. The original is in a spreadsheet format.
A FAT16 recommendation for SD cards has more to do with one that leaves more space available for user data and FAT16 might be the lesser of many other evils. Besides most people wouldn't have a clue about FS formats, they might know FAT and NTFS although they probably don't know that there is a difference with FAT as Windows does it all for them (such wonderful magic....). Of course there are many other FSs out there (I speak from a Mac/Windows/Linux perspective ).
I think however that you are worrying too much about what should be or shouldn't be with Forth. So what if PropForth doesn't have a PAGE command? Big deal, I write the version that suits the display device in just a few words, done. BTW, it's normally referred to as CLS or CLRSCN etc rather than PAGE which really only emits a $0C. ANSI sequences are different. Of course OCTAL is useless but so what? Just don't use it. It was more important once because DEC (PDPxx minicomputers etc) used OCTAL in their documentation, it was useful because you could represent binary with common decimal digits and via standard numeric keypads etc.
Forth was developed at the time to provide some real-time interactive control to some very real-time interactive hardware.....radio telescopes.
So you are caught up in comparing everything else to what you know first but what you may know first might and probably is not the best or right or fully understood etc. Personally I wouldn't bother trying to "learn" Forth by using the PC version. Use the version that runs on your Prop board, it is way more fun. Stick with that and get to know your Prop and your Forth inside out. Do something practical, you will learn so much from having a need and doing rather than approaching as a formal subject. My very very first project with Forth was on an Apple II and I found I could test and align disk drives as well as other hardware and that any tweaks I made were instant. Besides, the Forth itself was also the command interpreter but way better than any command interpreter that you could think of writing. Because of my exposure to Forth in this hardware manner I immediately applied it to an upcoming project developing a new breed of POS terminals. That was the most fun and the most productive ever. But I digress only enough to impress upon you.....STOP TALKING.....JUST DO IT.....USE THE FORTH......
I just mentioned Page as an example of what is NOT included (in PropForth). It is a handy feature as the screen does get a bit cluttered without it. But I do understand that having memory for words in short supply, it becomes omitted. You presume that I said it 'should' or 'must' be included.
I am much more concerned about why the new learner has to learn one Forth that uses dog, another uses mutt, a third uses hound, and a fourth uses canine. I think we all know that many are going to lean toward ANS Forth 94 name choices just because they are well documented. And that means I can read example code from many authors.
I have nothing against software forks, they happen to provide a lot of innovation and creativity. I just take a teacher's perspective that students should not be unnecessarily daunted, especially in the beginning. Let them find documents they can trust and then they can grow confident in using both what they know and what is new and possibly better. Only after they have gotten their bearings will a transfer of skills to other contexts be really rewarding. At this point, Tachyon is a relatively undocumented version of Forth, PropForth is better, and ANS Forth 94 has been around for ages.
In other words, TachyonForth has so far presumed that the average user will be already knowledgible and competent in SPIN and PASM. I am taking the other point of view, that Forth is a delightful entry point for the person that has never seen a Propeller before and may have never programmed a micro-controller. To them, the educational environment is as important or more important than the speed or novelty.
If you want to choose a synonym for every Forth word there ever was, you will have a very unique language. It can be done, but what is the point of doing so. There are enough 'non-core, non-standard words' that are required for using the Propeller.