Tachyon moves so fast I can find words it seems, even with the help of grep. Seems it should be defined in W5100.fth but no joy?
Never mind, found it.
Try QWORDS just for a quick and compact words listing or even QW just for those last 100 or so words.
There''s also HELP <word> which in the next version will also list the stack and description etc (as long as you have >32K EEPROM or SD). Maybe I might even have it find the source for the word and list it if it's loaded onto a file.
LIKE <word> WORDS/QWORDS/QW will list all words which have the same attributes such as kernel or extended kernel etc words.
ANY <char> WORDS/QWORDS/QW will list any words that have a matching character
MY WORDS/QWORDS/QW will just list the latest module words
MATCH <chars> WORDS/QWORDS/QW will list matching words that start with the same characters
All these may be replaced with a more general pattern mask when I get a round tuit.
I can see by your post though that I may need to implement WHICH WORDS just to find out what you are talking about
(I may need to check the operation of these controls as I haven't used them in some time)
I've been playing with Tachyon a bit today and was wondering if there is a way to list the available words without first loading EXTEND.fth? In other words, I'm looking for a list of the core words before any extensions are loaded. I had thought WORDS would do that but it doesn't seem to be one of the core words.
Hi all,
Lately I have been fooling around with very tiny WR703N and MR3020 wireless routers as a means to load and communicate with my Propeller Protoboard. They are about 2 inches by 2 inches by 1/2 inch high.
Yesterday, I managed to get my tiny MR3020 to download and install Tachyon V2.1 via the wifi, and then to bring up the Tachyon prompt. I did have to use a USB2SER on the USB port, but am working also on just a straight ttl RS232 setup from the MR3020 to the Propeller.
So it seems a nice fit for Forth over wifi.
These devices are only about $20USD, consume about 0.6 watts at 5VDC. and have OpenWrt firmware modifying them into a very handy custom wifi router. Someone has even claimed to use solar cells to power the wifi router, certainly seems easy enough to do.
Heater recompiled propeller-load, a command line binary loader that sits inside the wifi router's Linux OS. So it makes it possible to SCP a binary to the router, and then load it to the Propeller. I also loaded Minicom and an FTDI USB serial driver into the router, and that completes the set up to allow active Tachyon from afar.
I think I am going to enjoy this a lot. You can have a Propeller attached to anything and sitting anywhere. When you want to change something, you bring up the wifi router, enter Minicom, and you are into Tachyon of the device.
OpenWrt also adds another dimension to Tachyon as wifi can be deployed in a variety of ways to network Propellers.
I've been playing with Tachyon a bit today and was wondering if there is a way to list the available words without first loading EXTEND.fth? In other words, I'm looking for a list of the core words before any extensions are loaded. I had thought WORDS would do that but it doesn't seem to be one of the core words.
I try to keep the precompiled kernel tight, just the minimum that's required as it's easy to write Forth in Forth rather than as "bytes" within the rather limited Spin/PASM compiler. So always consider EXTEND.fth as part of the kernel that although it gets compiled by the 1st stage kernel, it is nonetheless the other half of the kernel, albeit that there is a lot of extra stuff in there. Remember too that the EEPROM utilities are all defined in EXTEND.fth and you really need that too.
I try to keep the precompiled kernel tight, just the minimum that's required as it's easy to write Forth in Forth rather than as "bytes" within the rather limited Spin/PASM compiler. So always consider EXTEND.fth as part of the kernel that although it gets compiled by the 1st stage kernel, it is nonetheless the other half of the kernel, albeit that there is a lot of extra stuff in there. Remember too that the EEPROM utilities are all defined in EXTEND.fth and you really need that too.
Okay, no problem. That makes a lot of sense. I had just thought I saw a video somewhere that showed a way to list the core words even before loading EXTEND.fth. I must have been dreaming! :-)
I actually did try loading EXTEND.fth but the load failed somewhere in the middle. This is probably due to using the CoolTerm terminal emulator on the Mac. I tried setting the line delay to 20ms as suggested in your document but I'm not sure that was enough. Is it possible that I also need to add a character delay? Is there any way to create a copy of Tachyon with EXTEND.fth preloaded without having to blast characters over the serial connection?
Okay, no problem. That makes a lot of sense. I had just thought I saw a video somewhere that showed a way to list the core words even before loading EXTEND.fth. I must have been dreaming! :-)
I actually did try loading EXTEND.fth but the load failed somewhere in the middle. This is probably due to using the CoolTerm terminal emulator on the Mac. I tried setting the line delay to 20ms as suggested in your document but I'm not sure that was enough. Is it possible that I also need to add a character delay? Is there any way to create a copy of Tachyon with EXTEND.fth preloaded without having to blast characters over the serial connection?
I normally use 12ms line delay and never ever a character delay but as for having EXTEND preloaded that's what the binary images are for in the DropBox. I may just update this too but there is a fairly recent one there in the binaries folder from the 8th which just includes EXTEND.fth. The startup automatically detects 5 or 10MHz crystal configurations and adjusts the PLL accordingly. Default baud is 230400 of course.
BTW, very early versions of Tachyon had WORDS and extras precompiled but as mentioned this is much better handled by Forth itself.
I normally use 12ms line delay and never ever a character delay but as for having EXTEND preloaded that's what the binary images are for in the DropBox.
I guess I was looking for a way to create a binary myself with whatever collection of Forth words I want including EXTEND.fth. Not a big deal. I'll figure out my terminal settings so I can get it loaded from CoolTerm or maybe I'll just move over to Linux and use minicom.
BTW, very early versions of Tachyon had WORDS and extras precompiled but as mentioned this is much better handled by Forth itself.
Maybe that's where my confusion came. I think I was watching your Tachyon tutorial video that was clearly marked as being out of date.
I guess I was looking for a way to create a binary myself with whatever collection of Forth words I want including EXTEND.fth. Not a big deal. I'll figure out my terminal settings so I can get it loaded from CoolTerm or maybe I'll just move over to Linux and use minicom.
Maybe that's where my confusion came. I think I was watching your Tachyon tutorial video that was clearly marked as being out of date.
Thanks for your help!
David
Once you load the binary you can still load in your own EXTEND.fth version and any other modules etc. Normally the modules all start with a FORGET <this module> command in case it already exists so there is no need to do anything special. However EXTEND.fth is really part of the kernel so if you try to load it in when it is already loaded it will perform a COLD which will reset the kernel in RAM back to it's precompiled state. If you want to create your own binary you can us the DUMPROM command which will fix the boot checksum in EEPROM and dump the EEPROM as a Intel hex file. I normally just copy this into a text file and save it as a .HEX file and run a HEXBIN utility then rename the BIN file to .binary to keep the Spin tool happy. Of course if you an SD card in your system then it is far simpler as you just type SAVEROM into a empty FIRMWARE.ROM file. Again, if you have EASYNET loaded and running you can easily read the FIRMWARE.ROM file over FTP and in fact this is also one way in which I disseminate new firmware.
Once you load the binary you can still load in your own EXTEND.fth version and any other modules etc. Normally the modules all start with a FORGET <this module> command in case it already exists so there is no need to do anything special. However EXTEND.fth is really part of the kernel so if you try to load it in when it is already loaded it will perform a COLD which will reset the kernel in RAM back to it's precompiled state. If you want to create your own binary you can us the DUMPROM command which will fix the boot checksum in EEPROM and dump the EEPROM as a Intel hex file. I normally just copy this into a text file and save it as a .HEX file and run a HEXBIN utility then rename the BIN file to .binary to keep the Spin tool happy. Of course if you an SD card in your system then it is far simpler as you just type SAVEROM into a empty FIRMWARE.ROM file. Again, if you have EASYNET loaded and running you can easily read the FIRMWARE.ROM file over FTP and in fact this is also one way in which I disseminate new firmware.
Wow! Lots of options. Tachyon is certainly a very complete package unlike the simple Basic interpreters I've created for the Propeller that are really more of a proof-of-concept. Thanks for your help!
I've been playing with Tachyon a bit today and was wondering if there is a way to list the available words without first loading EXTEND.fth? In other words, I'm looking for a list of the core words before any extensions are loaded. I had thought WORDS would do that but it doesn't seem to be one of the core words.
Hi David,
while Peter is surely right...
the curious mind whats to know.
You can easily search the kernel source for DICTIONARY to see the words.
In doing this I every now and then discover a 'new' word, which is not part of my active vocabulary yet.
so it's very educating too
btw: the Tachyon scriptable dynamic webserver with AJAX will be there soon.
AND: please, again, all of you - choose meaningful post titles - just click 'REPLY to THREAD' instead of REPLY to previous unrelated post !!!
Once you load the binary you can still load in your own EXTEND.fth version and any other modules etc. Normally the modules all start with a FORGET <this module> command in case it already exists so there is no need to do anything special. However EXTEND.fth is really part of the kernel so if you try to load it in when it is already loaded it will perform a COLD which will reset the kernel in RAM back to it's precompiled state. If you want to create your own binary you can us the DUMPROM command which will fix the boot checksum in EEPROM and dump the EEPROM as a Intel hex file. I normally just copy this into a text file and save it as a .HEX file and run a HEXBIN utility then rename the BIN file to .binary to keep the Spin tool happy. Of course if you an SD card in your system then it is far simpler as you just type SAVEROM into a empty FIRMWARE.ROM file. Again, if you have EASYNET loaded and running you can easily read the FIRMWARE.ROM file over FTP and in fact this is also one way in which I disseminate new firmware.
This is exactly what I was looking for recently, just bumping this for safe keeping.
Does this look like a successful load of EXTEND.fth?
00:00:00 End of source code, 1481 lines processed and .0001 errors found
MODULES LOADED:
1880: EXTEND.fth Primary extensions to TACHYON kernel - 140723-14OO
NAMES: $5C20...7442 for 6178 (3741 bytes added)
CODE: $0000...3511 for 7407 (7313 bytes added)
CALLS: 0452 vectors free
RAM: 9999 bytes free
. ok
\
EEPROM 9600d SERBAUD ok
?BACKUP ok
Published
Does this look like a successful load of EXTEND.fth?
00:00:00 End of source code, 1481 lines processed and .0001 errors found
MODULES LOADED:
1880: EXTEND.fth Primary extensions to TACHYON kernel - 140723-14OO
NAMES: $5C20...7442 for 6178 (3741 bytes added)
CODE: $0000...3511 for 7407 (7313 bytes added)
CALLS: 0452 vectors free
RAM: 9999 bytes free
. ok
\
EEPROM 9600d SERBAUD ok
?BACKUP ok
Published
I got a message in the middle saying this:
0552
--> Screenshot <-- not found .
0553
Is this a problem?
Thanks,
David
Never mind. My problem had to do with cutting and pasting from Safari. I went to the Tachyon DropBox folder and got EXTEND.fth directly and it loads fine. Sorry for the false alarm!
I've had fun playing with Tachyon today. It is certainly true that an interactive language is a very powerful tool. While Forth would probably not be my first choice, it is will suited to an unexpanded Propeller and Tachyon seems to be a very capable system. Now I need to get to work on a real Forth project! :-)
I've had fun playing with Tachyon today. It is certainly true that an interactive language is a very powerful tool. While Forth would probably not be my first choice, it is will suited to an unexpanded Propeller and Tachyon seems to be a very capable system. Now I need to get to work on a real Forth project! :-)
why only to an unexpanded Propeller ??
the more the Propeller gets expanded the better:
WizNet -> NW, FTP, TELNET, HTTP
Loads of Sensors & Actors
PWM
Motor Controller
...
the more the Propeller gets expanded the better:
WizNet -> NW, FTP, TELNET, HTTP
Loads of Sensors & Actors
PWM
Motor Controller
...
I forgot SD Filesystem, 4GB virtual memory
Sorry, what I meant was a Propeller without any extended memory like what would be needed to run something like JavaScript or even Python or Lisp. Tachyon makes very efficient use of the 32k of hub memory in P1 and packs in a lot more functionality than would likely be possible with so-called higher level languages. Of course hardware peripherals are necessary on pretty much any embedded system!
Forth is an excellent language to explore a new device interactively. So I am getting back into Tachyon in anticipation of it helping me with the Propeller2.
I've now got my Propeller1 running over a wifl link in anticipation of doing the same with a Propeller 2. Not much else to report as I do have to really settle in and catch up will all Peter J has created (and that is a heck of a lot).
Nick, I'm sure you've found yourself in a situation where someone comes to you for technical assistance telling you that something "does not work". "What do you mean" you may ask. In this case is the description wrong or do you have a sample of what it is that doesn't work?
REVECTOR can only work when a word has a vector as in the case of bytecode constructed from opcodes, the kernel opcodes themselves do not have vectors so you can't revector DUP for instance.
Here is a quick demonstration of REVECTOR at work changing the low-level SPACE word to print a dot instead:
: DOT "." EMIT ; ok
DOT . ok
REVECTOR SPACE DOT. ok
0 20 DUMP.
0000_0000: 00.B4.C4.04. 6E.4E.10.00. 78.7E.80.7E. 4C.7E.84.7E. ....nN..x~.~L~.~
0000_0010: 68.7E.02.00. 3C.7E.00.00. B3.5B.70.01. 82.00.00.00. h~..<~...[p..... ok
.STATS.
NAMES: $5C8C...74CF for 6211 (3758 bytes added)
CODE: $0000...35CE for 7563 (7374 bytes added)
CALLS: 0446 vectors free
RAM: 9918 bytes free
ok
seems the END statistics has problem after a RECLAIM
{Reclaimed 1,552 bytes
NAMES: $557A...7442 for 7880 ([B][COLOR=#ff0000]4294965744[/COLOR][/B] bytes added)
CODE: $0000...4CAE for 11750 (4294967286 bytes added)
CALLS: 0122 vectors free
RAM: 2252 bytes free
after load
NAMES: $54F8...7442 for 8010 ([B][COLOR=#ff0000]4294965874 [/COLOR][/B]bytes added)
CODE: $0000...4D42 for 11768 (0148 bytes added)
CALLS: 0102 vectors free
RAM: 1974 bytes free
}
An unintended side effect of RECLAIM but the GoogleDocs version of EXTEND at least printed this out as a signed number
Sometimes "helpful" information like this can be a bit awkward to report, as when do you count it being added and from what point etc. I think I may look at tidying this up a little and also only have it reporting after changes are made then muting any results thereafter. So perhaps even a new definition could report it's size.
Watched your videos and downloaded to my C3. Very impressive and FAST. Played with Forth back in the TRS 80 days and found I didnt retain much over the years. Still playing and have set it to the VGA port on the C3. Where would I look for that?
Watched your videos and downloaded to my C3. Very impressive and FAST. Played with Forth back in the TRS 80 days and found I didnt retain much over the years. Still playing and have set it to the VGA port on the C3. Where would I look for that?
Nice work BTW!!!!!
If you follow the links in my sig you will find source code, binaries, and more links to the early VGA versions up to the most recent. The early versions included VGA as it was still a nascent kernel and quite small but with only 32K of RAM to play with the bit-mapped VGA made it impossible to add all the extra functionality that was later added. I may include a small text based VGA driver in my upcoming runtime OBEX but I'm leaving all the fancy memory hungry VGA stuff for P2 when I can implement a fully self-hosted development system which can also compile/assemble new kernels.
Hello, who is the SD-Karte on the PIN for Tachyon from Propeller?
DO DI CLK CS ?
greeting
The pin configuration for an SD card is near the top of SDCARD.fth:
IFNDEF &SDCS
#P26 |< == &SDCS \ SDCARD CS
#P27 |< == &SDDO \ Data out from SDCARD
#P28 |< == &SDCK \ SDCARD clocks (Shared with SCL)
#P29 |< == &SDDI \ Data to SDCARD (Shared with SDA)
}
Change the #Pxx to whatever you want. I just figured this out 15 minutes before seeing your question.
@Peter Jakacki:
I want to use Tachyon for something resembling a home security/monitoring system. I've come up with several questions while looking at Tachyon's guts:
Why don't the SD card and Wiznet drivers run in their own PASM cogs? Wouldn't that be way faster? I was playing with your Tachyon website demo, and it seemed really slow, but that might have only been because too many people were trying to use it at once. I'm experimenting with adding PASM drivers now, even though it's probably not a good beginner's project for someone just starting FORTH.
Also, what's with the huge line delays? Are they really necessary? What's the shortest I can safely make them? It took much longer than my patience lasts for file transmission, probably around 10-20 minutes, for me to send EXTEND.fth to my propeller at 115200 baud with 20ms line delays. What's the absolute minimum for line delays? If it's to allow stuff you're dumping into it to take a while to run loops and such, could you consider adding soft flow control to the serial driver as an alternative, so delays only happen when necessary? If I get around to adding soft flow control to the serial driver, I'll give you the patch.
TRIM byte 0[$wxyz - $] should be as big as possible to still fit in hubram, right? What if it's not as big as possible? Does some ram near the top or somewhere else get wasted or what?
The pin configuration for an SD card is near the top of SDCARD.fth:
IFNDEF &SDCS
#P26 |< == &SDCS \ SDCARD CS
#P27 |< == &SDDO \ Data out from SDCARD
#P28 |< == &SDCK \ SDCARD clocks (Shared with SCL)
#P29 |< == &SDDI \ Data to SDCARD (Shared with SDA)
}
Change the #Pxx to whatever you want. I just figured this out 15 minutes before seeing your question.
@Peter Jakacki:
I want to use Tachyon for something resembling a home security/monitoring system. I've come up with several questions while looking at Tachyon's guts:
Why don't the SD card and Wiznet drivers run in their own PASM cogs? Wouldn't that be way faster? I was playing with your Tachyon website demo, and it seemed really slow, but that might have only been because too many people were trying to use it at once. I'm experimenting with adding PASM drivers now, even though it's probably not a good beginner's project for someone just starting FORTH.
Also, what's with the huge line delays? Are they really necessary? What's the shortest I can safely make them? It took much longer than my patience lasts for file transmission, probably around 10-20 minutes, for me to send EXTEND.fth to my propeller at 115200 baud with 20ms line delays. What's the absolute minimum for line delays? If it's to allow stuff you're dumping into it to take a while to run loops and such, could you consider adding soft flow control to the serial driver as an alternative, so delays only happen when necessary? If I get around to adding soft flow control to the serial driver, I'll give you the patch.
TRIM byte 0[$wxyz - $] should be as big as possible to still fit in hubram, right? What if it's not as big as possible? Does some ram near the top or somewhere else get wasted or what?
Thanks,
electrodude
20 ms line delay is not 20 ms character delay which should be zero, a common mistake. XON/XOFF is not properly supported on PCs it seems, they just never seem to respond since they have such huge FIFOs which do not look ahead for XOFFs.
As for the website demo I just brought it up on another PC over a weak wifi link and it came up instantly and just the other day I did the same from a remote location without any problems. But the webserver can only handle one connection at a time since the TCP/IP stack is implemented in the WIZnet although it is possible to open a socket in raw mode but then there is a lot more processing to do then.
Tachyon can work out of one cog without having to startup another cog just for a PASM function which even if it were in another cog would still require passing commands to it and waiting for responses. In many cases it is just as easy to call the function directly in the same cog which also doesn't have any problems with I/O pin conflicts that can result. Of course I could come up with a grand and complicated scheme but what am I trying to achieve then? I have a fast and fully functional system already.
Now "little grasshopper", take your time and when you find that you can't understand why it's done a certain way or why it isn't working the way you think it should then think that there must be good reason for it, and if there isn't, you will find out why. Once you take the time to find out why then you start to understand. You may start trying to improve what you don't understand but will you really improve it then? The idea with Tachyon is that you don't need to write special PASM drivers, that Forth is fast enough to tackle the I/O directly or in unison with a RUNMOD which is really just a microcoded instruction anyway.
Just getting back to the pin defintion file, it's usually best to define your own PCB (hardware definitions) file a bit like the QS.fth example so that you are not modifying a generic SDCARD.fth file directly. The defaults in SDCARD are simply in case no other pins have been defined. That way you can always use the very latest support files without modifications.
As for TRIM it is there to put the dictionary and buffers/cog image up at the top of memory where the dictionary grows down while the code space grows upwards. That space that's in there gets used as you add more modules and your application.
Now "little grasshopper", take your time and when you find that you can't understand why it's done a certain way or why it isn't working the way you think it should then think that there must be good reason for it, and if there isn't, you will find out why. Once you take the time to find out why then you start to understand. You may start trying to improve what you don't understand but will you really improve it then? The idea with Tachyon is that you don't need to write special PASM drivers, that Forth is fast enough to tackle the I/O directly or in unison with a RUNMOD which is really just a microcoded instruction anyway.
Oh I've been here befor with Tachyon a few times, "Use the source Luke"
Comments
Never mind, found it.
Try QWORDS just for a quick and compact words listing or even QW just for those last 100 or so words.
There''s also HELP <word> which in the next version will also list the stack and description etc (as long as you have >32K EEPROM or SD). Maybe I might even have it find the source for the word and list it if it's loaded onto a file.
LIKE <word> WORDS/QWORDS/QW will list all words which have the same attributes such as kernel or extended kernel etc words.
ANY <char> WORDS/QWORDS/QW will list any words that have a matching character
MY WORDS/QWORDS/QW will just list the latest module words
MATCH <chars> WORDS/QWORDS/QW will list matching words that start with the same characters
All these may be replaced with a more general pattern mask when I get a round tuit.
I can see by your post though that I may need to implement WHICH WORDS just to find out what you are talking about
(I may need to check the operation of these controls as I haven't used them in some time)
Lately I have been fooling around with very tiny WR703N and MR3020 wireless routers as a means to load and communicate with my Propeller Protoboard. They are about 2 inches by 2 inches by 1/2 inch high.
http://wiki.openwrt.org/toh/tp-link/tl-wr703n
Yesterday, I managed to get my tiny MR3020 to download and install Tachyon V2.1 via the wifi, and then to bring up the Tachyon prompt. I did have to use a USB2SER on the USB port, but am working also on just a straight ttl RS232 setup from the MR3020 to the Propeller.
So it seems a nice fit for Forth over wifi.
These devices are only about $20USD, consume about 0.6 watts at 5VDC. and have OpenWrt firmware modifying them into a very handy custom wifi router. Someone has even claimed to use solar cells to power the wifi router, certainly seems easy enough to do.
Heater recompiled propeller-load, a command line binary loader that sits inside the wifi router's Linux OS. So it makes it possible to SCP a binary to the router, and then load it to the Propeller. I also loaded Minicom and an FTDI USB serial driver into the router, and that completes the set up to allow active Tachyon from afar.
I think I am going to enjoy this a lot. You can have a Propeller attached to anything and sitting anywhere. When you want to change something, you bring up the wifi router, enter Minicom, and you are into Tachyon of the device.
OpenWrt also adds another dimension to Tachyon as wifi can be deployed in a variety of ways to network Propellers.
I try to keep the precompiled kernel tight, just the minimum that's required as it's easy to write Forth in Forth rather than as "bytes" within the rather limited Spin/PASM compiler. So always consider EXTEND.fth as part of the kernel that although it gets compiled by the 1st stage kernel, it is nonetheless the other half of the kernel, albeit that there is a lot of extra stuff in there. Remember too that the EEPROM utilities are all defined in EXTEND.fth and you really need that too.
I actually did try loading EXTEND.fth but the load failed somewhere in the middle. This is probably due to using the CoolTerm terminal emulator on the Mac. I tried setting the line delay to 20ms as suggested in your document but I'm not sure that was enough. Is it possible that I also need to add a character delay? Is there any way to create a copy of Tachyon with EXTEND.fth preloaded without having to blast characters over the serial connection?
I normally use 12ms line delay and never ever a character delay but as for having EXTEND preloaded that's what the binary images are for in the DropBox. I may just update this too but there is a fairly recent one there in the binaries folder from the 8th which just includes EXTEND.fth. The startup automatically detects 5 or 10MHz crystal configurations and adjusts the PLL accordingly. Default baud is 230400 of course.
BTW, very early versions of Tachyon had WORDS and extras precompiled but as mentioned this is much better handled by Forth itself.
Thanks for your help!
David
Once you load the binary you can still load in your own EXTEND.fth version and any other modules etc. Normally the modules all start with a FORGET <this module> command in case it already exists so there is no need to do anything special. However EXTEND.fth is really part of the kernel so if you try to load it in when it is already loaded it will perform a COLD which will reset the kernel in RAM back to it's precompiled state. If you want to create your own binary you can us the DUMPROM command which will fix the boot checksum in EEPROM and dump the EEPROM as a Intel hex file. I normally just copy this into a text file and save it as a .HEX file and run a HEXBIN utility then rename the BIN file to .binary to keep the Spin tool happy. Of course if you an SD card in your system then it is far simpler as you just type SAVEROM into a empty FIRMWARE.ROM file. Again, if you have EASYNET loaded and running you can easily read the FIRMWARE.ROM file over FTP and in fact this is also one way in which I disseminate new firmware.
David
Hi David,
while Peter is surely right...
the curious mind whats to know.
You can easily search the kernel source for DICTIONARY to see the words.
In doing this I every now and then discover a 'new' word, which is not part of my active vocabulary yet.
so it's very educating too
btw: the Tachyon scriptable dynamic webserver with AJAX will be there soon.
AND: please, again, all of you - choose meaningful post titles - just click 'REPLY to THREAD' instead of REPLY to previous unrelated post !!!
This is exactly what I was looking for recently, just bumping this for safe keeping.
I got a message in the middle saying this:
Is this a problem?
Thanks,
David
why only to an unexpanded Propeller ??
the more the Propeller gets expanded the better:
WizNet -> NW, FTP, TELNET, HTTP
Loads of Sensors & Actors
PWM
Motor Controller
...
I forgot SD Filesystem, 4GB virtual memory
I've now got my Propeller1 running over a wifl link in anticipation of doing the same with a Propeller 2. Not much else to report as I do have to really settle in and catch up will all Peter J has created (and that is a heck of a lot).
seems the END statistics has problem after a RECLAIM
{Reclaimed 1,552 bytes NAMES: $557A...7442 for 7880 ([B][COLOR=#ff0000]4294965744[/COLOR][/B] bytes added) CODE: $0000...4CAE for 11750 (4294967286 bytes added) CALLS: 0122 vectors free RAM: 2252 bytes free after load NAMES: $54F8...7442 for 8010 ([B][COLOR=#ff0000]4294965874 [/COLOR][/B]bytes added) CODE: $0000...4D42 for 11768 (0148 bytes added) CALLS: 0102 vectors free RAM: 1974 bytes free }The REVECTOR command does not work as described.
NickL
you need to be more specific.
What system configuration and SW loaded.
Example of percieved problem.
Nick, I'm sure you've found yourself in a situation where someone comes to you for technical assistance telling you that something "does not work". "What do you mean" you may ask. In this case is the description wrong or do you have a sample of what it is that doesn't work?
REVECTOR can only work when a word has a vector as in the case of bytecode constructed from opcodes, the kernel opcodes themselves do not have vectors so you can't revector DUP for instance.
Here is a quick demonstration of REVECTOR at work changing the low-level SPACE word to print a dot instead:
An unintended side effect of RECLAIM but the GoogleDocs version of EXTEND at least printed this out as a signed number
Sometimes "helpful" information like this can be a bit awkward to report, as when do you count it being added and from what point etc. I think I may look at tidying this up a little and also only have it reporting after changes are made then muting any results thereafter. So perhaps even a new definition could report it's size.
Watched your videos and downloaded to my C3. Very impressive and FAST. Played with Forth back in the TRS 80 days and found I didnt retain much over the years. Still playing and have set it to the VGA port on the C3. Where would I look for that?
Nice work BTW!!!!!
If you follow the links in my sig you will find source code, binaries, and more links to the early VGA versions up to the most recent. The early versions included VGA as it was still a nascent kernel and quite small but with only 32K of RAM to play with the bit-mapped VGA made it impossible to add all the extra functionality that was later added. I may include a small text based VGA driver in my upcoming runtime OBEX but I'm leaving all the fancy memory hungry VGA stuff for P2 when I can implement a fully self-hosted development system which can also compile/assemble new kernels.
DO DI CLK CS ?
greeting
The pin configuration for an SD card is near the top of SDCARD.fth:
IFNDEF &SDCS
#P26 |< == &SDCS \ SDCARD CS
#P27 |< == &SDDO \ Data out from SDCARD
#P28 |< == &SDCK \ SDCARD clocks (Shared with SCL)
#P29 |< == &SDDI \ Data to SDCARD (Shared with SDA)
}
Change the #Pxx to whatever you want. I just figured this out 15 minutes before seeing your question.
@Peter Jakacki:
I want to use Tachyon for something resembling a home security/monitoring system. I've come up with several questions while looking at Tachyon's guts:
Why don't the SD card and Wiznet drivers run in their own PASM cogs? Wouldn't that be way faster? I was playing with your Tachyon website demo, and it seemed really slow, but that might have only been because too many people were trying to use it at once. I'm experimenting with adding PASM drivers now, even though it's probably not a good beginner's project for someone just starting FORTH.
Also, what's with the huge line delays? Are they really necessary? What's the shortest I can safely make them? It took much longer than my patience lasts for file transmission, probably around 10-20 minutes, for me to send EXTEND.fth to my propeller at 115200 baud with 20ms line delays. What's the absolute minimum for line delays? If it's to allow stuff you're dumping into it to take a while to run loops and such, could you consider adding soft flow control to the serial driver as an alternative, so delays only happen when necessary? If I get around to adding soft flow control to the serial driver, I'll give you the patch.
TRIM byte 0[$wxyz - $] should be as big as possible to still fit in hubram, right? What if it's not as big as possible? Does some ram near the top or somewhere else get wasted or what?
Thanks,
electrodude
20 ms line delay is not 20 ms character delay which should be zero, a common mistake. XON/XOFF is not properly supported on PCs it seems, they just never seem to respond since they have such huge FIFOs which do not look ahead for XOFFs.
As for the website demo I just brought it up on another PC over a weak wifi link and it came up instantly and just the other day I did the same from a remote location without any problems. But the webserver can only handle one connection at a time since the TCP/IP stack is implemented in the WIZnet although it is possible to open a socket in raw mode but then there is a lot more processing to do then.
Tachyon can work out of one cog without having to startup another cog just for a PASM function which even if it were in another cog would still require passing commands to it and waiting for responses. In many cases it is just as easy to call the function directly in the same cog which also doesn't have any problems with I/O pin conflicts that can result. Of course I could come up with a grand and complicated scheme but what am I trying to achieve then? I have a fast and fully functional system already.
Now "little grasshopper", take your time and when you find that you can't understand why it's done a certain way or why it isn't working the way you think it should then think that there must be good reason for it, and if there isn't, you will find out why. Once you take the time to find out why then you start to understand. You may start trying to improve what you don't understand but will you really improve it then? The idea with Tachyon is that you don't need to write special PASM drivers, that Forth is fast enough to tackle the I/O directly or in unison with a RUNMOD which is really just a microcoded instruction anyway.
Just getting back to the pin defintion file, it's usually best to define your own PCB (hardware definitions) file a bit like the QS.fth example so that you are not modifying a generic SDCARD.fth file directly. The defaults in SDCARD are simply in case no other pins have been defined. That way you can always use the very latest support files without modifications.
As for TRIM it is there to put the dictionary and buffers/cog image up at the top of memory where the dictionary grows down while the code space grows upwards. That space that's in there gets used as you add more modules and your application.
Oh I've been here befor with Tachyon a few times, "Use the source Luke"