Shop OBEX P1 Docs P2 Docs Learn Events
TAQOZ - Tachyon Forth for the P2 BOOT ROM - Page 7 — Parallax Forums

TAQOZ - Tachyon Forth for the P2 BOOT ROM

145791038

Comments

  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-05-17 07:31
    Tubular wrote: »
    So I'm trying to set up SD boot with P123-A9. I have a pullup on P60 (only)

    The SD card has _BOOT_P2.BIX and _BOOT_P2.BIY files in its root directory. I can see the cog start very briefly and then give up.

    The documentation indicates we don't have to change the MBR nor VOL sector at all, is this correct?

    Is there any particular reason the SD card failure just stops the cog, rather than dropping back to serial like flash does??

    This might be a good question to ask on Cluso's P2 ROM Booter thread
    . (I see he is using that thread for documentation instead :) )

    I believe that Chip wanted the Prop to cogstop if it failed SD but SD was before Flash and that was wrong so it was a last minute change to boot Flash, SD, and then supposed to try serial again. I wanted to have diagnostic POST style pulses or something on one of the pins so we could tell what happened, and then maybe shutdown after 10 seconds. The reason for the shutdown is to prevent batteries being drained.


    @Cluso99 - Your terminal configurations are all wrong, there are no extra line feeds from TAQOZ so please try a proper terminal first. They look like they are inserting LFs on a CR and LFs on LFs!!!!!! None of the terminals I use look anything like what you are showing. The long line of dashes is a "discard line" when TAQOZ discards anything that may have been compiled temporarily and also flushes the rx buffer. Whenever you hit an escape from the console it will do this as it does a CR only to return to the start of the line and then writes the dashes over it. Another good reason why terminals should not automatically insert line feeds.

    Four times I cancel and discard my input and so end up with 4 lines of dashes
    ----------------------------------------------------------------
      Parallax P2  .:.:--TAQOZ--:.:.  V1.0         
    ----------------------------------------------------------------
    TAQOZ# MOUNT 
    Mounted WIDGET      8C0D.A960-6338.6430 [SDSL08G]          FAT32    7,944MB (32kB/cluster)  ok
    TAQOZ# ls
    /WIDGET      
    DUMPV4  .FTH   EASYFILE.FTH   EASYNET .FTH   EXTEND  .FTH   LIFE    .FTH   
    LOVE    .WAV   POPCORN .WAV   SEEDAWN .FTH   SPLAT-V4.FTH   TACHYO~1.SPI   
    WARPEACE.TXT   ROM_136X.OBJ     ok
    ----------------------------------------------------------------  ok
    ----------------------------------------------------------------  ok
    ----------------------------------------------------------------  ok
    ----------------------------------------------------------------  ok
    TAQOZ#
    
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-05-17 08:10
    @Cluso99 - I've redirected the emit output to print the output in hex bytes through the output :)
    TAQOZ# : SHOWHEX  uemit W~ .BYTE SPACE ' SHOWHEX uemit W! ;  ok
    TAQOZ# 0 SHOWHEX 00 20 6F 6B 0D 0A 54 41 51 4F 5A 23 20 6C 73 69 6F 20 0D 0A 50 49 4E 53 20 0D 0A 50 3A 30 30 30 30 30 30 30 30 30 30 31 31 31 31 31 31 31 31 31 31 32 32 32 32 32 32 32 32 32 32 33 33 33 33 33 33 33 33 33 33 34 34 34 34 34 34 34 34 34 34 35 35 35 35 35 35 35 35 35 35 36 36 0D 0A 0D 50 3A 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 0D 0A 0D 3D 3A 7E 7E 7E 7E 64 64 64 64 64 7E 64 64 7E 7E 7E 7E 7E 7E 7E 7E 7E 7E 7E 7E 7E 7E 7E 7E 7E 7E 7E 7E 7E 7E 7E 7E 68 68 68 68 68 7E 64 7E 64 64 64 7E 7E 7E 64 64 64 64 64 64 7E 7E 68 7E 68 68 20 6F 6B 0D 0A 54 41 51 4F 5A 23 20
    
    Then I type in "lsio<CR>" while it is active and as you can see there are only single CRLFs in the output. The very first bytes that are printed are " ok"+CRLF

    Back to normal and do an lsio again:
    TAQOZ# lsio 
    PINS 
    P:00000000001111111111222222222233333333334444444444555555555566
    P:01234567890123456789012345678901234567890123456789012345678901
    =:~~~~ddddd~dd~~~~~~~~~~~~~~~~~~~~~~~~hhhhh~d~ddd~~~dddddd~~h~hh ok
    TAQOZ#
    

    edit: Perhaps I can remove the "PINS" header, so I patched my code and ran BACKUP into Flash.
    TAQOZ# ' lsio 4+ 7 $0D FILL  ok
    TAQOZ# lsio 
    P:00000000001111111111222222222233333333334444444444555555555566
    P:01234567890123456789012345678901234567890123456789012345678901
    =:~~~~ddddd~dd~~~~~~~~~~~~~~~~~~~~~~~~hhhhh~d~ddd~~~dddddd~~~~hh ok
    TAQOZ# BACKUP  ok
    
  • That LSIO command is really useful. It showed up the jaycar xc4598 SD breakout actually has some pulldown resistors on the back which were affecting things or at least explaining what was going on even without an SD card in the socket. I think those pulldowns are actually affecting the boot sequence contrary to the diagrams Cluso has put in his new thread.

    Using the P123-A9. Initially I thought perhaps the buttons PB1-3 might be causing issues but thanks to LSIO I see these are on P55-57 and out of the way. And PB0 does the reset.

    I generally use RealTerm which is working very nicely with current CR + LFs. I also have Putty, Teraterm and PST and can post some screen shots later from a PC perspective.
    711 x 442 - 50K
  • Cluso99Cluso99 Posts: 18,066
    Thanks Peter!
    Resetting TeraTerm to use CR (default) instead of CR+LF removes the extra lines.
  • ceptimusceptimus Posts: 135
    edited 2018-05-17 08:46
    There are a lot of fake FTDI chips in the wild. These often work very well, but when testing serial drivers and serial to USB converters, it's always worth trying to discover if your chip is a fake and trying several different converters from different suppliers - even though they appear to use exactly the same chip.
  • ceptimus wrote: »
    There are a lot of fake FTDI chips in the wild. These often work very well, but when testing serial drivers and serial to USB converters, it's always worth trying to discover if your chip is a fake and trying several different converters from different suppliers - even though they appear to use exactly the same chip.

    I wouldn't know about fake chips as I always get mine from Mouser/Digikey etc. But the fake chips are quite different as you can see from the link.

    @Cluso99 - much better, now change the font! I use Terminal regular 12 or Parallax font with a bright green text on dark green background, looks really good.
  • MJBMJB Posts: 1,235
    so how much free 'wasted' space is there left in ROM now?
  • MJB wrote: »
    so how much free 'wasted' space is there left in ROM now?
    I hope there is still enough space for me to squeeze in my LISP interpreter! :-)

  • Cluso99Cluso99 Posts: 18,066
    Last count there was 196 bytes or 48 instructions :smiley:
  • cgraceycgracey Posts: 14,133
    edited 2018-05-17 20:36
    Tubular wrote: »
    So I'm trying to set up SD boot with P123-A9. I have a pullup on P60 (only)

    The SD card has _BOOT_P2.BIX and _BOOT_P2.BIY files in its root directory. I can see the cog start very briefly and then give up.

    The documentation indicates we don't have to change the MBR nor VOL sector at all, is this correct?

    Is there any particular reason the SD card failure just stops the cog, rather than dropping back to serial like flash does??

    It's a one-way jump right now. We would have to do more integration work before he could jump back into my ROM code. Maybe we can get that straightened out over the next few days. This is Cluso's code that does the SD booting. I think we just need to agree on which registers need leaving-alone, so that a safe reentry can be made. This would blow up the timing for host systems that only wait 100ms for a connection to be made, but it would leave the door open for TAQOZ, the Monitor, and the Prop_??? commands.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-05-18 00:38
    Has anyone tried to follow along in my document and learn to use TAQOZ and play with the P2?

    How is it going?
    What improvements can I make to the existing examples?
    What things would you like to see added?

    I've tried to take it slowly and introduce new words and examples and also if a scope capture is appropriate I include a print friendly negative of it too.
    While this is a work in progress, it probably will be for quite some time but it is also very helpful for me in that I get to think about things I might change or add to TAQOZ in the next few days as I can submit an updated version for ROM. But then it is locked in!

    The time for real feedback is now! :)
    (Paragraph indentation and formatting are cosmetics, I'm talking content).

    Here's a sample from that document if you haven't yet clicked the link (and were afraid to do so).
    PWM%20SAMPLE.png

  • Has anyone tried to follow along in my document and learn to use TAQOZ and play with the P2?

    How is it going?
    What improvements can I make to the existing examples?
    What things would you like to see added?

    I've tried to take it slowly and introduce new words and examples and also if a scope capture is appropriate I include a print friendly negative of it too.
    While this is a work in progress, it probably will be for quite some time but it is also very helpful for me in that I get to think about things I might change or add to TAQOZ in the next few days as I can submit an updated version for ROM. But then it is locked in!

    The time for real feedback is now! :)
    (Paragraph indentation and formatting are cosmetics, I'm talking content).

    Here's a sample from that document if you haven't yet clicked the link (and were afraid to do so).
    PWM%20SAMPLE.png
    I started but didn't get very far before I had to head off to a meeting. I'll continue tomorrow. What I'm wanting to do is learn how to start code running on other COGs and communicate between COGs.
  • @"David Betz" - Thanks, since each cog has already been preloaded with a TAQOZ kernel and left idling you can run code very easily with this very simple example:
    TAQOZ# : BLINKER BEGIN 7 HIGH 100 ms 7 LOW 100 ms AGAIN ;  ok
    TAQOZ# ' BLINKER 1 TASK W!  ok
    

    I will expand a bit more on this and cog-to-cog communication as I enhance TAQOZ to take advantage of some of P2's features.
  • @"David Betz" - Thanks, since each cog has already been preloaded with a TAQOZ kernel and left idling you can run code very easily with this very simple example:
    TAQOZ# : BLINKER BEGIN 7 HIGH 100 ms 7 LOW 100 ms AGAIN ;  ok
    TAQOZ# ' BLINKER 1 TASK W!  ok
    

    I will expand a bit more on this and cog-to-cog communication as I enhance TAQOZ to take advantage of some of P2's features.
    I don't understand this. I know that
    ' BLINKER
    
    will put the code address of BLINKER on the stack. What does the rest of the line do?
    1 TASK W!
    
    I assume W! writes a word into the variable TASK? How does that cause the BLINKER code to run on another COG?

  • @"David Betz" - I will probably polish that a bit more by adding a RUN word but remember that TAQOZ is already running an idle loop in all other cogs. It is checking its task register addressed by TASK and COGID for a non-zero value which when set will cause it to call that address.
  • Cluso99Cluso99 Posts: 18,066
    MJB wrote: »
    so how much free 'wasted' space is there left in ROM now?
    There is ~160 bytes free now, and ~16,224 wasted ;)
  • @"David Betz" - I will probably polish that a bit more by adding a RUN word but remember that TAQOZ is already running an idle loop in all other cogs. It is checking its task register addressed by TASK and COGID for a non-zero value which when set will cause it to call that address.
    Does
    1 TASK
    
    return the address of the task register for COG 1?

  • MJBMJB Posts: 1,235
    David Betz wrote: »
    @"David Betz" - I will probably polish that a bit more by adding a RUN word but remember that TAQOZ is already running an idle loop in all other cogs. It is checking its task register addressed by TASK and COGID for a non-zero value which when set will cause it to call that address.
    Does
    1 TASK
    
    return the address of the task register for COG 1?

    there is a tasks array with 8 bytes per task.
    ' TASK ( cog -- addr ) Return with address of task control register in "tasks"
    TASK    word    _3,_SHL,_WORD,tasks,PLUS,EXIT
    
    here you see the specified cog# is shifted left by 3 == *8
    and then added with the tasks base address and left on the stack for the following W! to use.
    The 'thing' in front of a W! is not always the name of a variable,
    but could be anything generating the address to store a value to.

    so
    x TASK
    
    just indexes into the tasks array
  • MJBMJB Posts: 1,235
    @"Peter Jakacki"
    I see you using DO LOOP
    but in Tachyon 5 you were using the generalized FOR NEXT
    wouldn't it be good for the user to have the same mechanisms in TAQOZ that you will
    have in TACHYON, to avoid some confusion?

    It will take a few bytes more, but CLUSO99 said there are a few bytes free ;-)

  • MJB wrote: »
    @"Peter Jakacki"
    I see you using DO LOOP
    but in Tachyon 5 you were using the generalized FOR NEXT
    wouldn't it be good for the user to have the same mechanisms in TAQOZ that you will
    have in TACHYON, to avoid some confusion?

    It will take a few bytes more, but CLUSO99 said there are a few bytes free ;-)

    I had thought about that but time was pressing and other details needed my attention. Dropping DO LOOPs and enhancing FOR NEXT was for a couple of reasons sensible for the P1. In TAQOZ we could have both, including the enhanced FOR NEXT. I can do without DO LOOPs myself though but how have you found the new FOR NEXT when it comes to coding?

    BTW - It would actually save memory to remove DO LOOPs

  • MJB wrote: »
    David Betz wrote: »
    @"David Betz" - I will probably polish that a bit more by adding a RUN word but remember that TAQOZ is already running an idle loop in all other cogs. It is checking its task register addressed by TASK and COGID for a non-zero value which when set will cause it to call that address.
    Does
    1 TASK
    
    return the address of the task register for COG 1?

    there is a tasks array with 8 bytes per task.
    ' TASK ( cog -- addr ) Return with address of task control register in "tasks"
    TASK    word    _3,_SHL,_WORD,tasks,PLUS,EXIT
    
    here you see the specified cog# is shifted left by 3 == *8
    and then added with the tasks base address and left on the stack for the following W! to use.
    The 'thing' in front of a W! is not always the name of a variable,
    but could be anything generating the address to store a value to.

    so
    x TASK
    
    just indexes into the tasks array
    Yeah, that's what I figured. Thanks for confirming. There wasn't any other way that I could make sense of that line of code.

  • MJB wrote: »
    @"Peter Jakacki"
    I see you using DO LOOP
    but in Tachyon 5 you were using the generalized FOR NEXT
    wouldn't it be good for the user to have the same mechanisms in TAQOZ that you will
    have in TACHYON, to avoid some confusion?

    It will take a few bytes more, but CLUSO99 said there are a few bytes free ;-)
    I had thought about that but time was pressing and other details needed my attention. Dropping DO LOOPs and enhancing FOR NEXT was for a couple of reasons sensible for the P1. In TAQOZ we could have both, including the enhanced FOR NEXT. I can do without DO LOOPs myself though but how have you found the new FOR NEXT when it comes to coding?

    BTW - It would actually save memory to remove DO LOOPs

    The more code compatible TACHYON and TAQOZ are, the better !

    Jason
  • MJBMJB Posts: 1,235
    David Betz wrote: »
    MJB wrote: »
    David Betz wrote: »
    @"David Betz" - I will probably polish that a bit more by adding a RUN word but remember that TAQOZ is already running an idle loop in all other cogs. It is checking its task register addressed by TASK and COGID for a non-zero value which when set will cause it to call that address.
    Does
    1 TASK
    
    return the address of the task register for COG 1?

    there is a tasks array with 8 bytes per task.
    ' TASK ( cog -- addr ) Return with address of task control register in "tasks"
    TASK    word    _3,_SHL,_WORD,tasks,PLUS,EXIT
    
    here you see the specified cog# is shifted left by 3 == *8
    and then added with the tasks base address and left on the stack for the following W! to use.
    The 'thing' in front of a W! is not always the name of a variable,
    but could be anything generating the address to store a value to.

    so
    x TASK
    
    just indexes into the tasks array
    Yeah, that's what I figured. Thanks for confirming. There wasn't any other way that I could make sense of that line of code.

    as always -- if in doubt read the soure code ;-)
  • MJBMJB Posts: 1,235
    edited 2018-05-18 20:46
    MJB wrote: »
    @"Peter Jakacki"
    I see you using DO LOOP
    but in Tachyon 5 you were using the generalized FOR NEXT
    wouldn't it be good for the user to have the same mechanisms in TAQOZ that you will
    have in TACHYON, to avoid some confusion?

    It will take a few bytes more, but CLUSO99 said there are a few bytes free ;-)

    I had thought about that but time was pressing and other details needed my attention. Dropping DO LOOPs and enhancing FOR NEXT was for a couple of reasons sensible for the P1. In TAQOZ we could have both, including the enhanced FOR NEXT. I can do without DO LOOPs myself though but how have you found the new FOR NEXT when it comes to coding?

    BTW - It would actually save memory to remove DO LOOPs

    Actually I like the explicit nature of the new FOR loops.
    If I didn't use Tachyon for a while I always need to think which way the two DO arguments are.
    Mostly I used ADO anyway with LOOP.
    In
    10 BY 100 FROM 10 FOR I . CR NEXT
    
    it is pretty obvious
    Also I expect most users of TAQOZ to NOT be Forth users.
    So at least it sounds a bit like BASIC ;-) ... the wrong way round
    Pretty easy to learn

    And if it saves space you can use for SPLAT ;-) or s.th. useful ... great
  • Cluso99Cluso99 Posts: 18,066
    Peter, before I forget, when you pass control to me, you leave the other cogs running TAQOZ.
    Btw when I call you I jump to entry-TAQOZ as there is no need to reset smart pins from the monitor.
  • @MJB - I'd like to change TAQOZ over to the newer way of FOR NEXT loops but I've been pressed for time :) Maybe we can get another shot at it yet?

    If you need to know what your pins on your board are doing and also which pins are which you can use this simple PROBE word which continuous generates the same output as the lsio word but also uses P0 as a digital probe and will indicate the port it is connected to with a * instead. This uses CR to stay on the same line, another reason for CR and LF to do what they do.
    : PROBE
    	CRLF ." P:" 62 0 DO I 10 / . LOOP
    	CRLF ." P:" 62 0 DO I 10 // . LOOP
    	CRLF
    	BEGIN
    	  CR 3 SPACES 62 1
    	  DO I LOW 0 PIN@ NOT I HIGH 0 PIN@ AND I FLOAT
    	    IF ." *"
    	    ELSE
    	      I LOW 200 WAIT I FLOAT 200 WAIT I PIN@ 1 AND 2* ( 1 = pullup )
    	      I HIGH 200 WAIT I FLOAT 200 WAIT I PIN@ 1 AND ( 0 = pulldown) OR
    	      " d~ch" + C@ EMIT
    	    THEN
    	  LOOP
    	50 ms KEY UNTIL
    	;
    

    Here's the output with P0 probing P28:
    TAQOZ# PROBE2 
    P:00000000001111111111222222222233333333334444444444555555555566
    P:01234567890123456789012345678901234567890123456789012345678901
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~*hhhhhddhhhhhhhhhhhhhhdddddddd~~~~ ok
    

    This btw was tested on a DE2-115 and there is a DE2-115.FTH in the Forth folder that has words that know about the LEDs and switches etc. An external SD card works and a Flash chip in the socket on the Parallax breakout works fine too.
  • Where are we with the benchmarks now? Ok, so I dug out my old Fibonacci benchmark and ran it again:
    TAQOZ# : fibo ( n -- f )  0 1  ROT FOR BOUNDS NEXT DROP  ;  ok
    TAQOZ# 47 6 DO CRLF ." fibo(" I . ." ) = " I  LAP fibo  LAP .LAP ."  result =" . 10 +LOOP 
    fibo(6) = 685 cycles = 8.562us  result =8
    fibo(16) = 1245 cycles = 15.562us  result =987
    fibo(26) = 1805 cycles = 22.562us  result =121393
    fibo(36) = 2365 cycles = 29.562us  result =14930352
    fibo(46) = 2925 cycles = 36.562us  result =1836311903 ok
    

    If P2 is on-track for 180Mhz then this translates to a fibo(46) in TAQOZ of 16.25us
  • Very impressive benchmark numbers, Peter! (Although usually when we do a fibo benchmark we define it recursively rather than iteratively... but Forth is a kind of functional language already, so the iterative version is pretty natural.)Fastspin is a bit faster, but considering that it's compiling to native code the difference is remarkably small. It looks like the iterative fibo takes about 24 cycles/iterations with fastspin, vs. 56 cycles/iteration with Tachyon. That's a very low interpretation overhead.
    [ Entering terminal mode.  Press ESC to exit. ]
    fibo(6) 121 cycles, result = 8
    fibo(16) 361 cycles, result = 987
    fibo(26) 601 cycles, result = 121393
    fibo(36) 841 cycles, result = 14930352
    fibo(46) 1081 cycles, result = 1836311903
    
    Just for reference here's the code (for fastspin 3.8.3/spin2gui 1.0.3). Tachyon is a *lot* more compact than Spin, although perhaps not quite as easy to read :).
    OBJ
      ser: "SimpleSerial"
    
    PUB demo | i, n, t
      ser.start(115_200)
      repeat i from 6 to 46 step 10
        ser.str(string("fibo("))
        ser.dec(i)
        ser.str(string(") "))
        t := CNT
        n := fibolp(i)
        t := CNT - t
        ser.dec(t)
        ser.str(string(" cycles, result = "))
        ser.dec(n)
        ser.str(string(13, 10))
    
    PUB fibolp(n) : r | lastr
      r := 1
      lastr := 0
      repeat n-1
        (lastr,r) := (r, r+lastr)
    
  • ersmith wrote: »
    Very impressive benchmark numbers, Peter! (Although usually when we do a fibo benchmark we define it recursively rather than iteratively... but Forth is a kind of functional language already, so the iterative version is pretty natural.)Fastspin is a bit faster, but considering that it's compiling to native code the difference is remarkably small. It looks like the iterative fibo takes about 24 cycles/iterations with fastspin, vs. 56 cycles/iteration with Tachyon. That's a very low interpretation overhead.

    Hey, that's great to know how fast Fastspin is, so I guess it's fast! What a great plug for Fastspin and the P2. No more slow code! I'd be interested in a listing of the code that it generates.

    The fibo itself takes 16 bytes of code, but that is of course, on top of the supporting code it is built on.
    TAQOZ# ' fibo 16 DUMPW 
    022AE- FE00 FE01 007F 010B  007A 0124 0067 0061     '........z.$.g.a.' ok
    
    While the main part of the interpreter uses only 4 instructions for cog calls, the looping instruction NEXT uses stacked & latched branches so there is no reading and calculating branch addresses, just load and go.
    ' NEXT ( -- ) Decrement count (on loop stack) and loop until 0, then pop loop stack
    forNEXT         djz     index,#POPBRANCH                ' exit loop
            _ret_   mov     PTRA,branchadr                  ' loop again
    

Sign In or Register to comment.