FAT32?

[granati]

I have 65C816 asm code for partitioning mass storage device (FAT16 partition), limited of course to 2Gb. I tried on some flash card and the new created FAT16 partition work fine in one Windows machine. Algorithm is based on rules described in the paper showed by BDD.
This code make MBR,PBR, FAT's tables and root directory on new partition (fast formatting). A full formatting (clear all cluster's) is frustating (long time).
Of course need of low level routines for read/write sector's and for identify device.

Marco

[whartung]

ArnoldLayne wrote:

BigDumbDinosaur wrote:

BTW, here is a Microsoft technical paper on the FAT filesystem for those who don't have all the details.

Also worth noting Paul Stoffregen's page about FAT32 as he concentrates on the bare minimum you need to get started:
https://www.pjrc.com/tech/8051/ide/fat32.html

Helped me a great deal.

That's a nice link. Thanks.

[kakemoms]

granati wrote:

I have 65C816 asm code for partitioning mass storage device (FAT16 partition), limited of course to 2Gb. I tried on some flash card and the new created FAT16 partition work fine in one Windows machine. Algorithm is based on rules described in the paper showed by BDD.
This code make MBR,PBR, FAT's tables and root directory on new partition (fast formatting). A full formatting (clear all cluster's) is frustating (long time).
Of course need of low level routines for read/write sector's and for identify device.

Marco

That is very interesting! Do you plan to share the source?

[granati]

Code is available at:

http://65xx.unet.bz/ - software section

direct link: http://65xx.unet.bz/mb01/B1606.zip

This code is a work in progress. Many pieces are incomplete, maybe full of bugs, but some sections are fully tested.
About FAT16 i'm developing a simple system for caching directory entries and accessed sector's for fast access. Traversing directories is still incomplete, but code for partitioning/formatting FAT16 is fully tested (also, work in floppy disk both 720K/1440K).
Look at F9/toscmd.asm for 'fdisk' implementation.

Note that low level routines for accessing ATA devices, USB devices (CH375/376 module) and floppy disk are in F8 directory. In this implementation ATA devices are accessed in DMA mode even if in the site is not showen the new ATA/DMA board i maded for my machine.

Marco

[kakemoms]

dolomiah wrote:

whartung wrote:

That's pretty nice.

Thank you, means a lot from a long standing member of the forum. I agree the 376 is great bit of kit, and if I used it I could have saved ROM space for more features in the interpreter, but the geek in me did enjoy getting the SPI SD Card interface working and then deep diving in to FAT to support a PC compatible filesystem.

I read the manual, I couldn't see a command to format disks, but looks like block level access is possible - as you say, loads of possibilities.

After holidays and some Verilog to get a SPI DMA buffer, I am trying to get my head around this code. It looks like you are completely ignoring the CRC7 part of the command string for the SD Card. Isn't that needed to get stable SPI communication?

What kind of CRC are you using for the FAT32?

[dolomiah]

kakemoms, are you referring to my 6502 homebrew source on hackaday, or what granati posted? Reason I am slightly confused is your reference to FAT32 - my code only supports FAT16.

But in case you are referring to my source code, yes from what I read and what is working, the SD card doesn't seem to care about the CRC after the CMD0. Weird, but works according to the document I found on this (an application note from 2004 by F. Foust, published by the University of Michigan). 0x95 is the correct CRC for CMD0, so I then just send the same value with all subsequent commands (ignore the comments that say the checksum has to be right, it's a copy and paste error!)

Regarding FAT32 CRC, well that's where I am confused as my code only supports FAT16 and there is no CRC in that. I am not sure there is any CRC in FAT32 mind..

[kakemoms]

dolomiah wrote:

kakemoms, are you referring to my 6502 homebrew source on hackaday, or what granati posted? Reason I am slightly confused is your reference to FAT32 - my code only supports FAT16.

But in case you are referring to my source code, yes from what I read and what is working, the SD card doesn't seem to care about the CRC after the CMD0. Weird, but works according to the document I found on this (an application note from 2004 by F. Foust, published by the University of Michigan). 0x95 is the correct CRC for CMD0, so I then just send the same value with all subsequent commands (ignore the comments that say the checksum has to be right, it's a copy and paste error!)

Regarding FAT32 CRC, well that's where I am confused as my code only supports FAT16 and there is no CRC in that. I am not sure there is any CRC in FAT32 mind..

Sorry I got the code mixed up here (my brain is still in holiday mode). The FAT32 question was to the other coder with the SteckOS.

I still don't understand why CRC is not used. FAT seems to make double copies of the file allocation table as a redundancy.. and that indicates that CRC would probably be a good idea.

There are several places that lists command arguments and CRC, so it seems like a table is all that is needed for most commands.

[kakemoms]

Ok, since I couldn't find any CRC-7 for 6502, I made one myself:

Code: Select all

; Calculation of CRC7 for SD Card communication
CMD0 = $40

*=$a000
        LDA     #CMD0      ; CMD0 command (no arguments)
        STA     crcdata
        LDA     #4
        LDX     #<crcdata
        LDY     #>crcdata
        JSR     crc7
        ASL     ; CRC for SPI in bit 7-1
        ORA     #1      ; bit0 always set
        STA     crcdata+5
        RTS

