Shop OBEX P1 Docs P2 Docs Learn Events
TACHYON O/S V3.0 JUNO - Furiously Fast Forth, FAT32+LAN+VGA+RS485+OBEX ROMS+FP+LMM+++ - Page 106 — Parallax Forums

TACHYON O/S V3.0 JUNO - Furiously Fast Forth, FAT32+LAN+VGA+RS485+OBEX ROMS+FP+LMM+++

1103104106108109

Comments

  • @Peter,

    after your midwifery (is that correct english?) LameStation graphics things come into motion. The following code iterates a linear byte buffer lcdmem and gives it out to the display. Currently without any convolution.
    pub LCDBITBLT ( -- ) --- transfer lcdmem to LCD Display
        \ transfer buffer to LCD
        -1 ctr_pages_last !
        -1 ctr_halves_last !
        0 lcdmemlen ADO
            \ iterate all bytes in lcdmem
            I 64 / ctr_halves !  \ counter for 64 Packets
            I 128 / ctr_pages ! \ counter for pages
            I 0 = IF
              \ ." first loop" CR
              LCDBOTH
              lcdon LCDCMD
            THEN
            ctr_pages @ ctr_pages_last @ <> IF
                \ new page
                \ ." new page " ctr_pages @ . ." _" I . CR
                lcdsetpage ctr_pages @ + LCDCMD --- iterate 'page's
           THEN
            ctr_halves @ ctr_halves_last @ <> IF
                \ ." new half " ctr_halves @ . ." _" I . CR
                ctr_halves @ EVEN? IF
                  LCDBOTH
                  lcdsetadr LCDCMD --- go left
                ELSE
                  LCDBOTH
                  lcdsetadr LCDCMD --- go left
                THEN
            THEN
            lcdmem I + C@ LCDDAT
            ctr_pages @ ctr_pages_last !
            ctr_halves @ ctr_halves_last !
        LOOP
        ;
    

    This is quite slow versus simple deleting but I don't care yet and will look for better performance later.
    LAP LCDBITBLT LAP .LAP 137.673ms ok
    LAP LCDCLS LAP .LAP 11.243ms ok
    

    The next step will be stuffing the bits together according to the screen buffer organized like this:
       0 1 2 3 4 5 ... 125 126 127
      +--------------------------------+
     0|                                |
     1|                                |
     2|                                |
      .                                .
      .                                .
      .                                .
    62|                                |
    63+--------------------------------+
    
    Maybe I can do this tomorrow "convolution day". After that drawing to the buffer has to be done. I will dive into VGA.FTH to see wether I can copy from there to draw to the buffer.

    regards,
    proplem
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-02-14 00:20
    @proplem - sounds good that you are getting it working.

    There are some strange things in your code though. You test for first time through the loop with I 0= IF when it makes more sense to place the init "LCDBOTH lcdon LCDCMD" before the loop without any need for a test which btw is happening every iteration and helping slow it down. You can also make your code faster by using shifts instead of divides if it is a binary multiple, so 5 >> instead of 64 / and 7 >> instead of 128 /, much much faster. That is why there 2/ (and 2*) words since these are actually shift right and shift left but they take a fraction of a microsecond to execute.

    The "ctr_halves @ EVEN?" ends up doing the same thing for both conditions?. Also, you could probably simplify the whole variables as flags thing too by simply leaving values on the stack since there are only two of them, so you end up using DUP or OVER or 3RD etc to "fetch" the variable. But even all that could be simplified too. No matter though, the important thing is to do what you have done, to get it working!

    EDIT: Here is a simplification of your code, still as your code, but mainly removing variables etc. This same code can be further reduced as you might see.
    pub LCDBITBLT ( -- ) --- transfer lcdmem to LCD Display
        \ transfer buffer to LCD
        -1 -1  ( oldpage oldhalf )  ( replaces -1 ctr_pages_last ! -1 ctr_halves_last ! )
        LCDBOTH  lcdon LCDCMD
        0 lcdmemlen ADO
            \ iterate all bytes in lcdmem (calculate as needed rather than using variables)
            OVER ( oldpage ) I 7 >> <> IF
                \ new page
                \ ." new page " ctr_pages @ . ." _" I . CR
                lcdsetpage I 7 >> + LCDCMD --- iterate 'page's
           THEN
            DUP ( oldhalf ) I 5 >> <> IF
                \ ." new half " ctr_halves @ . ." _" I . CR
                I 5 >> EVEN? IF  ( ???? no difference )
                  LCDBOTH lcdsetadr LCDCMD --- go left
                ELSE
                  LCDBOTH lcdsetadr LCDCMD --- go left
                THEN
            THEN
            lcdmem I + C@ LCDDAT
    	--- update "old" page and half stack variables
            2DROP I 7 >> I 5 >>  ( oldpage oldhalf )
        LOOP
        2DROP --- discard oldpage and oldhalf
        ;
    
  • After sorting out some bugs I changed the LCDBITBLT word according to Peter's recommendation of using stack operations instead of variables. This was a lot faster about 100 ms now about 50 ms.
    pub LCDBITBLT ( -- ) --- start from upper left corner and move down to bottom right and set ch
        \ transfer buffer to LCD
        LCDBOTH lcdon LCDCMD
        -1 -1  ( oldpage oldhalf )
        0 lcdmemlen ADO
          \ iterate all bytes in lcdmem (calculate as needed rather than using variables)
          OVER ( oldpage ) I 7 >> <> IF
               \ new page
               \ ." new page " ctr_pages @ . ." _" I . CR
               LCDBOTH
               lcdsetpage I 7 >> + LCDCMD --- iterate 'page's
          THEN
          DUP ( oldhalf ) I 6 >> <> IF
              \ ." new half " ctr_halves @ . ." _" I . CR
              I 6 >> EVEN? IF
                LCDA
              ELSE
                LCDB
              THEN
              lcdsetadr LCDCMD --- go left
          THEN
          lcdmem I + C@ LCDDAT
    \      2DUP *BTNA HIGH? IF ." I=" I . ."  h=" . ."  p=" . CR 100 ms THEN
          --- update "old" page and half stack variables
          2DROP I 7 >> I 6 >>  ( oldpage oldhalf )
        LOOP
        2DROP --- discard oldpage and oldhalf
        ;
    

    The code is faster but for me less understandable. I think I will revert to my first version using variables. This is a bit slower but I can better extend it. If I will need the speed, I will optimize and refactor later.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-02-15 23:39
    @proplem - I see the problem, it's thinking in German and writing in English! (then trying to translate it back to German when you read it)

    When Luke Skywalker used the Force he had to let go of his "aids", flipping the targeting computer out of the way. While useful, it can get in the way. Same with variables.

    Let's see, if we just simplify and factor, skip checking if we need to set or not, and just set. Maybe this will work?
    pub LCDCS ( address -- )	$40 AND IF LCDB ELSE LCDA THEN ;
    pub LCDPAGE ( address -- )	LCDBOTH 7 >> $B8 OR LCDCMD ;
    pub LCDADR ( address -- )	DUP LCDPAGE DUP LCDCS $3F AND $40 OR LCDCMD ;
    pub LCD! ( data address -- )	LCDADR LCDDAT ;
    
    --- transfer buffer to LCD, start from upper left corner and move down to bottom right and set ch
    pub LCDBITBLT ( -- )		LCDBOTH lcdon LCDCMD 0 lcdmemlen ADO lcdmem I + C@ I LCD! LOOP ;
    
    
  • D.PD.P Posts: 790
    edited 2017-02-16 05:22
    @proplem - I see the problem, it's thinking in German and writing in English! (then trying to translate it back to German when you read it)

    When Luke Skywalker used the Force he had to let go of his "aids", flipping the targeting computer out of the way. While useful, it can get in the way. Same with variables.

    Let's see, if we just simplify and factor, skip checking if we need to set or not, and just set. Maybe this will work?
    pub LCDCS ( address -- )	$40 AND IF LCDB ELSE LCDA THEN ;
    pub LCDPAGE ( address -- )	LCDBOTH 7 >> $B8 OR LCDCMD ;
    pub LCDADR ( address -- )	DUP LCDPAGE DUP LCDCS $3F AND $40 OR LCDCMD ;
    pub LCD! ( data address -- )	LCDADR LCDDAT ;
    
    --- transfer buffer to LCD, start from upper left corner and move down to bottom right and set ch
    pub LCDBITBLT ( -- )		LCDBOTH lcdon LCDCMD 0 lcdmemlen ADO lcdmem I + C@ I LCD! LOOP ;
    
    

    Beautiful, it's hard to learn to write in FORTH and not merely translate C, SPIN... into FORTH syntax.
  • @proplem - I see the problem, it's thinking in German and writing in English! (then trying to translate it back to German when you read it)

    When Luke Skywalker used the Force he had to let go of his "aids", flipping the targeting computer out of the way. While useful, it can get in the way. Same with variables.

    Let's see, if we just simplify and factor, skip checking if we need to set or not, and just set. Maybe this will work?
    pub LCDCS ( address -- )	$40 AND IF LCDB ELSE LCDA THEN ;
    pub LCDPAGE ( address -- )	LCDBOTH 7 >> $B8 OR LCDCMD ;
    pub LCDADR ( address -- )	DUP LCDPAGE DUP LCDCS $3F AND $40 OR LCDCMD ;
    pub LCD! ( data address -- )	LCDADR LCDDAT ;
    
    --- transfer buffer to LCD, start from upper left corner and move down to bottom right and set ch
    pub LCDBITBLT ( -- )		LCDBOTH lcdon LCDCMD 0 lcdmemlen ADO lcdmem I + C@ I LCD! LOOP ;
    
    
    Ha! After abandoning the first shock I tried it out. It works. After thinking wether I should leave the forum and become a manager - I don't want to have anything to do with black magic which is obviously used at this place.
    BUT: I compared performance:
    Peter's minimalistic FORTH version:
    LAP LCDBITBLT LAP .LAP 118.009ms ok
    

    My maybe not so convoluted FORTHish child's book readable version:
    LAP LCDBITBLT LAP .LAP 77.955ms ok
    

    Now you're gasping :-D :-D :-D

    Nevertheless chapeau Peter - of course it is a beautiful solution.

    Best regards, yours :-)
    proplem
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-02-16 11:42
    @proplem - no no no, that can't be right :) You made me chuckle, well done, and then I just had to code up the rest of it and try it out. Hmmmm..... I tried my version with V4 code:
    ( 0034 $2DA4  ok )   LAP LCDBITBLT LAP .LAP
    5900272 cycles at 96000000Hz  or 61.461ms
    
    That's with an lcdmemlen of 1,024 since we have a 128x64 graphic LCD = 128x8 bytes = 1,024.
    Anyway here's my code I used.
    TACHYON
    
    : KS0108.fth		PRINT" KS0108 128x64 Graphic LCD " ;
    
    $3FC	== *lcd
    $3F	== lcdon
    
    #P0	== *rs
    #P1	== *lcdce
    #P10	== *CS1
    #P11	== *CS2
    *CS1 MASK *CS2 MASK + == *BOTH
    
    1,024	== lcdmemlen
    
    lcdmemlen	bytes lcdmem
    
    
    --- Output a byte to the LCD as a character
    pri LCDDAT ( ch --  )
        *rs HIGH
    pri WriteLCD ( data -- )
        *lcd OUTCLR				--- Prep data bus as outputs (all low)
        2* 2* OUTSET				--- and write data (set after clear)
        *lcdce HIGH *lcdce LOW			--- 2us pulse chip enable
        ;
    --- Output a byte to the LCD as an instruction
    pri LCDCMD ( cmd -- )
        *rs LOW WriteLCD
        ;
    
    pub LCDCS ( address -- )	*BOTH OUTSET $40 AND IF *CS1 LOW ELSE *CS2 LOW THEN ;
    pub LCDPAGE ( address -- )	*BOTH OUTCLR 7 >> $B8 OR LCDCMD ;
    pub LCDADR ( address -- )	DUP LCDPAGE DUP LCDCS $3F AND $40 OR LCDCMD ;
    pub LCD! ( data address -- )	LCDADR LCDDAT ;
    
    --- transfer buffer to LCD
    --- start from upper left corner and move down to bottom right and set ch
    pub LCDBITBLT ( -- )		*BOTH OUTCLR lcdon LCDCMD 0 lcdmemlen ADO lcdmem I + C@ I LCD! LOOP ;
    
    
    END
    
    

    I'm sure I could make it faster and simpler again. I wonder if it works?

    If so then what about the optimized version that only sets the page, chip select, and address every 64 bytes since the "Y" address pointer autoincrements.
    ( 0037 $2DAC  ok )   LAP LCDBITBLT LAP .LAP
    1345520 cycles at 96000000Hz  or 14.015ms 
    
    Oh, and even in V4 it only requires
    Code bytes used = 158
    
  • @proplem - no no no, that can't be right :) You made me chuckle, well done, and then I just had to code up the rest of it and try it out. Hmmmm..... I tried my version with V4 code:
    ...

    @Peter, your version is nearly working - there must be a small mistake , I didn't take time to find it. But on Tachyon V3 runtime of your last posted version is:
    LAP LCDBITBLT LAP .LAP 110.631ms ok
    

    Maybe I should try my version on V4 but I don't want you to get a sleepless night :-D
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-02-16 11:58
    @proplem - I did load up V3 and got poor results but maybe with the same optimizations it will do a lot better, maybe not better than 14ms but I think I got 45ms for that method.

    Scratch that, I'm down to 12ms, no tricks.

    Scratch that
    ( 0034 $2DB2  ok )   LAP LCDBITBLT LAP .LAP
    847744 cycles at 96000000Hz  or 8.830ms
    
  • @proplem - I did load up V3 and got poor results but maybe with the same optimizations it will do a lot better, maybe not better than 14ms but I think I got 45ms for that method.

    Scratch that, I'm down to 12ms, no tricks.

    Scratch that
    ( 0034 $2DB2  ok )   LAP LCDBITBLT LAP .LAP
    847744 cycles at 96000000Hz  or 8.830ms
    

    Wow, that's a benchmark! Although I don't know wether the LCD display is in sync with this speed. I saw remarks in the internet that enable signal has to be hold 4 ms to stay in sync. We'll see later.

    BTW: Should I change to V4? We're having so much fun in this V3 thread :-)
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-02-16 12:32
    proplem wrote: »

    Wow, that's a benchmark! Although I don't know wether the LCD display is in sync with this speed. I saw remarks in the internet that enable signal has to be hold 4 ms to stay in sync. We'll see later.

    BTW: Should I change to V4? We're having so much fun in this V3 thread :-)

    I think that 4ms is more of a sync to do with game screen updates. You could have this routine running in a cog and just continually updating the LCD 100 times/second although the STN LCD is slow and probably you wouldn't need an update rate of more than 20 fps I'd say. Or you could have it update when the game requests a screen update. The controller chip itself does not need any such long timing such as 4ms, indeed the E high time is 450ns minimum.

    As for V4 I wouldn't want you to lose your momentum with Tachyon but as you can see, it is definitely faster in some areas and overall.
  • MJBMJB Posts: 1,235
    Hi @Peter

    where is the code for those faster and faster versions ?

    so we can learn step by step how you did it
    to improve our coding style ...
    thanks

  • MJB wrote: »
    Hi @Peter

    where is the code for those faster and faster versions ?

    so we can learn step by step how you did it
    to improve our coding style ...
    thanks

    Have a look here, before they try and put Tachyon in the "Forth" sub-forum, alongside the C, Basic, and Spin sub-forums of course :)
    TACHYON V4
    
    : KS0108.fth		PRINT" KS0108 128x64 Graphic LCD " ;
    
    $3FC			== *lcd
    $3F			== lcdon
    
    #P0			== *rs
    #P1			== *lcdce
    #P10			== *CS1
    #P11			== *CS2
    *CS1 MASK *CS2 MASK +	== *BOTH
    
    1,024			== lcdmemlen
    
    --- lcd buffer
    lcdmemlen		bytes lcdmem
    
    
    --- Output a byte to the LCD as a character
    pri LCDDAT ( ch --  )
        *rs HIGH
    pri WriteLCD ( data -- )
        --- write data (set after clear)
        *lcd OUTCLR 2* 2* OUTSET
        --- min 450ns pulse chip enable
        H H L
        ;
    --- Output a byte to the LCD as an instruction
    pri LCDCMD ( cmd -- )
        *rs LOW WriteLCD
        ;
    
    pub LCDCS ( address -- )	*BOTH OUTSET $40 AND IF *CS1 LOW ELSE *CS2 LOW THEN ;
    pub LCDPAGE ( address -- )	*BOTH OUTCLR 7 >> $B8 OR LCDCMD ;
    pub LCDADR ( address -- )	DUP LCDPAGE DUP LCDCS $3F AND $40 OR LCDCMD ;
    
    --- transfer buffer to LCD
    --- start from upper left corner and move down to bottom right and set ch
    pub LCDBITBLT ( -- )		*lcdce PIN L *BOTH OUTCLR lcdon LCDCMD 0 lcdmemlen ADO I LCDADR *rs HIGH I lcdmem + 64 ADO I C@ WriteLCD LOOP 64 +LOOP ;
    
    {
    Optimize BitBlt by setting address once every 64 columns as the KS0108 6-bit "Y" address autoincrements
    Also during writing 64 bytes of data skip having to set *rs HIGH, just select it at the start of the loop
    Reduce write pulse to KS0108
    ( 0034 $2DB2  ok )   LAP LCDBITBLT LAP .LAP
    847744 cycles at 96000000Hz  or 8.830ms
    }
    
    END
    

  • Cluso99Cluso99 Posts: 18,066
    Peter,
    Are you sure there is a Propeller underneath Tachyon? Seems too good to be true ;)
  • @Peter,

    as you are the current LCDBITBLT race leader (I never give up - some races are won in the last lap :-) I would like to slow you a little bit down.
    You mentioned already having implemented some graphics routines to draw into a buffer and pointed to VGA.FTH. This is color graphics but the LameStation Display is blue and white.
    Would you recommend to use this color graphic routines or should I implement from scratch some blue and white ones? (I could copy from yours.)
  • MJBMJB Posts: 1,235
    MJB wrote: »
    Hi @Peter

    where is the code for those faster and faster versions ?

    so we can learn step by step how you did it
    to improve our coding style ...
    thanks

    Have a look here, before they try and put Tachyon in the "Forth" sub-forum, alongside the C, Basic, and Spin sub-forums of course :)
    TACHYON V4
    
    : KS0108.fth		PRINT" KS0108 128x64 Graphic LCD " ;
    
    $3FC			== *lcd
    $3F			== lcdon
    
    #P0			== *rs
    #P1			== *lcdce
    #P10			== *CS1
    #P11			== *CS2
    *CS1 MASK *CS2 MASK +	== *BOTH
    
    1,024			== lcdmemlen
    
    --- lcd buffer
    lcdmemlen		bytes lcdmem
    
    
    --- Output a byte to the LCD as a character
    pri LCDDAT ( ch --  )
        *rs HIGH
    pri WriteLCD ( data -- )
        --- write data (set after clear)
        *lcd OUTCLR 2* 2* OUTSET
        --- min 450ns pulse chip enable
        H H L
        ;
    --- Output a byte to the LCD as an instruction
    pri LCDCMD ( cmd -- )
        *rs LOW WriteLCD
        ;
    
    pub LCDCS ( address -- )	*BOTH OUTSET $40 AND IF *CS1 LOW ELSE *CS2 LOW THEN ;
    pub LCDPAGE ( address -- )	*BOTH OUTCLR 7 >> $B8 OR LCDCMD ;
    pub LCDADR ( address -- )	DUP LCDPAGE DUP LCDCS $3F AND $40 OR LCDCMD ;
    
    --- transfer buffer to LCD
    --- start from upper left corner and move down to bottom right and set ch
    pub LCDBITBLT ( -- )		*lcdce PIN L *BOTH OUTCLR lcdon LCDCMD 0 lcdmemlen ADO I LCDADR *rs HIGH I lcdmem + 64 ADO I C@ WriteLCD LOOP 64 +LOOP ;
    
    {
    Optimize BitBlt by setting address once every 64 columns as the KS0108 6-bit "Y" address autoincrements
    Also during writing 64 bytes of data skip having to set *rs HIGH, just select it at the start of the loop
    Reduce write pulse to KS0108
    ( 0034 $2DB2  ok )   LAP LCDBITBLT LAP .LAP
    847744 cycles at 96000000Hz  or 8.830ms
    }
    
    END
    

    thanks @Peter, I had the 'same' idea of factoring around fast 64 byte block moves - so feels good to see the code. I would have taken me quite a while to write it ...

    So now on V4 you can even use your IC@ to speed up more :-) ...
  • MJBMJB Posts: 1,235
    proplem wrote: »
    @Peter,

    as you are the current LCDBITBLT race leader (I never give up - some races are won in the last lap :-) I would like to slow you a little bit down.
    You mentioned already having implemented some graphics routines to draw into a buffer and pointed to VGA.FTH. This is color graphics but the LameStation Display is blue and white.
    Would you recommend to use this color graphic routines or should I implement from scratch some blue and white ones? (I could copy from yours.)
    blue - white is ok for you ... you don't want the fancy half blue ??
    then a black&white approach might be sufficient.
    I didn'T look into the VGA code recently, but the structure should be easily usable.
  • MJB wrote: »
    blue - white is ok for you ... you don't want the fancy half blue ??
    then a black&white approach might be sufficient.
    I didn'T look into the VGA code recently, but the structure should be easily usable.

    Oh yes, you're right - half blue - I saw that it exists but didn't remember. So the decision is done. Full color support makes sense. I will dive into VGA.FTH ...

    Thank you MJB
  • Cluso99 wrote: »
    Peter,
    Are you sure there is a Propeller underneath Tachyon? Seems too good to be true ;)

    I just keep getting the distinct feeling that Parallax and the forum in general have a disdain for Forth. I mean, they keep comparing it with other "languages", as if an operating-system/compiler/interpreter running on the basic Propeller itself could be compared with "just a compiler" that runs on a PC. But then again, many have "tried Forth" and have formed and fixed their opinions :) Not all though I must say.

    I remember when Cliff Biffle wrote a Forth for the Propeller, the Parallax guys were all excited and wanted to go meet him. But that was just a Forth, buggy and slow, and not even a rudimentary file system or proper serial communications. What could you do with it? Not much at all. I tried.

    Tachyon is a practical solution for the Propeller, leveraging its strengths, and compensating for its weaknesses, then throwing in a whole bunch of absolutely useful stuff that you'd never thought you could do on "just a Propeller" (think here of ignorant disdain from the ARM/AVR/PIC etc crowd). If there existed a "language" that could showcase the Propeller, to have it show off all it's tricks, even all at the same time, wouldn't Parallax be interested, at least just to show what can be done? (long silence here).

    Maybe you're right Ray, it seems too good to be true.


  • ErNaErNa Posts: 1,738
    OK, it is a pity! What is Tachyon missing? Personally I'm very unhappy not to manage it to switch over to Tachyon. I miss a guy, who can pull people deep into Tachyon, so they find no way out and never want to do so. How to make a Master Plan?
  • I just keep getting the distinct feeling that Parallax and the forum in general have a disdain for Forth. I mean, they keep comparing it with other "languages", as if an operating-system/compiler/interpreter running on the basic Propeller itself could be compared with "just a compiler" that runs on a PC. But then again, many have "tried Forth" and have formed and fixed their opinions :) Not all though I must say.
    I hope you're including me in the "not all though" part. I've always been intrigued by Forth and now Tachyon given how much you can do with it. I follow the Tachyon threads and try to parse the examples but still haven't found a big block of time I can spend getting up to speed to a point where I can do non-trivial things. However, I can't see how you could argue against it being a big asset to the Propeller. I don't know of any other language that will let you do as much.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-02-17 12:52
    David Betz wrote: »
    I just keep getting the distinct feeling that Parallax and the forum in general have a disdain for Forth. I mean, they keep comparing it with other "languages", as if an operating-system/compiler/interpreter running on the basic Propeller itself could be compared with "just a compiler" that runs on a PC. But then again, many have "tried Forth" and have formed and fixed their opinions :) Not all though I must say.
    I hope you're including me in the "not all though" part. I've always been intrigued by Forth and now Tachyon given how much you can do with it. I follow the Tachyon threads and try to parse the examples but still haven't found a big block of time I can spend getting up to speed to a point where I can do non-trivial things. However, I can't see how you could argue against it being a big asset to the Propeller. I don't know of any other language that will let you do as much.

    Absolutely, you are the first guy I thought of and I didn't want to include you with these general comments, hence the "not all though". :)

    Now we discussed calling it something different in the past, like Tachyon Basic, or maybe even BlockyForth, perhaps taChyon++ :)

    Maybe it's the German in me that says "if this is the best way to do something, then why aren't I doing it that way". I think plain simple Spin will always be one of the best ways of getting into the Prop and it's sad to see that this nice simple solution is being pushed aside for something more "popular". The saddest part though is that these popular tools don't make the Propeller work better, leaner, or meaner, it simply shows up how inadequate the Propeller is (for those tools).



  • I'm taking first steps into VGA.FTH . I modified vgapars according to my LCD and now I wanted to PLOT a pixel and I wonder about the PLOT definition:
    pub PLOT        IF bigch ELSE BL THEN VCHAR ;
    

    How should this set a pixel into a memory bitmap?
    How do I set just one pixel?

    Remember I didn't try VGA.FTH yet (no VGA monitor and working at notebook). LameStation has no VGA and I'm in flow. Should I change to another board with VGA and do first steps or is it possible just to take the code to do bitmap graphics on my LCD Display?
  • proplem wrote: »
    I'm taking first steps into VGA.FTH . I modified vgapars according to my LCD and now I wanted to PLOT a pixel and I wonder about the PLOT definition:
    pub PLOT        IF bigch ELSE BL THEN VCHAR ;
    

    How should this set a pixel into a memory bitmap?
    How do I set just one pixel?

    Remember I didn't try VGA.FTH yet (no VGA monitor and working at notebook). LameStation has no VGA and I'm in flow. Should I change to another board with VGA and do first steps or is it possible just to take the code to do bitmap graphics on my LCD Display?

    Maybe VGA.FTH isn't the best one to use come to think of it. I do have a really old 128x64 LCD demo but that drew directly to the LCD, which you could also do and forgo the buffer. The same with QVGA TFT driver but one of the first things I did with Tachyon was run graphics VGA. It's old original Tachyon code <here> but it should give you a good headstart. There are also early youtube videos I did at the time too.

  • Cluso99Cluso99 Posts: 18,066
    Peter,
    What you have achieved is simply amazing. I am in awe of what you can do so simply, quickly and efficiently.
    I follow your thread but I cannot understand your code one liners. It's not something I can just see, nor wrap my head around. I've tried a few times. Perhaps my old brain cannot be retrained anymore.
    Anyway, keep up the excellent work. I know you are using it in you big project so it's not going to waste.
  • MJBMJB Posts: 1,235
    ErNa wrote: »
    OK, it is a pity! What is Tachyon missing? Personally I'm very unhappy not to manage it to switch over to Tachyon. I miss a guy, who can pull people deep into Tachyon, so they find no way out and never want to do so. How to make a Master Plan?

    YOU are THE guy ;-)
    the only guy to pull you in ...

  • The problem is that Forth is a steep learning curve for people that have already learned to program in other languages.

    The great strengths of Forth are that it's (relatively) easy to get going on new hardware, and that it results in amazingly compact code. The fact that it's so compact meant that it was very popular back in the 80s when memory was scarce and expensive but as memory (on most systems) became bigger and cheaper Forth tended to lose more and more of its share of the 'market'.

    On the propeller we don't have much RAM - there are ways of adding external RAM but they all suffer from one or more of the flaws of being slow, expensive, or using up a lot of the available I/O pins. Even if there was a very fast, very cheap way of adding lots of RAM that didn't use many pins it would still have the drawback of being non-standard for the propeller. So for the propeller, Forth is great fit - especially Peter's Tachyon flavour of Forth. It's not just a language - it's a compiler and operating system too - all running on the usual prop hardware without RAM expansion. Applications written in Forth run faster and are much smaller than those written in Spin - they're often smaller even than the same application written in assembler - unless that hand-written assembler is optimized very carefully.

    There's still the big learning curve to get over for newcomers - but dive in, stick with it, and eventually you develop the Forth way of thinking. It's a fun thing to do - and fun is the reason most of us are playing with the Propeller in the first place.
  • Maybe VGA.FTH isn't the best one to use come to think of it. I do have a really old 128x64 LCD demo but that drew directly to the LCD, which you could also do and forgo the buffer. The same with QVGA TFT driver but one of the first things I did with Tachyon was run graphics VGA. It's old original Tachyon code <here> but it should give you a good headstart. There are also early youtube videos I did at the time too.

    Thanks @Peter, I'm studying VGA DEMO.FTH.

    Trying to compile it I have changed some things in order to compile and load. My objective is to draw something into memory and LCDBITLBT this to the LCD device.

    0. Some few words about the structure of the bitmap (How are the bits organized?)
    One linear bytestream RRGGBBxx | RRGGBBxx | RRGGBBxx | ... ?

    1. I made some minor changes to be able to compile (WVARIABLE -> WORD, etc.) things where I know what I do

    2. 'pixels' buffer : I introduced 'BUFLEN', allocated bytes for 'pixels', introduced 'colors' like this
    \ [2017-02-17 Fri 21:00] $6000 == BUFLEN \ buffer length as defined in VGA DEMO.FTH
    1024 == BUFLEN \ buffer length (128 64 * 8 / )
    BUFLEN BYTES pixels
    TABLE colors 64 2* ALLOT
    

    3. Here I need help :
    I replaced 'FONT' with a dummy because I don't know what it does
    pub FONT ;
    

    4. Here I need help :
    I replaced '=PIXELS'
    pub =PIXELS ;
    

    5. VGAINIT is yet commented out also the last line

    PS: still not tried VGA.FTH in hardware - I know that it's good but I want to use it for the LameStation
    PPS: please don't spend too much time - I would just appreciate some tips

    Thanks in advance, proplem
  • MJBMJB Posts: 1,235
    proplem wrote: »
    Maybe VGA.FTH isn't the best one to use come to think of it. I do have a really old 128x64 LCD demo but that drew directly to the LCD, which you could also do and forgo the buffer. The same with QVGA TFT driver but one of the first things I did with Tachyon was run graphics VGA. It's old original Tachyon code <here> but it should give you a good headstart. There are also early youtube videos I did at the time too.

    Thanks @Peter, I'm studying VGA DEMO.FTH.

    Trying to compile it I have changed some things in order to compile and load. My objective is to draw something into memory and LCDBITLBT this to the LCD device.

    0. Some few words about the structure of the bitmap (How are the bits organized?)
    One linear bytestream RRGGBBxx | RRGGBBxx | RRGGBBxx | ... ?

    1. I made some minor changes to be able to compile (WVARIABLE -> WORD, etc.) things where I know what I do

    2. 'pixels' buffer : I introduced 'BUFLEN', allocated bytes for 'pixels', introduced 'colors' like this
    \ [2017-02-17 Fri 21:00] $6000 == BUFLEN \ buffer length as defined in VGA DEMO.FTH
    1024 == BUFLEN \ buffer length (128 64 * 8 / )
    BUFLEN BYTES pixels
    TABLE colors 64 2* ALLOT
    

    3. Here I need help :
    I replaced 'FONT' with a dummy because I don't know what it does
    pub FONT ;
    

    4. Here I need help :
    I replaced '=PIXELS'
    pub =PIXELS ;
    

    5. VGAINIT is yet commented out also the last line

    PS: still not tried VGA.FTH in hardware - I know that it's good but I want to use it for the LameStation
    PPS: please don't spend too much time - I would just appreciate some tips

    Thanks in advance, proplem

    @Proplem
    the LCDBITLBT uses a 1 bit bitmap to send to the LCD.
    why don't you start simple with a 1-bit memory bitmap.

    If / when it works make it more complicated.

    pub DRAWPIX ( x y 0/1 .. ) ...

    locate the byte \
    merge in the bit \ OR / ANDN ...

    ;

  • MJB wrote: »
    @Proplem
    the LCDBITLBT uses a 1 bit bitmap to send to the LCD.
    why don't you start simple with a 1-bit memory bitmap.

    If / when it works make it more complicated.

    pub DRAWPIX ( x y 0/1 .. ) ...

    locate the byte \
    merge in the bit \ OR / ANDN ...

    ;
    hi mjb, you are right. I could do this and reinvent all the work Peter has already done in less quality. Do you really recommend this and why?
Sign In or Register to comment.