Ah, interesting way to do that. Thanks for the comments!

Hi Again!

Things are starting to work here. I implemented the SPI interface myself in verilog... and I learnt a lot, but it was somewhat painful. Anyway, I made a DMA interface for the SPI, so at least I can get a full 512 byte block into memory without troubling the processor too much. Multiblock read is not supported yet.

As for the FAT32 implementation, I notice that you only support LBA and not basic FAT32? Or will it actually work with FAT32 (non-LBA) as well, just that you only check for partition type $c?

If I format my SDHC card with Win7, it will ask for FAT32 ($b) or exFAT ($7), neither which are LBA...

Awesome. I've been thinking about something like that for a while now, but I haven't gotten around to do it. Also I'm (yet) lacking VHDL prowess to get anywhere here.


Yes, Linux fdisk lists $0c as FAT32 LBA so I went with that. Not sure what Windows is doing there. I think SD cards only do LBA anyway.

we only support LBA adressing ($0c), therefore we only check for that and nothing else.
but you're right, it will work with SDHC cards and type $0b too. but for correctness of our fat32 implementation we decided to strict check the $0c type.


dont know why windows behaves in this way, giving a block device like SDHC a type of $0b seems wrong to me. however under windows i help myself by doing SD card partitioning with diskpart to set the appropriate type and sizes.

Thanks! I'll try to stick to that. At least for a while to keep it closer to the original test environment.

As for the Verilog code, I will publish it once its stable. Main changes (in your software) will be spi+card initialization and read/write block. I haven't troubled with multiblock read yet since the programs I load are only around 4-8KiB

And yea...I use a Lattice FPGA. It only requires 512bytes for the buffer (which can be external if you have or make a memory interface). Since much of the init/read/write is 6502 code, the amount of LUTs needed seems to be small.

Hi Again,

Progress goes slowly, but I have been successful up to fat_mount subroutine. Now, I couldn't find the file information, and at the end of it, it cooked down to this comment:

cluster_begin_lba = Partition_LBA_Begin + Number_of_Reserved_Sectors + (Number_of_FATs * Sectors_Per_FAT) - (2 * sec/cluster);

Which seems to be implemented correctly in the code, but I can't find any file information there. I have confirmed this with the Active Disk Editor program, and from others it looks like this should be:

cluster_begin_lba = Partition_LBA_Begin + Number_of_Reserved_Sectors + (Number_of_FATs * Sectors_Per_FAT);

E.g. no subtraction of 2*sectors_per_cluster value. If I use that, I do find file information, so is it a bug or is something else going on?

I have used the same formatting as you suggested above, but then copied some files using windows to the SDHC card.

hi and sorry for that confusion, but for performance reasons we avoid the substraction on each file lba address calculation to save cycles.
that's why our cluster_begin_lba starts at - 2*Sectors_Per_Cluster so for lba address calculation only the shift loop and the 32bit add is required.
the -2 "edge case" or microsoft spec. bug for the root cluster is handled beforehand.

Thank you for clearing that up.

For obvious reasons I have other output subroutines and they were expecting the not-so-optimized version.

I have mostly gotten rid of bugs in my "new" code. I use most of the basic functions of SteckOS, but the commands had to be reinterpreted due to the different Kernel (or Kernal as Commodore called it).

Anyway, I have SDHC cards working nicely. Long filenames work. Loading works.. but then I suddenly got a problem were different sectors were not loading correctly.

I could see this after implementing CRC16 checks for all the loaded sectors. Thus, most things loaded ok, but once in a while I had blocks that were just not loading. Repeating them did not change this. Re-saving them with a different name to the SD card did not help. So I ended up making a 8KiB file with 16-bit words counting from 0000 to $1000 (=4096). This file was stored on the SD Card from windows and nothing loaded on the 6502 side! All blocks had the wrong CRC16(??!).

So i went to some disk sector/block examiner program and looked at the different sectors of that file, and they were all coded as 32-bit entries with the 16-bit word as the first two bytes, then the value $1600 as the last two bytes. That whole file! I can see this in other files as well, but there is no system to the madness. Some blocks simply contain the RAW data, others have this 32-bit encoding.

Is this a particular thing with FAT32? I can't find any information about any special encoding scheme for the file blocks in FAT32, all documents talk about the ROOT, directory and cluster blocks, nothing about the files.. After searching for 2 days I have given up on finding any information on this. The files seems fine on the Windows 7 side, but some of the blocks contain this $1600 value in between the actual databytes.

Anyone know whats happening here?

PS: I should also tell you that the CRC16 is quite needed on my card. I run the SPI at 25MHz, and once in a while it also fails to load a normal block, but repeating it usually works.

Wait, so you created a file with 16b words (0000, 0001, 0002, ..., 0FFF, 1000), on a separate machine, and you could not read it back?

You're not running in to some byte swapping/endian thing here are you? Are you writing short ints on the other machine, or byte by byte?

Yes I created that under win7, could read it back without problems, but it had this strange encoding on the SD card.


All just copied as a file under win7. A guy I know suggested that it could be something with the SD card driver or SD card as he had experienced similar issues himself. I therefore reformatted the card, and voilá.. the strange encoding was gone(!) It now shows up in the same way on the harddrive and SD card. I use Acitve@Disk Editor to scan the card.

The same guy is looking into the kernel of Win7 for some other reason, and he was going to do some testing to see if he could replicate it on another machine, and see if the strange encoding came from Win7 itself or the driver. For the moment, my guess is the latter since it did not reproduce.