From: MagerValp on 21 Oct 2006 20:28
>>>>> "WM" == Wolfgang Moser <wnhp(a)d81.de.invalid> writes:
WM> The type-in:
___ . . . . . + . . o
_|___|_ + . + . + . Per Olofsson, arkadspelare
o-o . . . o + MagerValp(a)cling.gu.se
- + + . http://www.cling.gu.se/~cl3polof/
From: Groepaz on 23 Oct 2006 18:37
Wolfgang Moser wrote:
> Groepaz schrieb:
>> MagerValp wrote:
>>> WM> :-) Along with Tok64 integrated to produce true BASIC files for
>>> WM> testing and cbmconvert for creating a D64...
>>> I've been using petcat -w2. How does that compare to Tok64?
>> btw, you can omit linenumbers when using petcat (only use them in lines
>> that are targets for goto/gosub)
> pretty funny, this would simplify some things.
> It seems we got a new competitor for the job
> of minimizing the size/effort for the
> minislave.txt type-in?
i dont think so....my next/current project is transfering disks...about 4000
of them o_O
Wanted dead and alive: Schroedinger's cat
From: Wolfgang Moser on 24 Oct 2006 04:59
> Wolfgang Moser wrote:
>> It seems we got a new competitor for the job
>> of minimizing the size/effort for the
>> minislave.txt type-in?
> i dont think so....my next/current project is transfering disks...about 4000
> of them o_O
ohhh well, that's what we love to do. With
such a crowd of disks there is only one
* Booting pure DOS or Win98
* Raising The Star Commander
* Copy Disk with:
- Automatic Index generation
- Automatic side label generation
!!! Disk change detection
Although the last three points could be
"simulated" with a little script for
OpenCBM and the command cbmctrl change.
SC combines these and a lot of other
functions really useful for such masses
But... you surely don't need
recommendations in transferring disks.
From: Leif Bloomquist on 24 Oct 2006 09:15
"Wolfgang Moser" <wnhp(a)d81.de.invalid> wrote in message
> * Booting pure DOS or Win98
> * Raising The Star Commander
No way. For 4000 disks you definitely need WarpCopy64. WarpCopy64 can make
a D64 of a disk in about 22 seconds, and it includes auto-naming of the
D64s. Much, much, faster than Star Commander or opencbm. More expensive
because you need an RR-Net, but time is money...
From: Wolfgang Moser on 24 Oct 2006 10:58
Leif Bloomquist schrieb:
> "Wolfgang Moser" <wnhp(a)d81.de.invalid> wrote in message
>> * Booting pure DOS or Win98
>> * Raising The Star Commander
> No way. For 4000 disks you definitely need WarpCopy64. WarpCopy64 can make
> a D64 of a disk in about 22 seconds, and it includes auto-naming of the
Oh yes, excuse me for not mentioning that
"a new star is born" utility in my little
> D64s. Much, much, faster than Star Commander or opencbm. More expensive
> because you need an RR-Net, but time is money...
How about reliability? From eight years of
testing The Star Commander I really know
that it is mature regarding error handling
and "emulation" of simple DOS errors. If
cabling and timing is Ok, there hardly are
some disks that let SC struggle.
Since I neither own a RR-NET nor do I have
my C64 system installed, I cannot tell
anything (comparable) to WarpCopy.
You know, there have been times with CD
collections full of corrupted images because
of errornous transfers (was this the High
Voltage CD collection ?). These then filled
well known archives like ftp.arnold.no and
caused trouble over trouble over trouble.
So I heavily vote for testing a transfer
system "to death".
Sometimes simple tests like transferring a
D64 to disk, reading it back into another
D64 and then comparing both D64s with
cmp -b src.d64 dst.d64
reveals potential trouble. But that's no
test for errornous or difficult to read
Oh, before I forget, there is some
signficant difference between Warpcopy and
SC or OpenCBM. While SC and OpenCBM are
from the transfer system "class" 1541-to-PC
(using old Funet.FI nomenclature), Warpcopy
can be considered into the class CBM-to-PC
like many other tools:
* FCopy-PC, an FCopy III style transfer
system (same speed and parallel cable)
with a PC as storage backend,
connected via joystick ports
* Marko M?kel?'s cbmlink, a multi-system,
multi-platform, multi-cable, multi-
everything transfer system
get more from Fairlight.to tools
The greatest speed, if it comes down to this
feature only, coudl be gained from directly
adopting to the 1541's disk controller chip.
Paul Gardner-Stephen (developer of 64NET)
once made a promising prototype named
Disk-Suck. But its requirements with _two_
free LPT ports and pure DOS because of the
hard to reach timing tolerancies may have
prevented further developing progress. Don't
know, if I ever did try out that prototype