Hi Max,
Yes, I do like your idea and new challenges. However, time is limited and I have many other projects that are going to need to get done. But, when Release 2 of the board gets done next year, I'll definitely take on this challenge.
The SD Memory Card already uses 32bit numbers for the sectors. The MBR points to the DOS partition with 32bits.
The clusters are relative to this partition and must be added to a 32bit SD Card Sector base. There can be up to 255 sectors per cluster, so right there the relative sector number becomes 24bit.
I have built up 2 types of 32 bit routines. One where HL points to a 32 bit value in RAM and DE points to another. Then, in an effort to improve performance, I am using registers BCDE as a 32 bit value, and HL pointing to RAM for the other value. The 8080 is scarce on Registers.
But, when the time comes to "raise the bar", I'll be almost set for the 32 bit stuff. I wonder if there are needs to multiply 32bits by anything, which will require special routines for 40/48/64 bit numbers.
Cheers,
Josh
Date: Tue, 15 Jul 2014 16:26:40 +1000
Subject: Re: [N8VEM-S100:4583] FAT jumping
From: mjs...@gmail.com
To: n8vem...@googlegroups.com
--
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.
Yes, I do like your idea and new challenges. However, time is limited and I have many other projects that are going to need to get done. But, when Release 2 of the board gets done next year, I'll definitely take on this challenge.
The SD Memory Card already uses 32bit numbers for the sectors. The MBR points to the DOS partition with 32bits.
The clusters are relative to this partition and must be added to a 32bit SD Card Sector base. There can be up to 255 sectors per cluster, so right there the relative sector number becomes 24bit.
I have built up 2 types of 32 bit routines. One where HL points to a 32 bit value in RAM and DE points to another. Then, in an effort to improve performance, I am using registers BCDE as a 32 bit value, and HL pointing to RAM for the other value. The 8080 is scarce on Registers.
But, when the time comes to "raise the bar", I'll be almost set for the 32 bit stuff. I wonder if there are needs to multiply 32bits by anything, which will require special routines for 40/48/64 bit numbers.
Cheers,
Josh
Date: Tue, 15 Jul 2014 16:26:40 +1000
Subject: Re: [N8VEM-S100:4583] FAT jumping
From: mjs...@gmail.com
To: n8vem...@googlegroups.com
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.