[Coco] Getting more out of floppy disks

[Robert Gault]

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
> 

There are limits to how you can change any ROM code with POKEs. If you 
are not willing to write your own ml routines for the game, don't expect 
to make major changes in the ROMs.

You can with POKE increase the maximum track value that DKSI$ can 
access. That will not permit DOS to use more of the disk for program 
storage (LOAD/SAVE or LOADM/SAVEM) because the FAT and buffer areas 
would all need to be changed.

So about the best you can do with Basic is POKE the track max values and
FOR T=35 TO 79
FOR S=1 TO 18
DSKI$ 0, T, S, A$, B$
do something with A$ and B$
NEXT S,T