Compact flash pinout?

[barnacle]

Thanks, BDD. It's looking pretty easy to read the directory which I'm currently in the process of decoding.

Code: Select all

ECU.C  
[TEST.   ]
EEPROM.C  
GRAPHICS.C  
I18N.C  
MAIN.C  
SERIAL.C  

The entry in square brackets is a subdirectory. I want to pull time, date, and size data off the entry before I expand to take the next sector...

Neil

[barnacle]

Improved: traversing a directory listing across multiple sectors in a single cluster (in the image, using C for now). I still need to make a directory that overflows the cluster to test that, but it's not urgent.

Code: Select all

Start sector = 00000800
bytes per sector: 512
sectors per cluster: 8 (4k per cluster)
reserved sectors: 32
number of fats: 2
sectors per fat: 976
root sector (hex): 00000002
signature (hex): aa55
beginning lba of fat (hex): 00000820
beginning of clusters (hex): 00000fc0
ECU.C		  2021-06-10	15:05:16	31986
[TEST]		 2025-10-20	12:01:50	0
EEPROM.C	  2021-06-10	15:04:48	3348
GRAPHICS.C	2021-06-10	15:04:34	30920
I18N.C		 2021-06-10	15:04:12	42880
MAIN.C		 2021-06-17	09:37:10	15689
SERIAL.C	  2021-06-10	15:07:10	3309
SSD1309.C	 2021-06-10	11:51:26	5166
SYSMEM.C	  2021-06-10	11:41:40	2820

Neil

[barnacle]

Slowly, we progress (still using C on the disk image so I can play more easily before converting to 65c02 assembly).

The root directory:

Code: Select all

ECU.C		2021-06-10	15:05:16	31986
[TEST]		2025-10-20	12:01:50	0
EEPROM.C	2021-06-10	15:04:48	3348
GRAPHICS.C	2021-06-10	15:04:34	30920
I18N.C		2021-06-10	15:04:12	42880
MAIN.C		2021-06-17	09:37:10	15689
SERIAL.C	2021-06-10	15:07:10	3309
SSD1309.C	2021-06-10	11:51:26	5166
SYSMEM.C	2021-06-10	11:41:40	2820
FAT_FI~1.PDF	2025-10-26	22:15:14	86693
...
TS2083.PDF	2025-10-10	20:55:26	1797628
C20415~1.PDF	2025-10-10	20:51:46	128397
101D-T~2.PDF	2025-10-10	20:47:12	323874
CFS.PDF		2025-10-10	20:37:26	510327
53 files found

And the subdirectory TEST

Code: Select all

[.]		2025-10-20	12:00:16	0
[..]		2025-10-20	12:00:16	0
MAIN.ASM	2025-10-20	07:44:04	9269
MAIN.HEX	2025-10-20	07:44:06	1052
MAIN.LST	2025-10-20	07:44:06	19296
5 files found

I can follow the clusters for a file extending over multiple clusters, but there is as yet no way to open a file; I need something to find a file name in the directory cluster(s) for the current working directory, then take that back to the FAT.

My intent is that the user will be able to read (and eventually write) only from (to) the current directory, or change up and down the directory tree. I'm not touching long file names; the data is scattered through the cluster like it's been through a shotgun, and I don't want to get involved UTF-8. I'm also considering how much static data is required, which I obviously want to keep to a minimum on a 32k system. It needs a common 2-page transient area, but multiple files open will all need their own sector pages, plus various pointers and filename fragments. Hmm.

Neil

[barnacle]

The PCBs arrived from JLC this morning. Imagine how much nicer they'd be if I'd got the pads on the CF connector in the right place... at the moment they're exactly 0.375mm offset to the north (on this view), one pitch centre. No matter, a rat-tail file will resolve the issue, I suspect.

Meanwhile, the antigravity version continues to proceed; I can read individual sectors so I'm recreating the stuff I did previously in C. Nothing to see yet, though.

Neil

[barnacle]

The complete diagram, in black and white:

6502_cf_2_a.pdf

(585.52 KiB) Downloaded 58 times

Neil

[SamCoVT]

barnacle wrote:

I can follow the clusters for a file extending over multiple clusters, but there is as yet no way to open a file; I need something to find a file name in the directory cluster(s) for the current working directory, then take that back to the FAT.

My intent is that the user will be able to read (and eventually write) only from (to) the current directory, or change up and down the directory tree. I'm not touching long file names; the data is scattered through the cluster like it's been through a shotgun, and I don't want to get involved UTF-8. I'm also considering how much static data is required, which I obviously want to keep to a minimum on a 32k system. It needs a common 2-page transient area, but multiple files open will all need their own sector pages, plus various pointers and filename fragments. Hmm.

