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

P2 SD Boot Code (v32+)

124

Comments

  • evanh wrote: »
    Or just a second partition would do the same job.

    I am not sure that is true. The onboard controller operates beneath all of that. And it appears those things are a significant corruption source.
    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: http://forums.parallax.com/showthread.php?123709-Commented-Graphics_Demo.spin<br>
  • I was presuming both SD slots to be direct to two sets of Prop2 pins in Chip's scenario above. I was pointing out there wasn't any need to have the extra pins used to get just as good reliability.

    “What car did you learn to drive stick shift on?” == “What was the make and model of your first car?” -> Password reset! -- https://krebsonsecurity.com/2018/04/dont-give-away-historic-details-about-yourself/
  • Oh, agreed there. Didn't see where you were going with that.

    :D
    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: http://forums.parallax.com/showthread.php?123709-Commented-Graphics_Demo.spin<br>
  • Requiring 2 SD cards so that I can write to one of them doesn't make a lot of sense. Might as well boot from flash, and then use an SD card for read/write. I like the idea of using two partitions -- one for boot, and another one for read and write. The other possibility is to put the boot code in some sectors that aren't part of the FAT file system.
  • Don't mess with the FAT and all is well. You need to go about it the "write" way. My file create routines can preallocate whatever might be needed and the other thing is I don't mess with is the filesize in the directory constantly, just log away and mark the end of file, either as nulls or a signature, aligned or not. So I can read and write and at the very very worst I might lose a sector of data but not corrupt the formatting. However, I've never at that happen anyway.
    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    Tachyon Forth News Blog
    TAQOZ documentation
    Brisbane, Australia
  • When working on my RAISD-Kit years ago I stress-tested a lot of SD cards. The RAISD-Kit has 4 SD slots and I tested the whole RAID spectrum just for the fun of it.

    Usually data corruption on SD cards happen in the FAT32 File-System. I never had a problem to read any sector, never had any unexplainable losses. If cards got corrupted it was always open files, not rewritten/updated FAT-Entries/directory entries.

    The block access never failed to finish, never corrupted anything, I unplugged/reset/removed cards while in use, ABUSED them as much as I could but I never had corrupted sectors.

    As Peter mentioned for use on a MC fixed continuous files in the FAT and 'virtual memory' like access is a nice compromise between still PC usable and fast access from the MC without the overhead of FAT32.

    I personally really like the MBR boot. It is (sort of) protected from FAT32 and usually none OS will harm a MBR. It might even work with other File Systems.

    But I want to explain that SD cards are not unreliable by themselves, the used File System is picky when not un-mounted or file sizes not correctly updated or whatever may happen.

    So there is no need for two SD cards. As far as I know Windows will just mount and show the first partition of a SD card, A two partition solution could hide the OS partition easy.

    And the MBR boot loader loads a second stage loader that knows the sector address in the second partition.

    All there, right now.

    Thank you very, very much @Cluso99.

    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.
  • cgraceycgracey Posts: 9,027
    edited April 15 Vote Up0Vote Down
    Thanks, Mike. That's a lot of useful information.
  • SD Boot code update...

    Loads code from MBR and VOL sectors if 128 bytes from offset $080-$17F checksums to "Prop"

    If checksum is valid, the sector is copied from Hub $00000-$001FF to Cog $000-$07F followed by a JMP $020 in Cog (this is the code copied from hub $080).

    I have forced the checksum comparison (as it's not correct on my SD card) and it works as expected. I have a small routine in the MBR to flash a led at offset $080 ;)

    I have tidied the directory walking. It now searches up to a cluster (64 sectors usually) for the two filename entries. Once an unused directory entry the search is abandoned. Also I am checking the file attributes allowing Read Only, Hidden, System, Archive, but disallows Volume, LongFile, Directory.
  • Cluso99Cluso99 Posts: 13,635
    edited April 17 Vote Up0Vote Down
    Chip,
    Here is the SD ROM Boot code "Beta" version v124e.

    I expect it to be loaded into Cog and run after the pullup on CSn and pulldown on CLK have been validated. Currently it does not return if there is an SD error or no valid code exists - see the label ".loop_here" in the hubexec portion of the code.

    The hubexec portion of the code needs to remain in the protected hub section (ie top 16KB of hub ram) as it needs to be able to overwrite the cog code with loaded code in hub from $0 upwards.
    NOTE: Currently this code is defined as
    _HUBEXEC_code = $0_F000
    in order for the code to work when being compiled and downloaded by pnut.

    More to follow...
  • Here are the files to be stored in an SD Card

    _BOOT_P2.BIX is a 1 sector FAT file (512 bytes) that is read into hub $0 and then loaded into Cog $0 and executed by JMP #$0

    _BOOT_P2.BIY is a 64 sector 32KB FAT file that is read into hub $0 and then loaded into Cog $0 and executed by JMP #$0

    Both files flash a set of RGB LEDs (in rotation at 1 second intervals) that I have attached to P5, 9 & 7 respectively, active high.

    _BOOT_P2.BIX is searched first, then if not found, _BOOT_P2.BIY is searched. If found, the whole file_size is loaded into hub starting at $0.
    Currently if it is bigger than $F000 it will overwrite the hubexec loader!

    SD_MBR_VOL.txt contains the dump of my MBR sector 0, and VOL sector 8192.
    The relevant section that must be copied is the section offset $080-$17F.
    MBR flashes the green led at 2 seconds, VOL flashes the blue led at 2 seconds.
    I used HxD to overwrite the MBR and VOL card - you need to run HxD in administrator mode!!
    Neither has the correct checksum. Patch my SD Boot code at validate_csum to enforce the correct checksum
    '+-----------------------------------------------------------------------------+
    ' Validate MBR/VOL CSUM $080-$17F="Prop". If valid, copy to Cog & Run
    '+-----------------------------------------------------------------------------+
    validate_csum
                    mov     replyR1,          #0            ' csum=0
                    mov     bufad,            #$80          '\ set to sum $080-$17F
                    mov     bytescnt,         #(256/4)      '/
    .sum            rdlong  reply,            bufad
                    add     replyR1,          reply         ' accum csum
                    add     bufad,            #4
                    djnz    bytescnt,         #.sum
                    cmp     replyR1,          _csum     wz  ' ="Prop"?
    '''                cmp     replyR1,        ##$C38BDD1A wz  ' MBR force equal !!!!!!        greeen
    '''                cmp     replyR1,        ##$E1C56A6D wz  ' VOL force equal !!!!!!        blue
    '+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++               
            if_e    jmp     #_success80                     ' load cog & jmp #$020
    '+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++               
    validate_csum_ret
                    ret 
    '+-----------------------------------------------------------------------------+
    
  • jmgjmg Posts: 11,273
    I've not seen sizes of this SD boot + TAQOZ - is the idea still to have both in the ROM ?
  • SD Boot timing...

    ~1,320,000 clocks using the default RC oscillator (what is the frequency on the FPGA?)

    At 80MHz that rounds out to be ~16.5ms. However, this is not entirely accurate as a large part of the time is waiting for the card.
  • Code sizes rounded up

    Cog code 1424 bytes (includes 144 variables define as $0)

    Hub code 80 bytes (w/o hub initialisation ie w/o testing pullup/pulldown and copy to cog and execute)
  • Cluso99Cluso99 Posts: 13,635
    edited April 17 Vote Up0Vote Down
    I have the fix to limit the file load size. It's just a line of code and an equate. Not worth posting at this time.
  • Does anyone have an SDXC card?
    I would like to get one checked out with the older debugging code.
  • Great, Cluso99!

    I will look at this tomorrow, hopefully.

    All day was spent on the I/O pad timing characterization with On Semi. Probably some time tomorrow will go there, as well. It's just complicated.
  • Thanks Chip.

    OnSemi work sounds interesting :)

    I tried to combine it with the existing boot code.

    I was unsure how I would know if the jumps from the cog code would jump back to hub and not substitute a cog address which would be invalid.

    I have made all of the variables a RES 1 excepting two which I am unsure of needing to be preset to 0 (SDtype and blocksh). I will post this code tonight when I get home from work.
  • msrobotsmsrobots Posts: 1,919
    edited April 18 Vote Up0Vote Down
    I do find it wrong that you restrict the sd loader to NOT load the ROM area.

    If someone wants to boot from sd he might neither need TAQOZ nor any other rom content.

    One should be able to load the complete HUB image of 512KB at boot time...

    just saying,

    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.
  • Seconded.

    We should offer a full image option, just take it over, same as P1.

    That's gonna be used an awful lot. Vast majority scenario. Seems a shame to complicate doing that.
    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: http://forums.parallax.com/showthread.php?123709-Commented-Graphics_Demo.spin<br>
  • msrobots wrote: »
    I do find it wrong that you restrict the sd loader to NOT load the ROM area.

    If someone wants to boot from sd he might neither need TAQOZ nor any other rom content.

    One should be able to load the complete HUB image of 512KB at boot time...

    just saying,

    Mike
    Where do you think some of the boot code is residing? It's in the ROM.

    Secondly, the boot ROM is protected. You need to unprotect the ROM first.

    And last of all, the RAM is mirrored in the first P2, at 512KB. So who is going to decide if the code you load into the (512-16)KB block is for (512-16)B or for (1024-16)KB? You will need to build it this way.

    So, if you require to load the whole 512KB, you will need a second stage loader, which is no real biggie anyway.

  • My current boot ROM code sits entirely in the cog, so that the entire hub memory may be loaded.

    I'm still wrapped up in the characterization of our I/O pin. I don't know when this will be over. In the meantime, we have until next Friday to get the ROM together.
  • Cluso99Cluso99 Posts: 13,635
    edited April 18 Vote Up0Vote Down
    cgracey wrote: »
    My current boot ROM code sits entirely in the cog, so that the entire hub memory may be loaded.

    I'm still wrapped up in the characterization of our I/O pin. I don't know when this will be over. In the meantime, we have until next Friday to get the ROM together.

    My SD Boot code, at least currently, has a small portion that must reside in HUB ROM area. It's the bit that copies the lower hub $0 to cog $0 and then jumps to cog $0/$20 for execution. If there is an error from the SD routines, they also need to jump to hub to run the serial code.

    Maybe that can be changed, but then we have the dilema of whether the top 16KB is protected or not.

    Chip,
    Firstly, I presume you mean Friday week 27th.

    When you get time, can you answer the following (I am trying to save a cog long so that a list of variables only takes an even 16 longs)...
    _sendfirst      wypin   lmm_x, #_txpin       ' send byte to tx pin
    
    If the smartpins are setup to transmit 8 bit characters, what happens if the character loaded with wypin (lmm_x in above example) has other bits set (eg $3700ff35 to transmit $35)? ie are higher order bits ignored?
  • cgraceycgracey Posts: 9,027
    edited April 18 Vote Up0Vote Down
    Cluso99 wrote: »
    cgracey wrote: »
    My current boot ROM code sits entirely in the cog, so that the entire hub memory may be loaded.

    I'm still wrapped up in the characterization of our I/O pin. I don't know when this will be over. In the meantime, we have until next Friday to get the ROM together.

    My SD Boot code, at least currently, has a small portion that must reside in HUB ROM area. It's the bit that copies the lower hub $0 to cog $0 and then jumps to cog $0/$20 for execution. If there is an error from the SD routines, they also need to jump to hub to run the serial code.

    Maybe that can be changed, but then we have the dilema of whether the top 16KB is protected or not.

    Chip,
    Firstly, I presume you mean Friday week 27th.

    When you get time, can you answer the following (I am trying to save a cog long so that a list of variables only takes an even 16 longs)...
    _sendfirst      wypin   lmm_x, #_txpin       ' send byte to tx pin
    
    If the smartpins are setup to transmit 8 bit characters, what happens if the character loaded with wypin (lmm_x in above example) has other bits set (eg $3700ff35 to transmit $35)? ie are higher order bits ignored?

    Yes, they get ignored. Accommodation is there for 32 bits of data, whether or not they are all used.
  • Here are some hubexec routines for possible inclusion in the P2 ROM...

    This is the user cog code that calls the hubexec routines to output serial (to PST)
                    orgh    0
                    org     0
    
    entry
                    hubset  #$FF                            'set clock to 80MHz
                    nop
    
    ''---------------------------------------------------------------------------------------------------
    '' display debug SD info to PST...
    ''---------------------------------------------------------------------------------------------------
    'a 5 sec delay mechanism only (allows PST to start)
                    getct   delay
                    addct1  delay,          ##_clockfreq*5  ' 5s
                    waitct1               
    ''---------------------------------------------------------------------------------------------------
    'this call is required to start the serial driver (note a <cr> is sent to kick off the smart pin)
                  mov       lmm_x,            ##_bitper     ' 115200 baud, 8 bits
                  call      #_serialinit                    ' init serial P63/P62 & send <cr>
    ''---------------------------------------------------------------------------------------------------
                  mov     lmm_x,              #cls          ' clear screen
                  call    #_hubTx         
    
                  mov       lmm_f,            #_TXSTRING+0  ' send string, $00 terminated
                  mov       lmm_p,            ##_str_vers   ' (uses 2 instructions)
                  call      #_hubTxString
    ''---------------------------------------------------------------------------------------------------
    ' COG:
                  mov       lmm_x,            ##(cr + "C"<<8 + "O"<<16 + "G"<<24)
                  call      #_hubTx
    
                  mov       lmm_f,  #_LIST+_ADDR2+_HDG+_MON ' list count w heading monitor
                  mov       lmm_p,            ##$000        ' fm addr (uses 2 instructions)
                  mov       lmm_p2,           ##$01F        ' to addr
                  call      #_HubList
    ''---------------------------------------------------------------------------------------------------
    ' LUT:
                  mov       lmm_x,  ##(cr + "L"<<8 + "U"<<16 + "T"<<24)
                  call      #_hubTx
    
                  mov       lmm_f,  #_LIST+_ADDR2+_HDG+_MON ' list count w heading monitor
                  mov       lmm_p,            ##$200        ' fm addr (uses 2 instructions)
                  mov       lmm_p2,           ##$21F        ' to addr
                  call      #_HubList
    ''---------------------------------------------------------------------------------------------------
    ' HUB:
                  mov       lmm_x,  ##(cr + "H"<<8 + "U"<<16 + "B"<<24)
                  call      #_hubTx
    
                  mov       lmm_f,  #_LIST+_ADDR2+_HDG+_MON ' list count w heading monitor
                                                            ' $1_xxxxx tricks to force hub :)
                  mov       lmm_p,            ##$1_00000    ' fm addr (uses 2 instructions)
                  mov       lmm_p2,           ##$1_0007F    ' to addr
                  call      #_HubList
    ''---------------------------------------------------------------------------------------------------
    ' HUB:
                  mov       lmm_x,  ##(cr + "H"<<8 + "U"<<16 + "B"<<24)
                  call      #_hubTx
    
                  mov       lmm_f,  #_LIST+_ADDR2+_HDG+_MON ' list count w heading monitor
                  mov       lmm_p,            ##$04000      ' fm addr (uses 2 instructions)
                  mov       lmm_p2,           ##$0407F      ' to addr
                  call      #_HubList
    ''---------------------------------------------------------------------------------------------------
                  mov       lmm_x,            #cr
                  call      #_hubTx
    ''---------------------------------------------------------------------------------------------------
    .here         jmp       #.here
    ''---------------------------------------------------------------------------------------------------
    
    delay         long      0
    
    
    ''################################################################################################
    ''##    COG LMM hard coded to   $1E0-$1EF               ' (Location is fixed))                  ##
                    long    $3D3D3D3D[$1E0-$]               ' fill with "====" (if any)                   
    ''################################################################################################
                    fit     $1E0
    ''-------[ LMM parameters, etc ]-----------------------------------------------------------------
    lmm_x           long    0       ' parameter passed to/from LMM routine (typically a value)
    lmm_f           long    0       ' parameter passed to      LMM routine (function options; returns unchanged)
    lmm_p           long    0       ' parameter passed to/from LMM routine (typically a hub/cog ptr/addr)
    lmm_p2          long    0       ' parameter passed to/from LMM routine (typically a 2nd hub/cog address)
    lmm_c           long    0       ' parameter passed to/from LMM routine (typically a count)
    ''-------[ LMM additional workareas ]------------------------------------------------------------
    lmm_w           long    0        ' workarea (never saved - short term use between calls, except _HubTx)
    lmm_tx          long    0        ' _HubTx                       
    lmm_hx          long    0        ' _HubHex/_HubString                       
    lmm_hx2         long    0        ' _HubHex
    lmm_hc          long    0        '   "
    lmm_lx          long    0        ' _HubList
    lmm_lf          long    0        '   "
    lmm_lp          long    0        '   "
    lmm_lp2         long    0        '   "
    lmm_lc          long    0        '   "
    lmm_lc2         long    0        '   "
    ''-----------------------------------------------------------------------------------------------
                    fit     $1F0
    
    And here is the output captured by PST
    === Cluso's P2v32 Debugger v.0001a ===
    
    COG
     addr-  0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
     -----------------------------------------------------
      000: 00 FE 65 FD 00 00 00 00 1A 6C 60 FD C2 EB 0B FF  '..e......l`.....'
      004: 00 6C 64 FA 24 22 60 FD 00 5B 01 FF 07 C0 07 F6  '.ld.$"`..[......'
      008: 00 40 A0 FD 00 C0 07 F6 48 40 A0 FD 80 C2 07 F6  '.@......H@......'
      00C: 22 00 00 FF 5A C4 07 F6 DC 40 A0 FD A1 A7 23 FF  '"...Z....@....#.'
      010: 0D C1 07 F6 48 40 A0 FD 74 C2 07 F6 00 00 00 FF  '....H@..t.......'
      014: 00 C4 07 F6 00 00 00 FF 1F C6 07 F6 FC 40 A0 FD  '.............@..'
      018: A6 2A 2A FF 0D C0 07 F6 48 40 A0 FD 74 C2 07 F6  '.**.....H@..t...'
      01C: 01 00 00 FF 00 C4 07 F6 01 00 00 FF 1F C6 07 F6  '................'
    
    LUT
     addr-  0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
     -----------------------------------------------------
      200: 41 00 00 00 41 00 00 00 7E 00 00 00 41 00 00 00  'A...A...~...A...'
      204: 41 00 00 00 41 00 00 00 41 00 00 00 41 00 00 00  'A...A...A...A...'
      208: 41 00 00 00 41 00 00 00 41 00 00 00 41 00 00 00  'A...A...A...A...'
      20C: 41 00 00 00 41 00 00 00 41 00 00 00 41 00 00 00  'A...A...A...A...'
      210: 28 FE 65 AD 00 00 04 AB B4 F7 9F 8D 03 F4 27 F5  '(.e...........'.'
      214: 25 00 64 FD 00 CA 06 F6 00 CC 06 F6 40 7E 64 FD  '%.d.........@~d.'
      218: 3F 7C 0C FC 3E F8 0C FC 41 7C 64 FD 01 7C 06 FC  '?|..>...A|d..|..'
      21C: 00 7E 06 FC 00 02 1C FC 00 00 2C FC 20 00 67 FD  '.~........,. .g.'
    
    HUB
     addr-  0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
     -----------------------------------------------------
    00000: 00 FE 65 FD 00 00 00 00 1A 6C 60 FD C2 EB 0B FF  '..e......l`.....'
    00010: 00 6C 64 FA 24 22 60 FD 00 5B 01 FF 07 C0 07 F6  '.ld.$"`..[......'
    00020: 00 40 A0 FD 00 C0 07 F6 48 40 A0 FD 80 C2 07 F6  '.@......H@......'
    00030: 22 00 00 FF 5A C4 07 F6 DC 40 A0 FD A1 A7 23 FF  '"...Z....@....#.'
    00040: 0D C1 07 F6 48 40 A0 FD 74 C2 07 F6 00 00 00 FF  '....H@..t.......'
    00050: 00 C4 07 F6 00 00 00 FF 1F C6 07 F6 FC 40 A0 FD  '.............@..'
    00060: A6 2A 2A FF 0D C0 07 F6 48 40 A0 FD 74 C2 07 F6  '.**.....H@..t...'
    00070: 01 00 00 FF 00 C4 07 F6 01 00 00 FF 1F C6 07 F6  '................'
    
    HUB
     addr-  0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
     -----------------------------------------------------
    04000: 00 00 80 FF 3E F8 0C FC 3E C0 17 FC 41 7C 64 FD  '....>...>...A|d.'
    04010: 00 00 80 FF 3F 7C 0C FC 3F C0 17 FC 41 7E 64 FD  '....?|..?...A~d.'
    04020: 0D C0 07 F6 08 00 90 FD 40 7C 74 FD F8 FF 9F 3D  '........@|t....='
    04030: 3E C0 27 FC 2D 00 7C FD 40 7E 74 FD F8 FF 9F 3D  '>.'.-.|.@~t....='
    04040: 3F C0 8F FA 2D 00 7C FD E0 CD 03 F6 E0 CB 03 F6  '?...-.|.........'
    04050: FF C0 07 F5 D0 FF BF FD E5 C1 03 F6 08 C0 4F F0  '..............O.'
    04060: E8 FF 9F 5D E6 C1 03 F6 2D 00 7C FD E0 CF 03 F6  '...]....-.|.....'
    04070: E4 D3 03 F6 10 C2 CF F7 1B C0 FF 59 E1 C9 03 F6  '...........Y....'
    
  • The hubexec code uses $480 bytes (1152).

    I need to dig out my read string routine if I have time.
  • cgracey wrote: »
    Cluso99 wrote: »
    cgracey wrote: »
    My current boot ROM code sits entirely in the cog, so that the entire hub memory may be loaded.

    I'm still wrapped up in the characterization of our I/O pin. I don't know when this will be over. In the meantime, we have until next Friday to get the ROM together.

    My SD Boot code, at least currently, has a small portion that must reside in HUB ROM area. It's the bit that copies the lower hub $0 to cog $0 and then jumps to cog $0/$20 for execution. If there is an error from the SD routines, they also need to jump to hub to run the serial code.

    Maybe that can be changed, but then we have the dilema of whether the top 16KB is protected or not.

    Chip,
    Firstly, I presume you mean Friday week 27th.

    When you get time, can you answer the following (I am trying to save a cog long so that a list of variables only takes an even 16 longs)...
    _sendfirst      wypin   lmm_x, #_txpin       ' send byte to tx pin
    
    If the smartpins are setup to transmit 8 bit characters, what happens if the character loaded with wypin (lmm_x in above example) has other bits set (eg $3700ff35 to transmit $35)? ie are higher order bits ignored?

    Yes, they get ignored. Accommodation is there for 32 bits of data, whether or not they are all used.

    Thanks Chip. I had hoped so ;)
  • Cluso99Cluso99 Posts: 13,635
    edited April 19 Vote Up0Vote Down
    I have Rx (char) and RxString working (handles backspace, <cr> ends input.

    They are ready to go if there is ROM space. I will post the calls and their formats shortly.

    BTW there is a slot to patch in a disassembler. I had this working on IIRC v10.
  • Calls in my possible "monitor/debugger" candidate to be included in the P2 ROM
    ''-------[ 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)
    ''--------------------------------------------------------------------------------------------------
    ''-------[ Display Char(s) ]--------------------------------------------------- <--- display char(s) --->
    ''_HubTx                                                '                       
    '' On Entry:
    ''      lmm_x = char(s)                                 ' char(s): up to 4 chars; B0 first; <nul> terminates
    ''                                                      '            if =$0, tx one <nul>
    '' Call Format:
    ''            CALL      #_HubTx                         '                       < call: display char(s)>
    '' On Return:
    ''      lmm_x = -same-                                  ' char(s):  (unchanged)
    ''--------------------------------------------------------------------------------------------------
    ''-------[ Display Hex ]------------------------------------------------------- <--- display hex --->
    ''_HubHex                                               '                       
    '' On Entry:
    ''      lmm_f = _HEX [+options]                         ' mode:  #_HEX[+_REV][+_SP][+_ndigits]
    ''                                                      '        'n' digits = 7..0 where 0 = 8 digits
    ''      lmm_x = char(s)                                 ' char(s): 
    '' Call Format:
    ''            CALL      #_HubHex                        '                       < call: display hex >
    '' On Return:
    ''      lmm_f = -same-                                  ' mode:     (unchanged)
    ''      lmm_x = -same-                                  ' char(s):  (unchanged)
    ''--------------------------------------------------------------------------------------------------
    ''-------[ Display String, <nul> terminated ]---------------------------------- <--- display string --->
    ''_HubTxString                                          '
    '' On Entry:
    ''      lmm_f = #_TXSTRING [+options]                   ' mode:   #_TXSTRING
    ''      lmm_p = 'addr'                                  ' addr:   string (hub ptr)
    '' Call Format:
    ''            CALL      #_HubTxString                   '                       < call: display string>
    '' On Return:
    ''      lmm_f = -same-                                  ' mode:   (unchanged)
    ''      lmm_p = 'addr' (next string)                    ' addr:   (hub ptr to next string)
    ''--------------------------------------------------------------------------------------------------
    ''-------[ LIST a line ]------------------------------------------------------- <--- LIST a line --->
    ''_HubList
    '' On Entry:
    ''      lmm_f   = #_LIST [+options]                     ' mode:         _LIST[+_{ADDR2|COUNT}][+_HDG][+_{MON|SMON|CODE|LONG}]
    ''      lmm_p   = 'addr'        (from)                  ' addr:    from cog addr / hub ptr
    ''      lmm_p2  = 'addr2'       (to)    (optional)      ' addr2:   to   cog addr / hub ptr (if _ADDR2 specified)
    ''      lmm_c   = 'count'       (count) (optional)      ' count:   'n' lines (hex)         (if _COUNT specified)
    ''                                                      '          Note: only addr2 or count may be specified, not both!
    '' Call Format:
    ''             CALL     #_HubList                       '                       < call: LIST a line >
    '' On Return:
    ''      lmm_f   = same except _HDG off                  ' mode:    same except _HDG will be off
    ''      lmm_p   = addr++        (from)                  ' addr:    next from cog addr / hub ptr
    ''      lmm_p2  = addr2++/same  (to)                    ' addr2:   next to addr -OR- unchanged
    ''      lmm_c   = -same-        (count)                 ' count:   (unchanged)  
    ''---------------------------------------------------------------------------------------------------
    ''-------[ Rx: Receive a char ]------------------------------------------------ <--- receive char --->
    ''_HubRx
    '' On Entry:
    ''      lmm_x = -anything-                              ' value:
    '' Call Format:
    ''             CALL     #_HubRx                         '                       < call: receive char>
    '' On Return:
    ''      lmm_x = char                                    ' char:   input char
    ''--------------------------------------------------------------------------------------------------
    ''-------[ Receive String ]---------------------------------------------------- <--- receive string --->
    ''_HubRxString
    '' On Entry:
    ''      lmm_f = #_RXSTRING [+options]                   ' mode:   #_RXSTRING[+_ECHO][+_PROMPT][+_ADDR][+_NOLF]
    ''      lmm_x = char(s)                 (optional)      ' prompt: char(s)               
    ''      lmm_p = 'addr'                  (optional)      ' addr:   input string (hub ptr)
    '' Call Format:
    ''            CALL      #_HubRxString                   ' \                     < call: receive string >
    '' On Return:
    ''      lmm_f = -same-                                  ' mode:   (unchanged)
    ''      lmm_x = -same-                                  ' 
    ''      lmm_p = 'addr'                                  ' addr:   input string (hub ptr)
    ''      lmm_c = 'count'                                 ' count:  char(s) entered (incl <cr>, excl <nul>)
    ''--------------------------------------------------------------------------------------------------
    
    The following is normally used internally by _HubList
    ''-------[ Read Cog/Hub Long ]------------------------------------------------- <--- read: cog/hub long --->
    ''_RdLongCogHub
    '' On Entry:
    ''      lmm_x   = -anything-                            ' 'long':
    ''      lmm_p   = 'addr'                                ' 'addr':  cog addr / hub ptr
    '' Call Format:
    ''              CALL    #_RdLongCogHub                  '                       < call: read cog/hub long >
    '' On Return:
    ''      lmm_x   = 'long'                                ' 'long':  read from cog/hub
    ''      lmm_p   = 'addr++'                              ' 'addr++' cog addr++ / hub ptr++
    '---------------------------------------------------------------------------------------------------
    
  • SD Boot code now resides in Hub and runs as hubexec until the user code is loaded and run.
    It uses 32 longs as variable workareas in cog only.
  • Cluso99 wrote: »
    SD Boot code now resides in Hub and runs as hubexec until the user code is loaded and run.
    It uses 32 longs as variable workareas in cog only.

    Okay. Where is it posted?

    Is your confidence level pretty high, at this point?

    I need to learn how to run it and tie it to my ROM code.
Sign In or Register to comment.