Hey, that's great to know how fast Fastspin is, so I guess it's fast! What a great plug for Fastspin and the P2. No more slow code!
It sounds like all of the P2 tools so far are very fast... TAQOZ is really an incredible interpreter. Actually it's very tempting to use TAQOZ as the standard bytecode interpreter for P2. I've thought about adding a FORTH backend for fastspin (since it already can output C or PASM). The thing that's stumped me so far is how to do local variables. A good FORTH programmer rarely needs to put variables on the stack, but a compiler is going to be much dumber I'm afraid. If there are only a few locals then DUP, OVER, 3RD and 4TH will do, but for more complicated functions I'm not sure how to grab values from the stack. PICK would be handy, or some way to mark a base frame for the stack.
I'd be interested in a listing of the code that it generates.
I've attached it to this message. The original Spin is in comments, although because of inlining and optimization those comments don't line up very well with the generated code . The fibo function itself has been expanded in the main loop (since fibo is only called once) and looks like:
That's 10 instructions, so 40 bytes; considerably larger than Tachyon's 16 bytes!
While the main part of the interpreter uses only 4 instructions for cog calls, the looping instruction NEXT uses stacked & latched branches so there is no reading and calculating branch addresses, just load and go.
' NEXT ( -- ) Decrement count (on loop stack) and loop until 0, then pop loop stack
forNEXT djz index,#POPBRANCH ' exit loop
_ret_ mov PTRA,branchadr ' loop again
I've made a standalone version of TAQOZ that resides in 32kB of RAM so that I can test TAQOZ easily and make changes which I then copy back to the ROM version. This also means I can kinda test it on boards that don't have the latest ROM such as the BeMicro-A2 which has 128kB RAM and only 1 cog except it doesn't have cordic which is used by the multiply and divide routines.
I may do some automatic test and revector these cordic functions to other routines since I already have a UM/MOD64 that takes a 64-bit dividend and returns a 64-bit quotient and 32-bit remainder plus my fast multiply from the P1 version. These extras won't be in the ROM version though, only to allow testing on various boards. This should work on the DE0-Nano as well but I will have to test that out later.
I'm still sorting out some little glitches but in the meantime don't feel left out if all you have is the A2 or DE0 boards.
TAQOZ_RAM.spin2 is running nicely on a BeMicro-A2 and now I am going to test on a DE0-Nano.
Occasionally I read and post on comp.lang.forth and comp.arch.embedded. Just to test the waters and because I excited about it, I've posted to clf this piece: (I hope I got it right)
Parallax P2X8C4M64P 8-core 32-bit Realtime controller with Forth in ROM
1 post by 1 author
me (Peter Jakacki change)
6:41 PM (1 minute ago)
Well finally this design is proceeding to silicon and we expect to have samples of the initial batch in about 16 weeks. Although the P2 is not a Forth chip by any means, it brings me pleasure to know that I have TAQOZ, a subset of my Tachyon Forth in 16kB of mask ROM. This doesn't allow me the full FAT32 words but certainly all the words to do with serial Flash and virtual memory access to SD besides the SD/Flash/Serial bootloader section. The bootloader can load a full version if need be.
Since the chip boots up in internal RCFAST mode at 20MHz and autobauds at up to 3M baud then there is very little to stop hardware being debugged, even a faulty crystal won't affect it. Many of the words are to do with the hugely multifunctional smartpins of which there are 64. Any and all of these can be UARTS/PWM/PULSE/FREQ/ADC/DAC/VIDEO etc totally independently of the eight 32-bit cogs that besides their own internal code RAM can run code just as fast from anywhere in the 512kB of common hub RAM. All I/O is common to all cogs, they all have equal access. Clock speed is highly expected to be 180MHz with most instructions taking 2 cycles and there is a also a CORDIC engine for transforms etc and streamers which are a bit like DMA.
There are so many features in this chip but the difference between this and anything else is the simplicity of programming and whereas each cog supports interrupts of various events, there is no need for them either. However the Forth in ROM uses interrupts to buffer serial through smartpin UARTs just so that it could be tested really.
TAQOZ always compiles all non-immediate words so it is very easy to type in a one line program complete with conditionals and looping and have it run when you hit enter like this.
Parallax P2 .:.:--TAQOZ--:.:. V1.0 180522-1200
TAQOZ# $7F $20 DO I EMIT LOOP !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~ ok
TAQOZ#
Testing has been carried out on various FPGA boards that support anything from a single cog and 32k RAM to a full 16 cog 1MB RAM implementation although only 8 cogs and 512KB will be initially produced due to chip size. The price of the TQFP100 chip is expected to be around the same price of the current Propeller chip.
Thanks Peter!
Yes, running TAQOZ (loaded TAQOZ_RAM.bin onto an A2, running v32) on a BeMicro CV A2 works well. I've added an external SD and pulled in TAQOZ.fth and can mount an SD!
TAQOZ# mount
Mounted NO NAME 3EF6_0E00-9E95_5552 [PHSD08G] MSDOS5.0 FAT32 7,964MB (2kB/cluster) ok
TAQOZ# ls
/NO NAME
[SYSTEM~1] _BOOT_P2.BIX [TRASHE~1]
_BOOT_P2.BIY ok
Of course, I don't expect to boot from the SD, waiting for a new .jic, but running TAQOZ in RAM is allowing some testing.
I am looking at building some more of the FAT32 words right into the ROM file and thereby the RAM version so we can mount from ROM and list the directory etc.
We have another day or so now since onsemi have to make some adjustments to their simulation settings. We had an 8 hour Skype stint through the night until daybreak and got to spy on p2's secret herbs and spices while Chip was talking with onsemi and displaying simulations and verilog.
For the projects I'm working on, having file system capabilities out of the box will allow me to think of the P2 as a Computing Platform rather than a micro controller. Virtually all the low level work has been done for me ! I can really focus on my solution.
Great job guys !!!
I can't wait to get my hands on this thing !!
Hopefully Chip can still use my latest TAQOZ to be included in ROM since I have been recoding sections and making it more compact so I can fit in FAT32 on top of the virtual SD memory that I had already had put there. This means we can mount a FAT32 volume and perform a DIR at the very least. I'm hoping to fit in the fopen and rename functions as well. Being able to open a file makes it that little bit easier to edit or dump or type it out etc.
Here is the current TAQOZ automounting a FAT32 SD card when I type DIR which also lists info about the card and FAT32: (updated)
Cold start
----------------------------------------------------------------
Parallax P2 .:.:--TAQOZ--:.:. V1.0 180525-2345 139F
----------------------------------------------------------------
TAQOZ# DIR .SDSL16G 6131_6232 NO NAME 32k 15,189M
HELP 0000_FC80 0
FISH2 .VT 0001_0000 211,945
3X5 .TXT 0001_01C0 3,968
ASCIIART.TXT 0001_0200 55,148
MIDENG .TXT 0001_0280 1,248,077
VULGAR .TXT 0001_0C40 511,916
ROUGES .TXT 0001_1040 219,885
LEXICON .TXT 0001_1200 988,130
WARWORLD.TXT 0001_19C0 365,413
WEBSTERS.TXT 0001_1CC0 28,956,348
ILIAD .TXT 0001_F9C0 1,201,891
PRIDE .TXT 0002_0300 726,223
EASYFILE.FTH 0002_08C0 46,173
EXTEND .FTH 0002_0940 60,355
EASYNET .FTH 0002_09C0 42,985
LIFE .FTH 0002_0A40 7,308
CALCDEMO.FTH 0002_0A80 1,848
KJV .TXT 0002_0AC0 5,504,282
SEE .FTH 007A_5800 3,495
SPLAT-V4.FTH 0002_3500 18,944
WARPEACE.TXT 0002_3540 3,226,652
LOVE .WAV 0002_4E00 14,630,692
POPCORN .WAV 0002_BDC0 117,804
CD .ISO 0002_BEC0 4,012,965,888
ANSI 007A_5840 0
_BOOT_P2.BIX 007A_63C0 96
_BOOT_P2.BIY 007A_6400 32,768
ok
TAQOZ# WORDS
DUP OVER SWAP ROT -ROT DROP 3RD 4TH 2DROP 3DROP NIP 2SWAP 2DUP ?DUP AND
ANDN OR XOR ROL ROR >> << SAR 2/ 2* 4/ 4* 8<< 16>> 8>> 9<< 9>> REV |< >|
>N >B >9 BITS NOT = <> 0= 0<> 0< < U< > U> <= => WITHIN DUPC@ C@ W@ @ C+!
C! C@++ W+! W! +! ! BIT! SET CLR SET? 1+ 1- 2+ 2- 4+ + - UM* * W* / U/
U// // */ UM// C++ C-- W++ W-- ++ -- RND GETRND SQRT SETDACS ~ ~~ W~ W~~
C~ C~~ L>S >W L>W W>B W>L B>W B>L MINS MAXS MIN MAX ABS -NEGATE ?NEGATE
NEGATE ON TRUE -1 FALSE OFF GOTO IF ELSE THEN BEGIN UNTIL AGAIN WHILE REPEAT
SWITCH CASE@ CASE= CASE> BREAK CASE ADO DO LOOP +LOOP FOR NEXT ?NEXT I
J LEAVE IC@ I+ BOUNDS H L T F R HIGH LOW FLOAT PIN@ WRPIN WXPIN WYPIN RDPIN
RQPIN AKPIN WAITPIN WRACK PIN @PIN ns PW PULSE PULSES HILO DUTY NCO HZ
KHZ MHZ MUTE BLINK PWM SAW BIT BAUD TXD RXD TXDAT WAITX WAITCNT REBOOT
RESET 0EXIT EXIT NOP CALL JUMP >R R> >L L> !SP DEPTH COG@ COG! LUT@ LUT!
COGID COGINIT COGSTOP NEWCOG COGATN POLLATN SETEDG POLLEDG KEY KEY! CON
NONE COM CONKEY CONEMIT SEROUT EMIT EMITS CRLF CR CLS SPACE SPACES RAM
DUMP: DUMP DUMPW DUMPL DUMPA DUMPAW QD QW DEBUG lsio COG LUT KB MB M .
PRINT .AS .AS" .DECL .DEC4 .DEC2 HOLD #> <# # #S <D> U. .DEC .BIN .H .B
.BYTE .W .WORD .L .LONG .ADDR PRINT$ LEN$ " ." CTYPE ?EXIT DATA? ERASE
FILL CMOVE <CMOVE s ms us CNT@ LAP LAP@ .LAP .ms HEX DEC BIN .S WORDS @WORDS
GET$ SEARCH $># @DATA HERE @HERE @CODES uemit ukey char delim names TASK
REG @WORD SPIN | || , [W] ["] NULL$ $! $= ASM FORGET CREATE$ CREATE VAR
pub pri pre module : ; [ ' := == ==! ALIGN DATCON ALLOT org bytes words
longs byte word long res [C] GRAB NFA' CPA CFA \ --- ( { } IFNDEF IFDEF
TAQOZ TERM AUTO SPIRD SPIRDL SPIWB SPICE SPIWC SPIWW SPIWM SPIWL SPIPINS
SPIRX SPITXE SPITX WSLED WAIT CLKDIV RCSLOW HUBSET WP WE CLKHZ ERROR SFPINS
SF? SFWE SFINS SFWD SFRDS SFSID SFJID SFER4 SFER32 SFER64 SFERASE SFWRPG
BACKUP RESTORE SFRDS SFWRS SFC@ SFW@ SF@ SF .SF SDBUF sdpins MOUNT DIR
!SD !SX SD? CMD ACMD cid SDWR SDRDS SDWRS FLUSH SECTOR SDRD SDRDS SDADR
SD@ SD! SDC@ SDC! SDW@ SD @FAT @BOOT @ROOT fat END 430 ok
TAQOZ# lsio
P:00000000001111111111222222222233333333334444444444555555555566
P:01234567890123456789012345678901234567890123456789012345678901
=:d~~~dd~d~~~~~~~~~~~~~~~dd~~~d~~~~~~~hhhdh~~~d~d~~~hdhhdd~~h~hh ok
Opening files by name sounds dandy but unless I chop out a bit of other stuff there just isn't any room for it. I must get, check and convert and process strings etc which all takes precious ROM. However the DIR listing prints the starting sector which can be used instead. Also the SD virtual memory words will access 4GB offset from the open sector. Any DIR resets the open sector back to 0 etc.
Here's how it works at present. (I've snipped out some directory entries just to shorten the listing). If I want to open _BOOT_P2.BIY I use it's starting sector as an argument for FOPEN after which the SD virtual memory words will operate on the file. The normal Forth memory words for fetching and storing have an equivalent SD version such as SDC@ in place of C@ etc.
Opening files by name sounds dandy but unless I chop out a bit of other stuff there just isn't any room for it. I must get, check and convert and process strings etc which all takes precious ROM. However the DIR listing prints the starting sector which can be used instead. Also the SD virtual memory words will access 4GB offset from the open sector. Any DIR resets the open sector back to 0 etc.
Here's how it works at present. (I've snipped out some directory entries just to shorten the listing). If I want to open _BOOT_P2.BIY I use it's starting sector as an argument for FOPEN after which the SD virtual memory words will operate on the file. The normal Forth memory words for fetching and storing have an equivalent SD version such as SDC@ in place of C@ etc.
I hate to keep bringing this up but can we get more TAQOZ functionality by reducing the ROM monitor functions? There is a fair amount of overlap between the two. I know that TAQOZ runs in low memory and that the ROM monitor is in high memory but is that really that big a deal? We could have an option with the Spin and C tools to set the application base above what is used by TAQOZ so that an application and TAQOZ could reside in memory at the same time.
I hate to keep bringing this up but can we get more TAQOZ functionality by reducing the ROM monitor functions? There is a fair amount of overlap between the two. I know that TAQOZ runs in low memory and that the ROM monitor is in high memory but is that really that big a deal? We could have an option with the Spin and C tools to set the application base above what is used by TAQOZ so that an application and TAQOZ could reside in memory at the same time.
I had already spoken to Cluso99 about keeping the monitor as a monitor as trying to do anything in PASM just chews through memory and the interface at that level isn't all that friendly anyway. The combined SD bootloader + monitor takes 2,752 bytes so with Chip's bootloader TAQOZ ends up at after $FD000 which gives me around 12kB so there really isn't a lot of room to play with. However I'm looking at other functions I can trim or cull .
Now I've have just added FLOAD which loads a TAQOZ source file but i will probably rename this so that FLOAD can mean something more general. If i find some room i will try for handling files by name. Sector addresses work for now
David, the difference between the TAQOZ and the Monitor/SD routines are just that.
They are routines that run in hubexec in ROM HUB, and can be called from any user program, with minimal resource usage of the users space.
So all the base functions are there including serial operation calls including sending char(s), hex, listing (dumping) cog/LUT/hub memory, strings, reading a char and strings with an optional prompt char(s), and the Monitor itself can be called and returned from.
SD calls include initialising (mounting), searching the DIR for a filename, loading a file with optional run, reading any sector(s), and a whole lot more as the low level routines are exposed. Unfortunately there is not enough space for an SD write sector(s) routine although in itself it's not that difficult as the underlying support is accessible.
Combined, Chips Booter, SD Boot, and the Monitor take 4KB, with each taking about 1/3 rd of the 4KB.
TAQOZ has a huge number of features, but it is standalone and cannot be called from a users program and then return.
David, the difference between the TAQOZ and the Monitor/SD routines are just that.
They are routines that run in hubexec in ROM HUB, and can be called from any user program, with minimal resource usage of the users space.
So all the base functions are there including serial operation calls including sending char(s), hex, listing (dumping) cog/LUT/hub memory, strings, reading a char and strings with an optional prompt char(s), and the Monitor itself can be called and returned from.
SD calls include initialising (mounting), searching the DIR for a filename, loading a file with optional run, reading any sector(s), and a whole lot more as the low level routines are exposed. Unfortunately there is not enough space for an SD write sector(s) routine although in itself it's not that difficult as the underlying support is accessible.
Combined, Chips Booter, SD Boot, and the Monitor take 4KB, with each taking about 1/3 rd of the 4KB.
TAQOZ has a huge number of features, but it is standalone and cannot be called from a users program and then return.
If those functions are all available in the ROM space in upper memory, could TAQOZ use those to implement serial and SD support and hence reduce the footprint required for those functions in the TAQOZ image? If we have to have both TAQOZ and the monitor routines it would be nice if TAQOZ could take advantage of the code that is already present in the ROM space.
Here is the current TAQOZ automounting a FAT32 SD card when I type DIR which also lists info about the card and FAT32: (updated)
Opening files by name sounds dandy but unless I chop out a bit of other stuff there just isn't any room for it. I must get, check and convert and process strings etc which all takes precious ROM. However the DIR listing prints the starting sector which can be used instead. Also the SD virtual memory words will access 4GB offset from the open sector. Any DIR resets the open sector back to 0 etc.
Getting to DIR is worth having, as a simple field diagnostic and sanity check tool, and users can always load a larger TAQOZ if they want to massage SD contents more.
Is there a file date field that is easy to list, even if not fully formatted ?
I see a common question being 'what version code is on which of this stack of SD cards...' ?
Can the DIR work on any SD pins, or is it hard-wired to boot-pinout only ?
Peter says the functions take a minimum footprint in TAQOZ, because the TAQOZ interpreter has already been accounted for. I will let him answer later (maybe next week) as he's busy coding and debugging.
BTW we did not expect this extended window for the ROM code, so lots have been squeezed in as we get a few more days delay.
Peter says the functions take a minimum footprint in TAQOZ, because the TAQOZ interpreter has already been accounted for. I will let him answer later (maybe next week) as he's busy coding and debugging.
BTW we did not expect this extended window for the ROM code, so lots have been squeezed in as we get a few more days delay.
Well, whatever you have time to implement will be great. Thanks for putting all of this effort into this!
I have never been able to recreate the problem that Chip had on the 123-A9 board and I don't know if anyone else tried and had the same result. I thought I came across a very strange bug yesterday but it was simply a matter p2asm not picking up some address modes correctly since PNut is still stuck at the 1024 DAT symbol limit.
I'm sure if Cluso and I had the time we could make quite a few of these routines compatible and thereby save maybe another 1k or so. My routines are optimized for TAQOZ and Cluso's routines are optimized for his code.
OzPropDev got the same result with the ??? response
Is there another compile that includes the cordic? Could that be part of the problem?
... Cordic is used for the internal multiply and divide operations but I could do a version that replaced these with routines from the TAQOZ_RAM standalone edition.
I found TAQOZ in V32g didn't like any commands at all.
Can you type "lsio" and before you hit enter or space you press ctrl ? which dumps some memory areas including the word buffer. Then copy and paste it back here.
Does the same thing happen if you load and run TAQOZ_RAM.spin2?
"lsio" run from taqoz_ram on P123-A9 with v32g image.
ok
TAQOZ# lsio
P:00000000001111111111222222222233333333334444444444555555555566
P:01234567890123456789012345678901234567890123456789012345678901
=:~~~~~~~~~~~~~~~~~~~~~~~~~d~~~~~~~~~~~~~~~~~~d~~~~~~~~~~hhh~~~~ ok
TAQOZ#
It seems that cordic doesn't function correctly on this image then as the RAM version does not use cordic and also it seems that the last character in is also the first in the word buffer. Always a count of one and these routines do happen to use a umod. Can anyone see a problem with this cog code?
' U// ( dvdn dvsr -- rem quot )
UDIVMOD qdiv tos1,tos
getqx tos
_ret_ getqy tos1
' MOD ( n1 mod -- rem )
UMOD call #UDIVMOD
jmp #DROP
' U/ ( u1 u2 -- quot )
UDIVIDE qdiv tos1,tos
getqx tos1
jmp #DROP
This is used by this routine which adds another character to the word buffer. Simple enough you might think.
PUTCHARPL
word PUTCHAR,rg+wordcnt,DUPCFT,INC
word w+wordsz,UMOD,SWAP,CSTOREX+ex
Of course this could be done differently with INCMOD instructions but it shows up a problem.
TAQOZ itself is now frozen in ROM and Chip is making images available. I've attached the combined source and listing.
As I am updating the TAQOZ documentation it is another good time to ask if anyone has been using it and if so, what can I add or change? One of the reasons I ask is because I find that I seem to skip over what I consider the very very basics as I find that I need to step back and explain. But the problem is mainly because many are used to programming a little bit like this:
milliseconds_delay(300) // delay 300 ms
whereas we have to "translate" this to Forth as:
300 ms
I picked this example simply to highlight how ingrained our thinking becomes because that is how we are so used to writing programs for parsing by compilers that although we want "300 ms", we end up thinking in terms of how we code. But the point here is this: Since this document is mainly for ones who are familiar with programming and the Propeller, help me please to structure and word it in such a way that unlocks the right door at the right time as a reader progresses through the document. The document is structured however in the assumption that they are actually in front of a system to interact with it, trying out the exercises and hopefully experimenting at that point before progressing. Perhaps that's something I can add, exercises, but that might distract if they are too wordy. Perhaps a link to the exercise would suffice?
Anyway, this post is not about differences in programming languages, it's only about TAQOZ, but it does need to take the reader's background into account somehow.
TAQOZ# WORDS
DUP OVER SWAP ROT -ROT DROP 3RD 4TH 2DROP 3DROP NIP 2SWAP 2DUP ?DUP AND
ANDN OR XOR ROL ROR >> << SAR 2/ 2* 4/ 4* 8<< 16>> 8>> 9<< 9>> REV |< >|
>N >B >9 BITS NOT = <> 0= 0<> 0< < U< > U> <= => WITHIN DUPC@ C@ W@ @ C+!
C! C@++ W+! W! +! ! BIT! SET CLR SET? 1+ 1- 2+ 2- 4+ + - UM* * W* / U/
U// // */ UM// C++ C-- W++ W-- ++ -- RND GETRND SQRT SETDACS ~ ~~ W~ W~~
C~ C~~ L>S >W L>W W>B W>L B>W B>L MINS MAXS MIN MAX ABS -NEGATE ?NEGATE
NEGATE ON TRUE -1 FALSE OFF GOTO IF ELSE THEN BEGIN UNTIL AGAIN WHILE REPEAT
SWITCH CASE@ CASE= CASE> BREAK CASE ADO DO LOOP +LOOP FOR NEXT ?NEXT I
J LEAVE IC@ I+ BOUNDS H L T F R HIGH LOW FLOAT PIN@ WRPIN WXPIN WYPIN RDPIN
RQPIN AKPIN WAITPIN WRACK PIN @PIN ns PW PULSE PULSES HILO DUTY NCO HZ
KHZ MHZ MUTE BLINK PWM SAW BIT BAUD TXD RXD TXDAT WAITX WAITCNT REBOOT
RESET 0EXIT EXIT NOP CALL JUMP >R R> >L L> !SP DEPTH COG@ COG! LUT@ LUT!
COGID COGINIT COGSTOP NEWCOG COGATN POLLATN SETEDG POLLEDG KEY WKEY KEY!
CON NONE COM CONKEY CONEMIT SEROUT EMIT EMITS CRLF CR CLS SPACE SPACES
RAM DUMP: DUMP DUMPW DUMPL DUMPA DUMPAW QD QW DEBUG lsio COG LUT KB MB
M . PRINT .AS .AS" .DECL .DEC4 HOLD #> <# # #S <D> U. .DEC .BIN .H .B .BYTE
.W .WORD .L .LONG .ADDR PRINT$ LEN$ " ." CTYPE ?EXIT DATA? ERASE FILL CMOVE
<CMOVE s ms us CNT@ LAP LAP@ .LAP .ms HEX DEC BIN .S WORDS @WORDS GET$
SEARCH $># @DATA HERE @HERE @CODES uemit ukey char delim names TASK REG
@WORD SPIN | || , [W] ["] NULL$ $! $= ASM FORGET CREATE$ CREATE VAR pub
pri pre : ; [ ] ' := ==! ALIGN DATCON ALLOT org bytes words longs byte
word long res [C] GRAB NFA' CPA CFA \ --- ( { } IFNDEF IFDEF TAQOZ TERM
AUTO SPIRD SPIRDL SPIWB SPICE SPIWC SPIWW SPIWM SPIWL SPIPINS SPIRX SPITXE
SPITX WSLED WAIT CLKDIV RCSLOW HUBSET WP WE CLKHZ ERROR SFPINS SF? SFWE
SFINS SFWD SFSID SFJID SFER4 SFER32 SFER64 SFERASE SFWRPG BACKUP RESTORE
SFRDS SFWRS SFC@ SFW@ SF@ SF .SF SDBUF sdpins MOUNT DIR !SD !SX SD? CMD
ACMD cid SDWR SDRDS SDWRS FLUSH FOPEN FLOAD FGET FREAD FWRITE SECTOR SDRD
SDRDS SDADR SD@ SD! SDC@ SDC! SDW@ SD @FAT @BOOT @ROOT fat END 433 ok
TAQOZ#
Comments
I've attached it to this message. The original Spin is in comments, although because of inlining and optimization those comments don't line up very well with the generated code
That's 10 instructions, so 40 bytes; considerably larger than Tachyon's 16 bytes!
Very nice!
I may do some automatic test and revector these cordic functions to other routines since I already have a UM/MOD64 that takes a 64-bit dividend and returns a 64-bit quotient and 32-bit remainder plus my fast multiply from the P1 version. These extras won't be in the ROM version though, only to allow testing on various boards. This should work on the DE0-Nano as well but I will have to test that out later.
I'm still sorting out some little glitches but in the meantime don't feel left out if all you have is the A2 or DE0 boards.
Occasionally I read and post on comp.lang.forth and comp.arch.embedded. Just to test the waters and because I excited about it, I've posted to clf this piece: (I hope I got it right)
Yes, running TAQOZ (loaded TAQOZ_RAM.bin onto an A2, running v32) on a BeMicro CV A2 works well. I've added an external SD and pulled in TAQOZ.fth and can mount an SD!
Of course, I don't expect to boot from the SD, waiting for a new .jic, but running TAQOZ in RAM is allowing some testing.
dgately
We have another day or so now since onsemi have to make some adjustments to their simulation settings. We had an 8 hour Skype stint through the night until daybreak and got to spy on p2's secret herbs and spices while Chip was talking with onsemi and displaying simulations and verilog.
Great job guys !!!
I can't wait to get my hands on this thing !!
J
Here is the current TAQOZ automounting a FAT32 SD card when I type DIR which also lists info about the card and FAT32: (updated)
Cold start ---------------------------------------------------------------- Parallax P2 .:.:--TAQOZ--:.:. V1.0 180525-2345 139F ---------------------------------------------------------------- TAQOZ# DIR .SDSL16G 6131_6232 NO NAME 32k 15,189M HELP 0000_FC80 0 FISH2 .VT 0001_0000 211,945 3X5 .TXT 0001_01C0 3,968 ASCIIART.TXT 0001_0200 55,148 MIDENG .TXT 0001_0280 1,248,077 VULGAR .TXT 0001_0C40 511,916 ROUGES .TXT 0001_1040 219,885 LEXICON .TXT 0001_1200 988,130 WARWORLD.TXT 0001_19C0 365,413 WEBSTERS.TXT 0001_1CC0 28,956,348 ILIAD .TXT 0001_F9C0 1,201,891 PRIDE .TXT 0002_0300 726,223 EASYFILE.FTH 0002_08C0 46,173 EXTEND .FTH 0002_0940 60,355 EASYNET .FTH 0002_09C0 42,985 LIFE .FTH 0002_0A40 7,308 CALCDEMO.FTH 0002_0A80 1,848 KJV .TXT 0002_0AC0 5,504,282 SEE .FTH 007A_5800 3,495 SPLAT-V4.FTH 0002_3500 18,944 WARPEACE.TXT 0002_3540 3,226,652 LOVE .WAV 0002_4E00 14,630,692 POPCORN .WAV 0002_BDC0 117,804 CD .ISO 0002_BEC0 4,012,965,888 ANSI 007A_5840 0 _BOOT_P2.BIX 007A_63C0 96 _BOOT_P2.BIY 007A_6400 32,768 ok TAQOZ# WORDS DUP OVER SWAP ROT -ROT DROP 3RD 4TH 2DROP 3DROP NIP 2SWAP 2DUP ?DUP AND ANDN OR XOR ROL ROR >> << SAR 2/ 2* 4/ 4* 8<< 16>> 8>> 9<< 9>> REV |< >| >N >B >9 BITS NOT = <> 0= 0<> 0< < U< > U> <= => WITHIN DUPC@ C@ W@ @ C+! C! C@++ W+! W! +! ! BIT! SET CLR SET? 1+ 1- 2+ 2- 4+ + - UM* * W* / U/ U// // */ UM// C++ C-- W++ W-- ++ -- RND GETRND SQRT SETDACS ~ ~~ W~ W~~ C~ C~~ L>S >W L>W W>B W>L B>W B>L MINS MAXS MIN MAX ABS -NEGATE ?NEGATE NEGATE ON TRUE -1 FALSE OFF GOTO IF ELSE THEN BEGIN UNTIL AGAIN WHILE REPEAT SWITCH CASE@ CASE= CASE> BREAK CASE ADO DO LOOP +LOOP FOR NEXT ?NEXT I J LEAVE IC@ I+ BOUNDS H L T F R HIGH LOW FLOAT PIN@ WRPIN WXPIN WYPIN RDPIN RQPIN AKPIN WAITPIN WRACK PIN @PIN ns PW PULSE PULSES HILO DUTY NCO HZ KHZ MHZ MUTE BLINK PWM SAW BIT BAUD TXD RXD TXDAT WAITX WAITCNT REBOOT RESET 0EXIT EXIT NOP CALL JUMP >R R> >L L> !SP DEPTH COG@ COG! LUT@ LUT! COGID COGINIT COGSTOP NEWCOG COGATN POLLATN SETEDG POLLEDG KEY KEY! CON NONE COM CONKEY CONEMIT SEROUT EMIT EMITS CRLF CR CLS SPACE SPACES RAM DUMP: DUMP DUMPW DUMPL DUMPA DUMPAW QD QW DEBUG lsio COG LUT KB MB M . PRINT .AS .AS" .DECL .DEC4 .DEC2 HOLD #> <# # #S <D> U. .DEC .BIN .H .B .BYTE .W .WORD .L .LONG .ADDR PRINT$ LEN$ " ." CTYPE ?EXIT DATA? ERASE FILL CMOVE <CMOVE s ms us CNT@ LAP LAP@ .LAP .ms HEX DEC BIN .S WORDS @WORDS GET$ SEARCH $># @DATA HERE @HERE @CODES uemit ukey char delim names TASK REG @WORD SPIN | || , [W] ["] NULL$ $! $= ASM FORGET CREATE$ CREATE VAR pub pri pre module : ; [ ' := == ==! ALIGN DATCON ALLOT org bytes words longs byte word long res [C] GRAB NFA' CPA CFA \ --- ( { } IFNDEF IFDEF TAQOZ TERM AUTO SPIRD SPIRDL SPIWB SPICE SPIWC SPIWW SPIWM SPIWL SPIPINS SPIRX SPITXE SPITX WSLED WAIT CLKDIV RCSLOW HUBSET WP WE CLKHZ ERROR SFPINS SF? SFWE SFINS SFWD SFRDS SFSID SFJID SFER4 SFER32 SFER64 SFERASE SFWRPG BACKUP RESTORE SFRDS SFWRS SFC@ SFW@ SF@ SF .SF SDBUF sdpins MOUNT DIR !SD !SX SD? CMD ACMD cid SDWR SDRDS SDWRS FLUSH SECTOR SDRD SDRDS SDADR SD@ SD! SDC@ SDC! SDW@ SD @FAT @BOOT @ROOT fat END 430 ok TAQOZ# lsio P:00000000001111111111222222222233333333334444444444555555555566 P:01234567890123456789012345678901234567890123456789012345678901 =:d~~~dd~d~~~~~~~~~~~~~~~dd~~~d~~~~~~~hhhdh~~~d~d~~~hdhhdd~~h~hh okHere's how it works at present. (I've snipped out some directory entries just to shorten the listing). If I want to open _BOOT_P2.BIY I use it's starting sector as an argument for FOPEN after which the SD virtual memory words will operate on the file. The normal Forth memory words for fetching and storing have an equivalent SD version such as SDC@ in place of C@ etc.
To edit the file:
I had already spoken to Cluso99 about keeping the monitor as a monitor as trying to do anything in PASM just chews through memory and the interface at that level isn't all that friendly anyway. The combined SD bootloader + monitor takes 2,752 bytes so with Chip's bootloader TAQOZ ends up at after $FD000 which gives me around 12kB so there really isn't a lot of room to play with. However I'm looking at other functions I can trim or cull .
Now I've have just added FLOAD which loads a TAQOZ source file but i will probably rename this so that FLOAD can mean something more general. If i find some room i will try for handling files by name. Sector addresses work for now
They are routines that run in hubexec in ROM HUB, and can be called from any user program, with minimal resource usage of the users space.
So all the base functions are there including serial operation calls including sending char(s), hex, listing (dumping) cog/LUT/hub memory, strings, reading a char and strings with an optional prompt char(s), and the Monitor itself can be called and returned from.
SD calls include initialising (mounting), searching the DIR for a filename, loading a file with optional run, reading any sector(s), and a whole lot more as the low level routines are exposed. Unfortunately there is not enough space for an SD write sector(s) routine although in itself it's not that difficult as the underlying support is accessible.
Combined, Chips Booter, SD Boot, and the Monitor take 4KB, with each taking about 1/3 rd of the 4KB.
TAQOZ has a huge number of features, but it is standalone and cannot be called from a users program and then return.
Getting to DIR is worth having, as a simple field diagnostic and sanity check tool, and users can always load a larger TAQOZ if they want to massage SD contents more.
Is there a file date field that is easy to list, even if not fully formatted ?
I see a common question being 'what version code is on which of this stack of SD cards...' ?
Can the DIR work on any SD pins, or is it hard-wired to boot-pinout only ?
BTW we did not expect this extended window for the ROM code, so lots have been squeezed in as we get a few more days delay.
I have never been able to recreate the problem that Chip had on the 123-A9 board and I don't know if anyone else tried and had the same result. I thought I came across a very strange bug yesterday but it was simply a matter p2asm not picking up some address modes correctly since PNut is still stuck at the 1024 DAT symbol limit.
I'm sure if Cluso and I had the time we could make quite a few of these routines compatible and thereby save maybe another 1k or so. My routines are optimized for TAQOZ and Cluso's routines are optimized for his code.
Is there another compile that includes the cordic? Could that be part of the problem?
Does the same thing happen if you load and run TAQOZ_RAM.spin2?
Here I type "lsio" then ^?
TAQOZ# lsio DATA STACK (0) RETURN (4) $0000_DEE8 $0000_DD74 $0000_DCA6 $0000_D932 REGS 0FE00: 0000 0000 0000 0000 0000 0000 0000 0000 '................' 0FE10: 0000 0000 0000 0A0A 0000 0000 0023 0000 '............#...' 0FE20: 0001 0400 736C 6F69 0000 0000 0000 0000 '....lsio........' 0FE30: 0000 0000 0000 0000 0000 0000 0000 0000 '................' 0FE40: 0000 0000 0000 0000 0000 0000 0000 0000 '................' 0FE50: 0000 0000 0000 3400 302C 3231 392C 3733 '.......4,012,937' 0FE60: 332C 3435 1800 0A01 DBC3 0000 1F20 0607 ',354........ ...' 0FE70: 0000 0000 0000 0000 0006 0000 0000 0000 '................' 0FE80: 0000 0000 0000 0000 0000 0000 0000 0000 '................' 0FE90: 0000 B400 0000 B400 0000 1000 0000 1000 '................' 0FEA0: 0000 1000 0000 0000 0000 A55A 0000 0000 '..........Z.....' 0FEB0: 0000 0033 01AF 0000 0000 0000 0000 0000 '..3.............' 0FEC0: 0000 0000 0000 0000 0000 0000 0000 0000 '................' 0FED0: 0000 0000 0000 0000 0000 0000 0000 0000 '................' 0FEE0: 0000 0000 0000 0000 0000 0000 0000 0000 '................' 0FEF0: 0000 0000 0000 0000 0000 0000 0000 0000 '................' CODE 00FE0: 0000 0000 0000 0000 0000 0000 0000 0000 '................' 00FF0: 0000 0000 0000 0000 0000 0000 0000 0000 '................' 01000: 0063 0063 0063 D828 0063 0063 014C 3B3D 'c.c.c.(.c.c.L.=;' 01010: 3C3A 014C 2429 3928 014C 2429 3828 014C ':<L.)$(9L.)$(8L.' WORDS 0B400: 03 44 55 50 73 00 04 4F 56 45 52 77 00 04 53 57 '.DUPs..OVERw..SW' 0B410: 41 50 7E 00 03 52 4F 54 82 00 04 2D 52 4F 54 81 'AP~..ROT...-ROT.' 0B420: 00 04 44 52 4F 50 69 00 03 33 52 44 79 00 03 34 '..DROPi..3RDy..4' 0B430: 54 48 7B 00 05 32 44 52 4F 50 68 00 05 33 44 52 'TH{..2DROPh..3DR' P:00000000001111111111222222222233333333334444444444555555555566 P:01234567890123456789012345678901234567890123456789012345678901 =:d~~~dd~d~~~~~~~~~~~~~~~dd~~~d~~~~~~~hhhdh~~~d~d~~~hdhhdd~~h~hhIn fact if you can also type a ^B to do a full 64k block dump and perhaps just attach that file then I can at least see what it may be.
The only dump that worked was the ctrl-b (attached)
Where do I find taqoz_ram?
Found it.
First problem is that PST doesn't like <ctrl> ?
Switched to teraterm and "hey presto", lsio <ctrl> ? works in v32g.
But lsio on it's own doesn't work? Presume not since I think that 0FE20 should be showing lsio
' U// ( dvdn dvsr -- rem quot ) UDIVMOD qdiv tos1,tos getqx tos _ret_ getqy tos1 ' MOD ( n1 mod -- rem ) UMOD call #UDIVMOD jmp #DROP ' U/ ( u1 u2 -- quot ) UDIVIDE qdiv tos1,tos getqx tos1 jmp #DROPThis is used by this routine which adds another character to the word buffer. Simple enough you might think. PUTCHARPL word PUTCHAR,rg+wordcnt,DUPCFT,INC word w+wordsz,UMOD,SWAP,CSTOREX+exOf course this could be done differently with INCMOD instructions but it shows up a problem.Here's the listing from p2asm in case that helps.
' U// ( dvdn dvsr -- rem quot ) ff09a 0c9 fd104421 UDIVMOD qdiv tos1,tos ff09e 0ca fd604218 getqx tos ff0a2 0cb 0d604419 _ret_ getqy tos1 ' MOD ( n1 mod -- rem ) ff0a6 0cc fdbffff0 UMOD call #UDIVMOD ff0aa 0cd fd9ffe6c jmp #DROP ' U/ ( u1 u2 -- quot ) ff0ae 0ce fd104421 UDIVIDE qdiv tos1,tos ff0b2 0cf fd604418 getqx tos1 ff0b6 0d0 fd9ffe60 jmp #DROPhttps://drive.google.com/file/d/13X3cXH2-O3hx-ldjroR78m5c_MPM1fqB/view?usp=sharing
As I am updating the TAQOZ documentation it is another good time to ask if anyone has been using it and if so, what can I add or change? One of the reasons I ask is because I find that I seem to skip over what I consider the very very basics as I find that I need to step back and explain. But the problem is mainly because many are used to programming a little bit like this: whereas we have to "translate" this to Forth as:
I picked this example simply to highlight how ingrained our thinking becomes because that is how we are so used to writing programs for parsing by compilers that although we want "300 ms", we end up thinking in terms of how we code. But the point here is this: Since this document is mainly for ones who are familiar with programming and the Propeller, help me please to structure and word it in such a way that unlocks the right door at the right time as a reader progresses through the document. The document is structured however in the assumption that they are actually in front of a system to interact with it, trying out the exercises and hopefully experimenting at that point before progressing. Perhaps that's something I can add, exercises, but that might distract if they are too wordy. Perhaps a link to the exercise would suffice?
Anyway, this post is not about differences in programming languages, it's only about TAQOZ, but it does need to take the reader's background into account somehow.
TAQOZ# WORDS DUP OVER SWAP ROT -ROT DROP 3RD 4TH 2DROP 3DROP NIP 2SWAP 2DUP ?DUP AND ANDN OR XOR ROL ROR >> << SAR 2/ 2* 4/ 4* 8<< 16>> 8>> 9<< 9>> REV |< >| >N >B >9 BITS NOT = <> 0= 0<> 0< < U< > U> <= => WITHIN DUPC@ C@ W@ @ C+! C! C@++ W+! W! +! ! BIT! SET CLR SET? 1+ 1- 2+ 2- 4+ + - UM* * W* / U/ U// // */ UM// C++ C-- W++ W-- ++ -- RND GETRND SQRT SETDACS ~ ~~ W~ W~~ C~ C~~ L>S >W L>W W>B W>L B>W B>L MINS MAXS MIN MAX ABS -NEGATE ?NEGATE NEGATE ON TRUE -1 FALSE OFF GOTO IF ELSE THEN BEGIN UNTIL AGAIN WHILE REPEAT SWITCH CASE@ CASE= CASE> BREAK CASE ADO DO LOOP +LOOP FOR NEXT ?NEXT I J LEAVE IC@ I+ BOUNDS H L T F R HIGH LOW FLOAT PIN@ WRPIN WXPIN WYPIN RDPIN RQPIN AKPIN WAITPIN WRACK PIN @PIN ns PW PULSE PULSES HILO DUTY NCO HZ KHZ MHZ MUTE BLINK PWM SAW BIT BAUD TXD RXD TXDAT WAITX WAITCNT REBOOT RESET 0EXIT EXIT NOP CALL JUMP >R R> >L L> !SP DEPTH COG@ COG! LUT@ LUT! COGID COGINIT COGSTOP NEWCOG COGATN POLLATN SETEDG POLLEDG KEY WKEY KEY! CON NONE COM CONKEY CONEMIT SEROUT EMIT EMITS CRLF CR CLS SPACE SPACES RAM DUMP: DUMP DUMPW DUMPL DUMPA DUMPAW QD QW DEBUG lsio COG LUT KB MB M . PRINT .AS .AS" .DECL .DEC4 HOLD #> <# # #S <D> U. .DEC .BIN .H .B .BYTE .W .WORD .L .LONG .ADDR PRINT$ LEN$ " ." CTYPE ?EXIT DATA? ERASE FILL CMOVE <CMOVE s ms us CNT@ LAP LAP@ .LAP .ms HEX DEC BIN .S WORDS @WORDS GET$ SEARCH $># @DATA HERE @HERE @CODES uemit ukey char delim names TASK REG @WORD SPIN | || , [W] ["] NULL$ $! $= ASM FORGET CREATE$ CREATE VAR pub pri pre : ; [ ] ' := ==! ALIGN DATCON ALLOT org bytes words longs byte word long res [C] GRAB NFA' CPA CFA \ --- ( { } IFNDEF IFDEF TAQOZ TERM AUTO SPIRD SPIRDL SPIWB SPICE SPIWC SPIWW SPIWM SPIWL SPIPINS SPIRX SPITXE SPITX WSLED WAIT CLKDIV RCSLOW HUBSET WP WE CLKHZ ERROR SFPINS SF? SFWE SFINS SFWD SFSID SFJID SFER4 SFER32 SFER64 SFERASE SFWRPG BACKUP RESTORE SFRDS SFWRS SFC@ SFW@ SF@ SF .SF SDBUF sdpins MOUNT DIR !SD !SX SD? CMD ACMD cid SDWR SDRDS SDWRS FLUSH FOPEN FLOAD FGET FREAD FWRITE SECTOR SDRD SDRDS SDADR SD@ SD! SDC@ SDC! SDW@ SD @FAT @BOOT @ROOT fat END 433 ok TAQOZ#