I was hoping this was going to work out...
Uses the cogless graphics to update in real time.
Because the area is so small it's very smooth.
I'm using the graphics bitmap area as the scratch pad and then copy over to the area set aside for this control when done.
Working out as well as I hoped...
There are all kinds of other graphical controls and indicators we can do this way.
Things like rotary knobs, analog dials, clock, etc...
Here is the source and binary for the latest version.
I now have the mouse updating with vsync so it shows more smoothly.
But, I have noticed with the "Cogless Graphics Demo" that if you don't poll the mouse continuously, you will lose update information and the mouse becomes sluggish.
I need to either use an interrupt and/or add constant polling to one of the cogs...
But, it's fine now as long as the main cog isn't being bogged down by something in idle processing...
How about the VGA palette? I used to think it was awful, but turns out that it actually quantizes very well and it has 16 grays. The alternative is the SNES palette, but it doesn't have any grays.
It'd be nice to have a palette with named colors, so you can use their names as constants in code.
But, this GUI isn't tied to a particular palette. Someone could use whichever they wanted...
Seems netscape palette is now called net-safe palette.
I'm trying to find a list of names for those colors, but haven't found it yet...
This one is actually pretty interesting... ~4000 characters...
Chip's vector font is a bit more advanced in that includes arcs whereas this is all just straight lines.
Still, the curves on large characters on that first link looked pretty smooth...
I added a vertical slider and also support for drawing Hershey font characters...
This section produces the characters in the green area next to the vertical slider in the pic below:
Form1Vector1 long 'Graphical Vector Font String using Hershey format
long 10 '0 type 10=Graphical Vector Font String
long 0 '1 top=y-offset from graphics origin
long 0 '2 left=x-offset from graphics origin
long 512 '3 width scale 256=1X
long 512 '4 height scale 256=1X
long 0 '5 data
long 1 '6 color number (0..3)
long 2 '7 width to draw with
long Form1Graphic1 '8 graphics area on which to draw
byte "16MWOMOV ROMSMUNUPSQ ROQSQURUUSVOV",13
byte "48F^RTTWVXXXZW[U[SZQXPVPSQ RSQUOVMVKUISHQHOINKNMOOQQ RQQNPLPJQISIUJWLXNXPWRT RRTQYP\ RRTSYT\ RP\T\",13
byte "11MXVNTMRMPNOPOSPURVTVVU",0
This font probably isn't particularly useful, but was fun to do!
It would be so neat to have the basis of a computer that we could hone over time, to keep it very efficient and clean. It could be the genesis of all kinds of projects.
If you can get keyboard, mouse, and file I/O working with that, we'll have a computer.
This display work by Rayman, is ahead of what is needed by this : http://www.projectoberon.com/home "Project Oberon is a design for a complete desktop computer system from scratch. Its simplicity and clarity enables a single person to know and implement the whole system, while still providing enough power to make it useful and usable in a production environment."
That is based on 1024 x 768 pixel, monocolor display frame, and includes fonts.
I hope that Peters P2D2 plus the companion boards will give a compact hardware base to have a unified solution. As a lot of hurdles are being set by small deviations, changing pin numbers etc. Unified hardware is a key feature for success. Any updates, Peter?
Considering the complexity of even a half-decent edit window - with copy and paste, undo/redo, autoindent, syntax highlighting, a gutter with line numbers and bookmarks and debugger breakpoints, etc., etc., I'm not sure an edit window can be said to fit in a "handful". There's a whole class of computer programs - i.e., text editors - that are nothing more than glorified text editor boxes.
I just figured out I can put all the form data in a separate file and then #include it in the main file like this:
DAT 'Form data include
#include "TestForms_5m.spin2"
What is interesting is the position of this #include in the main file matters.
If I put it before PUB Main, it compiles but gives a blank display.
If I put it just after PUB Main, it works as expected.
If I put it where that data used to be, I get errors because earlier code in main file can't resolve references to address names in the form data.
I had to add in the enumerated list of color names and also "rows" and "cols" for this to work.
But now, I can actually compile the form data independently to check for size.
I might try moving some of the specialized code for handling the forms over here too.
This might turn out to be very convenient going forward...
Comments
I was hoping this was going to work out...
Uses the cogless graphics to update in real time.
Because the area is so small it's very smooth.
I'm using the graphics bitmap area as the scratch pad and then copy over to the area set aside for this control when done.
Working out as well as I hoped...
There are all kinds of other graphical controls and indicators we can do this way.
Things like rotary knobs, analog dials, clock, etc...
Also, rounded button option.
Added a new test form that shows 3 sliders to pick a color and then shows best fit from palette.
BTW: I'm not sure I'm sold on this xterm palette...
There are too many light and not enough dark colors.
I may switch to this netscape palette and add some extra greys:
http://www.columbia.edu/itc/visualarts/r4110/f2000/week06/06_03_Color_palettes.pdf
That would be really neat to have a bare-bones GUI that could be configured for all kinds of custom apps.
Mouse and Keyboard in, screen out, and whatever you want to add for signal interfacing.
I now have the mouse updating with vsync so it shows more smoothly.
But, I have noticed with the "Cogless Graphics Demo" that if you don't poll the mouse continuously, you will lose update information and the mouse becomes sluggish.
I need to either use an interrupt and/or add constant polling to one of the cogs...
But, it's fine now as long as the main cog isn't being bogged down by something in idle processing...
https://www.fountainware.com/EXPL/vga_color_palettes.htm
It'd be nice to have a palette with named colors, so you can use their names as constants in code.
But, this GUI isn't tied to a particular palette. Someone could use whichever they wanted...
Seems netscape palette is now called net-safe palette.
I'm trying to find a list of names for those colors, but haven't found it yet...
https://www.htmlcsscolor.com/hex/FF6633
This might work to get names for new palette, but tedious...
Searching the web I found this project using the "Hershey" vector font:
https://www.element14.com/community/groups/open-source-hardware/blog/2017/12/31/experimenting-with-e-paper-displays-building-a-clock
Which led me to here:
http://paulbourke.net/dataformats/hershey/
This one is actually pretty interesting... ~4000 characters...
Chip's vector font is a bit more advanced in that includes arcs whereas this is all just straight lines.
Still, the curves on large characters on that first link looked pretty smooth...
You'd probably want to store them in flash or hyper-something...
But, certain subsets might be OK for COG RAM...
This section produces the characters in the green area next to the vertical slider in the pic below:
Form1Vector1 long 'Graphical Vector Font String using Hershey format long 10 '0 type 10=Graphical Vector Font String long 0 '1 top=y-offset from graphics origin long 0 '2 left=x-offset from graphics origin long 512 '3 width scale 256=1X long 512 '4 height scale 256=1X long 0 '5 data long 1 '6 color number (0..3) long 2 '7 width to draw with long Form1Graphic1 '8 graphics area on which to draw byte "16MWOMOV ROMSMUNUPSQ ROQSQURUUSVOV",13 byte "48F^RTTWVXXXZW[U[SZQXPVPSQ RSQUOVMVKUISHQHOINKNMOOQQ RQQNPLPJQISIUJWLXNXPWRT RRTQYP\ RRTSYT\ RP\T\",13 byte "11MXVNTMRMPNOPOSPURVTVVU",0This font probably isn't particularly useful, but was fun to do!
This display work by Rayman, is ahead of what is needed by this :
http://www.projectoberon.com/home
"Project Oberon is a design for a complete desktop computer system from scratch. Its simplicity and clarity enables a single person to know and implement the whole system, while still providing enough power to make it useful and usable in a production environment."
That is based on 1024 x 768 pixel, monocolor display frame, and includes fonts.
OK maybe some people like it, but what @Rayman is doing here is way more intuitive for GUI orientated persons.
This is very interesting, slowly all things come together, KBD/MOUSE/VGA and half of the P2 still usable.
Enjoy!
Mike
I may add option to draw current value in the middle.
Next, want to take on rotary dial.
Buttons
Switches
Radio Buttons (1 active at a time)
Slider Control
Scroll Bar
Edit Line
Edit Window
Bitmap
That's got to be over half of what's needed, at the lower level.
Numeric entry can be useful and not as difficult...
What is interesting is the position of this #include in the main file matters.
If I put it before PUB Main, it compiles but gives a blank display.
If I put it just after PUB Main, it works as expected.
If I put it where that data used to be, I get errors because earlier code in main file can't resolve references to address names in the form data.
I had to add in the enumerated list of color names and also "rows" and "cols" for this to work.
But now, I can actually compile the form data independently to check for size.
I might try moving some of the specialized code for handling the forms over here too.
This might turn out to be very convenient going forward...
I'll look ...