TAQOZ - Tachyon Forth for the P2 BOOT ROM
Peter Jakacki
Posts: 10,193
A few months back I had a discussion with Chip regarding a version of Tachyon suitable for incorporating into the P2 BOOT ROM. Not only will TAQOZ allow booting from raw SD sectors but also by FAT32 name. Of course the full power of TAQOZ can be made available if a user connects a serial terminal and interacts with it and not only using "commands" but also "scripts" since this is essentially a non-standard Forth tailor made for the P2 to allow testing of hardware and smartpins etc. Even so, full programs can be typed in line by line or more conveniently by pasting or sending from an editor. Therefore the development environment is not limited to a PC as even phones and tablets have editors and serial terminals. The serial connection can even be via a Bluetooth serial module.
Since it includes SD driver layers and FAT32 along with all the commands/routines you can even think of it a bit like DOS and BATCH files.
Currently I am attempting documentation and full conversion of the higher level Forth source that includes FAT32 so that it can all be integrated into the TAQOZ.spin2 file which can be loaded in one keystroke from PNut. Please, if you want to help with documentation then please sign-in with your Google account so that you can request to edit the document directly or add sections etc rather than just commenting about paragraph formatting. I will start some other documents as well that focus on introductions and examples etc.
Current public documentation (Google doc for editing)
Current file TAZOZ.spin2
210125 - LATEST BINARY and boot files for TAQOZ RELOADED on SD
Since it includes SD driver layers and FAT32 along with all the commands/routines you can even think of it a bit like DOS and BATCH files.
Currently I am attempting documentation and full conversion of the higher level Forth source that includes FAT32 so that it can all be integrated into the TAQOZ.spin2 file which can be loaded in one keystroke from PNut. Please, if you want to help with documentation then please sign-in with your Google account so that you can request to edit the document directly or add sections etc rather than just commenting about paragraph formatting. I will start some other documents as well that focus on introductions and examples etc.
Current public documentation (Google doc for editing)
Current file TAZOZ.spin2
210125 - LATEST BINARY and boot files for TAQOZ RELOADED on SD
Comments
dgately
In other words, how similar is it to the P1 version?
J
Besides the ROM area where TAQOZ will land at boot-time, you use HUB-RAM.
My question here is if it is possible to keep hub address 0 to xxx free as a one block?
The goal would be that one COG runs TAQOS while the rest of the P2 from 0 to xxx is free for applications written in other languages.
And xxx is the lowest HUB address TAQOZ currently needs. My wish here is that TAQOZ hoovers on the top end of the available RAM.
xxx should be readable at a fixed ROM location and updated by TAQOZ after words are added.
This would allow to have TAQOZ (even with later loaded extensions) to run parallel occupying one COG and provide a Firmware or BIOS for all running programs.
I am not sure there, all you examples are with redirection the output of EMIT to different targets, but my guess is that TAQOZ can also redirect its input away from serial pins to some hub-mail box usable by other programs as a 'script-engine' .
So the question is - can you build TAQOZ so that it just lives on the top of the RAM?
just asking,
Mike
Ideally, TAQOZ should have a mode where it acts as a smart monitor program. In this mode it shouldn't need to use hub RAM or an SD card. If desired, the user could invoke a more advanced mode that would require the use of hub RAM and SD.
If the user program hasn't loaded via serial or serial Flash then what is the point of TAQOZ sitting there in a "smart monitor" mode? What are we expecting to do then? Surely we just want to be able to use it fully and if it hasn't detected a user program on SD card then what does it matter if it uses some hub RAM? I suppose what I am wondering about is that given the conditions I mentioned then what is your rationale for TAQOZ not using hub RAM?
Given good reason, we may want to do this, but I can't see why at present.
I have been testing out smartpin modes and making it easy to configure and exercise pins. Then there is the FAT32 firmware which allows us to interact with the files, listing, opening, reading and writing, loading etc. One thing I haven't put back in there yet is creating files but I may do this once I squeeze code and dictionary to fit without cutting back on functionality. I will be sure to include the serial Flash utilities as well so that Flash can be saved or loaded from a file or serially etc.
The dictionary may end up in a compressed state for inclusion in ROM and then decompressed into RAM afterwards. I'm aiming for 2kB compressed, 4kb uncompressed bearing in mind that there are over 500 active words and each word in the dictionary includes a 16-bit word code along with the name and attributes.
So my main question is basically then, what features would you consider a "must have" or how do you intend to use it?
Here's a quick screen dump including a decompilation of a word. The dictionary has a lot of words that would be "reclaimed" or stripped prior to the final image.
Parallax Propeller II .:.:--TAQOZ--:.:. V10180123.0 V31 FPGA ------------------------------------------------------------------------------ TAQOZ# ls -l -rwxrwxrwx 1 502 500 0 Dec 4 12:02 [HELP . ] -rwxrwxrwx 1 502 500 211k Nov 23 15:00 FISH2 .VT -rwxrwxrwx 1 502 500 3968 Nov 23 15:02 3X5 .TXT -rwxrwxrwx 1 502 500 55k Nov 23 15:01 ASCIIART.TXT -rwxrwxrwx 1 502 500 1M Nov 23 14:03 MIDENG .TXT -rwxrwxrwx 1 502 500 511k Nov 23 13:40 VULGAR .TXT -rwxrwxrwx 1 502 500 219k Nov 23 13:35 ROUGES .TXT -rwxrwxrwx 1 502 500 988k Nov 23 13:32 LEXICON .TXT -rwxrwxrwx 1 502 500 365k Nov 23 13:42 WARWORLD.TXT -rwxrwxrwx 1 502 500 28M Nov 23 12:11 WEBSTERS.TXT -rwxrwxrwx 1 502 500 1M Nov 23 12:07 ILIAD .TXT -rwxrwxrwx 1 502 500 726k Nov 23 12:06 PRIDE .TXT -rwxrwxrwx 1 502 500 46k Oct 24 13:33 EASYFILE.FTH -rwxrwxrwx 1 502 500 60k Oct 24 12:14 EXTEND .FTH -rwxrwxrwx 1 502 500 42k Oct 24 01:25 EASYNET .FTH -rwxrwxrwx 1 502 500 7308 Oct 15 05:08 LIFE .FTH -rwxrwxrwx 1 502 500 1848 Oct 11 06:04 CALCDEMO.FTH -rwxrwxrwx 1 502 500 5M Aug 28 12:12 KJV .TXT -rwxrwxrwx 1 502 500 3495 Jan 24 03:00 SEE .FTH -rwxrwxrwx 1 502 500 18k Mar 9 12:14 SPLAT-V4.FTH -rwxrwxrwx 1 502 500 3M Aug 30 07:03 WARPEACE.TXT -rwxrwxrwx 1 502 500 14M Feb 16 08:06 LOVE .WAV -rwxrwxrwx 1 502 500 117k Jun 17 06:07 POPCORN .WAV -rwxrwxrwx 1 502 500 4.0G Aug 23 11:19 CD .ISO -rwxrwxrwx 1 502 500 0 Jan 24 03:17 [ANSI . ] ok TAQOZ# SEE ls IMMEDIATE $3068: $FD6B REG $6B $306A: $0085 1+ $306C: $00E7 C@ $306E: $FE20 ' ' #32 $0020 $3070: $00B9 = $3072: $FC1E IF $30B0 $3074: $1C8E GET$ $3076: $0085 1+ $3078: $00E7 C@ $307A: $16DE SWITCH $307C: $FE6C 'l' #108 $006C $307E: $16EA CASE= $3080: $FC03 IF $3088 $3082: $102E CRLF $3084: $3062 LIST $3086: $005A EXIT THEN $3088: $FE66 'f' #102 $0066 $308A: $16EA CASE= $308C: $FC11 IF $30B0 $308E: $24DE FILE# $3090: $FE04 #4 $3092: $FE00 #0 $3094: $011A DO $3096: $102E CRLF $3098: $0111 I $309A: $1AA8 .AS" #|# " $30A2: $0111 I $30A4: $2812 FILE $30A6: $2B22 @DIRBUF $30A8: $2F2A .DIR $30AA: $0125 LOOP $30AC: $2812 FILE $30AE: $005A EXIT THEN $30B0: $2FD6 lscnt $30B2: $0E44 C~ $30B4: $0151 $2FDC (12252) ' ' $30B8: $2F7F GOTO (DIR) QV ok TAQOZ# WORDS SEE SEE? DECODE .W9 fad? if? +if -~i +~i INDENT .T .D (.AS) (.") (") (S) (R) (IF) (L) (W) >NFA ~f ~w ~i ~x QV ls LIST (LIST) .[]? (ls) lscnt .DIR1 (DIR) DIR DODIR .DIR (.DIR) .F83 .FSIZE .ATR pwd cd cwd$ cat FRUN FILE> FLOAD FOPEN FOPEN$ FOPENX FCLOSE >FILE FREAD FPUTB FPUT FGET fkey FREM FABORT FS? FS FS@ FSW@ FSC@ FS! FSC! FSX! FSA FSA! FSECT@ FSIZE@ @CLUST .FTIME .FDATE .ASMONTH .FYEAR DIR? dir$ @DIRBUF SECT1 @FSIZE @FDATE @FTIME @ATR >F83 FILE$ fname$ _file$ ?MOUNT MOUNT UNMOUNT .FAT .[ .CID .VOL .SER RDFAT S/C SC* FAT2 FAT1 @FAT ROOT @ROOT RO RW RW? @RW vbr+ fboot @cwd _rw dirbuf _file diradr mounted vbr @INFO parts FWR@ @FWR @FILE @FRD FILE fwr frd SD SDW@ SDC! SDC@ SD! SD@ RDSDA WRSDA SDRDS SDRD SECTOR FLUSH SDRDBK SDWR !SD !SDX SDDAT! SD4@ SDERR? STAT@ ACMD SDRES CMD TOKEN SDPINS ;; SDCLK CARD? FILE# SDBUF @scrc @sector wrflg scrcs sectors wrflgs sdcmd crc _sdrd _sdwr ocr csd cid =dtk #files BLKSIZ =sdpins SDC *SDCS DUP 2DUP OVER DROP 2DROP SWAP 2SWAP ROT -ROT NIP 3DROP ?DUP 3RD 4TH BOUNDS ON TRUE -1 FALSE OFF 1+ 1- 2+ 2- 4+ + - ADO DO LOOP +LOOP FOR NEXT ?NEXT I J LEAVE IC@ I+ AND ANDN OR XOR ROL ROR >> << SAR 2/ 2* 4/ 4* 8<< 16>> 8>> 9<< 9>> REV |< >| >N >B 9BITS BITS 0= 0<> NOT = <> > U> <= => DUPC@ C@ W@ @ C+! C! C@++ W+! W! +! ! BIT! SET CLR SET? C++ C-- W++ W-- ++ -- ~ ~~ W~ W~~ C~ C~~ L>S >W L>W W>B W>L B>W B>L UM* * W* SQRT MIN MAX UMIN UMAX BMASK ABS -NEGATE ?NEGATE NEGATE H L F R HIGH LOW FLOAT SHROUT SHRINP WRPIN WXPIN WYPIN RDPIN RQPIN AKPIN WAITPIN TXDAT WRACK PIN @PIN DUTY NCO HZ KHZ MHZ MUTE BLINK PWM SAW BIT BAUD TXD RXD PIN@ DELTA WAITCNT REBOOT RESET 0EXIT EXIT NOP CALL JUMP >R R> >L L> !SP DEPTH COG@ COG! COGID COGINIT COGSTOP COGATN POLLATN SETEDG POLLEDG RND LUT@ LUT! REG KEY KEY! keypoll CON NONE COM DISCARD CONKEY CONEMIT EMIT EMITS CRLF CR CLS DOT SPACE SPACES HOME PEN PAPER UL REVERSE BOLD PLAIN XY CURSOR CNT@ LAP LAP@ .LAP .ms QD RAM DUMP: DUMP DUMPW DUMPL DUMPA DUMPAW DEBUG COG LUT KB MB M . PRINT .AS .AS" .DECL .DEC4 .DEC2 @PAD HOLD >CHAR #> <# # #S <D> U. .DEC .BIN .B .BYTE .W .WORD .L .LONG .ADDR PRINT$ LEN$ " ." CTYPE / U/ U// // */ UM// 0< < U< WITHIN ?EXIT MOVBYTES DATA? ERASE FILL CMOVE <CMOVE s ms us HEX DEC BIN WORDS @NAMES GET$ SEARCH $># LOOKIN LOOKUP .S HERE @HERE @CODES BOOT? uemit ukey char delim names TASK @WORD SPIN GETRND | || , [W] ["] NULL$ $! $= NEW$ NEW VAR =: == ==! ALIGN DATCON ALLOT [C] GRAB pub pri pre : ; [ ' NFA' CPA CFA FORGET GOTO IF ELSE THEN ENDIF BEGIN UNTIL AGAIN WHILE REPEAT SWITCH CASE@ CASE= CASE> BREAK CASE TWICE \ --- ( { } IFNDEF IFDEF IDLE .VER TAQOZ CONSOLE AUTORUN SPIRD SPIWB SPIWR SPICE SPIWC SPIWW SPIPINS SPIRX SPITXE SPITX CLKIN CLKOUT CLOCK WS2812 WAIT CLKDIV RCSLOW HUBSET WP WE CLKHZ CLKMHZ BUFFERS ROM VECTORS PTRA PTRB DIRA DIRB OUTA OUTB INA INB org bytes words longs byte word long res blk red grn yel blu mag cyn whi ERROR END ok TAQOZ#After that, most likely as a monitor.
Forth allows us to access the SD card, boot binaries from FAT32 files, load TAQOZ source code which could be the assembler/disassembler etc. Simple immediate execution one line loops can be typed in or new definitions created which btw are lost on reset or could be saved to SD or Flash.
If you had a new board then TAQOZ lets you exercise the hardware such as blinking the leds and accessing SPI peripherals using built-in high level support. The smart pins can be configured easily too, here are some quick examples:
All the smart pin instructions are reproduced as high level Forth instructions, so you can $41 WYPIN to write $41 to the currently selected PIN using the WYPIN instruction. The problem I have at this early stage is testing the analog functions, which of course I can't, but I will have those functions available anyway.
@ke4pjw - I remember monitor programs as tedious machine code level reads, writes, runs, and dumps. Sure TAQOZ can do that....
BTW, you can dump "memory" from hub, cog, lut, Flash, raw SD, an open file, or any other memory in various formats such as byte, word, long, ASCII, and ASCII wide. Typically somewhere prior to the actual DUMP command if you wanted to select other than main memory you would use either COG LUT SF SD or FS or RAM although the dump command automatically resets the selection back to RAM after completion. Commands are DUMP DUMPW DUMPL DUMPA DUMPAW.
Memory can be read or written to using the familiar @ and ! to fetch and store or the C@ C! for bytes (characters) or W@ W! for 16-bit words. Then there are the block commands which move or fill such as: CMOVE <CMOVE FILL ERASE.
Delays are easy, to pulse pin 2 for 1ms every 1 second for 10 times:
All these examples can be typed in directly without having to place them in a definition unlike traditional Forths. Just type ." Hello World!" which is about the shortest Hello World example there is.
But of course I have barely scratched the surface of what TAQOZ in ROM can do. I'm sure it will prove to be very very useful.
Same too with asynch modes as after a pin is selected it is simply a matter of passing a baud rate to the RXD or TXD command to put it in that mode with the default data bits set to 8 but easily changed to 9 bits by saying 9 BITS before the RXD or TXD command.
Now I am testing the transition mode and decided to break that up into three words, TRANS to set the mode, PW to set the pulse width (just cycles at present but nanoseconds probably in the manner 100 ns PW ), and PULSES which triggers the number of pulse transitions. The pulse/cycle mode actually counts out pulses so manually typing $48 WRPIN $8.000C WXPIN 4 WYPIN causes four 50ns pulses in a 150ns period (sweet!) and then typing 2 WYPIN outputs two of those pulses so obviously I will find a way to express that in an easier to use format.
As I explore these mode interactively the documentation starts to make more sense but I'm just wondering how much testing has been done on the smartpins. Certainly I will continue to check them out and build support into TAQOZ.
1. Is taqoz active only when a serial link is established, or does it run even if I'm booting from SD and/or flash?
2. When taqoz runs does it require any hub RAM?
3. Can I run in the serial mode, and not run taqoz? That is, can I used the current loader commands that we have now in the serial mode?
1) serial
2) flash
3) boot from SD with clusso99's code
--3a) MBR boot
--3b) named File in root dir
4) if all fails jump into TAQOZ
--4a) TAQOZ start script from file from SD
1) and 2) may be prevented by some pullups/pulldowns on some pins?
not sure about preventing 3a) and 3b) and 4)
I also asked Peter if TAQOZ could just use top memory and keeping 0 - xxx free for use with c/pasm/spin programs, his answer was kind of avoiding the issue, stating that it would not make sense once TAQOZ is running. I disagree with that statement.
Currently TAQOZ seems to take over the whole HUB ram, a big mistake in my opinion, because then it is not a resident OS/debugger but a whole program running, thus disabling the use of TAQOZ in one or two COGS to say debug and watch a C or SPIN program.
It is understandable that Peter wants TAQOZ for his projects WITHOUT using SPIN or C or Basic or other software not written in FORTH, for his goals this is perfect.
But I think this is a big mistake.
TAQOZ could be used as program loader/debugger for other software NOT written in FORTH, even provide common routines for say stdin/out/err nicely redirectable to say serial ports, displays, etc, like TAQOZ is already doing for its own.
That could be a common base for other programs to be used as a BIOS, but sadly Peter is to fixated on building a FORTH and just FORTH system, NOT considering the co-existence of TAQOZ and other software at the same time on one chip.
The whole idea of a write protect ROM area is to allow a resident OS/BIOS to be available for other software running on the chip, not able to overwrite the ROM.
This is moot when TAQOZ uses low memory areas.
sad,
Mike
Anyhow, having taqoz in ROM should come in handy.
On boot, I am presuming that the ROM is serially loaded into the top of Hub RAM.
The next part is important...
Does part of this Hub get copied into Cog 0 and then a JMP $00000 (cog 0) ?
This part is important because I am hoping we can use hubexec to run the code directly from hub, particularly the routines to access the SD, but also any debug code, etc, including Peters TAQOZ.
OK, I try to ask a third time the same question with different formulation.
Can you build TAQOZ so that it JUST use memory in the upper part of the HUB leaving 0 - end of memory not used by TAQOZ free as one block?
I do understand that TAQOZ will need buffers and room to extend the dictionary, thus can not entirely live in the ROM area, but to make this useful as a resident loader/debugger while NOT using FORTH as main language one needs a top of free HUB-RAM address updated by TAQOZ, so that a program loaded at address zero knows how much RAM it has without destroying TAQOZ?
And like cluso99 mentioned it would be nice if, EVEN if a C, spin or pasm program is started serial, from flash or from sd it would be possible to start TAQOZ in some COGS to use as debugger and reuse SD block-access (FAT access?) and TAQOS nice redirection of input and output from the started program.
That is what I call BIOS, some known addresses in the ROM to run with HUBEXEC from any other COG and language.
What else for would be a write protected ROM area needed at all?
By now TAQOZ takes all COGS so coexistence with other running programs seems not possible planned for.
And that is sad, if not plain wrong.
I can not imagine writing a whole program in FORTH. But I could imagine writing some string-snippets to throw at a resident TAQOZ from C/Basic/Spin/Pasm/whatever other language.
TAQOZ should max use 2 COGs and leave the rest free for other uses. So please consider that other people will not run a complete Tachyon system from SD, but some other stuff, and still want to be able to use the power of FORTH.
Think of TACOZ as a parallel sub system like the smart pins. I run my SPIN program and can delegate things to TAQOZ while my program is doing something else in the remaining 6 COGS and the remaining HUB.
ha,
smartPins and smartROM?
If a loaded program could use TAQOZ over something like a virtual serial connection, alike common used mailboxes, also with fixed addresses in ROM then a program could simply access the TAQOZ console.
Now I can load my program, extend TAQOZ if needed with new words and simply batch it from my own program.
Those who can do FORTH can write nice extensions and other people like me can just copy them and use them in their language of choice.
and that would be a smartROM, because it can learn!
Enjoy!
Mike
Remember, we want a failsafe and future proof boot from SD. FAT32 is defined for SD up to 2TB. The minimum is expected to be about 2GB.
EXFAT requires licensing, so there is no point in supporting it in rom.
So memory maps and cog usage are of secondary importance to me at present since I'm just busy squeezing it down while testing out various functionalities. Nonetheless the time is fast approaching when we need to be finalized as to what is included in the ROM. Chip's loader, and then I think one single SD loader which may be a consolidation and amalgamation of our SD loaders, the best of so to speak.
Yes, it would be nice if TAQOZ ran in another cog and could be called serially or locally perhaps and only use the top of RAM. It is hard to envisage just how we might end up using it but don't forget that it is being included because Chip only needed a couple of kB for his stuff and we hate to see that ROM go to waste. TAQOZ will let you program and test hardware without the need for external tools or chips, just a simple serial terminal. That's what I like to see even just from a production testing viewpoint. Then there is the interactive file system, a bit like DOS if you like, so you can just use a microSD for your main memory and still be able to manipulate files.
The mask ROM can't execute in place. It has to be copied into RAM first.
Also, Chip has arranged the last 16 KB of HubRAM to be separated from the rest. It sits at the end of the 20 bit address space (right under 1 MB). This is intended for the debug routines and any OS like facilities. Peter has just indicated this space could be where TAQOZ sits, but it doesn't as yet.
Smartpins have been tested from Version 8 (April 2016) right up to now (Version 31).
A few tweaks/changes and bug fixes have happened along the way.
These fixes would never of happened without testing.
From the testing I have done myself the smartpins work as documented.
BTW, from what I have tested so far the smartpins work fine, and yes, there is a bit of misunderstanding but part of that is due to the documentation itself. I know it has thrown me off at times