As Chip suggested on live forum, I've made the diagrams for the bit permutes (MERGEB etc) animated. When you hover over the bit boxes, the line now strokes into the direction the thing goes. May be a bit gaudy. Also doesn't work in Firefox because it doesn't have :has. maybe I can refactor it to use less weird selectors, :has also seems to be slightly quirky in Chrome. (EDIT: No I can't.)
I can only see a value of this animation for the RGBEXP and SEUSSF. With these it really helps.
As for the rest it's so so (not really needed except maybe for the consistent behaviour).
It's an observation and not a complaint by any means.
@Wuerfel_21 said:
As Chip suggested on live forum, I've made the diagrams for the bit permutes (MERGEB etc) animated. When you hover over the bit boxes, the line now strokes into the direction the thing goes. May be a bit gaudy. Also doesn't work in Firefox because it doesn't have :has. maybe I can refactor it to use less weird selectors, :has also seems to be slightly quirky in Chrome. (EDIT: No I can't.)
That's cool!
Can you make it animate if they hover over the top or bottom areas where the instruction names and explanations are? Then, it would be more useful.
This makes me think that I should add a dashed line function to PLOT where you can specify the length and offset of the line breaks.
@cgracey said:
Can you make it animate if they hover over the top or bottom areas where the instruction names and explanations are? Then, it would be more useful.
With a really obnoxious selector, maybe. Will have to try.
Just wanted to say, that https://p2docs.github.io/ has now proven for the first time to be really helpful for me. (Was searching how to software reset P2)
Thank you very much!
Christof
It's great to have this reference material so handy to lookup Ada, well done. I'm pretty tired/lazy to go load googledocs and search in that each time and have to switch to view only mode etc to avoid edits. It's so sluggish. This is really snappy to look up P2 information.
The opcode matrix is cool too - haven't seen the P2 instructions presented like that before, although tables like this were obviously common for other older micros. I can now see some structure to the ISA madness.
Perhaps it would be a good thing to provide a table, what can be done with what kind of Ram. As far as I know there are three kinds of "private" Ram + 2 kinds of HUB Ram:
Cog: Use as accumulator registers, as accumulator registers for indirect access with ALTx, as code space
LUT lower half: Code space. Use for indirect access with PTRA/PTRB, indirect access through any cog register, access with immediate address, streamer access, read access from partner cog.
LUT upper half: Code space. Use for indirect access with PTRA/PTRB, indirect access through any cog register, NO access with immediate address, streamer access, read access from partner cog.
HUB non protected: ...
HUB write protected: ...
From LUT and COG the least versatile memory is the upper half of LUT. Perhaps it would be a good idea to encourage to use this first as best practice?! The background to write this, is that it took me quite a long time to realize, that the special power of Cog Ram is it's speed for data, since the hubexec with it's microcache was introduced. Coming from P1 it seemed natural to use it for code space. All the examples use Cog Ram for code space and Taqoz ends up to offer the upper half of LUT free for the user. The limitation of accessibility for the upper part of LUT came late in development of P2.
Sometimes the Streamer uses LUTRAM. Then, that area is special purpose.
Also, LUTRAM can be shared with the Cog's partner Cog's LUTRAM. Then, the two partnered LUTRAMs become somewhat transparent to each other as writes are automatically copied from one to the other. Or can be even be one way only.
The write protected part, last 16 kByte, of HubRAM is optional and defaults to not protected, so not any different to the rest.
Probably one point to make clear is that code address space is different to data address space:
Data address space is three spaces:
-- One space for CogRAM (0..$1ff longwords).
-- One space for LUTRAM (0..$1ff londwords).
-- One space for HubRAM (0..$ffff_ffff bytes, 4 GBytes).
Code address space is a single combined space (0..$f_ffff, 1 MByte):
-- The first 1024 addresses are longword addressing (cogexec) of CogRAM and LUTRAM consecutively.
-- With hubexec hubRAM accessed from 1024 ($400) and up as byte addressing. The first 1024 bytes of hubRAM are not accessible for code.
I love this documentation format and find myself using it all the time. It’s fast and is getting better with the additions you have been making. I especially like the quick search function. Too bad Parallax doesn’t have a similar setup for the Spin language.
Keep up the good work!
@DiverBob said:
Too bad Parallax doesn’t have a similar setup for the Spin language.
If someone wants to help me with writing the contents, I could do Spin2 docs, too.
Not sure if it should be a separate site or integrated into the current site. I kind of like having it as a hardware-only thing (that thus never gets outdated). There's also some overlap of keywords between asm and spin, so if the site is shared I'd need to implement some filtering feature for the search. For a separate site, I'd edit the stylesheet enough to where you can easily tell which one you're on...
"...I kind of like having it as a hardware-only thing (that thus never gets outdated).
Yes !
Please keep it that way.
Including anything software specific would mean tons of possible issues and zillion questions. Hardaware only is the way to go with this.
Does anyone have some example code that is simplistic like in the original PE kit manual for the P1.
It would be a great help. Translating from P1 to P2 is somewhat difficult.
Thanks in advance.
Martin.
Comments
As Chip suggested on live forum, I've made the diagrams for the bit permutes (MERGEB etc) animated. When you hover over the bit boxes, the line now strokes into the direction the thing goes. May be a bit gaudy. Also doesn't work in Firefox because it doesn't have :has. maybe I can refactor it to use less weird selectors, :has also seems to be slightly quirky in Chrome. (EDIT: No I can't.)
I can only see a value of this animation for the RGBEXP and SEUSSF. With these it really helps.
As for the rest it's so so (not really needed except maybe for the consistent behaviour).
It's an observation and not a complaint by any means.
That's cool!
Can you make it animate if they hover over the top or bottom areas where the instruction names and explanations are? Then, it would be more useful.
This makes me think that I should add a dashed line function to PLOT where you can specify the length and offset of the line breaks.
With a really obnoxious selector, maybe. Will have to try.
Only mildy terrible, as it turns out. Just had to move the text/arrows into groups.
@keyframes strokeflow-<%=id%> { from {stroke-dashoffset: 0;} to {stroke-dashoffset: 1.5;} } &:has(.bit_top:hover,.top_text *:hover) .conn line { stroke-dasharray: 0.85,0.65; animation: 0.5s linear reverse infinite strokeflow-<%=id%>; } &:has(.bit_bot:hover,.bot_text *:hover) .conn line:not(.extra) { stroke-dasharray: 0.85,0.65; animation: 0.5s linear normal infinite strokeflow-<%=id%>; } &:has(.bit_bot:hover,.bot_text *:hover) .conn line.extra { opacity: 15%; }Looks great, Ada!
Just wanted to say, that https://p2docs.github.io/ has now proven for the first time to be really helpful for me. (Was searching how to software reset P2)
Thank you very much!
Christof
I currently have info on condition codes on the "ASM Syntax" page: https://p2docs.github.io/asm_syntax.html#condition-codes
I think it should probably be moved to the "Cog resources" page (cog.html)? Though that also seems a bit off.
What do you bunch think?
I think it works where it is.
It's great to have this reference material so handy to lookup Ada, well done. I'm pretty tired/lazy to go load googledocs and search in that each time and have to switch to view only mode etc to avoid edits. It's so sluggish. This is really snappy to look up P2 information.
The opcode matrix is cool too - haven't seen the P2 instructions presented like that before, although tables like this were obviously common for other older micros. I can now see some structure to the ISA madness.
Heads-up...
Alpha blending chat moved here : https://forums.parallax.com/discussion/175046/alpha-blending-pixels#latest
An idea. @Wuerfel_21 @cgracey
Perhaps it would be a good thing to provide a table, what can be done with what kind of Ram. As far as I know there are three kinds of "private" Ram + 2 kinds of HUB Ram:
Cog: Use as accumulator registers, as accumulator registers for indirect access with ALTx, as code space
LUT lower half: Code space. Use for indirect access with PTRA/PTRB, indirect access through any cog register, access with immediate address, streamer access, read access from partner cog.
LUT upper half: Code space. Use for indirect access with PTRA/PTRB, indirect access through any cog register, NO access with immediate address, streamer access, read access from partner cog.
HUB non protected: ...
HUB write protected: ...
From LUT and COG the least versatile memory is the upper half of LUT. Perhaps it would be a good idea to encourage to use this first as best practice?! The background to write this, is that it took me quite a long time to realize, that the special power of Cog Ram is it's speed for data, since the hubexec with it's microcache was introduced. Coming from P1 it seemed natural to use it for code space. All the examples use Cog Ram for code space and Taqoz ends up to offer the upper half of LUT free for the user. The limitation of accessibility for the upper part of LUT came late in development of P2.
Also, LUTRAM can be shared with the Cog's partner Cog's LUTRAM. Then, the two partnered LUTRAMs become somewhat transparent to each other as writes are automatically copied from one to the other. Or can be even be one way only.
The write protected part, last 16 kByte, of HubRAM is optional and defaults to not protected, so not any different to the rest.
Probably one point to make clear is that code address space is different to data address space:
Data address space is three spaces:
-- One space for CogRAM (0..$1ff longwords).
-- One space for LUTRAM (0..$1ff londwords).
-- One space for HubRAM (0..$ffff_ffff bytes, 4 GBytes).
Code address space is a single combined space (0..$f_ffff, 1 MByte):
-- The first 1024 addresses are longword addressing (cogexec) of CogRAM and LUTRAM consecutively.
-- With hubexec hubRAM accessed from 1024 ($400) and up as byte addressing. The first 1024 bytes of hubRAM are not accessible for code.
I've just added a bunch more stuff to the site.
Including some serial boot info copy-pasted from the Google Doc.
Hmm, I should add the staging registers to the block diagram of the pins/smartpins ... I'm feeling confident on where they're located now.
I love this documentation format and find myself using it all the time. It’s fast and is getting better with the additions you have been making. I especially like the quick search function. Too bad Parallax doesn’t have a similar setup for the Spin language.
Keep up the good work!
If someone wants to help me with writing the contents, I could do Spin2 docs, too.
Not sure if it should be a separate site or integrated into the current site. I kind of like having it as a hardware-only thing (that thus never gets outdated). There's also some overlap of keywords between asm and spin, so if the site is shared I'd need to implement some filtering feature for the search. For a separate site, I'd edit the stylesheet enough to where you can easily tell which one you're on...
Yes !
Please keep it that way.
Including anything software specific would mean tons of possible issues and zillion questions. Hardaware only is the way to go with this.
Does anyone have some example code that is simplistic like in the original PE kit manual for the P1.
It would be a great help. Translating from P1 to P2 is somewhat difficult.
Thanks in advance.
Martin.
Looks really good!
UP and DOWN keys do not work though.
You mean like UP and DOWN arrows (scrolling buttons) ?
This I notoced as well (I'm on Opera on Linux) but no big deal.
Page UP/DOWN work, hovewer.
Well, it is a big deal. PgUp/PgDn move the whole content currently being displayed out of view.
I created an issue in github with a proposed fix
Fixed the issue yesterday. Please confirm that everything works as expected (and that I didn't break anything)
Looks good to me
Thanks!
All good but...
going along that route maybe someone will miss left and right arrows too at some pint, especially when in "zoom in" mode.
Nah, I'm just kidding