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

19293959798109

Comments

  • Cluso99 wrote: »
    Before I dig in to make any suggestions/changes, I believe I need to get feel for why some things have been done the way they have. (PS I am not being critical here as I am in awe of what has been achieved)

    * All cogs are started and those effectively unused are placed in an LMM idle loop, waiting for a flag to start the doing something useful. Was there any reason for this?

    * Cogs are started by spin. The propeller boot rom requires the first program to be spin. Was there any other reason to start the other cogs in spin?

    * The Tachyon kernel resides in the lower 32KB of EEPROM. Was there any reason why the base kernel does not use the upper 32KB of EEPROM (for VGA/UART etc)? For cases where only 32KB EEPROM is present? Because that is the way it developed? Anything else?

    BTW I have always been impressed by Tachyon. Delving into it a little only impresses me more!

    Sorry, I've been sidetracked and meant to get back to you on your earlier post.
    No worries Peter. I am having fun looking at the code ;)
    In the meantime:

    1 - Initially spare cogs were loaded with Tachyon and left in an idle loop so that it would be a very simple matter of handing it something to start executing which it would do immediately. Also COGINIT will only be useful if you have a copy of the Tachyon image to load, which we don't as the memory is reused for buffers. These days with V3 this could be made to happen that way though.
    Yes, I understand that.

    2 - I never knew any better when I coded the first few parts of the kernel but I'm guessing that if I look at the boot rom source code I will see how I can tell it to run my code directly. The Spin boot is of course only a few lines before cog 0 is loaded over with the kernel.
    The boot rom must run spin first in a cog. Subsequently you can start PASM, but not directly. As you found, the spin can be extremely small.

    3 - Tachyon was designed so that it would only require a simple one step F11 in Prop tool to load and besides the Prop booter only supports the first 32k anyway. I wish the boot ROM did handle >32k loads but then Prop tool would need to be able to compile to these areas too :(
    When I first wrote Tachyon I didn't have file system stuff or Ethernet etc so I had so much memory I actually tested V1 with bitmap VGA graphics at the time. So I didn't have any need to squeeze memory or try to use upper EEPROM, that need came much later.

    Thanks for your comments Ray, maybe you would like to suggest a Spinless boot method?
    From my OS I can certainly run PASM code directly.
    But alas, from boot at least a minimal spin cog must run which can replace it with a PASM COGINIT.

    Probably best to just have at least spin start one cog which could then load all of Tachyon.

    A lot depends on what you want a minimal Tachyon system to be.
    * Serial, and/or screen/keyboard.
    * Do you require 64KB EEPROM or is 32KB ok? If 32KB what minimal configuration?
    * Do you want to require an SD card?
  • Cluso99 wrote: »
    Cluso99 wrote: »
    Before I dig in to make any suggestions/changes, I believe I need to get feel for why some things have been done the way they have. (PS I am not being critical here as I am in awe of what has been achieved)

    * All cogs are started and those effectively unused are placed in an LMM idle loop, waiting for a flag to start the doing something useful. Was there any reason for this?

    * Cogs are started by spin. The propeller boot rom requires the first program to be spin. Was there any other reason to start the other cogs in spin?

    * The Tachyon kernel resides in the lower 32KB of EEPROM. Was there any reason why the base kernel does not use the upper 32KB of EEPROM (for VGA/UART etc)? For cases where only 32KB EEPROM is present? Because that is the way it developed? Anything else?

    BTW I have always been impressed by Tachyon. Delving into it a little only impresses me more!

    Sorry, I've been sidetracked and meant to get back to you on your earlier post.
    No worries Peter. I am having fun looking at the code ;)
    In the meantime:

    1 - Initially spare cogs were loaded with Tachyon and left in an idle loop so that it would be a very simple matter of handing it something to start executing which it would do immediately. Also COGINIT will only be useful if you have a copy of the Tachyon image to load, which we don't as the memory is reused for buffers. These days with V3 this could be made to happen that way though.
    Yes, I understand that.

    2 - I never knew any better when I coded the first few parts of the kernel but I'm guessing that if I look at the boot rom source code I will see how I can tell it to run my code directly. The Spin boot is of course only a few lines before cog 0 is loaded over with the kernel.
    The boot rom must run spin first in a cog. Subsequently you can start PASM, but not directly. As you found, the spin can be extremely small.

    3 - Tachyon was designed so that it would only require a simple one step F11 in Prop tool to load and besides the Prop booter only supports the first 32k anyway. I wish the boot ROM did handle >32k loads but then Prop tool would need to be able to compile to these areas too :(
    When I first wrote Tachyon I didn't have file system stuff or Ethernet etc so I had so much memory I actually tested V1 with bitmap VGA graphics at the time. So I didn't have any need to squeeze memory or try to use upper EEPROM, that need came much later.

    Thanks for your comments Ray, maybe you would like to suggest a Spinless boot method?
    From my OS I can certainly run PASM code directly.
    But alas, from boot at least a minimal spin cog must run which can replace it with a PASM COGINIT.

    Probably best to just have at least spin start one cog which could then load all of Tachyon.

    A lot depends on what you want a minimal Tachyon system to be.
    * Serial, and/or screen/keyboard.
    * Do you require 64KB EEPROM or is 32KB ok? If 32KB what minimal configuration?
    * Do you want to require an SD card?

    FWIW a spin compiler can be avoided as we can handcode the tiny spin stub, if that is a desired outcome.
  • MJBMJB Posts: 1,192
    Cluso99 wrote: »

    A lot depends on what you want a minimal Tachyon system to be.
    * Serial, and/or screen/keyboard.
    * Do you require 64KB EEPROM or is 32KB ok? If 32KB what minimal configuration?
    * Do you want to require an SD card?

    really minimal: Prop + crystal + EEPROM (xtreme even just prop if you load to RAM, without crystal - don't know if Tachyon could do that - currently with the timers etc. looks like not.

    would be great if nothing else is mandatory.
    So currently this is minimal possible.
  • If the 12MHz RC oscillator were calibrated then we could always work with that, albeit slowly. Then again it is possible to autobaud too but some kind of reference is preferable, so for the speed and calibration reason we need a crystal. Other micros even like the little PIC12F1572s I use have a calibrated/trimmed 32MHz oscillator via the PLL.

    But yeah, Tachyon works on just a Prop and crystal and normally at least 32k EEPROM is available but not necessary. For larger systems all that is required is the 64k EEPROM which is standard these days even for Parallax.
  • Peter JakackiPeter Jakacki Posts: 9,714
    edited 2016-08-05 - 14:09:34
    Hmmm, I can pack almost everything, even the high level VGA driver, the filesystem, the WIZ5500 driver, plus the SPLAT logic analyzer. The SPLAT timing shows the VGA running. These extra modules were loaded directly from a sub-directory on the SD card.

    I just have to see how I can squeeze in a little more room for the network servers which normally fit without the extra baggage. So now I'm looking at a way to get even more out of the humble P1 by pushing past my previous goals. There's probably a lot of stuff I've already loaded that might never get used but I think I can manage to fit all this stuff in together at the same time and still have room for apps. There are even small apps that I compile and run directly from file too.

    JUNOVGAWIZ.png
    2248 x 2052 - 123K
  • Wow! Improving by the day!

    Are you now loading the cog drivers directly from SD card now? Does this mean Tachyon now requires an SD card?
    I can certainly help out here.

    BTW I have thought for some time that this is the WTG for big and usable prop designs.
  • D.PD.P Posts: 790
    edited 2016-08-05 - 23:39:39
    Seems the current build of Juno and Extend.fth is causing a system lock when I issue reboot now. I have to rebuild to get the console to respond again?

    But it's only when I uncomment the DS1302 stuff to include this?

    And here is the timing for DS1302.fth that works with the chip FYI.
  • D.PD.P Posts: 790
    edited 2016-08-05 - 23:41:45
    This is issuing
    #111111 DSTIME!
    


    ds1302.jpg
    2840 x 362 - 99K
  • D.PD.P Posts: 790
    edited 2016-08-06 - 00:25:06
    Okay, success. With the latest files and loading my driver thus:
    EXTEND
    EEWORDS
    run COMPACT
    run BACKUP
    DS1302mini.FTH
    SDCARD
    EASYFILE
    DLVR-L30D.FTH
    GARDENCONTROL.FTH

    Thanks for everything.
    MODULES LOADED: 
    5078: GARDENCONTROL.fth   Garden Control 151107 1530 V0.68          
    4F3A: DLVR-L30D.fth       DLVR-L30D PSI Sensor 151108.1400 V0.3 
    404F: EASYFILE.fth        FAT32 Virtual Memory Access File System Layer V1.2 16 
    3A1C: SDCARD.fth          SD CARD Toolkit - 150827.0000 
    39A5: P8Only.fth          P8 Only HARDWARE DEFINITIONS 141118.0000 
    376E: DS1302mini.fth      DS1302 RTC Mini 160802.2100 
    17C0: EXTEND.fth          Primary extensions to TACHYON kernel - 160805-0040
    344A: EEWORDS.fth         TACHYON EEPROM DICTIONARY 160805.2330 
    
    VER:    Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160804.1730
    FREQ:   96MHZ (PLLEN OSCEN XTAL1  PLL16X)
    NAMES:  $63A7...74D0 for 4,393 bytes (+896)
    CODE:   $0930...5E37 for 21,767 bytes (+3,519)
    RAM:    1,392 bytes free
    BUILD:  FIRMWARE BUILD DATE 160805:115105   BOOTS:  9   runtime 25,043
    BOOT:    ok
       ok
    SETDST 
    Setting Date: 160805
    Setting Time: 120635 ok
    ls
    Mounted 769A.5500-EE02.CFBC          NO NAME     FAT32   7,944MB (32,768/cluste)
    NO NAME    
    [SYSTEM~1]     LOG0001 .TXT   LOG0002 .TXT   LOG0003 .TXT   LOG0004 .TXT   
    LOG0005 .TXT   LOG0006 .TXT   LOG0007 .TXT   LOG0008 .TXT   ~1      .TRA   
    [TRASHE~1]     [SPOTLI~1]     [FSEVEN~1]     FIRMWARE.ROM     ok
    
    
    
    
  • Peter JakackiPeter Jakacki Posts: 9,714
    edited 2016-08-06 - 02:39:58
    @D.P. - the DS1302 stuff was a little incomplete but I supposed half-hearted in that I didn't really see it as a good RTC solution anyway. I did have a problem with COMPACT which turned out to be with the fact that I had renamed the "word" variable to "@word" so as not to conflict with WORD since Tachyon has performed auto-case conversion for some time now. The funny thing was that in EASYFILE immediately after "word" which was being translated to "WORD" was DUP but since WORD is immediate it created a word variable called DUP. You can imagine what havoc that played!

    However I will be changing a lot of these case conflicts such as here and HERE which were fine at the time when strict case had to be observed but I found that allowing lower case in place of upper case makes it easier to type interactively.

    Now there's a problem with !PCB in that once it has been COMPACTed it is not detected by the boot routine which scans the RAM dictionary so the easy way around that is just redefine it again in the RAM dictionary as ": !PCB !PCB ;"


  • @Peter,

    Good news then, the pursuit of older tech lead to a bug fix, of course you would have found this without a DS1302 sidetrack two too, ouch :)

    And I have a good working DS1302.fth module now as well.

    Also now I should be able to COMPACT much further down in the build chain now i.e. right before the main module I believe and that will get me back a few more KBytes.



  • D.P wrote: »
    @Peter,

    Good news then, the pursuit of older tech lead to a bug fix, of course you would have found this without a DS1302 sidetrack two too, ouch :)

    And I have a good working DS1302.fth module now as well.

    Also now I should be able to COMPACT much further down in the build chain now i.e. right before the main module I believe and that will get me back a few more KBytes.

    Looks as if your garden control is taking up around 3.5k of code memory. Care to share the code or some project details? What we need is a Tachyon project page/wiki/blog.

  • D.P wrote: »
    @Peter,

    Good news then, the pursuit of older tech lead to a bug fix, of course you would have found this without a DS1302 sidetrack two too, ouch :)

    And I have a good working DS1302.fth module now as well.

    Also now I should be able to COMPACT much further down in the build chain now i.e. right before the main module I believe and that will get me back a few more KBytes.

    Looks as if your garden control is taking up around 3.5k of code memory. Care to share the code or some project details? What we need is a Tachyon project page/wiki/blog.

    I agree peter! I was intrigued by D.P.'s garden control.fth program as I daydream about an semi-automated greenhouse, and would like to see what everyone is doing with your epic contribution.

  • MJBMJB Posts: 1,192
    Shawn Lowe wrote: »
    D.P wrote: »
    @Peter,

    Good news then, the pursuit of older tech lead to a bug fix, of course you would have found this without a DS1302 sidetrack two too, ouch :)

    And I have a good working DS1302.fth module now as well.

    Also now I should be able to COMPACT much further down in the build chain now i.e. right before the main module I believe and that will get me back a few more KBytes.

    Looks as if your garden control is taking up around 3.5k of code memory. Care to share the code or some project details? What we need is a Tachyon project page/wiki/blog.

    I agree peter! I was intrigued by D.P.'s garden control.fth program as I daydream about an semi-automated greenhouse, and would like to see what everyone is doing with your epic contribution.
    +1 currently I measure only temperatures, but eventually the irrigiation system and the solar system needs to be automated as well ...

    so I would be happy to offer my constructive 'critic' ;-)

  • MJBMJB Posts: 1,192
    D.P wrote: »
    @Peter,

    Good news then, the pursuit of older tech lead to a bug fix, of course you would have found this without a DS1302 sidetrack two too, ouch :)

    And I have a good working DS1302.fth module now as well.

    Also now I should be able to COMPACT much further down in the build chain now i.e. right before the main module I believe and that will get me back a few more KBytes.
    D.P I am wondering - there is a DS1302.fth module in Peter'S Dropbox\MISC MODULES folder ...
    did you extend this or write your own? - can you share your mods...

    @Peter I did not find the DS1302 word in yesterdays EXTEND.fth ?? is is somewhere else?

  • D.PD.P Posts: 790
    edited 2016-08-06 - 16:48:27
    MJB wrote: »
    D.P wrote: »
    @Peter,

    Good news then, the pursuit of older tech lead to a bug fix, of course you would have found this without a DS1302 sidetrack two too, ouch :)

    And I have a good working DS1302.fth module now as well.

    Also now I should be able to COMPACT much further down in the build chain now i.e. right before the main module I believe and that will get me back a few more KBytes.
    D.P I am wondering - there is a DS1302.fth module in Peter'S Dropbox\MISC MODULES folder ...
    did you extend this or write your own? - can you share your mods...

    @Peter I did not find the DS1302 word in yesterdays EXTEND.fth ?? is is somewhere else?

    The section in EXTEND.fth for the DS1302 needs to be un-commented and a couple text lines need to be commented for the DS1302 to be included.

    Yes I did that initial code for the DS1302. Here is a more current version.

    @Peter, I'm in the middle of a rewrite of GARDENCONTROL.FTH, just have a commented out version to check for compile of the new framework with Juno. Will post when I have it ported to the P8 only module, it's actually to control the EBB and FLOW cycles of a Aquaponics system offering different cycles for day and night modes. All parameters are held in the battery backed ram on the DS1302 so it recovers what it was doing during power outages, reboots and equipment failures. I wrote this long ago it seems and my forth/tachyon has improved somewhat since then.
  • D.PD.P Posts: 790
    edited 2016-08-08 - 06:38:46
    Okay, after not using COMPACT until all of the modules are loaded (except for the one I'm working on) there is now so much memory for me to waste on my DEADC0DE I can't believe it. This is fantastic! GARDENCONTROL.FTH builds on Juno and a P8 module now so just some more integration and I will post this up for code review.
      Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160804.1730
    
    VER:    Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160804.1730
    FREQ:   96MHZ (PLLEN OSCEN XTAL1  PLL16X)
    NAMES:  $7126...74D0 for 938 bytes (+138)
    CODE:   $0930...5099 for 18,281 bytes (+351)
    RAM:    8,333 bytes free
    BUILD:  FIRMWARE BUILD DATE 160807:233945   BOOTS:  1   runtime 83
    BOOT:   
    MODULES LOADED: 
    4F3A: DLVR-L30D.fth       DLVR-L30D PSI Sensor 151108.1400 V0.3 
    404F: EASYFILE.fth        FAT32 Virtual Memory Access File System Layer V1.2 16 
    3A1D: SDCARD.fth          SD CARD Toolkit - 150827.0000 
    17C0: EXTEND.fth          Primary extensions to TACHYON kernel - 160805-0040
    376E: P8Only.fth          P8 Only HARDWARE DEFINITIONS 141118.0000 
    37E4: DS1302mini.fth      DS1302 RTC Mini 160802.2100 
    344A: EEWORDS.fth         TACHYON EEPROM DICTIONARY 160805.2330 
    ROMS
    0848 VGA32x15  
    0236 HSSERIAL  
    1648 SIDEMU    
    1940 QUADUART  
    0196 MONO16    
    1900 F32       
    ----------------------------------------------------------------
    
    
  • Good stuff D.P. Do you know you can also run COMPACT incrementally too as it detects that it has already run and just appends to the eeprom.


    BTW, PCB$ and PCB are now predefined in EXTEND so that it can report on it, you just need to change these two instead of defining them like this:
    " P1432 +P8"  PCB$ $!
    #1432 TO PCB
    
  • MJBMJB Posts: 1,192
    D.P wrote: »
    Okay, after not using COMPACT until all of the modules are loaded (except for the one I'm working on) there is now so much memory for me to waste on my DEADC0DE I can't believe it.

    AFAIK you can COMPACT after each moule you load, if you like.
    You only leave the modules you work on uncompacted, so you have them in RAM dictionary and can FORGET them if you want to reload them.

    So even with NW loaded there is plenty of space for an application.
    And with the script execution non time critical code can be loaded, executed and forgotten, not consuming any RAM permanently.

  • MJB wrote: »
    And with the script execution non time critical code can be loaded, executed and forgotten, not consuming any RAM permanently.

    I timed loading a normal "script" to scan and display the background timers and to compile and run to completion took 441ms. Timing the code itself it takes 154ms to execute and sector read about 1.5ms so almost 300ms was needed to compile about 20 lines of code and forget it afterwards. Obviously a couple of lines of code will be much faster, a single line to print out all printable ASCII characters takes 44ms total.

    Create a file and open it:
    $8000 mk RUNME
    FOPEN RUNME

    Read/write access (from beginning) and insert by printing a string to the file:
    RW >FILE PRINT" CR $7F $20 DO I EMIT LOOP LAP CR .LAP\r\n" CON

    Manually open the file (after closing) so I can time the whole launch and execution:
    LAP " RUNME" FOPEN$ IF FINPUT THEN   ok
    CR $7F $20 DO I EMIT LOOP LAP CR .LAP 
     !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~
    44.713ms ok
    

    10ms of 44.7ms was actually printing out so it took around 34ms for a load and compile on a single line.
  • D.PD.P Posts: 790
    edited 2016-08-09 - 15:37:05
    With the current files in dropbox I am getting reboots initially after power on issuing the first "ls" or "DIR" ? After the reboot everything seems fine. Even if I issue a "mount" first or a
    "?SDCARD" after a power reset.

    Also after reboot I am getting a LONG on the stack initially, I think I missed that this was a "feature" of the Juno?

    Okay not with the files you just posted 2 minutes ago.

    EDIT: okay got up and plugged this project in and it works great all of a sudden, I have no clue but ignore this post UFN. But I need to find the post about the LONG after reboot
      Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160804.1730
    
    VER:    Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160804.1730
    PCB:    P5555 +P8 Only (5555)
    FREQ:   96MHZ (PLLEN OSCEN XTAL1  PLL16X)
    NAMES:  $71B0...74D0 for 800
    CODE:   $0930...512D for 18,429 bytes (+352)
    RAM:    8,323 bytes free
    BUILD:  FIRMWARE BUILD DATE 160809:005659   BOOTS:  46   runtime 85
    BOOT:   
    MODULES LOADED: 
    40D3: EASYFILE.fth        FAT32 Virtual Memory Access File System Lay 
    4FCD: DLVR-L30D.fth       DLVR-L30D PSI Sensor 151108.1400 V0.3 
    3A79: SDCARD.fth          SD CARD Toolkit - 160808.1330 
    17C0: EXTEND.fth          Primary extensions to TACHYON kernel - 16080
    37E2: P8Only.fth          P8 Only HARDWARE DEFINITIONS 141118.0000 
    3841: DS1302mini.fth      DS1302 RTC Mini 160802.2100 
    34B6: COMPACT.fth         TACHYON COMPACT EEPROM DICTIONARY 160809.13 
    ROMS
    0848 VGA32x15  
    0236 HSSERIAL  
    1648 SIDEMU                                                           
    1940 QUADUART                                                         
    0196 MONO16                                                           
    1900 F32                                                              
    ----------------------------------------------------------------      
    . 1397575506 ok                                                       
    ls                                                                    
    Mounted 769A.5500-1694.FF80          NO NAME     FAT32   7,944MB (32,)
    NO NAME                                                               
    RUNME                   
    
    
    
  • WOW! I am really impressed by the video on page 1! how much memory are you running? What hardware? Do you sell the hardware preloaded so I can configure the IP and put it on my network and play from there?
    Sorry, for the questions that are probably answered in the 95 pages of posts, but I wanted to give you kudos, and jump right in, if possible.
  • Hi hinv,

    Jump on in. Peter can commit on his hardware, but you can run Tachyon on any of the Parallax Propeller boards. 64K eeprom is best. For the TCP/IP stuff you need to add a Wiznet 5500 chip and the jack of course like THIS Peter also has some nifty hardware too, but just jump right in you will find help in this thread.
  • D.P wrote: »
    If someone wants to setup github then I don't have a problem with that, I just haven't bothered myself and I can continue to just do what I do and work with Dropbox although Dropbox is kinda handy and easy.

    I'll give it a go.

    Gonna grab core Tachyon Files now

    UPDATE:

    HERE is the link to the new Tachyon P1 GitHub Repository.

    Let me know if you want other files tracked. Would be nice to let me know when stuff changes somehow so I can keep the library current.

    If and when you want to try to pull and commit changes to GitHub let me know and I will grant the permissions.
    @D.P, I'm appreciating your initiative with githubbing tachyon and lately cloned the repository in a few seconds - this is really fine for linux users. Thanks for this base work D.P

    You questioned for further files to be added - although the file organization in the dropbox seems to be grown it is (!) an organization and our super developer and we all are already used to it.

    As long as the dropbox and github are coexisting, using the same structure eases exchange/copy of files and maybe is more attracting Peter to join ...

    Shouldn't we implement the compatible structure?
    Or should we reorganize completely as you already started?
  • proplemproplem Posts: 233
    edited 2016-08-10 - 22:11:44
    Hi there, current dropbox version: hardware: IOT5500, tried
    /usr/local/bin/bstc.linux -p 2 "./Tachyon V3.0 JUNO.spin"
    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 V3.0 JUNO
    Program size is 32656 longs
    Compiled 4162 Lines of Code in 0.123 Seconds
    We found a Propeller Version 1
    Propeller Load took 11.476 Seconds
    
    then
    minicom tachyon -b 115200 -D /dev/ttyUSB0 --color=on
    
    serial communication seems not to work - baud rate problem? any tips what's going wrong?
    Thanks, proplem
  • The kernel is configured to autodetect 5MHz or 10Mhz crystals but you have to activate the 96MHz configuration by using the ' comment trick before the { block comment then remove the ' comment from the 80MHz configuration.
    CON { *** CLOCK MODES *** }
    {
    _clkmode        = xtal1 + pll8x
    _xinfreq        = 10_000_000            ' <--- AUTOMATIC 5 or 10MHz operation change at boot
    sysfreq         = 80_000_000
    '}
    '{ 6MHZ CRYSTAL
    _clkmode        = xtal1 + pll16x
    _xinfreq        = 6_000_000
    sysfreq         = 96_000_000
    '}
    
  • proplem wrote: »
    D.P wrote: »
    If someone wants to setup github then I don't have a problem with that, I just haven't bothered myself and I can continue to just do what I do and work with Dropbox although Dropbox is kinda handy and easy.

    I'll give it a go.

    Gonna grab core Tachyon Files now

    UPDATE:

    HERE is the link to the new Tachyon P1 GitHub Repository.

    Let me know if you want other files tracked. Would be nice to let me know when stuff changes somehow so I can keep the library current.

    If and when you want to try to pull and commit changes to GitHub let me know and I will grant the permissions.
    @D.P, I'm appreciating your initiative with githubbing tachyon and lately cloned the repository in a few seconds - this is really fine for linux users. Thanks for this base work D.P

    You questioned for further files to be added - although the file organization in the dropbox seems to be grown it is (!) an organization and our super developer and we all are already used to it.

    As long as the dropbox and github are coexisting, using the same structure eases exchange/copy of files and maybe is more attracting Peter to join ...

    Shouldn't we implement the compatible structure?
    Or should we reorganize completely as you already started?

    Well we could use this tool. But I wanna make sure it's okay with Peter to do this. And I don't know how we could mark the submits with appropriate comments as needed. My original goal was to submit all the core files at the same time that build together and mark the submit comment appropriately. Guess we could mark each one of these as a release. I need to think more about this and boy does Tachyon move around alot, and fast.

  • D.P wrote: »
    Well we could use this tool. But I wanna make sure it's okay with Peter to do this. And I don't know how we could mark the submits with appropriate comments as needed. My original goal was to submit all the core files at the same time that build together and mark the submit comment appropriately. Guess we could mark each one of these as a release. I need to think more about this and boy does Tachyon move around alot, and fast.
    Ok I didn't know about such a tool - this could help. Hmm. I have just hobbyists knowledge of git but I think it's worth learning. And it enables to coworking with many participants. I built my own branch
    git checkout -b "proplem"
    
    and it seems to be possible to switch back to master and to merge. Are you experienced with git - maybe you could write a small handout to give direction? With that one could start and research to get further information on git.

    @Peter: 96 MHz was the right tip! Now kernel and EXTEND.fth are working. Uff. I'll try to run my statemachine again ...
  • proplemproplem Posts: 233
    edited 2016-08-11 - 19:32:09
    I'm a tachyon newbie but I don't how know often I C-a t d ed in minicom copied forth code pasted it and so on.
    I'm dreaming of feeding forth files to a tachyon kerneled system via command line. Maybe this could be done via x/y/zmodem or such a 30 years old technology. This manual fiddling is time consuming and retracts me from really interactive working with tachyon.
    Scriptable tachyon would be such an improvement! It would be easier to guide newcomers step by step a la "do
    sz EXTEND.FTH
    
    then
    sz this.FTH
    
    then
    sz that.FTH
    
    . The dependency problems we are facing could be solved with Makefiles as already mentioned here. We could automate all these manual steps. All these processes would be inherently documented. This would boost productivity like this:
    proplem@cheetah2 ~/prj/tachyon/git/Tachyon-P1 (git)-[proplem] % make iot5500  
    /usr/local/bin/bstc.linux -p 2 "./Tachyon V3.0 JUNO.spin"
    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 V3.0 JUNO
    Program size is 32656 longs
    Compiled 4162 Lines of Code in 0.133 Seconds
    We found a Propeller Version 1
    Propeller Load took 11.474 Seconds
    stty -F /dev/ttyUSB0 115200 nl1 -hupcl
    /usr/bin/time -f 'downloaded in %e seconds' -o /dev/stdout sh -c 'cat ./EXTEND.FTH > /dev/ttyUSB0'
    downloaded in 9.31 seconds
    
    The problem with this example is that setting serial comm parameters via stty don't work (for me) otherwise I could walk forward in this manner. zmodem/sz would return a code wether the download is successful - this would be a secure process. Or does anybody have an idea to achieve this in a similar way?
  • You may have noticed that I have cleaned up the Dropbox files somewhat to reduce the clutter so that I have placed all the sub-folders into "more" and then further reduce the base code files by merging six files into three, the three Es - EXTEND, EASYFILE, EASYNET plus the kernel and VGA.

    The only time you should be doing lots of copy and pasting is when you are building a system. During development and testing much of the work is interactive with the occasional copy from terminal back into editor. The interactive part allows you to test out methods and ideas and thereby simplify the code and have fun at the same time discovering new and simpler ways of doing things. It is quite usual too to copy&paste the app code but this is usually just a single file and the whole process takes but a few seconds so I don't really see the need for file transfer software. What I would like to see though is either a terminal with functions linked to scripts to paste files, but we have to remember that Tachyon is the compiler, not the PC.
Sign In or Register to comment.