That's great progress. You can see how they ended up with File Control Blocks (FCB) on CP/M and old DOS. I made some of your same decisions (ignore long file names, for example) and made it as far as reading files by name, which was enough for my application at the time.

I ended up with a single sector buffer, used for accessing the FAT as well as file data. It thrashes a lot, as you would expect with a single buffer, but the CF is so fast that I didn't find that to be an issue. I used a file control structure for each file that was "open" that kept track of the filename (in directory entry format), attributes, first cluster, current cluster, current sector, fileposition (in bytes from beginning of file), file size and some extra info used for parsing lines (eg. the file position of the beginning of the current line in case I need to re-read it in). That last bit you probably won't need for your application.

Good work! Hopefully you can get your hardware gremlins (in the other thread) tamed so your new boards work.

[barnacle]

Thank you. With the C - easy enough to translate once I get the 65c02 board working - I am now as far as finding the start sector of a file, or directory, given the filename. Debating where to put fread() equivalancy in the handling; I'm thinking of a single transient sector (I think I stole that idea from CP/M) to handle all read and writes, with some sort of FCB as you have, for the same reasons. It does need something, for example, to avoid reading the directory and sector each time I want a byte...

Code: Select all

MAIN    C  	 cluster 20

0000 2f 2a 20 55 53 45 52 20 43 4f 44 45 20 42 45 47  - /* USER CODE BEG
0010 49 4e 20 48 65 61 64 65 72 20 2a 2f 0d 0a 2f 2a  - IN Header */../*
0020 2a 0d 0a 20 20 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a  - *..  ***********
0030 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a  - ****************
0040 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a  - ****************
0050 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a  - ****************
0060 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a  - ****************
0070 2a 2a 2a 0d 0a 20 20 2a 20 40 66 69 6c 65 20 20  - ***..  * @file  
0080 20 20 20 20 20 20 20 20 20 3a 20 6d 61 69 6e 2e  -          : main.
0090 63 0d 0a 20 20 2a 20 40 62 72 69 65 66 20 20 20  - c..  * @brief   
00a0 20 20 20 20 20 20 20 3a 20 4d 61 69 6e 20 70 72  -        : Main pr
00b0 6f 67 72 61 6d 20 62 6f 64 79 0d 0a 20 20 2a 2a  - ogram body..  **
00c0 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a  - ****************
00d0 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a  - ****************
00e0 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a  - ****************
00f0 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a  - ****************
0100 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 0d 0a 20 20  - ************..  
0110 2a 20 40 61 74 74 65 6e 74 69 6f 6e 0d 0a 20 20  - * @attention..  
0120 2a 0d 0a 20 20 2a 20 3c 68 32 3e 3c 63 65 6e 74  - *..  * <h2><cent
0130 65 72 3e 26 63 6f 70 79 3b 20 43 6f 70 79 72 69  - er>© Copyri
0140 67 68 74 20 28 63 29 20 32 30 32 30 20 53 54 4d  - ght (c) 2020 STM
0150 69 63 72 6f 65 6c 65 63 74 72 6f 6e 69 63 73 2e  - icroelectronics.
0160 0d 0a 20 20 2a 20 41 6c 6c 20 72 69 67 68 74 73  - ..  * All rights
0170 20 72 65 73 65 72 76 65 64 2e 3c 2f 63 65 6e 74  -  reserved.</cent
0180 65 72 3e 3c 2f 68 32 3e 0d 0a 20 20 2a 0d 0a 20  - er></h2>..  *.. 
0190 20 2a 20 54 68 69 73 20 73 6f 66 74 77 61 72 65  -  * This software
01a0 20 63 6f 6d 70 6f 6e 65 6e 74 20 69 73 20 6c 69  -  component is li
01b0 63 65 6e 73 65 64 20 62 79 20 53 54 20 75 6e 64  - censed by ST und
01c0 65 72 20 42 53 44 20 33 2d 43 6c 61 75 73 65 20  - er BSD 3-Clause 
01d0 6c 69 63 65 6e 73 65 2c 0d 0a 20 20 2a 20 74 68  - license,..  * th
01e0 65 20 22 4c 69 63 65 6e 73 65 22 3b 20 59 6f 75  - e "License"; You
01f0 20 6d 61 79 20 6e 6f 74 20 75 73 65 20 74 68 69  -  may not use thi
0000 73 20 66 69 6c 65 20 65 78 63 65 70 74 20 69 6e  - s file except in
0010 20 63 6f 6d 70 6c 69 61 6e 63 65 20 77 69 74 68  -  compliance with
0020 20 74 68 65 0d 0a 20 20 2a 20 4c 69 63 65 6e 73  -  the..  * Licens
0030 65 2e 20 59 6f 75 20 6d 61 79 20 6f 62 74 61 69  - e. You may obtai
0040 6e 20 61 20 63 6f 70 79 20 6f 66 20 74 68 65 20  - n a copy of the 
0050 4c 69 63 65 6e 73 65 20 61 74 3a 0d 0a 20 20 2a  - License at:..  *
0060 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20  -                 
0070 20 20 20 20 20 20 20 20 6f 70 65 6e 73 6f 75 72  -         opensour
0080 63 65 2e 6f 72 67 2f 6c 69 63 65 6e 73 65 73 2f  - ce.org/licenses/
0090 42 53 44 2d 33 2d 43 6c 61 75 73 65 0d 0a 20 20  - BSD-3-Clause..  
00a0 2a 0d 0a 20 20 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a  - *..  ***********
00b0 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a  - ****************
00c0 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a  - ****************
00d0 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a  - ****************
00e0 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a  - ****************
00f0 2a 2a 2a 0d 0a 20 20 2a 0d 0a 20 20 2a 20 57 69  - ***..  *..  * Wi
0100 64 67 65 74 20 4d 6b 20 36 2e 32 0d 0a 20 20 2a  - dget Mk 6.2..  *
0110 0d 0a 20 20 2a 20 50 6f 72 74 65 64 20 66 72 6f  - ..  * Ported fro
0120 6d 20 4d 6b 34 20 63 6f 64 65 20 77 69 74 68 20  - m Mk4 code with 
0130 73 69 67 6e 69 66 69 63 61 6e 74 20 63 68 61 6e  - significant chan
0140 67 65 73 3a 0d 0a 20 20 2a 20 2d 20 55 73 65 73  - ges:..  * - Uses
0150 20 4f 4c 45 44 20 64 69 73 70 6c 61 79 20 28 68  -  OLED display (h
0160 69 64 65 6f 75 73 6c 79 20 65 78 70 65 6e 73 69  - ideously expensi
0170 76 65 20 62 75 74 20 76 65 72 79 20 70 72 65 74  - ve but very pret
0180 74 79 29 20 69 6e 73 74 65 61 64 20 6f 66 20 4c  - ty) instead of L
0190 43 44 0d 0a 20 20 2a 20 2d 20 55 73 65 73 20 41  - CD..  * - Uses A
01a0 52 4d 20 53 54 4d 33 32 4c 30 37 33 20 34 38 2d  - RM STM32L073 48-
01b0 70 69 6e 20 70 72 6f 63 65 73 73 6f 72 20 69 6e  - pin processor in
01c0 73 74 65 61 64 20 6f 66 20 41 54 4d 45 4c 20 41  - stead of ATMEL A
01d0 56 52 0d 0a 20 20 2a 20 2d 20 55 73 65 73 20 67  - VR..  * - Uses g
01e0 65 6e 65 72 69 63 20 52 53 32 33 32 2d 6f 76 65  - eneric RS232-ove
01f0 72 2d 62 6c 75 65 74 6f 6f 74 68 20 6d 6f 64 75  - r-bluetooth modu
0000 6c 65 20 69 6e 73 74 65 61 64 20 6f 66 20 61 20  - le instead of a 
0010 73 65 72 69 61 6c 2d 55 53 42 20 63 68 69 70 0d  - serial-USB chip.
0020 0a 20 20 2a 20 2d 20 4e 6f 74 65 20 73 61 6d 65  - .  * - Note same
0030 20 63 6f 64 65 20 61 73 20 66 6f 72 20 6d 6b 20  -  code as for mk 
0040 36 20 28 36 34 20 70 69 6e 20 76 65 72 73 69 6f  - 6 (64 pin versio
0050 6e 29 0d 0a 20 20 2a 0d 0a 20 20 2a 20 52 65 63  - n)..  *..  * Rec
0060 6f 6d 6d 65 6e 64 65 64 20 73 65 72 69 61 6c 20  - ommended serial 
0070 70 72 6f 67 72 61 6d 20 66 6f 72 20 41 6e 64 72  - program for Andr
0080 6f 69 64 20 70 68 6f 6e 65 20 69 73 0d 0a 20 20  - oid phone is..  
0090 2a 20 68 74 74 70 73 3a 2f 2f 70 6c 61 79 2e 67  - * https://play.g
00a0 6f 6f 67 6c 65 2e 63 6f 6d 2f 73 74 6f 72 65 2f  - oogle.com/store/
00b0 61 70 70 73 2f 64 65 74 61 69 6c 73 3f 69 64 3d  - apps/details?id=
00c0 64 65 2e 6b 61 69 5f 6d 6f 72 69 63 68 2e 73 65  - de.kai_morich.se
00d0 72 69 61 6c 5f 62 6c 75 65 74 6f 6f 74 68 5f 74  - rial_bluetooth_t
00e0 65 72 6d 69 6e 61 6c 0d 0a 20 20 2a 20 73 65 74  - erminal..  * set
00f0 20 75 70 20 74 6f 20 63 6c 65 61 72 20 69 6e 70  -  up to clear inp
0100 75 74 20 6f 6e 20 73 65 6e 64 2c 20 74 75 72 6e  - ut on send, turn
0110 20 74 69 6d 65 73 74 61 6d 70 73 20 6f 66 66 2c  -  timestamps off,
0120 0d 0a 20 20 2a 0d 0a 20 20 2a 2f 0d 0a 2f 2a 20  - ..  *..  */../* 
0130 55 53 45 52 20 43 4f 44 45 20 45 4e 44 20 48 65  - USER CODE END He
0140 61 64 65 72 20 2a 2f 0d 0a 2f 2a 20 49 6e 63 6c  - ader */../* Incl
0150 75 64 65 73 20 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d  - udes -----------
0160 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d  - ----------------
0170 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d  - ----------------
0180 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d  - ----------------
0190 2d 2d 2d 2d 2d 2d 2d 2a 2f 0d 0a 23 69 6e 63 6c  - -------*/..#incl
01a0 75 64 65 20 22 6d 61 69 6e 2e 68 22 0d 0a 0d 0a  - ude "main.h"....
01b0 2f 2a 20 50 72 69 76 61 74 65 20 69 6e 63 6c 75  - /* Private inclu
01c0 64 65 73 20 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d  - des ------------
01d0 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d  - ----------------
01e0 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d  - ----------------
01f0 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2a 2f  - --------------*/

