Peter,
How do you use the binary version (load it into the prop & start it)? I am a novice.
Thanks
Tom
just open the binary file in Spin-Tool or BST (I and PEter use)
and do program / load RAM / load EEPROM
then set correct baud rate in terminal (for Explorer 1115200) and type ctl-c
then it should say hello to you
Ray,
Regarding the time it takes to load "extend", be sure that you only have an end of line delay in terraterm, not for each character. The first time I tried it I also had the chacter delay and it took forever to load extend (I eventually just exited it.) But when I tried with only end-of-line-delay, it went much faster and only took a couple of minutes.
Tom
- yes NO char delay
- line delay you can experiment - 20ms should easily do it -
I think Peter gave a even lower number recently.
part of the Forth way is to 'think' less ;-) and just try more :-)
do it - don't think and talk about
Have not tested that just yet by doing a reset.
just ctl-c no need to have 2nd thougts - and you know in seconds
Now I know that the word "fast" has been used to describe Tachyon, but as you start adding on the different .fth files, especially extend.fth, I would imagine that would make the kernel "bloated" and in turn start to run a "little" on the slow side, I would think.
you think ?? - try
NO, the kernel does not get "bloated"- just functionality added.
if you do not use this additions it will NOT be any slower.
and IF you use it - you are happy those are already there - and you save the time to write it.
also I learnt a lot just reading Peter's code (Kernel = Tachyon.spin, Extend.fth etc.)
But since the Prop only has 32k your memory might get full at some time.
Just look at a 'full' configuration with:
Extend, CD, Filesystem, Network, dynamic scriptable Webserver, FTP, Telnet, Email-sender, 1-Wire, I2C, SPI, RGB-LED ... , now VGA - and still space for your application.
And this without external memory !! (without external RAM I should say - SD-Card is very helpful)
So, to maximize the efficiency of Tachyon, you would have to be using the minimal amount of .fth updates, and those files would have to be some very tight code.
no need to think about efficiency unless you spent quite some hours working with it - and start to 'really' understand it. It is VERY efficient ;-)
Something else I noticed, while the extend.fth file was being loaded, what pins is the uSD assigned too? At the end of the file it looks like 9,10,11,12 are being used. So, using different boards might conflict with the default pin assignments?
it is a oneliner to change the configuration to your board -
and for many boards there are config files to load (see Peter's dropbox link in his Signature)
Now, the next thing I will try is the new VGA binary, as soon as I find a suitable VGA monitor.
Ray
have a lot of fun :-)
(p.s. I was new to Forth & the Prop when Peter published his first Tachyon - it actually helped me learn PASM - just reading the Kernel souece code in Tachyon.spin - can only recommend it)
- now that I reread what I wrote ..hmm... if it should sound a bit offensive - ... that's not my intention ;-)
No offense taken, I have been around here a long time, my skin gets thicker and thicker with each passing day.
I gave the new VGA binary a try, and 50/50. First I started with the C3 tried with two different VGA monitors, and no success. It must be the way the VGA is handled on the C3 that does not work with Tachyon.
I did have success with the QS+HIB setup, I guess Tachyon and the QS+HIB board were able to communicate. Since the BIGCLOCK program hogs the processor, I tried BIGCLOCK RUN, hoping it would be in the background and in the terminal I could still do some things(tasking), that did not work. Well at least I got the BIGCLOCK to run on the QS+HIB setup. I guess somebody with a C3 board will have to figure out how to get access to the VGA port.
I mentioned I tried with two monitors, one was a TV set with a VGA port, having the TV set in VGA mode, neither the C3 nor the QS+HIB board worked. I was hoping to have the TV set work though.
I guess with nobody jumping in with a C3 board, that knows how to use Tachyon, I am not so sure if I should pursue that board any further, but I sure like the idea of maybe Tachyon being able to use all the memory that is available in the C3 to really make it a monster of a system.
Ray
Peter,
How do you use the binary version (load it into the prop & start it)? I am a novice.
Thanks
Tom
Oh good, someone who wants to try the binary, please!
Click on and download VGA-EXPLORER-CLOCK7X9.binary for instance but there are other binaries in the link in my sig. Then assuming you have Prop tool installed you can double click on the binary file and it should open in the Prop tool with a dialog to load to {RAM] or [EEPROM]. So click EEPROM and after it is done open a terminal such as TeraTerm at 115.2k 8N1 and start talking to Forth. If you have VGA attached you can even type MAIN to see the digial clock running etc or type lshw to scan and list the hardware details.
No offense taken, I have been around here a long time, my skin gets thicker and thicker with each passing day.
I gave the new VGA binary a try, and 50/50. First I started with the C3 tried with two different VGA monitors, and no success. It must be the way the VGA is handled on the C3 that does not work with Tachyon.
I did have success with the QS+HIB setup, I guess Tachyon and the QS+HIB board were able to communicate. Since the BIGCLOCK program hogs the processor, I tried BIGCLOCK RUN, hoping it would be in the background and in the terminal I could still do some things(tasking), that did not work. Well at least I got the BIGCLOCK to run on the QS+HIB setup. I guess somebody with a C3 board will have to figure out how to get access to the VGA port.
I mentioned I tried with two monitors, one was a TV set with a VGA port, having the TV set in VGA mode, neither the C3 nor the QS+HIB board worked. I was hoping to have the TV set work though.
I guess with nobody jumping in with a C3 board, that knows how to use Tachyon, I am not so sure if I should pursue that board any further, but I sure like the idea of maybe Tachyon being able to use all the memory that is available in the C3 to really make it a monster of a system.
Good grief Charlie Brown, two others plus myself have spelt out "LINE delay, NOT character delay" (just refreshed the forum and see some other replies). I just tried mine with a LINE delay of 8 ms and the EXTEND took 50 seconds to download at 115.2k baud.
Anyway, EXTEND.fth has a lot of functions in it but the SDCARD stuff you have to load on top of that with SDCARD.fth (8 secs to load) and the FAT32.fth file handlers (20 secs to load). For the C3 I have modified SDCARD.fth but I haven't tested that part of it yet.
Just read your post regarding the VGA. I remember now that the C3 VGA has a buffer chip that needs to be enabled.Looks like P15 has to be pulled low so just tell it to with: 15 LOW
Then your VGA should spring to life. However nowhere did I say "BIGCLOCK RUN" that is NOT what you do. Just type MAIN, that's all as it will tell it to run in another cog etc.
In fact the definition for main is like this:
pub MAIN uemit ~ ' ?RTC +POLL httime ~ ' BIGCLOCK 3 RUN ;
So the ' tick word "immediately" reads the next word and returns with its run address after which I specify cog 3 to RUN. The parameters for RUN are ( addr cog -- ).
BTW, I have boards which fully utilize the Prop and include Ethernet as well. The C3 is trying to be a do-all and general-purpose at the same time, with only 32 I/O lines you have to make a choice, one or the other. Fortunately my systems normally allow for various modules to be plugged in so it ends up being general-purpose enough to be different special-purpose boards. I do like plug in modules or pcb breadboards (pcbs with plated through holes), I think they are a much better idea than a fixed breadboarding area which would leave it hard to rework and messy too. The breadboard module can just be plugged into another board and later on replaced with a proper PCB module.
NOTE: A fully loaded Tachyon system normally cannot fit into 32k of RAM but I have a method of moving the bulky dictionary up into the top 32k of a 64k EEPROM which is what is normally fitted these days. Even though EEPROM would be too slow to search through for each word I have a hashing scheme so blocks of words can be indexed and that block searched almost as fast as if it were all in RAM since we are now only scanning through a small block rather than the whole dictionary. So having the dictionary out of the way in upper EEPROM then frees up the precious 32k of RAM for actual code and buffers etc. Also the Prop normally has the images it loads in cogs (think of objects like VGA and serial etc) in that 32k of RAM which is rather wasteful after it's done it's job of loading that 2k or less (COGINIT/COGNEW) for each one into the cogs, but I reuse the area for buffers. In the case of the Tachyon PASM kernel it's hub area is reused for general buffers or for up to 4 open files at a time. The serial object gets reused as a serial buffer, the VGA object gets reused as a VGA buffer.
I just tried out '15 LOW' for the VGA, and then 'MAIN' on the C3, and it works. Now the mystery for the C3 VGA has been solved :-). I also noticed that when the VGA got invoked, having LEDs on P16 and P17, they lit up. I guess that means if you will be using the VGA, on the C3, the P16 - P23 pins will not be available, so that leaves you with P0 - P7 to work with. Not complaining, just pointing it out.
Peter, have you ever considered creating a softRTC? I guess that way you could have a more functional BIGCLOCK demo. I know it would probably be at the cost of another COG. Now that I found out that when you use the VGA, on the C3, you are now getting to be very limited on available IO pins.
I must say, I have been experimenting with Tachyon for a few days, and Forth does have some subtle quirks, that could be a problem in some large WORD creations. Lets see, PRINT", ' RUN, just to name a few, and I am just getting started. Oh, and the space before the ';', would be another big one.
Yesterday I was trying to get a handle on how to use ' RUN, which eventually I got to work. Since I have an LED on P16 and P17, I was trying to get them to RUN in separate COGs, continuously, which I finally accomplished using 16 BLINK and 17 BLINK. How do you stop a COG once it has been started, other than the reset button?
Today I am thinking about using the ' RUN for a continuous BLINK16 and BLINK17 word, but I set the duration times between the blinks. Both LEDs have to be blinking when started, in there separate COGs, and of course, it would be nice to a clean solution for stopping the COGs.
Ray
Good to hear then but running out of I/O pins is a Prop thing, nothing to do with the software, there are no magic bunnies I can pull out of the hat for that one I'm afraid to say. The only reason I can think of for the C3 to have LEDs in common with the VGA drive lines when it would have been way easier to stick them on an I2C port and save a pin is that this is a board for "education" and that wouldn't be complete without the tired old blinky LEDs. What a waste and it complicated the VGA circuit as it also complicated the SD card select too.
You mentioned a soft RTC and up until a couple of months ago I always had one sitting there but never used it and the trouble is that you have to manually set it after each reset so it would only be good for demos in my opinion. But the soft RTC was run from the timer cog (7) which is maintaining countdown timers and alarms etc so it's easy enough to put it back in I guess except I will integrate it better with the I2C RTC routines because I've been thinking that I could have the system check to see if there is an I2C RTC and possibly determine which one it is or else fall back to the soft RTC. In fact you can blink LEDs from those countdown timers like this:
TIMER blinker
pub BLINKY 500 blinker TIMEOUT 7 PIN@ IF 7 LOW ELSE 7 HIGH THEN ;
' BLINKY blinker ALARM --- setup the "blinker" timer to execute BLINKY when it times out.
To start it up the simplest way would be to just type BLINKY which will also load up the timer for the first time (it links into the list of timers dynamically) and for every 500 ms it will run BLINKY again. If you want to stop it then the simplest way would be: 0 blinker TIMEOUT which will stop that timer. Of course you could run a blinky in a cog but what a waste. BTW, there is also 32-channel PWM engine built into Tachyon that launches into a cog when invoked and maintains up to 32 channels of 8-bit PWM at up 7.6kHz. This PWM is table driven and you can get it to create arbitrary waveforms etc, even "blinks" automatically.
Thanks Peter, about your new blinker example. I see the necessary ';' , but I do not see a leading ':'. Is there something different when you use 'pub'?
On my QS board setup, I am using a softRTC, and I am very familiar with the hassle of inputting the new data on a new restart. But for experimentation purposes, it is better than nothing at all. Now that I think about it, isn't the Propeller philosophy all about soft peripherals?
Now I am thinking about how I can use Tachyon to replicate what I am doing with my QS board setup. On the QS board setup I am using PropGCC to provide a user IO session, meaning when they start a session via direct or via XBee, you type in some commands like 'tempf' to get a reading from the sht11 module, of course 'time' to get the real time reading from the softRTC. At this time, not knowing Forth at all, it seems like that could be a very awkward coding situation, let alone was Forth designed to accomplish anything like that in any efficient manner. I am now really considering getting away from using XBee and going strictly hardline, with maybe an RPi in the mix to get some LAN access. So that might present another aspect that would have to be considered.
Ray
Thanks Peter, about your new blinker example. I see the necessary ';' , but I do not see a leading ':'. Is there something different when you use 'pub'?
pub and pri for public/private are essentially ":" with the option to have some private headers removed after the module is compiled to save dictionary space. This also helps to show which words are intended for public use, and which you better not touch unless you exactly understand what is going on.
provide a user IO session, meaning when they start a session via direct or via XBee, you type in some commands like 'tempf' to get a reading from the sht11 module, of course 'time' to get the real time reading from the softRTC.
that is exactly what the Forth prompt/command line interpreter is all about.
it's there
and it's free
and it's powerful
and it's extensible
and it's wonderful
...
At this time, not knowing Forth at all, it seems like that could be a very awkward coding situation, let alone was Forth designed to accomplish anything like that in any efficient manner. I am now really considering getting away from using XBee and going strictly hardline, with maybe an RPi in the mix to get some LAN access. So that might present another aspect that would have to be considered.Ray
just take Peter's 'getting started' document line by line
and when you are done you will know a lot more
Thanks Peter, about your new blinker example. I see the necessary ';' , but I do not see a leading ':'. Is there something different when you use 'pub'?
On my QS board setup, I am using a softRTC, and I am very familiar with the hassle of inputting the new data on a new restart. But for experimentation purposes, it is better than nothing at all. Now that I think about it, isn't the Propeller philosophy all about soft peripherals?
Now I am thinking about how I can use Tachyon to replicate what I am doing with my QS board setup. On the QS board setup I am using PropGCC to provide a user IO session, meaning when they start a session via direct or via XBee, you type in some commands like 'tempf' to get a reading from the sht11 module, of course 'time' to get the real time reading from the softRTC. At this time, not knowing Forth at all, it seems like that could be a very awkward coding situation, let alone was Forth designed to accomplish anything like that in any efficient manner. I am now really considering getting away from using XBee and going strictly hardline, with maybe an RPi in the mix to get some LAN access. So that might present another aspect that would have to be considered.
Ray
I started using pub and pri in place of the plain : for two reasons, one so that it would be obvious to Prop users that this was a definition in the same way Spin is coded and also for the reason that since my headers (the name and pointers) are compiled into a separate area rather than inline like most Forths, I am able to specify whether this name needs to be kept in case I need to free up memory afterwards. There is a RECLAIM word which finds all the names marked by pri and strips them from the dictionary while reclaiming the memory. But there is no reason you can't use : although I am finding that there are a lot of traditional Forth symbol words that are hard to see in some fonts, words such as . are also aliased with more verbose names such as PRINT etc. BTW, the aliases don't take up any code space, they simply duplicate the pointers and attributes of the word they alias.
What do you mean by "awkward coding situation"? I thought that the GCC user IO session would have been awkward whereas any such "IO" is built-in and natural with Forth. If you connect your XBee to the console port as I do Bluetooth for instance, then you have access to all the hardware and software. To read the time you use one of the words already there such as .TIME or .DT to print a formatted date and time like this:
.DT 2015/07/30 THU 23:52:06 ok
You can even program/edit/debug over XBee all you like.
As for LAN access it is very easy to connect a WIZnet module such as my IoT5500 to the Prop assuming you have 4 I/O to spare and Tachyon has EASYNET to provide WEB/FTP/TELNET servers for starters.
There is even a stack-on Prop board to control this module and also has microSD so you can just talk to it serially.
I was doing some things this morning and I used .TASKS, just curious, what happened to 0001:?
I was also reading the section on "REDIRECTING OUTPUT", now that I have the VGA working on the C3, how would you redirect some output to the VGA monitor? I was thinking of something dumb like a word that starts the LED blinking and then shows a message on the VGA screen that the LED is blinking. I guess later on you could add a time that the LED started blinking.
If I were to attach an XBee, my XBee is set to 9600 BAUD, and I do not want to change it, how would you get Tachyon to start up at 9600 BAUD, without changing the Spin code? And of course I would want to reset it back to the default of 115200, in an easy manner.
Ray
Some of these debug words are not as comprehensive as they could be only because we are working with limited resources and unimportant details are left out. The .TASKS word is only checking the Tachyon task list, it can't really tell what's going on if a cog has been loaded with something else, in this case cog 1 runs the serial receive for the console.
If you look at some of the examples you can see that redirecting output is just that as anything/everything that ends up sending to the console can be redirected to another device. There are no kludgey special-purpose vga.cr or vga.printdec etc but instead the output device understands the control characters etc, just as if you plugged into a real device via a serial port.
For instance if you type VGA .TASKS CON it will display the task list on the VGA monitor (with line wrap). Notice however that after .TASKS I had a CON, well that's because we want Tachyon to return to the default I/O device, the serial CONsole. If I had left that out then it would stay with the VGA monitor, you can try it if you want, just enter VGA and see all the Forth output being redirected to the VGA monitor and if it were 80 characters wide it would be quite usable, and I am thinking of doing this too.
To change the console baud rate just type 9600 CONBAUD and it will lock in so that after the reset it will come up at 9600 baud. You can reset Tachyon from the console with a ^C or if you happen to have it stuck in some routine you can send a break which in TeraTerm is a <alt>B IIRC or in minicom ^A F
BTW, there is no real Spin code in the Tachyon kernel, just PASM or bytecodes, and only a few lines of Spin for launch the cogs.
Thanks Peter for your latest explanation. I did a 'QWORDS' and I guess in Forth talk, there were quite a few words in the Tachyon dictionary. Does anybody have a file that lists all the words in a manageable manner? It seems that getting a handle on the definition of the existing words would be a good logical step.
I tried the 'VGA TASKS. CON', it worked as expected but, it looked kind of klunky , on the screen. Now if you could manage the chars width and amount of lines of the output...
Lets say that you create a new word definition, is there way to edit that definition or do you have to redo the word again? Also is there a way to see exactly how many new words were created, and maybe delete them?
Ray
Thanks Peter for your latest explanation. I did a 'QWORDS' and I guess in Forth talk, there were quite a few words in the Tachyon dictionary. Does anybody have a file that lists all the words in a manageable manner? It seems that getting a handle on the definition of the existing words would be a good logical step.
Ray
Hi Ray,
I recommend to download the source files Tachyon.spin plus the *.fth files.
Load them all in an editor e.g. Notepad++ and then just go reading the code.
And serach helps find the cross references.
The code is partly - more and more - documented.
Where it is not there is the source which can tell you a lot.
Begin with Tachyon.spin, then EXTEND.fth ...
this gives a very good start once you understand all of it ;-)
I tried the 'VGA TASKS. CON', it worked as expected but, it looked kind of klunky , on the screen. Now if you could manage the chars width and amount of lines of the output..
At 32x15 it is clunky but the reason I have it is that is uses very little memory, the <1k code image size is reused as the VGA buffer so that it only requires 1k overall for the raw VGA. With VGA.fth I have added 3 different sized big digit modes to it as well as the streaming I/O handlers which interpret controls such as CR and CLS in a standard stream and all that takes 1.4k including the 5x7,6x8, and 7x9 digit fonts. So altogether that uses up 2.4k + some dictionary area, not bad and the big digit modes are really useful as in the case of the clock demo and the breakout game also demonstrates that you don't need bit-mapped graphics to run an arcade game.
Now this thing about "manage the chars width and amount of lines" makes me chuckle
Oh, if only it were that simple for all us Prop users and if the Prop had a dedicated GPU then maybe that would be all that we would need to do. The thing is that one cog can just manage so much in between each waitvid instruction and the higher resolution modes normally use two cogs working in tandem. All that is possible as we have cogs to spare but it all requires more memory, something that we would like some left over for actual applications. It's a bit like office space, sure you can pack more desks and chairs and shelves into it but you still need to sit somewhere and be able to move around, otherwise what's the point? But in regards to this I am looking to do more as I am aiming for 80x25 with a very small memory footprint. The memory just for 80x25 characters alone without any attributes etc amounts to 2k but ideally would be 4k with the current scheme of individual tile/character colors to allow for more versatility.
Lets say that you create a new word definition, is there way to edit that definition or do you have to redo the word again? Also is there a way to see exactly how many new words were created, and maybe delete them?
Each definition is compiled into bytecode, so the source does not remain in memory and although it would be possible to decompile and edit this, it is also not practical due to once again the memory constraints of the Prop. But this is not normally done in any system anyway, even ones with plenty of memory, just recompile. You may notice at the start of many of the .fth drivers that it begins with TACHYON [~ and then it ends with ]~ END. This is done for a number of reasons, even though you could do without them but they are there to identify that this is meant for Tachyon Forth and not some other Forth, and also in conjunction with the [~ it also puts it into a faster load mode showing only the line number it is up to and any messages until it reaches the ]~ END where it reports the "module" size (a module is identified by the ".fth" in the name).
Here is an example of VGA.fth being loaded the first time.
TACHYON [~ Propeller .:.:--TACHYON--:.:. Forth V27150720.2030
0501 fth not found
12:31:19 End of source code, 0502 lines processed and 0000 errors found
Load time = 7.555secs
MODULES LOADED:
3E79: VGA.fth VGA text driver 150709-2200
1A81: EXTEND.fth Tachyon Forth Propeller hardware debugger and explorer - 150727-1030
VER: Propeller .:.:--TACHYON--:.:. Forth V27150720.2030
FREQ: 80MHZ (PLLEN OSCEN XTAL1 PLL8X )
NAMES: $53C3...716B for 7,592 bytes (+536)
CODE: $0924...4411 for 15,085 bytes (+1,432)
CALLS: 284 vectors free
RAM: 4,018 bytes free
BUILD: FIRMWARE BUILD DATE 150730:081200
BOOTS: 24
BOOT: EXTEND.boot
POLL:
Now you can see that this VGA module uses 1.4k in code space and 536 bytes just in dictionary of which can be reclaimed or compacted later.
The word FORGET will forget all names from that name onwards to the latest and release the code, vectors, and dictionary memory for these. That's also why it is added to the beginning of the .fth files in case the module is already loaded and we have edited it on our computer and are now downloading it again.
Once the final P2 is available I intend to have a "version" of Tachyon for it and it has a lot more memory and resources etc available, expect to see a complete development and runtime system on a chip then.
Comments
How do you use the binary version (load it into the prop & start it)? I am a novice.
Thanks
Tom
just open the binary file in Spin-Tool or BST (I and PEter use)
and do program / load RAM / load EEPROM
then set correct baud rate in terminal (for Explorer 1115200) and type ctl-c
then it should say hello to you
Regarding the time it takes to load "extend", be sure that you only have an end of line delay in terraterm, not for each character. The first time I tried it I also had the chacter delay and it took forever to load extend (I eventually just exited it.) But when I tried with only end-of-line-delay, it went much faster and only took a couple of minutes.
Tom
- yes NO char delay
- line delay you can experiment - 20ms should easily do it -
I think Peter gave a even lower number recently.
do it - don't think and talk about
Have not tested that just yet by doing a reset.
just ctl-c no need to have 2nd thougts - and you know in seconds
Now I know that the word "fast" has been used to describe Tachyon, but as you start adding on the different .fth files, especially extend.fth, I would imagine that would make the kernel "bloated" and in turn start to run a "little" on the slow side, I would think.
you think ?? - try
NO, the kernel does not get "bloated"- just functionality added.
if you do not use this additions it will NOT be any slower.
and IF you use it - you are happy those are already there - and you save the time to write it.
also I learnt a lot just reading Peter's code (Kernel = Tachyon.spin, Extend.fth etc.)
But since the Prop only has 32k your memory might get full at some time.
Just look at a 'full' configuration with:
Extend, CD, Filesystem, Network, dynamic scriptable Webserver, FTP, Telnet, Email-sender, 1-Wire, I2C, SPI, RGB-LED ... , now VGA - and still space for your application.
And this without external memory !! (without external RAM I should say - SD-Card is very helpful)
So, to maximize the efficiency of Tachyon, you would have to be using the minimal amount of .fth updates, and those files would have to be some very tight code.
no need to think about efficiency unless you spent quite some hours working with it - and start to 'really' understand it. It is VERY efficient ;-)
Something else I noticed, while the extend.fth file was being loaded, what pins is the uSD assigned too? At the end of the file it looks like 9,10,11,12 are being used. So, using different boards might conflict with the default pin assignments?
it is a oneliner to change the configuration to your board -
and for many boards there are config files to load (see Peter's dropbox link in his Signature)
Now, the next thing I will try is the new VGA binary, as soon as I find a suitable VGA monitor.
Ray
have a lot of fun :-)
(p.s. I was new to Forth & the Prop when Peter published his first Tachyon - it actually helped me learn PASM - just reading the Kernel souece code in Tachyon.spin - can only recommend it)
- now that I reread what I wrote ..hmm... if it should sound a bit offensive - ... that's not my intention ;-)
I gave the new VGA binary a try, and 50/50. First I started with the C3 tried with two different VGA monitors, and no success. It must be the way the VGA is handled on the C3 that does not work with Tachyon.
I did have success with the QS+HIB setup, I guess Tachyon and the QS+HIB board were able to communicate. Since the BIGCLOCK program hogs the processor, I tried BIGCLOCK RUN, hoping it would be in the background and in the terminal I could still do some things(tasking), that did not work. Well at least I got the BIGCLOCK to run on the QS+HIB setup. I guess somebody with a C3 board will have to figure out how to get access to the VGA port.
I mentioned I tried with two monitors, one was a TV set with a VGA port, having the TV set in VGA mode, neither the C3 nor the QS+HIB board worked. I was hoping to have the TV set work though.
I guess with nobody jumping in with a C3 board, that knows how to use Tachyon, I am not so sure if I should pursue that board any further, but I sure like the idea of maybe Tachyon being able to use all the memory that is available in the C3 to really make it a monster of a system.
Ray
Peter,
How do you use the binary version (load it into the prop & start it)? I am a novice.
Thanks
Tom
Oh good, someone who wants to try the binary, please!
Click on and download VGA-EXPLORER-CLOCK7X9.binary for instance but there are other binaries in the link in my sig. Then assuming you have Prop tool installed you can double click on the binary file and it should open in the Prop tool with a dialog to load to {RAM] or [EEPROM]. So click EEPROM and after it is done open a terminal such as TeraTerm at 115.2k 8N1 and start talking to Forth. If you have VGA attached you can even type MAIN to see the digial clock running etc or type lshw to scan and list the hardware details.
I gave the new VGA binary a try, and 50/50. First I started with the C3 tried with two different VGA monitors, and no success. It must be the way the VGA is handled on the C3 that does not work with Tachyon.
I did have success with the QS+HIB setup, I guess Tachyon and the QS+HIB board were able to communicate. Since the BIGCLOCK program hogs the processor, I tried BIGCLOCK RUN, hoping it would be in the background and in the terminal I could still do some things(tasking), that did not work. Well at least I got the BIGCLOCK to run on the QS+HIB setup. I guess somebody with a C3 board will have to figure out how to get access to the VGA port.
I mentioned I tried with two monitors, one was a TV set with a VGA port, having the TV set in VGA mode, neither the C3 nor the QS+HIB board worked. I was hoping to have the TV set work though.
I guess with nobody jumping in with a C3 board, that knows how to use Tachyon, I am not so sure if I should pursue that board any further, but I sure like the idea of maybe Tachyon being able to use all the memory that is available in the C3 to really make it a monster of a system.
Good grief Charlie Brown, two others plus myself have spelt out "LINE delay, NOT character delay" (just refreshed the forum and see some other replies). I just tried mine with a LINE delay of 8 ms and the EXTEND took 50 seconds to download at 115.2k baud.
Anyway, EXTEND.fth has a lot of functions in it but the SDCARD stuff you have to load on top of that with SDCARD.fth (8 secs to load) and the FAT32.fth file handlers (20 secs to load). For the C3 I have modified SDCARD.fth but I haven't tested that part of it yet.
Just read your post regarding the VGA. I remember now that the C3 VGA has a buffer chip that needs to be enabled.Looks like P15 has to be pulled low so just tell it to with: 15 LOW
Then your VGA should spring to life. However nowhere did I say "BIGCLOCK RUN" that is NOT what you do. Just type MAIN, that's all as it will tell it to run in another cog etc.
In fact the definition for main is like this:
pub MAIN uemit ~ ' ?RTC +POLL httime ~ ' BIGCLOCK 3 RUN ;
So the ' tick word "immediately" reads the next word and returns with its run address after which I specify cog 3 to RUN. The parameters for RUN are ( addr cog -- ).
BTW, I have boards which fully utilize the Prop and include Ethernet as well. The C3 is trying to be a do-all and general-purpose at the same time, with only 32 I/O lines you have to make a choice, one or the other. Fortunately my systems normally allow for various modules to be plugged in so it ends up being general-purpose enough to be different special-purpose boards. I do like plug in modules or pcb breadboards (pcbs with plated through holes), I think they are a much better idea than a fixed breadboarding area which would leave it hard to rework and messy too. The breadboard module can just be plugged into another board and later on replaced with a proper PCB module.
NOTE: A fully loaded Tachyon system normally cannot fit into 32k of RAM but I have a method of moving the bulky dictionary up into the top 32k of a 64k EEPROM which is what is normally fitted these days. Even though EEPROM would be too slow to search through for each word I have a hashing scheme so blocks of words can be indexed and that block searched almost as fast as if it were all in RAM since we are now only scanning through a small block rather than the whole dictionary. So having the dictionary out of the way in upper EEPROM then frees up the precious 32k of RAM for actual code and buffers etc. Also the Prop normally has the images it loads in cogs (think of objects like VGA and serial etc) in that 32k of RAM which is rather wasteful after it's done it's job of loading that 2k or less (COGINIT/COGNEW) for each one into the cogs, but I reuse the area for buffers. In the case of the Tachyon PASM kernel it's hub area is reused for general buffers or for up to 4 open files at a time. The serial object gets reused as a serial buffer, the VGA object gets reused as a VGA buffer.
Peter, have you ever considered creating a softRTC? I guess that way you could have a more functional BIGCLOCK demo. I know it would probably be at the cost of another COG. Now that I found out that when you use the VGA, on the C3, you are now getting to be very limited on available IO pins.
I must say, I have been experimenting with Tachyon for a few days, and Forth does have some subtle quirks, that could be a problem in some large WORD creations. Lets see, PRINT", ' RUN, just to name a few, and I am just getting started. Oh, and the space before the ';', would be another big one.
Yesterday I was trying to get a handle on how to use ' RUN, which eventually I got to work. Since I have an LED on P16 and P17, I was trying to get them to RUN in separate COGs, continuously, which I finally accomplished using 16 BLINK and 17 BLINK. How do you stop a COG once it has been started, other than the reset button?
Today I am thinking about using the ' RUN for a continuous BLINK16 and BLINK17 word, but I set the duration times between the blinks. Both LEDs have to be blinking when started, in there separate COGs, and of course, it would be nice to a clean solution for stopping the COGs.
Ray
You mentioned a soft RTC and up until a couple of months ago I always had one sitting there but never used it and the trouble is that you have to manually set it after each reset so it would only be good for demos in my opinion. But the soft RTC was run from the timer cog (7) which is maintaining countdown timers and alarms etc so it's easy enough to put it back in I guess except I will integrate it better with the I2C RTC routines because I've been thinking that I could have the system check to see if there is an I2C RTC and possibly determine which one it is or else fall back to the soft RTC. In fact you can blink LEDs from those countdown timers like this:
TIMER blinker
pub BLINKY 500 blinker TIMEOUT 7 PIN@ IF 7 LOW ELSE 7 HIGH THEN ;
' BLINKY blinker ALARM --- setup the "blinker" timer to execute BLINKY when it times out.
To start it up the simplest way would be to just type BLINKY which will also load up the timer for the first time (it links into the list of timers dynamically) and for every 500 ms it will run BLINKY again. If you want to stop it then the simplest way would be: 0 blinker TIMEOUT which will stop that timer. Of course you could run a blinky in a cog but what a waste. BTW, there is also 32-channel PWM engine built into Tachyon that launches into a cog when invoked and maintains up to 32 channels of 8-bit PWM at up 7.6kHz. This PWM is table driven and you can get it to create arbitrary waveforms etc, even "blinks" automatically.
On my QS board setup, I am using a softRTC, and I am very familiar with the hassle of inputting the new data on a new restart. But for experimentation purposes, it is better than nothing at all. Now that I think about it, isn't the Propeller philosophy all about soft peripherals?
Now I am thinking about how I can use Tachyon to replicate what I am doing with my QS board setup. On the QS board setup I am using PropGCC to provide a user IO session, meaning when they start a session via direct or via XBee, you type in some commands like 'tempf' to get a reading from the sht11 module, of course 'time' to get the real time reading from the softRTC. At this time, not knowing Forth at all, it seems like that could be a very awkward coding situation, let alone was Forth designed to accomplish anything like that in any efficient manner. I am now really considering getting away from using XBee and going strictly hardline, with maybe an RPi in the mix to get some LAN access. So that might present another aspect that would have to be considered.
Ray
pub and pri for public/private are essentially ":" with the option to have some private headers removed after the module is compiled to save dictionary space. This also helps to show which words are intended for public use, and which you better not touch unless you exactly understand what is going on.
that is exactly what the Forth prompt/command line interpreter is all about.
it's there
and it's free
and it's powerful
and it's extensible
and it's wonderful
...
At this time, not knowing Forth at all, it seems like that could be a very awkward coding situation, let alone was Forth designed to accomplish anything like that in any efficient manner. I am now really considering getting away from using XBee and going strictly hardline, with maybe an RPi in the mix to get some LAN access. So that might present another aspect that would have to be considered.Ray
just take Peter's 'getting started' document line by line
and when you are done you will know a lot more
as I wrote above: try, play, do, have fun
On my QS board setup, I am using a softRTC, and I am very familiar with the hassle of inputting the new data on a new restart. But for experimentation purposes, it is better than nothing at all. Now that I think about it, isn't the Propeller philosophy all about soft peripherals?
Now I am thinking about how I can use Tachyon to replicate what I am doing with my QS board setup. On the QS board setup I am using PropGCC to provide a user IO session, meaning when they start a session via direct or via XBee, you type in some commands like 'tempf' to get a reading from the sht11 module, of course 'time' to get the real time reading from the softRTC. At this time, not knowing Forth at all, it seems like that could be a very awkward coding situation, let alone was Forth designed to accomplish anything like that in any efficient manner. I am now really considering getting away from using XBee and going strictly hardline, with maybe an RPi in the mix to get some LAN access. So that might present another aspect that would have to be considered.
Ray
I started using pub and pri in place of the plain : for two reasons, one so that it would be obvious to Prop users that this was a definition in the same way Spin is coded and also for the reason that since my headers (the name and pointers) are compiled into a separate area rather than inline like most Forths, I am able to specify whether this name needs to be kept in case I need to free up memory afterwards. There is a RECLAIM word which finds all the names marked by pri and strips them from the dictionary while reclaiming the memory. But there is no reason you can't use : although I am finding that there are a lot of traditional Forth symbol words that are hard to see in some fonts, words such as . are also aliased with more verbose names such as PRINT etc. BTW, the aliases don't take up any code space, they simply duplicate the pointers and attributes of the word they alias.
What do you mean by "awkward coding situation"? I thought that the GCC user IO session would have been awkward whereas any such "IO" is built-in and natural with Forth. If you connect your XBee to the console port as I do Bluetooth for instance, then you have access to all the hardware and software. To read the time you use one of the words already there such as .TIME or .DT to print a formatted date and time like this:
.DT 2015/07/30 THU 23:52:06 ok
You can even program/edit/debug over XBee all you like.
As for LAN access it is very easy to connect a WIZnet module such as my IoT5500 to the Prop assuming you have 4 I/O to spare and Tachyon has EASYNET to provide WEB/FTP/TELNET servers for starters.
There is even a stack-on Prop board to control this module and also has microSD so you can just talk to it serially.
I was also reading the section on "REDIRECTING OUTPUT", now that I have the VGA working on the C3, how would you redirect some output to the VGA monitor? I was thinking of something dumb like a word that starts the LED blinking and then shows a message on the VGA screen that the LED is blinking. I guess later on you could add a time that the LED started blinking.
If I were to attach an XBee, my XBee is set to 9600 BAUD, and I do not want to change it, how would you get Tachyon to start up at 9600 BAUD, without changing the Spin code? And of course I would want to reset it back to the default of 115200, in an easy manner.
Ray
If you look at some of the examples you can see that redirecting output is just that as anything/everything that ends up sending to the console can be redirected to another device. There are no kludgey special-purpose vga.cr or vga.printdec etc but instead the output device understands the control characters etc, just as if you plugged into a real device via a serial port.
For instance if you type VGA .TASKS CON it will display the task list on the VGA monitor (with line wrap). Notice however that after .TASKS I had a CON, well that's because we want Tachyon to return to the default I/O device, the serial CONsole. If I had left that out then it would stay with the VGA monitor, you can try it if you want, just enter VGA and see all the Forth output being redirected to the VGA monitor and if it were 80 characters wide it would be quite usable, and I am thinking of doing this too.
To change the console baud rate just type 9600 CONBAUD and it will lock in so that after the reset it will come up at 9600 baud. You can reset Tachyon from the console with a ^C or if you happen to have it stuck in some routine you can send a break which in TeraTerm is a <alt>B IIRC or in minicom ^A F
BTW, there is no real Spin code in the Tachyon kernel, just PASM or bytecodes, and only a few lines of Spin for launch the cogs.
I tried the 'VGA TASKS. CON', it worked as expected but, it looked kind of klunky , on the screen. Now if you could manage the chars width and amount of lines of the output...
Lets say that you create a new word definition, is there way to edit that definition or do you have to redo the word again? Also is there a way to see exactly how many new words were created, and maybe delete them?
Ray
Ray
Hi Ray,
I recommend to download the source files Tachyon.spin plus the *.fth files.
Load them all in an editor e.g. Notepad++ and then just go reading the code.
And serach helps find the cross references.
The code is partly - more and more - documented.
Where it is not there is the source which can tell you a lot.
Begin with Tachyon.spin, then EXTEND.fth ...
this gives a very good start once you understand all of it ;-)
At 32x15 it is clunky but the reason I have it is that is uses very little memory, the <1k code image size is reused as the VGA buffer so that it only requires 1k overall for the raw VGA. With VGA.fth I have added 3 different sized big digit modes to it as well as the streaming I/O handlers which interpret controls such as CR and CLS in a standard stream and all that takes 1.4k including the 5x7,6x8, and 7x9 digit fonts. So altogether that uses up 2.4k + some dictionary area, not bad and the big digit modes are really useful as in the case of the clock demo and the breakout game also demonstrates that you don't need bit-mapped graphics to run an arcade game.
Now this thing about "manage the chars width and amount of lines" makes me chuckle
Oh, if only it were that simple for all us Prop users and if the Prop had a dedicated GPU then maybe that would be all that we would need to do. The thing is that one cog can just manage so much in between each waitvid instruction and the higher resolution modes normally use two cogs working in tandem. All that is possible as we have cogs to spare but it all requires more memory, something that we would like some left over for actual applications. It's a bit like office space, sure you can pack more desks and chairs and shelves into it but you still need to sit somewhere and be able to move around, otherwise what's the point? But in regards to this I am looking to do more as I am aiming for 80x25 with a very small memory footprint. The memory just for 80x25 characters alone without any attributes etc amounts to 2k but ideally would be 4k with the current scheme of individual tile/character colors to allow for more versatility.
Lets say that you create a new word definition, is there way to edit that definition or do you have to redo the word again? Also is there a way to see exactly how many new words were created, and maybe delete them?
Each definition is compiled into bytecode, so the source does not remain in memory and although it would be possible to decompile and edit this, it is also not practical due to once again the memory constraints of the Prop. But this is not normally done in any system anyway, even ones with plenty of memory, just recompile. You may notice at the start of many of the .fth drivers that it begins with TACHYON [~ and then it ends with ]~ END. This is done for a number of reasons, even though you could do without them but they are there to identify that this is meant for Tachyon Forth and not some other Forth, and also in conjunction with the [~ it also puts it into a faster load mode showing only the line number it is up to and any messages until it reaches the ]~ END where it reports the "module" size (a module is identified by the ".fth" in the name).
Here is an example of VGA.fth being loaded the first time.
Now you can see that this VGA module uses 1.4k in code space and 536 bytes just in dictionary of which can be reclaimed or compacted later.
The word FORGET will forget all names from that name onwards to the latest and release the code, vectors, and dictionary memory for these. That's also why it is added to the beginning of the .fth files in case the module is already loaded and we have edited it on our computer and are now downloading it again.
Once the final P2 is available I intend to have a "version" of Tachyon for it and it has a lot more memory and resources etc available, expect to see a complete development and runtime system on a chip then.