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 107 — Parallax Forums

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

1103104105107109

Comments

  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-02-18 10:32
    @proplem - Earlier I referred to the KS0108 as a kludge of a kludge, so should it come as any surprise that interfacing to it is a bit of a kludge? The geometry indicates that a byte of pixels are written as a vertical column with 64 columns with another 64 columns in the other "chip". Then after traversing the chips to draw 128 columns of 8 pixels high you then go on to the next line. That's messy and we just need to find a nice simple way to map a conventional raster buffer where a byte of pixels is displayed horizontally rather than how the KS0108 expects it.

    So the BitBlit routine actually has to do a bit more than just read from memory, it needs to translate that on the fly. A byte would normally represent 8 horizontal pixels for monochrome so we would actually need to read 8 bytes extracting the same bit from each to build up a byte that we could write as 8 vertical pixels. If we were simply drawing a font that was 8 pixels high there would not be any problem as the font table would be arranged as 5 bytes for each column for a 5x7 font.

    Now if we assume we have a conventional monochrome pixel buffer where a byte is 8 horizontal pixels then we would need 16 bytes per line for 128 pixels by 64 lines, that's our 1,024 bytes. You can choose to address this buffer in two ways, either as a linear xy array and remap when you write to the LCD, or define the PLOT primitive to address the correct bit in the correct byte. But drawing is more important than writing to the display which can not handle a high frame update rate anyway, so I would choose a simple linear xy buffer and remap the pixels when I write to the LCD.

    You can also write a very short routine that displays this buffer on your terminal screen, mapping a * for a pixel and a dot or space for none. That would be a quick way to confirm it is working too.

    BTW, there is a PLOT module in V3 that you could use, just setup the buffer address and pixels/line as a binary shift of 7 bits for 128 pixels at 3 COGREG! and 4 COGREG! for the address.

    This would draw a sloped line from top left to the bottom center.
    0 64 ADO I I PLOT LOOP
    
    ' PLOT ( x y -- )
    _PLOT                   shl     tos,pixshift    ' n^2 bytes/Y line
                            mov     X,tos+1
                            shr     tos+1,#3        ' byte offset in line
                            add     tos,tos+1       ' byte offset in frame
                            add     tos,pixeladr    ' byte address in memory
                            and     X,#7    ' get bit mask
                            mov     tos+1,#1
                            shl     tos+1,X
                            jmp     #SET
    

    PLOT is a RUNMOD so you initially need to load it with [PLOT] and then either use RUNMOD to execute it or it may be more convenient to make an ALIAS of RUNMOD called PLOT
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-02-18 14:09
    @proplem - just to demonstrate what I mentioned above, here is some "test" code :)
    : SHOW
    	lcdmem lcdmemlen ADO
    	  CR I 16 ADO I C@ 8 FOR DUP 1 AND IF '*' ELSE '.' THEN EMIT 2/ NEXT DROP LOOP
    	  16 +LOOP
    	  ;
    
    ALIAS RUNMOD PLOT
    word X
    word Y
    : !LCD
    	lcdmem lcdmemlen ERASE
    	lcdmem 4 COGREG! 4 3 COGREG! [PLOT]
    	X W~ Y W~
    	;
    --- dummy CR & LF for test
    : VCR ;
    : VLF	DROP ;
    --- Draw a Propeller font character on the graphics screen at X,Y
    : LCDCH ( ch -- )
           DUP 2/ 7 SHL $8000 +			--- Calculate address of font character ( ch addr )
           Y W@ #32					--- 32 lines
     	  ADO DUP @				--- Next 16 pixels (2 sets)
     	  3RD 1 AND IF 2/ THEN 			--- If it's an odd character then adjust font pixels
             X W@ #16 				--- 16 pixels/line
     	    ADO DUP 1 AND			--- Next pixel in font set?
     	      IF I J PLOT THEN 			--- Plot each pixel
     	    2/ 2/ 				--- shift to next pixel (every second one)
     	    LOOP
             DROP 4 +  				--- next long (line)
             LOOP
     	2DROP 16 X W+!				--- Advance X cursor 16 pixels to the right
     	X W@ 120 > IF VCR #32 VLF THEN		--- but move to the next character line down if needed
     	;
    
    : LCD	' LCDCH uemit W! ;
    : DEMO	!LCD 0 64 ADO I I PLOT LOOP LCD PRINT" HELLO" CON SHOW ;
    

    Running it on the console
    ( 0004 $2D4E  ok )   TACHYON V4
      Propeller .:.:--TACHYON--:.:. Forth V4.1 DAWN 410170214.0000
    ( 0083 $2ED2  ok )   
    
       End of source code, 0000  errors found  Load time = 66289504 cycles at 96000000Hz  or 690.515ms 
    Code bytes used = 388
    CODE:$2ED2 =11474 bytes   NAME:$5C90 =6000 bytes   DATA:$76D8 =200 bytes    =11710 bytes free    Data Stack (0)
    ( 0084 $2ED2  ok )   
    ( 0085 $2ED2  ok )   DEMO
    
    *...............................................................................................................................
    .*..............................................................................................................................
    ..*.............................................................................................................................
    ...*............................................................................................................................
    ....*...........................................................................................................................
    ..****......***...*************...***.............***.................*****.....................................................
    ..***.*.....***...*************...***.............***...............*********...................................................
    ..***..*....***...*************...***.............***..............***********..................................................
    ..***...*...***...***.............***.............***..............***.....***..................................................
    ..***....*..***...***.............***.............***.............***.......***.................................................
    ..***.....*.***...***.............***.............***.............***.......***.................................................
    ..***......****...***.............***.............***.............***.......***.................................................
    ..***.......***...***.............***.............***.............***.......***.................................................
    ..***.......***...***.............***.............***.............***.......***.................................................
    ..*************...*********.......***.............***.............***.......***.................................................
    ..**************..*********.......***.............***.............***.......***.................................................
    ..*************.*.*********.......***.............***.............***.......***.................................................
    ..***.......***..****.............***.............***.............***.......***.................................................
    ..***.......***...***.............***.............***.............***.......***.................................................
    ..***.......***...***.............***.............***.............***.......***.................................................
    ..***.......***...***.............***.............***.............***.......***.................................................
    ..***.......***...****............***.............***.............***.......***.................................................
    ..***.......***...***.*...........***.............***.............***.......***.................................................
    ..***.......***...***..*..........***.............***..............***.....***..................................................
    ..***.......***...*************...*************...*************....***********..................................................
    ..***.......***...*************...*************...*************.....*********...................................................
    ..***.......***...*************...*************...*************.......*****.....................................................
    ...........................*....................................................................................................
    ............................*...................................................................................................
    .............................*..................................................................................................
    ..............................*.................................................................................................
    ...............................*................................................................................................
    ................................*...............................................................................................
    .................................*..............................................................................................
    ..................................*.............................................................................................
    ...................................*............................................................................................
    ....................................*...........................................................................................
    .....................................*..........................................................................................
    ......................................*.........................................................................................
    .......................................*........................................................................................
    ........................................*.......................................................................................
    .........................................*......................................................................................
    ..........................................*.....................................................................................
    ...........................................*....................................................................................
    ............................................*...................................................................................
    .............................................*..................................................................................
    ..............................................*.................................................................................
    ...............................................*................................................................................
    ................................................*...............................................................................
    .................................................*..............................................................................
    ..................................................*.............................................................................
    ...................................................*............................................................................
    ....................................................*...........................................................................
    .....................................................*..........................................................................
    ......................................................*.........................................................................
    .......................................................*........................................................................
    ........................................................*.......................................................................
    .........................................................*......................................................................
    ..........................................................*.....................................................................
    ...........................................................*....................................................................
    ............................................................*...................................................................
    .............................................................*..................................................................
    ..............................................................*.................................................................
    ...............................................................*................................................................
    ( 0086 $2ED2  ok )   
    
    
  • The complete LCD code the graphics driver ready to add those drawing routines to. The BitBlt needs to translate into the correct register address but at least you can check what it is supposed to look like using SHOW on the console.
    demo.png
    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
    
    $7C00			== 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
    }
    
    ALIAS RUNMOD PLOT
    
    word X
    word Y
    
    : !LCD
    	lcdmem lcdmemlen ERASE
    	lcdmem 4 COGREG! 4 3 COGREG! [PLOT]
    	X W~ Y W~
    	;
    : VCR	X W~ ;
    : VLF	Y W+! ;
    
    --- Draw a Propeller font character on the graphics screen at X,Y
    : LCDCH ( ch -- )
           DUP 2/ 7 SHL $8000 +			--- Calculate address of font character ( ch addr )
           Y W@ #32					--- 32 lines
     	  ADO DUP @				--- Next 16 pixels (2 sets)
     	  3RD 1 AND IF 2/ THEN 			--- If it's an odd character then adjust font pixels
             X W@ #16 				--- 16 pixels/line
     	    ADO DUP 1 AND			--- Next pixel in font set?
     	      IF I J PLOT THEN 			--- Plot each pixel
     	    2/ 2/ 				--- shift to next pixel (every second one)
     	    LOOP
             DROP 4 +  				--- next long (line)
             LOOP
     	2DROP 16 X W+!				--- Advance X cursor 16 pixels to the right
     	X W@ 112 > IF VCR 32 VLF THEN		--- but move to the next character line down if needed
     	;
    
    : LCD	' LCDCH uemit W! ;
    
    --- console render of graphics buffer
    : SHOW
    	lcdmem lcdmemlen ADO
    	  CR I 16 ADO I C@ 8 FOR DUP 1 AND IF '#' ELSE $20 THEN EMIT 2/ NEXT DROP LOOP
    	  16 +LOOP
    	  ;
    
    : DEMO	!LCD  0 64 ADO I I PLOT LOOP LCD PRINT" HELLO   WORLD" CON SHOW ;
    
    END
    
    1400 x 2060 - 29K
  • MJBMJB Posts: 1,235
    proplem wrote: »
    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?
    proplem wrote: »
    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?
    proplem wrote: »
    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?

    All the high level drawing routines for line/box/circle/character ... are based on setting a single pixel in the bitmap.
    So if you have this 'DRAWPIX' draw a single pixel routine all the rest can be reused.
    Just substitute the existing pixel drawing routine.
    This was based on the assumption you have the memory bitmap format and the CopyMemoryBitmapToLCD routine ready.

    But Peter's suggestion to do the adaptation on the CopyMemoryBitmapToLCD side is absolutely right. Then the front end can stay as it is.
    Both versions have their pros & cons.

    Doing the adaption on writing might be simpler to do. (I have it ready in my head ..)
  • The complete LCD code the graphics driver ready to add those drawing routines to. The BitBlt needs to translate into the correct register address but at least you can check what it is supposed to look like using SHOW on the console.
    ...
    [/code]

    Hi @Peter,
    in order to follow I had to switch to tachyon v4.
    After downloading from your dropbox I tried to compile and got:
    ln -sf  "Tachyon V4.1.spin" tachyon.spin
    iconv -f utf-16 -t utf-8 "tachyon.spin" > "tachyon.spin.utf-8"
    /usr/local/bin/bstc.linux -b "tachyon.binary" "./tachyon.spin.utf-8" -Ox -DDEF80MHz
    Found a USB Serial Device
    Brads Spin Tool Compiler v0.15.3 - Copyright 2008,2009 All rights reserved
    Compiled for i386 Linux at 08:17:46 on 2009/07/20
    Loading Object tachyon
    
    tachyon(2040,34) Error : Not a Long Address
                            jmp     #SET
    _________________________________^
    tachyon - Error at (4666,15) Expected Spin Method, Unique Name, Assembly Conditional, BYTE, WORD, LONG or Assembly Instruction
            byte 0[varram-(@romend+s)]
    ______________^
    
    Compiled 3402 Lines of Code in 0.088 Seconds
    ( killall -qw minicom || true )
    /usr/local/bin/bstl.linux -d /dev/ttyUSB0 -p 2 "./tachyon.binary"
    Brads SpinTool Loader v0.05 - Copyright 2008,2009 All rights reserved
    Compiled for i386 Linux at 09:34:58 on 2009/07/03
    Found a USB Serial Device
    Could not load Binary
    Makefile:90: recipe for target 'tachyon.binary.dl' failed
    make: *** [tachyon.binary.dl] Error 2
    
    Probably the code is so new that you didn't save the current version to dropbox :-(
  • @proplem - I forgot to save my edits which did compile but I have now. The SET is simply included inline with the PLOT code.
  • @proplem - I forgot to save my edits which did compile but I have now. The SET is simply included inline with the PLOT code.

    @Peter - thank you very much 6:20 in the morning, v4 up and running.

    At KS0108.FTH: SHOW works, display not yet, have to investigate what fails.

    Thank you very much!

    BTW: cause I use git locally I can now switch between branches v3 and v4 easily.
  • proplemproplem Posts: 233
    edited 2017-02-19 06:01
    @Peter,

    I have some trouble with my setup running v4:

    - lamestation
    - 80 MHz
    - Baudrate 921600 (default)
    - nldelay 50 ms

    Downloading EXTENDv4.FTH does compile with errors and doesn't sometimes finish.

    I can enter some commands but one time system freezes after loading KS0108.FTH and LCDBITBLT and there are obscurities pointing to erroneous baudrate settings.

    Because I have automated the build process via Makefile it would ease up things to be able to switch the baudrate after the first build step, downloding the kernel.
    CONBAUD should be part of the spin file - so one could play with it without having to change the source file.

    I'm aware that setting the baudrate on kernel level wouldn't be possible if the communication isn't safe. But I wished it earlier and so I wanted to mention it here. Also it would ease up testing with different baudrates.

    I would appreciate it really much.

    Thanks for your time, best regards
    proplem
    PS: Even hardware reset isn't working.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-02-19 07:16
    @proplem - not sure what your setup is there. I run Linux Mint 18 Cinnamon, minicom in a preferred xfce4 terminal, and line delay set to 5ms. Everything works very snappily.

    CONBAUD can't be changed when running the precompiled kernel because that would require EEPROM access which is defined in EXTEND and although it could be written in a form that runs precompiled, it is easier to let Forth compile these extensions. Can't you just vary the default baud rate in the source?

    btw - new line delay of 50ms is way over the top, as you see everything works fine with 5ms.


  • proplemproplem Posts: 233
    edited 2017-02-19 07:17
    @Peter
    Here a detailed problem report on Tachyon V4.1:

    Still the same hw-config as mentioned before (LameStation), 115200 Baud.

    I compiled like this:
    make clean ttydev=/dev/ttyUSB1 nldly=30 base
    
    which results in
    rm -f ./*.binary.dl
    ( killall -qw minicom || true )
    /usr/local/bin/bstl.linux -d /dev/ttyUSB1 -p 2 "./tachyon.binary"
    Brads SpinTool Loader v0.05 - Copyright 2008,2009 All rights reserved
    Compiled for i386 Linux at 09:34:58 on 2009/07/03
    Found a USB Serial Device
    Propeller Version 1 Found!
    touch tachyon.binary.dl
    make minicom
    make[1]: Entering directory '/home/schmidt5/prj/tachyon/git/TF-P1'
    sleep 1
    gnome-terminal -e "minicom tachyon -b 115200 -D /dev/ttyUSB1 --color=on"
    sleep 1
    make[1]: Leaving directory '/home/schmidt5/prj/tachyon/git/TF-P1'
    continue make? [y/n]: n
    Exiting.
    Makefile:93: recipe for target 'tachyon.binary.dl' failed
    make: *** [tachyon.binary.dl] Error 1
    
    This step compiled well. The error message is because I stopped continuation manually. After a hardware reset which always has to be done V4 comes up with:
    Propeller .:.:--TACHYON--:.:. Forth V4.1 DAWN 410170214.0000
    
     Cold start - no user code - setting defaults  
    --------------------------------------------------------------------------------
    ( 0001 $1900  ok )   TACHYON V4
      Propeller .:.:--TACHYON--:.:. Forth V4.1 DAWN 410170214.0000
    ( 1562 $2DE0  ok )   
    
    This is fine so far. Hardware reset is ok. After every hardware reset the tachyon kernel comes up cleanly.

    Now EXTEND.FTH (which is a renamed EXTEND-V4.FTH) has to be written:
    make clean ttydev=/dev/ttyUSB1 nldly=100 EXTEND.FTH.dl
    
    I used extra long nldelay and 115200 Baud.

    This results in:
    rm -f ./*.binary.dl
    ascii-xfr -s -l 100  EXTEND.FTH > /dev/ttyUSB1
    ASCII upload of "EXTEND.FTH"
    Line delay: 100 ms, character delay 0 ms
    

    In minicom/tachyon this happens:
       End of source code, 0000  errors found  Load time = 543921728 cycles at 80000000Hz  
    Code bytes used = 5344
    CODE:$2DE0 =11232 bytes   NAME:$5D82 =5758 bytes   DATA:$76D4 =196 bytes    =12194 byt)
    ( 1563 $2DE0  ok )   
    ( 1564 $2DE0  ok )   
    ( 1565 $2DE0  ok )   roms $1F00 $FF EFILL
    ( 1566 $2DE0  ok )   SAVEROMS
    ( 1567 $2DE0  ok )   --- 
    ( 1568 $2DE0  ok )   0 U@ DROP
    ( 1569 $2DE0  ok )   FORGET SAVEROMS
    
    ( 1570 $2D4E  ok )   
    ( 1571 $2D4E  ok )   ?BACKUP
    BACKUP /
    ( 1572 $2D4E  ok )   AUTORUN BOOT
    .STATS
    
    CODE:$2D4E =11086 bytes   NAME:$5D8E =5746 bytes   DATA:$76D4 =196 bytes    =12352 byt)
    ( 1573 $2D4E  ok )   lsroms
    NO ROMS
    ( 1574 $2D4E  ok )   
    ( 1575 $2D4E  ok )   
    ( 1576 $2D4E  ok )   
    

    If I do hardware reset now tachyon v4 hangs completely. Even power off doesn't help any more.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-02-19 07:35
    @proplem - the only difference I can see is that your system doesn't have a 64kB EEPROM but that only means that there are "NO ROMS". However I will check this on a 32kB board if I can find one just to make sure that there are no new bugs. I did move console and pingnet parameters into a fixed area in the header area. The console baud rate is now stored as system ticks.
    Check the youtube video I did of a V4 build in my previous post.
    MEMORY MAP
    0000    CLKFREQ
    0004    CLK
    0005    CHKSUM
    0006    PBASE   0010            Always $0010
    0008    VBASE   7E34
    000A    DBASE   7E3C
    000C    PCURR   7E0C            Spin code reset vector
    000E    DCURR   7E40
    0010    PROP TOOL ?             0000.0010:   24 7E 02 00  FC 7D 00 00
    
    0018    VERSION
    0028    CONSOLE BAUD TICKS
    002C    RXPIN,TXPIN,0,0
    0030    PPCFGS (PPBAUD,TR,TE,ID,GP)
    0038    -
    
  • @Peter - started a build for IoT5500 with this 96 MHz device I didn't have problems to write EXTENDV4.FTH and hardware resetting afterwards. So it seems having to do with the hardware that writing EXTENDV4.FTH on LameStation (with propplug) hangs/fails.
    Sorry that I'm such a source of work for you :-(
  • @proplem - I haven't tried this on a standard 32kB EEPROM system but I will try to do this soon. Any work that is enjoyable is hardly work, it's play, but we say it's work so we get paid :)
  • ceptimusceptimus Posts: 135
    edited 2017-02-19 12:36
    Are there any terminal emulators that we could set to look for the 'ok' (or other ?) response(s) when pasting code to Tachyon? Then we could turn the end-of-line delay down to zero and get faster compile times.

    I suppose the easiest (?) way would be to implement X-on, X-off protocol in the Prop's serial driver.
  • proplemproplem Posts: 233
    edited 2017-02-19 19:20
    ceptimus wrote: »
    Are there any terminal emulators that we could set to look for the 'ok' (or other ?) response(s) when pasting code to Tachyon? Then we could turn the end-of-line delay down to zero and get faster compile times.

    I suppose the easiest (?) way would be to implement X-on, X-off protocol in the Prop's serial driver.

    @ceptimus - I think also it would be a great improvement to have control flow and so I searched the thread about the string "XON" and found at least:
    http://forums.parallax.com/discussion/comment/1114281/#Comment_1114281
    http://forums.parallax.com/discussion/comment/1119585/#Comment_1119585
    http://forums.parallax.com/discussion/comment/1124323/#Comment_1124323
    http://forums.parallax.com/discussion/comment/1282018/#Comment_1282018
    http://forums.parallax.com/discussion/comment/1282062/#Comment_1282062
    http://forums.parallax.com/discussion/comment/1331956/#Comment_1331956
    http://forums.parallax.com/discussion/comment/1331983/#Comment_1331983
    http://forums.parallax.com/discussion/comment/1332061/#Comment_1332061
    http://forums.parallax.com/discussion/comment/1332063/#Comment_1332063

    I thought it would be helpful to find this collected.

    Best regards, proplem
  • Hello fellow Tachyon users.

    It seems pretty quiet around here ... no posts in almost two months! Has something happened that I'm yet aware of?

    Just loaded Juno V3 onto a Proto Board. It seems to be the basic word set. Is there a particular EXTEND I should be using for Juno?

    Thanks,

    Michael
    K6MLE
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-04-12 23:57
    K6MLE wrote: »
    Hello fellow Tachyon users.

    It seems pretty quiet around here ... no posts in almost two months! Has something happened that I'm yet aware of?

    Just loaded Juno V3 onto a Proto Board. It seems to be the basic word set. Is there a particular EXTEND I should be using for Juno?

    Thanks,

    Michael
    K6MLE

    I think we are all too busy doing stuff with Tachyon to spend time chatting about it on the forum :) The forum seems to be mostly about those asking for help or about "P2 dreams" :)
    (btw, however much I can "fly" in my dreams, if P2 was available in silicon then there is no need to dream and I would be right in the middle of the P2 feeding frenzy)

    In answer to your question there is only one EXTEND.FTH in the V3 directory, just use that. I will have to load V3 onto a board and check all the files and maybe update the binaries folder as well although I may place a simple extended V3 binary into the V3 folder itself to make it easier to evaluate.

    Now some ramblings....
    The two most immediately practical threads I've seen lately are Heater's RISC-V and also the outworking of the SD card speed thread in respect not so much to working out what the OP was trying to say but in the response to the challenge. I did however find that whole compiler problem was amusing as I had a very simple copy&paste solution very early on that runs extremely fast without any optimization and without implementing multiple-block read modes either. The trouble was my easy solution was not in C.

    What is the observation I make from this alone? That to most people being productive and effective is not as important as being orthodox, even if you are desperate for a solution and pulling your hair out. What does it mean for people who can and may prefer to code in Forth? Nothing of course, we can still write C or any other method if we have to but we are free to choose the best solution. Talking about the best solution in regards to hardware many of us on this forum favor the esoteric Parallax Propeller, a chip that the masses know little about or view with disdain as they compare benchmarks and "features". Yet we are free and empowered to use the Propeller or some other chip. Just the other day I used a tiny little XMC1100 for an encoder application written in Forth as this solution was the best for a one-off. I benefit because I haven't limited myself to any one solution. I see the general inability of the masses to grok Forth as a limitation in finding the best solution just as anyone who is limited to Arduino and unable to grok other architectures will be limited in finding the best solution and thereby pulling their hair out.

  • Hi Peter,

    Just tried the load of EXTEND.FTH from the V3 directory and got an error at line 2224 "error in .TIMERS at RUNTIME @ 0 PRINTDEC *error*.

    I for one, though I'm retired, would much rather program in FORTH and seek it out for the platform I'm compelled to use at a given time. I've always appreciated the assistance received by you and others on the forum, but also understand that most of you are working and not retired! Being patient is one of my virtues! :)
  • K6MLE wrote: »
    Hi Peter,

    Just tried the load of EXTEND.FTH from the V3 directory and got an error at line 2224 "error in .TIMERS at RUNTIME @ 0 PRINTDEC *error*.

    I for one, though I'm retired, would much rather program in FORTH and seek it out for the platform I'm compelled to use at a given time. I've always appreciated the assistance received by you and others on the forum, but also understand that most of you are working and not retired! Being patient is one of my virtues! :)

    Hmm, that's strange, it seemed to load perfectly although I'm trying to upload a binary in the meantime. I set my line delay to 15ms in minicom but try increasing to 20ms. I guess you are using teraterm or minicom.

  • Hi Peter,
    I am using Teraterm and have the line delay set to 25ms, per the readme.txt file in the V3 folder. I use the 'upload raw file' feature to sent it to the Propeller.
  • I tried both the paste text method and the [File} [Send file] command with binary ticked option and both worked fine. Which version of TeraTerm do you have that has an "upload raw file" feature?
  • I'm using Ubuntu and the GtkTerm program to communicate with the Prop. The data is being sent as ASCII, the only other choice being HEX. The Tachyon file I'm using is "Tachyon V3.0 JUNO.spin". There's also a "V3.0-S" file ... not sure how they differ. There's also a "V3.1 JUNO testing" file, which I imagine is not what I want. The EXTEND file says "160818-1400" on the 8th line. Have I got the correct files? It appears to me that I do. Barring a problem there, I'll give it another try and see what happens.
  • Just tried one more time before calling it a night ... stopped at 2315 - "Structure mismatch! *error*

    This is with 25ms line delay and no char delay.

    If you're using Linux, do you suggest a different comm program?

    Thanks!

  • Minicom ticks all the boxes in that it just works
  • Thanks!
    I'll try minicom tomorrow and see how it flies.
  • MJBMJB Posts: 1,235
    Hi Peter,

    just wondering you do not recommend to use V4.

    Is there any reason to stay with Tachyon-V3 over V4
    after you spent so much time on V4 now?
    Anything major still missing?

    My recent little uses of V4 were all fine.

  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-04-13 16:14
    MJB wrote: »
    Hi Peter,

    just wondering you do not recommend to use V4.

    Is there any reason to stay with Tachyon-V3 over V4
    after you spent so much time on V4 now?
    Anything major still missing?

    My recent little uses of V4 were all fine.

    Well I still need to polish the hubcaps with such little things such as being able to backspace properly on interactive entry but otherwise I find that it all works very nicely. I can also compact the dictionary to EEPROM as regular dictionary entries although I'm still looking at improving the search time and also I must try adding vocabularies but none of these things are stopping me from using V4.3 with my commercial projects.

    V4 has been able to utilize the cog memory better since it can now use wordcode to directly address cog or hub code and also encode literals and branches. Each Tachyon cog maintains its data stack in cog memory now so there is no need to allocate stack memory for each cog. Also V4 has proven itself in overall memory savings and speed, so yeah, if you don't mind a few quirks in the meantime then use V4.

  • K6MLE wrote: »
    Thanks!
    I'll try minicom tomorrow and see how it flies.
    I patched the minicom sources a while ago and pasted the dpkg here in this thread. That version saves the line delay in the settings.
    I also created a makefile to ease up building. If you're interested I could post it.
    @k6mle i figured out further tricks to send files from the linux command line.
    Btw: nice to hear from all of you :-)
  • Loaded up minicom and had success on loading EXTEND.FTH in JUNO V3. Now to 'play'!

  • @Peter Jakacki,
    you commented out ERASE$ in (V3) EXTEND.FTH
    pub ERASE$ ( str -- \ Fully erase the string - reads max len from header )
            DUP 3 - C@ ERASE
            ;
    
    Is something wrong with it?
Sign In or Register to comment.