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

TAQOZ - Tachyon Forth for the P2 BOOT ROM

1232426282938

Comments

  • I started a git repo : https://github.com/speccy88/TAQOZ/blob/master/docs/guide.md
    The goal of the repo was for everyone to contribute. Feel free to ask to become a collaborator or submit a pull request!

    It would be nice to have a cheat sheet like that one : http://flashforth.com/ff5-sheet.pdf
  • FredBlaisFredBlais Posts: 370
    edited 2019-04-08 11:50
    @"Peter Jakacki" by the way, I started working on making a custom terminal for communication with Taqoz using Python prompt toolkit. It features word autocomplete, command history and I would like to support file sending.

    It could be useful to switch to a mode where we can write a full line before sending to Taqoz. A typo can get frustrating if we hit space too fast.

    What autocomplete looks like :
    https://python-prompt-toolkit.readthedocs.io/en/stable/_images/ptpython-2.png
  • @FredBlais - Yes, a cheat sheet as a quick reference would be great. There's also no reason why we can't drop into line edit mode with history backup for interactive use. The word by word compile is great for compilation speed but I think we can afford some memory for a text input buffer for interactive mode. I imagine that we could have history for the last ten lines easily. I think the reason that I'm holding off gitin is because while it will be good once we have several contributors, it is more of a bother for me in the meantime.

    BTW, I've been using memory load mode with block mode compilation ( TAQOZ..END) where it saves all the text into upper RAM before processing it so it is much faster since there isn't any line delay necessary.
  • MJBMJB Posts: 1,235
    The compact version of TAQOZ in ROM is mainly for hardware debugging but of course could also be used to program the prop without any other tools other than a terminal and perhaps an editor.

    The TAQOZ in taking about is the extended version that will go on being extended. When i said it is not one of the P2 languages, i meant it is not mentioned officially. When i question the future of it, this had to do with how it is to be used. If i am the only one writing and documenting and using it then it doesn't make any sense to waste all that extra effort catering for users and trying to promote it.

    I see that my commercial products will take up a lot of my time and i could just concentrate on that. Is anybody actually interested in using it? I see lots and lots of excitement over various languages but I'm primarily interested in what i can do with the P2.

    Hi Peter,
    I am sitting here on the sideline watching until there is a P2D2 with motherboard from you (with Internet via WiZ5500/ESP32)
    ... with the final P2 on it until I will have HW to play with and being able to contribute.
    But no commercial projects from me.

    My workhorse will still be P1+Tachyon for most things as this is powerful enough.

    And as you I am really wondering how much is going on in the C-Threads and
    how few seem to pick up TaqOS for real work, as it is clearly the most
    powerful P2 programming environment to date.

    People would not even be at the mercy of a compiler writer
    having access to the full TaqOS source - thank YOU
    being in FULL control of all there is happening.




  • MJB wrote: »

    Hi Peter,
    I am sitting here on the sideline watching until there is a P2D2 with motherboard from you (with Internet via WiZ5500/ESP32)
    ... with the final P2 on it until I will have HW to play with and being able to contribute.
    But no commercial projects from me.

    My workhorse will still be P1+Tachyon for most things as this is powerful enough.

    And as you I am really wondering how much is going on in the C-Threads and
    how few seem to pick up TaqOS for real work, as it is clearly the most
    powerful P2 programming environment to date.

    People would not even be at the mercy of a compiler writer
    having access to the full TaqOS source - thank YOU
    being in FULL control of all there is happening.

    Ditto, except maybe a commercial giant Australian crayfish aquaponics controller :wink: Yes I am raising blue claws.
  • Just steering a TAQOZ topic back into the general TAQOZ thread.............

    TAQOZ, like Tachyon for the P1, allows console input and output to be redirected easily, it's just a matter of setting the ukey and uemit vectors. Normally these two vectors are set to zero to indicate to the KEY and EMIT routines to use the default serial I/O but if non-zero then TAQOZ uses the 16-bit address to execute wordcode in place of the default serial.

    So it is quite normal that TAQOZ is redirected, for instance the VGA text driver mode in the RAM version redirects console output to VEMIT etc.

    If you create a simple blocking on send mailbox word that captured all the output, it might be as simple as this:
    word inbox --- simple inbox, any non-zero is received as a character (use $100 etc to send a null)
    --- simple receive routine reads the inbox and only clears it when it is non-zero (avoids r/w clash)
    : GETMAIL ( -- char )   inbox W@ DUP IF inbox W~ THEN >B ;
    
    word outbox
    --- simple blocking send routine will wait until the outbox is externally cleared before sending
    : SENDMAIL ( char -- )  BEGIN outbox W@ 0= UNTIL $100 OR outbox W! ;
    
    --- redirect all input and output to a mailbox 
    : MAIL    ' GETMAIL ukey W! ' SENDMAIL uemit W! ;
    

    TAQOZ input via KEY is normally non-blocking in that it returns with a null if there is nothing. Default serial pins can be left as they are or the smart pins disabled (WRPIN #0,pin in assembly)
  • msrobotsmsrobots Posts: 3,701
    edited 2019-07-07 09:20
    Ahh, thank you @"Peter Jakacki",

    that gives me something to try.
    Now where is that mailbox in HUB or how can I set/find the addresses?

    I have TAQOZ running at its default location and leave 0-32K HUB untouched by my program. I can send your code via pins before I release them.

    But where in HUB I find the mailbox(es) to use them from another COG with PASM. I think we are very close here to solve my problem, I even seem to understand the TAQOZ code...

    please bear with me, now, and give me the last needed hint to get this running...

    and yes I will need to disable the original serial console in TAQOZ so the pins are free for the rest of the P2.

    Mike
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2019-07-07 09:34
    Mike, TAQOZ variables are normally created in a separate data area and advance a data pointer. It is easy to find out where these are if you simply copy and paste the MAILBOX code and then use the REPL:
    TAQOZ# inbox .L $0000_ED64 ok
    

    However instead of specifying inbox and outbox as variables, you could just as easily define them as constants that point to wherever in memory you want, like this:
    $7.FFFC := inbox
    $7.FFFE := outbox
    
  • msrobotsmsrobots Posts: 3,701
    edited 2019-07-07 10:11
    OK, that is even better.

    so I can define the addresses like this.

    $HUBADDRESSin := inbox
    $HUBADDRESSout := outbox

    then define the words GETMAIL and SENDMAIL using the word variables inbox and outbox. And define a word MAIL to redirect to my mailbox.

    and then redirect the I/O via a simple
    MAIL

    ?

    I need to send one script to redirect TAQOZ while still using pins and then start my main program in COG 1 having all pins as without TAQOZ in COG0

    so that could be this?
     --- simple inbox, any non-zero is received as a character (use $100 etc to send a null)
    $7.000 := inbox
     --- simple outbox, waits until external cleared
    $7.002 := outbox
    --- simple receive routine reads the inbox and only clears it when it is non-zero (avoids r/w clash)
    : GETMAIL ( -- char )   inbox W@ DUP IF inbox W~ THEN >B ;
    --- simple blocking send routine will wait until the outbox is externally cleared before sending
    : SENDMAIL ( char -- )  BEGIN outbox W@ 0= UNTIL $100 OR outbox W! ;
    --- redirect all input and output to a mailbox 
    : MAIL    ' GETMAIL ukey W! ' SENDMAIL uemit W! ;
    MAIL
    

    and if I still have serial I could switch between Mailbox and serial by entering
    CON
    or
    MAIL
    ?

    I need to try this out tonight. This is absolutely cool.

    Please tell me if I could finally read the code and get it.

    Mike
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2019-07-07 13:15
    Mike, this is what Tachyon on the P1 does for its ping-pong intercom networking in that it uses a mailbox in unison with the serial console. The idea here is that once a device is selected then it activates the blocking mode of the outbox and so whatever the console is sending serially it is also sending through the outbox which is "ponged out when it is pinged" over the virtual full-duplex console.

    Anyway, back to this mailbox for the P2. Although TAQOZ can be switched to use MAIL instead of serial at power-up, we still need to think how we are going to load your other software first as this is the real problem, and the mailbox is dead simple as you can see. TAQOZ in ROM loads up into the first 64kB and then relocates the dictionary etc so I guess your software could load up first and then call the TAQOZ startup in another cog perhaps? I haven't tried it but I will have to look at the methods.

    TAQOZ in ROM is limited although it has packed a lot into 12kB but as you know I mentioned I superloaded unoptimized TAQOZ and it takes less than 32kB so it's a pity that we couldn't have 32k ROM because then a bare chip would be super awesome right from boot. I say this because you may need to load in the RAM version of TAQOZ rather than use the ROM which in itself is very good for debugging hardware.
  • Cluso99Cluso99 Posts: 18,066
    Yes, I agree that the ROM version of TAQOZ should only be used if you cannot load the full blown version which has heaps of bells and whistles.

    It would be great to be able to call the soft TAQOZ with simple one liners. Then perhaps we can get to grips with TAQOZ by asking peter to help us with some of those one liners. It’s such a shame for peter to have done all this super work and not used because we can’t seem to come to grips with it.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2019-07-07 15:06
    I'm never sure where the problem is with understanding a simple one-liner in Forth. I think maybe this might even be tied in with the English language and how spoken languages affect the way we think whereas it is not unusual for non-native English speakers to know at least 2 or 3 languages. Forth seems to be used more in Germany and other parts of Europe and in Taiwan. The other impediment is simply that many tend to think in terms of the way that they have been taught "programming" in that you write top down with braces and brackets etc and every line needs to be parsed by the compiler and optimized into something that might look totally different. So while the abstraction is useful, the compiler is in charge and you must obey its rules.

    There is no such abstraction with Forth, what you see is what you get. Just read it as you would assembly language, a mov is a mov, an add is an add, there is no substitution etc. So if we take a Hello World and make it into a word called HELLO, we can SEE how it compiled:
    TAQOZ# : HELLO 10 FOR CRLF PRINT" Hello World!" NEXT ; ---  ok
    TAQOZ# HELLO --- 
    Hello World!
    Hello World!
    Hello World!
    Hello World!
    Hello World!
    Hello World!
    Hello World!
    Hello World!
    Hello World!
    Hello World! ok
    TAQOZ# SEE HELLO
    
    D895: pub HELLO
    6D8E: F80A     10
    6D90: 0118     FOR
    6D92: 12AA       CRLF
    6D94: 148E       PRINT" Hello World!"
    6DA4: 0127     NEXT
    6DA6: 004D     ;
          26 bytes 
     ---  ok
    TAQOZ# 
    

    Notice the one-for-one correspondence with every Forth word and what is compiled, just like assembly, which it is, for the Forth VM.

    Anyway, I've never had any trouble with writing Forth, only with not understanding why many find it too hard, although I have trouble reading some Forth code I've seen from others. However I know the problem there is that they are not thinking Forth, they are simply translating code or their own thinking into Forth code which does not enforce any real syntax or structure. No paint by numbers, it's more like a blank canvas and colors that you can use in a variety of undiscovered ways, you can make it a work of art, or a mess. Forth is meant to be used to shape Forth itself, it is the palette you paint with.

    EDIT: perhaps even this Hello World which shows how words become part of the "language/compiler"
    TAQOZ# : HELLO PRINT" Hello World!" ; ---  ok
    TAQOZ# : HELLOS  FOR CRLF HELLO NEXT ; ---  ok
    TAQOZ# 5 HELLOS --- 
    Hello World!
    Hello World!
    Hello World!
    Hello World!
    Hello World! ok
    TAQOZ# SEE HELLOS
    
    D91B: pub HELLOS
    6C7A: 0118     FOR
    6C7C: 12AA       CRLF
    6C7E: 6C68       HELLO
    6C80: 0127     NEXT
    6C82: 004D     EXIT
          10 bytes 
     ---  ok
    TAQOZ# SEE HELLO
    
    D924: pub HELLO
    6C68: 148E     PRINT" Hello World!"
    6C78: 004D     EXIT
          18 bytes 
     ---  ok
    TAQOZ#
    
  • ErNaErNa Posts: 1,738
    Hello Peter, I think it's not the language, it's the stack concept and that you have to unfold procedure calls so excution can take place without brackets. We learn to implement a logical structure using a logic elements, like nand, or, and which bring some inputs to one output or using relays, which bring one input to some outputs. In PLC there are two parties, one using instruction lists the other using function blocks. And they both are right.
  • Cluso99Cluso99 Posts: 18,066
    TAQOZ# : HELLO 10 FOR CRLF PRINT" Hello World!" NEXT ; --- ok

    To me this is even confusing.

    I get you are making this a new word (subroutine) "HELLO"

    I get that its going to repeat FOR 10 times and where the next is placed, and I know from past info the 10 comes before the FOR

    But then the CRLF and Print"Hello World!" are reversed. OK writing this down I think I get that yes everything is backwards in forth so the message comes first, then the crlf. But when I looked at the whole line, I couldnt see why crlf and the print were not reversed.

    Trouble is, you cannot just read the whole line backwards, just parts of it :(
  • msrobotsmsrobots Posts: 3,701
    edited 2019-07-07 23:34
    Mike, this is what Tachyon on the P1 does for its ping-pong intercom networking in that it uses a mailbox in unison with the serial console. The idea here is that once a device is selected then it activates the blocking mode of the outbox and so whatever the console is sending serially it is also sending through the outbox which is "ponged out when it is pinged" over the virtual full-duplex console.

    Anyway, back to this mailbox for the P2. Although TAQOZ can be switched to use MAIL instead of serial at power-up, we still need to think how we are going to load your other software first as this is the real problem, and the mailbox is dead simple as you can see. TAQOZ in ROM loads up into the first 64kB and then relocates the dictionary etc so I guess your software could load up first and then call the TAQOZ startup in another cog perhaps? I haven't tried it but I will have to look at the methods.

    TAQOZ in ROM is limited although it has packed a lot into 12kB but as you know I mentioned I superloaded unoptimized TAQOZ and it takes less than 32kB so it's a pity that we couldn't have 32k ROM because then a bare chip would be super awesome right from boot. I say this because you may need to load in the RAM version of TAQOZ rather than use the ROM which in itself is very good for debugging hardware.

    As said a couple of times now, loading other software first is solved. I basically patch the fastspin generated PASM to not load at HUB $400 but HUB $10400 and start in COG1 not COG0, So it leaves the first 64K alone and jmps COG0 into the ROM to start TAQOZ after patching the ROM a bit to allow ser coms over a second pair of smart pins.

    Currently I patch a lot of ROM to allow bi-directional serial coms to TAQOZ and Monitor, but I might be able to reduce that since I would just need to patch TAQOZ RX and send the redirect to Mailbox code.

    From then on I could use the mailbox and free the pins.

    This "TAQOZ in ROM loads up into the first 64kB and then relocates the dictionary etc" is a bit unclear to me, what HUB memory TAQOZ needs besides the first 64K?
    Cluso99 wrote: »
    Yes, I agree that the ROM version of TAQOZ should only be used if you cannot load the full blown version which has heaps of bells and whistles.

    It would be great to be able to call the soft TAQOZ with simple one liners. Then perhaps we can get to grips with TAQOZ by asking peter to help us with some of those one liners. It’s such a shame for peter to have done all this super work and not used because we can’t seem to come to grips with it.

    My thinking is that the ROM version of TAQOZ is a not moving target and thus better to use then a full blown TAQOZ, but maybe my thinking is wrong (happened before).

    So maybe it would be better to just include a binary BLOB already patched to use a mailbox and forgo the ROM patching and ROM starting.

    I am all ears here, my goal is just to have a TAQOZ hiding in the HUB accessible from PASM via mailbox. Then a small driver-object to include in any fastspin program would be a simple thing and one could call a TAQOZ sub system from Spin, basic, C and whatever eric will provide next.

    a example:
    CON
      oscmode = $010c3f04
      freq = 160_000_000
      baud = 230_400
      _rom_baud     = 115_200
      _rom_rx_pin   = 51						' pin serial receiver
      _rom_tx_pin   = 53						' pin serial transmitter
    
    
    OBJ
      ser: "FullDuplexSerial2.spin"
      rom: "TaqozSerial.spin2"
    
    VAR
    BYTE name[128]
    
    PUB demo | c
      clkset(oscmode, freq)
      ser.start(63, 62, 0, baud)
      rom.start(_rom_tx_pin+1, _rom_rx_pin+1, 0, _rom_baud)
    
       repeat 30000
       
        if (c:=rom.rxcheck)>-1
          ser.tx(c)
        if (c:=ser.rxcheck)>-1
          rom.tx(c)
    
      rom.tx(13)
      rom.tx(10)
      rom.str(string("56 BLINK",13,10))
      rom.str(string("57 BLINK",13,10))
      rom.str(string("2 2 + .",13,10))
    
      repeat
       
        if (c:=rom.rxcheck)>-1
          ser.tx(c)
        if (c:=ser.rxcheck)>-1
          rom.tx(c)
    
    
    

    will compile to some PASM where I have to replace this
    	cogid	$1d0
    	coginit	$1d0,##$400
    	orgh	$10
    	long	0	'reserved
    	long	0 ' clock frequency: will default to 160000000
    	long	0 ' clock mode: will default to $10007f8
    
    	orgh	$400
    	org	0
    

    by this
    ' start original program in COG1 and jmp COG0 into TAQOZ, patching ROM serial pins
            orgh    0
            org     0
    
    	' patch ROM
    	' tx_pin in _Enter_Monitor
    	wrbyte	#_rom_tx_pin,	  ##$FCA98   	' new -         wypin   lmm_x,            #_rom_tx_pin
    						' old -         wypin   lmm_x,            #tx_pin
    	' tx_pin & rx_pin in _SerialInit
    	wrbyte	#_rom_tx_pin,	  ##$FCABC	' new -         wrpin   ##_txmode,        #_rom_tx_pin
    						' old -         wrpin   ##_txmode,        #tx_pin
    	wrbyte	#_rom_tx_pin,	  ##$FCAC0   	' new -         wxpin   lmm_x,            #_rom_tx_pin
    						' old -         wxpin   lmm_x,            #tx_pin
    	wrbyte	#(_rom_tx_pin<<1),##$FCAC5   	' new -         dirh    #_rom_tx_pin
    						' old -         dirh    #tx_pin
    	wrbyte	#$88,	          ##$FCACA   	' new -         wrpin   ##%0000_0001_000_0000000000000_00_11111_0,        #_rx_pin
    						' old -         wrpin   ##_rxmode,        #rx_pin
    	wrbyte	#_rom_rx_pin,	  ##$FCACC   	' new -         wrpin   ##%0000_0001_000_0000000000000_00_11111_0,        #_rom_rx_pin
    						' old -         wrpin   ##_rxmode,        #rx_pin
    	wrbyte	#_rom_rx_pin,	  ##$FCAD0   	' new -         wxpin   lmm_x,            #_rom_rx_pin
    						' old -         wxpin   lmm_x,            #rx_pin
    	wrbyte	#(_rom_rx_pin<<1),##$FCAD5   	' new -         dirh    #_rom_rx_pin
    						' old -         dirh    #rx_pin
    	wrbyte	#_rom_tx_pin,	  ##$FCADC   	' new -         wypin   lmm_x,            #_rom_tx_pin
    						' old -         wypin   lmm_x,            #tx_pin
    	' tx_pin in _HubTx	
    	wrbyte	#(_rom_tx_pin<<1),##$FCAF5   	' new -         testp   #_rom_tx_pin	wc
    						' old -         testp   #tx_pin		wc
    	wrbyte	#_rom_tx_pin,	  ##$FCAFC   	' new -         wypin   lmm_x, #_rom_tx_pin
    						' old -         wypin   lmm_x, #tx_pin 
    	' rx_pin in _HubRx
    	wrbyte	#(_rom_rx_pin<<1),##$FCB11   	' new -         testp   #_rom_rx_pin	wc
    						' old -         testp   #rx_pin		wc
    	wrbyte	#_rom_rx_pin,	  ##$FCB18   	' new -         rdpin   lmm_x, #_rom_tx_pin
    						' old -         rdpin   lmm_x, #tx_pin 
    	' _REENTER_TAQOZ not _START_TAQOZ on ESC cr
            wrbyte	#$B4,		  ##$FCD8C   	' new - if_e    jmp     #@_REENTER_TAQOZ
    						' old - if_e    jmp     #@_START_TAQOZ
    	'TAQOZ
    	wrbyte	#(_rom_tx_pin<<1),##$FE9D1   	' new -         dirh    #_rom_tx_pin
    						' old -         dirh    #tx_pin
    	wrbyte	#_rom_tx_pin,	  ##$FE9D4   	' new -         wypin   #$0D,            #_rom_tx_pin
    						' old -         wypin   #$0D,            #tx_pin
    	wrbyte	#(_rom_rx_pin<<1),##$FE9DD   	' new -         dirh    #_rom_rx_pin
    						' old -         dirh    #rx_pin
    	wrbyte	#_rom_rx_pin,	  ##$FE9E0   	' new -         rdpin   fz,#_rom_rx_pin wc
    						' old -         rdpin   fz,#rx_pin wc 
    	wrlong	rxsetsel,	  ##$FE9F0   	' new -         setse1  #%110<<6+_rom_rx_pin
    						' old -         setse1  #%110<<6+rx_pin
    	wrbyte	#_rom_rx_pin,	  ##$FEA14   	' new -         rdpin   fz,#_rom_rx_pin 
    						' old -         rdpin   fz,#rx_pin wc 
    	wrbyte	#_rom_tx_pin,	  ##$FF358   	' new -         mov	txpin,#_rom_tx_pin
    						' old -         mov	txpin,#tx_pin
    	wrbyte	#_rom_tx_pin,	  ##$FF370   	' new - txpin		long	_rom_tx_pin
    						' old - txpin		long	tx_pin
    
    	' now start
            mov     $1ef,		  ##$FC000      ' lmm_bufad, locn of hub buffer for serial routine 
            mov     $1e0,             ##(freq / _rom_baud) << 16 + 7          	' _rom_baud baud, 8 bits     ' lmm_x, sets serial baud
            call    #$fcab8                    	' initialise serial _SerialInit
    	
            'SETQ    ptra_val           		' would end up in ptra of new cog
            coginit #1,##@_mainprogram              ' Start Main program in COG #1
    
    '.monitor      call      #$fcd78                ' to the monitor/debugger
    '              jmp       #.monitor               ' loop back in case of "Q<cr>"
    
    	jmp	#$FD028				' and transfer control of COG 0 to TAQOZ
    rxsetsel 	setse1  #%110<<6+_rom_rx_pin
            fit     $1E0                    	' ensure LMM reserved area cog $1E0-$1EF available                                                                              
    ''---------------------------------------------------------------------------------------------------
            orgh    $10000              		' leave the first 64K free for TAQOZ
            org 0
    _mainprogram
    ''---------------------------------------------------------------------------------------------------
    '' HERE NOW THE SOURCE OF WHATEVER YOU WANT TO PLAY WITH (it will run on COG #1++)
    ''
    '' you have to change orgh $400 against orgh $10400 in you code following this
    ''---------------------------------------------------------------------------------------------------
    	cogid	$1d0
    	coginit	$1d0,##$10400
    	orgh	$10010
    	long	0	'reserved
    	long	0 ' clock frequency: will default to 160000000
    	long	0 ' clock mode: will default to $10007f8
    
    	orgh	$10400
    	org	0
    

    And compile and run the changed PASM.

    That is now using 4 smartpins and the TAQOZ rom runs on 51 and 53, the 'rom' driver uses 52 and 54, the usb ports are free for the application.

    Now I can send the TAQOZ redirect to MAIL snipped, I guess but all of this is quite ugly

    If I could include a patched TAQOZ as binary blob things might be more easy.

    Enjoy!

    Mike

    The forum does not allow to upload P2asm so remove the .txt
  • jmgjmg Posts: 15,140
    Cluso99 wrote: »
    TAQOZ# : HELLO 10 FOR CRLF PRINT" Hello World!" NEXT ; --- ok

    To me this is even confusing.

    I get you are making this a new word (subroutine) "HELLO"

    I get that its going to repeat FOR 10 times and where the next is placed, and I know from past info the 10 comes before the FOR

    But then the CRLF and Print"Hello World!" are reversed. OK writing this down I think I get that yes everything is backwards in forth so the message comes first, then the crlf. But when I looked at the whole line, I couldnt see why crlf and the print were not reversed.

    Trouble is, you cannot just read the whole line backwards, just parts of it :(

    Is that a leading, or trailing CRLF ?
    I think CRLF is a custom print_crlf
    Maybe this needs a `Forth wizard GUI` / Translator where you can type English code <-> TAQOZ
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2019-07-08 00:06
    @Cluso99 - I'm really surprised that it was my choice of a CR and LF before it started printing that got you. Why did I do it that way? Because Forth is interactive and when I hit the enter key then Forth will respond on the same line unless directed otherwise
    TAQOZ# 12 34 + PRINT --- 46 ok
    
    So to force the first response onto a new line I would precede it with a CRLF
    TAQOZ# 12 34 + CRLF PRINT --- 
    46 ok
    
    BTW, PRINT is an alias for the traditional but tiny . symbol. I use PRINT for readability in source code, and . when I interact for convenience.

    Traditionally CR in Forth would do a CR LF combo but if I wanted to return to the start of the line I either had to say $0D EMIT or define another word for just a carriage return like <CR>.
    With the P2 I thought I'd lock it in from the start, a CR is just a carriage return, an LF is just a line feed, and a CRLF is an explicit return to the start of the next line.

    If my Hello World had it after the message, guess what the console output from HELLOS would look like :)

    There was never any need to read it backwards, it did what I asked it to, and Forth compiles word for word. No need to guess how the compiler is going to interpret it.
  • The current - pin patched - version does not just allow to use TAQOZ over the rom-driver, you also can get hold of the monitor

    Enjoy!

    Mike
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2019-07-08 01:09
    jmg wrote: »
    Is that a leading, or trailing CRLF ?
    I think CRLF is a custom print_crlf
    Maybe this needs a `Forth wizard GUI` / Translator where you can type English code <-> TAQOZ

    How would you "translate"
    PRINT" Hello " PRINT" World!"
    
    would it print "World!Hello "?
    Why would CRLF PRINT" Hello World!" be any different?

    Argghh, this is frustrating. I cannot understand why left to right, word for word code is being reinterpreted backwards?
    "100 ms" needs to be interpreted to "delay.ms(100)" IF you are translating into another computer language perhaps, but does it need to be translated?
  • jmgjmg Posts: 15,140
    jmg wrote: »
    Is that a leading, or trailing CRLF ?
    I think CRLF is a custom print_crlf
    Maybe this needs a `Forth wizard GUI` / Translator where you can type English code <-> TAQOZ

    How would you "translate"
    PRINT" Hello " PRINT" World!"
    
    would it print "World!Hello "?
    Why would CRLF PRINT" Hello World!" be any different?

    Argghh, this is frustrating. I cannot understand why left to right, word for word code is being reinterpreted backwards?
    "100 ms" needs to be interpreted to "delay.ms(100)" IF you are translating into another computer language perhaps, but does it need to be translated?

    The example above is straight forward, I assumed it was printing a leading CRLF, using 'print macro' named CRLF, I think Cluso99 may have assumed trailing CRLF.
    The issue is not so much with the simplest lines, it's when you increment a little to more complex blocks of code.
  • MJBMJB Posts: 1,235
    ....
    I superloaded TAQOZ yesterday with every utility I had so that beyond the normal FAT32 and formatter and audio/image/video routines I also included the decompiler, the clockgen, the breakout game, Mandelbrot, Silabs C2 programmer, EasyNet servers etc and all the code and dictionary came to around 32kB. So it seems to me that TAQOZ extreme edition could hide away in a tiny corner along with Python somehow :)
    so TaqOS on the P2 is smaller than Tachyon on the P1 ???

  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2019-07-08 12:27
    MJB wrote: »
    so TaqOS on the P2 is smaller than Tachyon on the P1 ???

    Indeed it seems and certainly the _ret_ field makes some opcodes a single PASM instruction long. Bear in mind that I have file and receive buffers outside of this area that I haven't included. The P1 with everything and buffers still had room for some app code, otherwise, what's the use. But whether it is a bit more or less than 32k without buffers, it is still a small memory footprint. So it will fit nicely in 64kB and still have plenty of room to breathe.
  • MJBMJB Posts: 1,235
    edited 2019-07-08 18:22
    
    
    
    Cluso99 wrote: »
    TAQOZ# : HELLO 10 FOR CRLF PRINT" Hello World!" NEXT ; --- ok

    To me this is even confusing.

    I get you are making this a new word (subroutine) "HELLO"

    I get that its going to repeat FOR 10 times and where the next is placed, and I know from past info the 10 comes before the FOR

    But then the CRLF and Print"Hello World!" are reversed. OK writing this down I think I get that yes everything is backwards in forth so the message comes first, then the crlf. But when I looked at the whole line, I couldnt see why crlf and the print were not reversed.

    Trouble is, you cannot just read the whole line backwards, just parts of it :(

    hi Cluso99
    part of the problem might be that you think forth is reverse - it is not ... it is straight forward.
    If you want me to add two numbers you have to first give them to me - then I can ADD them ...
    1 2 +
    and then I can print it ... so simply one step after the other
    1 2 + PRINT

    But obviously the FOR (word/operator) is quite loaded with experience from BASIC,C,...
    maybe in Forth if you name it

    TIMESREPEAT it makes more sense 10 goes on the stack, TIMESREPEAT consumes it

    10 TIMESREPEAT ... stuff to do NEXT

    but of course FOR types faster ;-) ...

    why the CRLF this time goes in front of the PRINT Peter explained already

    but actually the PRINT" Hello" is kind of reverse for FORTH
    in that the STRING 'Hello' comes after the PRINT

    you could write " hello" (recognize the SPACE after the first ") which puts the string on the stack
    ... kind of at least ... it puts the address of the string on the stack.

    so
    " hello" PRINT prints 20486 (decimal) the address in the input buffer where the 'hello"' resides

    " hello" PRINT$ prints hello the string at the address on top of the stack, which was terminated with the "

    BUT !!
    " hello"
    PRINT$
    on 2 separate lines fails to work because for the second input line the input buffer is reused where the
    'hello' string was parked until the line is fully evaluated ...

    and if you look closer

    even '" ' with space and then 'hello"' is really kind of reverse ...

    because '" ' the "space word is a special word for parsing input from the command line
    It reads what comes on the input line "AFTER" the '" ' word - and does not only refer to the stack ...

    if you are even more confused now ...
    it took me a while to understand this -
    but reading Peter's assembler and Tachyon source helped me a lot in the beginning.

    and now it just feels natural

    little ADDIT:
    now:

    : HELLO
    " hello"
    PRINT$ ;

    will it work ? sure
    because the ':' starts building a permanent definition in code space, so the string is kind of 'copied' there
    and will be available later and the ';' semicolon word switches back to interactive mode
    In reality the string is not copied at all because the compiler input buffer just resides in the next free code space
    and moves on after the definition is finished.
    (this is from Tachyon - not 100% sure Peter did not change all of this in TAQOS )

    so you see PRINT" hello" is just nicer way of saying " hello" PRINT$

    ADDIT2:
    that's actually a nice way to view it.
    The code you input get's compiled onto the CODESTACK.
    If the line was temporary the stuff get's pop'ed after. (actually just overwritten with the next input)
    If it is a permanent definition it stays there and the CODESTACK pointer moves to the end of it.
    If you later want to FORGET a number of the latest definitions,
    the CODESTACK is just pop'ed by moving the pointer down.
    And the housekeeping is done with the DICTIONARY

    IF you want to disassemble/decompile or inspect your code .. you know where it is ...
  • Cluso99Cluso99 Posts: 18,066
    Each time i look, i get part way to understanding, then do other stuff, and i am then back almost where i started.
    Unfortunately its just not as simple as say basic, spin or those simple languages (ie not C). Thats a big shame because its efficient and powerful.
  • @Cluso99 - you are old enough to remember when Australia changed over to decimal currency in 1966 and then eventually everything was decimal. It took many years for old people to adjust even though decimal currency was super simple. Why? Because they continued to translate everything back into pounds, shillings, and pence (pounds and ounces etc). Although they read the sign that said $1.20, they would hesitate and fumble mentally converting that into imperial currency, which btw, they were no longer using, it had all been replaced with decimal currency.

    As I said, don't fumble mentally, you need to have this mental agility to just think and work with what you've got, if it's P2ASM, then you wouldn't think x86. So if it's Spin, then think Spin, if it's C, then think C, if it's Forth, then think Forth. (I've got this mental picture of trying to write C while thinking Spin or Forth :) )



  • Cluso99Cluso99 Posts: 18,066
    Nah. Don't remember that ;)

    ... on the fourteenth of February 1966.
  • Cluso99 wrote: »
    Nah. Don't remember that ;)

    ... on the fourteenth of February 1966.

    to the tune of click go the shears boys, click, click, click :)
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2019-07-21 00:52
    From the Tachyon thread......
    msrobots wrote: »
    OK, I am using
    Parallax P2 *TAQOZ* Extensible Firmware V2.0 'CHIP' 80MHz 190212-1700
    direct out of the DROP BOX

    57 BLINK - blinks LED 57

    57 MUTE - stops blinking LED 57

    so far OK but

    57 BLINK - blinks LED 57

    56 MUTE - stops blinking LED 57

    why?

    Mike

    All TAQOZ smartpin operations setup the pin number with PIN so that all subsequent operations will use that pin. BLINK in an exception because it is meant as a very quick and easy test. It is defined simply as:
    pub BLINK ( pin -- )		PIN 2 HZ ;
    
    MUTE does not need a parameter, it simply uses the last PIN number. The pin number you supplied will still be sitting on the stack, unused.

    To mute an arbitrary pin, specify it.
    56 BLINK
    57 BLINK
    56 PIN MUTE
    

    BTW, after 57 BLINK try 10 HZ to make it blink faster. No extra parameters are required.

    Here's another one, using PWM to make it dim. Something like:
    5 100 1,000 PWM
    
    Don't forget to select the PIN beforehand, it will stay latched until changed.
    5 100 specify 5 on in a frame of 100, so 5%, while 1,000 is the divider for the PWM clock and even 1 will work but the frequency it will be CLK/(1*100).
  • Aah OK, that makes sense. So 56 BLINK works for switching blink on but I will need 56 PIN MUTE to switch off. Thanks.

    I took that MUTE thing from your post of how to disable serial on TAQOZ and missed that PIN.

    For my embedding of TAQOZ test I am using now the 64K version for es and added the mailbox and start my own program and all gets loaded via Spin2Gui/FastSpin/P2load into RAM.

    Basically I start TAQOZ but my program is already in HUB starting at $10004 and using $10000 and $10002 as Mailbox.

    Works perfect, but I need to paste

    $10.000 := incon
    $10.002 := outcon
    : GETCON ( -- char ) incon W@ DUP IF incon W~ THEN >B ;
    : SENDCON ( char -- ) BEGIN outcon W@ 0= UNTIL $100 OR outcon W! ;
    : MBX ' GETCON ukey W! ' SENDCON uemit W! ;
    : EMBED MBX 63 PIN MUTE 62 PIN MUTE $10004 1 COGINIT ;
    EMBED

    into the terminal to start mailbox and my program.

    I am starting the unhanged _BOOT_P2.BIX binary (64K) and would like to add some words plus running one word at startup.

    Question one - how to set a autostart that EMBED will be executed when TAQOZ image gets started.
    Question two - how to save that current running TAQOZ as binary to SD to use it instead of _BOOT_P2.BIX binary to include in my Program.

    Slowly I am getting where I want to go, I have a SPIN object using the Mailbox at $10000 and I can (with some pain) load TAQOZ at HUB 0 and my Program at HUB $10004, while still using FastSpin and Spin2Gui.

    Now I just need to add the above words and get hold of that now changed 64K binary to include it instead of _BOOT_P2.BIX out of the dropbox.

    @MJB suggested SAVE2SD but this seems not to be there in _BOOT_P2.BIX, can I maybe use FWRITE to copy a image to SD?

    I just need the changed TAQOZ as binary to start. @MJB also said something about baking(?) a own image from source, but I was not really understanding what he meant by that exactly.

    So what I am looking for is a way to create a 64K binary including above definitions and executing EMBED at startup.

    I am trying to get TAQOZ next to the other languages, and I think I am pretty close now.

    Absolut perfect would be if MBX replaces CON so if some TAQOZ script developed for console/ROM/TAQOZ would not accidently switch back to serial, say redirecting to some LCD and back to CON. This should then redirect to MBX.

    help me, pretty please,

    Mike
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2019-07-21 07:39
    Correction, 56 BLINK implies that the pin number is latched to 56 so a subsequent MUTE is all that is needed.
    Blink P56 for 5 seconds then MUTE
    56 BLINK 5 s MUTE
    

    There is already an autostart routine which executes the word INITS and that word itself is normally all cleared to NOPs but you can add a vector to it with:

    Just use AUTO
    AUTO MYSTARTUP 
    
    then backup (I just use BU which is a shortcut for BACKUP MBR)

    I will get back soon with some more answers.
Sign In or Register to comment.