MUL, MULS, ONES and ENC...
asterick
Posts: 158
Just out of curiousity, what do these instructions do currently?
Are they just NOPs?
Oh, and what is the result/carry of WAITPEQ and WAITPNE...
And all those ---'s in the data sheet for various flags on instructions (IE: MOVS), does it just pass the previous state of the flag through?
Are they just NOPs?
Oh, and what is the result/carry of WAITPEQ and WAITPNE...
And all those ---'s in the data sheet for various flags on instructions (IE: MOVS), does it just pass the previous state of the flag through?
Comments
According to Propeller manual Z flag is set if the input ANDed with the mask (source) is zero. So this doesn't really make sense on WAITPEQ when it's only true if (MASK & INx) == 0 == STATE, so it will get set only if STATE is 0. And usually you know the value of STATE while coding. But on WAITPNE it makes more sense: (MASK & INx) != STATE, so MASK & INx may be zero regardless of STATE after the instruction.
EDIT: The - means it will write 0 to the flag if wc or wz is set.
Post Edited (Jasper_M) : 1/9/2007 11:18:35 AM GMT
Who knows if I'll ever figure out how the color carrier is generated on WAITVID for NTSC / PAL signals. [noparse]:)[/noparse]
I can fill you in a bit about the video stuff.
The prop does NTSC so amazingly simple!
I'm going to quit ranting and just let you explain it to me. [noparse]:D[/noparse]
Just think of a 1-bit serializer that is summed onto the lumi values.
sort of like this...
+1, +1, +1, +1, +0, +0, +0, +0, +1, +1.....
Which is added on top of a lumi-value ranging from 0 to 7.
Say the Lumi is 4.
Then with the serializer running on the output you will get.
4, 5, 4, 5, 4, 5..... and toggle between those values.
The speed at which this 1bit toggle (chroma modulation) is done, is set by one of the COG's accumulator counters.
If this toggle is done at 3.58Mhz. The TV will see this as a chroma signal.
The Prop has a 4bit phase control on this serializer. This is used to control the color phase.
Interesting note: If you chroma-modulation value 7 the output overflows and will go. 7, 0 ,7, 0. since adding (1) to a (7) in a 3bit word will overflow back to zero.
The porch timing and blanking layout is done all in software.
Hope that helps. ^^
--Andrew Arsenault
Post Edited (Ym2413a) : 1/9/2007 7:12:53 PM GMT
And don't forget chroma dithering as well! (with the aid of a fast dot clock)
I already got more then the normal number of colors out of my Prop doing this.
Some people have already or are working on video drivers that support more advanced colors and more colors per-area.
Thanks to how simple the video hardware really is, most of what you get comes down to what you can write in software.
Actually, it's modulated +-1 , not +0/+1 ... so if luma is 4, then after chroma, the output will be like 3,5,3,5... And setting luma to 111 causes it to go to SYNC levels (0) which is not good. However, setting it to zero will cause output like 7,1,7,1 ... Which doesn't go to sync range. And it's not a one-bit serializer - it outputs 3 bits at a time to the 3-bit DAC. And the clock that drives the serializer must be 16 times faster than the colorburst (the 3.5 something MHz signal) because since a phase is altered in 16 steps (chroma range is 0...15), it will need to change output data in the middle of one colorburst cycle with a precision of 16 times one colorburst cycle.
And yes, high color is possible up to 86 different colors (6 grayscales, 5 luminance values of 16 different chromas). The video hardware takes always in 4 different colors and n pixels of the colors. n is an integer between 1 and 32. Hydra comes with some hi-color engines.
From the sound of it. It sounds like the output of this serializer is summed onto the Lumi (3 bit) value.
I don't remember if it was +0, +1. or -1, +1.
But I think your right about it being -1, +1 the more I think about it. ^-^
Both would work about the same. (one would shift the lumi up half a bit and only be half as saturated)
Let me see if I can pull up that old post from many many months ago when we where talking about this.
The input Freq for the serializer is 57.28Mhz from the counter.
It then outputs 3.58Mhz.
Note: Oddly enough one of the video engines I looked at stores the value as twice that and halfs it later.
Post Edited (Ym2413a) : 1/9/2007 8:38:49 PM GMT
Actually I remember too seeing a post by someone who knows about what he talks about saying that...
I think a half of the value has to be stored to the counter because the frequency of overflows isn't going out of the counter, but rather the MSB of counter's accumulator - and it's frequency is twice the frequency of counter overflows. I'm not entirely sure about this (or maybe I misunderstood what you meant).
Interesting enough I have generated more then 86 colors from the prop with no extra external parts. *grins*
I've gotten 166 colors from my Prop by using dithering on the saturation. It helps to produce "muted" tones by turning on and off the Chroma signal at a speed where to TV see's it as half the amplitude. (Alternating Colored and Grayscale pixels really fast)
The output would look something like this if Lumi was set to 5.
On
Off
On
Off
6, 4, 6, 4, 5, 5, 5, 5, 6, 4, 6, 4, 5, 5, 5, 5.
To the Analog TV it see's the signal as if it was going.
5.5, 4.5, 5.5, 4.5, 5.5, 4.5.......
I like this a lot because even though the Propeller supports a lot of nice Hues! (4 bit)
and a nice 3 bit Lumi.
It only has a 1-bit Saturation control.
I find this the biggest limit in it's color output.
The 86 color palette lacks muted tones so everything is overly colorfull.
I'd like to see a video engine that supports a larger palette of colors to pull from then the 86 limit.
I might have to write it my self though in order to see it.
Check this out:
http://forums.parallax.com/showthread.php?p=617845
Post Edited (Ym2413a) : 1/10/2007 4:28:56 PM GMT
100% C#, and with a very good reason (other than cross platform-ed-ness). I'll release the details when It's further along.
Right now as it stands, before I release an alpha version
1) Finish the _____ interface / dialog
2) Finish the logic probe view (waveform view of the pin state in seconds)
3) Finish the interpreted mode on the emulator
4) fix the annoying redraw flicker after the windows are asked to update.
5) step by instruction (not by clock)
1 being a secret detail that I'm not going to tell anyone about until it's done. It's super cool though. It's basically finished, I just need to slap a GUI on it.
EDIT: Yes, it will be opensource eventually.
Post Edited (asterick) : 1/10/2007 7:42:24 PM GMT
Gear looks pretty darn cool! ^^