This is REALLY cool! That is quite a list of features. I was just thinking last night of what it might take to build an assembler in forth so that I could run it on my Zipit Z2 using gforth, but you did it on forth on the propeller, which is as good or better really. Do you think the assembler is gforth compatible?
I can see now that I am going to have some fun playing with it.
Another question: I see that the Spineret has a 4 bit buss for fast nibble transfers in addition to SPI. Does Sal have a driver in the kernel to drive it at 4bits?
Thanks!
Doug
Thanks, I didn't do my testing yet, so I haven't udated the docs, so everrybody is kind of on their own for a bit, but please play.
GFORTH - the assembler is probably going to be different, unless it is an assembler targeted for the prop;
BUT the forth code should be MOSTLY compatible, except in places where the prop architecture is unique. Post specific questions and maybe we can answer.
Which GFORTH are we talking, send me a PM with the link etc, so I can see if something runs on my rig.
Spineret has wiznet5100, which has SPI and some parallel interface. Right now we are only talking SPI, Sal says it fast enough for what he's doing. If there is a need for other stuff, mention what it is and we'll put it in the queue.
Of course, you shouldn't wait, it would probably much faster (and more fun) to do it yourself, and many of us will be interested and like to help.
There is no WORD"variable ".
Is there WORD instead of "variable "?
words variable
NFA (Forth/Asm Immediate eXecute) Name
Prop0 Cog6 ok
There should be
wvariable - - in propforthcore.f
cvariable , lvariable -- I thought these existed in previous versions, but I no longer seen them.
If they are no used in re-generating propforth.spin, Sal may have decided they are unnecessary.
Of course, you could define them if you need them. I'll ask on tomorrow's call.
I made some progress, but I haven't gotten it all squared away yet.
The clean up and re-structuring changed several things from the development version I was working from. Please bear with me.
Got the instructions in as far as the ROM-less demo word. Please if you can follow it, to that point, let me know any mistakes to fix or changes you wish to see.
-'daisy chain' or what? \
- slaves??? Are they just for added CPU power, or can we address their I/O pins? If so, how?
- slaves??? When we start spinning off processes to slave cogs do we have any knowledge and/or control of what cog in which slave we are going to?
1) tree - master can have 5 slave props; all others can have 7 slaves.
2) Yes, and yes
3) yes, and several ways; what ever is convenient. My preferences is sequential numbers, master cogs are 0-7; first slave is 8-15; etc. Master pins are 0-31; first slave is 32-63, etc. But if you prefer you could have free cogs in a pool, a just ask who is available. Pins, I don't see how one would use them as a pool, since I always connect a specific device to a specific set of pins.
Initially, the prop ID value is 0 at boot. (All use master's ROM image). MASTER detects NO-PROP on 31 & 30, so he knows he's master. SLAVE detect there is a master on 30 & 31 and asks for an ID. Master ID starts as 0 and assigns slave ID's as my-ID + 1 more according to the pins they are hanging from. SLAVE get the same image and do the same. SIMPLE, yes? Actually there's a formula for the deeper levels, but you get the idea.
Master starts and does a reset and rom emulations for each possible slave. Physical channel wiring is identical on all props, except "used " or "not used"
1) tree - master can have 5 slave props; all others can have 7 slaves.
I am still pondering this ... where would the second slave connect? If not a 'daisy-chain' but a 'tree' I don't see room for four more slaves on the master
I am still pondering this ... where would the second slave connect? If not a 'daisy-chain' but a 'tree' I don't see room for four more slaves on the master
MASTER has 5 unused cogs.
Each unused cog may be used to run a synchronous serial channel to a slave. (another separate physical prop chip)
Each synchronous serial channel needs 4 signals: MOSI, MISO, Clock, RESET (and power and ground)
5 cogs establishing 5 channels would need 20 pins (to attach 5 more props).
7 cogs establishing 7 channels would need 28 pins (to attach 7 more props).
BUT we might be able to use the same RESET and CLOCK pin for all slaves hanging off a master or sub master, so it would only require
(5*2)+2=12 pins for the MASTER and
(7*2)+2=16 pins for the SUB-masters.
[Of course, we will have to check if kuroneko's delay map investigation http://forums.parallax.com/showthread.php?127653-FYI-waitpxx-cog-synchronisation
has any impact on this. ]
We end up using all the resources of the masters and sub-masters, but we get 7 cogs and 28 pins on each leaf-slave. Net increase in resources is very fast.
Sal says that the masters don't have to be fully populated, that is you could use one cog and talk to the master using 28, 29, 30, 31; and another cogs and talk to the slave using 0, 1,2,3 for example, and make a daisy chain as long as you want. I think "tree" and not so much "daisy chain", but I'm sure there could be neat uses for either.
Anyway, as you noticed, nobody has built any of these massive configurations, so we don't know if they will work. But they'll work. or we'll try something else.
I was asking about assembler.f working on gforth because I have gforth on my Zipit Z2, and it would be cool to be able to compile propeller assembly to .eeprom or .bin images that I could download to the propeller.
About the 4.0 release schematic. Why connect to pins 28&29 as well as 30 & 31? Instead of emulating a eeprom, why not leave those pins free and just boot from the master propeller via pins 30&31?
I was asking about assembler.f working on gforth because I have gforth on my Zipit Z2, and it would be cool to be able to compile propeller assembly to .eeprom or .bin images that I could download to the propeller.
About the 4.0 release schematic. Why connect to pins 28&29 as well as 30 & 31? Instead of emulating a eeprom, why not leave those pins free and just boot from the master propeller via pins 30&31?
gforth - send links for you zforth and I'll give it a look.
pins 28&29 are the high speed synchronous serial. this is the multi-prop channel
pins 30&31 are another plain old async serial channel. somebody asked how to do another async serial channel. Its another way (possibly more familiar) to test that the other parts are working.
The 30&31 connections is optional, the 28&29 is not, if there is no EEPROM, the prop doesn't have any instructions and turns itself off.
Hey all. I'm beginning to find I made some incorrect assumptions in the release notes. The examples I have seen so far in 3.6 and am working on now in 4.0 are for a master and one slave. The slave automagically wakes up becasue the master emulates eeprom.
The incorrect bit might be the multiple slaves support. I don't know if the mechanism for automatically loading up N-slaves is complete. I'm begining to think that that mechanism is the target for the NEXT release, although the PARTS to do it are in this one. I'll re-words the docs tonight i hope. sorry for the confusion. They don't call me "brain?-no!" for nothing.
The 30&31 connections is optional, the 28&29 is not, if there is no EEPROM, the prop doesn't have any instructions and turns itself off.
OK Its slowly sinking into my thick Irish skull ... Basic set for a slave cog is pins for MISO/MOSI, a pin for CLK and one for RESet. The Spinneret Slave configuration has no clock because you let it use its own clock.
I can see sharing CLK ... though, what is the fanout for Prop pin? Will it support 5 prop pins?
I think sharing RESet could be a recipe for craziness!
30/31 on each slave is optionally available as serial port ... as a Forth command line? a copy of PST? Hang a serial LCD and display info?
I am still pondering this ... where would the second slave connect? If not a 'daisy-chain' but a 'tree' I don't see room for four more slaves on the master
Brian, I'm still pondering this too and wondered why the Braino would not simply post his schematic until I realized, being the braino, he runs all this code in his brain with no wiring diagrams or machine platform.
...wondered why the Braino would not simply post his schematic until I realized, being the braino, he runs all this code in his brain with no wiring diagrams or machine platform.
I was looking for a schematic too, but I figured the readme should be enough. But I'm having trouble, too. I'm begining to think including the "N-slaves" in the feature list might be pre-mature.
Probably I should test more before I post. I will have have to change the feature list from "supports N-slaves" to "supports 1-channel per free cog"; the automagic booting of the slaves appears to be waiting for a future release. Sorry, guys, I got too excited.
About test of README.TXT.
I renamed fs.f to 10_fs.f after step 9.
I renamed below after step 11.
propforth.f
> 11_propforth.f
LogicAnalyzer.f
> 12_LogicAnalyzer.f
asm.f
> 13_asm.f
norom.f
> 14_norom.f
com.f
> 15_com.f
comnorom.f
> 16_comnorom.f
snet.f
> 17_snet.f
after step 12, below;
fsls
008000 002272 propforth.f
00A280 000E77 LogicAnalyzer.f
00B140 0020CE asm.f
00D240 000D0F norom.f
00DF80 001426 com.f
00F3C0 000221 comnorom.f
00F600 000112 snet.f
8C0 bytes free in files system
step 13
reboot
RESET Prop0 Cog6 ok
fsload LogicAnalyzer.f
Prop0 Cog6 ok
C" hex a aae60 setHza b 6ACFC0 setHzb" 5 cogx
Prop0 Cog6 ok
sampleNoTrigger
UNDEFINED WORD sampleNoTrigger
Prop0 Cog6 ok
words sampleNoTrigger
NFA (Forth/Asm Immediate eXecute) Name
Prop0 Cog6 ok
I have question to everyone.
I cannot test procedures of README.TXT.
This problem is caused only me?
You can test procedures of README.TXT?
No problem?
LogicAnalyzer.f
> 12_LogicAnalyzer.f
after step 12, below;
fsload LogicAnalyzer.f
sampleNoTrigger
UNDEFINED WORD sampleNoTrigger
problem only me? You can test procedures of README.TXT? No problem?
Hi caskaz
I got past that point. LogicAnalyzer works for me.
If you got "UNDEFINED WORD" you did a mistake someplace.
When you load logicanalyzer.f, sample notrigger is defined, as you can see from the code.
So something is NOT correct in the steps you performed.
When I do that step, the logic analyzer displays the logic level of the pins for a sample period, as expected.
I got stuck later on, at the "demo" word, which might be due to the ordering of parameters on the stack in the example code, but I have not been able to fix it.
In your case, if the intructions did not help, go back to the README.txt file
Be sure to reload propforth.spin before you start.
be sure to back up one step if you get an error.
be sure to back up two steps if you get the smae error two times,
and so on.
It took me a couple times to get it going, and when I did it really SLOWLY, as I was writing the instructs at the same time, I was very careful to get it right. That was the time it worked.
I did test-procedure(from installing PropForth4.0) many times.
Maybe I think I repeat wrong way.
But I don't know which is wrong.
Maybe I will do correct way when I reset my brain( I forget current way)
I give up doing test-procedure.
I did test-procedure(from installing PropForth4.0) many times.
Maybe I think I repeat wrong way.
But I don't know which is wrong.
Maybe I will do correct way when I reset my brain( I forget current way)
I give up doing test-procedure.
Thanks for trying so hard. If even you have troubles, then its clear that the instructions need work.
I'll keep looking at it, most likely I will break readme.txt into several smaller tests that can be done independently. I'll try to get something on the weekend.
... this weekend. ... best position for the DIP prop on the protoboard?
May I recommend: I have the DIP-40 on a breadboard. I usually find I make mistakes the first couple dozen times I set up a circuit. I went through miles of solder wick before I discovered bread boards.
Also - Proceed a little slowly, the readme.txt is one long list of several experiments, sometimes there are multiple steps on a single line and its easy to miss one and get stuck.
SOMETIMES it scrolls many lines of source code across the screen, and sometimes it does not.
I THINK if we copy the text "fsload LogicAnalyzer.f" from the readme.txt file and paste it into teraterm, it does NOT scroll the text. If we TYPE the text into teraterm, it DOES scroll.
If the text does NOT scroll, sampleNoTrigger is UNDEFINED WORD
If the text DOES scroll, the logic analyzer runs!
I think this may be our problem. I have not determined if the problem is in teraterm or propforth, but probably its in propforth. It could be in the interpreter or in fs.f, I would guess fs.f since its the newest thing.
With this new knowledge, please try again. I will try to get past the demo word this weekend
I did type-in "fsload LogicAnalyzer.f" , not copy/paste.
It's ok.
When copy/paste string, WORD"(fsfind)" inside fs.f can't find out address for string"LogicAnalyzer.f"
But no error message.
I don't know reason.
I posted eeDunp at #28.
This output cr 2times.
Default"cr" for PropForth4 is $d + $a.
When _crf is 0, "cr" output only $d.
I think comments for cognchan(line436) of PropForthCore is a littele different.
cognchan (n1 -- n2) number of io channels for cog n2 --> number(n2) of io channels for cog n1
I did type-in "fsload LogicAnalyzer.f" , not copy/paste.It's ok.
When copy/paste string, WORD"(fsfind)" inside fs.f can't find out address for string"LogicAnalyzer.f" But no error message.I don't know reason.
I posted eeDunp at #28.
This output cr 2times. Default"cr" for PropForth4 is $d + $a.
When _crf is 0, "cr" output only $d.
1) Thank you very much for continuing testing. This was a tricky one.
2) LogicAnalyzer.f is NOT in the dictionary, it is the filename of the forth source code in the EE-mini-filesystem. The functions of the "software logic analyzer package" are sampleNoTrigger etc; these reside in the dictionary.
Bear in mind that the logic analyzer package is different because the big chunks of assembler code that reside only in the one cog that is running logic analyzer. Also, the logic analyzer collects samples into the remaining cog-ram for the fast sample rates. The slower sample rates are collected in to hub memory. you have to be aware of which is which. The documentation is supposed to explain this, but I don't know how clear it is.
3) In earlier version, Propforth did a CR-LF for the serial terminal..
BUT the Telnet portion would give blank lines because of the way telnet works.
I asked Sal to do anything necessary to make them both operate the same way.
As a result, we have to change the default setting for teraterm.
Now, serial and ethernet will both behave the same way (I hope).
I neglected to mention this different in the notes, I will add that tonight if I ever get these kid to bed.
I think comments for cognchan(line436) of PropForthCore is a littele different.
cognchan (n1 -- n2) number of io channels for cog n2 --> number(n2) of io channels for cog n1
Thanks, I'll give this a look next time I'm in there
If anyone is interested, here are a couple of Forth words to access Xmem on the Ramblade. I had not really seen any reason to do this until I noticed that Caz had started work on a FAT16 system. The ability to move large files from SDcard to Xmem brings us close to Stand-Alone Forth computer. The missing link being a solid Text editor. Thinking Forth by Leo Brodie provides an excellent tutorial and he uses the development of a Forth text editor in the work. Anyone up for it ?
BTW Rev 3.5 and 4.0 seem to work OK on the Ramblade, clocked at 6.5MHZ. FYI the system here consists of a Ramblade, Propmod with SDcard and a single Propmod ( 3 Props 2 SD slots 512K SDRAM)
\ Xmem read byte example 1FFF xrd will leave byte at location 1FFF on TOS
: xrd dup 0 set_dira \ (adr--data)
mem_top < if \ test if lower than ram top, if so continue
set_outa \ put adr on buss
ram_dr set_dira \ enable adr lines
rd_ina \ read data
18 rshift \ align
then ; \ depart leaving result on TOS
\ Xmem write byte example 2A 1FFF xwr will put a 2A at location 1FFF
: xwr dup \(data adr--xm)
0 set_dira
mem_top < if \ test if lower than ram top, if so continue
ram_dw set_dira \ disable Sram
swap \ put data TOS and adr under
18 lshift \ align data
or \ or data, with adr on stack
set_outa \ put data and adr on buss
ram_strobe set_dira \ write stobe
ram_dw set_dira \ reset stobe
then ; \ depart with clean stack
Forth words to access Xmem on the Ramblade. ... Caz .. FAT16 system.
The missing link being a solid Text editor. .... Anyone up for it ? Ron
I vote Ron is lead on the text editor utility. If you are interested, make gmail account so you can join the google code site, and PM me.
I have been fiddling with Frank Sargent's Pygmy Forth. It is open source and for PC. It is very close to what I imagine is a "classic forth" in that it has a minimal kernel and a load of options extensions. My intent was to use this as a model for propforth editor extensions, but did not make usable progress due to other obligations.
Of course you are free to pursue any direction you see fit, this is just a suggestion.
Maybe I should make a list of functions we are wishing for, post our progrss?
If you guys think this is good idea I will make a stab later today when I incorporate this week's changes.
Feedback in the form of PM's or forum posts would be appreciated.
There were some small problems in the schematic I uploaded in Message #26 in the pullup on P29 on the slave and in the pin alignment on J1, the programming interface. Fixed and new image loaded to Message #26
@Braino, I think you will need to edit your link to the schematic on your Google PropForth page
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.
Comments
Thanks, I didn't do my testing yet, so I haven't udated the docs, so everrybody is kind of on their own for a bit, but please play.
GFORTH - the assembler is probably going to be different, unless it is an assembler targeted for the prop;
BUT the forth code should be MOSTLY compatible, except in places where the prop architecture is unique. Post specific questions and maybe we can answer.
Which GFORTH are we talking, send me a PM with the link etc, so I can see if something runs on my rig.
Spineret has wiznet5100, which has SPI and some parallel interface. Right now we are only talking SPI, Sal says it fast enough for what he's doing. If there is a need for other stuff, mention what it is and we'll put it in the queue.
Of course, you shouldn't wait, it would probably much faster (and more fun) to do it yourself, and many of us will be interested and like to help.
There is no WORD"variable ".
Is there WORD instead of "variable "?
There should be
wvariable - - in propforthcore.f
cvariable , lvariable -- I thought these existed in previous versions, but I no longer seen them.
If they are no used in re-generating propforth.spin, Sal may have decided they are unnecessary.
Of course, you could define them if you need them. I'll ask on tomorrow's call.
http://code.google.com/p/propforth/wiki/PropForth4SetupAndTest
I made some progress, but I haven't gotten it all squared away yet.
The clean up and re-structuring changed several things from the development version I was working from. Please bear with me.
Got the instructions in as far as the ROM-less demo word. Please if you can follow it, to that point, let me know any mistakes to fix or changes you wish to see.
1) tree - master can have 5 slave props; all others can have 7 slaves.
2) Yes, and yes
3) yes, and several ways; what ever is convenient. My preferences is sequential numbers, master cogs are 0-7; first slave is 8-15; etc. Master pins are 0-31; first slave is 32-63, etc. But if you prefer you could have free cogs in a pool, a just ask who is available. Pins, I don't see how one would use them as a pool, since I always connect a specific device to a specific set of pins.
Initially, the prop ID value is 0 at boot. (All use master's ROM image). MASTER detects NO-PROP on 31 & 30, so he knows he's master. SLAVE detect there is a master on 30 & 31 and asks for an ID. Master ID starts as 0 and assigns slave ID's as my-ID + 1 more according to the pins they are hanging from. SLAVE get the same image and do the same. SIMPLE, yes? Actually there's a formula for the deeper levels, but you get the idea.
Master starts and does a reset and rom emulations for each possible slave. Physical channel wiring is identical on all props, except "used " or "not used"
I am still pondering this ... where would the second slave connect? If not a 'daisy-chain' but a 'tree' I don't see room for four more slaves on the master
MASTER has 5 unused cogs.
Each unused cog may be used to run a synchronous serial channel to a slave. (another separate physical prop chip)
Each synchronous serial channel needs 4 signals: MOSI, MISO, Clock, RESET (and power and ground)
5 cogs establishing 5 channels would need 20 pins (to attach 5 more props).
7 cogs establishing 7 channels would need 28 pins (to attach 7 more props).
BUT we might be able to use the same RESET and CLOCK pin for all slaves hanging off a master or sub master, so it would only require
(5*2)+2=12 pins for the MASTER and
(7*2)+2=16 pins for the SUB-masters.
[Of course, we will have to check if kuroneko's delay map investigation
http://forums.parallax.com/showthread.php?127653-FYI-waitpxx-cog-synchronisation
has any impact on this. ]
We end up using all the resources of the masters and sub-masters, but we get 7 cogs and 28 pins on each leaf-slave. Net increase in resources is very fast.
Sal says that the masters don't have to be fully populated, that is you could use one cog and talk to the master using 28, 29, 30, 31; and another cogs and talk to the slave using 0, 1,2,3 for example, and make a daisy chain as long as you want. I think "tree" and not so much "daisy chain", but I'm sure there could be neat uses for either.
Anyway, as you noticed, nobody has built any of these massive configurations, so we don't know if they will work. But they'll work.
I got as far as line 335 in the README.txt instructions. the 'demo' word for the {{{norom.f}}} test got stuck
I think the parameters for the 'rambootnx' words are in the wrong order based on the stack note in 'norom.f'
Must sleep... brain sore...
I was asking about assembler.f working on gforth because I have gforth on my Zipit Z2, and it would be cool to be able to compile propeller assembly to .eeprom or .bin images that I could download to the propeller.
About the 4.0 release schematic. Why connect to pins 28&29 as well as 30 & 31? Instead of emulating a eeprom, why not leave those pins free and just boot from the master propeller via pins 30&31?
gforth - send links for you zforth and I'll give it a look.
pins 28&29 are the high speed synchronous serial. this is the multi-prop channel
pins 30&31 are another plain old async serial channel. somebody asked how to do another async serial channel. Its another way (possibly more familiar) to test that the other parts are working.
The 30&31 connections is optional, the 28&29 is not, if there is no EEPROM, the prop doesn't have any instructions and turns itself off.
The incorrect bit might be the multiple slaves support. I don't know if the mechanism for automatically loading up N-slaves is complete. I'm begining to think that that mechanism is the target for the NEXT release, although the PARTS to do it are in this one. I'll re-words the docs tonight i hope. sorry for the confusion. They don't call me "brain?-no!" for nothing.
OK Its slowly sinking into my thick Irish skull ... Basic set for a slave cog is pins for MISO/MOSI, a pin for CLK and one for RESet. The Spinneret Slave configuration has no clock because you let it use its own clock.
I can see sharing CLK ... though, what is the fanout for Prop pin? Will it support 5 prop pins?
I think sharing RESet could be a recipe for craziness!
30/31 on each slave is optionally available as serial port ... as a Forth command line? a copy of PST? Hang a serial LCD and display info?
I was looking for a schematic too, but I figured the readme should be enough. But I'm having trouble, too. I'm begining to think including the "N-slaves" in the feature list might be pre-mature.
Probably I should test more before I post. I will have have to change the feature list from "supports N-slaves" to "supports 1-channel per free cog"; the automagic booting of the slaves appears to be waiting for a future release. Sorry, guys, I got too excited.
About test of README.TXT.
I renamed fs.f to 10_fs.f after step 9.
I renamed below after step 11.
propforth.f
> 11_propforth.f
LogicAnalyzer.f
> 12_LogicAnalyzer.f
asm.f
> 13_asm.f
norom.f
> 14_norom.f
com.f
> 15_com.f
comnorom.f
> 16_comnorom.f
snet.f
> 17_snet.f
after step 12, below;
I have question to everyone.
I cannot test procedures of README.TXT.
This problem is caused only me?
You can test procedures of README.TXT?
No problem?
Hi caskaz
I got past that point. LogicAnalyzer works for me.
If you got "UNDEFINED WORD" you did a mistake someplace.
When you load logicanalyzer.f, sample notrigger is defined, as you can see from the code.
So something is NOT correct in the steps you performed.
When I do that step, the logic analyzer displays the logic level of the pins for a sample period, as expected.
I got stuck later on, at the "demo" word, which might be due to the ordering of parameters on the stack in the example code, but I have not been able to fix it.
In your case, if the intructions did not help, go back to the README.txt file
Be sure to reload propforth.spin before you start.
be sure to back up one step if you get an error.
be sure to back up two steps if you get the smae error two times,
and so on.
It took me a couple times to get it going, and when I did it really SLOWLY, as I was writing the instructs at the same time, I was very careful to get it right. That was the time it worked.
I did test-procedure(from installing PropForth4.0) many times.
Maybe I think I repeat wrong way.
But I don't know which is wrong.
Maybe I will do correct way when I reset my brain( I forget current way)
I give up doing test-procedure.
Thanks for trying so hard. If even you have troubles, then its clear that the instructions need work.
I'll keep looking at it, most likely I will break readme.txt into several smaller tests that can be done independently. I'll try to get something on the weekend.
Thanks,
Doug
May I recommend: I have the DIP-40 on a breadboard. I usually find I make mistakes the first couple dozen times I set up a circuit. I went through miles of solder wick before I discovered bread boards.
Also - Proceed a little slowly, the readme.txt is one long list of several experiments, sometimes there are multiple steps on a single line and its easy to miss one and get stuck.
I just notices something - When we run
SOMETIMES it scrolls many lines of source code across the screen, and sometimes it does not.
I THINK if we copy the text "fsload LogicAnalyzer.f" from the readme.txt file and paste it into teraterm, it does NOT scroll the text. If we TYPE the text into teraterm, it DOES scroll.
If the text does NOT scroll, sampleNoTrigger is UNDEFINED WORD
If the text DOES scroll, the logic analyzer runs!
I think this may be our problem. I have not determined if the problem is in teraterm or propforth, but probably its in propforth. It could be in the interpreter or in fs.f, I would guess fs.f since its the newest thing.
With this new knowledge, please try again. I will try to get past the demo word this weekend
I did type-in "fsload LogicAnalyzer.f" , not copy/paste.
It's ok.
When copy/paste string, WORD"(fsfind)" inside fs.f can't find out address for string"LogicAnalyzer.f"
But no error message.
I don't know reason.
I posted eeDunp at #28.
This output cr 2times.
Default"cr" for PropForth4 is $d + $a.
When _crf is 0, "cr" output only $d.
I think comments for cognchan(line436) of PropForthCore is a littele different.
cognchan (n1 -- n2) number of io channels for cog n2 --> number(n2) of io channels for cog n1
1) Thank you very much for continuing testing. This was a tricky one.
2) LogicAnalyzer.f is NOT in the dictionary, it is the filename of the forth source code in the EE-mini-filesystem. The functions of the "software logic analyzer package" are sampleNoTrigger etc; these reside in the dictionary.
Bear in mind that the logic analyzer package is different because the big chunks of assembler code that reside only in the one cog that is running logic analyzer. Also, the logic analyzer collects samples into the remaining cog-ram for the fast sample rates. The slower sample rates are collected in to hub memory. you have to be aware of which is which. The documentation is supposed to explain this, but I don't know how clear it is.
3) In earlier version, Propforth did a CR-LF for the serial terminal..
BUT the Telnet portion would give blank lines because of the way telnet works.
I asked Sal to do anything necessary to make them both operate the same way.
As a result, we have to change the default setting for teraterm.
Now, serial and ethernet will both behave the same way (I hope).
I neglected to mention this different in the notes, I will add that tonight if I ever get these kid to bed.
Thanks, I'll give this a look next time I'm in there
BTW Rev 3.5 and 4.0 seem to work OK on the Ramblade, clocked at 6.5MHZ. FYI the system here consists of a Ramblade, Propmod with SDcard and a single Propmod ( 3 Props 2 SD slots 512K SDRAM)
Code below.....
0017FFFF constant ram_dr
FF07FFFF constant ram_dw
FF37FFFF constant ram_strobe
0003FFFF constant mem_top
\ helpers to make code readable
: set_dira dira COG! ; \ dira helper
: set_outa outa COG! ; \ outa helper
: rd_ina ina COG@ ; \ ina helper
\ Xmem read byte example 1FFF xrd will leave byte at location 1FFF on TOS
: xrd dup 0 set_dira \ (adr--data)
mem_top < if \ test if lower than ram top, if so continue
set_outa \ put adr on buss
ram_dr set_dira \ enable adr lines
rd_ina \ read data
18 rshift \ align
then ; \ depart leaving result on TOS
\ Xmem write byte example 2A 1FFF xwr will put a 2A at location 1FFF
: xwr dup \(data adr--xm)
0 set_dira
mem_top < if \ test if lower than ram top, if so continue
ram_dw set_dira \ disable Sram
swap \ put data TOS and adr under
18 lshift \ align data
or \ or data, with adr on stack
set_outa \ put data and adr on buss
ram_strobe set_dira \ write stobe
ram_dw set_dira \ reset stobe
then ; \ depart with clean stack
\ end of code
If only I had more time to play Prop
cheers
Ron
I vote Ron is lead on the text editor utility. If you are interested, make gmail account so you can join the google code site, and PM me.
I have been fiddling with Frank Sargent's Pygmy Forth. It is open source and for PC. It is very close to what I imagine is a "classic forth" in that it has a minimal kernel and a load of options extensions. My intent was to use this as a model for propforth editor extensions, but did not make usable progress due to other obligations.
Of course you are free to pursue any direction you see fit, this is just a suggestion.
Maybe I should make a list of functions we are wishing for, post our progrss?
If you guys think this is good idea I will make a stab later today when I incorporate this week's changes.
Feedback in the form of PM's or forum posts would be appreciated.
@Braino, I think you will need to edit your link to the schematic on your Google PropForth page
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.
updated