Greetings all.

I've been working on some 6502 designs and now have a reasonably repeatable and flexible basic design. One of the things I wanted was a hard drive so after browsing all the 8 bit IDE pages I could find I've built one (not the same as anyone elses but is it ever?)

Now it works and I can identify devices and device types, read and write sectors, select master or slave etc. I have begun thinking about a file system and have sketched a few requirements...

Must have 32 bit pointers, well with one of my "spare" drives being 1.8GB I figure full LBA addressing is the only way to go so a FAT32 lookalike perhaps?

Some sort of boot specification, at the moment it can only boot from disk into BASIC as that is the only thing I have full source for and can change to suit.

Filenames, not 8.3! But what maximum length? Keeping it to less than 256 characters would make parsing easier but just how long?

Block use. Some sort of availability map so I don't have to steal bytes in each sector to chain them which makes file transfer to/from disk much easier.

Compatability with other filesystems isn't important as this will only be for the micro's own fixed disks. Other filesystems such as CDROM and Zip could be later bolt ons.

Ideas anyone?

Cheers,
Lee.

Although it's not really 6502-related, I'll chip in here a bit, as long as you promise to use it with a 6502 system ha ha

>Filenames, not 8.3! But what maximum length?
>Keeping it to less than 256 characters would
>make parsing easier but just how long?

Names of files, variables, constants, functions, or whatever should be long enough to be descriptive, but not so long so as to become unwieldy. The assemblers I've worked with, as well as my Forth, allow 31-character names. I don't know that I've ever needed that many, but there have been times that 15 would have been too limiting. Of course a nice thing about names in Forth is that you can use any characters except the space, nul, <CR>, and generally the backspace, <LF>, <FF>, and escape characters. The special characters are very useful, including things like the degree and square root symbols, foreign characters, and even the Greek characters we use so much in engineering.

As to an availability map, file-allocation table, etc. on a disc, I cannot speak from experience; but have you considered file chains? I've done this in battery-backed RAM without a FAT (yes, in a 6502 system). It would have to work a little differently on a disc that's divided up into sectors and so on (and may even have bad sectors sprinkled around which must be avoided), but I'd entertain some discussion on it. If it's too unrelated to the 65k family, maybe we should take the discussion off-line. Until then, I'll keep watching here.

Garth Wilson

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

>Although it's not really 6502-related, I'll chip in here a bit,
>as long as you promise to use it with a 6502 system ha ha

Of course it's for a 6502 system, if it were for something else, say a Z80 system, I would have just used CP/M 3. The target system is a 1.8MHz 6502, 60K RAM, 2K ROM, 6551, Quantum Fireball 1080 and a Quantum Trailblazer 850.

Yet to be finished is the 640x400 graphic LCD and IBM keyboard ports.

>>Filenames, not 8.3! But what maximum length?

>Names of files, variables, constants, functions, or whatever
>should be long enough to be descriptive, but not so long so
>as to become unwieldy. The assemblers I've worked with, as
>well as my Forth, allow 31-character names.

I was thinking 32 max as a good trade between usefull length and size.

>Of course a nice thing about names in Forth is that you can
>use any characters except the space, nul, <CR>, and generally
>the backspace, <LF>, <FF>, and escape characters

As for characters I thought any except those from $00 to $1F. Spaces in a name would probably mean using quotes round filenames but I can live with that.

>As to an availability map, file-allocation table, etc. on a
>disc, I cannot speak from experience; but have you considered
>file chains?

Thought about it but it will mean, I think, having pointers stored in each sector. This makes data transfers a little harder than the 512 bytes/sector if you use a FAT but the big minus for chains would be searching the chain for free space an a big drive. Ok so I'm currently only using 17 sectors (8.5K) on the Trailblazer but I want to be able to use it all easily.

>I've done this in battery-backed RAM without a FAT (yes, in a
>6502 system).

Want to share the details?

>(and may even have bad sectors sprinkled around which must
>be avoided)

I've got the S.M.A.R.T. docs, banishes bad sectors. 8^)=

>If it's too unrelated to the 65k family, maybe we should
>take the discussion off-line. Until then, I'll keep
>watching here.

Like I said, this is specifically for a 6502 system which is why I asked here.

Lee.

I'm sure many here (including myself) would be interested in the software interface to these. I have most of the info here on the IBM AT keyboard, but I don't think it tells how to turn the three lights off and on.

