I have a question about the HDMI specifically. Is the image buffered? I can see that it's 640x480@60Hz - how many bits/pixel? Can the p2 do a full image buffer where a user could set/address individual pixels? If so, it wouldn't be that difficult to apply a graphics engine like we used with the OLED display and allow users to draw shapes/text/etc.
When questions can be answered by people other than Chip (like Rayman just did) we will all benefit. We have to externally manage his time, where possible.
You could have the Z axis fade as it recedes like they do in some games ("fog"). Intensity cue the signal as it comes forward towards the viewer.
Alternatively you could do like they do in Rhino cad, where there are typically 4 views on the screen at once - one from arbitrary angle (eg iso), then plan and a couple of elevations (XY, XZ, YZ).
I have a question about the HDMI specifically. Is the image buffered? I can see that it's 640x480@60Hz - how many bits/pixel? Can the p2 do a full image buffer where a user could set/address individual pixels? If so, it wouldn't be that difficult to apply a graphics engine like we used with the OLED display and allow users to draw shapes/text/etc.
I did this last year with the VGA 640x480x8 in TAQOZ with ploting, rendering fonts, drawing lines and boxes etc as well as displaying bmp graphics and 320x240 movies scaled to 640x480.
To draw a red panel at 40 x 40 y by 200 wide and 100 high, this is the syntax I use:
40 x 40 y 200 w 100 h red panel
But no, it's not buffered as the VGA 80bit color requires 300kB, however if you drop the bpp or introduce color tiles then you can certainly have it buffered.
@MattMatz If you have access to external HyperRAM and a P2 you should very soon have a full screen full bit depth frame buffer with VGA/DVI outputs that other COGs can access for doing interactive frame buffer based graphics. That is being developed right now.
Also even though you can still get or set individual pixels in external memory the latency is far higher than HUB RAM so wherever possible in your application the accesses to external memory can also be done in bursts for higher performance. For example a circle fill graphics routine could transfer blocks of suitable size/colours to each affected scan line in the frame buffer at the appropriate start and end x co-ordinates of the circle on that scan line. Once it gets going the burst fill to HyperRAM can be very fast, though not quite as fast as to HUB if setq is used with longs. That's as fast as things get.
I think adding a fill routine (i.e. write with a single value) as part of the HyperRAM driver makes sense too. That way the calling COG doesn't need to setup its own line of that size and pre-fill it to do a simple block fill in external RAM. Same goes for block copy between HyperRAM regions, though that may need a dedicated scratch area of say 128 or 256 bytes.
I have a question about the HDMI specifically. Is the image buffered? I can see that it's 640x480@60Hz - how many bits/pixel? Can the p2 do a full image buffer where a user could set/address individual pixels? If so, it wouldn't be that difficult to apply a graphics engine like we used with the OLED display and allow users to draw shapes/text/etc.
It's 8 bits per pixel. There are a few streamer modes, luma8 and rgbi8, where no pallet is necessary in the LUT, in order to produce 256 or 32 shades of 8 different colors.
Yes, you could make shape and line-drawing routines to display whatever you want in the 640x480 pixel array.
I understand .scpmode and .scp_x. They get defined elsewhere. But, to me, #3<<6 + scp_base comes to:
#3<<6 = shift %11 six bit positions left to yield %11000000, or 192
now add scp_base (52) to get 192 + 52 = 244. Obviously that's not a valid pin number for the Prop-2. Where did I go wrong?
I'm interested in how to set up the inputs for a 4-channel "scope" and use them to get 8-bit values from 3 or 4 inputs. No HDMI, no display, just data.
BTW:
1. This calculation should occur once in the program.
2. This type of "complex" notation, with shifts, ANDs, ADDs, and so on confuses newcomers (like me) to Prop-2 assembly language. Please consider straightforward, non-computed, unshifted values for information such as pin numbers, bit masks, bit positioning, and so on. Strive for clarity. Experts on this Forum understand these things, but to someone getting started, they can be a time sink or a dead end. --Jon
I understand .scpmode and .scp_x. They get defined elsewhere. But, to me, #3<<6 + scp_base comes to:
#3<<6 = shift %11 six bit positions left to yield %11000000, or 192
now add scp_base (52) to get 192 + 52 = 244. Obviously that's not a valid pin number for the Prop-2. Where did I go wrong?
This needs to be read as pins 52 (scp_base), 53, 54 & 55 (3 more pins). This allows all 4 smart pins to be configured and made active simultaneously.
Building the shift and add into the value would require just as much explanation. What is really missing here is proper commentary to explain why the shift and add is there.
The demo was written for a more experienced audience, but not revisited until now.
I understand .scpmode and .scp_x. They get defined elsewhere. But, to me, #3<<6 + scp_base comes to:
#3<<6 = shift %11 six bit positions left to yield %11000000, or 192
now add scp_base (52) to get 192 + 52 = 244. Obviously that's not a valid pin number for the Prop-2. Where did I go wrong?
This needs to be read as pins 52 (scp_base), 53, 54 & 55 (3 more pins). This allows all 4 smart pins to be configured and made active simultaneously.
Building the shift and add into the value would require just as much explanation. What is really missing here is proper commentary to explain why the shift and add is there.
The demo was written for a more experienced audience, but not revisited until now.
There is a nice semantic ADDPINS operator now, but I think that didn't exist when the demo was written.
The values for .scpmode and .scp_x get defined elsewhere and seem OK. But I must have missed something about the operation #3<<6+scp_base. Shifting 3 (%11) six positions left equals 192. Then add 52 for scp_base and the pin number comes to 244. That can't be right. What have I missed?
I want to understand how to set up the four pins for analog measurements; no HDMI, no LCD, no LEDs, just the 8-bit ADC data and how to get the scope mode to work.
For what it's worth:
1. Usually in a program you aim to calculate the value of #3<<6+scp_base once. That makes code easier to read, understand, and revise.
2. To help newbies such as me understand code such as #3<<6_scp_base would it be better to show the actual value and how the a comment to explain where the values come from than to put a roadblock in our progress? For me, simplicity and clarity are the keys to good examples. Thanks for your help. --Jon
@JonTitus
Thank you for your post. This is where I have asked for some slow instruction and comments as to what is actually happening in the code. Too many assume that we ALL understand. There are many who try to help and help well but we are all learning. That is what I am doing. So if folks can comment clearly we can all understand.
Thanks again.
Chip usually writes quick routines for the more experienced to see what can be done. He leaves the rest for us to expand upon. It's probably the easiest way to get some of the quirky features that can do amazing things out there for us to experiment with.
There's no way Chip would have time to write a full set of documented routines! We're great-full for the tidbits of info we get from him.
BTW This scope mode was "sneaked" into one of the chip revisions. IIRC the first we knew of it was the code snippet
... But, to me, #3<<6 + scp_base comes to:
#3<<6 = shift %11 six bit positions left to yield %11000000, or 192
now add scp_base (52) to get 192 + 52 = 244. Obviously that's not a valid pin number for the Prop-2. Where did I go wrong?
That's one of the changes from revA to revB silicon. A lot of the documentation was written for revA. And in this case wasn't rewritten to give the new details, although there is short description in the instruction spreadsheet that Chip maintains alongside the main doc.
In revB, pin instructions gained a second field that allowed setting of 1 to 32 pins at a time. The "S" operand nearly doubled in size from six bits to eleven bits.
AKPIN S/#
WRPIN D/#, S/#
WXPIN D/#, S/#
WYPIN D/#, S/#
S/# %xxxxxxxx_xxxxxxxx_xxxxx_CCCCC_BBBBBB
C: Contiguous span of pins - 1, eg: #0 is the single pin specified by base pin.
B: Base pin number.
The span wraps from P31 to P0, and from P63 to P32.
Folks: I still would like to know how this instruction works, how the bits shift, what gets added, and so on, step by step. I don't understand it.
wxpin .scp_x, #3<<6+scp_base
I understand comments about what the result does. --Jon
from above:
WYPIN D/#, S/#
S/# %xxxxxxxx_xxxxxxxx_xxxxx_CCCCC_BBBBBB
C: Contiguous span of pins - 1, eg: #0 is the single pin specified by base pin.
B: Base pin number.
so CCCCCC == #3
and
BBBBBB == scp_base
to get the #3 in the right place you have to <<6 shift it left 6 bit positions and add scp_base to it
so this works here on 4 pins (n-1 = 3) at one go starting with scp_base pin number
How much crosstalk is there between non-paired pins? There is likely still some from the pcb and package. Digital outputs have a low impedance and probably aren't a good representation of an analog source. Maybe 50 ohms from digital output to ADC, or use a reduced drive mode.
Very little between non-paired pins, but between paired pins, the crosstalk is at about -24dB, which is really high, about 4 bits down.
I get this error. what am I missing? please
Thanks
Comments
It'll be revision C.
I have a question about the HDMI specifically. Is the image buffered? I can see that it's 640x480@60Hz - how many bits/pixel? Can the p2 do a full image buffer where a user could set/address individual pixels? If so, it wouldn't be that difficult to apply a graphics engine like we used with the OLED display and allow users to draw shapes/text/etc.
Yes, images is buffered in HUB RAM. At 8bpp or less, the full image fits in HUB RAM.
Yes, graphics engines can be done.
I've actually done some already for the FPGA version... Have to dust those off soon...
BTW, HDMI works the same as VGA under the hood, so it's easy to make a driver that works for both.
BTW2, HyperRam should enable 24-bit color (and higher resolutions for VGA).
We need him focused on Spin2 right now.
Thanks,
Ken Gracey
Why stop at XY? Why not have XYZ mode with the Z axis represented by colour?
Addit: I'm open to ideas for representing the fourth channel too. I guess two sets of XY with different colours to differentiate the sets would work.
You could have the Z axis fade as it recedes like they do in some games ("fog"). Intensity cue the signal as it comes forward towards the viewer.
Alternatively you could do like they do in Rhino cad, where there are typically 4 views on the screen at once - one from arbitrary angle (eg iso), then plan and a couple of elevations (XY, XZ, YZ).
P2 is going to be great for such visualisation
I did this last year with the VGA 640x480x8 in TAQOZ with ploting, rendering fonts, drawing lines and boxes etc as well as displaying bmp graphics and 320x240 movies scaled to 640x480.
To draw a red panel at 40 x 40 y by 200 wide and 100 high, this is the syntax I use:
But no, it's not buffered as the VGA 80bit color requires 300kB, however if you drop the bpp or introduce color tiles then you can certainly have it buffered.
Also even though you can still get or set individual pixels in external memory the latency is far higher than HUB RAM so wherever possible in your application the accesses to external memory can also be done in bursts for higher performance. For example a circle fill graphics routine could transfer blocks of suitable size/colours to each affected scan line in the frame buffer at the appropriate start and end x co-ordinates of the circle on that scan line. Once it gets going the burst fill to HyperRAM can be very fast, though not quite as fast as to HUB if setq is used with longs. That's as fast as things get.
I think adding a fill routine (i.e. write with a single value) as part of the HyperRAM driver makes sense too. That way the calling COG doesn't need to setup its own line of that size and pre-fill it to do a simple block fill in external RAM. Same goes for block copy between HyperRAM regions, though that may need a dedicated scratch area of say 128 or 256 bytes.
It's 8 bits per pixel. There are a few streamer modes, luma8 and rgbi8, where no pallet is necessary in the LUT, in order to produce 256 or 32 shades of 8 different colors.
Yes, you could make shape and line-drawing routines to display whatever you want in the 640x480 pixel array.
I finally got around to trying this demo. Looks great.
COM scp_base = 52
...
wrpin .scpmode, #3<<6+scp_base
wxpin .scp_x, #3<<6+scp_base
dirh #3<<6+scp_base
I understand .scpmode and .scp_x. They get defined elsewhere. But, to me, #3<<6 + scp_base comes to:
#3<<6 = shift %11 six bit positions left to yield %11000000, or 192
now add scp_base (52) to get 192 + 52 = 244. Obviously that's not a valid pin number for the Prop-2. Where did I go wrong?
I'm interested in how to set up the inputs for a 4-channel "scope" and use them to get 8-bit values from 3 or 4 inputs. No HDMI, no display, just data.
BTW:
1. This calculation should occur once in the program.
2. This type of "complex" notation, with shifts, ANDs, ADDs, and so on confuses newcomers (like me) to Prop-2 assembly language. Please consider straightforward, non-computed, unshifted values for information such as pin numbers, bit masks, bit positioning, and so on. Strive for clarity. Experts on this Forum understand these things, but to someone getting started, they can be a time sink or a dead end. --Jon
This needs to be read as pins 52 (scp_base), 53, 54 & 55 (3 more pins). This allows all 4 smart pins to be configured and made active simultaneously.
Building the shift and add into the value would require just as much explanation. What is really missing here is proper commentary to explain why the shift and add is there.
The demo was written for a more experienced audience, but not revisited until now.
There is a nice semantic ADDPINS operator now, but I think that didn't exist when the demo was written.
The values for .scpmode and .scp_x get defined elsewhere and seem OK. But I must have missed something about the operation #3<<6+scp_base. Shifting 3 (%11) six positions left equals 192. Then add 52 for scp_base and the pin number comes to 244. That can't be right. What have I missed?
I want to understand how to set up the four pins for analog measurements; no HDMI, no LCD, no LEDs, just the 8-bit ADC data and how to get the scope mode to work.
For what it's worth:
1. Usually in a program you aim to calculate the value of #3<<6+scp_base once. That makes code easier to read, understand, and revise.
2. To help newbies such as me understand code such as #3<<6_scp_base would it be better to show the actual value and how the a comment to explain where the values come from than to put a roadblock in our progress? For me, simplicity and clarity are the keys to good examples. Thanks for your help. --Jon
Thank you for your post. This is where I have asked for some slow instruction and comments as to what is actually happening in the code. Too many assume that we ALL understand. There are many who try to help and help well but we are all learning. That is what I am doing. So if folks can comment clearly we can all understand.
Thanks again.
@evanh
Finally got some time to code. I am back on what you taught me.
Moving forward.
Thanks
wrpin, wxpin, dirh and setscp are executed on all of those 4 smartpins at the same time.
one of the wonderful things the P2 can do. Pin Groups accessed with one PASM statement.
And YES you could precalculate the value and store as constant or so. But better use ADDPINS in the future, it makes more readable code in Spin2.
Enjoy!
Mike
There's no way Chip would have time to write a full set of documented routines! We're great-full for the tidbits of info we get from him.
BTW This scope mode was "sneaked" into one of the chip revisions. IIRC the first we knew of it was the code snippet
In revB, pin instructions gained a second field that allowed setting of 1 to 32 pins at a time. The "S" operand nearly doubled in size from six bits to eleven bits.
wxpin .scp_x, #3<<6+scp_base
I understand comments about what the result does. --Jon
from above:
so CCCCCC == #3
and
BBBBBB == scp_base
to get the #3 in the right place you have to <<6 shift it left 6 bit positions and add scp_base to it
so this works here on 4 pins (n-1 = 3) at one go starting with scp_base pin number
I am not using C. I rather work with Tachyon/Taqoz in the future and understanding PASM helps ;-)
I get this error. what am I missing? please
Thanks
I have been out of the loop because of work. What do you suggest as the end and where?
Thanks
EDIT: Have a read of JonnyMac's new topic - https://forums.parallax.com/discussion/172172/using-inline-pasm2-to-learn-pasm2