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 $00mov _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 entriesmov bufad, _bufad ' dir hub locn' scan this sector for filename entry...
.scan rdlong reply, bufad '\ check this entrycmp reply, #0wz'| $0 = empty?if_nejmp #.check '| n:_RET_MODZ _clr wz'/ return "NZ" = not found
.check cmp reply, fname wz'| check fname...add bufad, #4'|rdlong reply, bufad '|if_ecmp reply, fname+1wz'|add bufad, #4'|rdlong reply, bufad '|and reply, ##$D8FFFFFF'| check atts b7+6+4+3if_ecmp reply, fname+2wz'|if_ejmp #.found '/ found!add bufad, #(32-8) ' next entrydjnz _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:
00eb8000 41444154 41313620 20202008 00007d96 c24cc24c 00007d96 c24c0000 00000000 ADATA16 ...}..L.L..}..L...... 00eb8020 4269006e 006b002e 006f000f 002d6200 6a000000 ffffffff ffff0000 ffffffff Bi.n.k...o...-b.j............... 00eb8040 0130002e 0061006c 006c000f 002d5f00 63006f00 67007300 5f000000 62006c00 .0...a.l.l...-_.c.o.g.s._...b.l. 00eb8060 30414c4c 5f437e31 4f424a20 0064fb6d c24cc24c 0000fb6d c24ced01 40000000 0ALL_C~1OBJ .d.m.L.L...m.L..@... 00eb8080 4269006e 006b002e 006f000f 006d6200 6a000000 ffffffff ffff0000 ffffffff Bi.n.k...o...mb.j............... 00eb80a0 0131002e 0061006c 006c000f 006d5f00 63006f00 67007300 5f000000 62006c00 .1...a.l.l...m_.c.o.g.s._...b.l. 00eb80c0 31414c4c 5f437e31 4f424a20 0000006e c24cc24c 0000006e c24cee01 40000000 1ALL_C~1OBJ ...n.L.L...n.L..@... 00eb80e0 4269006e 006b002e 006f000f 00b46200 6a000000 ffffffff ffff0000 ffffffff Bi.n.k...o....b.j............... 00eb8100 0132002e 0061006c 006c000f 00b45f00 63006f00 67007300 5f000000 62006c00 .2...a.l.l...._.c.o.g.s._...b.l. 00eb8120 32414c4c 5f437e31 4f424a20 0064016e c24cc24c 0000016e c24cef01 40000000 2ALL_C~1OBJ .d.n.L.L...n.L..@... 00eb8140 5f424f4f 545f5032 42494120 0064086e c24cc24c 0000086e c24cf201 40000000 _BOOT_P2BIA .d.n.L.L...n.L..@... 00eb8160 e533002e 0061006c 006c000f 00f45f00 63006f00 67007300 5f000000 62006c00 .3...a.l.l...._.c.o.g.s._...b.l. 00eb8180 e5414c4c 5f437e31 4f424a20 0000046e c24cc24c 0000046e c24cf001 40000000 .ALL_C~1OBJ ...n.L.L...n.L..@... 00eb81a0 5f424f4f 545f5032 42495920 0000046e c24cc24c 0000046e c24cf001 40000000 _BOOT_P2BIY ...n.L.L...n.L..@... 00eb81c0 5f424f4f 545f5032 42495a20 0000166c c24cc24c 0000355c c24ce901 40000000 _BOOT_P2BIZ ...l.L.L..5\.L..@... 00eb81e0 5f424f4f 545f5032 42495820 0064756a c24cc24c 0000355c c24ce101 40000000 _BOOT_P2BIX .duj.L.L..5\.L..@... 00eb8200 4269006e 006b002e 006f000f 002c6200 6a000000 ffffffff ffff0000 ffffffff Bi.n.k...o...,b.j............... 00eb8220 0134002e 0061006c 006c000f 002c5f00 63006f00 67007300 5f000000 62006c00 .4...a.l.l...,_.c.o.g.s._...b.l. 00eb8240 34414c4c 5f437e31 4f424a20 0000aa6c c24cc24c 0000355c c24cec01 40000000 4ALL_C~1OBJ ...l.L.L..5\.L..@... 00eb8260 4269006e 006b002e 006f000f 006e6200 6a000000 ffffffff ffff0000 ffffffff Bi.n.k...o...nb.j............... 00eb8280 0135002e 0061006c 006c000f 006e5f00 63006f00 67007300 5f000000 62006c00 .5...a.l.l...n_.c.o.g.s._...b.l. 00eb82a0 35414c4c 5f437e31 4f424a20 0000066e c24cc24c 0000066e c24cf101 40000000 5ALL_C~1OBJ ...n.L.L...n.L..@... 00eb82c0 e569006e 006b002e 006f000f 00b36200 6a000000 ffffffff ffff0000 ffffffff .i.n.k...o....b.j............... 00eb82e0 e536002e 0061006c 006c000f 00b35f00 63006f00 67007300 5f000000 62006c00 .6...a.l.l...._.c.o.g.s._...b.l. 00eb8300 e5414c4c 5f437e31 4f424a20 0064086e c24cc24c 0000086e c24cf201 40000000 .ALL_C~1OBJ .d.n.L.L...n.L..@... 00eb8320 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ *00eb8000 41444154 41313620 20202008 00007d96 c24cc24c 00007d96 c24c0000 00000000 ADATA16 ...}..L.L..}..L...... 00eb8020 e569006e 006b002e 006f000f 002d6200 6a000000 ffffffff ffff0000 ffffffff .i.n.k...o...-b.j............... 00eb8040 e530002e 0061006c 006c000f 002d5f00 63006f00 67007300 5f000000 62006c00 .0...a.l.l...-_.c.o.g.s._...b.l. 00eb8060 e5414c4c 5f437e31 4f424a20 0064fb6d c24cc24c 0000fb6d c24ced01 40000000 .ALL_C~1OBJ .d.m.L.L...m.L..@... 00eb8080 4269006e 006b002e 006f000f 006d6200 6a000000 ffffffff ffff0000 ffffffff Bi.n.k...o...mb.j............... 00eb80a0 0131002e 0061006c 006c000f 006d5f00 63006f00 67007300 5f000000 62006c00 .1...a.l.l...m_.c.o.g.s._...b.l. 00eb80c0 31414c4c 5f437e31 4f424a20 0064fb6d c24cc24c 0000fb6d c24ced01 40000000 1ALL_C~1OBJ .d.m.L.L...m.L..@... 00eb80e0 e569006e 006b002e 006f000f 00b46200 6a000000 ffffffff ffff0000 ffffffff .i.n.k...o....b.j............... 00eb8100 e532002e 0061006c 006c000f 00b45f00 63006f00 67007300 5f000000 62006c00 .2...a.l.l...._.c.o.g.s._...b.l. 00eb8120 e5414c4c 5f437e31 4f424a20 0064016e c24cc24c 0000016e c24cef01 40000000 .ALL_C~1OBJ .d.n.L.L...n.L..@... 00eb8140 5f424f4f 545f5032 42494120 0064086e c24cc24c 0000086e c24cf201 40000000 _BOOT_P2BIA .d.n.L.L...n.L..@... 00eb8160 e533002e 0061006c 006c000f 00f45f00 63006f00 67007300 5f000000 62006c00 .3...a.l.l...._.c.o.g.s._...b.l. 00eb8180 e5414c4c 5f437e31 4f424a20 0000046e c24cc24c 0000046e c24cf001 40000000 .ALL_C~1OBJ ...n.L.L...n.L..@... 00eb81a0 5f424f4f 545f5032 42495920 0000046e c24cc24c 0000046e c24cf001 40000000 _BOOT_P2BIY ...n.L.L...n.L..@... 00eb81c0 5f424f4f 545f5032 42495a20 0000166c c24cc24c 0000355c c24ce901 40000000 _BOOT_P2BIZ ...l.L.L..5\.L..@... 00eb81e0 5f424f4f 545f5032 42495820 0064756a c24cc24c 0000355c c24ce101 40000000 _BOOT_P2BIX .duj.L.L..5\.L..@... 00eb8200 4269006e 006b002e 006f000f 002c6200 6a000000 ffffffff ffff0000 ffffffff Bi.n.k...o...,b.j............... 00eb8220 0134002e 0061006c 006c000f 002c5f00 63006f00 67007300 5f000000 62006c00 .4...a.l.l...,_.c.o.g.s._...b.l. 00eb8240 34414c4c 5f437e31 4f424a20 0000aa6c c24cc24c 0000355c c24cec01 40000000 4ALL_C~1OBJ ...l.L.L..5\.L..@... 00eb8260 4269006e 006b002e 006f000f 006e6200 6a000000 ffffffff ffff0000 ffffffff Bi.n.k...o...nb.j............... 00eb8280 0135002e 0061006c 006c000f 006e5f00 63006f00 67007300 5f000000 62006c00 .5...a.l.l...n_.c.o.g.s._...b.l. 00eb82a0 35414c4c 5f437e31 4f424a20 0000066e c24cc24c 0000066e c24cf101 40000000 5ALL_C~1OBJ ...n.L.L...n.L..@... 00eb82c0 e569006e 006b002e 006f000f 00b36200 6a000000 ffffffff ffff0000 ffffffff .i.n.k...o....b.j............... 00eb82e0 e536002e 0061006c 006c000f 00b35f00 63006f00 67007300 5f000000 62006c00 .6...a.l.l...._.c.o.g.s._...b.l. 00eb8300 e5414c4c 5f437e31 4f424a20 0064086e c24cc24c 0000086e c24cf201 40000000 .ALL_C~1OBJ .d.n.L.L...n.L..@... 00eb8320 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ *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 ................................ *1/1 "%08_ax " 4/1 "%02x" " " 4/1 "%02x" " " 4/1 "%02x" " " 4/1 "%02x" " " 4/1 "%02x" " " 4/1 "%02x" " " 4/1 "%02x" " " 4/1 "%02x" " " 32/1 "%_p" "\n"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
MOUNT @ROOT FOPEN 0 $200 SD DUMPvv AND $D8 00eb8000 41 444154 41313620 202020 08 vol 00007d96 c24cc24c 00007d96 c24c0000 00000000 ADATA16 ...}..L.L..}..L...... 00eb8020 deleted e5 69006e 006b002e 006f00 0f long 002d6200 6a000000 ffffffff ffff0000 ffffffff .i.n.k...o...-b.j............... 00eb8040 deleted e5 30002e 0061006c 006c00 0f long 002d5f00 63006f00 67007300 5f000000 62006c00 .0...a.l.l...-_.c.o.g.s._...b.l. 00eb8060 deleted e5 414c4c 5f437e31 4f424a 20 arch 0064fb6d c24cc24c 0000fb6d c24ced01 40000000 .ALL_C~1OBJ .d.m.L.L...m.L..@... 00eb8080 42 69006e 006b002e 006f00 0f long 006d6200 6a000000 ffffffff ffff0000 ffffffff Bi.n.k...o...mb.j............... 00eb80a0 01 31002e 0061006c 006c00 0f long 006d5f00 63006f00 67007300 5f000000 62006c00 .1...a.l.l...m_.c.o.g.s._...b.l. 00eb80c0 31 414c4c 5f437e31 4f424a 20 arch 0064fb6d c24cc24c 0000fb6d c24ced01 40000000 1ALL_C~1OBJ .d.m.L.L...m.L..@... 00eb80e0 deleted e5 69006e 006b002e 006f00 0f long 00b46200 6a000000 ffffffff ffff0000 ffffffff .i.n.k...o....b.j............... 00eb8100 deleted e5 32002e 0061006c 006c00 0f long 00b45f00 63006f00 67007300 5f000000 62006c00 .2...a.l.l...._.c.o.g.s._...b.l. 00eb8120 deleted e5 414c4c 5f437e31 4f424a 20 arch 0064016e c24cc24c 0000016e c24cef01 40000000 .ALL_C~1OBJ .d.n.L.L...n.L..@... 00eb8140 5f 424f4f 545f5032 424941 20 arch 0064086e c24cc24c 0000086e c24cf201 40000000 _BOOT_P2BIA .d.n.L.L...n.L..@... 00eb8160 deleted e5 33002e 0061006c 006c00 0f long 00f45f00 63006f00 67007300 5f000000 62006c00 .3...a.l.l...._.c.o.g.s._...b.l. 00eb8180 deleted e5 414c4c 5f437e31 4f424a 20 arch 0000046e c24cc24c 0000046e c24cf001 40000000 .ALL_C~1OBJ ...n.L.L...n.L..@... 00eb81a0 5f 424f4f 545f5032 424959 20 arch 0000046e c24cc24c 0000046e c24cf001 40000000 _BOOT_P2BIY ...n.L.L...n.L..@... 00eb81c0 5f 424f4f 545f5032 42495a 20 arch 0000166c c24cc24c 0000355c c24ce901 40000000 _BOOT_P2BIZ ...l.L.L..5\.L..@... 00eb81e0 5f 424f4f 545f5032 424958 20 arch 0064756a c24cc24c 0000355c c24ce101 40000000 _BOOT_P2BIX .duj.L.L..5\.L..@... 00eb8200 42 69006e 006b002e 006f00 0f long 002c6200 6a000000 ffffffff ffff0000 ffffffff Bi.n.k...o...,b.j............... 00eb8220 01 34002e 0061006c 006c00 0f long 002c5f00 63006f00 67007300 5f000000 62006c00 .4...a.l.l...,_.c.o.g.s._...b.l. 00eb8240 34 414c4c 5f437e31 4f424a 20 arch 0000aa6c c24cc24c 0000355c c24cec01 40000000 4ALL_C~1OBJ ...l.L.L..5\.L..@... 00eb8260 42 69006e 006b002e 006f00 0f long 006e6200 6a000000 ffffffff ffff0000 ffffffff Bi.n.k...o...nb.j............... 00eb8280 01 35002e 0061006c 006c00 0f long 006e5f00 63006f00 67007300 5f000000 62006c00 .5...a.l.l...n_.c.o.g.s._...b.l. 00eb82a0 35 414c4c 5f437e31 4f424a 20 arch 0000066e c24cc24c 0000066e c24cf101 40000000 5ALL_C~1OBJ ...n.L.L...n.L..@... 00eb82c0 deleted e5 69006e 006b002e 006f00 0f long 00b36200 6a000000 ffffffff ffff0000 ffffffff .i.n.k...o....b.j............... 00eb82e0 deleted e5 36002e 0061006c 006c00 0f long 00b35f00 63006f00 67007300 5f000000 62006c00 .6...a.l.l...._.c.o.g.s._...b.l. 00eb8300 deleted e5 414c4c 5f437e31 4f424a 20 arch 0064086e c24cc24c 0000086e c24cf201 40000000 .ALL_C~1OBJ .d.n.L.L...n.L..@... 00eb8320 00 000000 00000000 000000 00 -end- 00000000 00000000 00000000 00000000 00000000 ................................And here is my code_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.