Back on name lengths... 32 works out nicely in Forth not just because it's a reasonable length, but it allows the first byte of a Forth word's name field to have 5 bits for the length, 1 for precedence, 1 for smudge, and always leave the high bit set to facilitate finding the beginning of the name field when backing up from the code field or link field addresses. I won't go into the significance of the extra bits much here since Forth is not the point of this forum, but I'll be glad to discuss the innards with anyone on private E-mail. Having the 5 LSBs tell the length of the name means you don't have to use up 31 bytes for every name—only as much as the name needs. So if you had 6 bits for name length allowing names up to 63 bytes but never used more than 31, the extra allowance would not take any more room in memory, or in your case, the hard disc.


Thinking a little more about it, I do think it would be impractical to use the file chain idea on a large disc (1.8GB!), if in fact you really have thousands of files on it instead of fewer really long ones or leaving much of the disc untouched. (I'm sure that if you do use anywhere near that much space with a 6502 system, it would be for digital recording of some type, and not for humongous programs!) But to avoid having to search super-long chains of files, you could have several chains on the one disc, possibly dividing the files into categories. Within a file though, there would not need to be info in each sector pointing to where the next sector is (as in a system where they can get badly fragmented), so reading should not be difficult or slow. If you can keep the whole file together, part of the info in the file's header would tell how long the file is, and you can just read sequentially until you get to the end. Of course avoiding fragmentation if you edit the file and make it longer will require either scooting other files around to make room, or putting it somewhere else where there's enough room all in one place. It might be a good idea to store the file with a few extra sectors at the end, so the length can be changed some without having to scoot other files around as often. The file's header would tell not only how long the file is, but how much space is allocated to it, so that as you skip through the chain looking for a particular file, the header for the next file is easy to find.


In this case, there was just one chain in the memory. Partly to keep extra checks on the integrity of the chain, one variable held the number of files in the chain, another held the address of the first byte after the last EOF, and that byte had to hold a certain value. If any discrepancy was found after skipping through the chain by the headers, we figured that the back-up power went down low enough to really start fouling things up, so we would wipe it out and give the dreaded "memory lost" message. In reality, that never seemed to happen; but if it were more than once in a blue moon and the back-up power all seemed fine, the thing to do would have been to have a utility program that would search through the chain and try to put the pieces back together, warning if a given file appeared to be corrupted. Then at least you don't lose everything without an explanation. Since this file chain was all in RAM that's not divided into sectors or anything like that, we just put files right up against each other so all the free space was together at the end. This means that if a file was edited and enlarged, we had to scoot all the following files down to make room, and if the file was shrunk, all the following files would be moved in to take up the extra space produced. Being in RAM, all the extra movement of files went fast enough that the user was unaware of it.

With the sectored system of a disc, you would normally start every file header at the beginning of a sector, so that if the file chain ever did get corrupted, it would be easier to rescue most or possibly all of the data.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

>>Yet to be finished is the 640x400 graphic LCD and IBM keyboard

>>ports.

>I'm sure many here (including myself) would be interested in
>the software interface to these. I have most of the info here
>on the IBM AT keyboard, but I don't think it tells how to turn
>the three lights off and on.

I recently found my code to use an AT keyboard with an 8051 (and via that to my Amiga, much cheaper than a new Amiga keyboard!) so I'm going to translate that for the 6502. Some hardware issues remain, because I can't afford to have the 6502 constantly watching for a start signal from the keyboard like the 8051 does, there will need to be some sort of interrupt generator. From then on it's just bit banging through a synchronous link. Turning the lights on and off is quite easy, ISTR you just send a control byte, much like the reset sequence, and three of the bits control the LEDs directly.

When I finish I will porbably forward the details to Mike at 6502.org as I don't have my own site (yet).

>Back on name lengths... 32 works out nicely in Forth

[CUT]

>you don't have to use up 31 bytes for every name-- only as
>much as the name needs. So if you had 6 bits for name length
>allowing names up to 63 bytes but never used more than 31,
>the extra allowance would not take any more room in memory,
>or in your case, the hard disc.

I don't think space will be much of a problem, there will probably be some fixed format for directory entries with all the bytes defined and no variable length fields (i.e. unused bytes would be null). One though just occured to me, doesn't Forth have some disk handling built into the language? ISTR something about screens being used to store Forth source, could that be adapted for hard disk use?

>Thinking a little more about it, I do think it would be
>impractical to use the file chain idea on a large disc
>(1.8GB!), if in fact you really have thousands of files
>on it instead of fewer really long ones or leaving much
>of the disc untouched. (I'm sure that if you do use anywhere
>near that much space with a 6502 system, it would be for
>digital recording of some type, and not for humongous programs!)

One of the things I want to be able to do is store all the 6502 developement stuff on a 6502 system so I wouldn't need to use my PC or Amiga anymore for this. I could then develope directly on the target hardware. The need for space comes in when you realise the size of source files for anything remotely usefull as a system. So far I have a 27k long monitor source file and a 191k long floating point BASIC source file. If you assemble both these with the label lists, output lists, hex files and binary images you have well over half a meg of data allready.

Suddenly, even on a 6502 system 1GB doesn't seem too big. 8^)=

>Of course avoiding fragmentation if you edit the file
>and make it longer will require either scooting other
>files around to make room, or putting it somewhere else
>where there's enough room all in one place.

I've thought a bit about this and decided that if a file is extended beyond the end of it's last sector then a new file will be created and the old file marked as deleted. It looks like I'll be writing 6502scandisk.exe 8^)=

>This means that if a file was edited and enlarged, we
>had to scoot all the following files down to make room,
>and if the file was shrunk, all the following files would
>be moved in to take up the extra space produced. Being in
>RAM, all the extra movement of files went fast enough that
>the user was unaware of it.

That sounds much like how strings and arrays are held in BASIC, the interpreter I use can garbage collect 40+ KBytes of strings and string arrays in under a second, not bad but a little impractical for many megabytes.

>With the sectored system of a disc, you would normally
>start every file header at the beginning of a sector,
>so that if the file chain ever did get corrupted, it
>would be easier to rescue most or possibly all of the data.

ATM I'm planning 1 sector for the header/sector list with an extension sector list block(s) if needed. Fielsd in this so far are filesize, attributes (readable, writable, executable, deletable, archive), creation date, edited date and file comment (a feature from the Amiga file system that is sorely missing on dos/winxx).

I can see 6502scandisk.exe getting bigger. 8^)=

