Shop OBEX P1 Docs P2 Docs Learn Events
4-bit GUI (testing) Now with WS2812B RGB LED test example — Parallax Forums

4-bit GUI (testing) Now with WS2812B RGB LED test example

RaymanRayman Posts: 13,805
edited 2017-01-22 20:02 in Propeller 2
Here's a look at what a 4-bit GUI might look like... Uses Prop2 V13.

I think this font looks OK, but maybe I'll try others...

Driver code comes from Chip and Ozpropdev mostly, but some of the stuff is mine.

Supports 4 different resolutions (I think). Screenshot is SVGA (800x600)

Update: Now supports usb mouse with cursor and drawing, see posts later on below.
Update2: Now has a mostly working paint demo
Update3: GuiTest#6 now has the basic GUI elements needed for simple application including variable fonts, buttons, check boxes, option buttons and group boxes.
Update4: GuiTest#8 hopefully has everything needed for basic app. Switched palette to named colors in HTML3.2

«1345

Comments

  • RaymanRayman Posts: 13,805
    VGA (640x480) looks better, at least on this other monitor...
    1632 x 1224 - 446K
  • For those looking at writing a GUI (OS?) for the P2, you may want to check out these two projects for idea's/inspiration/documentation.

    SymbOS
    -Is a full multi-tasking OS (Z80) with networking and windowed GUI
    -Runs on Amstrad CPC and MSX
    -Very low memory requirements (as little as 128k)
    -extensive documentation (some stuff may be in German)
    -still actively being developed
    http://www.symbos.de/

    GOS for Atari 8bit
    -a full multi-tasking OS (6502) with a windowed GUI
    -inspired by SymbOS
    -Uses many of the techniques used by SymbOS to run fast and small
    -Active development
    http://atari8.co.uk/gui/

    If something like either of these can be built on the P2 then we will have something profoundly new !!
    -Modern hardware (Yes, it is a microcontroller but it is modern ;-)
    -A functional OS and GUI that is NOT Linux
    -A tiny, complete system that maker's can learn quickly !!

    Maybe this should be called Nano Computing ;-)
  • cgraceycgracey Posts: 14,133
    Looks good, Rayman. That reminds me of our old FIB machine.
  • RaymanRayman Posts: 13,805
    Thanks. I'm not sure I'm happy with the Windows 16-color palette...

    That SymbOS screenshots with shades of lime or shades of orange looks interesting...
  • Looks great Rayman! :)
    BTW I had to cut/paste ProgoCoFont.txt into ypur code as there is no ProgoCo.dat file in the zip file.
  • RaymanRayman Posts: 13,805
    edited 2016-11-17 00:44
    Sorry about that... I'll fix it now...

    Ok, I think it now includes the .dat file
  • RaymanRayman Posts: 13,805
    Just need to add in garryj's USB code and eric's spin2cpp of float to string and I'll be all set.
  • rjo__rjo__ Posts: 2,114
    no... then you'll need to add support for 8,16 and 24 bit.

    just kidding:)
  • RaymanRayman Posts: 13,805
    I think I like this palette, have to give it a try:
    https://androidarts.com/palette/16pal.htm

    Have to change the names though...
  • I was gonna suggest that one. The C64 / VIC color set is pretty nice.

  • RaymanRayman Posts: 13,805
    It's basically 3 shades of gray (including white and black), 4 shades of red, 4 shades of blue, 3 shades of green, with yellow and orange thrown in.
  • RaymanRayman Posts: 13,805
    I added some 1024x768 modes. For some reason, regular XGA doesn't sync right.
    Also, it looks like the higher the dot clock, the better it looks.
    Maybe can go 113 MHz with real chip and do even better.

    Also added that other palette to see how it looks...
  • RaymanRayman Posts: 13,805
    Looks like my test monitors just can't auto adjust with a very dark background.
    Changed from nightblue to white and now all the 1024x768 modes work.
  • RaymanRayman Posts: 13,805
    Anybody know the speed difference between a rep loop with wrbyte and one with wrlong?

    My fill rectangle routine is using wrbyte for now, but wondering if paying a price for that simplicity...
  • jmgjmg Posts: 15,140
    Rayman wrote: »
    Looks like my test monitors just can't auto adjust with a very dark background.
    Changed from nightblue to white and now all the 1024x768 modes work.
    Yes, I've found that modern Monitors expect a windows type raster, and black backgrounds at the borders confuse the smart auto-locking and phase adjusting they do.
    They are quite smart, once you give them a signal they can work with, but it does make 'small steps' testing harder.
  • RaymanRayman Posts: 13,805
    This version can paint 4-bit bitmaps. Also, now does filled and hollow circles.
  • RaymanRayman Posts: 13,805
    edited 2016-11-20 22:36
    What it looks like in VGA mode...
    Think this palette is going to work OK.

    Another option would be to use the palette the MS Paint uses to make it simpler to create BMP resources...
    1632 x 1224 - 478K
  • potatoheadpotatohead Posts: 10,253
    edited 2016-11-21 00:02
    If you supply a template file, the colors will be present in paint. Just make one with swatches, and it's not a big deal.

    Or turn people onto paint.net. I had missed that one, and now I use it constantly.

  • RaymanRayman Posts: 13,805
    I just dropped in the garryj's USB host code into this GUI test and it runs!

    Only had to move cogs from 0&1 to 6&7 (because VGA needs to be on cog 0).

    It's amazing that there was not a single variable overlap.
  • Woo-hoo!
  • !!! Nice.

    How are you guys interfacing USB?
  • Unless rayman has already started one, a real interface has yet to be implemented. The current USB keyboard/mouse demo just dumps the output to serial out as the data arrives.
  • RaymanRayman Posts: 13,805
    I think Garryj has us 99% of the way there...

    Think I just need to do some integration and limiting to get x and y position values ...
  • RaymanRayman Posts: 13,805
    This version has a cursor that is moved by USB mouse.

    You can even paint black by pushing left button and white with right button.

    I should synchronize draws with vertical refresh, but think this is OK for now...
  • jmgjmg Posts: 15,140
    Rayman wrote: »
    This version has a cursor that is moved by USB mouse.

    You can even paint black by pushing left button and white with right button.

    Good progress !
    Can you modify the heading to include USB, and post a moving progress summary in the first post ?

    eg I think the tested is

    VGA (640x480)
    1024x768
    FS USB Mouse -> Pixel X.Y.Toggle
    Needs how many COGS ( c0+c6+c7) ?
  • RaymanRayman Posts: 13,805
    Edited top post.

    Close to having both keyboard and mouse at same time with two instances of USB.

    But, only the last thing plugged in works now.
    I think it's all the hub variables at the very end of the USB code.
    That might be a problem, have to figure out how to deal with that...
  • Rayman wrote: »
    I think it's all the hub variables at the very end of the USB code.
    Yeah, the keyboard and mouse structures are owned by the HID driver, but all of the USB data structures are shared by host and driver.

    Phase two was to get the host multi-instance friendly, but I haven't had a chance to get to it yet...
  • Close to having both keyboard and mouse at same time with two instances of USB.
    Ran your GUI with mouse support -- so cool!

    Do you have a 2.4GHz wireless keyboard/mouse combo? If both support the boot protocol, the demo should do both at the same time with a single host. I have a Microsoft Wireless 5000 combo and this one I got for $20 from WalMart that I use for testing:
    Onn Wireless Keyboard and Mouse

    Both use a full-speed dongle, and the mouse works in the GUI with the mouse & keyboard output going to the serial terminal.

    Great work!
  • RaymanRayman Posts: 13,805
    Thanks, the wireless thing sounds like a great backup plan.
    Maybe I'll just live with mouse only for now.
    Or, I can unplug mouse and plug in keyboard, if needed.
    Good enough for now...


  • RaymanRayman Posts: 13,805
    edited 2016-12-09 16:48
    Found a bug in my cursor code... Had to add "ABS" statements to make it work for the case of x and y movements being equal.

    But now, the code looks inefficient. There must be a better way to compare x and y with old values and see if either one has changed?
    rdlong    gx1,##@xmouse
                  rdlong    gy1,##@ymouse
                  sub       gx1,CursorX
                  abs       gx1,gx1
                  sub       gy1,CursorY
                  abs       gy1,gy1
                  add       gx1,gy1
                  cmp       gx1,#0 wz,wc
            if_z  jmp       #GEDone
    
Sign In or Register to comment.