Good to see officially released documents even if they are not 100% completed. It's much faster to scroll through a locally stored PDF than always looking up those google documents.
BTW, is there some documentation about the new PASM single step debugger available, somewhere?
Also note that the entries fro xxxPIX are mildly misleading/incorrect.
ADDPIX sums individual RGB (reg, green, blue) color values of Src into that of Dest and stores the result in the Dest register.
ADDPIX is for one, agnostic of the actual color model (or whether the vectors represent colors to begin with), but more importantly, it adds all 4 bytes. (i.e. the "Alpha" channel, too).
I commented to that extent ages ago and Jeff seems to have forgotten to fix it.
@ManAtWork said:
Good to see officially released documents even if they are not 100% completed. It's much faster to scroll through a locally stored PDF than always looking up those google documents.
BTW, is there some documentation about the new PASM single step debugger available, somewhere?
These days I enjoy writing the documentation almost as much as I enjoy writing the software. One without the other seems like only half a job.
You're right. When I was a product manager at Toro, we always had a very detailed specification so that we could write the docs as the engineers were working on the hardware/firmware/software. Of course, both sides would meet often to make sure everything was progressing as required and that both elements matched. Doing things this way (full spec, no feature creep, parallel work) helped us cut our product development cycle dramatically.
I did not find better information in these documents regarding Goertzel, Streamer, WRLUT.
Ken runs the company -- I don't think he's writing docs. You should probably submit suggestions/issues to editor@parallax.com so that anything that needs to be addressed gets attention.
Your problem there is that you used the crusty assembler in TAQOZ that doesn't check for this case. Propeller Tool doesn't let you write invalid instructions.
Your problem there is that you used the crusty assembler in TAQOZ that doesn't check for this case. Propeller Tool doesn't let you write invalid instructions.
Well yes, in Forth it is always assumed, that the programmer knows, what he/she does. I don't know, what crusty exactly means. But Peter did a great job to give us this great tool und to include this assembler, which was a lot. Of work over several years.
I have discovered, that the limitation is mentioned in the source code file of the assembler.
I did not find better information in these documents regarding Goertzel, Streamer, WRLUT.
Ken runs the company -- I don't think he's writing docs. You should probably submit suggestions/issues to editor@parallax.com so that anything that needs to be addressed gets attention.
Hi,
writing docs is a rather big investment. I assume, that in this case the writer himself or somebody else has even to try out some things to be sure. I assume, that finishing the manuals will need several man- months. So this is certainly a management decision for the investment and for the priority. I am not sure, if Parallax are convinced, that they will get back that additional investment. So, sadly, I could understand, if they would not make the investment.
I therefore addressed @"Ken Gracey" . My own experience at work was, that the management influences quality of documentation very much, if they give time and value this work. If they ask for other things instead, doc does not happen.
@"Christof Eb." said:
...My own experience at work was, that the management influences quality of documentation very much, if they give time and value this work. If they ask for other things instead, doc does not happen.
That !
It is my experience too.
Sadly, there is little understanding among the managers that hunting bugs without having proper documentation sometimes costs big money too, not to mention peoples' frustrations and unexpected/unwanted delays that often cost money. But, at the end, the ROI has to be there, regardless of the decissions on the documentation.
Comments
Good to see officially released documents even if they are not 100% completed. It's much faster to scroll through a locally stored PDF than always looking up those google documents.
BTW, is there some documentation about the new PASM single step debugger available, somewhere?
Also note that the entries fro xxxPIX are mildly misleading/incorrect.
ADDPIX is for one, agnostic of the actual color model (or whether the vectors represent colors to begin with), but more importantly, it adds all 4 bytes. (i.e. the "Alpha" channel, too).
I commented to that extent ages ago and Jeff seems to have forgotten to fix it.
Another error, perhaps. For MUXQ it claims
Semi-incorrect, since MUXQ is the one instruction that can use stale Q values.
It is in the Spin2 doc file:
https://docs.google.com/document/d/16qVkmA6Co5fUNKJHF6pBfGfDupuRwDtf-wyieh_fbqw/edit?usp=sharing
Single step PAST debugging is awesome and look forward to trying it.
I just searched the above and this is all I find:
You're right. When I was a product manager at Toro, we always had a very detailed specification so that we could write the docs as the engineers were working on the hardware/firmware/software. Of course, both sides would meet often to make sure everything was progressing as required and that both elements matched. Doing things this way (full spec, no feature creep, parallel work) helped us cut our product development cycle dramatically.
Ken runs the company -- I don't think he's writing docs. You should probably submit suggestions/issues to editor@parallax.com so that anything that needs to be addressed gets attention.
Your problem there is that you used the crusty assembler in TAQOZ that doesn't check for this case. Propeller Tool doesn't let you write invalid instructions.
Well yes, in Forth it is always assumed, that the programmer knows, what he/she does. I don't know, what crusty exactly means. But Peter did a great job to give us this great tool und to include this assembler, which was a lot. Of work over several years.
I have discovered, that the limitation is mentioned in the source code file of the assembler.
Hi,
writing docs is a rather big investment. I assume, that in this case the writer himself or somebody else has even to try out some things to be sure. I assume, that finishing the manuals will need several man- months. So this is certainly a management decision for the investment and for the priority. I am not sure, if Parallax are convinced, that they will get back that additional investment. So, sadly, I could understand, if they would not make the investment.
I therefore addressed @"Ken Gracey" . My own experience at work was, that the management influences quality of documentation very much, if they give time and value this work. If they ask for other things instead, doc does not happen.
That !
It is my experience too.
Sadly, there is little understanding among the managers that hunting bugs without having proper documentation sometimes costs big money too, not to mention peoples' frustrations and unexpected/unwanted delays that often cost money. But, at the end, the ROI has to be there, regardless of the decissions on the documentation.
The change to using PTRX based came after @"Peter Jakacki" wrote the assembler, so it needs to get added to it, then you are fine.
I guess that is what @Wuerfel_21 meant with 'crusted', sadly Peter left so the development stopped.
Mike