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

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

245

Comments

  • SeairthSeairth Posts: 2,474
    edited 2016-12-12 12:06
    Rayman wrote: »
    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
    

    Why not just
                    rdlong  gx1, ##@xmouse
                    rdlong  gy1, ##@ymouse
                    cmp     gx1, CursorX wz
            if_nz   jmp     #GEMove
                    cmp     gy1, CursorY wz
            if_nz   jmp     #GEMove
                    jmp     #GEDone
    GEMove          mov     CursorX, gx1
                    mov     CursorY, gy1
                    ' etc...
    

  • RaymanRayman Posts: 13,799
    That is a bit better, thanks.
  • ErNaErNa Posts: 1,738
    xor xold xnew
    xor yold ynew
    and xold yold
    add xold #1
    -> zero: were equal
  • RaymanRayman Posts: 13,799
    That looks very good. Don't need that "add xold #1" do we?
  • ErNa wrote: »
    xor xold xnew
    xor yold ynew
    and xold yold
    add xold #1
    -> zero: were equal

    Shouldn't the AND be an OR instead?

    or you could use ANYB like so
    		rdlong	gx1,##@xmouse
    		rdlong	gy1,##@ymouse
    		xor	gx1,CursorX
    		xor	gy1,CursorY
    		anyb	gx1,gy1 wz
    	if_z	jmp	#GEDone
    
    


  • RaymanRayman Posts: 13,799
    That looks really good. Thanks!
  • xor?

    Do you need a 32bit value for the old mouse coordinates?

    Put X in the upper word, Y in the lower word.

    Do the same for the CursorX/Y values.

    Then XOR OLD,NEW

    If it's non-zero, then it changed.
  • ErNaErNa Posts: 1,738
    ErNa wrote: »
    xor xold xnew
    xor yold ynew
    and xold yold
    add xold #1
    -> zero: were equal
    didn't realize, 1 xor 1 = 0 xor 0 = 0, so ok +1 is not needed.
    But combining two 16 bit values to one 32 bit value may take more computing time and even more code space, so the pros and cons have to be carefully weighted. My gut feeling is keeping the variables separated is the better solution

  • RaymanRayman Posts: 13,799
    pedward wrote: »
    Do you need a 32bit value for the old mouse coordinates?

    I'm still deciding on this... Right now, it feels like we have nearly infinite memory space, so I'm just doing everything as longs.

    If things get tight later, I might have to reconsider...

  • This should work too.
                  rdlong  gx1,##@xmouse
                  rdlong  gy1,##@ymouse
                  cmp     gx1,CursorX wz,wc
                  cmpx    gy1,CursorY wz,wc
            if_e  jmp     #GEDone
    

  • RaymanRayman Posts: 13,799
    Interesting...
    Is there a problem though if both x and y change by 1?
    Seems like won't work if gy1=CursorY+carry...
  • AribaAriba Posts: 2,682
    Another way..
                  rdlong    gx1,##@xmouse
                  rdlong    gy1,##@ymouse
                  cmp       gx1,CursorX  wz
            if_z  cmp       gy1,CursorY  wz
            if_z  jmp       #GEDone
    

    Andy
  • cgraceycgracey Posts: 14,133
    edited 2016-12-12 13:23
    Ariba wrote: »
    Another way..
    Hu
                  rdlong    gx1,##@xmouse
                  rdlong    gy1,##@ymouse
                  cmp       gx1,CursorX  wz
            if_z  cmp       gy1,CursorY  wz
            if_z  jmp       #GEDone
    

    Andy

    That looks very straightforward.
  • cgraceycgracey Posts: 14,133
    ozpropdev wrote: »
    This should work too.
                  rdlong  gx1,##@xmouse
                  rdlong  gy1,##@ymouse
                  cmp     gx1,CursorX wz,wc
                  cmpx    gy1,CursorY wz,wc
            if_e  jmp     #GEDone
    

    This uses Z-AND in CMPX, but does C have any use?
  • SeairthSeairth Posts: 2,474
    edited 2016-12-12 15:11
    Ariba wrote: »
    Another way..
                  rdlong    gx1,##@xmouse
                  rdlong    gy1,##@ymouse
                  cmp       gx1,CursorX  wz
            if_z  cmp       gy1,CursorY  wz
            if_z  jmp       #GEDone
    

    I like this the most, so far. It's still very clear what's being tested, but avoids the extra branches that my version had.
  • Rayman wrote: »
    Interesting...
    Is there a problem though if both x and y change by 1?
    Seems like won't work if gy1=CursorY+carry...
    A habit of mine is to always include "WC's" in CMP instructions.
    Remove them from my example and all is well. :)

  • RaymanRayman Posts: 13,799
    Guess I don't know what "Z-AND in CMPX" means...

    The docs just say:
    "Compare S with carry to D unsigned. If the wc is specified then the carry flag is set if there is an overflow"
  • cgraceycgracey Posts: 14,133
    edited 2016-12-12 23:58
    Rayman wrote: »
    Guess I don't know what "Z-AND in CMPX" means...

    The docs just say:
    "Compare S with carry to D unsigned. If the wc is specified then the carry flag is set if there is an overflow"

    All the add/sub/cmp instructions which end in the letter X do two special things which aid in >32-bit extended integer operations:

    1) They incorporate the C flag as input.
    2) Rather than set Z according to result=0, Z gets AND'd with result=0.
  • For CMPX, if the WZ effect is specified, the Z flag is set (1) if Z was previously set
    and Value1 equals Value2 + C (use WC and WZ on preceding CMP and CMPX instructions).
    If the WC effect is specified, the C flag is set (1) if Value1 is less than Value2
    (as multi-long values).

    This would mean you would need to ensure the C flag is cleared.
    		rdlong	gx1,##@xmouse
    		rdlong	gy1,##@ymouse
    		setcz	#0 wc
    		cmp	gx1,CursorX wz
    		cmpx	gy1,CursorY wz
    	if_e	jmp	#GEDone
    

    Therefore Ariba's solution is the way to go. :)
  • RaymanRayman Posts: 13,799
    edited 2016-12-15 17:23
    Making progress with the GUI...

    Made a better paint demo.
    This is bit of distraction from goal though...
    Need to add buttons next...

    PS: In case anybody actually tries it, the right mouse button clears the drawing area...

    PS2: I was thinking about connecting this to my new TV, but realized it doesn't have any VGA inputs... VGAs days may be numbered...
    1024 x 683 - 442K
  • RaymanRayman Posts: 13,799
    edited 2016-12-15 19:30
    TV with no VGA inputs just got me thinking about TFP410 DVI encoder and choice of palette...
    Only problem there is that it uses a lot more pins...

    This palette would need 24 pins for color (8 each for R, G, and Blue).

    But, the Windows 16 color palette only needs 6 pins (2 each for R, G, and Blue).

    Actually, I guess I'd need to figure out if I could use the streamer with 6 pins for color.
    That might be a trick. Maybe I could tell it to use 24-bit color but only enable 6 of 24 pins for output...
  • potatoheadpotatohead Posts: 10,253
    edited 2016-12-15 21:00
    TV with no VGA inputs just got me thinking about TFP410 DVI encoder and choice of palette...
    Only problem there is that it uses a lot more pins...

    That's part of why Chip put the color engine back in. We can do component, RGB, whatever.

    I've setup various displays, and have an older world standard broadcast monitor for SD now too. (all the PAL / NTSC variants)

    When I can get back to this, and understand how that color transform system works better, I intend to follow up on some formats. P2 has killer display support. And the landscape is fracturing some. An ideal setup is probably good analog support + an HDMI converter, with output tuned pixel perfect. It's gonna cover everybody and on almost all of those options, we get color management. One unified color space, drive what you got. The exception will be TTL displays, and nobody will care. Because TTL.

    Component should sing on most HDTV sets, and it's capable of things like running luma at full resolution, color at some other one too. HDMI 4K does this, luma at the 4K color stays at current 1080 --ish.

    One nice thing about it, lacking in VGA, is all the HDTV capable displays will continue to support a slow horizontal refresh, 15Khz. While this limits vertical resolution to under 500 pixels generally, it's a great 640, 720, 800 pixel x 400ish pixel display option. And it maps back to simple S-video / Composite for prototyping, capture, whatever.

  • Your GUI is awesome. Fun to see it coming together.
  • RaymanRayman Posts: 13,799
    edited 2016-12-16 00:23
    Fixed a couple bugs that prevented erasure of the edges...

    Ready to move on now.
  • Ray that is very cool stuff. Lot's of possibilities.
  • RaymanRayman Posts: 13,799
    Fixed another bug that let you draw on the edge.
    I think it's good now.

    BTW: My 4yo just tried it out. His first time with a mouse. Got it right away...
  • RaymanRayman Posts: 13,799
    Was kinda a Steve Jobs moment, but with a lot less drama
  • RaymanRayman Posts: 13,799
    Added support for different fonts.
    Also has variable pitch and wide font support
    1632 x 1224 - 1M
  • jmgjmg Posts: 15,140
    edited 2016-12-19 00:38
    Rayman wrote: »
    Added support for different fonts.
    Also has variable pitch and wide font support

    Very Impressive...

    I had a quick scan of Project Oberon docs, and I can find a 1024x768 display spec, but not much hard info on the fonts themselves...

    Some info here.. source code
    http://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Fonts.Mod.txt

    has comment
    (* raster sizes: Syntax8 1367, Syntax10 1628, Syntax12 1688, Syntax14 1843, Syntax14b 1983,
    Syntax16 2271, Syntax20 3034, Syntac24 4274, Syntax24b 4302 *)



    This link says Tools, Fonts & Libraries
    http://www.projectoberon.net/zip/apptools.zip

    and seems to have just 8 font files, with 8,10,12,16, and i & b suffix, guessing those are italic and Bold ?
    They are quite small, being 1986 to 2907 bytes in size. Maybe that 1367, 2271 above is the raster in bytes, before the record headers are added ? ( Diff of a similar 619 & 636 bytes )

    Missing from the list above look to be 14,20,24 sizes ?


    With the source code and the PDF
    http://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.System.pdf
    there might be enough info to be able to read (or convert) those font files ?

    Addit: google also finds this, a Mac port, dated Jul 31 2016
    https://itunes.apple.com/us/app/oberon-workstation/id1057155516?mt=12
  • Rayman wrote: »
    Was kinda a Steve Jobs moment, but with a lot less drama


    I'm moved by this, takes me back to Commodore and Atari, and being able to create graphics on screen. Great work, all of you!
Sign In or Register to comment.