Does PropForth 4.0 require multiple props?
Can I just use PropForth 4.0 on a spinneret, or a protoboard by itself?
I would rather not have to do any wiring in order to get started.
A couple people asked about this already
Propforth4.0 does NOT require multiple pros BUT
the instructions are centered around the multiple prop set-up and tests.
ALSO the set-up as posted assumes the protoboard and a 64k EEPROM for the file system.
The core will run on a demo board, and the extensions can be added, but adjustments have to be made for the demo board's 32k EEPROM.
So I 'm going through today and making updates and figuring out how to handle the diferences between the 32k EEPROM which cannot use the fs.f and the current posted package which relies on the 64k EEPROM and fs.f
PM me with specific questions if you don't want to wait for the update to be posted
@Hinv
Q1. No single prop is Ok
Q2. Yes, you can use Forth on protoboard or any prop board for that matter providing the eeprom is 64K. You can get away with 32K eeprom at a pinch with Propforth rev 3.5
Providing you set the xtal, if it differs from 5MHZ (5MHZ is the default) and that you set the RX/TX pins to suit your board config normally P31 and P30 in Propforth.spin file before downloading.
You can get away with 32K eeprom at a pinch with Propforth rev 3.5
I would request that folks try to stick with the current release if at all possible. The earlier releases are no longer supported, and are superceded by the newer releases because they were found to be lacking in some way.
V4.0 like all previous version is designed to run on any prop chip, its the variance in external EEPROM size that we ned to pay attention to.
This V4.0 version is highlighting the EEPROM file system, which unfortunately does not play well in the 32k EEPROM, but can be made to work (if you really understand it and want to be really careful, which is possible by not tangental to the current focus at this time).
If anybody is stuck because they only have access to a demo board please post or PM me. Otherwise if you can use a proto, schmart, or Pro Dev board, that would be least strain on the braino.
Prog0 Cog6 ok
cominit comstat
C9 0 E7 0
Prog0 Cog6 ok
cominit comstat
E9E18 0 E9E4B 13EC
......
RESET Prop0 Cog6 ok
fsload com.f - - - loading cominit and comstat
Prog0 Cog6 ok
cominit comstat
1D449 0 1D47E 0
Prog0 Cog6 ok
.....
Prog0 Cog6 ok
comstat
7BC88 0 7BCBD 0
Prog0 Cog6 ok
The first time you appear to have gotten something wrong, possibly a loose wire, and registered a lot of errors.
After the reset, the channels are working, counting packets and no errors.
You have success! Omedito-gozimasu!
The channel between master prop chip and slave prop chip is working. The rest of the example (which I haven't done on 4.0 but ran successfully on 3.6) shows how to switch between cogs on master:
Master0 Cog4 Ok (0-4 are available on master I think)
and cogs on the slave:
SlaveN Cog9 (0-6 are available I think; slave cogs are numbered 8-15 on first slave)
The Problem with REV 4.00 is that the I/O pins 31 and 30 are not easily reasigned. This hampers the development of drivers which use these pins.
Hydra and Ramblade for example use these pins for Xmem once programmed. I am not sure about the new Dram boards but I can see this being a problem I hope its not too late to revisit this issue.
The first time you appear to have gotten something wrong, possibly a loose wire, and registered a lot of errors.
I think hardware has no problem.
reboot
fsload com.f
Loading cominit and comstat
Prop0 Cog6 ok
cominit
Prop0 Cog6 ok
comstat
352F2 0 35327 0
Prop0 Cog6 ok
comstat
5AAEA 0 5AB20 0
Prop0 Cog6 ok
comstat
8C713 0 8C748 0
Prop0 Cog6 ok
cominit comstat
E440D 0 E4441 13ED
Prop0 Cog6 ok
cominit comstat
No reply
I read source code about iochannel.
I have question.
io-channel of each cog has 32byte from data area for each cog.
For example, cog6 has data-area from 0xAB8 to 0xB97.
io-channnel of cog6 occupy datas from 0xAB8 to 0xAD8.
each io-channel(0 - 7) has 4byte.
But debugcmd use from 0xABE to 0xABF. Other cogdata(debugvalue base coghere execword >out >in pad) also has data until 0xAD8.
io-channel and cogdata(debugcmd debugvalue base coghere execword >out >in pad) is overlapping...
The Problem with REV 4.00 is that the I/O pins 31 and 30 are not easily reasigned. This hampers the development of drivers which use these pins.
Hydra and Ramblade for example use these pins for Xmem once programmed. I am not sure about the new Dram boards but I can see this being a problem I hope its not too late to revisit this issue.
Ron
Sorry Ron, I think you mis-understand.
4.0 is centered around the example of re-assigning the I/O pins. In this case, we use 29 and 28 to emulated EEPROM in the slave, and then use them for the MASTER/SLAVE high speed synchronous serial channel.
The pins 31 and 30 are used for standard serial communications, and propforth uses these pins by default to communicate with the command prompt. this allows interactive development, which is sometimes considered an advantage. You could re-assign the serial to other pins, as shown in the example where a new asynchronous serial channel is established on pin 0 and 1 of the master to pins 30 & 31 of the slave. But to talk to the propchip over serial using a terminal program, we just leave it on 30 & 31 since there is already dedicated hardware installed and we never waste parts if we can help it.
So, you can do whatever you want with your specific hardware, and it will be no problem. I would question why you would waste either A) a perfectly good serial chip or the ability to develop interactively from the PC.
If your hardware has keyboard and display like the demo board and you no longer need serial at all, then no modification is needed, please see the High-Res and Low res-VGA examples. Also see the HIVE project.
We don't had a Ramblade. The HIVE guys sent us boards and specifically ask propforth to be ported to it. Porting to Ramblade should be easy with hardware in hand. (Hint Hint send me a spare? For Xmas???)
But unless I missed something, the comment is a non-issue, I think it already does exactly what you asked.
Prof
No, you are not missing anything, I just need to sit down and work throught the propforth.spin 4.00.
I will finish off the Xmem lib routines and test them on Rev 4.00. I have a HX512 hydra card and will look at xrd and xwr words for that card later. The xwr and xrd words are the only two routines that are hardware dependant.
FYI My case Ramblade will operate as a slave and handles Xmem and SDcard functions only.
I think I got it figured out. Here's how to do the multi - prop example per Sal's instructions using the EEPROM file system:
1) We need to load propforth.spin using proptool
2) To use the EEPROM file system method you need to load into teraterm:
fs.f
propforth.f
com.f
norom.f
comnorom.f
3) At this point, only fs.f was loaded into the dictionary, the other are SOURCE in EEPROM.
NOW we need to load the source into the dictionary using:
fsload propforth.f
fsload com.f
fsload norom.f
fsload comnorom.f
Make sure the text scrolls as each file is loaded,
4) do saveforth
reboot
Here's how to do the multi - prop example WITHOUT the EEPROM file system:
1) We need to load propforth.spin using proptool
2) EDIT the following files and comment out:
a) the line(s) with fswrite at the top of the file
b) the line with ... at the bottom of the file
c) the lines fsload in comnorom.f
I'm trying to update the instructions with the material in posts #72 and #73 to make them clearer.
Once through it its really obvious but the first eight or so times I could not figure it out at all.
Post or PM me if anybody is still stuck and I'll try to make the instructions better.
@Braino - you seem to be doing all this under the blind assumption that the whole world of PropForth is populated by serfs on the Redmond estate ... I am doing this with an iMac running OSX 10.6.5 and BST, and using Zterm .... PLEASE be a little more generic in your descriptions of loading into the file system ... TNX
I'm cofused about this.
"5 2 term" mean that connecting (current cog_number n iochannnel 0) to (cog_number 5 iochannnel 2)?
I'm wrong?
Channel means slave?
What is channel?
term in com.f below:
:term \ [n1 n2 -- ]
over \ [n1 n2 n1] <-- status on stack
cognchan \ [n1 n2 (number of io-channel for cog_n1) ]
min \ [n1 A] (A is smaller on n2 and number of io-channel for cog_n1) <-- I can't understand this part well.
>r >r \ push datas on stack
cogid \ get current cog number(n)
0
r> r> \ pop datas to stacke [n 0 n1 A]
(iolink) \ cog_n channel_0 connect to cog_n1 channel_A
begin
key dup 6 =
if
drop 1 \ if 6, quit
else
emit 0
then
until
cogid \ get current cog number(n)
iounlink \ disconnect cog_n
;
@Braino - you seem to be doing all this under the blind assumption that the whole world of PropForth is populated by serfs on the Redmond estate ... I am doing this with an iMac running OSX 10.6.5 and BST, and using Zterm .... PLEASE be a little more generic in your descriptions of loading into the file system ... TNX
Sorry partner, don't know what you are asking.
If you have a terminal program similar to teraterm, and can paste text into the screen rather than typing, the above is written for that. PM me to explain the differences and I'll adjust accordingly.
Prop0 Cog6 ok
cominit comstat
E440D 0 E4441 13ED
Prop0 Cog6 ok
about iochannel...I have question.
io-channel and cogdata(debugcmd debugvalue base coghere execword >out >in pad) is overlapping...
I think my understanding is wrong. What am I wrong?
1) The output of comstat is XmitPackets XtmitErrors RecvPackets RecvErrors
So you have errors in the packet communications. If its not the hardware, it is something else.
2) io-channel: I haven't gotten in that deep yet, sorry. Can you post an issue in google code?
Ask it as a question and Sal can fix it or explain it.
Sorry partner, don't know what you are asking.
If you have a terminal program similar to teraterm, and can paste text into the screen rather than typing, the above is written for that. PM me to explain the differences and I'll adjust accordingly.
Zterm and TeraTerm for the most part are twins ... at times you have mentioned speed and the danger of overrunning the input (loading the LogicAnalyzer.f comes to mind), but there's been little discussion of paced text file sending vs pasting ... I can only assume that TeraTerm offers this. Maybe the setup docs need a preface where the mechanics of file loading is discussed, what, how, why, and what to look for as indicators of success/failure. I'd be willling to write it.
The cut from a plain text editor and paste to the Terminal has always been the method used even going back to the days Cliff''s PropellerForth. In those days it was a bit hit and miss, but its very solid now.
For rev 3.5 its helps to add a short delay (2ms) for line feeds,Teraterm allows this in the set up.
Hopefully with a text Editor and Fat16 system SDcard system things will change, but there is nothing wrong with the system as it stands.
Zterm and TeraTerm ... twins ... speed ... overrunning the input ... paced text file sending vs pasting ... I'd be willling to write it.
Here's what I got:
fl - (fast load) at the top of the file is for pasting more than 80 characters of text. If you use it, it works, if you don't it overruns.
Paced Text - 0 ms for characters, 0 ms for lines
Text files sending - not supported / I haven't figure out a way to make it work
Notes:
More than 80 character in the input buffer causes overrun after approx. 3rd semi colon - there is a slight delay when the definition is committed to the dictionary,
fl - (fast load) buffers the input text stream into unused memory. In 4.0, one cog puts the input stream into memory, another compiles it into the dictionary and returns the memory to free memory.
I'm supposed to update all the docs, but I'm behind (and in hurry to post this now)
Hope this helps, we'll get it nailed eventually.
Another note: in earlier versions, the comment character \ would cause the CR-LF line terminator to be ignored and never reach the interpreter, so you needed a blank line after an in-line commented line. Sal said he would take a look at it, but I haven't had a chance to check this yet. If you get weird error messages when loading chunks of text with in-line comments, its probably not fixed yet. Probably not worth addressing until SD and text editor are in place. Is this the issue you are having? Sorry, its just awkward until the SD/editor material is implemented
Another note: in earlier versions, the comment character \ would cause the CR-LF line terminator to be ignored and never reach the interpreter, so you needed a blank line after an in-line commented line.
How does PropForth handle line ending? Does it explicitly want CR-LF? What does it do if it gets CR only, or LF only as some non-DOS derived files might have?
I take a Propeller Platform USB with a single 24LC512 and it loads up OK.
1 - use BST to load PropForth.spin
2 - use Zterm to load fs.f
3 - execute fslw and get
Prop0 Cog6 ok
fsls
8000 bytes free in files system
Prop0 Cog6 ok
... and everything else seems to load OK
Now, take an original Propeller Platform with 2 24LC512 (addressed 0 and 1) and
do the same thing and you get
Prop0 Cog6 ok
fsls
008000 00B400 o/DPT67#=667#6m00B4008
fsls
-3500 bytes free in files system
Prop0 Cog6 ok
and then try to load PropForth.f and it blows with
[code]
Prop0 Cog0 ok
\ image>ee ( n1 - n16 addr -- ) writes the 16 longs on the stack to the addr in eeprom
Prop0 Cog0 ok
Prop0 Cog0 ok
[if image>ee
Prop0 Cog0 ok
Prop0 Cog0 ok
: image>ee >r pad 3C + 40 0 do swap over i - L! 4 +loop drop r> pad 40 eewritepage if 8003 ERR then padbl ; ]
Prop0 Cog0 ok
Prop0 Cog0 ok
Prop0 Cog0 ok
Prop0 Cog0 ok
Prop0 Cog0 ok
Prop0 Cog0 ok
...
UNDEFINED WORD ...
Prop0 Cog0 ok
[/code]
as far as I can tell almost all of PropForth.f went directly to the dictionary and not to the EEPROM fs.
I think we have a problem with EEPROM ....
a single 24LC512 and it loads up OK.
1 - use BST to load PropForth.spin
2 - use Zterm to load fs.f
3 - execute fslw and get
fsls
8000 bytes free in files system
Prop0 Cog6 ok
Now, take an original Propeller Platform with 2 24LC512 (addressed 0 and 1) and
do the same thing and you get
[code]
Prop0 Cog6 ok
fsls
008000 00B400 o/DPT67#=667#6m00B4008
...
UNDEFINED WORD ...
as far as I can tell almost all of PropForth.f went directly to the dictionary and not to the EEPROM fs.
Could you enter an issue report in google code site? I don't have that hardware and don't know much about eeproms
(32K is demo board and 64k is protoboard is the boundry of my knowledge)
Just to check:
fl -- (fastload) was at start of file?
fswrite propforth.f -- was after fl before start of source?
... -- was at end of file?
One more thing:
Propforth use to terminate lines with CR+LF, but that made too many blank lines in the telnet output.
This time Sal tried to make all i/o consistent, now the terminal program only needs CR.
I don't know if this affects your issue, but its something related that changed.
I'm trying to keep organized, which is always problematic for a braino.
Would it be OK if I post your ID and what tasks you are working on? Either here on the forums or on the propforth page?
What I really want to do is organize
- testing of the kernel (I can't get to it very quickly)
- review of the documentation (It's still abysmal, not enough feedback)
- provide testing for your development (extra eyes sometimes always help)
I know everybody possibly has a life and little time for playtime, and might not be as fanatical as others, but if you are interested, it would be a big help.
Also, you can PM me if you are shy and have not posted yet.
Could you enter an issue report in google code site? I don't have that hardware and don't know much about eeproms
(32K is demo board and 64k is protoboard is the boundry of my knowledge)
Just to check:
fl -- (fastload) was at start of file?
fswrite propforth.f -- was after fl before start of source?
... -- was at end of file?
One more thing:
Propforth use to terminate lines with CR+LF, but that made too many blank lines in the telnet output.
This time Sal tried to make all i/o consistent, now the terminal program only needs CR.
I don't know if this affects your issue, but its something related that changed.
Yes to all the 'checks'
1 - the problems manifest before I even tried PropForth.f. The code (PropForth.spin plus fs.f) obviously recognized that the second 64K EEPROM was there but botched the setup some how. It may be as simple as bad math ... it should be "18000 bytes free" not "-3500 bytes free" and the bad numbers cause trouble all over ... or the bad display is a manifestation of a deeper problem.
2 - The problem with loading PropForth.f is simple. With the second EEPROM in place "fswrite" is completely broken. It never gets to EEPROM. When fs.f executes fswrite in this crippled state it blows immediately to the Cog6 prompt and all that code tries to go straight to dictionary.
Yes to all the 'checks'
...bad math ... it should be "18000 bytes free" not "-3500 bytes free"
2 - ... executes fswrite ... to the Cog6 prompt and all that code tries to go straight to dictionary.
Is there some relation between 18000 and -3500? The kernel initially did everything unsigned, could the cause be related to that?
One last check -
You have demonstrated with other software that the 2 EEPROM configuration works and there is nothing funky with the addressing or data lines, etc? (I assume the answer will be yes but I have to ask anyway)
Sal tested with 3 @ 64k EEPROM (per the notes) so I'm interested the difference from your hardware and his test rig.
Is there some relation between 18000 and -3500? The kernel initially did everything unsigned, could the cause be related to that?
One last check -
You have demonstrated with other software that the 2 EEPROM configuration works and there is nothing funky with the addressing or data lines, etc? (I assume the answer will be yes but I have to ask anyway)
Sal tested with 3 @ 64k EEPROM (per the notes) so I'm interested the difference from your hardware and his test rig.
Thanks for testing and sharing your results!
I been pondering 180000 and -3500 and cannot think of any reason ....
Yes, the second EEPROM works and no hinky kluges.
Ask Sal what happens if he pulls third EEPROM so that there are only two.
Comments
A couple people asked about this already
Propforth4.0 does NOT require multiple pros BUT
the instructions are centered around the multiple prop set-up and tests.
ALSO the set-up as posted assumes the protoboard and a 64k EEPROM for the file system.
The core will run on a demo board, and the extensions can be added, but adjustments have to be made for the demo board's 32k EEPROM.
So I 'm going through today and making updates and figuring out how to handle the diferences between the 32k EEPROM which cannot use the fs.f and the current posted package which relies on the 64k EEPROM and fs.f
PM me with specific questions if you don't want to wait for the update to be posted
Q1. No single prop is Ok
Q2. Yes, you can use Forth on protoboard or any prop board for that matter providing the eeprom is 64K. You can get away with 32K eeprom at a pinch with Propforth rev 3.5
Providing you set the xtal, if it differs from 5MHZ (5MHZ is the default) and that you set the RX/TX pins to suit your board config normally P31 and P30 in Propforth.spin file before downloading.
cheers
Ron
I would request that folks try to stick with the current release if at all possible. The earlier releases are no longer supported, and are superceded by the newer releases because they were found to be lacking in some way.
V4.0 like all previous version is designed to run on any prop chip, its the variance in external EEPROM size that we ned to pay attention to.
This V4.0 version is highlighting the EEPROM file system, which unfortunately does not play well in the 32k EEPROM, but can be made to work (if you really understand it and want to be really careful, which is possible by not tangental to the current focus at this time).
If anybody is stuck because they only have access to a demo board please post or PM me. Otherwise if you can use a proto, schmart, or Pro Dev board, that would be least strain on the braino.
I just found your link to zipit on the other thread and ordered a couple. I'll post after the brainettes have done their analysis.
I checked [cominit comstat] at line297 on README.TXT..
My result is normal?
Result is below;
The first time you appear to have gotten something wrong, possibly a loose wire, and registered a lot of errors.
After the reset, the channels are working, counting packets and no errors.
You have success! Omedito-gozimasu!
The channel between master prop chip and slave prop chip is working. The rest of the example (which I haven't done on 4.0 but ran successfully on 3.6) shows how to switch between cogs on master:
Master0 Cog4 Ok (0-4 are available on master I think)
and cogs on the slave:
SlaveN Cog9 (0-6 are available I think; slave cogs are numbered 8-15 on first slave)
Way to go! you are the first on 4.0 (after Sal)
Hydra and Ramblade for example use these pins for Xmem once programmed. I am not sure about the new Dram boards but I can see this being a problem I hope its not too late to revisit this issue.
Ron
I think hardware has no problem.
I read source code about iochannel.
I have question.
io-channel of each cog has 32byte from data area for each cog.
For example, cog6 has data-area from 0xAB8 to 0xB97.
io-channnel of cog6 occupy datas from 0xAB8 to 0xAD8.
each io-channel(0 - 7) has 4byte.
But debugcmd use from 0xABE to 0xABF. Other cogdata(debugvalue base coghere execword >out >in pad) also has data until 0xAD8.
io-channel and cogdata(debugcmd debugvalue base coghere execword >out >in pad) is overlapping...
I think my understanding is wrong.
What am I wrong?
Sorry Ron, I think you mis-understand.
4.0 is centered around the example of re-assigning the I/O pins. In this case, we use 29 and 28 to emulated EEPROM in the slave, and then use them for the MASTER/SLAVE high speed synchronous serial channel.
The pins 31 and 30 are used for standard serial communications, and propforth uses these pins by default to communicate with the command prompt. this allows interactive development, which is sometimes considered an advantage. You could re-assign the serial to other pins, as shown in the example where a new asynchronous serial channel is established on pin 0 and 1 of the master to pins 30 & 31 of the slave. But to talk to the propchip over serial using a terminal program, we just leave it on 30 & 31 since there is already dedicated hardware installed and we never waste parts if we can help it.
So, you can do whatever you want with your specific hardware, and it will be no problem. I would question why you would waste either A) a perfectly good serial chip or
If your hardware has keyboard and display like the demo board and you no longer need serial at all, then no modification is needed, please see the High-Res and Low res-VGA examples. Also see the HIVE project.
We don't had a Ramblade. The HIVE guys sent us boards and specifically ask propforth to be ported to it. Porting to Ramblade should be easy with hardware in hand. (Hint Hint send me a spare? For Xmas???)
But unless I missed something, the comment is a non-issue, I think it already does exactly what you asked.
No, you are not missing anything, I just need to sit down and work throught the propforth.spin 4.00.
I will finish off the Xmem lib routines and test them on Rev 4.00. I have a HX512 hydra card and will look at xrd and xwr words for that card later. The xwr and xrd words are the only two routines that are hardware dependant.
FYI My case Ramblade will operate as a slave and handles Xmem and SDcard functions only.
Ron
I think I got it figured out. Here's how to do the multi - prop example per Sal's instructions using the EEPROM file system:
1) We need to load propforth.spin using proptool
2) To use the EEPROM file system method you need to load into teraterm:
fs.f
propforth.f
com.f
norom.f
comnorom.f
3) At this point, only fs.f was loaded into the dictionary, the other are SOURCE in EEPROM.
NOW we need to load the source into the dictionary using:
fsload propforth.f
fsload com.f
fsload norom.f
fsload comnorom.f
Make sure the text scrolls as each file is loaded,
4) do saveforth
reboot
5) hit enter a couple times
enter this
5 2 term
to connect master cog 5 to SLAVE cog 2
CTL+f to exit,
enter this
5 6 term
to connect MASTER cog 5 to SLAVE cog 6
Here's how to do the multi - prop example WITHOUT the EEPROM file system:
1) We need to load propforth.spin using proptool
2) EDIT the following files and comment out:
a) the line(s) with fswrite at the top of the file
b) the line with ... at the bottom of the file
c) the lines fsload in comnorom.f
propforth.f
com.f
norom.f
comnorom.f
3) load the four files in the order given
4) do saveforth
reboot
5) hit enter a couple times
enter this
5 2 term
to connect master cog 5 to SLAVE cog 2
CTL+f to exit,
enter this
5 6 term
to connect MASTER cog 5 to SLAVE cog 6
Once through it its really obvious but the first eight or so times I could not figure it out at all.
Post or PM me if anybody is still stuck and I'll try to make the instructions better.
@Braino - you seem to be doing all this under the blind assumption that the whole world of PropForth is populated by serfs on the Redmond estate ... I am doing this with an iMac running OSX 10.6.5 and BST, and using Zterm .... PLEASE be a little more generic in your descriptions of loading into the file system ... TNX
I'm cofused about this.
"5 2 term" mean that connecting (current cog_number n iochannnel 0) to (cog_number 5 iochannnel 2)?
I'm wrong?
Channel means slave?
What is channel?
term in com.f below:
:term \ [n1 n2 -- ] over \ [n1 n2 n1] <-- status on stack cognchan \ [n1 n2 (number of io-channel for cog_n1) ] min \ [n1 A] (A is smaller on n2 and number of io-channel for cog_n1) <-- I can't understand this part well. >r >r \ push datas on stack cogid \ get current cog number(n) 0 r> r> \ pop datas to stacke [n 0 n1 A] (iolink) \ cog_n channel_0 connect to cog_n1 channel_A begin key dup 6 = if drop 1 \ if 6, quit else emit 0 then until cogid \ get current cog number(n) iounlink \ disconnect cog_n ;Sorry partner, don't know what you are asking.
If you have a terminal program similar to teraterm, and can paste text into the screen rather than typing, the above is written for that. PM me to explain the differences and I'll adjust accordingly.
Line 225 in com.f
\ 30 - byte, the master pin out --> the reset pin in
Line 227 in com.f
\ 32 - byte, the reset pin --> the master pin out
Sorry, It's my mistake.
Line 225 and 227 is correct.
1) The output of comstat is XmitPackets XtmitErrors RecvPackets RecvErrors
So you have errors in the packet communications. If its not the hardware, it is something else.
2) io-channel: I haven't gotten in that deep yet, sorry. Can you post an issue in google code?
Ask it as a question and Sal can fix it or explain it.
Zterm and TeraTerm for the most part are twins ... at times you have mentioned speed and the danger of overrunning the input (loading the LogicAnalyzer.f comes to mind), but there's been little discussion of paced text file sending vs pasting ... I can only assume that TeraTerm offers this. Maybe the setup docs need a preface where the mechanics of file loading is discussed, what, how, why, and what to look for as indicators of success/failure. I'd be willling to write it.
The cut from a plain text editor and paste to the Terminal has always been the method used even going back to the days Cliff''s PropellerForth. In those days it was a bit hit and miss, but its very solid now.
For rev 3.5 its helps to add a short delay (2ms) for line feeds,Teraterm allows this in the set up.
Hopefully with a text Editor and Fat16 system SDcard system things will change, but there is nothing wrong with the system as it stands.
Here's what I got:
fl - (fast load) at the top of the file is for pasting more than 80 characters of text. If you use it, it works, if you don't it overruns.
Paced Text - 0 ms for characters, 0 ms for lines
Text files sending - not supported / I haven't figure out a way to make it work
Notes:
More than 80 character in the input buffer causes overrun after approx. 3rd semi colon - there is a slight delay when the definition is committed to the dictionary,
fl - (fast load) buffers the input text stream into unused memory. In 4.0, one cog puts the input stream into memory, another compiles it into the dictionary and returns the memory to free memory.
I'm supposed to update all the docs, but I'm behind (and in hurry to post this now)
Hope this helps, we'll get it nailed eventually.
Another note: in earlier versions, the comment character \ would cause the CR-LF line terminator to be ignored and never reach the interpreter, so you needed a blank line after an in-line commented line. Sal said he would take a look at it, but I haven't had a chance to check this yet. If you get weird error messages when loading chunks of text with in-line comments, its probably not fixed yet. Probably not worth addressing until SD and text editor are in place. Is this the issue you are having? Sorry, its just awkward until the SD/editor material is implemented
How does PropForth handle line ending? Does it explicitly want CR-LF? What does it do if it gets CR only, or LF only as some non-DOS derived files might have?
When PropForth4 find out "\", it skip strings until 0xd. Not skip 0xd.
When PropForth4 find out "{", it skip strings until "}".
Please refer line1018's WORD"(fl)" in PropForthCore.
I take a Propeller Platform USB with a single 24LC512 and it loads up OK.
1 - use BST to load PropForth.spin
2 - use Zterm to load fs.f
3 - execute fslw and get
... and everything else seems to load OK
Now, take an original Propeller Platform with 2 24LC512 (addressed 0 and 1) and
do the same thing and you get
[/code]
as far as I can tell almost all of PropForth.f went directly to the dictionary and not to the EEPROM fs.
Could you enter an issue report in google code site? I don't have that hardware and don't know much about eeproms
(32K is demo board and 64k is protoboard is the boundry of my knowledge)
Just to check:
fl -- (fastload) was at start of file?
fswrite propforth.f -- was after fl before start of source?
... -- was at end of file?
One more thing:
Propforth use to terminate lines with CR+LF, but that made too many blank lines in the telnet output.
This time Sal tried to make all i/o consistent, now the terminal program only needs CR.
I don't know if this affects your issue, but its something related that changed.
I'm trying to keep organized, which is always problematic for a braino.
Would it be OK if I post your ID and what tasks you are working on? Either here on the forums or on the propforth page?
What I really want to do is organize
- testing of the kernel (I can't get to it very quickly)
- review of the documentation (It's still abysmal, not enough feedback)
- provide testing for your development (extra eyes sometimes always help)
I know everybody possibly has a life and little time for playtime, and might not be as fanatical as others, but if you are interested, it would be a big help.
Also, you can PM me if you are shy and have not posted yet.
Yes to all the 'checks'
1 - the problems manifest before I even tried PropForth.f. The code (PropForth.spin plus fs.f) obviously recognized that the second 64K EEPROM was there but botched the setup some how. It may be as simple as bad math ... it should be "18000 bytes free" not "-3500 bytes free" and the bad numbers cause trouble all over ... or the bad display is a manifestation of a deeper problem.
2 - The problem with loading PropForth.f is simple. With the second EEPROM in place "fswrite" is completely broken. It never gets to EEPROM. When fs.f executes fswrite in this crippled state it blows immediately to the Cog6 prompt and all that code tries to go straight to dictionary.
Is there some relation between 18000 and -3500? The kernel initially did everything unsigned, could the cause be related to that?
One last check -
You have demonstrated with other software that the 2 EEPROM configuration works and there is nothing funky with the addressing or data lines, etc? (I assume the answer will be yes but I have to ask anyway)
Sal tested with 3 @ 64k EEPROM (per the notes) so I'm interested the difference from your hardware and his test rig.
Thanks for testing and sharing your results!
I been pondering 180000 and -3500 and cannot think of any reason ....
Yes, the second EEPROM works and no hinky kluges.
Ask Sal what happens if he pulls third EEPROM so that there are only two.