Emulated proper prefetch behavior in native cogs (occurs before result of current instruction is executed)
Change interpreted cog boot behavior to accommodate 'appropriate' PAR behavior (14 bit constant, not 32 bit value loaded from 14bit PAR address)
Proper emulation of unaligned reads / writes of words / longs
Awesome!
This is great since I can play around with the Prop at work when I don't have my demoboard with me! (lol)
Glad to see that the PAR is now emulated correctly. Odd how it's 14bit isn't it?
That's what I though at first until I studied the chip a little bit more and found out why.
Ym2413a said...
Awesome!
This is great since I can play around with the Prop at work when I don't have my demoboard with me! (lol)
Glad to see that the PAR is now emulated correctly. Odd how it's 14bit isn't it?
That's what I though at first until I studied the chip a little bit more and found out why.
Yea, I just assumed that the COG would auto load 32 bits from that address, but I like this way better. More flexable. [noparse]:)[/noparse]
Oh, and just something that I'm working on is attached.
EDIT: I didn't want to bump the topic, but here is what the current revision of the television plugin looks like
The color phase decoding is god awful, and extremely sensitive. I'm mildly underwhelmed by it. [noparse]:D[/noparse] It's really not as impressive as you might think, and it depends on a square wave worth of video in order to properly operate, the syncing is also pretty hackish. So far, here is how it works:
Gray level is the output from a low-pass RC filter (which is probably how real televisions work)
The saturation level sensor is similar to the "peak" setup you would see on your equalizer. It has a decay rate and if the voltage is ever out of range of the current sat window, it updates it accordingly.
Chroma, on the other hand, is nasty. It waits for a rapid change in the voltage. If it sees a rapid change, it either a) latches that time (if it's in a burst period in hblank signal) or b) it compares the current time against the latched time, divides that time (seconds) by the color frequency... subtracts the floor and uses that as the hue (0 - 1.0).
There is some color offsetting too (since 0deg isn't red in NTSC) You can see the color burst in the hblank field on the left side of the plugin.
I've been desperately trying to find a function that properly rounds a square wave of predefined frequency into a good approximation of a sinus wave. I may try a comb filter, but I'm not 100% sure.
I changed a lot of the code in the television plugin. the picture is SIGNIFICANTLY clearer now.
I'll work on making the sync detection code better (IE: detect the interlace fields, rather that just toggling it)
All I gots to say is who says NTSC has to be ugly. [noparse]:D[/noparse]
Step 1) Lowpass & Lumi
Store x number of samples in an array. Say... 32 samples big.
For every sample entered into the array (On update) remove the oldest sample.
Take the average of those samples... (Low-Pass)
The output of that is your LUMI. (easy enough)
Step 2) Highpass
Do a highpass to get the Saturation and Hue...
Take current sample from DAC and subtract the LUMI value found in the last process. (The difference will be the high frequancy singals) (High-Pass)
This should range from +1 to -1. (with the current graphics engines) -n to +n
Step 3) Saturation
Clip negitive values of the Highpass output. So values only range half of output (0 to +n).
If saturation = 0 (No color)
If saturation = 1 (Color)
Another average based lowpass would help with this a little bit. So you wont get as much dot-clawling.
We cliped half the signal so the numbers don't cancel out when we average them.
Step 4) Hue.
Take the output of the simple Highpass Filter.
Store it into an array X samples big.
Subtract it from another array that has the samples stored from the Color Burst.
Take the average of the difference and that is your HUE!!!
Tada! I havn't tested this yet just to warn you. (lol)
Anyway sorry because I know it's much easier said then done.
All I gots to say is who says NTSC has to be ugly. [noparse]:D[/noparse]
Well it looks like whatever your doing for decoding seems to be working pretty darn well based on that photo. ^^
Goes to show you how much more complex NTSC is compared to say... VGA's RGB.
All I gots to say is who says NTSC has to be ugly. [noparse]:D[/noparse]
Well it looks like whatever your doing for decoding seems to be working pretty darn well based on that photo. ^^
Goes to show you how much more complex NTSC is compared to say... VGA's RGB.
Well, the fact that they got any color at all is impressive, considering the state of electronics in the early 50s.
All I gots to say is who says NTSC has to be ugly. [noparse]:D[/noparse]
Well it looks like whatever your doing for decoding seems to be working pretty darn well based on that photo. ^^
Goes to show you how much more complex NTSC is compared to say... VGA's RGB.
My new method isn't actually that much different than my old one, it's kinda an amalgamation of what you suggested and what I was doing before.
Essentially, it samples at a rate of 1/16th of NTSC color burst. It logs the last 9 samples (gives you slightly larger than one half of a colorburst wavelength) I use those samples to determine the minimum / maximum of the signal.
I essentially use the same method for determining the color phase shift as before, it looks for any significant rise in voltage across the signal, and uses that as the comparitor for phase shift. This comparison is done with an abstract rate (any time a change is seen, it checks to see if the voltage increased)
This gives a VERY sharp picture, as I'm sure you saw in the screencap. The only problem is it will break if it's fed a sinus waveform.
I could adjust it by making the minimum / maximum log be 16 samples (since that would give a full burst frequency). All that does is results in more color bleed (since the saturation/lumi to stablize when the baseline changes), it would also cause some rainbowing on the color burst (since it will cascade through the color palette on the rising edge of the color carrier)
I don't know what it would do with your modified half/sat code, but chances are it would make it look stripey.
A good question is how does the TV object handle the (Illegal Saturation) values the Propeller generates stock?
There are 16 values that generate a output of 1,7,1,7... on the DAC. They display on the Television, but shouldn't be used since they are very over saturated! Try 120IRE peak to peak.
Color Bars which have some of the most vivid colors NTSC can generate only modulations up to about 80 IRE max.
Over saturated colors can be displayed by setting the Lumi value to 0, and turing on Chroma Modulation.
They are also 180 degrees out of phase from the normal colors.
My study of them has shown that they tend to blend together and the HUEs between neighboring values are no longer linear. (In other words the resolution of the HUE decreases quite a bit)
My plugin doesn't care about the range, those oversaturated colors get rather grainular, but they render (and are eye cutting sharp) I have a color bars generator so I could test hue code against the TV I have sitting next to my desk.
Wow! I just tried this out... VERY nice! I can't wait for the TV plugin... stepping through a TV app should help me understand the TV driver better so I can work on modifying it for my needs.
I've started using Gear to debug the assembly language version of my ads7822p adc driver, and it already helped me squash a bug!
Very nice work asterik
A couple of suggestions, if you don't mind...
when the simulation is stopped on the 'logic probe' pane, it would be VERY useful if we could "zoom in" on the grid and see finer grained divisions... ie I'd love to be able to see 12.5ns divisions showing the pin activity, and be able to scroll around in the currently captured buffer
also being able to click on two places on the zoomed or normal plot and showing the elapsed time between the two points would be useful as well
Back to debugging...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ www.mikronauts.com - a new blog about microcontrollers
Bill Henning said...
I've started using Gear to debug the assembly language version of my ads7822p adc driver, and it already helped me squash a bug!
Very nice work asterik
A couple of suggestions, if you don't mind...
when the simulation is stopped on the 'logic probe' pane, it would be VERY useful if we could "zoom in" on the grid and see finer grained divisions... ie I'd love to be able to see 12.5ns divisions showing the pin activity, and be able to scroll around in the currently captured buffer
also being able to click on two places on the zoomed or normal plot and showing the elapsed time between the two points would be useful as well
Back to debugging...
I've been wanting to improve the robustness of just about all the GUI elements of the emulator, right now priority is on squashing all those annoying little execution bugs that remain. I think I've got most of them narrowed down to spin execution.
ULTIMATELY, I would like to see the interpreted cog step view show a source code style view (waiting on a tab file or something similar from the parallax cats), the logic view needs better zoom control and obviously a little mouse probe so you can click at a point, and see what time slice you are at, and what level it is (with optional snapping to wave edges), mouse controlled zooming, etc.the spin memory viewer could use some work, but it's pretty much everything I can extrapolate except for the opcode highlighting (which requires a LOT more processing than one would expect), etc etc. Eventually I will get around to all this.
Currently, however, a couple of other projects that I've been neglecting have are starting to rear their ugly heads. I had a multiplayer flash game go live about a week ago that unfortunately wasn't quit ready for the mainstream (the server was slightly less than stable)... and at work feature creep kit one of my applications thanks to my boss.
Once I have free time again, I'll start fine tuning things.
I'm working on assembly language stuff now. This is a huge help as I've got small bits of time to work in and am not always able to setup a prop and display. Thank you for developing this as far as you have.
This stuff looks great. Unfortunately, I haven't the foggiest on how to start. Would have any instructions anywhere laying around or recomend some test code?
Thanks,
Greg
I open a spin file in the Propeller tool, hit F8, choose "Save Binary File" then open the binary file in Gear. If you need to use a plug-in such as tv output you would then click "Open Plugin" and choose the desired plug-in, in this case Television. To see the output choose the "Television" tab then click on Run.
One question: how do I simulate a button press and LED output (I guess the LED output could be seen by viewing the pin state?)
Keep up the good work asterick (No, not your day job - GEAR!)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
BTW: I type as I'm thinking, so please don't take any offense at my writing style www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
Comments
Emulated proper prefetch behavior in native cogs (occurs before result of current instruction is executed)
Change interpreted cog boot behavior to accommodate 'appropriate' PAR behavior (14 bit constant, not 32 bit value loaded from 14bit PAR address)
Proper emulation of unaligned reads / writes of words / longs
This is great since I can play around with the Prop at work when I don't have my demoboard with me! (lol)
Glad to see that the PAR is now emulated correctly. Odd how it's 14bit isn't it?
That's what I though at first until I studied the chip a little bit more and found out why.
Yea, I just assumed that the COG would auto load 32 bits from that address, but I like this way better. More flexable. [noparse]:)[/noparse]
Oh, and just something that I'm working on is attached.
EDIT: I didn't want to bump the topic, but here is what the current revision of the television plugin looks like
Post Edited (asterick) : 2/7/2007 9:05:49 PM GMT
I was wondering if you where going to make a NTSC plugin.
This is GREAT!!.
I'm impressed with the fact you wrote color phase decoding into it as well.
--Andrew Arsenault.
Gray level is the output from a low-pass RC filter (which is probably how real televisions work)
The saturation level sensor is similar to the "peak" setup you would see on your equalizer. It has a decay rate and if the voltage is ever out of range of the current sat window, it updates it accordingly.
Chroma, on the other hand, is nasty. It waits for a rapid change in the voltage. If it sees a rapid change, it either a) latches that time (if it's in a burst period in hblank signal) or b) it compares the current time against the latched time, divides that time (seconds) by the color frequency... subtracts the floor and uses that as the hue (0 - 1.0).
There is some color offsetting too (since 0deg isn't red in NTSC) You can see the color burst in the hblank field on the left side of the plugin.
I've been desperately trying to find a function that properly rounds a square wave of predefined frequency into a good approximation of a sinus wave. I may try a comb filter, but I'm not 100% sure.
I'll work on making the sync detection code better (IE: detect the interlace fields, rather that just toggling it)
All I gots to say is who says NTSC has to be ugly. [noparse]:D[/noparse]
Step 1) Lowpass & Lumi
Store x number of samples in an array. Say... 32 samples big.
For every sample entered into the array (On update) remove the oldest sample.
Take the average of those samples... (Low-Pass)
The output of that is your LUMI. (easy enough)
Step 2) Highpass
Do a highpass to get the Saturation and Hue...
Take current sample from DAC and subtract the LUMI value found in the last process. (The difference will be the high frequancy singals) (High-Pass)
This should range from +1 to -1. (with the current graphics engines) -n to +n
Step 3) Saturation
Clip negitive values of the Highpass output. So values only range half of output (0 to +n).
If(Highpass > 0){
Saturation == Highpass;
} else {
Saturation == 0;
}
If saturation = 0 (No color)
If saturation = 1 (Color)
Another average based lowpass would help with this a little bit. So you wont get as much dot-clawling.
We cliped half the signal so the numbers don't cancel out when we average them.
Step 4) Hue.
Take the output of the simple Highpass Filter.
Store it into an array X samples big.
Subtract it from another array that has the samples stored from the Color Burst.
Take the average of the difference and that is your HUE!!!
Tada! I havn't tested this yet just to warn you. (lol)
Anyway sorry because I know it's much easier said then done.
Well it looks like whatever your doing for decoding seems to be working pretty darn well based on that photo. ^^
Goes to show you how much more complex NTSC is compared to say... VGA's RGB.
My new method isn't actually that much different than my old one, it's kinda an amalgamation of what you suggested and what I was doing before.
Essentially, it samples at a rate of 1/16th of NTSC color burst. It logs the last 9 samples (gives you slightly larger than one half of a colorburst wavelength) I use those samples to determine the minimum / maximum of the signal.
I essentially use the same method for determining the color phase shift as before, it looks for any significant rise in voltage across the signal, and uses that as the comparitor for phase shift. This comparison is done with an abstract rate (any time a change is seen, it checks to see if the voltage increased)
This gives a VERY sharp picture, as I'm sure you saw in the screencap. The only problem is it will break if it's fed a sinus waveform.
I could adjust it by making the minimum / maximum log be 16 samples (since that would give a full burst frequency). All that does is results in more color bleed (since the saturation/lumi to stablize when the baseline changes), it would also cause some rainbowing on the color burst (since it will cascade through the color palette on the rising edge of the color carrier)
I don't know what it would do with your modified half/sat code, but chances are it would make it look stripey.
There are 16 values that generate a output of 1,7,1,7... on the DAC. They display on the Television, but shouldn't be used since they are very over saturated! Try 120IRE peak to peak.
Color Bars which have some of the most vivid colors NTSC can generate only modulations up to about 80 IRE max.
Over saturated colors can be displayed by setting the Lumi value to 0, and turing on Chroma Modulation.
They are also 180 degrees out of phase from the normal colors.
My study of them has shown that they tend to blend together and the HUEs between neighboring values are no longer linear. (In other words the resolution of the HUE decreases quite a bit)
--Andrew Arsenault.
Pat
Miscellaneous bug fixes
Television plugin
Exceptional work .... love it ...
QuattroRS4
I forgot to put it in the release folder... I'll update the release. Thanks for the tip. [noparse]:D[/noparse]
Pat
Very nice work asterik
A couple of suggestions, if you don't mind...
when the simulation is stopped on the 'logic probe' pane, it would be VERY useful if we could "zoom in" on the grid and see finer grained divisions... ie I'd love to be able to see 12.5ns divisions showing the pin activity, and be able to scroll around in the currently captured buffer
also being able to click on two places on the zoomed or normal plot and showing the elapsed time between the two points would be useful as well
Back to debugging...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
I've been wanting to improve the robustness of just about all the GUI elements of the emulator, right now priority is on squashing all those annoying little execution bugs that remain. I think I've got most of them narrowed down to spin execution.
ULTIMATELY, I would like to see the interpreted cog step view show a source code style view (waiting on a tab file or something similar from the parallax cats), the logic view needs better zoom control and obviously a little mouse probe so you can click at a point, and see what time slice you are at, and what level it is (with optional snapping to wave edges), mouse controlled zooming, etc.the spin memory viewer could use some work, but it's pretty much everything I can extrapolate except for the opcode highlighting (which requires a LOT more processing than one would expect), etc etc. Eventually I will get around to all this.
Currently, however, a couple of other projects that I've been neglecting have are starting to rear their ugly heads. I had a multiplayer flash game go live about a week ago that unfortunately wasn't quit ready for the mainstream (the server was slightly less than stable)... and at work feature creep kit one of my applications thanks to my boss.
Once I have free time again, I'll start fine tuning things.
*.*
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*.*
Ibsen
" It's nice to be important, but
·· more important to be nice... "
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Excellent work!
I'm working on assembly language stuff now. This is a huge help as I've got small bits of time to work in and am not always able to setup a prop and display. Thank you for developing this as far as you have.
Thanks,
Greg
This is great software!
One question: how do I simulate a button press and LED output (I guess the LED output could be seen by viewing the pin state?)
Keep up the good work asterick (No, not your day job - GEAR!)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
BTW: I type as I'm thinking, so please don't take any offense at my writing style
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
Well, the easiest way would be to write LED and button plugins.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
BTW: I type as I'm thinking, so please don't take any offense at my writing style
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)