[Coco] Getting more out of floppy disks

[Arthur Flexser]

The problem with the FAT buffer is not a serious one, so long as you don't
intend to have open files on more than one drive at once.  There is a single
byte that controls the offset from where one drive's FAT buffer begins to the
beginning of the next one.  Setting that byte to a value of one causes no
serious problems;  ADOS uses this method to support 40- and 80-track drives. (A
double-sided 80-track drive is treated as two 80-track single-sided ones.) So
where standard RSDOS allows for four non-overlapping 35-track FAT buffers, you
can easily accommodate 80-track buffers by overlapping.  I think treating all 80
tracks of the drive as a single drive by this method is much easier than your
proposed scheme of treating tracks above 40 as a second 40-track drive on the
same side.

Art

On Thu, 14 Feb 2008, CoCo Mongrel wrote:

> So for the game I'm working on, I'd like to get as much out of a single
> floppy disk as I can without wasting a lot of CPU or memory on complex
> compression algorithms.  I would like to provide the option for those who
> have more modern floppy drives or hard drives with multiple RS-DOS
> partitions to use them to store lots of game data.
> 
> I have 80-track (3.5") drives on my CoCo, but they're being used as 35-track
> double-sided drives.  I still prefer the 720K floppies, even though there's
> a lot of waste (though I do use the full capacity in OS-9) because data
> transfer with modern PCs is easier using 3.5" disks.
> 
> I know there are DOSes, and patches to stock RS-DOS that go from 35 to 40
> tracks, and that allow you to map the second side of the disk to otherwise
> unused drive numbers (e.g. 2,3).  But on 80 track drives, that still only
> uses half of the disk.  My understanding is that BASIC's FAT buffer would
> have to be expanded in order to use 80 tracks (or something like that).  But
> how difficult would it be to make DECB treat track 40 as track 0?  That way
> you could have a whole upper bank of 40 tracks on each side of a disk.  The
> inconvenient part would be that you'd have to poke a bunch of changes back
> and forth to switch between the lower bank and the upper bank, so it
> wouldn't be well suited to everyday interactive use.  But it wouldn't be at
> all difficult to make a BASIC program keep track of which bank you were in,
> and just have a subroutine to patch DECB for the lower or the upper 40
> tracks as necessary.  Or am I fooling myself about how difficult it would be
> to get BASIC to add 40 to its tracks?  Any thoughts?
> 
> CoCoMongrel
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>