[Coco] dw 3

Tue Nov 23 22:32:48 EST 2010

On Tue, Nov 23, 2010 at 10:09:04PM -0500, Aaron Wolfe wrote:
> 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 :)

I took a look at dw4 and didn't have a lot of luck getting it to run on my linux
machine. For now I can do what I need via dw3 but would like to use dw4 in the
future. I was hoping to talk you into helping me getting it working during the
2011 cocofest. :-)

The Other Frank

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