Forum Update - Announcement about May 10th, 2018 update and your password.

P2 Monitor/Debug for possible inclusion in the ROM

Cluso99Cluso99 Posts: 13,769
edited April 22 in Propeller 2 Vote Up0Vote Down
This is in case Peter cannot fit TAQOZ into the ROM.

The code runs in hub in hubexec mode and supports Serial I/O on P62&63 as well as various list commands that may be called from a users program.
I have detailed the output in previous thread(s).
https://forums.parallax.com/discussion/comment/1435968/#Comment_1435968

This code requires COG $1E0-$1EF for parameter passing to the hubexec code, and a further 128 bytes somewhere in hub ram for buffer and stack space. Currently this is a fixed location, but is intended to be set as a parameter when the serial code is initialised. The baud is already set by a passed parameter to _SerialInit. This will be a second parameter.

The following calls are supported...
_HubTx          transmit a serial character
_HubTxString    transmit a serial string, $0 terminated
_HubHex         transmit in hex
_HubList        list cog/lut/hub data

_HubRx          receive a serial character
_HubRxString    receive a serial string, <cr> terminated

_HubMonitor     call the monitor/debug with following command formats
[[#]xxxxxxxx] [-] [.yyyyy] [,[$]ccccc] z [m] <cr>

[xxxxxx] . [yyyyyy] L <cr>      List COG/LUT/HUB from addr1 to addr2
Q <cr>                           Return to user program
? <cr>                           Display help

WIP
[xxxxxx] - [xxxxxxxx] ... <cr>         Store to address with data...
  (will take paste of list output format)

To do (time permitting)
[xxxxxx] G <cr>                        Goto address
[xxxxxx] . [yyyyyy] , [ccccc] M<cr>    Move  COG/LUT/HUB from addr1 to addr2 for count
#[xxxxxxxx] . [yyyyyy] , [ccccc] M<cr> Fill  COG/LUT/HUB with data to addr2 for count

Attached is the code for testing.

Please don't ask for features as I don't have the time for discussion as the ROM closes Friday !!!
«1

Comments

  • 51 Comments sorted by Date Added Votes
  • nice, but eventually to late.

    As far as I understood @chips posts the ROM had to be at OnSemi TODAY (22) and the ROM closed last Friday.

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • Dave HeinDave Hein Posts: 5,494
    edited April 22 Vote Up0Vote Down
    On the 18th Chip posted
    cgracey wrote: »
    In the meantime, we have until next Friday to get the ROM together.
    I interpret "next Friday" as the 27th. If he meant the 20th I think he would have said "this" instead of "next".
  • Cluso99Cluso99 Posts: 13,769
    edited April 22 Vote Up0Vote Down
    I asked Chip a few posts later and he confirmed 27th.

    I am waiting for him to finish with onsemi to finalise the SD Boot for the ROM.

    BTW Is anyone actually testing the current P2 v32b code???
  • Yes, we officially have until Friday to get the ROM done.

    I am behind on the debug documentation. Is this needed for the ROM code?
  • cgraceycgracey Posts: 9,139
    edited April 23 Vote Up0Vote Down
    I have been thinking that because we have strict execution time limits on serial boot code, maybe we should have SD card booting not bother with serial booting. If the SD card is detected via the pull up, or pull down, we abandon the normal loading and attempt to boot from the SD. On failure, we could always go to TAQOZ. Then, we need to figure how to get into TAQOZ from the serial boot.
  • cgracey wrote: »
    I have been thinking that because we have strict execution time limits on serial boot code, maybe we should have SD card booting not bother with serial booting. If the SD card is detected via the pull up, or pull down, we abandon the normal loading and attempt to boot from the SD. On failure, we could always go to TAQOZ. Then, we need to figure how to get into TAQOZ from the serial boot.

    Agreed.
    The only other thought was to boot from serial and on another cog run either flash or sd boot. Whichever completed first would stop the other. But this is more complicated and with only days to go might not be worth the risk.

    I am not sure where Peter is at with TAQOZ today. I spoke to him over the w/e. In case he's not ready i have been working on a Monitor/Debug that could go in its place.

  • cgracey wrote: »
    Yes, we officially have until Friday to get the ROM done.

    I am behind on the debug documentation. Is this needed for the ROM code?
    Not for me.
  • jmgjmg Posts: 11,657
    cgracey wrote: »
    I have been thinking that because we have strict execution time limits on serial boot code, maybe we should have SD card booting not bother with serial booting. If the SD card is detected via the pull up, or pull down, we abandon the normal loading and attempt to boot from the SD..

    The boot needs to have fast paths possible into each of UART, SPI, SD.
    Fastest entry currently into serial is to continually send a repeating "> Prop_Chk 0 0 0 0 ", and wait for an echo (P2 out of reset) of CR+LF+“Prop_Ver Au”+CR+LF

  • Cluso99Cluso99 Posts: 13,769
    edited April 29 Vote Up0Vote Down
    Here is an updated version of my proposed Monitor/Debugger v116a for P2-V32c

    In the sample program (the cog section) this code will display a piece of code from cog, lut and hub.
    Then the user is prompted to enter a string of text terminated with <cr>. <bs> works too, and the characters are echoed.

    Next the user program calls the monitor program. Here are some strings to enter to try it out.
    The "*" is a prompt character from the monitor.
    Most spaces are optional (except in the download where spaces cause the write of the accumulated hex long to be written).

    The download format is the same as that output by the "L" list command. pnut outputs with ascii but doesn't have a delimiter quote :(
    I tried to cut and past a line in PST but PST doesn't like it :( A terminal program would likely work fine.
    * 000 . 010 L <cr>               list cog from $000 to $010
    * 200 . 210 L <cr>               list lut from $200 to $210
    * 00000 . 00020 L <cr>           list hub from $00000 to $00020
    * 4000 . 4010 L <cr>             list hub from $4000 to $4010
    
    *  000- 00 11 22 33 44 55 66 77  'xxxx' <cr>      download/store in cog $000 the hex characters
    *00000- 00 11 22 33 44 55 66 77         <cr>      download/store in hub $00000 the hex characters (bytes)      
    
    *4000 G <cr>                     Jump to hub $4000 (there is some code stored here for testing)
    *000 G <cr>                      Jump to cog $000  (careful - there is test no code here to run)
    
    * Q <cr>                         Quit back to the user program
    * ? <cr>                         Display a help screen
    

    Please check it works properly.
    Please, no requests for added features!

  • evanhevanh Posts: 5,096
    edited May 2 Vote Up0Vote Down
    Smartpin mode setting for async serial can be done with just # (short immediate) addressing mode. It's not much but an easy 8 bytes to be saved in _SerialInit routine.

    "Are we alone in the universe?"
    "Yes," said the Oracle.
    "So there's no other life out there?"
    "There is. They're alone too."
  • Cluso99Cluso99 Posts: 13,769
    evanh,
    Thanks, but I specifically didn't want to use smartpins in boot code.
    It then has to be cleared down, and I didn't want this to be required.
    This way, I don't have to worry about interrupts either.

    I know Chip has used the smartpin in the boot code.
  • jmgjmg Posts: 11,657
    Cluso99 wrote: »
    ... I specifically didn't want to use smartpins in boot code.
    It then has to be cleared down, and I didn't want this to be required.
    This way, I don't have to worry about interrupts either.

    I know Chip has used the smartpin in the boot code.

    There are merits both ways. First generation boot loaders needed to be KISS, and so used SW baud.
    That also means you have more control over a chip with possible HW faults.
    However, Smart pins do allow higher boot baud rates, and that is important.
    Smart pins are also now looking mature, with more testing hours on the clock, especially in serial mode...
    OnSemi seem to be claiming a high chance of working silicon, and especially of Logic portions, so that risk appears to be lower...

    Just looking now at new data on small MCUs that claim up to SysCLK(24MHz)/4 Baud rates.


  • evanhevanh Posts: 5,096
    Cluso99 wrote: »
    evanh,
    Thanks, but I specifically didn't want to use smartpins in boot code.
    It then has to be cleared down, and I didn't want this to be required.
    This way, I don't have to worry about interrupts either.

    I know Chip has used the smartpin in the boot code.

    Ah, here's your init routine, out of the above source file, that uses a couple of Smartpins for the async serial.
    ''-------[ Serial Routines (uses SmartPins) ]---------------------------------- <--- serial initialise --->
    ''_SerialInit
    '' On Entry:
    ''      lmm_x = _bitper                                 ' tx & rx bit period + #(bits-1)
    '' Call Format:
    ''            CALL      #_SerialInit                    '                       < call: serial initilise>
    '' On Return:
    ''      lmm_x = #CR                                     ' (changed)
    ''--------------------------------------------------------------------------------------------------
    _SerialInit
                    wrpin   ##_txmode,        #_txpin       ' set asynchronous tx mode in smart pin tx
                    wxpin   lmm_x,            #_txpin       ' set tx bit period + #(bits-1)
                    dirh    #_txpin                         ' enable smart pin tx 
                    
                    wrpin   ##_rxmode,        #_rxpin       ' set asynchronous rx mode in smart pin rx
                    wxpin   lmm_x,            #_rxpin       ' set rx bit period + #(bits-1)
                    dirh    #_rxpin                         ' enable smart pin rx
    
                    mov     lmm_x,            #CR           ' we have to prime send buffer empty flag, 
                    wypin   lmm_x,            #_txpin       ' ... so send <cr> to tx pin
                  RET                               wcz     '                       <--- return to calling routine --->
    ''--------------------------------------------------------------------------------------------------
    
    "Are we alone in the universe?"
    "Yes," said the Oracle.
    "So there's no other life out there?"
    "There is. They're alone too."
  • Cluso99Cluso99 Posts: 13,769
    Oh! That was so looong ago I had forgotten. Think it may even go back to p2hot.
    Originally I used bit banging back in the first P2.
    Guess I must say it's been working for years.
  • Cluso99Cluso99 Posts: 13,769
    edited May 4 Vote Up0Vote Down
    Ugh!!
    Just realised why I haven't been able to get my monitor running properly/reliably when I insert it into the boot code.
    Serial interrupts are still running from the booter trying to autobaud causing weird serial responses ;)

    Off to read the manual on clearing interrupts and resetting smart pins :(
  • Wow!
    By a "spooky" coincidence I was messing with autobaud stuff today. :)


    Melbourne, Australia
  • Cluso99Cluso99 Posts: 13,769
    SUCCESS :)
    ' NEED TO DISABLE CHIP'S SERIAL & AUTOBAUD !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    		wrpin	#0, #rx_ths
    		wxpin	#0, #rx_ths
    		wypin   #0, #rx_ths
    		wrpin	#0, #rx_tne
    		wxpin	#0, #rx_tne
    		wypin   #0, #rx_tne
    		setint1 #0
    		setint2 #0
    		setint3 #0
    
    Here is Bootloader code that can be downloaded and run...

    Try "> " to set autobaud in Chip's code, followed by one of...

    <esc> to run TAQOZ
    <ctl-d> to boot a file named "_BOOT_P2.BIX" or _"BOOT_P2.BIY" from an SD card
    <ctl-e> to run my monitor
    Monitor Commands... (spaces for clarity and optional)
    
    xxxxxx.xxxxxx L <cr>      List cog/lut/hub from addr to addr
    
    xxxxx - xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 'xxxxxxxxxxxxxx' <cr>   Store in cog/lut/hub (no. of bytes optional, ascii optional)
    xxxxx G <cr>  Goto/jump to addr in cog/lut/hub
    
    Q <cr>        Quit (return to users calling program) - currently responds "!" and jumps back to monitor code
    
    
    examples(spaces optional)
     
    0 L <cr>               lists cog $000
    200 L <cr>             lists lut $200
    0000 L <cr>            lists hub $00000
    1000.1080 L <cr>       lists hub $1000 to $1080
    
    000- 11 22 33 44 55667788 <cr>   stores in cog (note the reversal of the long $55667788)
    
    The file _BOOT_P2.BIX.spin2 needs to be renamed (remove ".spin2" - forum requirement) and copied to an SD card. It flashes a LED on P5.

  • Peter JakackiPeter Jakacki Posts: 7,455
    edited May 4 Vote Up0Vote Down
    I seem to have over 1kB free in the ROM. I wonder if I can squeeze something useful in there....

    This hubmap counts active bytes in 256 byte blocks capped at $FF (=256). The .. are all zeros and each line represents 4kB which is skipped if it is all zeros (unused).
    TAQOZ# HUBMAP 
    0000.0000 FF .. .. .. 51 .. .. .. .. .. .. .. .. .. .. 02 
    0000.8000 FC .. .. 08 D7 E5 F5 FF F7 FF FE FF FE FF 32 .. 
    0000.C000 EE F1 A6 EF E8 D8 CA CD C1 B9 C8 C9 CF C1 F0 D8 
    0000.D000 DE D0 CA D8 D9 DF BB BD DF DD E7 DF E1 C2 .. .. 
    0000.E000 .. .. .. .. .. .. .. .. 5F E0 EE E9 EB E1 F6 F2 
    0000.F000 D4 EF ED E8 D3 E3 F0 EF F0 F2 62 .. .. .. 34 02 
    0007.C000 EE F1 A6 EF E8 D8 CA CD C1 B9 C8 C9 CF C1 F0 D8 
    0007.D000 DE D0 CA D8 D9 DF BB BD DF DD E7 DF E1 E4 DA E8 
    0007.E000 F5 FF F7 FF FD FF FE FF 69 E0 EE E9 EB E1 F6 F2 
    0007.F000 D4 EF ED E8 D3 E3 F0 EF F0 F2 62 .. .. .. .. .. 
    000F.C000 EE F1 A6 EF E8 D8 CA CD C1 B9 C8 C9 CF C1 F0 D8 
    000F.D000 DE D0 CA D8 D9 DF BB BD DF DD E7 DF E1 E4 DA E8 
    000F.E000 F5 FF F7 FF FD FF FE FF 69 E0 EE E9 EB E1 F6 F2 
    000F.F000 D4 EF ED E8 D3 E3 F0 EF F0 F2 62 .. .. .. .. ..  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 ~ ~~ 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 COGATN POLLATN SETEDG POLLEDG KEY KEY! CON NONE COM CONKEY CONEMIT 
    EMIT EMITS CRLF CR CLS DOT SPACE SPACES RAM DUMP: DUMP DUMPW DUMPL DUMPA 
    DUMPAW QD DEBUG lsio COG LUT KB MB M . PRINT .AS .AS" .DECL .DEC4 .DEC2 
    HOLD #> <# # #S <D> U. .DEC .BIN .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 
    LOOKIN LOOKUP uemit ukey char delim names TASK REG @WORD SPIN | || , [W] 
    ["] NULL$ $! $= 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 IDLE .VER TAQOZ TERM AUTO SPIRD 
    SPIRDL SPIWB SPIWR SPICE SPIWC SPIWW SPIWS SPIPINS SPIRX SPITXE SPITX CLKIN 
    CLKOUT CLOCK WSLED WAIT CLKDIV RCSLOW HUBSET WP WE CLKHZ CLKMHZ BUFFERS 
    ROM IRQVEC PTRA PTRB DIRA DIRB OUTA OUTB INA INB ERROR END  394 ok
    

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    P2 SHORTFORM DATASHEET +++++ TAQOZ documentation
    Brisbane, Australia
  • Cluso99Cluso99 Posts: 13,769
    edited May 4 Vote Up0Vote Down
    Sssh. I might find something ;)

    BTW I think all those serial problems were to do with the Interrupt stealing some input characters.

    Did you remove, or make the ascii terminal controls optional ?
  • Cluso99Cluso99 Posts: 13,769
    Peter,
    Am I correct in recalling that TAQOZ interprets the input as it's being entered?

    What did you squeeze to save that space?
  • Yes, all delimited words are tested for numbers first or the dictionary is searched and if not an immediate word (IF/THEN etc) then the wordcode is compiled. On a CR the compiled code is either executed or if it is part of a definition then the code pointer is simply advanced to continue to compile as part of a definition.

    I removed all the ANSI for starters. I'd like to the SPLAT logic analyzer if I can. Anyone with a terminal can capture port signals and display them easily.

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    P2 SHORTFORM DATASHEET +++++ TAQOZ documentation
    Brisbane, Australia
  • David BetzDavid Betz Posts: 12,197
    edited May 4 Vote Up0Vote Down
    Cluso99 wrote: »
    Monitor Commands... (spaces for clarity and optional)
    
    xxxxxx.xxxxxx L <cr>      List cog/lut/hub from addr to addr
    
    xxxxx - xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 'xxxxxxxxxxxxxx' <cr>   Store in cog/lut/hub (no. of bytes optional, ascii optional)
    xxxxx G <cr>  Goto/jump to addr in cog/lut/hub
    
    Q <cr>        Quit (return to users calling program) - currently responds "!" and jumps back to monitor code
    
    
    examples(spaces optional)
     
    0 L <cr>               lists cog $000
    200 L <cr>             lists lut $200
    0000 L <cr>            lists hub $00000
    1000.1080 L <cr>       lists hub $1000 to $1080
    
    000- 11 22 33 44 55667788 <cr>   stores in cog (note the reversal of the long $55667788)
    
    The file _BOOT_P2.BIX.spin2 needs to be renamed (remove ".spin2" - forum requirement) and copied to an SD card. It flashes a LED on P5.
    Your monitor commands look like Forth with arguments first followed by a command. May as well just let TAQOZ do the job.

  • Cluso's debugger is used to debug other software. TAQOZ does have extensive debug words but it may not be compatible with the memory footprint of the user's code.
    TAQOZ# 0 $20 COG DUMP 
    00.0000:  FDAF.DA68 FD90.00C0 0000.0000 0000.0000  0000.0000 0000.0000 0000.0000 0000.0000 
    00.0008:  0000.0000 0000.FE00 0000.0000 0000.DC04  0000.0050 4000.0032 0000.B9B8 0000.4404 
    00.0010:  0000.0000 0000.0001 0000.0021 0000.0032  0000.0042 0000.0001 0000.0000 0000.0000 
    00.0018:  0000.0000 0000.0000 0000.0050 0000.0000  0000.0000 0000.DA43 0000.FBFF 0000.FCFF  ok
    TAQOZ# 0 $20 LUT DUMP 
    00.0000:  0000.0000 DEAD.BEEF 0000.0000 DEAD.BEEF  DEAD.BEEF 0000.DEAD FFFF.FFFF FFFF.FFFF 
    00.0008:  0000.0000 FFFF.FFFF 0000.0000 FFFF.FFFF  0000.0041 0000.0041 0000.0041 0000.0041 
    00.0010:  AD65.FE28 AB04.0000 8D9F.F7B4 F527.F403  FD64.0025 F606.CA00 F606.CC00 FD64.7E40 
    00.0018:  FC0C.7C3F FC0C.F83E FD64.7C41 FC06.7C01  FC06.7E00 FC1C.0200 FC2C.0000 FD67.0020  ok
    TAQOZ# 0 $40 DUMP 
    00.0000: FF FF 3C 00 00 00 FF FF FF FF 00 00 56 06 56 06    ..<.........V.V.
    00.0010: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20                    
    00.0020: 20 20 09 09 09 2D 2D 2D 20 53 65 74 75 70 20 61      ...--- Setup a
    00.0030: 20 70 6F 69 6E 74 65 72 20 74 6F 20 74 68 65 20     pointer to the  ok
    TAQOZ# 0 $100 DUMPAW 
    00.0000: ..<.........d.d.                  ...--- Setup a pointer to the raw file starting sector...  DUP $24 SD!......--- write the file
    00.0080:  size we are using...  diradr @FILE @ $28 SD!.....--- save 64GB encoded pointer to the directory entry..\.  TIME. $30 SD!......- ok
    TAQOZ#
    

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    P2 SHORTFORM DATASHEET +++++ TAQOZ documentation
    Brisbane, Australia
  • Cluso99Cluso99 Posts: 13,769
    edited May 4 Vote Up0Vote Down
    David,
    Those commands were built with a group of user callable commands to send characters, hex, string, and read characters, strings, etc. So, it's like a bios for serial. The monitor is just the user friendly (from a command line terminal) section of those calls. I did strip quite a bit of functionality out though.

    My understanding is that TAQOZ is more of an alternative language that can be used to test out the hardware. I know Peter is using it to construct real programs but unfortunately I don't expect a lot of users to do this. But it's a great interactive development tool that will hopefully get a lot of people into P2.
  • David BetzDavid Betz Posts: 12,197
    edited May 4 Vote Up0Vote Down
    Cluso's debugger is used to debug other software. TAQOZ does have extensive debug words but it may not be compatible with the memory footprint of the user's code.
    TAQOZ# 0 $20 COG DUMP 
    00.0000:  FDAF.DA68 FD90.00C0 0000.0000 0000.0000  0000.0000 0000.0000 0000.0000 0000.0000 
    00.0008:  0000.0000 0000.FE00 0000.0000 0000.DC04  0000.0050 4000.0032 0000.B9B8 0000.4404 
    00.0010:  0000.0000 0000.0001 0000.0021 0000.0032  0000.0042 0000.0001 0000.0000 0000.0000 
    00.0018:  0000.0000 0000.0000 0000.0050 0000.0000  0000.0000 0000.DA43 0000.FBFF 0000.FCFF  ok
    TAQOZ# 0 $20 LUT DUMP 
    00.0000:  0000.0000 DEAD.BEEF 0000.0000 DEAD.BEEF  DEAD.BEEF 0000.DEAD FFFF.FFFF FFFF.FFFF 
    00.0008:  0000.0000 FFFF.FFFF 0000.0000 FFFF.FFFF  0000.0041 0000.0041 0000.0041 0000.0041 
    00.0010:  AD65.FE28 AB04.0000 8D9F.F7B4 F527.F403  FD64.0025 F606.CA00 F606.CC00 FD64.7E40 
    00.0018:  FC0C.7C3F FC0C.F83E FD64.7C41 FC06.7C01  FC06.7E00 FC1C.0200 FC2C.0000 FD67.0020  ok
    TAQOZ# 0 $40 DUMP 
    00.0000: FF FF 3C 00 00 00 FF FF FF FF 00 00 56 06 56 06    ..<.........V.V.
    00.0010: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20                    
    00.0020: 20 20 09 09 09 2D 2D 2D 20 53 65 74 75 70 20 61      ...--- Setup a
    00.0030: 20 70 6F 69 6E 74 65 72 20 74 6F 20 74 68 65 20     pointer to the  ok
    TAQOZ# 0 $100 DUMPAW 
    00.0000: ..<.........d.d.                  ...--- Setup a pointer to the raw file starting sector...  DUP $24 SD!......--- write the file
    00.0080:  size we are using...  diradr @FILE @ $28 SD!.....--- save 64GB encoded pointer to the directory entry..\.  TIME. $30 SD!......- ok
    TAQOZ#
    
    I see. It's too bad TAQOZ couldn't be made to run from the 16K "ROM" area. Wouldn't it just take one additional instruction (add on a base address) to get your word codes working from a higher address?

  • I could get it "working" sorta but if I try to extend it when I interact and create new words outside of that area then I'm in trouble. But there would a whole lot of things to think about and document if it we made to run in that area too for the reason that it would be co-resident with user code. How much time do we have? Not enough...

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    P2 SHORTFORM DATASHEET +++++ TAQOZ documentation
    Brisbane, Australia
  • I could get it "working" sorta but if I try to extend it when I interact and create new words outside of that area then I'm in trouble. But there would a whole lot of things to think about and document if it we made to run in that area too for the reason that it would be co-resident with user code. How much time do we have? Not enough...
    I guess the non-linear memory map doesn't help much with the 16K "ROM" area way at the top of the address space. If it were just at the top of 512K then you could set the base address at 512K-64K and put all of the core words in the last 16K. Then you'd have the remaining 48K for user extensions which is what you get if you zero as your base address.

  • Cluso99Cluso99 Posts: 13,769
    As I understand TAQOZ, they are lots of tiny executables. If they are not on the bottom 64KB, then every time you go to run a little executable, of just a couple of instructions, you have to add a base address. So every few instructions, you add another one for overhead. That's going to slow the amazing speed significantly.
    Peter has built an amazing piece of code, but it just needs to run at the bottom 64KB.
  • Cluso99 wrote: »
    As I understand TAQOZ, they are lots of tiny executables. If they are not on the bottom 64KB, then every time you go to run a little executable, of just a couple of instructions, you have to add a base address. So every few instructions, you add another one for overhead. That's going to slow the amazing speed significantly.
    Peter has built an amazing piece of code, but it just needs to run at the bottom 64KB.
    I had originally envisioned TAQOZ as a programmable monitor for the P2. I don't think it is absolutely essential that it be blindingly fast. I imagine that when Peter or anyone else wants to write a full application in Forth they will use full Tachyon not what is in the ROM. As it stands now we get a simple monitor and a stripped down implementation of a programming language.
Sign In or Register to comment.