@prof_braino, I'll load PropForth on my C3 board, and try it out. I'll let you know how it goes.
@Loopy, you probably meant Celsius instead of Fahrenheit. That would be a little more accurate. Or maybe the boiling point of water in Fahrenheit divided by two.
Well, I am not up to coding a complete ANS Forth from scratch for the Propeller anytime soon. And I at least qualify for Mensa (being in the top 2% of the population is really not very far into the genius status).
Two things are implied - you understand the Propeller quite well and you have an equally competent understanding of C. And then there is the fact that you acquired Forth's underlying fundamentals so fast. It is always simple if you fully understand it.
BTW, I am not sure that qualifying for Mensa is really that big a deal, just one out of 50 is merely enough to get one into trouble by thinking they can figure out anything. Focus and effort are equally important.
When I was asking the forum and annoying the Forth enthusiasts with questions like, "What is the Forth standard?" and "Would the real Forth stand up?" I was not expecting anyone to go away and write one from scratch:)
BTW, I have started, but haven't finished a 'study listing' of ANS Forth words with topical groupings for easier comprehension. Comparative notes with PropForth and TachyonForth are being considered.
What are topical groupings?
Well, all the arithmetical items are together, bit-wise operators are together, moves to and from data memory are together, stack manipulations are together, and so on. These groupings are intended to ease finding something one particularly needs as word names alone are rather cryptic.
It is taking time just because I don't fully understand quite a few items, but I am working from references that other prepared of ANS Forth Core items and Extended Core items. With micro-controllers, there are always some Non-standard items that one has to learn for the particular platform. Those are not being included. But I am thinking of adding notes with an ANS Forth item is provided with a completely different name.
PropForth uses ST? to replace the ANS Forth word .S and by doing so, the new user might be frustrated in trying to read a lot of generalized tutorial material as one much know what one needs to translate to run tutorial examples. There are not a lot of these, but it would also be useful to note which items are included in PropForth or Tachyon Forth as a way to widen the library of reference material one can study from.
I guess this project is growing, so I have no idea how soon I will have something useful for others.
Frankly, every Forth developer seems to have some personal reasons for doing things their own way.
.s is historically correct for backward compatibility, but ST? is more intuitive for the new learner.
I am not about trying to make anyone to comply to ANS Forth 1994. I just have noticed that it was the most recent standard for Forth and possibly a reference that we all might be referring to.
Adding a fully compliant ANS Forth to Tachyon Forth or PropForth just might squeeze out memory space required for either better speed or for a specific allocation. On a PC, issues of speed and space are not as obvious. I suspect that anyone that gets into micro-controller Forth has preferences as to what they want to give up to get other things done.
I agree that ST? makes a bit more sense and you are correct about the memory savings out weighing the benefits.
I usually think of words beginning or ending in "." as printing words that will print something from the stack and remove it. .S certainlyy leaves something on the stack, so the dot doesn't fit for me of course the "?" words often test the TOS for something, remove it and leave a Boolean at TOS indicating the results of the test.....well, not quite for ST? Instead of "What's in a name?" we're all about "it's all in a name!" in this programming business.
As for categories?
Stack Words - do the @ and ! variants go here or they better thought of as "Memory Words"?
Arithmetic & Logical
Conditional & Looping
Compiling Words
I/O - gets tricky here since you have terminal, file and microcontroller type I/O maybe 2 categories
COG/Propeller words
Debug/Utility Words - saveforth, words, etc.
I'm sure I'm forgetting bunches.
Any documentation is a valiant effort. I'll certainly work with you as my time permits. I probably learn better through documenting and tutorializing. I'm still learning and trying figure Forth out in all forms.
i made a big deal about ".s" versus "ST?" way back when i joined the project.
Sal pointed out that these are two different words, as propforth does NOT do things the same as regular forth due to prop archtiecture. so propforth does not have .s but instead has ST?
this is to show that it is a different set of functionality rather than an arbtrary choice of name.
Sal typically knows what he's talking about, and its his desicion to make anyway. But this illustrates how any "standard" can only be applied so far, as eventually something MUST differ from the generic case.
just to reiterate, you guys are all smarter than me, i just do some of the docs
sometimes i write them, sometimes i read them
believe it or not, i'm not as smart as david mccallum's picture looks
thanks for doing the "hard part", using the software and sharing your results!
I'm not smarter. I'm not as smart as my cat looks...but my eyes have that strange glow.
I just like to play with Forth for some strange reason (more socially acceptable then paying with knives or fire).
Someday I may write code that actually does something....don't wait for that day. If I can help someone use something AND actually get started on the road to productivity, it's been a good day.
Okay Mindrobots,
How does one get PropForth to actually power up and immediately execute a program rather than go into interactive input from the serial port?
That would seem to be very handy for PropForth robot.
I always thought this was the most to-the-point reference on forth. I didnt think this was available to the general public without purchase of liscence, but it looks like its been availibe since august.
propforth has a few differences (explicite number base, no software multitasking, different CREATE, separate compile words, etc) but mostly resembles this.
I gave PropForth a try, and I am also having some problems with it. Assuming I have Forth source files on an SD card how do I compile them? I tried the include command, but PropForth didn't understand it. Also, does PropForth work with the C3 board's SD chip select? The setup instructions only allow specifying the standard 4 SD pins.
I started to re-write my Forth interpreter, which I call pfth. It's pronounced like the sound of air being let out of a tire. Or you could pronounce it as P-Forth, but there is another pforth that already exist. This second version is much cleaner than my orignal version since I now have a better understanding of the fundamentals of Forth. The kernel is written in C, and it supports 43 basic Forth words. In addition, I have a separate Forth source file that adds another 54 words.
Currently the kernel is about 770 lines of C code. I can run it on my PC and on the Prop. When starting pfth you can specify source files on the command line, such as "pfth ansi.fth test.fth". Or you can load a source file using the include command, such as "include test2.fth". I'll post the source for pfth once I finish implementing all the ANS core words.
...which I call pfth. It's pronounced like the sound of air being let out of a tire.
Brilliant name!!
I don't think PropForth is able to handle the C3 chip select out of the box. I think that was addresses in Tachyon but I don't recall it being addressed in PropForth.....I'm sure the good Professor will chime in soon if I am misleading you.
To load a .f file, you use the fload word for example in the boot.f file for gettign the HTTP server goging, at one point, it does:
fload httpserver.f
httpserver.f contains the definitions for the words implementing the http server.
You can just chain them together having one load the next or have a controlling file thet just loads them in order:
Pfth is a great name. Or maybe Pfth........... forth! or p.fth;-) or just plain pfth
What ever you come up with I would love to load on a Demo Board or a Proto Board. Different code has offers something to learn.
I suppose that one will get a larger following of users if you stick to the Propeller Proto Board as it is much less expensive and can be easily included in a finished project. It may be time for me to buy another 5 pack as what I have remaining are pretty beat up.
At first I liked the C3, but the price grew and it is indeed a rather expensive board. The new Propeller BoE is quite appealing.
I haven't yet gotten an SDcard reader in use. I have two and I want one to be used on the Propeller Demo Board as it has quite a few goodies included. But I am a bit wary of the care and feeding of SDcards. From what I understand, they prefer a FAT16 or FAT32 file system. Though they can be used in an SPI mode, at least some cards wear faster when used in this manner as the wear protection feature is bypassed.
I guess I am just wondering out loud which SDcard mode PropForth and Tachyon Forth and Pfth are committed to. I realize that I should probably just dig out the answers myself, but it is so easy to ask.
The JupiterAce will be an interesting milestone. I am not so much into retro computer aspect as I do see that the complete concept of a Forth machine will appeal to users that are not into building something from a bit of this and a bit of that.
@Prop Braino
I will take a look at PolyForth as I am beginning to see how one verison of Forth inspires features that migrate to another.
Meanwhile, both PropForth and Tachyon Forth have gotten me back into thinking deeply about the Propeller.
Okay, I downloaded the Parallax micro SDcard reader documentation and it seems all the extra pins are available, but there are really just 4 pins that important for data transfer. There are two more to provide power at 3.3 volts, and one that indicates that the holder has a card available.
I presume that as long as one is using the FAT16 or FAT32 file system, the card manages its own wear protection. Am I correct about this?
Okay, I downloaded the Parallax micro SDcard reader documentation and it seems all the extra pins are available, but there are really just 4 pins that important for data transfer. There are two more to provide power at 3.3 volts, and one that indicates that the holder has a card available.
I presume that as long as one is using the FAT16 or FAT32 file system, the card manages its own wear protection. Am I correct about this?
I don't know about any of that, but I do know that you can add an SD very easy and cheap like this:
If you do the default wireing, it includes all the pins, and should work in either mode. But propforth hasn't implemented the 4 bit mode yet, and I don't know if Caskaz ever finished the FAT support extensions, we just haven't needed them. We treat the SD as internal to the propsystem, so we really don't need to worry about FAT, just send files to the PC for that (save grey hairs).
I'm always disturbed by the "retro computer" bit. Its such an under-use of this part.
The Jupiter ACE project is finally make complete capable standalone forth system, in my mind it potentially a big deal. The original had too little memory, and was too slow. The prop version has too much memory, and it too fast. And it has two sessions of hires VGA, can control servos and read sensors.
The biggest deal is we can add as many cores as we want. Its only integer math, but I still think there is something to be said for having 100 cores for 100 dollars. The challenge that remains is how to write programs that use the prop as a pool of cores for a single number crunching task, etc.
The Jupiter ACE should not be a retro toy, but rather an inexpensive bleeding edge toy.
If you do the default wiring, it includes all the pins, and should work in either mode. But propforth hasn't implemented the 4 bit mode yet, and I don't know if Caskaz ever finished the FAT support extensions, we just haven't needed them. We treat the SD as internal to the propsystem, so we really don't need to worry about FAT, just send files to the PC for that (save grey hairs).
I am happy to hear the JupterACE project is taking shape and promises to be better than the original. That might make this question of proper FAT support more worthwhile to resolve.
I have no problem with the wiring of the micro SD card and I even purchased a couple of 2G microSDcards to use with them. (nothing smaller avaiable at the time, about $10 USD each).
But from what I recall, many people that have tried using SD cards as simple SPI storage have discovered this bypassed internal protection from excessive writes to one area. Apparently the SDcard is committted to using a MicroSoft format in order to get durability out of it.
So, one has to either create a way to rotate areas that are written to or use FAT16 or FAT32 in order to get the internal protection. Either way, it is more software than merely an SPI interface writing to blocks of SRAM. One has to have softare support of at least one file name and likely having about 8 would be better.
Bean developed a FAT formated data recording SDcard reader that I have and he managed to get into the FAT file system in a limited way. So I will try to review what he discovered to see if it is in anyway useful.
While I'd love to use my old SDcards (which are tiny in comparison to this 2Gbyte microSDcard), the Parallax reader only takes microSDcards. So I am just pondering what I want to do - get another card reader, canibalize Bean's device, or risk the 2Gbyte SDcard.
So far, it seems both PropForth and TachyonForth are NOT supporting any form of FAT16 or FAT32, and I suspect neither of you have considered managing block rotation of where files are written on a card in a purely generic SPI mode.
I guess that there is some propiretary 'magic' in how the FAT on these cards manages links to the actual blocks that keep the file data.
We did something that "OS way of thinking" folks aren't going to like. Actually, we what we DIDN'T do is what you might disagree with. Consider:
In the forth dictionary, if you use the same identifier over again, the previous definition is covered up, and effectively the most recent definition is the only one. Except memory is consumed by the old definition. Doing a saveforth re-writes the dictionary, and the old definition is ignored, and the memory is recovered.
SAME THING WITH SD. When you write a file to SD, it occupies a specific contiguous set of blocks. And you can read and rewrite those exact blocks (sectors) all day long. [Now I have to to check if this is still like this, I haven't been in there for a bit BUT...]
If you reload a file using the same name, the old file is still there, but now the name is associated with a new start location. SO THE WAY BLOCK ROTATION IS MANAGED is we just write to the files' blocks for a while; when we want to REALLY change the file (for example adjust the size), it moves to a new location, and the old location is implicitly "taken out of service".
Oh, no! those N blocks of space are lost! Wait a second! You have a million pages. How soon until you run out of space? Who cares? Just re-initialize the card, and start over once in a while. Or buy a new card they are cheap. Basically, the user is responsible for managing block rotation if it is ever an issue, but the block rotation is passively managed by not doing garbage collection.
Forth is not an OS so this kind of overhead is not required, and it would only get in the way most of the time. IF you really need FAT support, and file management, and block rotation, by all means write the extension. I will be grateful and use it too. BUT as an extension, only to be loaded when someone actively decides to take to effort of spending the memory and speed on that extension. consider that it has not been needed, and it has not been missed. By considering this in the design of our apps, we can save tons of overhead and preserve speed, determinism, etc; and it will still Look like an OS a large part of the time.
So far, we have not yet run out of space, and we have not detected a failure. Sal designed this for high speed logging of massive data streams, and the stuff he has running in his bench is doing just that. No problems so far, since 5.0 came out.
FAT is handy if you need to use an SD on a windows PC, but unnecessary outside the context of the PC.
Well, I do understand your point of view - but it may create premature card failures. And I am aware of the opinion that Forth isn't an OS, but if it looks, smells, tastes, and feels like an OS - what is it?
The short story is that there is a perfectly good OBEX object for FAT16/32 available. And it even has additional support for real time clocks to time and date stamp -- though it can be run without. All this will cost a Cog if it can be accommodated. And it would put your JupiterACE into the JupiterACE_Supreme category.
I realize I am being argumentative and compelling. I am quite happy to bump along with EEPROM images, but if you are going to exploit the SDcards - I suggest you don''t do it halfway.
Take a good look at Parallax Semiconductor's AN006 and consider if it hasn't done much of the work for you.
I have no problem with how 'saveforth' operates. I just will not use SDcards if they repeatedly fail when used in PropForth. Above all, I am in no rush for such a thing as I have plenty to learn about PropForth as it is.
I apologize for seeming pushy on this point. But I feel it is best for all. But of course, I may be asking for something that is just not possible for reasons unknown to me.
...many people that have tried using SD cards as simple SPI storage have discovered this bypassed internal protection from excessive writes to one area.
I don't believe this is true.
When you write a block to an SD card you use a block number to specify it. But that may not be the block number of the actual physical storage on the SD card. The SD card has a processor of it own to map logical blocks to physical blocks. Also the SD card has more physical blocks than advertised. It can use those extra blocks in it's wear levelling efforts,
I suspect that when you write a logical block number L it will end up somewhere on the physical store as block number M1 and M1 is marked as
"allocated" or "used" by the SD card internally. If you now overwrite logical block L1 it may well result in being written to different physical block M2 which is also marked as "allocated" or "used" and perhaps the old M1 is now "unallocated" and free for use. In this way blocks are rotated around and wear levelling takes place.
But consider this: What if I now delete a file that contains logical block L?
My file system will rearrange things to make L a free files system block, perhaps by fiddling with directory entries and other FS data structures. But,
and here us a big BUT, the SD card knows nothing of your file system, just because you have unlinked that block and returned it to your free space pool in your FS doe snot mean that the SD now thinks it's free. So actually the SD card fills up with allocated blocks and run out of space even though there is tones of it according to the FS.
For this reason SD cards have a TRIM command to explicitly tell them that a block is no longer in use by the files system and can be used again for further file allocations and wear levelling.
Linux has a command "fstrim" that does exactly this. I have no idea if your Android phone or camera or whatever does this.
Apparently the SDcard is committted to using a MicroSoft format in order to get durability out of it.
I don't believe this is true either. Whilst SD cards are FAT formatted out of the box there are plenty of systems running Linux from SD card with a variety of different file systems quite happily. And as I said the SD card itself knows nothing of you file system.
Perhaps we need an FST trim function for the Propeller.
I'd love to find links for you that explain all this but it seems to be very hard info to find and SD manufactures do not shout about their wear levelling tricks. Perhaps Kye or some other FS expert could fill us in on this.
What you have done for file storage is rude and crude and OS people may hate it.
However I have often though about this myself. With two things in mind:
1) Having a FAT or other proper files system on the Propeller takes up a huge lot of valuable HUB space. Would be great to get that down to something more reasonable.
2) We have gigantic amounts of space on SD cards, at least from the point of view of pretty small and slow systems like the Propeller.
So I come to a similar conclusion to yourself. Let's not worry about wasting SD space instead think about the simplest possible way to get named files onto an SD with the smallest amount of code space in the Prop. I would not even worry about supporting directories. After all the CP/M file system was tiny compared to what we have for FAT on the Prop.
What you have done for file storage is rude and crude and OS people may hate it.
That's the nicest thing I've heard all day! (Its morning here)
Sal wrote a test that just logs time and data and sensor data (temp or baro? I forget) to SD as fast as it can go. Its been running for months and has not run out of room and has not caused a failure. We're waiting to get a data point on something actually breaking.
If we talk to caskaz, I'm sure he would re-start his work on a FAT extension for SD in propforth. Sal doesn't see any point, and doesn't want folks (like you and me) to think it is actually necessary for anything, except to be compatible with an inappropriate solution. Instead, we send "file" data to the PC and let the PC handle it, since the PC is the one worried about it in the first place. Again, if we wish to do this on the prop, its (relatively) easy, but at a high cost of dictionary and speed.
The killer feature of having FAT on an SD is that the card can be popped into a Windows PC and read/written easily there.
Not being one to care about the inadequacies of Windows I don't see why this problem has to be projected down into our little micro controllers.
If we can create a rude and crude files system (RCFS) on the Propeller we can probably create a simple program to read/write it from Linux quite easily. This is already done for CP/M format file system images with cpmtools.
We have different constraints and freedoms than when FAT was invented, disk space we can waste, code space we cannot.
Comments
@Loopy, you probably meant Celsius instead of Fahrenheit. That would be a little more accurate.
Two things are implied - you understand the Propeller quite well and you have an equally competent understanding of C. And then there is the fact that you acquired Forth's underlying fundamentals so fast. It is always simple if you fully understand it.
BTW, I am not sure that qualifying for Mensa is really that big a deal, just one out of 50 is merely enough to get one into trouble by thinking they can figure out anything. Focus and effort are equally important.
When I was asking the forum and annoying the Forth enthusiasts with questions like, "What is the Forth standard?" and "Would the real Forth stand up?" I was not expecting anyone to go away and write one from scratch:)
What are topical groupings?
Well, all the arithmetical items are together, bit-wise operators are together, moves to and from data memory are together, stack manipulations are together, and so on. These groupings are intended to ease finding something one particularly needs as word names alone are rather cryptic.
It is taking time just because I don't fully understand quite a few items, but I am working from references that other prepared of ANS Forth Core items and Extended Core items. With micro-controllers, there are always some Non-standard items that one has to learn for the particular platform. Those are not being included. But I am thinking of adding notes with an ANS Forth item is provided with a completely different name.
PropForth uses ST? to replace the ANS Forth word .S and by doing so, the new user might be frustrated in trying to read a lot of generalized tutorial material as one much know what one needs to translate to run tutorial examples. There are not a lot of these, but it would also be useful to note which items are included in PropForth or Tachyon Forth as a way to widen the library of reference material one can study from.
I guess this project is growing, so I have no idea how soon I will have something useful for others.
Ok, now you're a bit more ANS than you were a moment ago. :0)
Maybe we need a ANS.F for making PropForth compliant(er).
.s is historically correct for backward compatibility, but ST? is more intuitive for the new learner.
I am not about trying to make anyone to comply to ANS Forth 1994. I just have noticed that it was the most recent standard for Forth and possibly a reference that we all might be referring to.
Adding a fully compliant ANS Forth to Tachyon Forth or PropForth just might squeeze out memory space required for either better speed or for a specific allocation. On a PC, issues of speed and space are not as obvious. I suspect that anyone that gets into micro-controller Forth has preferences as to what they want to give up to get other things done.
I usually think of words beginning or ending in "." as printing words that will print something from the stack and remove it. .S certainlyy leaves something on the stack, so the dot doesn't fit for me of course the "?" words often test the TOS for something, remove it and leave a Boolean at TOS indicating the results of the test.....well, not quite for ST? Instead of "What's in a name?" we're all about "it's all in a name!" in this programming business.
As for categories?
Stack Words - do the @ and ! variants go here or they better thought of as "Memory Words"?
Arithmetic & Logical
Conditional & Looping
Compiling Words
I/O - gets tricky here since you have terminal, file and microcontroller type I/O maybe 2 categories
COG/Propeller words
Debug/Utility Words - saveforth, words, etc.
I'm sure I'm forgetting bunches.
Any documentation is a valiant effort. I'll certainly work with you as my time permits. I probably learn better through documenting and tutorializing. I'm still learning and trying figure Forth out in all forms.
Sal pointed out that these are two different words, as propforth does NOT do things the same as regular forth due to prop archtiecture. so propforth does not have .s but instead has ST?
this is to show that it is a different set of functionality rather than an arbtrary choice of name.
Sal typically knows what he's talking about, and its his desicion to make anyway. But this illustrates how any "standard" can only be applied so far, as eventually something MUST differ from the generic case.
sometimes i write them, sometimes i read them
believe it or not, i'm not as smart as david mccallum's picture looks
thanks for doing the "hard part", using the software and sharing your results!
I just like to play with Forth for some strange reason (more socially acceptable then paying with knives or fire).
Someday I may write code that actually does something....don't wait for that day. If I can help someone use something AND actually get started on the road to productivity, it's been a good day.
How does one get PropForth to actually power up and immediately execute a program rather than go into interactive input from the serial port?
That would seem to be very handy for PropForth robot.
Nah, just get the robot to enter it's own Forth commands via the terminals keyboard:)
onreset
in propforth.htm
example is in quickstarttouchdemo in wiki downloads
sorry i couldn't leave a smarty pants reply as the answer to a ligitimate question
If I got this right, you mean for me to read about the 'onreset' word in the documentation provided in the .zip file.
DB005 polyFORTH reference manual
I always thought this was the most to-the-point reference on forth. I didnt think this was available to the general public without purchase of liscence, but it looks like its been availibe since august.
propforth has a few differences (explicite number base, no software multitasking, different CREATE, separate compile words, etc) but mostly resembles this.
I started to re-write my Forth interpreter, which I call pfth. It's pronounced like the sound of air being let out of a tire.
Currently the kernel is about 770 lines of C code. I can run it on my PC and on the Prop. When starting pfth you can specify source files on the command line, such as "pfth ansi.fth test.fth". Or you can load a source file using the include command, such as "include test2.fth". I'll post the source for pfth once I finish implementing all the ANS core words.
Brilliant name!!
I don't think PropForth is able to handle the C3 chip select out of the box. I think that was addresses in Tachyon but I don't recall it being addressed in PropForth.....I'm sure the good Professor will chime in soon if I am misleading you.
To load a .f file, you use the fload word for example in the boot.f file for gettign the HTTP server goging, at one point, it does:
fload httpserver.f
httpserver.f contains the definitions for the words implementing the http server.
You can just chain them together having one load the next or have a controlling file thet just loads them in order:
fload part1.f
fload part2.f
fload part3.f
I can't wait to see pfth!
Ron Sutcliffe started in on a stand alone C3 (vga+editor etc) but non-nerd activities suspended that effort
we should have jupiterace (vga + keyboard) in an optimized kernel shortly, but it may be easier to just write something rather than wait
What ever you come up with I would love to load on a Demo Board or a Proto Board. Different code has offers something to learn.
I suppose that one will get a larger following of users if you stick to the Propeller Proto Board as it is much less expensive and can be easily included in a finished project. It may be time for me to buy another 5 pack as what I have remaining are pretty beat up.
At first I liked the C3, but the price grew and it is indeed a rather expensive board. The new Propeller BoE is quite appealing.
I haven't yet gotten an SDcard reader in use. I have two and I want one to be used on the Propeller Demo Board as it has quite a few goodies included. But I am a bit wary of the care and feeding of SDcards. From what I understand, they prefer a FAT16 or FAT32 file system. Though they can be used in an SPI mode, at least some cards wear faster when used in this manner as the wear protection feature is bypassed.
I guess I am just wondering out loud which SDcard mode PropForth and Tachyon Forth and Pfth are committed to. I realize that I should probably just dig out the answers myself, but it is so easy to ask.
The JupiterAce will be an interesting milestone. I am not so much into retro computer aspect as I do see that the complete concept of a Forth machine will appeal to users that are not into building something from a bit of this and a bit of that.
@Prop Braino
I will take a look at PolyForth as I am beginning to see how one verison of Forth inspires features that migrate to another.
Meanwhile, both PropForth and Tachyon Forth have gotten me back into thinking deeply about the Propeller.
I presume that as long as one is using the FAT16 or FAT32 file system, the card manages its own wear protection. Am I correct about this?
I don't know about any of that, but I do know that you can add an SD very easy and cheap like this:
http://code.google.com/p/propforth/wiki/PropToSDconnection
If you do the default wireing, it includes all the pins, and should work in either mode. But propforth hasn't implemented the 4 bit mode yet, and I don't know if Caskaz ever finished the FAT support extensions, we just haven't needed them. We treat the SD as internal to the propsystem, so we really don't need to worry about FAT, just send files to the PC for that (save grey hairs).
I'm always disturbed by the "retro computer" bit. Its such an under-use of this part.
The Jupiter ACE project is finally make complete capable standalone forth system, in my mind it potentially a big deal. The original had too little memory, and was too slow. The prop version has too much memory, and it too fast. And it has two sessions of hires VGA, can control servos and read sensors.
The biggest deal is we can add as many cores as we want. Its only integer math, but I still think there is something to be said for having 100 cores for 100 dollars. The challenge that remains is how to write programs that use the prop as a pool of cores for a single number crunching task, etc.
The Jupiter ACE should not be a retro toy, but rather an inexpensive bleeding edge toy.
I am happy to hear the JupterACE project is taking shape and promises to be better than the original. That might make this question of proper FAT support more worthwhile to resolve.
I have no problem with the wiring of the micro SD card and I even purchased a couple of 2G microSDcards to use with them. (nothing smaller avaiable at the time, about $10 USD each).
But from what I recall, many people that have tried using SD cards as simple SPI storage have discovered this bypassed internal protection from excessive writes to one area. Apparently the SDcard is committted to using a MicroSoft format in order to get durability out of it.
So, one has to either create a way to rotate areas that are written to or use FAT16 or FAT32 in order to get the internal protection. Either way, it is more software than merely an SPI interface writing to blocks of SRAM. One has to have softare support of at least one file name and likely having about 8 would be better.
Bean developed a FAT formated data recording SDcard reader that I have and he managed to get into the FAT file system in a limited way. So I will try to review what he discovered to see if it is in anyway useful.
While I'd love to use my old SDcards (which are tiny in comparison to this 2Gbyte microSDcard), the Parallax reader only takes microSDcards. So I am just pondering what I want to do - get another card reader, canibalize Bean's device, or risk the 2Gbyte SDcard.
So far, it seems both PropForth and TachyonForth are NOT supporting any form of FAT16 or FAT32, and I suspect neither of you have considered managing block rotation of where files are written on a card in a purely generic SPI mode.
I guess that there is some propiretary 'magic' in how the FAT on these cards manages links to the actual blocks that keep the file data.
In the forth dictionary, if you use the same identifier over again, the previous definition is covered up, and effectively the most recent definition is the only one. Except memory is consumed by the old definition. Doing a saveforth re-writes the dictionary, and the old definition is ignored, and the memory is recovered.
SAME THING WITH SD. When you write a file to SD, it occupies a specific contiguous set of blocks. And you can read and rewrite those exact blocks (sectors) all day long. [Now I have to to check if this is still like this, I haven't been in there for a bit BUT...]
If you reload a file using the same name, the old file is still there, but now the name is associated with a new start location. SO THE WAY BLOCK ROTATION IS MANAGED is we just write to the files' blocks for a while; when we want to REALLY change the file (for example adjust the size), it moves to a new location, and the old location is implicitly "taken out of service".
Oh, no! those N blocks of space are lost! Wait a second! You have a million pages. How soon until you run out of space? Who cares? Just re-initialize the card, and start over once in a while. Or buy a new card they are cheap. Basically, the user is responsible for managing block rotation if it is ever an issue, but the block rotation is passively managed by not doing garbage collection.
Forth is not an OS so this kind of overhead is not required, and it would only get in the way most of the time. IF you really need FAT support, and file management, and block rotation, by all means write the extension. I will be grateful and use it too. BUT as an extension, only to be loaded when someone actively decides to take to effort of spending the memory and speed on that extension. consider that it has not been needed, and it has not been missed. By considering this in the design of our apps, we can save tons of overhead and preserve speed, determinism, etc; and it will still Look like an OS a large part of the time.
So far, we have not yet run out of space, and we have not detected a failure. Sal designed this for high speed logging of massive data streams, and the stuff he has running in his bench is doing just that. No problems so far, since 5.0 came out.
FAT is handy if you need to use an SD on a windows PC, but unnecessary outside the context of the PC.
The short story is that there is a perfectly good OBEX object for FAT16/32 available. And it even has additional support for real time clocks to time and date stamp -- though it can be run without. All this will cost a Cog if it can be accommodated. And it would put your JupiterACE into the JupiterACE_Supreme category.
I realize I am being argumentative and compelling. I am quite happy to bump along with EEPROM images, but if you are going to exploit the SDcards - I suggest you don''t do it halfway.
Take a good look at Parallax Semiconductor's AN006 and consider if it hasn't done much of the work for you.
http://www.parallaxsemiconductor.com/an006
I have no problem with how 'saveforth' operates. I just will not use SDcards if they repeatedly fail when used in PropForth. Above all, I am in no rush for such a thing as I have plenty to learn about PropForth as it is.
I apologize for seeming pushy on this point. But I feel it is best for all. But of course, I may be asking for something that is just not possible for reasons unknown to me.
Respectfully,
I don't believe this is true.
When you write a block to an SD card you use a block number to specify it. But that may not be the block number of the actual physical storage on the SD card. The SD card has a processor of it own to map logical blocks to physical blocks. Also the SD card has more physical blocks than advertised. It can use those extra blocks in it's wear levelling efforts,
I suspect that when you write a logical block number L it will end up somewhere on the physical store as block number M1 and M1 is marked as
"allocated" or "used" by the SD card internally. If you now overwrite logical block L1 it may well result in being written to different physical block M2 which is also marked as "allocated" or "used" and perhaps the old M1 is now "unallocated" and free for use. In this way blocks are rotated around and wear levelling takes place.
But consider this: What if I now delete a file that contains logical block L?
My file system will rearrange things to make L a free files system block, perhaps by fiddling with directory entries and other FS data structures. But,
and here us a big BUT, the SD card knows nothing of your file system, just because you have unlinked that block and returned it to your free space pool in your FS doe snot mean that the SD now thinks it's free. So actually the SD card fills up with allocated blocks and run out of space even though there is tones of it according to the FS.
For this reason SD cards have a TRIM command to explicitly tell them that a block is no longer in use by the files system and can be used again for further file allocations and wear levelling.
Linux has a command "fstrim" that does exactly this. I have no idea if your Android phone or camera or whatever does this. I don't believe this is true either. Whilst SD cards are FAT formatted out of the box there are plenty of systems running Linux from SD card with a variety of different file systems quite happily. And as I said the SD card itself knows nothing of you file system.
Perhaps we need an FST trim function for the Propeller.
I'd love to find links for you that explain all this but it seems to be very hard info to find and SD manufactures do not shout about their wear levelling tricks. Perhaps Kye or some other FS expert could fill us in on this.
What you have done for file storage is rude and crude and OS people may hate it.
However I have often though about this myself. With two things in mind:
1) Having a FAT or other proper files system on the Propeller takes up a huge lot of valuable HUB space. Would be great to get that down to something more reasonable.
2) We have gigantic amounts of space on SD cards, at least from the point of view of pretty small and slow systems like the Propeller.
So I come to a similar conclusion to yourself. Let's not worry about wasting SD space instead think about the simplest possible way to get named files onto an SD with the smallest amount of code space in the Prop. I would not even worry about supporting directories. After all the CP/M file system was tiny compared to what we have for FAT on the Prop.
That's the nicest thing I've heard all day! (Its morning here)
Sal wrote a test that just logs time and data and sensor data (temp or baro? I forget) to SD as fast as it can go. Its been running for months and has not run out of room and has not caused a failure. We're waiting to get a data point on something actually breaking.
If we talk to caskaz, I'm sure he would re-start his work on a FAT extension for SD in propforth. Sal doesn't see any point, and doesn't want folks (like you and me) to think it is actually necessary for anything, except to be compatible with an inappropriate solution. Instead, we send "file" data to the PC and let the PC handle it, since the PC is the one worried about it in the first place. Again, if we wish to do this on the prop, its (relatively) easy, but at a high cost of dictionary and speed.
The killer feature of having FAT on an SD is that the card can be popped into a Windows PC and read/written easily there.
Not being one to care about the inadequacies of Windows I don't see why this problem has to be projected down into our little micro controllers.
If we can create a rude and crude files system (RCFS) on the Propeller we can probably create a simple program to read/write it from Linux quite easily. This is already done for CP/M format file system images with cpmtools.
We have different constraints and freedoms than when FAT was invented, disk space we can waste, code space we cannot.