I tested 2-eeprom too.
1st eeprom 0x0-0xffff, 2nd eeprom 0x10000-0x1ffff
Line93 8000 --> 8000
Line94 10000 --> 20000
Just to check the math (I'm not good with hex),
End of RAM: 32K - 8000(h)
Start of 64K EEPROM: 8000h
[only 32k 8000h free EEPROM due to over lap with RAM]
End of 64K EEPROM1: 10000h
[End at RAM end + 32k; this is previous value for line 94]
beginning of 64k EEPROM2: 10000h
end of EEPROM2: 20000h [64k + 64k]
So the constant that holds EEPROM address has to be manually changed for new EEPROM size?
That is good work. I'll put this in the documentation.
It seems that WORD"(fsfree)" find out first location in file system.
I think it needs [80000 wconstant fstop] if 8-eeprom(24LS512) .
Sorry,I don't understand well fs.f yet.
It seems that WORD"(fsfree)" find out first location in file system.
I think it needs [80000 wconstant fstop] if 8-eeprom(24LS512) .
Sorry,I don't understand well fs.f yet.
That look right:
1 0000 h = 65,536(d)
so
8 * 1 0000 h = 8 0000 = 524,288(d)
So that's a lot of bytes for text files.
Thanks caskaz!
Did you think about combining the EEPROM file system and your SD work?
For example, make one file that is the same size as the EEPROM and access it using similar words are the EEPROM words? I don't know off hand what would be simplest. It would be really handy if we could read the SD card on the PC and access it from forth with simple words.
End of RAM: 32K - 8000(h)
Start of 64K EEPROM: 8000h
[only 32k 8000h free EEPROM due to over lap with RAM]
End of 64K EEPROM1: 10000h
[End at RAM end + 32k; this is previous value for line 94]
beginning of 64k EEPROM2: 10000h
end of EEPROM2: 20000h [64k + 64k]
So the constant that holds EEPROM address has to be manually changed for new EEPROM size?
That is good work. I'll put this in the documentation.
Thanks caskaz!
I made the change to fs,f, won't have time to test until late tonight or tomorrow. TNX Caskaz
I'm going to make sd_loader.
My idea is that sd_loader load from SD into ram.
At first I tested sd_viewer(modified for PropForth4).
But "out of memory" because Word"fl" is very different to PropForth3.5.
Free area for PropForth4 also is smaller than PropForth3.5.
... sd_loader... load from SD into ram.
sd_viewer(modified for PropForth4). But "out of memory" because Word"fl" is very different to PropForth3.5.
Free area for PropForth4 also is smaller than PropForth3.5.
You can choose keep the core minimal and skip parts of propforth.f.
But the real goal is to define the minimum functions needed to excercise the SD, very small. Then have a second layer for the user interface and fancy stuff, also very small. Of course there is a minimum for all the basic functions, finding this is the puzzle. If you can decide what is the minimum set of functions your LCD system needs, maybe you can reduce the kernel to make room for you app. .
An alternative is to have one prop dedicated to storage and memory access, and another prop for the rest of the application, there are several examples of multi-prop solutions that use this approach. But I'm not far enough along and don't know the particulars.
caskaz brought up that the extended kernel is getting bigger, and my reply was to not load the propforth.f extensions.
But what good is that if you need the propforth.f extension, AND lots of other stuff?
This is where the discussion turn to the colorforth model.
Eventually, the app gets too big, and we run out of memory. This is true on any processor, we notice it a littl earlier (at 32k) on the prop.
There are several ways to proced. One is with a memory extender software like LMM (check reference add link).
Another is to limit the size of the kernel in the first place and stil do everything that you want.
The second method what we see in colorforth. The first method is being explored in other investigations on the prop, so we don't need to cross that ground at the moment. The eventually we hope to have both solutions as an option.
So how does colorforth magically keep the kernel small and provide every possible needed function? The trick is that we take advantage of forth's interactive comppiler. We decide the absolute minimum words that need to be in the kernel and application. EVERYTHING ELSE is complied on the fly, and after it does it's job, it is RELEASED FROM MEMORY.
Words can more or less be classified as permenant (kernel) or transient (application).
So the structure of non-permenet words is
This way you can make any function the full sive of the available (non-core) memory, but not tie up all your resources.
This is not the best option for all cases. I don't know of any off hand, but at some point the memory extender technique will be used.
I invite you guys to try one option and discuss the other. Sal is considering the colorforth model. I was thinking th SD material may in some part be a candidate.
I think both forks should be pursued, BUTTTTTT. I hope that the 'colorforth' model is not handled just as a 'crutch' until the expanded memory ideas are fleshed out. You guys have done incredible stuff already on 32K limits making it actually viable. This option should be pursued vigorously so that newbies can 'get their feet wet' on existing hardware they already have AND so heavyweights can take fat code like propforth.f and slim it down to run a highly specifc app on a lean piece of hardware.
Back on the flie load documentation subject. Last night, in the wee hours of the morning, I loaded up three other boards, all different, all ultimately successful (some took multiple tries) I believe I understand the process of what to do and, more importantly, what not to do as well as when to sit on your hands! I will start the writeup later today and I will have a first cut by the morning.
I think both forks should be pursued, BUTTTTTT. I hope that the 'colorforth' model is not handled just as a 'crutch' until the expanded memory ideas are fleshed out. You guys have done incredible stuff already on 32K limits making it actually viable. This option should be pursued vigorously so that newbies can 'get their feet wet' on existing hardware they already have AND so heavyweights can take fat code like propforth.f and slim it down to run a highly specifc app on a lean piece of hardware.
Exactly, please keep open mind
Others have found extended memory is the "crutch" and on the fly compile and release is "better faster cheaper". Of course it all subjective and you get decide. I won't go either way till see the results data
I don't see xmem being that important in the scheme of things. It will find its place for manipulating large blocks of data, text editing and streaming data for VGA for example, but not for extending the Forth dictionary.
Re-colorForth...for what its worth
The propforth.f file includes many words which are nothing more than helpers. They could be moved to lib files. I am thinking of words like pinh pinx? delms etc etc... HUB memory is at a premium and remember, the bigger the directory the longer interpret takes to return some tokens towards the beginning of the dictionary . More importantly it becomes increasing difficult to find a reason to remove these words once they become part of a developer's code.
These words could be moved into libaries. eg Proplib, SDlib, VGAlib, TVlib, VTLib, XmemLib etc leaving propforth.f containing only the forth words needed to support the lib files. It makes for easier management, a reasonable approach now that caskaz is getting the Fat16 together.
Re-colorForth...for what its worth
propforth.f file includes ... helpers. They could be moved to lib files.
I am thinking of words like pinh pinx? delms etc etc...
the bigger the directory the longer interpret takes to return some tokens towards the beginning of the dictionary .
More importantly it becomes increasing difficult to find a reason to remove these words once they become part of a developer's code.
These words could be moved into libaries. eg Proplib, SDlib, VGAlib, TVlib, VTLib, XmemLib etc leaving propforth.f containing only the forth words needed to support the lib files. It makes for easier management, a reasonable approach now that caskaz is getting the Fat16 together.
Ron
Xmem is important to the people that like to use it. Sometimes its the only way, sometimes its just comfortable.
All words in propforth.f are helpers, ie not mandatory in kernel. pinAA words are only important when you want to use pins. delms is only when you want to delay a specific number of milliseconds. Which is all the time. This is why we are considering the technique of loading them on the fly, and forgetting them on the fly.
Reading source from EEPROM (or SD), compiling on the fly, and forgetting the definitions after they have served their purpose is functionally equivalent to managing executable code in extended memory and swapping it in and out of hub memory. The technique is slightly different but the same end is achieved. The difference is that the latter solution is well known and requires additional hardware (the memory chips), and additional software (the extended memory manager). The alternative being considered does not require additional hardware (the EEPROM is already there, and SD will be soon) and does not require additional software (the interpreter is already there). So the hardware should be cheaper, and thee software should be simpler and therefore potentially faster.
Dictionary size only impacts speed only during compilation; but for execution, compilation from memory versus compiled into the dictionary are about the same (at least it takes the same amount of time when I press enter until I see the result). . Displaying compilation on the screen is what takes time, as it is limited by 57600 baud rate. If we notice on the fly compilation to be too slow for any reason, we can always to something else.
This issue does NOT involve removing helper words from developers code. The technique is to write modular code so that code does not have to be resident in its entirety when it is not needed. This has been demonstrated very effective in the colorforth discussions. So we might give it a try. You are free to do what ever you wish, of course, this is just a direction that is being considered.
I think the thing you mean when you talk about lib files is the same as colorforth, the only difference is colorforth is (supposed to be) at a much simpler level, and potentially smaller and faster. But we don't know until we make some code and do some experiments.
So I think we agree on all points, with only some terminology being different.
Prof
Compile (docolon) is not affected by the dictionary size for the reasons mentioned below (no linked listas such). We don' t care about compile time, we are more interested in the " interpret - execute " cycle.
The word "interpret" fetches a words from the directory. Strickly speaking the word "execute" does not change as a result of directory size., It may sound tivial but every word that is processed by exicute is returned by interpret, Hope that makes sense. SAL's propforth dictionary sructure is not that much different than other Forths ( no code pointers)
Helpers are great for readabilty but slow processing down (more words to find). I like the word [if its a step in right direction
Here is my first cut, its about half done, and rough. I offer it in solicitation of comments, corrections, criticisms, etc ... its flat text with paragraphs as long lines. My regular email address is at the top of the file, I would prefer feedback by regular email
Here is my first cut, its about half done, and rough. I offer it in solicitation of comments, corrections, criticisms, etc ... its flat text with paragraphs as long lines. My regular email address is at the top of the file, I would prefer feedback by regular email
Comments
I tested 2-eeprom too.
1st eeprom 0x0-0xffff
2nd eeprom 0x10000-0x1ffff
Rename fs.f to 10_fs.f.
Editting 10_fs.f.
Line93 8000 --> 10000 <--- Sorry, 8000 still is ok.
Line94 10000 --> 20000
Loading 10_fs.f.
fsls
008000 002272 propforth.f
00A280 000E77 LogicAnalyzer.f
00B140 0020CE asm.f
00D240 000D0F norom.f
00DF80 001426 com.f
00DF30 000221 comnorom.f
00F600 000112 snet.f
108C0 bytes free infilesystem
Prog0 Cog6 ok
Copy/paste propforth.f to Teraterm.
fsls
008000 002272 propforth.f
00A280 000E77 LogicAnalyzer.f
00B140 0020CE asm.f
00D240 000D0F norom.f
00DF80 001426 com.f
00DF30 000221 comnorom.f
00F600 000112 snet.f
00F740 002272 propforth.f
E640 bytes free infilesystem
Prog0 Cog6 ok
Just to check the math (I'm not good with hex),
End of RAM: 32K - 8000(h)
Start of 64K EEPROM: 8000h
[only 32k 8000h free EEPROM due to over lap with RAM]
End of 64K EEPROM1: 10000h
[End at RAM end + 32k; this is previous value for line 94]
beginning of 64k EEPROM2: 10000h
end of EEPROM2: 20000h [64k + 64k]
So the constant that holds EEPROM address has to be manually changed for new EEPROM size?
That is good work. I'll put this in the documentation.
Thanks caskaz!
It seems that WORD"(fsfree)" find out first location in file system.
I think it needs [80000 wconstant fstop] if 8-eeprom(24LS512) .
Sorry,I don't understand well fs.f yet.
That look right:
1 0000 h = 65,536(d)
so
8 * 1 0000 h = 8 0000 = 524,288(d)
So that's a lot of bytes for text files.
Thanks caskaz!
Did you think about combining the EEPROM file system and your SD work?
For example, make one file that is the same size as the EEPROM and access it using similar words are the EEPROM words? I don't know off hand what would be simplest. It would be really handy if we could read the SD card on the PC and access it from forth with simple words.
I made the change to fs,f, won't have time to test until late tonight or tomorrow. TNX Caskaz
I'm going to make sd_loader.
My idea is that sd_loader load from SD into ram.
At first I tested sd_viewer(modified for PropForth4).
But "out of memory" because Word"fl" is very different to PropForth3.5.
Free area for PropForth4 also is smaller than PropForth3.5.
You can choose keep the core minimal and skip parts of propforth.f.
But the real goal is to define the minimum functions needed to excercise the SD, very small. Then have a second layer for the user interface and fancy stuff, also very small. Of course there is a minimum for all the basic functions, finding this is the puzzle. If you can decide what is the minimum set of functions your LCD system needs, maybe you can reduce the kernel to make room for you app. .
An alternative is to have one prop dedicated to storage and memory access, and another prop for the rest of the application, there are several examples of multi-prop solutions that use this approach. But I'm not far enough along and don't know the particulars.
TNX Caz and Braino ...
caskaz brought up that the extended kernel is getting bigger, and my reply was to not load the propforth.f extensions.
But what good is that if you need the propforth.f extension, AND lots of other stuff?
This is where the discussion turn to the colorforth model.
Eventually, the app gets too big, and we run out of memory. This is true on any processor, we notice it a littl earlier (at 32k) on the prop.
There are several ways to proced. One is with a memory extender software like LMM (check reference add link).
Another is to limit the size of the kernel in the first place and stil do everything that you want.
The second method what we see in colorforth. The first method is being explored in other investigations on the prop, so we don't need to cross that ground at the moment. The eventually we hope to have both solutions as an option.
So how does colorforth magically keep the kernel small and provide every possible needed function? The trick is that we take advantage of forth's interactive comppiler. We decide the absolute minimum words that need to be in the kernel and application. EVERYTHING ELSE is complied on the fly, and after it does it's job, it is RELEASED FROM MEMORY.
Words can more or less be classified as permenant (kernel) or transient (application).
So the structure of non-permenet words is
This way you can make any function the full sive of the available (non-core) memory, but not tie up all your resources.
This is not the best option for all cases. I don't know of any off hand, but at some point the memory extender technique will be used.
I invite you guys to try one option and discuss the other. Sal is considering the colorforth model. I was thinking th SD material may in some part be a candidate.
Your thoughts?
Others have found extended memory is the "crutch" and on the fly compile and release is "better faster cheaper". Of course it all subjective and you get decide. I won't go either way till see the results data
Re-colorForth...for what its worth
The propforth.f file includes many words which are nothing more than helpers. They could be moved to lib files. I am thinking of words like pinh pinx? delms etc etc... HUB memory is at a premium and remember, the bigger the directory the longer interpret takes to return some tokens towards the beginning of the dictionary . More importantly it becomes increasing difficult to find a reason to remove these words once they become part of a developer's code.
These words could be moved into libaries. eg Proplib, SDlib, VGAlib, TVlib, VTLib, XmemLib etc leaving propforth.f containing only the forth words needed to support the lib files. It makes for easier management, a reasonable approach now that caskaz is getting the Fat16 together.
Ron
Xmem is important to the people that like to use it. Sometimes its the only way, sometimes its just comfortable.
All words in propforth.f are helpers, ie not mandatory in kernel. pinAA words are only important when you want to use pins. delms is only when you want to delay a specific number of milliseconds. Which is all the time. This is why we are considering the technique of loading them on the fly, and forgetting them on the fly.
Reading source from EEPROM (or SD), compiling on the fly, and forgetting the definitions after they have served their purpose is functionally equivalent to managing executable code in extended memory and swapping it in and out of hub memory. The technique is slightly different but the same end is achieved. The difference is that the latter solution is well known and requires additional hardware (the memory chips), and additional software (the extended memory manager). The alternative being considered does not require additional hardware (the EEPROM is already there, and SD will be soon) and does not require additional software (the interpreter is already there). So the hardware should be cheaper, and thee software should be simpler and therefore potentially faster.
Dictionary size only impacts speed only during compilation; but for execution, compilation from memory versus compiled into the dictionary are about the same (at least it takes the same amount of time when I press enter until I see the result). . Displaying compilation on the screen is what takes time, as it is limited by 57600 baud rate. If we notice on the fly compilation to be too slow for any reason, we can always to something else.
This issue does NOT involve removing helper words from developers code. The technique is to write modular code so that code does not have to be resident in its entirety when it is not needed. This has been demonstrated very effective in the colorforth discussions. So we might give it a try. You are free to do what ever you wish, of course, this is just a direction that is being considered.
I think the thing you mean when you talk about lib files is the same as colorforth, the only difference is colorforth is (supposed to be) at a much simpler level, and potentially smaller and faster. But we don't know until we make some code and do some experiments.
So I think we agree on all points, with only some terminology being different.
Thank you Brian this will be a big help. I have been very slow getting this releases documentation squared away.
Compile (docolon) is not affected by the dictionary size for the reasons mentioned below (no linked listas such). We don' t care about compile time, we are more interested in the " interpret - execute " cycle.
The word "interpret" fetches a words from the directory. Strickly speaking the word "execute" does not change as a result of directory size., It may sound tivial but every word that is processed by exicute is returned by interpret, Hope that makes sense. SAL's propforth dictionary sructure is not that much different than other Forths ( no code pointers)
Helpers are great for readabilty but slow processing down (more words to find). I like the word [if its a step in right direction
Ron
I entered brian's instructions into the wiki
http://code.google.com/p/propforth/wiki/PropForth4BrianRiley
I also added some notes to complete the end. Please give feedback directly to Brian or here.
Brian, would you like to edit the page directly, or have changes go thru me?
Propforth 4.0a is now available see thread
http://forums.parallax.com/showthread.php?128055-Propforth4.0a-available-for-download&p=961860#post961860
New version has corrections to typos, is reorganized, includes examples for less than 32K EEPROM