[Coco] dw 3

[Aaron Wolfe]

On Tue, Nov 23, 2010 at 10:26 PM, Frank Pittel <fwp at deepthought.com> wrote:
>
> Any chance of getting this ported to linux? I'm looking forward to giving this a
> try.
>

Everything I write for the CoCo community runs on Windows, Linux, Mac,
and any other platform that has a Java JRE.  No need to port, it's
already supported :)

-Aaron


> 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
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>