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

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

18889919394109

Comments

  • MJBMJB Posts: 1,200
    edited 2016-07-21 06:41
    D.P wrote: »
    acknowledged, just got the one posted 6 min ago now
    MJB can see your evil waste in the kernel now, beware :)
    ok ok - I am the 'big brother watching for wasted bytes now' ;-)

    AND you see my good intention ??

    I had a little bit the impression focus was shifted to P2-Tachyon now,
    so I am happy to see P1-Tachyon is still very alife and growing.
    Most of my projects will continue to be P1 for a long time.

    let's continue the fun

    and don't forget - 'I am your friend' - not a C-proposing Forth critic ;-)

  • D.P wrote: »
    F32 huh?
    I'm having an issue I guess. Also "suitable" parameters?

    EDIT
    I can't FINDROM on anything loaded but lsroms works, more looking here.

    Sorry, it's a wip and at present I am just searching on a fixed length 8 characters so " F32 " will find it.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2016-07-21 12:59
    MJB wrote: »
    D.P wrote: »
    acknowledged, just got the one posted 6 min ago now
    MJB can see your evil waste in the kernel now, beware :)
    ok ok - I am the 'big brother watching for wasted bytes now' ;-)

    AND you see my good intention ??

    I had a little bit the impression focus was shifted to P2-Tachyon now,
    so I am happy to see P1-Tachyon is still very alife and growing.
    Most of my projects will continue to be P1 for a long time.

    let's continue the fun

    and don't forget - 'I am your friend' - not a C-proposing Forth critic ;-)

    Ok, you are officially the WME (waste management expert), to keep a look out for bits and bytes wasted :) (as a friend of course).
    ==============> WORM (Waste Of Resources Manager) :)

    Many may be caught up in P2 fantasy land but I have an immediate need for P2 which although only available in expensive FPGA at present I can just manage to get away with this for some prototypes. I will be in big trouble if it is delayed but I also have prepared my alternative which might include a network of P1s or perhaps an ARM and a P1.

    So the only REAL chip for the REAL world besides fantasies is the P1 and so it's a matter of making these do what I need and perhaps I may be asking more of them in the near future which is why I need those ROMs and reliable multi-chip networking. I could have done this years ago but P2 was always just around the corner.......... :depressed:

    btw, mind your "language", we will have none of that "C" word around here :)
  • D.PD.P Posts: 790
    edited 2016-07-21 07:15
    Forth is a programming environment for creating application-oriented
    languages.

    Leo Brodie, Thinking Forth

    Yeah regarding the F32, just got there in the source.
    " F32     " FINDROM . 62306 ok
    2 " F32     " LOADCOG Loading cog 2 F362 ok
    
    
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2016-07-21 13:32
    V3 includes LMM interpreter - adding support to assembler

    Another nice little feature I have built into Tachyon with some cog memory I saved was a simple LMM loop which with the support of the interactive assembler allows LMM to be written inline and mixed with Tachyon code. LMM can even jmp to Tachyon opcodes in the cog and return back to the LMM loop if the "unext" pointer is changed from Tachyon's interpreter loop to LMM's. A simple restore is all that is needed to fix it back up again. Since it uses Tachyon's IP instruction pointer for its PC it means that after a return it can continue executing Tachyon bytecode immediately after the LMM. Well, we will have to see how it works out in practice but it is a convenient way to include some LMM PASM inline or even just LMM code definitions.

    btw: "code <name>" creates a regular Forth dictionary header but the first code byte is the opcode for the LMM interpreter with the code long aligned of course.

    The assembler uses regular syntax with some subtle modifications. Here's a little sample of what it looks like at present and in interactive mode it indents for the source and spits out the assembled code on the left as you go.
    code STREND ( ptr -- ptr2 )        
    fchlp       rdbyte  R0,tos    ( read a byte )
                sub     R0, # 1    ( end is either a null or anything >$7F )
                cmp     R0, # $7E wc
          if_c  add     tos, # 1
          if_c  mov     IP, # fchlp
                jmp     unext
    endcode
    
    EDIT: Actually, I could easily add an LMM style jmp in place of "mov IP", I don't know if there is one used already but I could just say "jmpl #fchlp"
  • D.PD.P Posts: 790
    edited 2016-07-21 14:31
    F32 ROM usage.

    Seems I'm missing something in usage of this ROM. I believe F32 is usually started in a cog, in Tachyon we do this:
    3 " F32     " LOADCOG
    

    And I thought from the assembler this should leave F32 running in the cog waiting for a :execCmd but I don't see it running in lscogs?

    So my question is how to use this in Tachyon, one simple example would help here. I do realize I need to pass appropriate params to the LOADCOG i.e. result, fa, fb but the syntax is escaping me here.

    Thanks
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2016-07-21 16:05
    lscogs only lists the cogs from the Tachyon perspective but it can't really tell what the cog is doing.

    The syntax for loading a cog is like this:
    vgapars 2 " VGA32x15" LOADCOG
    

    So you need to supply the parameter which is a pointer to the F32 command just as Spin does it:
    f32_Cmd := 0
      return cog := cognew(@f32_entry, @f32_Cmd) + 1
    

    So create a long and pass that like this:
    long f32cmd
    f32cmd 3 " F32     " LOADCOG
    

    Then test it with a simple float add which in Spin is:
    PUB FAdd(a, b)
      result  := cmdFAdd
      f32_Cmd := @result
      repeat
      while f32_Cmd
    

    But f32cmd looks like it is actually an address pointing to [result,fNumA,fNumB] which you could create with "3 longs result" where result is the command and the result.
    So setup the 3 longs first "cmdF+ result !" before pointing F32cmd to it like this "result f32cmd !"
    When f32cmd is set to zero then you can read the result.

    However I'm really tired so I'm not reading this well at the moment. I will get my head into it tomorrow.

    Actually, here's some quick test code to get you going:
    ( define some variables and constants )
    long f32cmd
    3 longs result
    result 4 +	== fnumA
    fnumA 4 +	== fnumB
    
    f32cmd 3 " F32     " LOADCOG  ( start up F32 )
    
    : FCMD ( n1 n2 cmd -- result )  result ! fnumB ! fnumA ! result f32cmd ! begin f32cmd @ 0= until result @ ;
    
    : >F ( n1  -- result )		0 $5CFC8E42 FCMD ;
    : F> ( n1 -- result )		1 $5CFCBE48 FCMD ;
    : F+ ( n1 n2 -- result )	$5CFC3C0D FCMD ;
    : F- ( n1 n2 -- result )	$5CFC3C0C FCMD ;
    : F* ( n1 n2 -- result )	$5CFC641F FCMD ;
    : F/ ( n1 n2 -- result )	$5CFC6233 FCMD ;
    : FSIN ( n1 -- result )		0 $5CFD72A2 FCMD ;
    : FSQR ( n1 -- result )		0 $5CFD006C FCMD ;
    ( test out a simple F+ 4095.761 + 4095.761 )
    $457FFC2E DUP F+ .LONG
    $457FFC2E DUP F+ $457FFC2E F- .LONG
    $BAC90FDC FSIN .LONG
    $457FFC2E DUP F* .LONG
    $457FFC2E DUP F* FSQR .LONG
    987 DUP * >F FSQR F> .[s][/s]
    
    Look in the Tachyon extras folder for a file called "F32 tests.fth"
    12345 DUP * . 152399025 ok
    12345 DUP * LAP >F LAP .LAP 37.200us ok
    LAP FSQR LAP .LAP 52.200us ok
    LAP F> LAP .LAP 37.400us ok
    . 12345 ok
    



  • lscogs only lists the cogs from the Tachyon perspective but it can't really tell what the cog is doing.
    .
    .
    .

    Okay thanks and goodnight


  • D.P wrote: »
    lscogs only lists the cogs from the Tachyon perspective but it can't really tell what the cog is doing.
    .
    .
    .

    Okay thanks and goodnight
    Yeah, I'm going to bed now but just did a quick speed test:
    12345 DUP * . 152399025 ok
    12345 DUP * LAP >F LAP .LAP 37.200us ok
    LAP FSQR LAP .LAP 52.200us ok
    LAP F> LAP .LAP 37.400us ok
    . 12345 ok
    
    
  • Wow, haven't been able to follow for a few days and a new Tachyon is born.
    Happy birthday TF3; ) congratulations
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2016-07-22 00:15
    proplem wrote: »
    Wow, haven't been able to follow for a few days and a new Tachyon is born.
    Happy birthday TF3; ) congratulations

    Still "TF1" or just plain "TF" as opposed to TF2, the P2 version but in retrospect (if you can call a few days that) I think you and MJB kicked this off. How so? Well I added the extra print functions and MJB got a little upset, as we do from time to time, and as I had been looking at the memory map previously to see where I could consolidate memory, I decided to try a few things.

    So I had always wondered whether I would save memory by reducing the size of the XCALL vectors that allow the kernel to call high level bytecode functions using just 2 bytes (XCALL + VECTOR). The vectors are needed to keep the source code simple and clean and still work with the Prop tool or BST but once Forth itself is compiling functions it can compile calls as 16-bits using 3 bytes which is what it does when the XCALL table is filled. When I made the changes and tried them out by compiling EXTEND, hardware headers, SDCARD, and EASYFILE I found I still ended up saving around 400 bytes so it seemed like the thing to do.

    But those compiled PASM images for the cogs were hogging a lot more memory than that even if some were reused as generous buffers. The VGA image is not used very often but quite handy and it had a small footprint, but it still takes up some memory, how to get rid of it and still have it but as we know you can't have your cake and eat it too, that's impossible! Well as soon as I told myself it was impossible then it became possible, I would use up memory with PASM images and then allow Forth to reuse that area when it does a backup to EEPROM as a backup normally avoids the PASM image for the kernel and console receive of course. So all I had to do was add some means for a Forth routine to scan for them in EEPROM (that part of RAM gets overwritten by EXTEND itself) and then save them in upper EEPROM - before a BACKUP. Then add some extra functions to find individual images by name and be able to launch them.

    So now we have V3.0 JUNO with a library of ROMs and floating point etc, and it all started with you and MJB, and then D.P "nagging" me about FP :)

    BTW, floating point really needs some way to enter and print fp numbers, so I will look into this soon. I also forgot that I had added LMM and methods too.

  • MJBMJB Posts: 1,200
    MJB wrote: »
    when doing this major revision,
    maybe you can change ACC to spicnt in SPIWR16,
    so it is consistent with the documentation and SPIWRX can be used as described,
    by loading 'n spicnt COGREG! ' before, which is very hard with ACC as it is now.
    @Peter ... may I bring up this little thing again ...
  • @MJB - I hadn't forgotten, just been busy with some other "little" things.
  • MJBMJB Posts: 1,200
    @MJB - I hadn't forgotten, just been busy with some other "little" things.
    while we are at little things ...

    I think FCREATE$ was not fully implemented yet ...
    e.g. Finding a free DIR entry and writing data there ..

  • MJB wrote: »
    @MJB - I hadn't forgotten, just been busy with some other "little" things.
    while we are at little things ...

    I think FCREATE$ was not fully implemented yet ...
    e.g. Finding a free DIR entry and writing data there ..

    It's been on my to-do list for a while but if you get it working then I'm fine with that too!

  • MJBMJB Posts: 1,200
    MJB wrote: »
    @MJB - I hadn't forgotten, just been busy with some other "little" things.
    while we are at little things ...

    I think FCREATE$ was not fully implemented yet ...
    e.g. Finding a free DIR entry and writing data there ..

    It's been on my to-do list for a while but if you get it working then I'm fine with that too!
    I think I'll wait ;-) - no urgent need
    - just saw it and wanted to remind you.

  • MJBMJB Posts: 1,200
    @Peter

    EXTEND.fth
    pri >UPPER  ( str1 --  ) --- Convert lower-case letters to upper-case
    
    should be pub ??

    IFDEF EXPLORER
    #22 MODULE: MCP3208_8_channel_ADC
    ( MCP3208 8 channel ADC )
    ...
    
    will not load ADC module, even if specified with LOADMODs, when NOT in EXPLORER mode.
    Maybe
    IFDEF EXPLORER 
         : INCLUDE $FFFFFFFF ;      --- include all for EXPLORER
    }
    
    or a specific list, would be a better option than the mix of MODULE and IF(N)DEF EXPLORER / SMALL ... like


    The a bit more verbous MODULE loader I started quite some time ago would take care of module dependencies, so if 17 has a prerequisite of 5 and 5 needs 3 then just specifying 17 would pull in all in the right sequence (i.e. as defined in EXTEND).
    Extend was just to much changing all the time to get a stable dependency matrix.
    This is not critical now, that we have sooo much more space.
    But Tachyon and applications will continue to grow.
    Good to know we can come back to this when space is getting full again.
  • @MJB - I have been using an alternate EXTEND which checks for IFDEF EXPLORER rather than a IFNDEF SMALL etc. Seems to be a lot better as I am trying to get away from specifying includes but EXPLORER could be set to include all.

    Those other minor things I can certainly fix.
  • MJBMJB Posts: 1,200
    @MJB - I have been using an alternate EXTEND which checks for IFDEF EXPLORER rather than a IFNDEF SMALL etc. Seems to be a lot better as I am trying to get away from specifying includes but EXPLORER could be set to include all.

    Those other minor things I can certainly fix.

    I was referring to yesterdays EXTEND.fth version ...
  • Cluso99Cluso99 Posts: 17,761
    Peter,
    Time to get my feet wet :)
    So some questions first.

    Can I just use Tachyon with an SD Card? As you probably know I have a Propeller OS that runs on SD Card. It uses FAT32 (also supports FAT16) and the EEPROM is loaded to boot into the OS on the SD Card. From there, using a terminal on P30/31 I can load any propeller binary file. So...
    * Can I load Tachyon V3 from the SD Card?
    * Does Tachyon require (any of) the lower 32KB of the EEROM? (upper 32KB is fine)
  • Tachyon is designed to work with a minimal system comprised of a Prop, a crystal, and a 32kB EEPROM although 64kB is more common and preferred. But the kernel that is compiled with the Propeller tool doesn't even know about EEPROM itself, so you could just load it into RAM but EXTEND.fth which is compiled by the Tachyon kernel itself has EEPROM utilities onboard so it can backup to EEPROM etc. Other modules that can be loaded include the SDCARD and EASYFILE FAT32 extensions.

    If you want a loader shell to load Tachyon then isn't that the same as any other binary? But if you want to build your own binary from the kernel as mentioned you need to be able to save it on the SD card which you can do with Tachyon itself. Once Tachyon knows how to access the SD card you can load source code into Tachyon from files directly.

    So to get started I would load in Tachyon into RAM then load in EXTEND.fth BUT just comment out the BACKUP at the end of the source if you don't want it overwriting your O/S. Before you do much more you may want to disable BACKUP by creating a dummy backup with : BACKUP ;
    Then create a hardware header file in the manner of QS.H etc that specify your SD pin assignments for instance after which you can load SDCARD and EASYFILE after which you can save your binary to the card although at present you need to create a dummy 64K file called FIRMWARE.ROM so that you can type SAVEROM instead of BACKUP to save the kernel image to the card. Of course you can use Tachyon to rename this file etc or whatever.

  • Cluso99Cluso99 Posts: 17,761
    edited 2016-07-24 04:58
    Peter,
    Where is V3.0 located (source as I will need to recompile since I currently am using a 12MHz xtal)?
    Found on your dropbox link. BTW your "Intro + links" links to V2.3.
    I can find v2.3 but not 3.0. I have (and use) bst.

  • Cluso99Cluso99 Posts: 17,761
    Created my board header
    TACHYON
    [~
    
    FORGET PX2.fth
    pub PX2.fth        ." P8XBlade2 HARDWARE DEFINITIONS 160724.0000 " ;
    
    --- Cluso's P8XBlade2 ---
    
    ( P8X32A PINOUTS )
    #P15    |< == &SDCS             '' SDCARD CS
    #P14    |< == &SDDI             '' Data to SDCARD 
    #P13    |< == &SDCK             '' SDCARD clocks  
    #P12    |< == &SDDO             '' Data out from SDCARD
    
    &SDCS >| #24 SHL &SDDO >| 16 SHL OR &SDDI >| 8 SHL OR &SDCK >| OR        == SDC
    
    ( PCB DEFINITIONS )
    \ Do what we need to do to init the hardware on this pcb
    pub !PCB
        &SDCS    OUTSET
        ;
    " P8XBlade2" 0 STRING PCB$
    #8888     == PCB
    
    ]~
    END
    

    I have downloaded the latest Tachyon V3.0 Juno from DropBox and after changing the xtal freq, compiled with bst and downloaded to my pcb. Get the Tachyon message OK.
    All good so far :)
  • Cluso99Cluso99 Posts: 17,761
    edited 2016-07-24 07:10
    I tried adding EXTEND.FTH but I get this error
    Tachyon V3.0 and Extend.fth both from dropbox (not the zipped file)
    ----------------------------------------------------------------
      Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160720.0000
     Cold start - no user code - setting defaults
    ----------------------------------------------------------------
      ok
    ( general set of includes when building an expanded TF with filesystem. )  ok
    : INCLUDE
    \
    \
    \
    \
    \
      %00_0000101001_1110010100_1101100000
    ;  ok
    CREATE SMALL  ok
    }  ok
    TACHYON   Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160720.0000
     ok
    0000  oktest V2.8 kernel or greater )
    0001  ok
    0002  ok
    0003  ok
    0004  ok
    0005  ok
    0006  okTEND.fth
    .....
    .....
    0080  ok
    0081  ok
    0082  ok
    0083  ok
    0139                     error in CREATE$ at WORD 1- C! word SWAP CMOVE (CREATE) *error*
    ----------------------------------------------------------------
    

    Presume I need to do something like "CREATE EXPLORER" but not sure how/where???
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2016-07-24 07:09
    That early in the load may simply be the fact that you need to set a line delay of around 20ms if you use TeraTerm as there isn't any effective handshake with serial ports these days (things are worse because of deep FIFOs).

    Send a break if you want to reset it.
  • Cluso99Cluso99 Posts: 17,761
    Still the same error. I tried editing the EXTEND.FTH file and changing CREATE SMALL to CREATE EXPLORER but that did not work either. Tried using a line delay of 100ms without success. Any ideas???
  • Never need more than 20ms but I will try a load myself just in case something got changed....back shortly
  • D.PD.P Posts: 790
    edited 2016-07-24 07:49
    I use 23ms line delay in minicom.

    115200 baud

  • My bad, I had been changing upper/lower case conflicts with some words in V3 as early on I had identical upper and lower case words and quite some time ago I allowed lower case to be used in searches so that if it failed to find a word it would then promote the searched term to upper case and try again, in which "case" it would succeed. But "word" is the variable for the word buffer whereas WORD is the declaration for a word variable, so I am in the process of changing some small things but I must have been interrupted at the time and I've been away from testing all weekend.

    Now, back into the saddle, tested out EXTEND and it is fine now.
  • I just rebuilt the world without error from current dropbox?
    2390  ok---  
    2391 
    
    00:00:00  End of source code, 2392 lines processed and 0000 errors found 
    Load time = 0.000us
    MODULES LOADED: 
    1787: EXTEND.fth          Primary extensions to TACHYON kernel - 160720-1500
    
    VER:    Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160720.0000
    FREQ:   80MHZ (PLLEN OSCEN XTAL1  PLL16X)
    NAMES:  $5B62...74C6 for 6,500 bytes (+3,861)
    CODE:   $0930...341B for 10,987 bytes (+7,316)
    RAM:    10,055 bytes free
    BUILD:  FIRMWARE BUILD DATE 000000:000000   BOOTS:  0   runtime 0
    BOOT:   EXTEND.boot ok
      ok
    IFDEF V3  ok
    ---   ok
    : SAVEROMS 
             " ROMS" U@ @NAMES 3 ANDN ' TACHYON 3 ANDN 
             DO I E@ OVER = IF CR PRINT" COPY ROMS @" I .WORD PRINT"  for " I 4 + E 
             4 +LOOP 
             DROP 
             ;  ok
    SAVEROMS 
    COPY ROMS @1738 for 6872 ok
    FORGET SAVEROMS  ok
    }  ok
      ok
    ?BACKUP  ok
      ok
    
    
Sign In or Register to comment.