Cheers,
Lee.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Just to add my thoughts to this....

Why not consider adopting the file system from one of the free/GPL'd U*ix clones? This could give many advantages including a) the design work has already been done, b) you would only have to initially debug the reading code rather than the reading and writing code at the same time, c) you could plug the hard disk into the U*ix system and use some of the tools on it to help debug. For instance, why not adopt the 'ext2' file system from Linux? (I'm not sure of the technical implications of this i.e. size of pointers, size of structures etc though).

The information regarding 'ext2' is readily available on the internet as are many others.

Another useful thing would be that you could format a disk and copy some files onto it from your Linux system and then have something that you know is correct to work from.

Just my thoughts on the subject.....

Simon J

> Why not consider adopting the file system from one of
> the free/GPL'd U*ix clones? This could give many
> advantages including a) the design work has already been done,

I'd not thought of that as my only real contact with U*ix is the Sun workstations I sometimes use at work.

> b) you would only have to initially debug the reading
> code rather than the reading and writing code at the
> same time,

Writing is no harder than reading, it' easy enough to 'fake' any filesystem using an assembler and data statements to construct the disk blocks by hand.

> c) you could plug the hard disk into the U*ix system
> and use some of the tools on it to help debug.

I don't have one, a U*ix system that is, I do however have both PCs and Amigas but I don't want to have to implement partitioning and both those systems require it on fixed disks.

> The information regarding 'ext2' is readily available

Ext2fs offers some nice features but it also has way too much overhead for a single user, single tasking 6502 system. As the slowest part of this is the processor the less work the better.

> Another useful thing would be that you could format
> a disk and copy some files onto it from your Linux
> system and then have something that you know is correct
> to work from.

Format, that's another thing I'd like to avoid. You don't need to format the whole disk, only the root and block map.

For now I want the simplest system I can get away with that provides the features I want, later I'll add the MSDOS and CDROM drivers.

> Just my thoughts on the subject.....

Ta much,
Lee.

>> Yet to be finished is the 640x400 graphic LCD and IBM keyboard

>> ports.

> I'm sure many here (including myself) would be interested in the
> software interface to these. I have most of the info here on the
> IBM AT keyboard, but I don't think it tells how to turn the three
> lights off and on.