(just some sample text file I stuck on the cf for testing)

Actually called from

Code: Select all

    // display part of a file
    show_cluster(find_file(0,"main.c"));

So you can see there's already quite a lot going on. Getting my head around the 2-cluster offset between the cluster referenced in the directory listing (in this case, 0x20) and where it actually is in the clusters (here, 0x1E).

Neil

[SamCoVT]

barnacle wrote:

So you can see there's already quite a lot going on. Getting my head around the 2-cluster offset between the cluster referenced in the directory listing (in this case, 0x20) and where it actually is in the clusters (here, 0x1E).

Yeah, it does seem weird that the very first cluster is not cluster #0 but rather cluster #2, so you will need to subtract 2 from the cluster numbers in the directory when calculating what sector on the disk you want to read. This is because the first two entries in the FAT hold special data so 0 and 1 do not reference clusters at all.

If you want to skip having to subtract 2 all the time, I believe you can just move your "start of data clusters" LBA address back by two clusters. The danger of doing that is that if you ever do access 0 or 1, you'll be in the FAT rather than the data clusters (then again, if you try to access cluster 0 or 1 with the subtract_2 method, you'll also be in trouble).

[barnacle]

Yeah. It's tricky: the numbers in the FAT refer to FAT records, so record 5 is the fifth record along. But they _also_ refer to clusters, and cluster 5 is the third cluster along. Snag is, MS uses the same name for both which doesn't help.

