Hi Geoff,
I'll try to answer your questions as clearly as possible.
1. Regarding the Read Sectors routine -
This is just used to load the fat, directory and boot file from the floppy disk into memory. As you have correctly understood - EFL doesn't write the code for you it just simplifies booting a file from a fat structure. What you want to do is write code to be placed in the boot file to handle your access to the CF card. Think of it as a mini OS. Using the example of EFL you could write code to create a fat for your CF card and then write a few functions to use the card e.g.create_file, read_sectors and write_sectors. Place this code in the XCOMMAND.BIN file.
You could alter the load address used by EFL to boot your code into high memory. You could then load some code at 100H ie. a program, to play with and test the functions you have written. The two routines which you may find directly useful are CLUSTER2LBA and LBA2CHS which translate between LBA and CHS adressing - To keep things simple I only used track and sector addressing but say, a hard disk, would also use head addressing in CHS mode. Since LBA can simply use sector addressing this is the simplest and (these days) most universally compatible method. A logical sector is just a physical sector adjusted by for the sectors offset of the fat and directory - in EFL the data section starts at logical sector 0.
So, yes you are correct - a rewritten subroutine along the lines of Read Sectors but specifically for the CF card would be one such function - with the qualifier that it reads from the CF cards own fat.
Ultimately I would envisage the developed LBA low level disk routines as MOS routine counterparts of the floppy functions to be added to an expanded EPROM -
MOS 2.0? :) These would then be called by the CBIOS of whatever operating system is developed.
A tip : Creating a FAT for your CF card is dead easy. All you have to do is calculate and reserve the number of sectors that will hold all of the FAT words to address the entire card. As EFL is just Fat 16 at the moment you might have to use large cluster sizes or partition the card into smaller virtual drives.
Because a fat is just a linked list of cluster pointers, a new unused fat is just a sequential series. So all you have to do is write words 1,2,3,...nnn in order, to your reserved sectors and there is your fat, ready for action. (0 points to 1, 1 points to 2 etc.) It is also useful to keep a a tracking variable called something like FirstFree which as its name suggests, always points to the first free cluster in the chain - useful when creating a new file.
2. Yes! You add additional files to the Root directory exactly as you described. Remember to reduce the directory space tail by 32 bytes for each additional entry.
So once you have formatted YCOMMAND.BIN you have DS (512*8)-64,$E5 to the end of the Directory.
Fat1 does need to be altered also. e.g.
Fat1: DW $0001 ; Cluster 0 (XCOMMAND.BIN) ... uses 2 clusters
DW $FFFF ; Cluster 1 (XCOMMAND.BIN)
DW $0003 ; Cluster 2 (YCOMMAND.BIN) ... uses 3 clusters
DW $0004 ; Cluster 3 (YCOMMAND.BIN)
DW $FFFF ; Cluster 4 (YCOMMAND.BIN)
adjust this
DS ((512*2)-10),0 ; the rest are free.
Finally the Data section currently contains the allocated cluster for file XCOMMAND.BIN so you are right, the next file cluster to be allocated would start at EndProg.
However I spotted a bug since the boot block is set to 2 sectors per cluster. XCOMMAND.BIN uses 2 clusters ,so in fact it is 2k long not 1k
The real free space for XCOMMAND.BIN should have been -
EndProg: DS (2048-(EndProg-SignOnMsg)),'D' and YCOMMAND.BIN data would start after this.
Filling to the end of space is not essential. It does however provide a wayof checking if your load has worked as you expected it to and it avoids loading garbage from the disk.
----- Original Message -----
Sent: Thursday, March 20, 2008 11:25 AM
Subject: [tatung_einstein] Re: The Experimental FAT Loader
Hi Phil,
A couple of questions;
If I wanted to read from a CF card plugged into my adaptor would I
just have to re-write "ReadSectors:" to call the code to read a block
from the CF instead of calling ZRBLK? (I'll obviously have to write
the code first. I know there's no space for it, yet...)
Assuming the CF card contains the same data as created by your ASM
file (i.e. formatted FAT16 with one file called XCOMMANDBIN), would I
simply be able to add another file to the Root Directory like so;
Root: DM "XCOMMANDBIN"
DB 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
FClust: DW $0000 ; points to first cluster of file (0)
DB 0,0,0,0
DM "YCOMMANDBIN"
DB 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
DW $0002 ; points to first cluster of file (1)
DB 0,0,0,0
DS (512*8)-32,$E5
then add the data for the file after "SignOnMsg:" and "Endprog:",
making sure to fill the space as "Endprog:" does.
Or do I also need to ad anything to "Fat1:"
I may be reading it wrong but I think that I could then change
"CmdFileName:" to either run XCOMMANDBIN or YCOMMANDBIN
NOTE: I'm not planning on doing the above but want to know if I
understand the concepts in your code. Like I've said before I'm no
software expert.
If it helps you there is some information on LBA addressing for a CF
card in my Compact Flash Access Guide in the files section of the
site. Addressing an IDE adaptor would be the same
Regards,
Geoff
No virus found in this incoming message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.21.7/1329 - Release Date: 14/03/08 12:33
Offline 
Send Email