crcdata byte 0,0,0,0,0,0

; start of data is in X & Y
; length-1 is in A

crc7
        STX     $2
        STY     $3     
        STA     $4

        LDX     #0
        STX     $5      ;crc
        STX     $6      ; counter
crc7lp1
        LDY     $6
        LDA     ($2),Y          ; get ch
        LDX     #7
crc7lp2
        TAY
        ASL     $5      ; shift CRC
        EOR     $5      ; CH XOR CRC
        AND     #$80
        BEQ     crc7mp1 ; if (CH XOR CRC) AND $80 = 0
        LDA     $5
        EOR     #$09
        STA     $5      ; CRC = CRC XOR $09
crc7mp1
        TYA             ; CH
        ASL             ; shift CH
        DEX
        BPL     crc7lp2         ; loop 7 times
        LDA     $5
        AND     #$7f
        STA     $5      ; CRC = CRC AND $7F
        INC     $6
        DEC     $4
        BPL     crc7lp1
        LDA     $5      ; CRC
        RTS

Probably not the fastest way, but it seems to work.

[BitWise]

I'm not sure that you really need a CRC7 routine. The series of commands you send to initialise the SC card are always the same so the CRC7 bytes can be pre-computed. Later when accessing the card to read/write blocks the CRC16 values are optional.

I can't find the 6502 code I wrote for my SBC when I was playing with this last year. I'll try to dig it up later.

[BitWise]

Heres the listing of the code I wrote that initialises an SD card and read/dumps a 512 byte sector. One day I'll get back to it.

boot-65c02.zip

(11.45 KiB) Downloaded 180 times

This was for my SB-6502 board and its virtual SPI65 interface. All the CRC7 values are fixed in the initialisation data.

[ArnoldLayne]

kakemoms wrote:

Sorry I got the code mixed up here (my brain is still in holiday mode). The FAT32 question was to the other coder with the SteckOS.

That would be me. There is no CRC code at all in the SteckOS FAT32-implementation. I think that's not needed at all there.
Where one CRC7 checksum IS indeed needed is when using the SD card command CMD0 during SD card init, but not need to generate one because it always the same, as BitWise already pointed out.

Or was there another question I missed?

[ArnoldLayne]

ArnoldLayne wrote:

kakemoms wrote:

Sorry I got the code mixed up here (my brain is still in holiday mode). The FAT32 question was to the other coder with the SteckOS.

That would be me. There is no CRC code at all in the SteckOS FAT32-implementation. I think that's not needed at all there.
Where one CRC7 checksum IS indeed needed is when using the SD card command CMD0 during SD card init, but not need to generate one because it always the same, as BitWise already pointed out.

Coming to think of it, FAT32 long filenames use a crc7 checksum. But don't get me started on FAT long filenames.

[kakemoms]

ArnoldLayne wrote:

Hi,

we are working our own FAT32 implementation as part of the operating system "SteckOS" for our 6502-based homebrew computer "Steckschwein" http://www.steckschwein.de

It's not complete yet, we currently do not follow cluster chains, so files > 1 cluster are a problem.
We chose not to support long file names either.
But creating, reading, writing files and directories works. The "API" is loosely modeled after POSIX (open,close,read,write).

The code is publicly available: https://bitbucket.org/steckschwein/stec ... os/kernel/

Our implementation only needs a means to read and write (512 byte)blocks and a few memory locations.

Cheers,
Thomas

Hi again!

I am grinding through your code, and mostly its easy reading. Only a few 65c02 specific instructions, so they are easy to replace. At least up until now. Then I came accross this code segment which makes less sense to me:

Code: Select all

path_inverse:
		stz krn_tmp
		stz krn_tmp2
		ldy #0
		jsr l_inv
		iny
		lda #0
		sta (krn_ptr2),y
		rts
l_inv:
		lda (krn_ptr3), y
		iny
		cpy krn_tmp3
		beq l_seg
		cmp #'/'
		bne l_inv
		phy
		jsr l_inv
		ply
		sty krn_tmp
l_seg:
		ldy krn_tmp
		inc krn_tmp
		lda (krn_ptr3), y
		ldy krn_tmp2
		inc krn_tmp2
		sta (krn_ptr2), y
		cmp #'/'
		bne l_seg
		rts

The jsr instruction that goes back to its own code segment seems somewhat untraditional. Could you explain what is happening here?

[ArnoldLayne]

kakemoms wrote:

The jsr instruction that goes back to its own code segment seems somewhat untraditional. Could you explain what is happening here?

You got me there!
The Steckschwein Project is a team effort, and that happens to be not my code. Looks like some kind of recursion to resolve a file path to me.
Let me try to convince my teammate to register here to have him explain it himself.

[ArnoldLayne]

ArnoldLayne wrote:

Let me try to convince my teammate to register here to have him explain it himself.

He does not want to. But he added a few comments to the code to make more clear what's going on:

https://bitbucket.org/steckschwein/stec ... l/util.asm