From: Jim Brain (brain_at_jbrain.com)
Date: 2007-12-28 04:01:07
B. Degnan wrote: > >> >> >> As for the FS, I think it should be supported, but I don't know that >> it should be the only one supported. I think FAT should be supported >> as well, for folks who want to mount their CF and then pick it up and >> pop it into their PC. >> However, beyond the use of IDE partition tables, I can;t find a doc >> that explains the FS layout. Without it, it will be very hard to >> implement. > > > What would the doc(s) be called? Is it possible that there are CBM > service docs with this info. I am not sure what you mean exactly > (machine code or schematics). > > Bill I mean, on the ide64 website, I cannot find a document that explains the IDE64 native filesystem format. I have downloaded the IDEDOS source code, but it could take quite a bit of time to reverse engineer the FS format from the source. Thus, without that document explaining the disk format, it will require going through the source code to re-implement it. On a separate note, but to get it on the list, here is an idea for a CBM-DOS compatible FS that can handle more than 16MB partitions. Normally, a 16MB partition maximum size is due to 256 tracks * 256 sectors * 256 bytes/sector. Adding more bytes for Tracks or Sectors causes much grief and requires changing the physical layout of the sectors for directories and T&S linking. Still, if we treat the initial T&S of the file as a pointer to the VP, and the VP has a small BAM that hold just HI words of the T&S, then you can use the normal T&S of the sector layout as a new "pointer" to the next sector. The direntry hold an initial T&S of X:Y, where X >1. To open the file, DOS goes to the VP area, where the file BAM is located. The first 4 bytes are a reference to the next absolute sector. The next 4 bytes are the starting sector of the file. DOS then goes there, opens the file, records the T&S in the file and loads the data. If the client requests the next sector, the T&S from the first sector is used as a "pointer" to the VP BAM to find the next sector. The disadvantage is that the approach uses 6 bytes per sector (the 2 bytes in the sector + 4 bytes in the BAM) for linking as opposed to 2 in the original DOS. We can better, using 4 bytes per sector + 2 bytes: Start as before, going to the first sector, but record 2 bytes in RAM for this channel the "pointer" (would start at 0x0000). When the system asks for the next sector, increment the "pointer", dereference that location in the VP BAM to get one word of the next T&S and use the actual T&S of the current sector to get the other word. Probably it's best to put the HI word in the T&S area, and the low WORD in the VP BAM, since you can't use Track 0 (that is used to denote last track and the sector indicates the number of valid bytes in the track), but maybe there is a way around that. Obviously, this would not work for truly random access, where the CBM client asks for an arbitrary T&S. But, routines that use the file-based DOS routines would work, and a lot of the existing CBM layout should continue to work. Of course, the idea may be totally offbase, but I thought I would throw it out in case it helps. Jim -- Jim Brain, Brain Innovations (X) email@example.com Dabbling in WWW, Embedded Systems, Old CBM computers, and Good Times! Home: http://www.jbrain.com Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.