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

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

18788909293109

Comments

  • I've upgraded the kernel so that we can have \n \r \t \$xx or any other character after the \ as passthrough.
    ." hello \"tachyon\"\r\nnew line\$05"
    
    hello "tachyon"
    new line ok
    Minicom2.7
    

    btw, the same applies to string literals such as " hello \"tachyon\"" PRINT$
    That's great - I will download current version as soon as possible.
  • MJBMJB Posts: 1,235
    edited 2016-07-17 14:01
    One of the first things I teach my students is the Pareto-principle or commonly known as 80/20 rule.
    This is another nice example of it in action.
    On the left the implementation of the basic ." word the literal PRINTSTRING.
    On the right the new version with the extensions to handle escaped characters like \n\r\t\...

    Nice how simple the basic code is and how much more is needed to handle this special extension.

    of course writing
    ." Hello\n\rWorld" 
    
    might look more familiar to C programmers than
    ." Hello" $0A EMIT $0D EMIT ." WORLD"
     \ or better
    ." Hello" CR  ." WORLD"
    
    and it saves 6 bytes, but costs around additional ~73 bytes in the extended kernel vs 29 bytes of the base code !!
    And this cost is there even if this feature will not be used.
    At todays memory sizes this is of course nothing to spend a second thought on.
    But on REALLY size restricted systems like the 32k Propeller it can be significant.

    So thanks Peter, looks great -
    AND this is the path that lead us to Windows (huge and full of functions which are rarely used/useful) ;-)

    Of course this could have been implemented as an optional extension as well.

    But windows had little problems since the HW was always growing fast -
    as is the new P2 vs. P1 ... memory size ;-)







    1325 x 473 - 226K
  • I'm so tempted to say goodbye to these forums sometimes...

    I, for one, would hate to see that happen Peter. I haven't learned Tachyon Forth yet, but I will. I am always intrigued by your posts, and grateful for your contributions to the Propeller community.

    Jon
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2016-07-17 16:06
    @MJB - don't fret, this is a useful feature at least for inserting double quotes and also for some control characters. I could decide not to implement the \n\r\t and save 30 bytes but have a look at all this memory that is just sitting around and that has nothing to do with code or dictionary.
    SERIAL BUFFERS
    0000.7100: ...BUFFERS .WORD...S..MAP..MAP....$100 MAP..0 $8000 DUMPL.A.BLKSIZ 4 * ...$*....S.$1234 DUP 2*.....S.$7F00 $100 i
    0000.7180: dth.0 $8000 DUMPA....Z.`.R...)=a.P.p.P=..R...)=a/.L\.Z=...|\.P}..Z...H....T\...h...h.R..6R.....d.R..9R...)=b..T\.
    
    FILE BUFFERS B
    0000.7200: BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
    <snip>
    0000.7980: BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBk
    
    VGA BUFFERS V (960bytes)
    0000.7A00: VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
    <snip>
    0000.7D80: VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
    FREE F (384 bytes)
    0000.7E00: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
    0000.7E80: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
    0000.7F00: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
    

    This is where I can gain more memory by examining where I can consolidate some of this buffer space such as combining the file buffers with the VGA in the second 1K section and save 1.4k. Trouble is this is the area that is reused after the coginits from the cog images for Tachyon, VGA, Serial/PingPong and I can only use them for buffers and not code or dictionary since we don't want to write over that original images in EEPROM when we do a BACKUP.

    If I get around to loading cog images into upper EEPROM then I can free up the lower memory but that introduces more complexities with compiling plus getting that image into upper EEPROM. What I need is to load all the cogs first and then load my 32k RAM unencumbered by cog images. Optimizing memory for the P1 is not easy though.

    @JonnyMac - I haven't left yet but I sure do hate walking around cold deserted streets in a rundown part of town where many have packed up and left long ago and those left over are rather sad and sorry looking getting rid of old stuff while others keep languishing and hanging out year after year waiting for the next big thing. The place may have plenty of history and old-timers hanging around eager to engage you in idle chit-chat or debates but the bub has gone from the hub.
  • D.PD.P Posts: 790
    edited 2016-07-17 16:53
    proplem wrote: »
    Hi there,
    (Tachyon) FORTH is really a language of enormous efficiency. As I'm always interested in reusing learned lessons I would like to (learn) program more in Forth. In a windows environment I'm looking for a solution to do some database access to a postgres database. I searched shortly and it seems that there are not many matches for these topics (search was "forth windows postgres"). Forth is a niche language.

    Before I spend more time in researching do you have experience with a forth in a windows/linux(/android/ios) environment which suits well with the tachyon paradigms and which you recommend?

    Well I use a few different database systems professionally; MS SQL, MYSQL, SYBASE ...
    And to access them all I tend to use RedBean, a lightweight Object Relationship Mapper and PHP. Use the right tool for the job in my view.

    But back to how cool Tachyon Forth is

    Here's a word that takes two parameters and transmits the "sentence" to a 4D Systems uLCD display via serial with checksum on the fly. Now I'm sure a brighter bulb could remove some swaps or dups but this works perfectly for my needs currently at 9600 baud.
    #ptx is the serial output pin constant and #wr_obj is just the write command constant
    : SDMSG ( val obj --  )
        #wr_obj DUP >L     \ loop stack as a checksum accumulator, first byte
        #ptx SEROUT             \ send write obj cmd
        W>B                     \ move obj into 2 byte msb top of stack
        DUP L> XOR >L           \ add byte to checksum
        SWAP                    \  need the other one
        DUP L> XOR >L           \ add other byte to checksum
        SWAP                    \ align bytes in proper order for transmission
        #ptx SEROUT             \ send first byte
        #ptx SEROUT             \ send second byte
        W>B                     \ move val into 2 bytes
        DUP L> XOR >L           \ add byte to checksum
        SWAP                    \ do the dance again
        DUP L> XOR >L           \ add byte to checksum
        SWAP                    \ align bytes in proper order
        #ptx SEROUT             \ send msb of val
        #ptx SEROUT             \ send lsb of val
        L> #ptx SEROUT          \ send checksum
    ;
    
    
    

    Easy and clean no?


    EDIT

    Took about 43.234 seconds before I got a "little bird" notice of a more Elegant implementation per Peter, THANKS.
    BYTE 4dsum
    : 4DO		DUP 4dsum C@ XOR 4dsum C! #ptx SEROUT ;
    : 4D		' 4DO uemit W! 4dsum C~ ;
    : SDMSG ( val obj --  )
        4D #wr_obj EMIT
        W>B EMIT EMIT
        W>B EMIT EMIT
        4dsum C@ EMIT
        CON
        ;
    

    EDIT timing
    LAP $2000 $1000 SDMSG .LAP 23.515secs ok         \  new routine
    LAP $2000 $1000 SDMSG1 .LAP 21.711secs ok       \ previous routine  
    

    Now it's not seconds but milli seconds?
  • D.PD.P Posts: 790
    edited 2016-07-18 01:47
    This has got me thinking how to dispatch incoming message and object events from the 4D uLCD systems.

    Let's just look at the object events
    6 serial bytes arrive
    <B><B><B><B><B><B>
    EventType byte
    object type high byte (i.e. button type)
    object type low byte (i.e. button instance )
    object value high byte
    object value low byte
    checksum byte

    Based on object type and instance I would dispatch to the proper word.

    Currently doing the dance with case statements and IFs, it's getting cluttered as the UI gets more complicated and new features are added based on user requests.

    The other message type is also 6 bytes. I'm trying to refactor the code base on Peter's previous example using a vector to handle the chksum calculation.




  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2016-07-18 02:08
    D.P wrote: »

    EDIT timing
    LAP $2000 $1000 SDMSG .LAP 23.515secs ok         \  new routine
    LAP $2000 $1000 SDMSG1 .LAP 21.711secs ok       \ previous routine  
    

    Now it's not seconds but milli seconds?

    You missed the lapping LAP after SDMSG and before .LAP.
    There's also the even simpler version I sent you too:
    : >4D ( sum ch -- sum )		>B SWAP OVER XOR SWAP #ptx SEROUT ;
    : SDMSG ( val obj --  )
        0 #wr_obj >4D
        OVER 8>> >4D SWAP >4D
        OVER 8>> >4D SWAP >4D
        DUP >4D DROP
        ;
    

    Here's the timing:
    LAP $1000 $2000 SDMSG LAP .LAP 6.988ms ok

    But that doesn't tell you much as the routine is caught up in bit-bashing 9600 baud serial. Here it is with say 250k baud
    LAP $1000 $2000 SDMSG LAP .LAP 377.166us ok

    and also
    400000 SERBAUD ok
    LAP $1000 $2000 SDMSG LAP .LAP 278.166us ok


    btw, LAP is a fast opcode unlike .LAP which is a high-level bytecode definition so LAP introduces minimal timing delays that are also measured and taken into account inside of .LAP
  • Properly skooled, thank you.

    I realized the timing wasn't gonna be close given 9600 baud.

    The hardest part of FORTH is thinking instead of just following the syntax of other languages.
  • D.P wrote: »
    Properly skooled, thank you.

    I realized the timing wasn't gonna be close given 9600 baud.

    The hardest part of FORTH is thinking instead of just following the syntax of other languages.

    I suppose that I end up being a "tutor" not simply because I know Tachyon but also because of the way I look at and reduce problems to a simple solution. Complex stuff is too complex for my little brain and I like simple solutions. It is amazing though the number of times I have had to tackle complex problems with complex specifications and standards that after doing the hard yards on it turns out to be quite simple after you cut through all that added complexity fluff ...... and even simpler when you reimplement it!

  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2016-07-18 23:02
    V2.10 testing for V3

    I've been working on a V2.10 which may just become V3 as I have found a way to precompile "ROMS" for cogs without losing any hub memory. Well, it's a trick and they are in memory when the kernel is first loaded but the cog images are in the free memory area between the end of the kernel bytecode and the low end of the dictionary (grows down). When I load up EXTEND.fth and just before it does a BACKUP to EEPROM it searches the EEPROM for "ROMS" and copies this whole area which may consist of several ROMS to >32k EEPROM. When we want to load a cog with a ROM we just specify the name and the cog to load like " VGA" 4 LOADROM or something like that. ROMs can also be stored on SD card, stacks of them in fact. Initially I have simply made the resident VGA driver a "ROM". Still a WIP but it shouldn't be long before it's all up and running fully.

    V2.10 was started initially to try to free up some more memory so I cut my vector table down from 2K to 1K and made adjustments elsewhere to keep it happy. I then loaded up EXTEND, a hardware header, SDCARD, and EASYFILE and compared the differences since less vectors means more calls will be compiled as 3 bytes vs 2 bytes. Anyway, even so, the newer version saved at least 400 bytes in this area alone. I also made changes so that we have NFA for a name field, a BFA for the bytecodes field address in the header, and CFA for the actual runtime code itself. Probably a few other things too but it's late/early now.
  • Excellent news, while there is basically unlimited memory for my needs in P2 I've often run out of memory in P1 and had to forgo using EasyNet which I would really like to get back in certain projects.
  • D.P wrote: »
    Excellent news, while there is basically unlimited memory for my needs in P2 I've often run out of memory in P1 and had to forgo using EasyNet which I would really like to get back in certain projects.

    Have you ever used COMPACT in EEWORDS to build a dictionary in upper EEPROM to free up space? I've got applications built on top of EASYNET because around 10k of RAM is freed up with the COMPACT operation. The dictionary may be in EEPROM but it's not slow as the words are hashed grouped into blocks read quickly into a buffer where searched words are maintained and freshened in a RAM cache with any newer words just building on top of that cache as a regular RAM dictionary. It is very similar in speed to a regular RAM dictionary search since it doesn't have to check every word in the dictionary, but after searching any new words in RAM and cache and if not found then the word is hashed which forms an index to 1 of 64 blocks that should contain the entry. So at the most it is a single EEPROM block read.
  • Yes I have used COMPACT and EEWORDS. It's my bloated code that I am refactoring rapidly as I move away from linear syntax style programming. It's a slog but I enjoy being a novice and learning new challenging things. I pity those stuck in the rut needing to always be the expert. FORTH/Tachyon is similar to chess for me, lots of moves, some just wrong, some more clever, some more lethal :)
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2016-07-19 09:11
    ROMS
    Now that I can put ROMS into the kernel code without consuming hub memory and available as runtime objects to load into cogs I just need to polish a little bit more to make it work.
    VER:    Propeller .:.:--TACHYON--:.:. Forth V300160719.0000
    FREQ:   96MHZ (PLLEN OSCEN XTAL1  PLL16X)
    NAMES:  $5BA4...74C6 for 6,434 bytes (+3,795)
    CODE:   $0930...338D for 10,845 bytes (+7,174)
    CALLS:  1 vectors free
    RAM:    10,263 bytes free
    BUILD:  FIRMWARE BUILD DATE 000000:000000
    BOOTS:  0
    BOOT:   EXTEND.boot
    POLL:   
    
    MODULES LOADED: 
    1787: EXTEND.fth          Primary extensions to TACHYON kernel - 160627-1200
    ok
    lsroms 
    1744 0848 VGA 32x15
    1AA4 0236 UART
    1BA0 1648 SIDEMU
    2220 1940 QUART
    29C4 0196 MONO16 ok
    
    

    So I could for instance load cog 4 with the SIDEMU with the command " SIDEMU" 4 LOADROM but there is also the matter of setup parameters that I need to work out.
  • V3 and ROMS in EEPROM (or SD)

    Things are looking good so far, after loading a kernel I can add EXTEND.fth which then automatically detects the ROMs in lower EEPROM and moves them into upper EEPROM before BACKUP which of course writes over the old image. Now I've been stepping through some of those ROMs which btw are simply just the PASM part of an object that normally gets loaded into a cog with coginit. One of the first ROMs I'm testing is the VGA32x15 text mode driver. The method is to pass the parameter, cog, and name to LOADCOG which scans the upper EEPROM and if found it will COGINIT the cog with this ROM.

    This is how I am loading up the VGA driver at present from within my code:
    vgapars 2 " VGA32x15" LOADCOG
    

    These are some of the ROMS I have already included:
    0848 VGA32x15  
    0236 HSSERIAL  
    1648 SIDEMU    
    1940 QUADUART  
    0196 MONO16
    

    The QUADUART is really just the 4-port full-duplex serial driver that I will have to test out next but the SIDEMU will be more fun.
  • MJBMJB Posts: 1,235
    edited 2016-07-20 00:11
    V3 and ROMS in EEPROM (or SD)

    Things are looking good so far, after loading a kernel I can add EXTEND.fth which then automatically detects the ROMs in lower EEPROM and moves them into upper EEPROM before BACKUP which of course writes over the old image. Now I've been stepping through some of those ROMs which btw are simply just the PASM part of an object that normally gets loaded into a cog with coginit. One of the first ROMs I'm testing is the VGA32x15 text mode driver. The method is to pass the parameter, cog, and name to LOADCOG which scans the upper EEPROM and if found it will COGINIT the cog with this ROM.

    This is how I am loading up the VGA driver at present from within my code:
    vgapars 2 " VGA32x15" LOADCOG
    

    These are some of the ROMS I have already included:
    0848 VGA32x15  
    0236 HSSERIAL  
    1648 SIDEMU    
    1940 QUADUART  
    0196 MONO16
    

    The QUADUART is really just the 4-port full-duplex serial driver that I will have to test out next but the SIDEMU will be more fun.

    wow - great progress
    now we can be more generous with a few bytes here and there ;-)

    and later those ROMs can be generated dynamically with the ASSEMBLER
    and written to SD ...
    so OBEX is coming

    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.


  • MJB wrote: »

    wow - great progress
    now we can be more generous with a few bytes here and there ;-)

    and later those ROMs can be generated dynamically with the ASSEMBLER
    and written to SD ...
    so OBEX is coming

    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.


    OBEX is what I was thinking about too. Although my fixed point math has gotten much much better without FP support in Tachyon, there are some standard saturated vapor pressure equations for wet/dry bulb RH measurement I would just prefer to let F32.asm handle in a single cog.

    Really neat Peter

  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2016-07-20 14:17
    D.P wrote: »
    OBEX is what I was thinking about too. Although my fixed point math has gotten much much better without FP support in Tachyon, there are some standard saturated vapor pressure equations for wet/dry bulb RH measurement I would just prefer to let F32.asm handle in a single cog.

    Really neat Peter

    F32 could easily be added and as I said I am still tweaking this version but so far, so good. Since this version frees up a lot of memory then this might be suitable for you to use even without compacting the dictionary. Don't forget you can also RECLAIM private words either globally or selectively and gain a bit more there too.

    EDIT: here's a quick little intro video on Dropbox where it loads up a VGA "ROM" and runs a demo (got cut short at the end)
  • Hey I saw that F32 in the listing! Nice work. Really look forward to V3. Dang and a peak at the workbench, nice and cluttered, getting stuff done!
  • nglordinglordi Posts: 114
    edited 2016-07-20 21:24
    Peter:

    I tried to download TACHYON V3.0 JUNO and received the following error message: Limit of 1024 DAT symbols exceeded.

    The load stopped at _UnitTrunc in the code.

    Nick


  • What hardware? P1 or P2
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2016-07-20 23:56
    nglordi wrote: »
    Peter:

    I tried to download TACHYON V3.0 JUNO and received the following error message: Limit of 1024 DAT symbols exceeded.

    The load stopped at _UnitTrunc in the code.

    Nick

    I'd been scratching my head trying to figure out what you were saying as a "download" is normally when we grab a file from somewhere else like the interweb thingy but it just dawned on me that you meant you tried to load the Prop, doh! (and I just had a coffee). I normally use BST which always works so much better than the Prop Tool but I just tried using Prop Tool and now I see what you mean. I'm not sure if I've got a way around it but can you try it with BST in the meantime (or just always)?

    I have a BST archive in my Tachyon tools folder and the version I like to use in linux is 19.4pre11 so give that a try. You can also get BST to generate a real listing which I normally copy from the listing window back into a Spin document so I can reference and search it easily.
  • Just a P1 version

    Loaded here correctly with BST as well. Extend is loaded too. Really nice Peter.
    00:00:00  End of source code, 2392 lines processed and 0000 errors found
    Load time = 7.187secs
    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@ .DEC I roms I 4 + E@ romsz MIN ECOPY LEAVE THEN
             4 +LOOP
             DROP
             ;  ok
    SAVEROMS
    COPY ROMS @1738 for 6872 ok
    FORGET COPYROMS COPYROMS not found   ok
    
    nglordi wrote: »
    Peter:

    I tried to download TACHYON V3.0 JUNO and received the following error message: Limit of 1024 DAT symbols exceeded.

    The load stopped at _UnitTrunc in the code.

    Nick

    I'd been scratching my head trying to figure out what you were saying as a "download" is normally when we grab a file from somewhere else like the interweb thingy but it just dawned on me that you meant you tried to load the Prop, doh! (and I just had a coffee). I normally use BST which always works so much better than the Prop Tool but I just tried using Prop Tool and now I see what you mean. I'm not sure if I've got a way around it but can you try it with BST in the meantime (or just always)?

    I have a BST archive in my Tachyon tools folder and the version I like to use in linux is 19.4pre11 so give that a try. You can also get BST to generate a real listing which I normally copy from the listing window back into a Spin document so I can reference and search it easily.

  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2016-07-21 00:14
    @D.P Just saw a tiny error there and fixed EXTEND as I was changing names and COPYROMS was changed to SAVEROMS (which it does) before they are obliterated in the first 32k when Tachyon does a BACKUP. So once SAVEROMS runs once it isn't needed anymore so we FORGET it before a backup (I don't want MJB breathing down my neck for wasting that handful of bytes now do I? :) )

    I still can't decide if I want to say LOADROM or LOADCOG because it loads a ROM but it also loads a cog but it is part of the ROM words..........sometimes choosing a good name takes longer than writing the word, it does, it does.

    note: I suppose that since these words extend the language it is important then to have good names unlike traditional compilers where it really_doesn't_matter_what_you_call_it!!!!! :)
  • acknowledged, just got the one posted 6 min ago now

    MJB can see your evil waste in the kernel now, beware :)
    00:00:00  End of source code, 2392 lines processed and 0000 errors found
    Load time = 6.559secs
    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@ .DEC I roms I 4 + E@ romsz MIN ECOPY LEAVE THEN
             4 +LOOP
             DROP
             ;  ok
    SAVEROMS
    COPY ROMS @1738 for 6872 ok
    FORGET SAVEROMS  ok
    }  ok
      ok
    ?BACKUP  ok
      ok
      ok
      ok
    
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2016-07-21 00:20
    @D.P - btw, you can load F32 into a cog with a suitable parameter and start testing it if you like. I still need to get a round tuit as these PASM drivers still need an interface at the Forth level but the Spin code should give you a good guide.

    btw again, EXTEND now has a default of a smaller build so I don't have to worry but I suppose what I should really do is get rid of the SMALL word and CREATE LARGE or EXPLORER to specify a larger build than the default.
  • Okay I'll see what trouble I can get into with my vapor pressure math

    Tachyon 100 Club ( 100 pages on the forums or bust) :)
      Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160720.0000
    
    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:  1   runtime 35
    BOOT:   EXTEND.boot
    MODULES LOADED:
    1787: EXTEND.fth          Primary extensions to TACHYON kernel - 160720-1500
    ROMS
    0848 VGA32x15
    0236 HSSERIAL
    1648 SIDEMU
    1940 QUADUART
    0196 MONO16
    1900 F32
    
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2016-07-21 00:22
    D.P wrote: »
    Okay I'll see what trouble I can get into with my vapor pressure math

    Tachyon 100 Club ( 100 pages on the forums or bust) :)
      Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160720.0000
    
    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:  1   runtime 35
    BOOT:   EXTEND.boot
    MODULES LOADED:
    1787: EXTEND.fth          Primary extensions to TACHYON kernel - 160720-1500
    ROMS
    0848 VGA32x15
    0236 HSSERIAL
    1648 SIDEMU
    1940 QUADUART
    0196 MONO16
    1900 F32
    

    100 pages of "code" !!! Sounds good ;)
    Just detail your F32 tests, that'll help.

  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2016-07-21 00:29
    D.P wrote: »
    Hey I saw that F32 in the listing! Nice work. Really look forward to V3. Dang and a peak at the workbench, nice and cluttered, getting stuff done!

    That's supposed to be the clean area of my PC bench but that's also where I have test equipment on the shelf above. Now if I panned around the workshop you would see that I am surrounded by benches as the one in front of me continues to the right over to the corner where I do my soldering, then all the drills and grinders etc then over to a wall of parts drawers, then a wall of parts shelves and then there is the island bench right behind so I can swivel around and work from there too. Somewhere in between all the benches and shelves and equipment I have some room to move :) I will have to give you some sneak peeks at other areas when I do a proper V3 video.
    (darn.....where's that phone of mine, put something down on the bench and it disappears.....)

  • D.PD.P Posts: 790
    edited 2016-07-21 06:41
    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.
    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 250,188
    BOOT:   EXTEND.boot
    MODULES LOADED: 
    1787: EXTEND.fth          Primary extensions to TACHYON kernel - 160720-1500
    ROMS
    0848 VGA32x15  
    0236 HSSERIAL  
    1648 SIDEMU    
    1940 QUADUART  
    0196 MONO16    
    1900 F32       
    ----------------------------------------------------------------
    " F32" FINDROM . 0 ok
      ok
    
    
Sign In or Register to comment.