K2, I don't think your expectations are whacked. The only thing that I can say concerning the people that you PMed, is that if you had some kind of problem, you should have contacted Parallax directly. This is their product, and the responsibility of support is on them, not the community. Now, if you don't contact Parallax, that's on you. If you do contact Parallax and get blown off, that's on them.
Well, I did PM two Parallax employees as well, but I heard nothing from them at all. I'm certain they're very busy with more important tasks. Answering customer queries almost certainly isn't one of their assigned duties. It may be that no one is assigned that duty.
The fact is, there is a big lack of documentation available for the Propeller. Sure, you can't force people to write books, but there is a lack of baseline documentation available, which I personally believe is not the community's responsibility to provide. PASM is a good example. The Propeller has been on the market 4-5 years, which is plenty of time to hire a writer to write "PASM 101".
Sometimes it seems to me that there is too much reliance on the user community to provide the solutions to the problems.
What can I say except that I agree with you entirely. It is admirable of deSilva and potatohead to have gone to such an effort out of the goodness of their hearts. But it seems just a tad shameful on the part of Parallax that the vacuum exists. If money is the problem, sell downloads of the PDF for $10 a pop. Frankly, at this point I would pay $10 for smudged photocopies of just a few functional templates.
I learn by pulling things to bits. Maybe it is the medical training - the first thing they get you to do in medical school is go down to the dissecting room and pull a body to bits.
I started PASM by pulling to bits the Zicog that heater wrote. I started by changing just one line of code, then recompiled it to see what happens. Pretty soon I found I had a grasp of many of the instructions. Try adding a tiny new routine in and see:
1) if it still runs and
2) if it now does the thing you programmed it to do.
Then I pulled to bits the prop demo board and started adding new bits.
There is a real lack of documentation I agree. My 'documentation' is the collective bits and pieces of code in the obex.
Can you be more specific about the code you want to write and what you want to do - I'd be fairly sure there is enough collective wisdom here to help out a lot.
I didn't follow this discussion exactly, because it would have been more difficult than writing a perfect ASM documentation. What are the contributions saying, what is the meaning, how to interpret the reactions and actions?
In the end, it is quite simple: Read Goethes Dr.Faustus, both parts. All the life and everything behind is in.
What I want to say is: there is no way to experience except doing everything by yourself, falling in every pit and crawl out again. The best users guide can not give you more than hint to the entry.
So, don't wait for what will never come. If you think, that a documentation is wrong, misses something, goes the wrong way: write a better one, use your experience at your best. And do NOT read it again after three years: you will be ashamed.
Life is a compromise and in the end, all decide the same way to go. For different reasons. ;-)
Well, I did PM two Parallax employees as well, but I heard nothing from them at all. I'm certain they're very busy with more important tasks. Answering customer queries almost certainly isn't one of their assigned duties. It may be that no one is assigned that duty.
Parallax seems to be full of helpful people (from the top down (or bottom up if you prefer)) and I think there is someone there assigned to help all of us.
I found the best way to learn propeller languages is using the objects, as you proably did. Only advice is move up slowly.
Chip's graphics object or the one with 4 serial ports fully configurable in a single COG are at the higher end.
Just a cuple of ideas:
Check well known objects doing simpler tasks. For instance all the float family, or the 32 servo control.
In the past the servo object was modified for a fine timing issue discussed on the forum. Maybe finding the old discussion, and the previous code would prove a great tutorial.
In another discussion Beau posted a cordic code. In this object a cog worked as a coprocessor, waiting for a request to perform a task. The code was well documented and modular, allowing room to add up to 256 functions.
I modified it (well.. messed up..) to access also an array, and to do other tasks, but I think I still have the original code.
You might already know all the stuff, so forget about it, but looking at first quality code is one of my favourite learning mehods.
I learn by pulling things to bits. Maybe it is the medical training - the first thing they get you to do in medical school is go down to the dissecting room and pull a body to bits.
I started PASM by pulling to bits the Zicog that heater wrote. I started by changing just one line of code, then recompiled it to see what happens.
This is how I learn also. I suspect if I didn't have such a huge vasovagal reaction probably triggered by hemophobia I'd probably have been a doctor too
I like to think of it as the "break it then fix it" method of learning. In your case, you took a working zicog, broke it by changing it and learned how to fix it to work again. Books are incredibly valuable, but are no substitute for real "in the trenches" world experience
Dr_A, "I learn by pulling things to bits. Maybe it is the medical training..."
I really hope none of you patients are readers here
Here is an observation from Max Robinson an expert in tube radios:
If I worked on radios the same way doctors worked on people when ever a capacitor, resistor, or tube, failed I would just take it out and throw it away. Yet the radio would be expected to work as well as when it was new. So far I am down my tonsils, adenoids, about one and a half feet of large intestine, and a gall bladder. My power output is down and my distortion percentage is up.
Haemophobia is in many of us ... I got into chemistry ;-)... but not because of that!
On a seious note: assembler needs some work till you understand why and maybe how , then is just a matter of nomeclature, or so I believe.
When I want to do some pasm development (didn'T happen in a while ) I use (* advertisement *) my own simulator. It has some quirks, but it mostly does what It is supposed to... a multi-cog pasm simulator, get it from: http://sourceforge.net/projects/ppropellersim/ Please, read the included docs !!!!!!!
I have been trying to find/download some of documentation mentioned in this thread. Of course the issues with the new forum make it more difficult so I keep jumpin back to the old forum.
I am trying to get the Propeller Tricks and Trap pdf, but I get and error
saying the file is damaged and can ot be repaired.
Well, thanks. I'm on that project, partially because people have asked, and because that's how I was taught to get hold of this stuff. I thought I would share perspective, because it's valuable in these kinds of things.
My early computing experience was similar to the one Heater describes. There was some functional documentation, like we see here, and some code, which appears to be more than they had on 6809.
I find it very interesting that I used to go grocery shopping with Mom, eager to pick up a copy of a computing magazine that actually talked about computing! There was code in there, techniques, sometimes a game, and lots of basic material on how things could be done.
Fast forward to today, and it's really not all that different with the forum. The same core bits are there, there is a lot of code, and we've got a great peer group applying the tech.
Back then, "video generators" were only loosely documented, just as this one is. Happy accidents, and "hacks" applied to them, resulted in great displays over time, as has happened with this one. (agreed on a functional diagram being missing, and not interested in starting that discussion again)
I liked Andre's book. It's worth the money, and it's got a great treatment of how to apply the chip in different contexts. The "Official Guide" is also quite good, both recommended.
A look at Chips multi-cog video driver, or Baggers and Eric Ball multi-cog sprite code, shows the application of some higher order comp-sci understanding, to the propeller. The same can be said for the SIDCog, or probably my text drivers (that one not as advanced in the comp-sci sense), or any number of great objects we have to look at
Eric went ahead and did a software color signal on the Propeller, for example. It does not use the chroma generator in the video generator. The docs necessary for that are the Prop Data Sheet, and instruction references. Outside of Parallax, the docs required are those that detail video signals, and how chroma works, followed by some generic comp-sci stuff on loops, and math.
To learn from those, one only needs to read the code. Every line of code tells a story, and understanding that story requires fetching the relevant information from the various disciplines that are incorporated into the object. What Andre' did was combine that for games, and it's worth it.
Andre is a subject matter expert in games. Seems to me, the kinds of documentation being asked for, most often would come from subject matter experts in the various disciplines, noting their application of the propeller. That seems to put the burden on the eco-system more often than not, at least from where I stand.
With modern computing, often the barrier is high for entry. Things are very complex, limiting the "just do it" and "just read the code" approach, and perhaps that's where part of the disconnect is. The beauty of companies like Parallax, is the time taken to package tech into usable pieces, so that people can learn, do, play, build, etc... without having to run through a lot of school, and or read thick volumes to get stuff done.
I find it difficult in my mind to reconsile these things. Mature tech has gone through that process multiple times, with it's "ecosystem" contributing, building, etc... A look at the 6502 reveals we know damn near everything there is ever to know about that chip now. Back when Woz built the Apple, we didn't! And that computer shipped with a rough theory of operation, detailed ROM code listings for those wanting to learn, and schematics! The rest was applying the various diciplines to the computer.
Today, with the Prop, that really isn't any different. How can it be?
And so I don't understand the "need docs" queries here. If one wants to make sound, it seems to me, obtaining some info on the theory of sound, music, and audio tech, terminology, and application is needed. Once that has been obtained, one then applies the computing technology, along with some circuit (such as PWM) to then generate sound. Those docs exist in many forms, do they not? --leaving only the functional description of the propeller, and it's electrical characteristics as the necessary bits needed to actually apply the propeller then.
BTW: I think this is a great thread, aptly titled. When I was a kid, learning how to do these things, perspective was the most valuable thing I found. Learning how people think to solve problems was often more important than seeing solutions. Today, that remains true --plus we have the net now, meaning most core things about most disciplines are out there for the taking!
So the part I don't understand is why not just do that?
Here's an interesting question:
If you could "mind meld" with another person, and let's say Chip, just because it's fun, and you could get something. Would you get all the detail on the Propeller, or would you get the way of thinking that led to the realization of something like the Propeller?
I would take the latter in a second, because that empowers a person to consume what they can find and apply it. Taking the former is great, but would only be valuable, given somebody has the application knowledge already, would it not?
Wow, that is a lot of great information and advice. Thanks to ALL. Even Leon.
max72: No, I don't know all that! Thank you for it.
heater: It's not a question of how to implement the algorithms. They were created in C (for the ARM) some time ago, and I converted them to PASM this week. Thanks to jazzed's BMADebugger, they've even been verified. The problem is that I need to get six cogs running the code and sharing variables in Hub RAM. And the variables in Hub also need to be accessed by SPIN running on the other two cogs.
The sharing of MULTIPLE variables is the first problem. All I have to go on is page 178 of the Propeller Manual. But a SINGLE SHARED VARIABLE AND A FEW PROP PINS ACTING AS STATUS BITS TO COORDINATE ITS USE IS NOT A BIG ENOUGH PIPE FOR THIS APPLICATION. (Note: I'm not yelling at any one person. I'm not yelling at all. I simply want to emphasize something I've already mentioned and no one has seen. Who needs cryptography? Just post it on the Prop Forum and it is certain it will never be read... Joking...Just joking.)
The timing of cog launches and the passing of parameters is the second problem.
The reason I keep bringing up Chip's VGA code is because he seems to be solving both problems. But I'm completely confused about how. That's the rub.
Maybe this is too ambitious for a first PASM project. But it is also the only PASM application that had enough attraction to me to want to see it through. It's a conundrum.
One question that comes to mind, is why use the pins for coordination?
Shouldn't that be flags, and or timing?
The PAR register is only one way of establishing that kind of communication. One common use is to have the PAR register point to sequentially ordered HUB memory locations, which then either serve as status flags, for the cogs to understand who is communicating with who and why, and as pointers to buffers where said communication occurs. If those addresses are defined in advance, PAR is not necessary at all.
Most of the time, PAR is just used in this way, not actually passing anything of importance, but just the address of where those things reside in the HUB.
The PAR register is only one way of establishing that kind of communication. One common use is to have the PAR register point to sequentially ordered HUB memory locations, which then either serve as status flags, for the cogs to understand who is communicating with who and why, and as pointers to buffers where said communication occurs. If those addresses are defined in advance, PAR is not necessary at all.
Most of the time, PAR is just used in this way, not actually passing anything of importance, but just the address of where those things reside in the HUB.
Every sentence you just wrote is new to me. Your post is ENTIRELY germane to my problem. So couldn't Parallax provide a simple template incorporating and documenting the very things you just mentioned? I am not asking for another tutorial - I don't have the patience, they're too wordy, and Parallax doesn't have the time. But USEFUL examples and templates would be MARVELOUS.
Every sentence you just wrote is new to me. Your post is ENTIRELY germane to my problem. So couldn't Parallax provide a simple template incorporating and documenting the very things you just mentioned? I am not asking for another tutorial - I don't have the patience, they're too wordy, and Parallax doesn't have the time. But USEFUL examples and templates would be MARVELOUS.
A few weeks ago I was learning how variables could be passed between PASM and Spin in main memory. Damn near cooked my noodle because the example I was following (FullDuplexSerialPlus) didn't explicitly make comments as to how and why it was doing what it was doing on the PASM side. I could find no tutorial, template or example about it. I feel your pain. I set about commenting their code and the picture of what it was doing emerged. I may pick up the torch and write an example and explain it, though I am a newbe and not qualified to do so I wound up using the technique in my FullDuplexParallel object, and left the comments in place.
I could find no tutorial, template or example about it. I feel your pain. I set about commenting their code and the picture of what it was doing emerged.... I wound up using the technique in my FullDuplexParallel object, and left the comments in place.
I've just downloaded it. I look forward to following your comments. It may be just the ticket!
Edit: Alas, I've got a long way to go before FullDuplexParallel becomes my Rosetta Stone. I see the parts you've commented, and they are very helpful. But there is a whole lot of uncommented content that I don't yet understand. I will likely have to do my own noodle cooking on those parts.
FullDuplexSerial is a wonderful thing and a great example of PASM code tricks. But I wonder if it's a good place to begin if you are starting out on the road to understanding data communication between COGS.
1) It actually has two "threads" going on in one COG. One for transmit and one for receive. These separate activities are implemented as "coorotines" using jmpret to change context from one thread to another at suitable points in the code. I would put this technique under the "advanced" heading for anyone getting into PASM.
2) It uses a cunning cyclic buffer technique to implement input and output buffers in such a way that the buffers are shared with the application without risk of corruption when both FDX and the application are accessing the buffer at the same time. Also with out the use of LOCKS. Again this technique I would put under the heading of "advanced". Not that the PASM to do it is hard, just that the idea itself is kind of non-obvious.
And no you don't need pins to synchronise communication between COGS. It might be argued that you can synch COGs faster using pins but let's not go there yet.
As we are talking crypto code let's set up a simple thought experiment with that:
1) Let's say Cog A, in Spin or PASM, has blocks of plain text that it wants to be encrypted by some other COG B.
2) All wee need is a buffer in memory whose address is known to both COGS. So let that be an array buffer[0], buffer[2]...buffer[n]
3) Let's put the data blocks, of length "n" into array elements 1, 2, 3 ...n
4) Let's use buffer[0] to synchronize the two COGs. buffer[0] has the value 0 on start up.
5) When Cog A has a block to encrypt he writes it to the buffer starting at buffer[1]. Then he writes some special value to buffer[0]. Could just be 1, meaning "data available, please encrypt it".
6) Cog B meanwhile has been sitting in a loop reading buffer[0] as long as it is 0 he keeps looping. When it becomes 1 he breaks out of the loop and proceeds to read and encrypt the data from buffer[1] upwards.
7) Whilst B is doing that Cog A sits in a loop waiting for buffer[0] to become 0 again.
8) When Cog B is finished his work he writes the encrypted data back to the buffer starting at buffer[1]. He the sets buffer[0] back to 0 and goes back to waiting for it to become non-zero again.
9) Cog A sees the buffer[0] is now zero again and hence knows he can put new data there if he wants to.
In this way the two COG share data and have synchronized their access to it. They are never reading and writing the buffer at the same time and scrambling data. They don't need locks to do this. Just the control flag provided by buffer[0]
The only remaining problem is "How do these two COGs both know the address of the buffer array?"
Well, one knows it because it is defined in his object. He can start the other COG and pass the buffer address through the PAR mechanism.
For a good example of how this is look at the floating point object in OBEX. Or VMCog uses a very simple "mailbox" technique like this. Never mind how the guts of those two objects work but the data passing they use is simple enough.
I had to laugh as I was reading your post! You are very much correct that I'd like to avoid "coorotines," "cunning cyclic buffer techniques," and LOCKs at the outset. At the very least, they obscure the essential portions of code that I do need to understand.
BTW, the pins weren't hard to use at all. They were just status bits to me, and I've been dealing with status bits and defining my own protocols forever. But they were probably a waste of a valuable and scarce resource. It was just that, lacking a second shared variable or any other means of information transfer, they were necessary. It was part of the original failed plan to get things working in a day or two.
Anyway, a rather essential aspect of this project is that it is not an encoding device. At the moment, it is a research tool. The nature of the research is such that it doesn't follow the plaintext-encoder-cyphertext paradigm. But it does need about ten shared memory locations between each cog and the Hub.
(As implemented on the ARM array, the algorithms run day and night for weeks, slowly accumulating data. That's why I'm so keen on more- and faster processors. I'm terribly interested in what the Propeller can do vis-a-vis ARM Cortex chips. FWIW, I'm not using necessary the fastest ARM chips, but rather whatever chips deliver the most functional MIPS-per-$ once all the costs are factored in, including the price of programming tools.)
The outline of the thought experiment you've provided is more than ample to accommodate my current needs. Since the Prop implementation is new, I'm not 100% sure what the final configuration will look line, i.e., what config will deliver optimum performance. I'm not even sure how the tasks will ultimately be distributed across the sea of cogs.
The "remaining problem" that you mention really is the problem. I'm very interested in exploring both Float32 and VMCog to see what I can glean from them w.r.t. it.
Thank you so much for direction you have provided!
I've just downloaded it. I look forward to following your comments. It may be just the ticket!
Edit: Alas, I've got a long way to go before FullDuplexParallel becomes my Rosetta Stone. I see the parts you've commented, and they are very helpful. But there is a whole lot of uncommented content that I don't yet understand. I will likely have to do my own noodle cooking on those parts.
Yea, I looked back at my code and I didn't keep the comments on where it was establishing the pointers to main memory in PASM. There is some trickey going on there that is not documented. Sorry bout that.
I looked back at my code and I didn't keep the comments on where it was establishing the pointers to main memory in PASM. There is some trickery going on there that is not documented.
It will stay in my library as a text for the PASM201 class. There's plenty to be learned there.
I couldn't find VMCog for some reason. Bill's link didn't work and I couldn't find it on his webpage either.
Fortunately, Float32 looks perfect! I already had it on hand and had looked at it frequently, but more at the algorithms. Floating point libraries are a fascinating thing.
Anyway, I can see that it's about as perfect for the job at hand as anything could be. It's noodle cooking time.
Bobb, maybe my problem is that I've programmed in assembly on too many processors.
K2,
This kind of thing bit me for a short while. I wrote ASM for years on the 6502, 68xx, 680x0, Z80, etc. and tried to apply my same style of coding to the Propeller Assembly. I ended up throwing all my previous experience aside and just looking at it from a new perspective and it seemed to make more sense to me. Maybe this won't help you, but I recognize the situation, having been in your place at the start.
If we look in the Spin start method of VMCog, just because I have it open in front of me, we see that it starts it's PASM work in a new Cog with the line:
cognew(@vmcog, mailbox)
Where:
1) "vmcog" is the label at the start of the PASM code in its DAT section.
2) The "@" symbol means "take the HUB memory address", of the vmcog code in this case.
3) And "mailbox" is a variable holding the address of one of those data exchange areas we talked about earlier.
So what happens, what does this cognew do?
1) It loads up the 496 LONGs from the given address, from vmcog in this case, into the memory of new COG.
2) It starts that new COG running that code.
3) And here is the "magic" part, that second parameter, the "mailbox" value ends up in the PAR register of that newly running COG.
So I guess 3) is the missing link for you. When the PASM is running the register PAR is where you can find whatever parameter was sent to the COG from SPINs cognew.
That value in par could be just a value, say a LED flash frequency, but more often than not it is a pointer to some memory containing multiple parameter items or like in this case a data exchange "mailbox"
So now we look in the vmcog PASM code and it starts with:
init_vm mov pvmcmd, par ' save pointer to mailbox, first word is command
add pvmcmd, #4
mov pvmaddr, pvmcmd ' pvmaddr = pointer to long in hub that holds the vmaddr
add pvmcmd, #4
mov pvmdata, pvmcmd ' pdata = pointer to long in hub for byte/word/long to be read/written to/from vm
Here we see it is saving the value of par as the address of some command variable in HUB. Then it saves that address +4 and +8 as the address of other components of the data exchange mailbox.
Now all this is detailed on page 189 in the COGNEW section of my Propeller manual where it says:
Parameter is used to optionally pass a value to the new cog. This value ends up in the
new cogs read-only Cog Boot Parameter (PAR) register. Parameter can be used to
pass a either a single 14-bit value or the address of a block of memory to be used by
the assembly routine. Parameter is required by COGNEW, but if not needed for your
routine, simply set it to an innocuous value like zero (0).
Heater, you are such a peach that I'm going to print off your penultimate post and memorize it. I swear. And even though "I get it," I'm certain you have amplified upon the matter in ways that will prove vital in my development as a propmeister. Mil gracias!
Edit: It will also enlighten many to come. And if Parallax ever takes my advice to compile a list of the best answers to oft-recurring questions, they'd better include your post or I'll turn the Whine Machine back on!
@ Ale: This morning was so busy that I didn't get a chance to acknowledge even a fraction of the great help offered. I downloaded your simulator a couple of days ago. IIRC, the problem I had was no immediate way to compile Java. But all indications are that it's an amazing tool. I'd love to have it.
@ Parallax: Yes, it is the height of hubris for some Johnny-Come-Lately to think he was the first to suggest anything. Relax, Johnny doesn't think that.
@ BradC: I visited a dialysis patient once and fainted in the hallway. Pretty embarrassing. Blood flowing through plastic tubes was more than I could handle. Also, your BST is great! Didn't know what it was, or that it was available for Windows until Bean suggested I take a look at PropBasic. I definitely have to spend a bunch more time with it.
@schill: Didn't know anything about the official support request process. Many thanks for the heads-up.
@ErNa: You are absolutely right. Rather than grousing about Parallax and all they ought to do, I should do what I can do. I should start my own compilation of the best solutions. If it's any good, maybe it will benefit others. Also, it would put me in charge of the selection; I could make certain that Heater's post gets in.
@ Heater: Thanks for directing me to VMCog. I saw the letters 'debug' and figured that wasn't it.
BTW, the reality dawned when I realized that the PropTool must have stacked together the SPIN variables - local variables to be specific - into a contiguous list so that par could reference them in the first place. The lack of global variable declarations really threw me for a loop. Even when I understood the way par was being used, it still seemed like DAT was pulling things out of thin air.
The two influences that corrupted my thinking on this matter were 'C', where local variables are not only local, but they are often ephemeral. The very idea that a different cog or object could access them was automatically rejected by my brain until it was faced with the reality that it couldn't be happening any other way.
The other corrupting influence was the #$*%&% (read contemptible) code example on pg. 178. Not only did it reinforce the idea that only global variables could be shared variables, it implanted the idea that PAR could be used no other way. Potatohead provided the first inkling that this was wrong. Until then it didn't matter how many code listing I looked at, I was still trying to fit what I found elsewhere into the paradigm established by the PAR example on 178. A red herring all the way.
Then, when Heater directed me to a piece of code (Float32) that was so uncluttered with other business, and had practically no global variables, and was obviously employing legerdemain for its operation, well, the cookie crumbled. Or biscuit, rather.
I still despise the unnamed curmudgeon that precipitated this whole public shame. But Parallax got what they wanted, I didn't give away too much of what I'm working on, and a profound respect for several individuals just grew deeper.
A look at the 6502 reveals we know damn near everything there is ever to know about that chip now. Back when Woz built the Apple, we didn't! And that computer shipped with a rough theory of operation, detailed ROM code listings for those wanting to learn, and schematics!
I'd have to second what you said here.
The 6502 and the Apple II were vast mysteries to me. I could only imagine what lurked in their depths. Grasping the whole picture seemed pretty much beyond the capabilities of mere mortals.
Now they look pretty provincial, simple, and small. These days I find myself wondering why I was so diffident about delving into their intricacies back then.
Anyway, the two points I wanted to make are:
* I'm amazed by young people like Kye. Given the leaps of understanding he and others have already made on matters that seem a whole lot more complex than the 6502 and Apple DOS, I can only imagine what they will be doing in 10 or 20 years.
* Given the breadth and complexity of what they've had to document, Parallax has done a great job. It is always sharp and professional looking.
Comments
Well, I did PM two Parallax employees as well, but I heard nothing from them at all. I'm certain they're very busy with more important tasks. Answering customer queries almost certainly isn't one of their assigned duties. It may be that no one is assigned that duty.
What can I say except that I agree with you entirely. It is admirable of deSilva and potatohead to have gone to such an effort out of the goodness of their hearts. But it seems just a tad shameful on the part of Parallax that the vacuum exists. If money is the problem, sell downloads of the PDF for $10 a pop. Frankly, at this point I would pay $10 for smudged photocopies of just a few functional templates.
I started PASM by pulling to bits the Zicog that heater wrote. I started by changing just one line of code, then recompiled it to see what happens. Pretty soon I found I had a grasp of many of the instructions. Try adding a tiny new routine in and see:
1) if it still runs and
2) if it now does the thing you programmed it to do.
Then I pulled to bits the prop demo board and started adding new bits.
There is a real lack of documentation I agree. My 'documentation' is the collective bits and pieces of code in the obex.
Can you be more specific about the code you want to write and what you want to do - I'd be fairly sure there is enough collective wisdom here to help out a lot.
In the end, it is quite simple: Read Goethes Dr.Faustus, both parts. All the life and everything behind is in.
What I want to say is: there is no way to experience except doing everything by yourself, falling in every pit and crawl out again. The best users guide can not give you more than hint to the entry.
So, don't wait for what will never come. If you think, that a documentation is wrong, misses something, goes the wrong way: write a better one, use your experience at your best. And do NOT read it again after three years: you will be ashamed.
Life is a compromise and in the end, all decide the same way to go. For different reasons. ;-)
It's probably a good idea to ask for support through the official support request process:
http://www.parallax.com/tabid/381/Default.aspx
Parallax seems to be full of helpful people (from the top down (or bottom up if you prefer)) and I think there is someone there assigned to help all of us.
Chip's graphics object or the one with 4 serial ports fully configurable in a single COG are at the higher end.
Just a cuple of ideas:
Check well known objects doing simpler tasks. For instance all the float family, or the 32 servo control.
In the past the servo object was modified for a fine timing issue discussed on the forum. Maybe finding the old discussion, and the previous code would prove a great tutorial.
In another discussion Beau posted a cordic code. In this object a cog worked as a coprocessor, waiting for a request to perform a task. The code was well documented and modular, allowing room to add up to 256 functions.
I modified it (well.. messed up..) to access also an array, and to do other tasks, but I think I still have the original code.
You might already know all the stuff, so forget about it, but looking at first quality code is one of my favourite learning mehods.
Massimo
This is how I learn also. I suspect if I didn't have such a huge vasovagal reaction probably triggered by hemophobia I'd probably have been a doctor too
I like to think of it as the "break it then fix it" method of learning. In your case, you took a working zicog, broke it by changing it and learned how to fix it to work again. Books are incredibly valuable, but are no substitute for real "in the trenches" world experience
I really hope none of you patients are readers here
Here is an observation from Max Robinson an expert in tube radios:
http://www.angelfire.com/electronic/funwithtubes/
On a seious note: assembler needs some work till you understand why and maybe how
When I want to do some pasm development (didn'T happen in a while
I am trying to get the Propeller Tricks and Trap pdf, but I get and error
saying the file is damaged and can ot be repaired.
http://forums.parallax.com/attachment.php?attachmentid=49618&d=1191033043
Any help would be appreciated.
EDIT: Never mind - I did find it in the old forum http://forums.parallaxinc.com/forums/attach.aspx?a=17267
Be glad when the forum issues are fixed!
My early computing experience was similar to the one Heater describes. There was some functional documentation, like we see here, and some code, which appears to be more than they had on 6809.
I find it very interesting that I used to go grocery shopping with Mom, eager to pick up a copy of a computing magazine that actually talked about computing! There was code in there, techniques, sometimes a game, and lots of basic material on how things could be done.
Fast forward to today, and it's really not all that different with the forum. The same core bits are there, there is a lot of code, and we've got a great peer group applying the tech.
Back then, "video generators" were only loosely documented, just as this one is. Happy accidents, and "hacks" applied to them, resulted in great displays over time, as has happened with this one. (agreed on a functional diagram being missing, and not interested in starting that discussion again)
I liked Andre's book. It's worth the money, and it's got a great treatment of how to apply the chip in different contexts. The "Official Guide" is also quite good, both recommended.
A look at Chips multi-cog video driver, or Baggers and Eric Ball multi-cog sprite code, shows the application of some higher order comp-sci understanding, to the propeller. The same can be said for the SIDCog, or probably my text drivers (that one not as advanced in the comp-sci sense), or any number of great objects we have to look at
Eric went ahead and did a software color signal on the Propeller, for example. It does not use the chroma generator in the video generator. The docs necessary for that are the Prop Data Sheet, and instruction references. Outside of Parallax, the docs required are those that detail video signals, and how chroma works, followed by some generic comp-sci stuff on loops, and math.
To learn from those, one only needs to read the code. Every line of code tells a story, and understanding that story requires fetching the relevant information from the various disciplines that are incorporated into the object. What Andre' did was combine that for games, and it's worth it.
Andre is a subject matter expert in games. Seems to me, the kinds of documentation being asked for, most often would come from subject matter experts in the various disciplines, noting their application of the propeller. That seems to put the burden on the eco-system more often than not, at least from where I stand.
With modern computing, often the barrier is high for entry. Things are very complex, limiting the "just do it" and "just read the code" approach, and perhaps that's where part of the disconnect is. The beauty of companies like Parallax, is the time taken to package tech into usable pieces, so that people can learn, do, play, build, etc... without having to run through a lot of school, and or read thick volumes to get stuff done.
I find it difficult in my mind to reconsile these things. Mature tech has gone through that process multiple times, with it's "ecosystem" contributing, building, etc... A look at the 6502 reveals we know damn near everything there is ever to know about that chip now. Back when Woz built the Apple, we didn't! And that computer shipped with a rough theory of operation, detailed ROM code listings for those wanting to learn, and schematics! The rest was applying the various diciplines to the computer.
Today, with the Prop, that really isn't any different. How can it be?
And so I don't understand the "need docs" queries here. If one wants to make sound, it seems to me, obtaining some info on the theory of sound, music, and audio tech, terminology, and application is needed. Once that has been obtained, one then applies the computing technology, along with some circuit (such as PWM) to then generate sound. Those docs exist in many forms, do they not? --leaving only the functional description of the propeller, and it's electrical characteristics as the necessary bits needed to actually apply the propeller then.
BTW: I think this is a great thread, aptly titled. When I was a kid, learning how to do these things, perspective was the most valuable thing I found. Learning how people think to solve problems was often more important than seeing solutions. Today, that remains true --plus we have the net now, meaning most core things about most disciplines are out there for the taking!
So the part I don't understand is why not just do that?
Here's an interesting question:
If you could "mind meld" with another person, and let's say Chip, just because it's fun, and you could get something. Would you get all the detail on the Propeller, or would you get the way of thinking that led to the realization of something like the Propeller?
I would take the latter in a second, because that empowers a person to consume what they can find and apply it. Taking the former is great, but would only be valuable, given somebody has the application knowledge already, would it not?
max72: No, I don't know all that! Thank you for it.
heater: It's not a question of how to implement the algorithms. They were created in C (for the ARM) some time ago, and I converted them to PASM this week. Thanks to jazzed's BMADebugger, they've even been verified. The problem is that I need to get six cogs running the code and sharing variables in Hub RAM. And the variables in Hub also need to be accessed by SPIN running on the other two cogs.
The sharing of MULTIPLE variables is the first problem. All I have to go on is page 178 of the Propeller Manual. But a SINGLE SHARED VARIABLE AND A FEW PROP PINS ACTING AS STATUS BITS TO COORDINATE ITS USE IS NOT A BIG ENOUGH PIPE FOR THIS APPLICATION. (Note: I'm not yelling at any one person. I'm not yelling at all. I simply want to emphasize something I've already mentioned and no one has seen. Who needs cryptography? Just post it on the Prop Forum and it is certain it will never be read... Joking...Just joking.)
The timing of cog launches and the passing of parameters is the second problem.
The reason I keep bringing up Chip's VGA code is because he seems to be solving both problems. But I'm completely confused about how. That's the rub.
Maybe this is too ambitious for a first PASM project. But it is also the only PASM application that had enough attraction to me to want to see it through. It's a conundrum.
Shouldn't that be flags, and or timing?
The PAR register is only one way of establishing that kind of communication. One common use is to have the PAR register point to sequentially ordered HUB memory locations, which then either serve as status flags, for the cogs to understand who is communicating with who and why, and as pointers to buffers where said communication occurs. If those addresses are defined in advance, PAR is not necessary at all.
Most of the time, PAR is just used in this way, not actually passing anything of importance, but just the address of where those things reside in the HUB.
Very simply because it's the only tool in my PASM box.
Every sentence you just wrote is new to me. Your post is ENTIRELY germane to my problem. So couldn't Parallax provide a simple template incorporating and documenting the very things you just mentioned? I am not asking for another tutorial - I don't have the patience, they're too wordy, and Parallax doesn't have the time. But USEFUL examples and templates would be MARVELOUS.
There is some code out there that does these things...
I'm gonna think on it some. Perhaps some others will chime in.
Can you describe at high level, what your data comms look like?
A few weeks ago I was learning how variables could be passed between PASM and Spin in main memory. Damn near cooked my noodle because the example I was following (FullDuplexSerialPlus) didn't explicitly make comments as to how and why it was doing what it was doing on the PASM side. I could find no tutorial, template or example about it. I feel your pain. I set about commenting their code and the picture of what it was doing emerged. I may pick up the torch and write an example and explain it, though I am a newbe and not qualified to do so
I've just downloaded it. I look forward to following your comments. It may be just the ticket!
Edit: Alas, I've got a long way to go before FullDuplexParallel becomes my Rosetta Stone. I see the parts you've commented, and they are very helpful. But there is a whole lot of uncommented content that I don't yet understand. I will likely have to do my own noodle cooking on those parts.
FullDuplexSerial is a wonderful thing and a great example of PASM code tricks. But I wonder if it's a good place to begin if you are starting out on the road to understanding data communication between COGS.
1) It actually has two "threads" going on in one COG. One for transmit and one for receive. These separate activities are implemented as "coorotines" using jmpret to change context from one thread to another at suitable points in the code. I would put this technique under the "advanced" heading for anyone getting into PASM.
2) It uses a cunning cyclic buffer technique to implement input and output buffers in such a way that the buffers are shared with the application without risk of corruption when both FDX and the application are accessing the buffer at the same time. Also with out the use of LOCKS. Again this technique I would put under the heading of "advanced". Not that the PASM to do it is hard, just that the idea itself is kind of non-obvious.
And no you don't need pins to synchronise communication between COGS. It might be argued that you can synch COGs faster using pins but let's not go there yet.
As we are talking crypto code let's set up a simple thought experiment with that:
1) Let's say Cog A, in Spin or PASM, has blocks of plain text that it wants to be encrypted by some other COG B.
2) All wee need is a buffer in memory whose address is known to both COGS. So let that be an array buffer[0], buffer[2]...buffer[n]
3) Let's put the data blocks, of length "n" into array elements 1, 2, 3 ...n
4) Let's use buffer[0] to synchronize the two COGs. buffer[0] has the value 0 on start up.
5) When Cog A has a block to encrypt he writes it to the buffer starting at buffer[1]. Then he writes some special value to buffer[0]. Could just be 1, meaning "data available, please encrypt it".
6) Cog B meanwhile has been sitting in a loop reading buffer[0] as long as it is 0 he keeps looping. When it becomes 1 he breaks out of the loop and proceeds to read and encrypt the data from buffer[1] upwards.
7) Whilst B is doing that Cog A sits in a loop waiting for buffer[0] to become 0 again.
8) When Cog B is finished his work he writes the encrypted data back to the buffer starting at buffer[1]. He the sets buffer[0] back to 0 and goes back to waiting for it to become non-zero again.
9) Cog A sees the buffer[0] is now zero again and hence knows he can put new data there if he wants to.
In this way the two COG share data and have synchronized their access to it. They are never reading and writing the buffer at the same time and scrambling data. They don't need locks to do this. Just the control flag provided by buffer[0]
The only remaining problem is "How do these two COGs both know the address of the buffer array?"
Well, one knows it because it is defined in his object. He can start the other COG and pass the buffer address through the PAR mechanism.
For a good example of how this is look at the floating point object in OBEX. Or VMCog uses a very simple "mailbox" technique like this. Never mind how the guts of those two objects work but the data passing they use is simple enough.
http://forums.parallax.com/showthread.php?t=119725
BTW, the pins weren't hard to use at all. They were just status bits to me, and I've been dealing with status bits and defining my own protocols forever. But they were probably a waste of a valuable and scarce resource. It was just that, lacking a second shared variable or any other means of information transfer, they were necessary. It was part of the original failed plan to get things working in a day or two.
Anyway, a rather essential aspect of this project is that it is not an encoding device. At the moment, it is a research tool. The nature of the research is such that it doesn't follow the plaintext-encoder-cyphertext paradigm. But it does need about ten shared memory locations between each cog and the Hub.
(As implemented on the ARM array, the algorithms run day and night for weeks, slowly accumulating data. That's why I'm so keen on more- and faster processors. I'm terribly interested in what the Propeller can do vis-a-vis ARM Cortex chips. FWIW, I'm not using necessary the fastest ARM chips, but rather whatever chips deliver the most functional MIPS-per-$ once all the costs are factored in, including the price of programming tools.)
The outline of the thought experiment you've provided is more than ample to accommodate my current needs. Since the Prop implementation is new, I'm not 100% sure what the final configuration will look line, i.e., what config will deliver optimum performance. I'm not even sure how the tasks will ultimately be distributed across the sea of cogs.
The "remaining problem" that you mention really is the problem. I'm very interested in exploring both Float32 and VMCog to see what I can glean from them w.r.t. it.
Thank you so much for direction you have provided!
Yea, I looked back at my code and I didn't keep the comments on where it was establishing the pointers to main memory in PASM. There is some trickey going on there that is not documented. Sorry bout that.
--Terry
It will stay in my library as a text for the PASM201 class. There's plenty to be learned there.
I couldn't find VMCog for some reason. Bill's link didn't work and I couldn't find it on his webpage either.
Fortunately, Float32 looks perfect! I already had it on hand and had looked at it frequently, but more at the algorithms. Floating point libraries are a fascinating thing.
Anyway, I can see that it's about as perfect for the job at hand as anything could be. It's noodle cooking time.
Do not over cook the noodles:)
K2,
This kind of thing bit me for a short while. I wrote ASM for years on the 6502, 68xx, 680x0, Z80, etc. and tried to apply my same style of coding to the Propeller Assembly. I ended up throwing all my previous experience aside and just looking at it from a new perspective and it seemed to make more sense to me. Maybe this won't help you, but I recognize the situation, having been in your place at the start.
In Float32.spin, the first line in DAT is: rdlong t1, par wz
Edit:
Major Edit:
Major Major Edit:
Nevermind. I get it.
I think I will burn page 178. For me it was a complete red herring.
OK, good riddle.
If we look in the Spin start method of VMCog, just because I have it open in front of me, we see that it starts it's PASM work in a new Cog with the line:
cognew(@vmcog, mailbox)
Where:
1) "vmcog" is the label at the start of the PASM code in its DAT section.
2) The "@" symbol means "take the HUB memory address", of the vmcog code in this case.
3) And "mailbox" is a variable holding the address of one of those data exchange areas we talked about earlier.
So what happens, what does this cognew do?
1) It loads up the 496 LONGs from the given address, from vmcog in this case, into the memory of new COG.
2) It starts that new COG running that code.
3) And here is the "magic" part, that second parameter, the "mailbox" value ends up in the PAR register of that newly running COG.
So I guess 3) is the missing link for you. When the PASM is running the register PAR is where you can find whatever parameter was sent to the COG from SPINs cognew.
That value in par could be just a value, say a LED flash frequency, but more often than not it is a pointer to some memory containing multiple parameter items or like in this case a data exchange "mailbox"
So now we look in the vmcog PASM code and it starts with:
init_vm mov pvmcmd, par ' save pointer to mailbox, first word is command add pvmcmd, #4 mov pvmaddr, pvmcmd ' pvmaddr = pointer to long in hub that holds the vmaddr add pvmcmd, #4 mov pvmdata, pvmcmd ' pdata = pointer to long in hub for byte/word/long to be read/written to/from vmHere we see it is saving the value of par as the address of some command variable in HUB. Then it saves that address +4 and +8 as the address of other components of the data exchange mailbox.
Now all this is detailed on page 189 in the COGNEW section of my Propeller manual where it says:
What, after I wrote all that?:)
Nevermind. Next problem...
Edit: It will also enlighten many to come. And if Parallax ever takes my advice to compile a list of the best answers to oft-recurring questions, they'd better include your post or I'll turn the Whine Machine back on!
@ Parallax: Yes, it is the height of hubris for some Johnny-Come-Lately to think he was the first to suggest anything. Relax, Johnny doesn't think that.
@ BradC: I visited a dialysis patient once and fainted in the hallway. Pretty embarrassing. Blood flowing through plastic tubes was more than I could handle. Also, your BST is great! Didn't know what it was, or that it was available for Windows until Bean suggested I take a look at PropBasic. I definitely have to spend a bunch more time with it.
@schill: Didn't know anything about the official support request process. Many thanks for the heads-up.
@ErNa: You are absolutely right. Rather than grousing about Parallax and all they ought to do, I should do what I can do. I should start my own compilation of the best solutions. If it's any good, maybe it will benefit others. Also, it would put me in charge of the selection; I could make certain that Heater's post gets in.
@ Heater: Thanks for directing me to VMCog. I saw the letters 'debug' and figured that wasn't it.
BTW, the reality dawned when I realized that the PropTool must have stacked together the SPIN variables - local variables to be specific - into a contiguous list so that par could reference them in the first place. The lack of global variable declarations really threw me for a loop. Even when I understood the way par was being used, it still seemed like DAT was pulling things out of thin air.
The two influences that corrupted my thinking on this matter were 'C', where local variables are not only local, but they are often ephemeral. The very idea that a different cog or object could access them was automatically rejected by my brain until it was faced with the reality that it couldn't be happening any other way.
The other corrupting influence was the #$*%&% (read contemptible) code example on pg. 178. Not only did it reinforce the idea that only global variables could be shared variables, it implanted the idea that PAR could be used no other way. Potatohead provided the first inkling that this was wrong. Until then it didn't matter how many code listing I looked at, I was still trying to fit what I found elsewhere into the paradigm established by the PAR example on 178. A red herring all the way.
Then, when Heater directed me to a piece of code (Float32) that was so uncluttered with other business, and had practically no global variables, and was obviously employing legerdemain for its operation, well, the cookie crumbled. Or biscuit, rather.
I still despise the unnamed curmudgeon that precipitated this whole public shame. But Parallax got what they wanted, I didn't give away too much of what I'm working on, and a profound respect for several individuals just grew deeper.
I'd have to second what you said here.
The 6502 and the Apple II were vast mysteries to me. I could only imagine what lurked in their depths. Grasping the whole picture seemed pretty much beyond the capabilities of mere mortals.
Now they look pretty provincial, simple, and small. These days I find myself wondering why I was so diffident about delving into their intricacies back then.
Anyway, the two points I wanted to make are:
* I'm amazed by young people like Kye. Given the leaps of understanding he and others have already made on matters that seem a whole lot more complex than the 6502 and Apple DOS, I can only imagine what they will be doing in 10 or 20 years.
* Given the breadth and complexity of what they've had to document, Parallax has done a great job. It is always sharp and professional looking.