I've got my uSD adaptor plugged into the Prop123 board now. And it works! That's always good.
all_cogs_blink.obj boots in a blink. The 442 KB file of VGA_640_x_480_16bpp.obj takes about 9 seconds to boot.
I've noticed what appears to be a bug. The FAT32 filename search for _BOOT_P2.BIX only works for the first entry of the directory. Not much of a search if it always has to be the first entry.
Minor correction, it works when it is the first non-empty entry. Your null detect might be opposite to intended.
FPGA image used is Prop123_A9_Prop2_8cogs_v32i.rbf
evan,
I think you need to do further testing. My files are not anywhere near the start of my directory. There are 16 directory entries per sector, and in a normal 32KB cluster for FAT32 there will be 64 sectors scanned. That means a possible 1024 entries. I terminate if a long of $00000000 is found. This is the indication of the end of the directory entries. When an entry is deleted the first character of the entry has the top bit $80 set. The remaining filename is left intact. This is how undelete programs work.
There are however other entries in the directory, such as directories (folders if you like) and system entries, and long filename entries. These are all skipped.
Perhaps you need to look at the SD card with a hex disk program. Sorry, forget which one I use ATM.
Don't forget, you can use the Monitor to load or run any file.
Also, don't forget that my file names are case sensitive.
Oh, no I made too much assumption again. Linux doesn't always fill the first empty entry when adding a new filename. There was filled then unfilled before the _BOOT_P2.BIX entry.
Could be tricky in the future but you are right about the searching.
BTW While I only check for one cluster, IIRC the directory can be 2 clusters long. I figured 1024 entries was sufficient.
I was disappointed about the proprietary and complex nature of exFAT. Hopefully someone will overturn MS patents. IMHO that was old 70's technology and nothing new. Or come up with FAT64.
Hey, I wouldn't call that a fail when you are cheating somewhat. It's no different to deleting an extraneous file. Gaps in the entry list are hardly unheard of.
Hey, I wouldn't call that a fail when you are cheating somewhat. It's no different to deleting an extraneous file. Gaps in the entry list are hardly unheard of.
No. There are not supposed to be blank entries in the directory. That is one of the reasons for the way files are deleted.
Linux is a full blown os. I think shortcuts in a micro os isn't exactly in the same realm. I am pretty sure if Windows did that there would be a lot of complaints.
Anyway, that's how it is. There was time for testing and suggestions and complaints. Those days passed with only a handful of people testing.
Don't be so rushed. There really hasn't been much time to test the new stuff.
I've had a quick look at the raw data, there is MSbit markers present like you say, so I'm not yet sure why the search is failing. It looks a bit like there is some unicode for the extended filenames ...
Okay, looks like I totally shouldn't have been using any long filenames. Everything cleans up nicely when I start over and only use the 8.3 naming.
Here's what happened by reformatting then adding a single long filename as the first entry, then deleting it, then adding _BOOT_P2.PIX followed by duplicate BIY and BIZ files:
I've just noticed the Prop123 board also requires a minimum of 10 seconds of power down to boot cleanly. This could easily explain some of my earlier confusion over what combinations worked or not. I've not had to deal with this when using the comport loading.
Bah! Or not. Sometimes it just doesn't boot. Most of the time it's happy with only a couple of seconds power off.
EDIT: I'm doing <0.5 second power downs and it's about 1-in-3 attempts don't boot.
EDIT2: Ah-ha! Dug up a terminal emulator and got it toggling the DTR line for resets instead of doing power cycles. Guess what? Perfect reboots as fast as I like. Pop out the SD card and the reboot doesn't load. Put the SD card back in and perfect rapid reboots again. Happy chappy.
Okay, looks like I totally shouldn't have been using any long filenames. Everything cleans up nicely when I start over and only use the 8.3 naming.
I'm not quite following what works/does not work, and the trigger conditions here.
Can you summarize the rules around long files names and formatting steps ?
Bah! Or not. Sometimes it just doesn't boot. Most of the time it's happy with only a couple of seconds power off.
EDIT: I'm doing <0.5 second power downs and it's about 1-in-3 attempts don't boot.
EDIT2: Ah-ha! Dug up a terminal emulator and got it toggling the DTR line for resets instead of doing power cycles. Guess what? Perfect reboots as fast as I like. Pop out the SD card and the reboot doesn't load. Put the SD card back in and perfect rapid reboots again. Happy chappy.
Does this mean the FPGA loading side is not 100% reliable, but gets more reliable with a longer power-off ?
I've seen some parts specify a minimum Vcc before their POR ramp works, and that can be << 1V. You could meter some supplies to see what residual level is needed to get more reliable ?
If you need to diagnose any SD problems then pop on over to TAQOZ. For instance, if you wanted to hex dump your root directory you can mount the card, fopen the directory as a file, and then hex dump it etc.
Try this - you can even type all on one line if you like
_searchDIR and fname+2, ##$00FFFFFF ' 12th char must be $00
mov _blocknr, dir_begin ' DIR SECTOR#
decod _sectors, clustersh ' max sectors to scan (1 cluster)
.search_next call #@_readSECTOR ' read sector
'+-----------------------------------------------------------------------------+
'+ Walk Directory: (read DIR sectors) +
'+ 16 x 32byte DIR(fname) entries per DIR sector +
'+ +$00[1] = $00 = empty +
'+ => $80 = deleted file +
'+ search +$00[11] = 8.3 filename +
'+ verify +$0B[1] = FileAttrib AND $D8,check $00 +
'+ $01=read,02=hidden,04=system,08=volume,0F=longfile,10=dir,20=archive+
'+ calc +$14[2] = FAT32: 1st cluster# HI -\-> cluster +
'+ calc +$1A[2] = FAT32: 1st cluster# LO -/ +
'+ calc +$1C[4] = FAT32: FileSize in bytes --> file_size +
'+ calc dat_begin = dir_begin + ((cluster-2)<<6) +
'+-----------------------------------------------------------------------------+
' scan dir sector for files...
.walk_dir mov _entries, #16 ' 16*32byte file entries
mov bufad, _bufad ' dir hub locn
' scan this sector for filename entry...
.scan rdlong reply, bufad '\ check this entry
cmp reply, #0 wz '| $0 = empty?
if_ne jmp #.check '| n:
_RET_ MODZ _clr wz '/ return "NZ" = not found
.check cmp reply, fname wz '| check fname...
add bufad, #4 '|
rdlong reply, bufad '|
if_e cmp reply, fname+1 wz '|
add bufad, #4 '|
rdlong reply, bufad '|
and reply, ##$D8FFFFFF '| check atts b7+6+4+3
if_e cmp reply, fname+2 wz '|
if_e jmp #.found '/ found!
add bufad, #(32-8) ' next entry
djnz _entries, #.scan ' "NZ" not found this sector
'+-----------------------------------------------------------------------------+
add _blocknr, #1 ' next sector#
_RET_ djnz _sectors, #.search_next ' return "NZ" = not found
I read the first long, check that it is not $00000000 (an unused entry signifying end of directory)
Then I compare the first long with the first 4 character of the filename. This automatically discards any deleted files (with an $80 bit set) as well.
Then i read the next long and compare with the next 4 chars of the filename.
Then I read the next (3rd) long, and the last char with $D8 which leaves the system and dir bits (removes read/hidden/system/archive bits). The filename 12th char has already been made $00. Then I compare.
If all 3 compares passed, then it is the filename I am looking for. If not, try the next until $00000000 or the first cluster is done.
So your file should have been found.
Thanks for the effort there Cluso. It's all resolved I feel. That one was probably okay if I had tried it again. Biggest issue was the unreliable power ups. Followed by confusion over filename entry ordering due to the long filenames gobbling three entries each.
Comments
all_cogs_blink.obj boots in a blink. The 442 KB file of VGA_640_x_480_16bpp.obj takes about 9 seconds to boot.
I've noticed what appears to be a bug. The FAT32 filename search for _BOOT_P2.BIX only works for the first entry of the directory. Not much of a search if it always has to be the first entry.
FPGA image used is Prop123_A9_Prop2_8cogs_v32i.rbf
I think you need to do further testing. My files are not anywhere near the start of my directory. There are 16 directory entries per sector, and in a normal 32KB cluster for FAT32 there will be 64 sectors scanned. That means a possible 1024 entries. I terminate if a long of $00000000 is found. This is the indication of the end of the directory entries. When an entry is deleted the first character of the entry has the top bit $80 set. The remaining filename is left intact. This is how undelete programs work.
There are however other entries in the directory, such as directories (folders if you like) and system entries, and long filename entries. These are all skipped.
Perhaps you need to look at the SD card with a hex disk program. Sorry, forget which one I use ATM.
Don't forget, you can use the Monitor to load or run any file.
Also, don't forget that my file names are case sensitive.
Could be tricky in the future but you are right about the searching.
BTW While I only check for one cluster, IIRC the directory can be 2 clusters long. I figured 1024 entries was sufficient.
I was disappointed about the proprietary and complex nature of exFAT. Hopefully someone will overturn MS patents. IMHO that was old 70's technology and nothing new. Or come up with FAT64.
Hey, I wouldn't call that a fail when you are cheating somewhat. It's no different to deleting an extraneous file. Gaps in the entry list are hardly unheard of.
Linux is a full blown os. I think shortcuts in a micro os isn't exactly in the same realm. I am pretty sure if Windows did that there would be a lot of complaints.
Anyway, that's how it is. There was time for testing and suggestions and complaints. Those days passed with only a handful of people testing.
No it doesn't. It marked the first character with OR $80. That's not a blank entry, it's a deleted entry.
I've had a quick look at the raw data, there is MSbit markers present like you say, so I'm not yet sure why the search is failing. It looks a bit like there is some unicode for the extended filenames ...
Here's a selected dump of a FAT32 root that is booting fine:
Here's what happened by reformatting then adding a single long filename as the first entry, then deleting it, then adding _BOOT_P2.PIX followed by duplicate BIY and BIZ files:
Sorry if I was a tad behind on the requirements. I certainly haven't read everything.
Is there any debug for booting?
EDIT: I'm doing <0.5 second power downs and it's about 1-in-3 attempts don't boot.
EDIT2: Ah-ha! Dug up a terminal emulator and got it toggling the DTR line for resets instead of doing power cycles. Guess what? Perfect reboots as fast as I like. Pop out the SD card and the reboot doesn't load. Put the SD card back in and perfect rapid reboots again. Happy chappy.
Can you summarize the rules around long files names and formatting steps ?
I've seen some parts specify a minimum Vcc before their POR ramp works, and that can be << 1V. You could meter some supplies to see what residual level is needed to get more reliable ?
Try this - you can even type all on one line if you like
Then I compare the first long with the first 4 character of the filename. This automatically discards any deleted files (with an $80 bit set) as well.
Then i read the next long and compare with the next 4 chars of the filename.
Then I read the next (3rd) long, and the last char with $D8 which leaves the system and dir bits (removes read/hidden/system/archive bits). The filename 12th char has already been made $00. Then I compare.
If all 3 compares passed, then it is the filename I am looking for. If not, try the next until $00000000 or the first cluster is done.
So your file should have been found.