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

TAQOZ - Tachyon Forth for the P2 BOOT ROM

Peter JakackiPeter Jakacki Posts: 10,193
edited 2021-08-07 22:05 in Forth
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




«13456738

Comments

  • Looks like a good start. Thanks!
  • What is the minimum hardware environment for TAQOZ? Obviously, the P2 is target, but which of the FPGA variants would be supported (I'm assuming more than 1 cog in order to communicate from a terminal app)? Just wondering if it provides support for the DE0-nano raw or BeMico-A2...

    dgately
  • Peter, how similar is TAQOZ to v4.7?
    In other words, how similar is it to the P1 version?

    J
  • I have a question here for @Peter.

    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
  • Would it be possible for TAQOZ to not use any hub RAM at all? Also, it would be good if TAQOZ loaded in some other cog than cog 0. There are some features in the FPGA that are only available from cog 0.

    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.
  • Dave Hein wrote: »
    Would it be possible for TAQOZ to not use any hub RAM at all? Also, it would be good if TAQOZ loaded in some other cog than cog 0. There are some features in the FPGA that are only available from cog 0.

    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 haven't kept up with the TAQOZ discussion, so I don't know all the details of how it will work. I just want to make sure that there is a mode where I can boot up my program from flash, and all the hub RAM is available for my program to use. Also, I would like to be able to reboot from flash and preserve the previous contents of the hub RAM as much as possible.
  • Steadily I've been tweaking and squeezing TAQOZ down to fit into boot ROM and in doing so I wonder what features would serve best. BTW, TAQOZ uses 16-bit word codes as Tachyon V4 uses rather than byte codes from previous versions. So the kernel's code address range is limited to 64kB not including data and dictionary etc and I find that this shouldn't be a problem since code is so compact and besides there are ways to expand that. As to what memory footprint we want depends upon how it is to be used but really remember that although there has been talk of it being used as a "BIOS" etc that it is in fact a useful hardware debugger at the very least.

    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#
    
  • I would use it as a monitor, assembler, disassembled. Useful for exploring the hardware, quick known environment.
  • potatohead wrote: »
    I would use it as a monitor, assembler, disassembled. Useful for exploring the hardware, quick known environment.
    That's what I had in mind as well. However, if it has support for reading files from an SD card then I think it should be used for SD boot support if that is to be included in the ROM.

  • potatoheadpotatohead Posts: 10,261
    edited 2018-01-24 19:39
    Yup. I think the same, but have basically just stepped out of the SD discussion. If that one is smaller, it will resolve better.
  • It might be smaller but if the Tachyon one is going to be there anyway it might as well be used.
  • I will be using it to learn Forth :D

    After that, most likely as a monitor.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-01-24 23:38
    @potatohead - I would like to include an assembler and disassembler but I think we would need more ROM than we have. I have at most about 14k but I am aiming for 12k since I am allowing for Cluso99's loader.

    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:
    14 PIN  38 KHZ     ( select pin 14 and configure smart pin to output a 38kHz signal )
    34 PIN 8 BIT 115200 TXD     ( select pin 34 for 8 bit data at 115200 baud asynch transmit )
    3 PIN 1024 4096 1 PWM   ( select pin 3 for 1024 cycles out of a 4096 cycle frame with divider of 1 for triangle PWM - use SAW otherwise )
    5 BLINK  ( blink an LED on pin 5 - short for 5 PIN 2 HZ )
    0 HIGH 0 LOW ( pulse pin 0 high then low - automatically selects output mode)
    0 PIN H L H L H L H L F R ( select pin 0 then issue four fast High and Low requests, Float the pin, then Read it )
    60 FOR I PIN I 1+ KHZ NEXT ( configure pins 0 to 59 for 1 to 60kHz mode )
    

    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.... :) .... then you can "learn Forth" :)

    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:
    2 PIN L   10 FOR H 1 ms L  1 s NEXT
    

    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.


  • cgraceycgracey Posts: 14,202
    It's looking good, Peter!
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-01-26 13:53
    Has anyone played much with the smartpins yet? I've been using some of the modes and of course we can't test the analog functions but I'm trying to set up a way of being able to set the pins easily. For instance, to output an NCO frequency is easy enough, I just type 32 PIN to select the pin which stays latched until changed and then 38 KHZ to get that pin to output that frequency. I am making it that simple.

    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.
  • Just to whet your appetite, here is how I am currently accessing smartpin PULSE/CYCLE mode with some screen caps.
    978 x 329 - 22K
  • cgraceycgracey Posts: 14,202
    Peter, I tested each mode myself, but there may be facets of their behavior which could be improved.
  • I never got clarification on some comments I posted on January 2. The comments were
    Dave Hein wrote: »
    I just want to make sure that there is a mode where I can boot up my program from flash, and all the hub RAM is available for my program to use. Also, I would like to be able to reboot from flash and preserve the previous contents of the hub RAM as much as possible.
    I didn't post my comments as questions, which may be why there wasn't a response to them. So let me pose a few questions.

    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?

  • As far as I understood current booting is:

    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
  • Thanks for posting the boot sequence. That clarifies things. I wonder if it would be better to just put a simple monitor/debugger program in ROM. I suppose taqoz could be used that way as long as it doesn't trash any of the hub memory. It might be useful to have a debugger that could start up after a user program crashes. I suppose on a Prop this could be done by loading a watchdog program in a cog that is activated if it detects that other cogs are no longer resetting the watchdog timer.

    Anyhow, having taqoz in ROM should come in handy.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-01-27 01:42
    I'm out at the moment but í don't understand where this idea of TAQOZ taking over memory comes from. Of course it needs hub memory both to run and for file buffers etc. What a user binary does IF it is loaded by TAQOZ is totally beyond TAQOZ's control, not the other way round. However I have asked the question as to how everyone intends to use it. As for me, i will probably load a full Tachyon system from SD myself.
  • Cluso99Cluso99 Posts: 18,069
    There are some details that Chip has not yet provided about booting. Perhaps it has not been worked thru yet.

    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.
  • msrobotsmsrobots Posts: 3,709
    edited 2018-01-27 04:02
    I'm out at the moment but í don't understand where this idea of TAQOZ taking over memory comes from. Of course it needs hub memory both to run and for file buffers etc. What a user binary does IF it is loaded by TAQOZ is totally beyond TAQOZ's control, not the other way round. However I have asked the question as to how everyone intends to use it. As for me, i will probably load a full Tachyon system from SD myself.

    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
  • Cluso99Cluso99 Posts: 18,069
    edited 2018-01-27 08:08
    My current SD Boot code does not use smart pins. I am a bit concerned about the lack of smart pin testing to rely on smart pins for rom boot code. I'd rather rely on simple code to get things booting. There is only read support and simple FAT32 root directory reading to find a file to load. Based on 32KB clusters and 32 byte directory entries, I am only scanning fo a file name in the first 64 sectors of 16 entries, so the file name entry must be in the first 1024 entries. I am happy that this is a reasonable attempt. But if boot code is found in the MBR (sector 0) or else the VOL (first sector of the first partition) then this will be used as the boot code.
    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.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-01-27 08:47
    Just to clarify, while TAQOZ supports smartpins at the Forth and user level it does not use any smartpin modes for SD cards as we need sure and certain boot methods. However there is still the issue of having two separate SD boot methods which we may need to look at consolidating especially considering that we only have 16kB of ROM total. But in the meantime I'm happy to do my thing, Cluso99 to do his thing, Chip to do his thing, and then when we are happy with it all we can work together as a team into making it into one boot ROM. In this regard I would really love the ability to work with the FPGA in such a way that I could burn the "ROM" and fully test it. I don't know how hard that would be with an FPGA version but with more complexity we need more flexibility in being able to make a change and test it again, as if it were 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.
  • evanhevanh Posts: 16,014
    DaveH,
    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.

  • Cluso99 wrote: »
    I am a bit concerned about the lack of smart pin testing to rely on smart pins for rom boot code.
    What specifically about the smartpins are you concerned about?
    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.





  • evanhevanh Posts: 16,014
    edited 2018-01-27 10:07
    I never found any Smartpin bugs ... just misunderstandings.
  • While we're talking about smartpins, I'm still getting around to checking out the SPI modes in the next couple of days. Has anyone done had this running yet?

    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 :)
Sign In or Register to comment.