The mouse still occasionally won't work. Just had to power cycle P123 to fix it though.
I think I may have done garryj's fix wrong... Think I decided that the wrlut should be after enabling LUT sharing and not before. Anyway, I've swapped the order to this:
setlut #LSHARE_WRITE ' Allow host cog to write this LUT
wrlut #D_READY, #D_EVENT ' Reset shared LUT eventID
Just remembered that I like to have hot key support.
Allows one to navigate with just keyboard...
See in picture how controls have a red highlighted character.
I think it's better to do it when ALT or CTRL is pushed, but wasn't immediately clear how to do that with garryj's USB code.
So, I'll probably just handle unconditional key presses for now:
That is great work Ray. Thinking in context to a real chip, about how much of the ram in 1 core would you be using with the graphics shown in that demo? Would you be up against the wall? Is it like the P1 graphics we use where you only have 1 core of ram to use for graphics?
In 480p and 4bpp, I'm feeling like there's all kind of space.
Think I'm at about 200kB now with the basic core nearly complete.
150kB of that is display buffer (?) Need to check my math...
Is USB+GUI only ~50kB? Guess so, it's basically just 5 cogs worth of code with some fonts and other data...
With 512kB expected, that leaves a ton of room for the actual application.
Later on, bmp resources could be on SD card and loaded to video buffer as needed.
Maybe I can try this on my new TV after all...
Just found these things with the TV manuals when cleaning up:
Even if new TVs stop having VGA, seems they support component.
Component and VGA give about the same quality anyway...
Yes, I just got two new 49" 4k monitors and they've each got 4 HDMI inputs and Y-Pb-Pr component inputs. These monitors can be gotten from Walmart for only $249 each. The viewing angle is 178°, which is nice. The only problem is that they have some internal sharpening algorithm that puts bright white pixels around dark lines (like text), making details harder to see.
Added Hot-Key options to buttons, checks and options.
One of the Alt buttons has to be down for it to work.
(I think this helps prevent accidental key presses).
Also added "indicators", for now just circles to look like LEDs.
This test changes the color of the indicator when top button pushed.
Also added "lines", just because I thought it could come in handy.
Optimized where I know how, but still only have ~20 longs left in main cog.
This what draws GUI elements.
Don't think it's critical for all GUI draws to be in cog, but think it's better.
A progress bar is one other thing I'd like to add before moving on...
This LED indicator just made me want to go back to Windows palette.
The red and green here don't work well as LEDs...
That show different ones that would use 9 pins for color.
maybe 9-pins is fine, but this way doesn't seem very efficient...
I suppose 9 pins is about 3 pins, or 8 levels, for each R, G, and B. Does that HDMI converter take in digital signals that for VGA would have gone to DACs?
It would probably be a lot of rewriting, but have you considered dropping the restrictive color palette and the huge display buffer and switching to on-the-fly scanline generation? You would only need to store two full-color scanlines in hubram: the one the streamer is currently displaying in the background, and the one after that, which the cog draws into while the streamer is outputting the other one. When the cog finishes generating a scanline, it waits for the streamer interrupt to fire. The streamer ISR then sets up the streamer to output the scanline that the cog just generated, and then the cog starts drawing the next scanline into the other scanline in hubram.
I'm confused. Shouldn't the converter only need three color pins?
There are chips that take analog in. Seems like using one of those preserves the nice color management in the chip as well as will allow for whatever palette / color options people choose in their display scheme.
That's a nice palette with an emphasis on color. Very clever choices in that one. At modest resolutions, the individual colors are all close to standard colors. Good saturation, easily seen.
At higher resolutions, it could be dithered to really look good.
It would probably be a lot of rewriting, but have you considered dropping the restrictive color palette and the huge display buffer and switching to on-the-fly scanline generation?
This is a good idea too. Especially for simple graphics like this.
This is how the EVE line from FTDI does it...
This could get us to 1080p!
Given a short lead, maybe ferrite bead, or shield, these things (analog to digital converters) can be pixel perfect.
RE: On the fly.
We have the throughput and number of COG free to make compositing graphics possible too. Chip added the pixel mixer for basic effects as well.
A combination of display buffer, sprite type graphics one can instance, all composited should give a lot of display capability with flexible RAM. Doing this was expensive on P1.
P2 could work with a high color scanning, or 16 bit color, whatever.
On each frame:
Sort sprite type assets for vertical position to determine fetch order, if they are in off chip storage.
Fetch the ones needed into on chip buffer, on the fly if warranted.
Read background low color display buffer.
Read asset scanline data.
Pixel mix to add it all into the scan line buffer.
Write to display.
Done this way, a ton of stuff can sit off chip, pulled in when needed, and the limit would move from colors to number of unique graphic instances on screen.
A 16 color buffer as background could also be done tile style, like the Parallax P1 driver, so that bitmaps could be where desired, with the palette desired.
Doing this would make great use of an HDTV display, and probably won't take more than a few COGS for most cases.
Could also run the dynamic display slower. Given it can handle X objects per frame, allow positioning at every other frame rate for in buffer objects, and object fetch could be Y unique, new things per every few frames.
That would teduce the load on the fetch and sort portion, possibly freeing cogs fo other things or keeping the display to a few COGS overall.
Users won't notice this much, if at all in most GUI scenarios, so long as the pointer runs full frame rate.
Early on, we talked about digital video, licensing and a lot of other requirements. P2 has robust analog out. We can drop a converter chip onto dev boards, and get common signals tuned right in.
Once that is done, people can choose analog or digital display. Provide a set of DACS for each, or a switch.
With that all nailed down, we have color managed display capability on just about everything from composite analog, up through whatever one can drive with DVI / HDMI. One color space for the whole works too.
The only oddball cases would be TTL displays, and those are expected to lack color management anyway.
In my P2 Invaders 2,0 I use "on the fly" video generation for the sprites and text. http://forums.parallax.com/discussion/165289/p2-invaders-2-0-their-back
I synchronize the scan line with the video driver using the "COGATN" feature.
It also makes use of the masked write long "WMLONG" instruction.
Works great!
In my P2 Invaders 2,0 I use "on the fly" video generation for the sprites and text. http://forums.parallax.com/discussion/165289/p2-invaders-2-0-their-back
I synchronize the scan line with the video driver using the "COGATN" feature.
It also makes use of the masked write long "WMLONG" instruction.
Works great!
I gotta circle back around to this. Thanks for the heads up!
Added "Primitive" object so can add lines, circles, rectangles, etc to form.
Added a progress bar
Added Idle processing. This test flashes an indicator and moves the progress bar.
Added vertical sync flag to help reduce flicker when updating objects.
Think it's time now to see if I can actually do something useful with this...
In writing Windows software, I found only two screen controls that I trusted: PushButton and ScrollBar. I drew everything else, myself, and tested for mouse/click positions. It made for a 10x snappier user interface than loading the window with slow, buggy, pre-built controls. So, less is sometimes more.
Uh-Oh... I'm actually a fan of MFC. Makes programming a lot easier, IMHO.
But, seems people are moving to C# because it's safer.
Anyway, for me the issue with any OS for what I have in mind here is that I want stuff to just work. Don't want to deal with settings or updates or drive problems... Just want to turn it on and have it work, all the time, every time...
No biggie. It's just a choice. I've experienced similar things in other environments. Code I wrote for a CAD system, applying a similar idea, still runs. Was written in the very early 90s. Almost nothing else from that Era, on that system, does.
Sometimes working with the baseline, or a useful subset has advantages.
Comments
I completely missed that, So C an Z flags are saved on any call and can be restored - if needed - to restore them by RET wc (and or) wz?
This is absolutely cool.
Enjoy!
Mike
Yes.
It let's you do neat things like..
The mouse still occasionally won't work. Just had to power cycle P123 to fix it though.
I think I may have done garryj's fix wrong... Think I decided that the wrlut should be after enabling LUT sharing and not before. Anyway, I've swapped the order to this:
Allows one to navigate with just keyboard...
See in picture how controls have a red highlighted character.
I think it's better to do it when ALT or CTRL is pushed, but wasn't immediately clear how to do that with garryj's USB code.
So, I'll probably just handle unconditional key presses for now:
Think I'm at about 200kB now with the basic core nearly complete.
150kB of that is display buffer (?) Need to check my math...
Is USB+GUI only ~50kB? Guess so, it's basically just 5 cogs worth of code with some fonts and other data...
With 512kB expected, that leaves a ton of room for the actual application.
Later on, bmp resources could be on SD card and loaded to video buffer as needed.
Just found these things with the TV manuals when cleaning up:
Even if new TVs stop having VGA, seems they support component.
Component and VGA give about the same quality anyway...
Yes, I just got two new 49" 4k monitors and they've each got 4 HDMI inputs and Y-Pb-Pr component inputs. These monitors can be gotten from Walmart for only $249 each. The viewing angle is 178°, which is nice. The only problem is that they have some internal sharpening algorithm that puts bright white pixels around dark lines (like text), making details harder to see.
One of the Alt buttons has to be down for it to work.
(I think this helps prevent accidental key presses).
Also added "indicators", for now just circles to look like LEDs.
This test changes the color of the indicator when top button pushed.
Also added "lines", just because I thought it could come in handy.
Optimized where I know how, but still only have ~20 longs left in main cog.
This what draws GUI elements.
Don't think it's critical for all GUI draws to be in cog, but think it's better.
A progress bar is one other thing I'd like to add before moving on...
This LED indicator just made me want to go back to Windows palette.
The red and green here don't work well as LEDs...
Thinking ahead to DVI converter chip and minimizing #color pins...
The VGA version of CGA colors only uses 6 pins for color.
But, I found this:
http://help.adobe.com/en_US/RoboHelp/Rword/7.0/mergedProjects/roboexpl/images-Word/windows_16_color_palette.htm
and this:
http://www.december.com/html/spec/color16.html
That show different ones that would use 9 pins for color.
maybe 9-pins is fine, but this way doesn't seem very efficient...
I suppose 9 pins is about 3 pins, or 8 levels, for each R, G, and B. Does that HDMI converter take in digital signals that for VGA would have gone to DACs?
There are chips that take analog in. Seems like using one of those preserves the nice color management in the chip as well as will allow for whatever palette / color options people choose in their display scheme.
That's a nice palette with an emphasis on color. Very clever choices in that one. At modest resolutions, the individual colors are all close to standard colors. Good saturation, easily seen.
At higher resolutions, it could be dithered to really look good.
Maybe I never looked for one of those...
Be interesting to see how the quality compares...
The TFP410 that I've used before takes up to 24 pins of color.
I think it can be used with the streamer.
This is a good idea too. Especially for simple graphics like this.
This is how the EVE line from FTDI does it...
This could get us to 1080p!
RE: On the fly.
We have the throughput and number of COG free to make compositing graphics possible too. Chip added the pixel mixer for basic effects as well.
A combination of display buffer, sprite type graphics one can instance, all composited should give a lot of display capability with flexible RAM. Doing this was expensive on P1.
P2 could work with a high color scanning, or 16 bit color, whatever.
On each frame:
Sort sprite type assets for vertical position to determine fetch order, if they are in off chip storage.
Fetch the ones needed into on chip buffer, on the fly if warranted.
Read background low color display buffer.
Read asset scanline data.
Pixel mix to add it all into the scan line buffer.
Write to display.
Done this way, a ton of stuff can sit off chip, pulled in when needed, and the limit would move from colors to number of unique graphic instances on screen.
A 16 color buffer as background could also be done tile style, like the Parallax P1 driver, so that bitmaps could be where desired, with the palette desired.
Doing this would make great use of an HDTV display, and probably won't take more than a few COGS for most cases.
Could also run the dynamic display slower. Given it can handle X objects per frame, allow positioning at every other frame rate for in buffer objects, and object fetch could be Y unique, new things per every few frames.
That would teduce the load on the fetch and sort portion, possibly freeing cogs fo other things or keeping the display to a few COGS overall.
Users won't notice this much, if at all in most GUI scenarios, so long as the pointer runs full frame rate.
Early on, we talked about digital video, licensing and a lot of other requirements. P2 has robust analog out. We can drop a converter chip onto dev boards, and get common signals tuned right in.
Once that is done, people can choose analog or digital display. Provide a set of DACS for each, or a switch.
With that all nailed down, we have color managed display capability on just about everything from composite analog, up through whatever one can drive with DVI / HDMI. One color space for the whole works too.
The only oddball cases would be TTL displays, and those are expected to lack color management anyway.
Then we say, drive what you got and mean it.
In my P2 Invaders 2,0 I use "on the fly" video generation for the sprites and text.
http://forums.parallax.com/discussion/165289/p2-invaders-2-0-their-back
I synchronize the scan line with the video driver using the "COGATN" feature.
It also makes use of the masked write long "WMLONG" instruction.
Works great!
Added a progress bar
Added Idle processing. This test flashes an indicator and moves the progress bar.
Added vertical sync flag to help reduce flicker when updating objects.
Think it's time now to see if I can actually do something useful with this...
Only touching a little of the MFC brings immunity to the many little annoyances found in updates, changes, hooks for new features, etc...
But, seems people are moving to C# because it's safer.
Anyway, for me the issue with any OS for what I have in mind here is that I want stuff to just work. Don't want to deal with settings or updates or drive problems... Just want to turn it on and have it work, all the time, every time...
Sometimes working with the baseline, or a useful subset has advantages.