[Coco] dw 3

[Frank Pittel]

Any chance of getting this ported to linux? I'm looking forward to giving this a
try.

The Other Frank


On Wed, Nov 24, 2010 at 02:39:00AM +0000, Luis Fernandez wrote:
> 
> Frank Pittel
> I built in two weeks a utility built into windows to see and review DSK
> I saw no good
> Toolshed does many things but commands
> 
> The 0.8 beta
> 
> - Copy of PC and vice versa COCO
> - Format, Create empty disk DSK, desfracmenta, orders DSK.
> - Check FAT errors
> - View of Ski and sectors
> - Format coconut, coconut characters in windows (to remember).
> - Convert BIN BAS ASC and vice versa
> - View and edit text DSK
> - View and edit HEX DSK
> - Erase PC and DSK
> - Sort By Name Size in Bytes granules in granule Etc. first ascending and descending.
> - English and Spanish languages, expandable
> 
> COMING SOON
> 
> - OS9 and NITRO, 40 tarck, 80 tack and DD, if someone has knowledge and information on the subject, will welcome
> - Drag and drop
> - Desfracmenta
> - Sort By Name Size in Bytes granules in granule Etc. first ascending and descending.
> - The sources may lead to the end, so that duplicates alla changes there.
>   The idea is that I ask for them, for now, and if I can the please.
> - Compare many. DSK and see if there are duplicate programs. adding into each other.
> 
> Surely there are better, lol
> 
> Suggestions and improvements, aids in tests
> Yes there are better tell me I better use this or another and now, hahaha
> If anyone has knowledge and information on the subject, will welcome
> 
> Luis Fernandez.
> 
> > Date: Tue, 23 Nov 2010 20:22:21 -0600
> > From: fwp at deepthought.com
> > To: coco at maltedmedia.com
> > Subject: Re: [Coco] dw 3
> > 
> > On Tue, Nov 23, 2010 at 07:42:20PM -0500, Aaron Wolfe wrote:
> > > On Tue, Nov 23, 2010 at 7:07 PM, Robert Gault <robert.gault at att.net> wrote:
> > > > Aaron Wolfe wrote:
> > > >
> > > >>
> > > >> How about a tool to turn these 256drive.dsk images into a directory of
> > > >> separate .dsk files and automatically generate the dw4 disk set
> > > >> definition to load them together?  The user can then temporarily map
> > > >> in a disk from any source, including another "converted" 256drive.dsk
> > > >> and do the copy or backup directly.  The disk set definition allows
> > > >> these files to be loaded together into the 256 "drives" just like a
> > > >> 256drive.dsk.
> > > >>
> > > >> I am basing this solution on the 256drive.dsk format being used only
> > > >> with drivewire and hdbdos.. nothing else reads these, so we aren't
> > > >> losing compatibility with anything by just getting rid of them,
> > > >> correct?
> > > >>
> > > >
> > > > To be frank, I'm not sure I understand what you propose. I think it may be
> > > > what we need but without a specific example or a demonstration, I can't
> > > > tell. Maybe a rewording of the proposal?
> > > >
> > > >>
> > > >> I can add a parameter to a disk set that tells dw4 to compensate for
> > > >> this offset, and add a matching per drive setting with a 'dw' command
> > > >> to toggle it.  Similar to hosw things like write protect work.  Would
> > > >> that work, and if so, how do i compensate for the offset?
> > > >>
> > > >
> > > > The Disk Basic sector offset is contained in the HDBDOS/RGBDOS ROM, bytes
> > > > $D939-$D93A. This a 24-bit address. The value for MESS and VCC by default is
> > > > $5A000 and very unlikely to have been changed by any user. Hardware systems
> > > > are different given different sizes of hard drive. The offset value could be
> > > > anything depending on the size of the drive and whether the user requires
> > > > OS-9 and/or Disk Basic.
> > > >
> > > > You may find that DW4 needs to determine the offset directly from the .dsk
> > > > or .vhd image rather than the HDBDOS ROM. That can be done but there is no
> > > > sure-fire method for determining if the first part of the drive is an OS-9
> > > > partition. If it were, then the first three bytes of LSN0 give the size of
> > > > the drive in sectors and is the offset.
> > > > As it happens, there is also no distinction between backing up an OS-9
> > > > floppy to drive0 on a multi-drive .dsk image from a true .vhd image that is
> > > > say half OS-9 and half Disk Basic. Luckily the point is moot because the
> > > > first three bytes of LSN0 are still valid.
> > > >
> > > > I probably should throw in the following possibility. You don't need to
> > > > limit the number of Disk Basic drives on a .vhd or true hard drive to 256.
> > > > Since a Coco3 runs in full RAM, the bytes at $D939-$D93A may be POKEd with
> > > > new values. That means you can have multiple Disk Basic partitions each with
> > > > 256 drives if the hard drive or image is larg enough.
> > > >
> > > 
> > > 
> > > Ok.  I think what we are looking at is a system that works very well
> > > for real hard drives (or CF cards, etc.. any large storage directly
> > > attached to a CoCo) but does not work well for a PC tethered solution.
> > > 
> > > With "real" storage, it makes perfect sense to store multiple disk
> > > images in a partition.  However, this strategy seems inconvenient when
> > > used with DriveWire.   Doing a literal translation of the "partition
> > > full of disks" to a "file full of disks" just makes it more difficult
> > > to do things with those disks in the DriveWire scenario, and doesn't
> > > provide any benefit that I can see.   If I'm missing something please
> > > let me know.
> > > 
> > > I would propose that going forward, we load individual disks rather
> > > than files containing 256 disks.  This allows easier management of
> > > files and makes it easy to get disks in and out of the CoCo system.
> > > 
> > > If that is agreeable, then the remaining issues would be to continue
> > > support for those who prefer the 256 disk files (already done) and to
> > > provide a mechanism for those who wish to transition to individual
> > > .dsk files to do so.
> > > 
> > > This is what the utility I mentioned before would do.  It would take
> > > as input a large file containing 256 disks and create as output (up
> > > to) 256 individual .dsk files, each containing one disk image.  At the
> > > same time, it would create a disk set definition for these new files
> > > so that they can all be loaded with a single operation, effectively
> > > the same as mounting the original file is a single operation.
> > > 
> > > It seems that supporting the .vhd files is again an example of using
> > > DriveWire in a less than convenient way but if someone is operating
> > > from such a file, I'd like to be able to support that.
> > > I suspect that this is not common.  How about just letting the user
> > > specify the offset to be used rather than trying to determine it
> > > automatically?
> > > 
> > > Does any or all of this sound workable?
> > 
> > In the long run it may be easier to use indvidual files rather then single files
> > with large numbers of disks. I don't have my rsdos book handy but as memory
> > serves it's possible to "name" a floppy. Any chance of drivewire naming the .dsk
> > file to that label? Also, in the interests of maintainability you may want to
> > offer the ability to "load" a directory. That directory would have the .dsk
> > files to be loaded and optionally a file that contains the order. Having to
> > manually "load" 256 files into the drivewire server would be a major pain!
> > 
> > The Other Frank
> > 
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > http://five.pairlist.net/mailman/listinfo/coco
>  		 	   		  
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco