I second what Seairth said, and his observations and comments on using Forth & TAQOZ. I have programmed numerous languages over the years, and so far *somewhat* behind in figuring out this new command set, no hard feelings intended. From the comments on other / competitors websites, Many newbie users out there are just happy to copy & paste a few "sketches" and are lucky to get anything working, as they have no real formal(?) education in coding. I am not saying you have to be any kind of "expert" but whatever commands you use have to be intuitive and language like. With so many new features on the P2, let's strive to keep the Smart Pins usage & commands simple and understandable.
Since TAQOZ internally just uses 16 bit addresses it is living in the lower 64K of HUB and running on COG0.
I read that TAQOZ now supports a auto start vector and can write itself into the flash or SD boot.
That leads me to the idea to let TAQOZ load my binary from SD or Flash at say HUB $10000 and start my binary at HUB $10000 in cog1, leaving TAQOZ running on COG0.
That would be a perfect Monitor/Test/Debug? tool while developing, and when done one compiles for HUB $0 instead of HUB $10000.
I can already use @Cluso99's Monitor to load and start a file at any address, but I can not automate this.
now the question.
what would I need to do in TAQOZ to load a file from SD or Flash into a HUB address X and start a COG (say COG1) to either load itself from that HUB address and start in COG exec mode or just start running in HUB exec mode from that address?
..
That would be a perfect Monitor/Test/Debug? tool while developing, and when done one compiles for HUB $0 instead of HUB $10000.
I can already use @Cluso99's Monitor to load and start a file at any address, but I can not automate this.
Ah, right, that's more self test/stimulus testing than a classic Debug, and P2 should be very good at self test/stimulus testing, with multiple COGs and Smart-pins that can cross-connect.
TAQOZ scripts are great for that self test/stimulus testing, and I already have them doing that sort of work, via smart pin support.
It would be nice to have more examples, around all the smart pin modes, eg one for
10011 = for X periods, count time
that configs and reports serially, would be great...
After a few days of playing around with my P2-Eval, some observations re: TaQoz:
1. We desperately need a comprehensive word list. It's cool to type WORDS and say hey, there's fopen and fread and fwrite, but how do you use them? What are their arguments and results? I have spent hours looking for such documentation and if it exists at all it's hidden deep within some long thread where I can't find it. Since TaQoz is baked into the chip, this should be part of the P2 datasheet.
2. We also desperately need a short tutorial for more complex functions like file access. I saw a brief mention elsewhere that TaQoz doesn't allow opening by filename -- OK, how DO you do it then? I doubt this would take more than a page to present a couple of demos. Remember us Forth n00bs also don't know how string data is handled in (this version of) Forth.
3. I actually see a strong place for TaQoz in rapid application development; Forth isn't really that hard to learn if you have the documentation and play with it a bit, and it will do more in a given memory footprint than just about any other language (per Chuck Moore's design). So is it possible to autoboot a TaQoz application, either from SD or perhaps from a Flash backup? Something like this is necessary to deploy a TaQoz image as an end-user application.
4. Is it possible to load a binary PASM image and launch a cog in TaQoz?
5. Is there a standard TaQoz extension being developed to take care of its shortcomings? (I find this a better idea than expanding the ROM, since interfaces may change over time; SD makes sense since boot from SD is baked into the P2.) If so this also needs to be made available and documented well enough for self-educated n00bs to get running and use.
It is certainly convenient to be able to exercise the SD card and blinkenlights without hunting down a tool chain to build an application. I like TaQoz being there because this is exactly the sort of thing Forth was invented for. Yes, it is write-only, which is why things have to be documented. But it's possible for a single developer to build surprisingly large and robust systems fast using Forth, which I think makes it a perfect Propeller thing. Even the WikiReader could be booted to a Forth prompt for similar purposes, and it gives us a common touchstone in what will probably become a small zoo of competing language offerings.
... So is it possible to autoboot a TaQoz application, either from SD or perhaps from a Flash backup? Something like this is necessary to deploy a TaQoz image as an end-user application.
...
5. Is there a standard TaQoz extension being developed to take care of its shortcomings? ...
You can boot anything from flash, so that anything could be TAQOZ.
I can launch TAQOZ using a terminal script, and I think the next ROM plans to have a jumper choice for (final) TAQOZ load.
Terminal script is 3 characters, '> '+ESC, and a 250ms wait, for TAQOZ to load, so any user application can do the same right now.
I'd imagine there will be (at least?) two TAQOZ versions (eg) the TAQOZ-R which is baked into ROM, and another more powerful build, TAQOZ-F which can boot from flash, and is a superset of TAQOZ-R.
Anything that runs on TAQOZ-R, should run on TAQOZ-F
The recursive version can just refer to itself without >R R> juggling or other means since TAQOZ can cascade definitions on into another due to the fact that code and dictionary are separate and also that threaded code can be called without the need for a code header. So be aware that TAQOZ and standard Forths which normally are designed for PCs are not the same since there is a lot of customization that suits the P2 and embedded environments (I wish they would distinguish PC Forths from small embedded systems)
This is the recursive version which is not very efficient because it involves lots and lots of pushing and popping of the data stack which incurs a speed penalty in TAQOZ which is why a lot of words try not to do that.
: FIBO ( x -- y )
DUP 2 > IF DUP 1- FIBO
SWAP 2- FIBO + EXIT
THEN
DROP 1
;
This is the very efficient iterative version though:
: fibo ( n -- f ) 0 1 ROT FOR BOUNDS NEXT DROP ;
and running you can use the .AS" to format the number printing:
: fibos 1 46 ADO CRLF I .AS" fibo(*|#) = " LAP I fibo LAP .LAP .AS" result = *|#" 5 +LOOP ;
like this:
TAQOZ# fibos
fibo(1) = 466 cycles= 2,588ns @180MHz result = 1
fibo(6) = 786 cycles= 4,366ns @180MHz result = 8
fibo(11) = 1,106 cycles= 6,144ns @180MHz result = 89
fibo(16) = 1,426 cycles= 7,922ns @180MHz result = 987
fibo(21) = 1,746 cycles= 9,700ns @180MHz result = 10946
fibo(26) = 2,066 cycles= 11,477ns @180MHz result = 121393
fibo(31) = 2,386 cycles= 13,255ns @180MHz result = 1346269
fibo(36) = 2,706 cycles= 15,033ns @180MHz result = 14930352
fibo(41) = 3,026 cycles= 16,811ns @180MHz result = 165580141
fibo(46) = 3,346 cycles= 18,588ns @180MHz result = 1836311903 ok
EDIT - fixed up fibos and results
BTW, it is easy enough to copy text from the terminal screen and paste it and format it with the code tags.
Re discussion about how TAQOZ should be used or not used. I think this discussion should be moved to a new thread since this one is more about actually using it and discussing how to use it.
Personally I find that when anyone says that once comical quip "write only" then it usually is a cheap shot since any code can be perceived as write only. I have had to delve through other people's spaghetti code in C or other languages at times, so then I could just as easily apply this line to other "languages" but I know it is not the language, it's the person trying to speak a non-native language and making a mess not only of the words but also of the thinking and structure.
As I keep saying however, Forth may be a "language" on a PC running under some O/S but on an embedded system it is often the O/S and development environment and "language" all wrapped up into one.
If someone translates C or other code into Forth, it is often very inefficient and horrible to understand, in effect "write only".
If someone thinks in Forth and then writes in Forth, the result can be simple, elegant, fluent, efficient and easy to understand.
Now it we can move this to another thread then when I have anytime left over I can comment more about TAQOZ in general.
If anyone wants to help with documenting, then please feel free to help and ask questions.
Re discussion about how TAQOZ should be used or not used. I think this discussion should be moved to a new thread since this one is more about actually using it and discussing how to use it.
Personally I find that when anyone says that once comical quip "write only" then it usually is a cheap shot since any code can be perceived as write only. I have had to delve through other people's spaghetti code in C or other languages at times, so then I could just as easily apply this line to other "languages" but I know it is not the language, it's the person trying to speak a non-native language and making a mess not only of the words but also of the thinking and structure.
As I keep saying however, Forth may be a "language" on a PC running under some O/S but on an embedded system it is often the O/S and development environment and "language" all wrapped up into one.
If someone translates C or other code into Forth, it is often very inefficient and horrible to understand, in effect "write only".
If someone thinks in Forth and then writes in Forth, the result can be simple, elegant, fluent, efficient and easy to understand.
Now it we can move this to another thread then when I have anytime left over I can comment more about TAQOZ in general.
If anyone wants to help with documenting, then please feel free to help and ask questions.
I was not taking a cheap shot at Forth or TAQOZ, and even said that my issues were likely due to my own shortcomings. I think you're missing my point. I think it's reasonable that most people coming to the P2 will come from a C or similar background. If they think it's necessary to learn TAQOZ to use the P2, it's going to be a barrier for some of them, hence my comments about how TAQOZ is marketed. Some will try to learn TAQOZ, and may have issues similar to mine. Telling newcomers that they're at fault because they aren't approaching Forth correctly may be technically accurate, but it's also a great way to alienate those same newcomers.
My hope was, by pointing these issues out now, that this would promote some thought in how to effectively help TAQOZ users when a wider audience starts using the chip. (And to help people like me right now.) Please don't take this as an attack on Forth or TAQOZ. We are all friends here (I hope), and I intended my original post to be helpful (not hurtful).
(As a side note, maybe the micro version of Forth could be called Mirth. "Bringing the joy of Forth to the microcontroller..." )
@Seairth - When we start a ball off rolling downhill it is sometimes hard to stop whereas pushing it uphill requires constant effort. It is that "write only" ball that started rolling which can only go downhill that I was concerned about. Forgive me if I speak "forthrightly", it is just to get to the point on an otherwise slow back and forth forum conversation. I certainly don't get offended easily nor do I continue to do so if I did.
TAQOZ is a great hardware diagnostic tool useful also for exploring various aspects not only of the P2 but whatever we connect to it. Now if I have a disk tool and an assembler tool, then it will be an even better tool. If people are more familiar with their tools and those tools are available and able to do the job then I would suspect that that is what they will choose. I'm not sure though that Parallax will support "Forth" but I do hope that they support TAQOZ. There is a big difference between "playing" with Forth on a PC or having played with Forth back in the 80's, and using TAQOZ on the P2.
@"Peter Jakacki" is doing a wonderful job here, but is getting a bit thin skinned between his normal job, developing the next ROM and supporting people here in this forum.
No wonder that he steams a bit.
I see it like this, and I do not mean that as criticism at all, in the opposite I am happy for @"Peter Jakacki" that he was able to wing this and vehemently supported him in getting TAQOZ into the ROM.
The P2 is a brilliant design, as the P1, quite different from mainstream. A 10(?) Million $ chip. And Peter had and has the chance to get his FORTH variant into the ROM.
If I would be him I would scream for joy, all the time.
Because it will be a Parallax Product and for that reason hopefully available for decades to go. Like the Stamps or the P1.
And I am pretty sure that Peter is not sleeping a lot, given the time constrains and his known desire to optimize code to the essence.
You have probably been in situations pressing you like he is pressed now. One gets thin skinned. No offence.
But you are right about the documentation. Peter has a lot of google docs but what would be needed is some Andy Lindsay quality Parallax "What's a TAQOZ" to explain the ROM contained words with examples on how to test your own hardware connected to whatever pins.
And that is what the ROM build in TAQOZ should support, having SPLAT in there would be awesome.
Peter, my one question is how to display what a word is made of. Was not obvious.
Ok, in a full version of Tachyon I have a decompiler so that you can SEE how it is compiled word for word. The best way at present with TAQOZ is to search the assembler listing or the individual include file. You can find the original archived in the Tachyon/P2/BOOT/ROM-V32i folder.
For instance, FREAD is in "sdcard.inc":
' FREAD ( sdsrc hubdst bytes -- )'
FREAD word _ALIGNL,ADO,IX,OVERPLUS,SDFETCH,IX,STORE
FLOOP word _4,PLOOP,DROP,EXIT
Of course that is in a form that P2ASM can assemble but the Forth code would look like this otherwise:
: FREAD ( sdsrc hubst bytes -- ) 4 ALIGN ADO I OVER+ SD@ I ! 4 +LOOP DROP ;
Don't forget that there are some TAQOZ documents available in my sig but I stopped documenting anything because nobody could be bothered to read it, it seems.
I have been looking through those. Thanks, that is a big help. Just knowing what a word consumes and a hint about it helps.
Most of the short examples make good sense now. There is a think differently for larger programs. I can't nail it down, other than to say it is something like not yet having all the "places" to put the data in yet.
Each time I give it a go, some little thing shakes loose. I am in no hurry.
A good TAQOS ROM will see a lot of use. We can frame it up for people a little as we learn.
Actually I find the TAQOZ intro indispensable for the words that are documented and the examples. The Tachyon dictionary is helpful for understanding how many of the words work, although it contains many more words than TAQOZ. I did copy the the TAQOZ words list from the intro into Excel and put them in alpha order. A printout is attached.
Peter, my one question is how to display what a word is made of. Was not obvious.
Ok, in a full version of Tachyon I have a decompiler so that you can SEE how it is compiled word for word. The best way at present with TAQOZ is to search the assembler listing or the individual include file. You can find the original archived in the Tachyon/P2/BOOT/ROM-V32i folder.
For instance, FREAD is in "sdcard.inc":
' FREAD ( sdsrc hubdst bytes -- )'
FREAD word _ALIGNL,ADO,IX,OVERPLUS,SDFETCH,IX,STORE
FLOOP word _4,PLOOP,DROP,EXIT
Of course that is in a form that P2ASM can assemble but the Forth code would look like this otherwise:
: FREAD ( sdsrc hubst bytes -- ) 4 ALIGN ADO I OVER+ SD@ I ! 4 +LOOP DROP ;
Don't forget that there are some TAQOZ documents available in my sig but I stopped documenting anything because nobody could be bothered to read it, it seems.
why should we, come on, we are still kind of a family, and just ask uncle Jakacki.
You are completely right, do not waste any serious time on documentation yet until the respin P2 is finalized.
Take a deep breath and concentrate on what a hardware testing User might need most.
That's the first user group.
Next think about using the P2 as IO controller sending command/response over serial from some other application.
That's the second user group.
Find some way to switch TAQOZ Input/output to some P1 like mailbox system, so that one could use TAQOZ as a subsystem, like smartpins, provided that it still has the lower 64k and cog0. That would allow any program to use TAQOZ like a fullduplex serial without using PINs, just some mailbox.
That's the Third user group.
Then think about what would be nice to include for programming in TAQOZ.
That's the FORTH user group.
I wish that a bigger ROM would be feasible, but even with compression you need to careful select what to include and what to load later.
The list above would be my priorities, but I am a bystander, just in awe what you guys down under did.
I had a 1-wire or RS485 networking layer built into V4 on the P1 which ran in conjunction with the console and emulated a full-duplex link. This allowed me to deploy systems without any application loaded onto a network and I could still "chat" with any unit as if it had a dedicated serial console connection, or I could talk to groups or globally and paste the same source code or commands into all of them.
Maybe I could implement this on the P2 in ROM because that is what was missing from the P1 version and each one required a EEPROM but with P2 and networking in ROM we could have P2s that can boot or just be controlled with "scripts" and one-liners over a RS485 network, or a single I/O.
Hi Peter,
I really like your iterative version of fibo, I just tried it out. Later on I will try the recursive version.
I use Notepad++ to create my source code then I use this menu and submenu selections Edit -> Blank Operations -> Remove Unnecessary Blank and EOL, so that my code is converted to a single line(s) that I can paste into the Taqoz prompt.
I'm not sure if all of the Forth symbols align with TAQOS or Tachyon, but this cleared up a couple of missing links in my brain as I try to understand the list of TAQOS words.
@HydraHacker - best not to strip out anything, especially eol terminators since some things can go awry if they aren't there. I just copy and paste with a 3ms line delay.
@dgately - i suppose these things are both a help and a hindrance because there are a lot of things there too that just aren't applicable or just plain wrong. Fair enough though if you are happy to muddle through it and glean useful bits.
To all - thanks for rolling up your sleeves and giving it a go.
OK, now you are directly in the center of Killer App functionality there!
Being able to communicate between 2 P2's natively across a single I/O without any intervening hardware blobs? Cool, almost like a Data Link Layer function a la CDP?
TO bad we can't get each P2 with a burned in MAC/Identifier.
I had a 1-wire or RS485 networking layer built into V4 on the P1 which ran in conjunction with the console and emulated a full-duplex link. This allowed me to deploy systems without any application loaded onto a network and I could still "chat" with any unit as if it had a dedicated serial console connection, or I could talk to groups or globally and paste the same source code or commands into all of them.
Maybe I could implement this on the P2 in ROM because that is what was missing from the P1 version and each one required a EEPROM but with P2 and networking in ROM we could have P2s that can boot or just be controlled with "scripts" and one-liners over a RS485 network, or a single I/O.
@"Peter Jakacki" How does one change the intensity of the VGA output in Tacoz? The VGA console is super spiffy! (but a little dark on my monitor, which may be due to my breakout board)
The raw variables for intensity control are INT and INTON where storing a byte to INT affects the current intensity and INTON is the reload value. Try 100 INT C!.
I've tried FLOAD but it doesn't seem to work. I get the following:
Cold start
----------------------------------------------------------------
Parallax P2 .:.:--TAQOZ--:.:. V1.0--142 180530-0135
----------------------------------------------------------------
TAQOZ# mount .SDSS16G 3665_3133 NO NAME 32k 15,189M ok
TAQOZ# dir
.SDSS16G 3665_3133 NO NAME 32k 15,189M
PFTH103 $0000_4040 2016.11.14.17.36 0
Bh - c o. l $1C00_3F80 1980.03.06.00.03 4,294,901,760
t h i n. k $0B40_3F80 1980.03.15.00.03 7,602,290
THINKI~1.PDF $0000_65C0 2014.02.02.21.27 4,499,830
Bd o c . $FFC0_3F80 2107.15.31.31.63 4,294,967,295
A n d . s $1BC0_3F80 1980.03.20.00.03 3,014,760
ANDSOF~1.DOC $0000_6200 2014.01.31.14.37 476,160
B I n f. o $1D00_3F80 1980.03.15.00.03 110
S y s t. e $1BC0_3F80 1980.03.21.00.03 6,619,245
SYSTEM~1 $0000_8840 2017.07.07.20.22 0
3204GOOD.FTH $0000_8880 2019.01.06.04.15 1,335
N D . F. T $FFC0_3F80 2107.15.31.31.63 4,294,967,295
T A Q O. Z $0B40_3F80 1980.02.24.00.02 4,522,068
AQOZ1~1.FTH $0000_88C0 2019.01.11.20.51 3,059
EXTEND .FTH $0000_88C0 2019.01.11.20.51 3,059
ok
TAQOZ# FLOAD EXTEND.FTH ??? ok
TAQOZ# ïïïïïïïïïïïïïïïïïïïïïïïïïïïïïïïïïïïïïïïïïïïïïïïïïïïïïïïïïïïïïïïïï
After a couple of pages of ï I hit esc 4 times to stop it. In the listing above, I deleted a long string of ï.
I had a 1-wire or RS485 networking layer built into V4 on the P1 which ran in conjunction with the console and emulated a full-duplex link. This allowed me to deploy systems without any application loaded onto a network and I could still "chat" with any unit as if it had a dedicated serial console connection, or I could talk to groups or globally and paste the same source code or commands into all of them.
Maybe I could implement this on the P2 in ROM because that is what was missing from the P1 version and each one required a EEPROM but with P2 and networking in ROM we could have P2s that can boot or just be controlled with "scripts" and one-liners over a RS485 network, or a single I/O.
Oh yes @"Peter Jakacki", please do that.
I found your P1 demo you showed us very impressive and having that in the ROM of the P2 would help a lot.
What would I need to do in TAQOZ to load a binary from SD to a specific address, say $10000 directly behind TAQOZ and start a new cog to run this leaving TAQOZ undisturbed?
Comments
Since TAQOZ internally just uses 16 bit addresses it is living in the lower 64K of HUB and running on COG0.
I read that TAQOZ now supports a auto start vector and can write itself into the flash or SD boot.
That leads me to the idea to let TAQOZ load my binary from SD or Flash at say HUB $10000 and start my binary at HUB $10000 in cog1, leaving TAQOZ running on COG0.
That would be a perfect Monitor/Test/Debug? tool while developing, and when done one compiles for HUB $0 instead of HUB $10000.
I can already use @Cluso99's Monitor to load and start a file at any address, but I can not automate this.
now the question.
what would I need to do in TAQOZ to load a file from SD or Flash into a HUB address X and start a COG (say COG1) to either load itself from that HUB address and start in COG exec mode or just start running in HUB exec mode from that address?
Mike
Ah, right, that's more self test/stimulus testing than a classic Debug, and P2 should be very good at self test/stimulus testing, with multiple COGs and Smart-pins that can cross-connect.
TAQOZ scripts are great for that self test/stimulus testing, and I already have them doing that sort of work, via smart pin support.
It would be nice to have more examples, around all the smart pin modes, eg one for
10011 = for X periods, count time
that configs and reports serially, would be great...
1. We desperately need a comprehensive word list. It's cool to type WORDS and say hey, there's fopen and fread and fwrite, but how do you use them? What are their arguments and results? I have spent hours looking for such documentation and if it exists at all it's hidden deep within some long thread where I can't find it. Since TaQoz is baked into the chip, this should be part of the P2 datasheet.
2. We also desperately need a short tutorial for more complex functions like file access. I saw a brief mention elsewhere that TaQoz doesn't allow opening by filename -- OK, how DO you do it then? I doubt this would take more than a page to present a couple of demos. Remember us Forth n00bs also don't know how string data is handled in (this version of) Forth.
3. I actually see a strong place for TaQoz in rapid application development; Forth isn't really that hard to learn if you have the documentation and play with it a bit, and it will do more in a given memory footprint than just about any other language (per Chuck Moore's design). So is it possible to autoboot a TaQoz application, either from SD or perhaps from a Flash backup? Something like this is necessary to deploy a TaQoz image as an end-user application.
4. Is it possible to load a binary PASM image and launch a cog in TaQoz?
5. Is there a standard TaQoz extension being developed to take care of its shortcomings? (I find this a better idea than expanding the ROM, since interfaces may change over time; SD makes sense since boot from SD is baked into the P2.) If so this also needs to be made available and documented well enough for self-educated n00bs to get running and use.
It is certainly convenient to be able to exercise the SD card and blinkenlights without hunting down a tool chain to build an application. I like TaQoz being there because this is exactly the sort of thing Forth was invented for. Yes, it is write-only, which is why things have to be documented. But it's possible for a single developer to build surprisingly large and robust systems fast using Forth, which I think makes it a perfect Propeller thing. Even the WikiReader could be booted to a Forth prompt for similar purposes, and it gives us a common touchstone in what will probably become a small zoo of competing language offerings.
You can boot anything from flash, so that anything could be TAQOZ.
I can launch TAQOZ using a terminal script, and I think the next ROM plans to have a jumper choice for (final) TAQOZ load.
Terminal script is 3 characters, '> '+ESC, and a 250ms wait, for TAQOZ to load, so any user application can do the same right now.
I'd imagine there will be (at least?) two TAQOZ versions (eg) the TAQOZ-R which is baked into ROM, and another more powerful build, TAQOZ-F which can boot from flash, and is a superset of TAQOZ-R.
Anything that runs on TAQOZ-R, should run on TAQOZ-F
The recursive version can just refer to itself without >R R> juggling or other means since TAQOZ can cascade definitions on into another due to the fact that code and dictionary are separate and also that threaded code can be called without the need for a code header. So be aware that TAQOZ and standard Forths which normally are designed for PCs are not the same since there is a lot of customization that suits the P2 and embedded environments (I wish they would distinguish PC Forths from small embedded systems)
This is the recursive version which is not very efficient because it involves lots and lots of pushing and popping of the data stack which incurs a speed penalty in TAQOZ which is why a lot of words try not to do that.
This is the very efficient iterative version though:
and running you can use the .AS" to format the number printing: like this: EDIT - fixed up fibos and results
BTW, it is easy enough to copy text from the terminal screen and paste it and format it with the code tags.
Personally I find that when anyone says that once comical quip "write only" then it usually is a cheap shot since any code can be perceived as write only. I have had to delve through other people's spaghetti code in C or other languages at times, so then I could just as easily apply this line to other "languages" but I know it is not the language, it's the person trying to speak a non-native language and making a mess not only of the words but also of the thinking and structure.
As I keep saying however, Forth may be a "language" on a PC running under some O/S but on an embedded system it is often the O/S and development environment and "language" all wrapped up into one.
If someone translates C or other code into Forth, it is often very inefficient and horrible to understand, in effect "write only".
If someone thinks in Forth and then writes in Forth, the result can be simple, elegant, fluent, efficient and easy to understand.
Now it we can move this to another thread then when I have anytime left over I can comment more about TAQOZ in general.
If anyone wants to help with documenting, then please feel free to help and ask questions.
I was not taking a cheap shot at Forth or TAQOZ, and even said that my issues were likely due to my own shortcomings. I think you're missing my point. I think it's reasonable that most people coming to the P2 will come from a C or similar background. If they think it's necessary to learn TAQOZ to use the P2, it's going to be a barrier for some of them, hence my comments about how TAQOZ is marketed. Some will try to learn TAQOZ, and may have issues similar to mine. Telling newcomers that they're at fault because they aren't approaching Forth correctly may be technically accurate, but it's also a great way to alienate those same newcomers.
My hope was, by pointing these issues out now, that this would promote some thought in how to effectively help TAQOZ users when a wider audience starts using the chip. (And to help people like me right now.) Please don't take this as an attack on Forth or TAQOZ. We are all friends here (I hope), and I intended my original post to be helpful (not hurtful).
(As a side note, maybe the micro version of Forth could be called Mirth. "Bringing the joy of Forth to the microcontroller..."
TAQOZ is a great hardware diagnostic tool useful also for exploring various aspects not only of the P2 but whatever we connect to it. Now if I have a disk tool and an assembler tool, then it will be an even better tool. If people are more familiar with their tools and those tools are available and able to do the job then I would suspect that that is what they will choose. I'm not sure though that Parallax will support "Forth" but I do hope that they support TAQOZ. There is a big difference between "playing" with Forth on a PC or having played with Forth back in the 80's, and using TAQOZ on the P2.
@"Peter Jakacki" is doing a wonderful job here, but is getting a bit thin skinned between his normal job, developing the next ROM and supporting people here in this forum.
No wonder that he steams a bit.
I see it like this, and I do not mean that as criticism at all, in the opposite I am happy for @"Peter Jakacki" that he was able to wing this and vehemently supported him in getting TAQOZ into the ROM.
The P2 is a brilliant design, as the P1, quite different from mainstream. A 10(?) Million $ chip. And Peter had and has the chance to get his FORTH variant into the ROM.
If I would be him I would scream for joy, all the time.
Because it will be a Parallax Product and for that reason hopefully available for decades to go. Like the Stamps or the P1.
And I am pretty sure that Peter is not sleeping a lot, given the time constrains and his known desire to optimize code to the essence.
You have probably been in situations pressing you like he is pressed now. One gets thin skinned. No offence.
But you are right about the documentation. Peter has a lot of google docs but what would be needed is some Andy Lindsay quality Parallax "What's a TAQOZ" to explain the ROM contained words with examples on how to test your own hardware connected to whatever pins.
And that is what the ROM build in TAQOZ should support, having SPLAT in there would be awesome.
Enjoy!
Mike
Ok, in a full version of Tachyon I have a decompiler so that you can SEE how it is compiled word for word. The best way at present with TAQOZ is to search the assembler listing or the individual include file. You can find the original archived in the Tachyon/P2/BOOT/ROM-V32i folder.
For instance, FREAD is in "sdcard.inc": Of course that is in a form that P2ASM can assemble but the Forth code would look like this otherwise:
Don't forget that there are some TAQOZ documents available in my sig but I stopped documenting anything because nobody could be bothered to read it, it seems.
Most of the short examples make good sense now. There is a think differently for larger programs. I can't nail it down, other than to say it is something like not yet having all the "places" to put the data in yet.
Each time I give it a go, some little thing shakes loose. I am in no hurry.
A good TAQOS ROM will see a lot of use. We can frame it up for people a little as we learn.
Tom
why should we, come on, we are still kind of a family, and just ask uncle Jakacki.
You are completely right, do not waste any serious time on documentation yet until the respin P2 is finalized.
Take a deep breath and concentrate on what a hardware testing User might need most.
That's the first user group.
Next think about using the P2 as IO controller sending command/response over serial from some other application.
That's the second user group.
Find some way to switch TAQOZ Input/output to some P1 like mailbox system, so that one could use TAQOZ as a subsystem, like smartpins, provided that it still has the lower 64k and cog0. That would allow any program to use TAQOZ like a fullduplex serial without using PINs, just some mailbox.
That's the Third user group.
Then think about what would be nice to include for programming in TAQOZ.
That's the FORTH user group.
I wish that a bigger ROM would be feasible, but even with compression you need to careful select what to include and what to load later.
The list above would be my priorities, but I am a bystander, just in awe what you guys down under did.
Enjoy!
Mike
Maybe I could implement this on the P2 in ROM because that is what was missing from the P1 version and each one required a EEPROM but with P2 and networking in ROM we could have P2s that can boot or just be controlled with "scripts" and one-liners over a RS485 network, or a single I/O.
I really like your iterative version of fibo, I just tried it out. Later on I will try the recursive version.
I use Notepad++ to create my source code then I use this menu and submenu selections Edit -> Blank Operations -> Remove Unnecessary Blank and EOL, so that my code is converted to a single line(s) that I can paste into the Taqoz prompt.
HydraHacker
I'm not sure if all of the Forth symbols align with TAQOS or Tachyon, but this cleared up a couple of missing links in my brain as I try to understand the list of TAQOS words.
dgately
@dgately - i suppose these things are both a help and a hindrance because there are a lot of things there too that just aren't applicable or just plain wrong. Fair enough though if you are happy to muddle through it and glean useful bits.
To all - thanks for rolling up your sleeves and giving it a go.
Being able to communicate between 2 P2's natively across a single I/O without any intervening hardware blobs? Cool, almost like a Data Link Layer function a la CDP?
TO bad we can't get each P2 with a burned in MAC/Identifier.
The fuses were removed AFAIK.
Most SPI flash memories have family members that have unique IDs. The tiny MCU Peter has on P2D2, also has a unique ID.
EasyFile.fth from Peter's P2 Dropbox folder shows: so
FLOAD myfile.fth
should do it after the SD is mounted.
reading the source is fun ... and you can discover a lot
After a couple of pages of ï I hit esc 4 times to stop it. In the listing above, I deleted a long string of ï.
Tom
try FLOAD $0000_88C0
uups NO this is FORTH so it would be
$0000_88C0 FLOAD
in FORTH parameters go first and method last.
Mike
Oh yes @"Peter Jakacki", please do that.
I found your P1 demo you showed us very impressive and having that in the ROM of the P2 would help a lot.
What would I need to do in TAQOZ to load a binary from SD to a specific address, say $10000 directly behind TAQOZ and start a new cog to run this leaving TAQOZ undisturbed?
Enjoy!
Mike