[Coco] dw 3

Tue Nov 23 22:24:09 EST 2010

On Tue, Nov 23, 2010 at 10:32 PM, Frank Pittel <fwp at deepthought.com> wrote:
> 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. :-)
>

I'll be there!  Looking forward to it.

I test each release of DW4 on a few Linux distros in virtual machines
here. I know at least a handful of people are using it with linux,
because I helped them get it going.  We have some instructions on the
wiki for Linux:
https://sourceforge.net/apps/mediawiki/drivewireserver/index.php?title=Installation

The documentation isn't great but it's slowly getting better.  Someday
this thing will be as polished as it really should be... maybe not in
my lifetime, but someday :)

You can also always email me directly (aawolfe at gmail.com) or find me
and other coco nuts on the CoCo chat IRC:
http://webchat.freenode.net/?channels=coco_chat

Always happy to help anyone with DW or other CoCo issues if I can.

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