[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [N8VEM-S100:4583] FAT jumping



FAT32... Does that mean adding LFN (Long File Names)? That would mean a fair amount of extra work?

Thanks

 

Leonard

 

From: n8vem...@googlegroups.com [mailto:n8vem...@googlegroups.com] On Behalf Of Max Scane
Sent: Tuesday, July 15, 2014 2:27 AM
To: n8vem...@googlegroups.com
Subject: Re: [N8VEM-S100:4583] FAT jumping

 

Hi Josh,

 

Looks like you are well on your way..

 

I would however, encourage you to implement FAT32 first and then FAT 16.  You can easily convert the 16 bit addresses and counters into a 32 bit number and use the same utility routines for both FAT 16 and 32.

 

There is surprisingly little difference between FAT16 and 32 apart from the size of the data elements and the locations of root directory etc.

 

I would suggest to start off writing some routines to do 32 bit adds, increments and compares.

 

Just my suggestions of course, you are free to do it how you please... :-)

 

Regards,

 

Max

 

On Tue, Jul 15, 2014 at 3:42 PM, Crusty OMO <crus...@hotmail.com> wrote:

Hi Guys,

Well, here's my first project where I have done some real FAT jumping...

In case anyone is interested,  below is a screen shot of reading a Logical Disk sector from the virtual disk in a file.
The file is Disk-10.txt which is loaded with the 2002 records of J's and the record number (big endian).

I call for sector 7D0 (2000), and the first Seek needs to read the FAT, which it does, FAT table starts at sector 0x000000F7.
on the next jump, the seek takes it deeper into the FAT and requires to read the next FAT sector at ...F8
the rest of the seeks just jump around that same sector of the FAT until it finds the right data cluster.

The next "hop" is not shown because it's reached it, and I would guess that would be cluster 13A.
2 Clusters are reserved, so subtract 2.   0x13A = 0x139.  There are 0x20 sectors per cluster, so multiply
0x139 * 0x20 = 0x2700.  Data sectors start at 0x303 (for this SD card), so add that in....
0x2700 + 0x303 = 0x2A03,  which is close enough to 0x2A17 to find the data...
Just kidding, the sector within that cluster is found by 0x7D0 (logical sector desired) divided by 4 and MOD 0x20.
That comes out to 0x14...
0x2A03 + 0x14 = 0x2A17  ... and there's the right data!
Actually, it loads the 4 logical sectors of 128 bytes in each 512 sector, then it picks the right quadrant based on 0x7D0 MOD 4

And Bob's your uncle!
Regards,
Josh Bensadon

 

 

 

--
You received this message because you are subscribed to the Google Groups "N8VEM-S100" group.
To unsubscribe from this group and stop receiving emails from it, send an email to n8vem-s100+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

 

--
You received this message because you are subscribed to the Google Groups "N8VEM-S100" group.
To unsubscribe from this group and stop receiving emails from it, send an email to n8vem-s100+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.