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:
evanh@controlled:~/hoard/coding/prop2/testing$ sudo hexdump /dev/sdc1 -s $((0x00eb8000)) -n 4096 -f hexdump.fmt 00eb8000 41444154 41313620 20202008 00008723 c34cc34c 00008723 c34c0000 00000000 ADATA16 ....#.L.L...#.L...... 00eb8020 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ * evanh@controlled:~/hoard/coding/prop2/testing$ sudo hexdump /dev/sdc1 -s $((0x00eb8000)) -n 4096 -f hexdump.fmt 00eb8000 41444154 41313620 20202008 00008723 c34cc34c 00008723 c34c0000 00000000 ADATA16 ....#.L.L...#.L...... 00eb8020 426b002e 006f0062 006a000f 00cd0000 ffffffff ffffffff ffff0000 ffffffff Bk...o.b.j...................... 00eb8040 0161006c 006c005f 0063000f 00cd6f00 67007300 5f006200 6c000000 69006e00 .a.l.l._.c....o.g.s._.b.l...i.n. 00eb8060 414c4c5f 434f7e31 4f424a20 00647085 c24cc24c 00007085 c24c0700 40000000 ALL_CO~1OBJ .dp..L.L..p..L..@... 00eb8080 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ * evanh@controlled:~/hoard/coding/prop2/testing$ sudo hexdump /dev/sdc1 -s $((0x00eb8000)) -n 4096 -f hexdump.fmt 00eb8000 41444154 41313620 20202008 00008723 c34cc34c 00008723 c34c0000 00000000 ADATA16 ....#.L.L...#.L...... 00eb8020 e56b002e 006f0062 006a000f 00cd0000 ffffffff ffffffff ffff0000 ffffffff .k...o.b.j...................... 00eb8040 e561006c 006c005f 0063000f 00cd6f00 67007300 5f006200 6c000000 69006e00 .a.l.l._.c....o.g.s._.b.l...i.n. 00eb8060 e54c4c5f 434f7e31 4f424a20 00647085 c24cc24c 00007085 c24c0700 40000000 .LL_CO~1OBJ .dp..L.L..p..L..@... 00eb8080 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ * evanh@controlled:~/hoard/coding/prop2/testing$ sudo hexdump /dev/sdc1 -s $((0x00eb8000)) -n 4096 -f hexdump.fmt 00eb8000 41444154 41313620 20202008 00008723 c34cc34c 00008723 c34c0000 00000000 ADATA16 ....#.L.L...#.L...... 00eb8020 5f424f4f 545f5032 42495820 00647b85 c24cc24c 00007b85 c24c0800 40000000 _BOOT_P2BIX .d{..L.L..{..L..@... 00eb8040 e561006c 006c005f 0063000f 00cd6f00 67007300 5f006200 6c000000 69006e00 .a.l.l._.c....o.g.s._.b.l...i.n. 00eb8060 e54c4c5f 434f7e31 4f424a20 00647085 c24cc24c 00007085 c24c0700 40000000 .LL_CO~1OBJ .dp..L.L..p..L..@... 00eb8080 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ * evanh@controlled:~/hoard/coding/prop2/testing$ sudo hexdump /dev/sdc1 -s $((0x00eb8000)) -n 4096 -f hexdump.fmt 00eb8000 41444154 41313620 20202008 00008723 c34cc34c 00008723 c34c0000 00000000 ADATA16 ....#.L.L...#.L...... 00eb8020 5f424f4f 545f5032 42495820 00647b85 c24cc24c 0000355c c24c0800 40000000 _BOOT_P2BIX .d{..L.L..5\.L..@... 00eb8040 5f424f4f 545f5032 42495920 00648d85 c24cc24c 00008d85 c24c0900 40000000 _BOOT_P2BIY .d...L.L.....L..@... 00eb8060 5f424f4f 545f5032 42495a20 00648f85 c24cc24c 00008f85 c24c0a00 40000000 _BOOT_P2BIZ .d...L.L.....L..@... 00eb8080 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ *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
_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 foundI 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.