@"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.
@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.
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.
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 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)
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, 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:
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, 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.
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.
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#
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.
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
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?
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
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
@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.
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?
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.
....
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 ???
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.
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 ...
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 )
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.
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.
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)
Comments
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
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
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.
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
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:
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)
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
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:
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?
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
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.
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.
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#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
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?
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
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 0And 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
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
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.
Enjoy!
Mike
How would you "translate" 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.
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.
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 ...
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.
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
... on the fourteenth of February 1966.
to the tune of click go the shears boys, click, click, click
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: 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.
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: 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).
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
Blink P56 for 5 seconds then 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 then backup (I just use BU which is a shortcut for BACKUP MBR)
I will get back soon with some more answers.