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.
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.
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.
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.
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.
_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
'+-----------------------------------------------------------------------------+
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.
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.
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?
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.
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.
Comments
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.
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
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.
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...
_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 '+-----------------------------------------------------------------------------+~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.
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)
I would like to get one checked out with the older debugging code.
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.
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.
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
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.
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.
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)... 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.
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 $1F0And here is the output captured by PSTI need to dig out my read string routine if I have time.
Thanks Chip. I had hoped so
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.
''-------[ 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++ '---------------------------------------------------------------------------------------------------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.