I've seen the software available for the AT keyboard and it's not the best, also the hardware described is not as simple as it could be. Lastly there is no decoder for the keyboard just the raw byte reader and decoding is a bit of a pain.

The good news however is I've nearly finished mine, the hardware is complete (and simple) and the software just has some key mapping issues to sort out (UK vs. US mapping). Once done I'll write it up and post it to www.6502.org

Cheers
Lee.

In general, the two strategies for managing disk space are FAT and I-block.

FAT you know: make a big table of all the clusters, and have directory entries point to this table (where the links between clusters are maintained)

I-blocks work slightly differently. The directory entries point to a cluster which contains a link map to the actual sectors used in the file. The Apple DOS used this scheme. It has the advantage that the usage map is one bit per cluster, not one word, and so (for a FAT 32) would be 1/32 the size. Also, other than on new file writes, the usage map does not get referenced, so it saves on disk movement, too.

Unix, of course, is a mix of these two; they essentially keep FATs for each section of disk (usually sized so that the i-node takes one cluster exactly).

Unix uses a 30 character filename limit, and limits qualified path length to 128 characters in most implementations (because the FILE structure in UNIX has a fixed-length string, to avoid dynamic memory allocation for the file system.

On a 6502, there is some advantage to using the 256-byte sector directly. Of course, every additional byte added to the address costs - memory, hard drive space & speed. I suggest you use 4 bytes, but avoid translation: have the 4 bytes be head/track/sector, thus you specify the exact position for the data in terms that need no translation.

Another advantage can be gained by having the usage map for a cylinder be in a single sector at the start of the cylinder - then you don't need to have any chain logic between them, and it can be as large as the HD is without any additional work.
WizWom

Lee,

That sounds excellent! I am sure there would be many people (myself included) interested in building that project.

Best Regards,
Mike

_________________
- Mike Naberezny (mike@naberezny.com) http://6502.org

the file system that was used in the 6800 and 6809 systems used a 'chain' system for the drives - i believe this was done by john start. there is no need to move files around as a file grew or was deleted. each sector used the last 4 bytes as two sixteen bit pointers to the previous and next sectors in the file. the first sector in the file was pointed to by the directory entry, and the last sectors next pointer was null. the o.s. kept another linked list of the unused sectors, and if w file needed to grow it removed the first entry from this ilst, and the linked list of a deleted file was appended to the end of this list.

this gave the user dynamic allocation of disk space, there was no need to 'pack' the drive to remove deleted files, and bad sectors were mapped out by not including them in the list of free sectors...

bob engle

> FAT you know: make a big table of all the clusters,
> and have directory entries point to this table (where
> the links between clusters are maintained)

> I-blocks work slightly differently. The directory
> entries point to a cluster which contains a link map
> to the actual sectors used in the file. It has the
> advantage that the usage map is one bit per cluster,
> not one word, and so (for a FAT 32) would be 1/32 the
> size. Also, other than on new file writes, the usage
> map does not get referenced, so it saves on disk movement,
> too.

I'm going to use a FAT, mostly so I don't have to read the disk to find out where the space is and I'm going to use it like is done with I-blocks i.e. one bit per sector.

I'm still not decided how I'm going to link the file blocks but I thing I'll keep the sector list in the file header and let the file header grow as needed to hold this list. Directories will be similar, a header for the directory "file" which holds all the subdirectory and file header pointers for that directory.

> I suggest you use 4 bytes, but avoid translation:
> have the 4 bytes be head/track/sector, thus you
> specify the exact position for the data in terms
> that need no translation.

I intend to avoid translation completely. There will be no head/track/sector addressing, everything will be done using LBA addressing and only LBA drives will be supported. Why? Well the only drive I have that doesn't support LBA addressing is a 40Mb seagate and as it doesn't work reliably anyway I'll never use it so no need.

Cheers,
Lee.

Hi Mike,

> That sounds excellent! I am sure there would be
> many people (myself included) interested in
> building that project.

I assume you mean the AT keyboard interface. If so I've allready posted it to www.6502.org and I'm sure it will be up on their pages very soon. 8^)=

I'm working on the follow up project now, I2C interface (very similar hardware) with a colour text/graphics VDU (can anyone say "teletext chip"?)
There may even be an I2C FM stereo radio circuit as well.

Cheers,
Lee.