[Coco] dw 3

[Luis Fernandez]

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