Anyway, the board problems appear to be fixed (aka I am a idiot) so I'm starting to look at the 65c02 access stuff again.

Neil

[BigDumbDinosaur]

barnacle wrote:

Yeah. It's tricky: the numbers in the FAT refer to FAT records, so record 5 is the fifth record along. But they _also_ refer to clusters, and cluster 5 is the third cluster along. Snag is, MS uses the same name for both which doesn't help.

FAT32 is nothing more than a couple of band-aids stuck on FAT16, which itself was a mish-mash of FAT12, Micro-Soft’s aberration of their aberration (FAT) of the easily-corrupted CP/M “filesystem”. 

Not too long after QDOS had morphed in to MS-DOS, Micro-Soft had to figure out how to add a tree-style directory structure to FAT so as to not appear too far out-of-date to UNIX weenies.  Rather than acknowledge that patching FAT would be too much like putting lipstick on a pig and a total rewrite would be a better course of action, they went ahead with the makeup kit, and proceeded to develop something that was even more corruption-prone than its CP/M ancestor: FAT12.  Peter Norton became hideously wealthy selling his wares to an entire generation of MS-DOS users stuck with FAT-based filesystems, and programmers cursed under their collective breath as they wrote directory parsing code. 

A truly horrid arrangement, in my humble opinion.

BTW, Micro-Soft’s implementation of FAT12 had several insidious bugs, one being an outright logic error that was probably the number one cause of disk corruption.  As I said, Peter Norton made a boat-load of money selling disk repair software.