Discussion:
64copy v4.2 (full version) released
(too old to reply)
Peter Schepers
2005-04-26 19:41:45 UTC
Permalink
Folks:

After a lengthy debugging cycle for 64COPY 4.2a1, I have decided to
release the full version of 64COPY. The biggest change is the complete
rewrite of the 6502 disassembler, along with a much improved and memory
conservant HELP system. You can download the latest version from:

http://ist.uwaterloo.ca/~schepers/download.html

---------------------------------------------------------------------------
Peter Schepers, | Author of : 64COPY, The C64 EMU file converter
Info Systems & Technology | http://ist.uwaterloo.ca/~schepers/personal.html
University of Waterloo, | My opinion is not likely that of the
Waterloo, Ontario, Canada | University, its employees, or anybody
(519) 888-4567 ext 2456 | on this planet. Too bad!
Glenn P.,
2005-04-30 09:58:49 UTC
Permalink
Post by Peter Schepers
After a lengthy debugging cycle for 64COPY 4.2a1, I have decided to
release the full version of 64COPY.
If I ever knew what "64Copy" is, I have since forgotten. For the benefit
of those in a similar position, could you describe this program for us
briefly? Thanks...

--
============================================================================
%%%%%%%%%%%%%%%% "Glenn P.," <C128UserDELETE-***@FVI.Net> %%%%%%%%%%%%%%%%%
============================================================================
_____
{~._.~} "My mother, she cooked me;
_( Y )_ My father, he ate me;
(:_~*~_:) My sister, little Ann Marie,
(_)-(_) She gathered up the bones of me,
========= And laid them 'neath the Juniper Tree --
========= Tweet, tweet! What a pretty bird am I!"

----------------------------------------------------------------------------
--From "The Juniper Tree", a delightfully fun tale of cruelty, child-murder,
and familial cannibalism written (c. 1815) by those two esteemed purveyors
of Family Entertainment, the brothers Jacob Ludwig & Wilhelm Carl Grimm.

:: Take Note Of The Spam Block On My E-Mail Address! ::
Stephan Schmid
2005-04-30 12:39:11 UTC
Permalink
Post by Glenn P.,
If I ever knew what "64Copy" is, I have since forgotten. For the benefit
of those in a similar position, could you describe this program for us
briefly? Thanks...
Something like Star Commander, only without the
transfer-to-real-floppydisks feature. It's similiar in use and looks and
feels quite like the Star Commander. But it has a load of other features
that the SC lacks, so it's a good addition to it.

Regards,
Stephan
Peter Schepers
2005-04-30 20:06:21 UTC
Permalink
Post by Stephan Schmid
Post by Glenn P.,
If I ever knew what "64Copy" is, I have since forgotten. For the benefit
of those in a similar position, could you describe this program for us
briefly? Thanks...
Something like Star Commander, only without the
transfer-to-real-floppydisks feature. It's similiar in use and looks and
feels quite like the Star Commander. But it has a load of other features
that the SC lacks, so it's a good addition to it.
I was going to reply this (Saturday) morning, but I've been experimenting
with a Linksys NAT router, and couldn't get Dreamweaver to SFTP to my site
to update the 64Copy home page. The 64copy home page ended up getting
nuked, so I decided to save the response until I could get this whole
mess fixed!

Along with Setphan's brief description, check out
http://ist.uwaterloo.ca/~schepers/personal.html for the low-down on what
64Copy does. 64Copy has been in development since 1994 (Star Commander and
64Copy were developed at almost the same time), so I'm a little surprised
you haven't heard of it.

I will try to add more about what 64Copy does to the site later.

---------------------------------------------------------------------------
Peter Schepers, | Author of : 64COPY, The C64 EMU file converter
Info Systems & Technology | http://ist.uwaterloo.ca/~schepers/personal.html
University of Waterloo, | My opinion is not likely that of the
Waterloo, Ontario, Canada | University, its employees, or anybody
(519) 888-4567 ext 2456 | on this planet. Too bad!
Alan
2005-05-01 05:22:22 UTC
Permalink
Post by Stephan Schmid
Post by Glenn P.,
If I ever knew what "64Copy" is, I have since forgotten. For the benefit
of those in a similar position, could you describe this program for us
briefly? Thanks...
Something like Star Commander, only without the
transfer-to-real-floppydisks feature. It's similiar in use and looks and
feels quite like the Star Commander. But it has a load of other features
that the SC lacks, so it's a good addition to it.
If 64Copy would work with GEOS disks it would be perfect. That, for me, is
the big advantage Star Commander has over 64Copy.
--
·.·Žš š)) -:|:-
ž.·Ž .·Žšš))
Alan
((žž.·Ž ..·Ž
-:|:- ((žž ·.·
Peter Schepers
2005-05-18 02:28:32 UTC
Permalink
Post by Alan
Post by Stephan Schmid
Post by Glenn P.,
If I ever knew what "64Copy" is, I have since forgotten. For the benefit
of those in a similar position, could you describe this program for us
briefly? Thanks...
Something like Star Commander, only without the
transfer-to-real-floppydisks feature. It's similiar in use and looks and
feels quite like the Star Commander. But it has a load of other features
that the SC lacks, so it's a good addition to it.
If 64Copy would work with GEOS disks it would be perfect. That, for me, is
the big advantage Star Commander has over 64Copy.
And if you would respond to my private email to you on this matter (sent
to (***@earthlink.net), maybe I would consider it a little more
seriously.

---------------------------------------------------------------------------
Peter Schepers, | Author of : 64COPY, The C64 EMU file converter
Info Systems & Technology | http://ist.uwaterloo.ca/~schepers/personal.html
University of Waterloo, | My opinion is not likely that of the
Waterloo, Ontario, Canada | University, its employees, or anybody
(519) 888-4567 ext 2456 | on this planet. Too bad!
Wendell III
2005-05-18 01:20:09 UTC
Permalink
In that case, why not merge the efforts into one mother tool?

-Wendell
Post by Stephan Schmid
Post by Glenn P.,
If I ever knew what "64Copy" is, I have since forgotten. For the benefit
of those in a similar position, could you describe this program for us
briefly? Thanks...
Something like Star Commander, only without the
transfer-to-real-floppydisks feature. It's similiar in use and looks
and feels quite like the Star Commander. But it has a load of other
features that the SC lacks, so it's a good addition to it.
Regards,
Stephan
--
ph: 773.880.1282 fx: 866.805.2744 icq: 12107743 aim: zephyrwendell
gg: 7116285 y!: zephyrwendell web: http://www.zephyrsyndicate.com
Peter Schepers
2005-05-18 02:25:57 UTC
Permalink
Post by Wendell III
Post by Stephan Schmid
Post by Glenn P.,
If I ever knew what "64Copy" is, I have since forgotten. For the benefit
of those in a similar position, could you describe this program for us
briefly? Thanks...
Something like Star Commander, only without the
transfer-to-real-floppydisks feature. It's similiar in use and looks
and feels quite like the Star Commander. But it has a load of other
features that the SC lacks, so it's a good addition to it.
In that case, why not merge the efforts into one mother tool?
Because.

---------------------------------------------------------------------------
Peter Schepers, | Author of : 64COPY, The C64 EMU file converter
Info Systems & Technology | http://ist.uwaterloo.ca/~schepers/personal.html
University of Waterloo, | My opinion is not likely that of the
Waterloo, Ontario, Canada | University, its employees, or anybody
(519) 888-4567 ext 2456 | on this planet. Too bad!
Joe Forster/STA
2005-05-18 14:54:26 UTC
Permalink
Hi Wendell,
Post by Wendell III
In that case, why not merge the efforts into one mother tool?
Two completely different programming languages, authors, coding styles.
And both have been started more than a decade ago, never meant to become
part of a multi-author project. (And the 64COPY source is not public yet.
If I may make a guess, it's because it's just the same hard-to-read-and-
understand source as that of the Commander, not really meant to ever be
published... 8^) )

Ever thought why Linux and Windows has never been merged, to get a stable
_and_ "nice" (errr, Mac users should turn their faces somewhere else!)
operating system...? Never mind, just kidding! ;-)

Joe
--
KOVÁCS Balázs alias Joe Forster/STA ***@c64.org; http://sta.c64.org
Don't E-mail spam, HTML or uncompressed files! More contacts on homepage
Peter Schepers
2005-05-20 11:07:17 UTC
Permalink
Post by Joe Forster/STA
Hi Wendell,
Post by Wendell III
In that case, why not merge the efforts into one mother tool?
Two completely different programming languages, authors, coding styles.
And both have been started more than a decade ago, never meant to become
part of a multi-author project.
Joe codes in Pascal, I work in Watcom C. Joe has training in programming,
I am self taught. Both sources couldn't be more different. Joe's design
paradigm and mandate were different from mine from the start. Joe lives in
Hungary, I'm in Canada.

Both projects started in ~1993-1994, and Joe and myself were already
communicating back then about features, program direction, etc. Both tools
were written for DOS for various reasons, for me because it provided the
best compatibility across many OS's of the day (Windows 3.1, OS/2, DOS).
OS's have changed, emulators now exist on many more platforms, and this
now limits the usefulness of the DOS-based tools. For someone like
Silverdr to criticize their usefulness now without knowing how and why
they were developed is silly.
Post by Joe Forster/STA
(And the 64COPY source is not public yet.
If I may make a guess, it's because it's just the same hard-to-read-and-
understand source as that of the Commander, not really meant to ever be
published... 8^) )
Oh, is it ever! The only code that I am really proud of is the GCR
conversion and the Disassembler rewrite. They are the newest and best
designed, actually hashed out on paper before ever being coded.

The FAQ on my website (new as of yesterday) describes why I'm not
releasing the source code.

---------------------------------------------------------------------------
Peter Schepers, | Author of : 64COPY, The C64 EMU file converter
Info Systems & Technology | http://ist.uwaterloo.ca/~schepers/personal.html
University of Waterloo, | My opinion is not likely that of the
Waterloo, Ontario, Canada | University, its employees, or anybody
(519) 888-4567 ext 2456 | on this planet. Too bad!
silverdr
2005-05-20 11:38:43 UTC
Permalink
Peter Schepers wrote:

[...]
Post by Peter Schepers
now limits the usefulness of the DOS-based tools. For someone like
Silverdr to criticize their usefulness now without knowing how and why
they were developed is silly.
I see that I really failed to make you understand what I meant :-( or
you just didn't read what I wrote with willingness to understand :-(

Regards,

silly silverdr
White Flame (aka David Holz)
2005-05-21 09:37:07 UTC
Permalink
Post by Peter Schepers
Both projects started in ~1993-1994, and Joe and myself were already
communicating back then about features, program direction, etc. Both tools
were written for DOS for various reasons, for me because it provided the
best compatibility across many OS's of the day (Windows 3.1, OS/2, DOS).
OS's have changed, emulators now exist on many more platforms, and this
now limits the usefulness of the DOS-based tools.
WinXP 64bit apparently does away with the 16-bit DOS compatibility layer.
Has anybody tested 64copy with that to see if it still works?
--
White Flame (aka David Holz)
http://www.white-flame.com/
(spamblock in effect)
Joe Forster/STA
2005-05-17 12:35:53 UTC
Permalink
Hi Glenn,
Post by Glenn P.,
Post by Peter Schepers
After a lengthy debugging cycle for 64COPY 4.2a1, I have decided to
release the full version of 64COPY.
If I ever knew what "64Copy" is, I have since forgotten. For the benefit
of those in a similar position, could you describe this program for us
briefly?
64COPY is a DOS shell, a Norton-Commander clone, with Commodore-related
extra features. While The Star Commander specializes in accessing Commodore
drives from the PC, 64COPY's greatest features are rather related to
processing Commodore files on the PC: directory editor, BASIC detokenizer,
interactive disassembler. Its newest release is a first in supporting the
".g64" GCR-encoded disk images. If there's something missing from The Star
Commander, you should try 64COPY first, before searching for a stand-alone
utility for that particular purpose on the Net... ;-) Bye,

Joe
--
KOVÁCS Balázs alias Joe Forster/STA ***@c64.org; http://sta.c64.org
Don't E-mail spam, HTML or uncompressed files! More contacts on homepage
Peter Schepers
2005-05-18 02:34:08 UTC
Permalink
Post by Joe Forster/STA
Hi Glenn,
Post by Glenn P.,
Post by Peter Schepers
After a lengthy debugging cycle for 64COPY 4.2a1, I have decided to
release the full version of 64COPY.
If I ever knew what "64Copy" is, I have since forgotten. For the benefit
of those in a similar position, could you describe this program for us
briefly?
64COPY is a DOS shell, a Norton-Commander clone, with Commodore-related
extra features. While The Star Commander specializes in accessing Commodore
drives from the PC, 64COPY's greatest features are rather related to
processing Commodore files on the PC: directory editor, BASIC detokenizer,
interactive disassembler. Its newest release is a first in supporting the
".g64" GCR-encoded disk images. If there's something missing from The Star
Commander, you should try 64COPY first, before searching for a stand-alone
utility for that particular purpose on the Net... ;-) Bye,
Thanks to Joe for this brief synopsis. Being the author, sometimes it is
difficult to sum up ones own work. I know I can't even explain it very
well to friends that ask about it.

I have been working very hard over the past few years improving 64Copy,
especially wrt the more difficult to work with formats like G64, but have
gotten no feedback. I've rewritten the entire 6502 disassembler to make it
likely the most powerful available on a DOS platform... no feedback. Does
64Copy work that well?

---------------------------------------------------------------------------
Peter Schepers, | Author of : 64COPY, The C64 EMU file converter
Info Systems & Technology | http://ist.uwaterloo.ca/~schepers/personal.html
University of Waterloo, | My opinion is not likely that of the
Waterloo, Ontario, Canada | University, its employees, or anybody
(519) 888-4567 ext 2456 | on this planet. Too bad!
Sam Gillett
2005-05-18 03:41:09 UTC
Permalink
"Peter Schepers" wrote ...
Post by Peter Schepers
I have been working very hard over the past few years improving 64Copy,
especially wrt the more difficult to work with formats like G64, but have
gotten no feedback. I've rewritten the entire 6502 disassembler to make it
likely the most powerful available on a DOS platform... no feedback. Does
64Copy work that well?
I have not used 64Copy personally, however... I have noticed that _several_
people in this group have posted their praise of 64Copy, and recommended it
highly to others. Based on that, I would say that it is obvious to a neutral
bystander that 64Copy does indeed work that well.

Keep up the good work!
--
Best regards,

Sam Gillett

Change is inevitable,
except from vending machines!
silverdr
2005-05-19 14:25:10 UTC
Permalink
Peter Schepers wrote:

[...]
Post by Peter Schepers
I have been working very hard over the past few years improving 64Copy,
especially wrt the more difficult to work with formats like G64, but have
gotten no feedback. I've rewritten the entire 6502 disassembler to make it
likely the most powerful available on a DOS platform... no feedback. Does
64Copy work that well?
It is probably partly due to the fact that booting DOS or something
similar is a very cumbersome task for many people. I eventually managed
to boot an environment, in which I could run both SC and 64Copy but I
immediately lost all my regular comfort and connectivity and, and...
Thus, even if it worked, it wasn't really usable when compared to my
current setup where I can do many things in parallel: check the info
from the net, analyse code, develop, access my cvs repositories, test on
both emulator and the real h/w very quickly due to things like
cbm4linux, c2n232 and some others...
Peter Schepers
2005-05-19 15:42:16 UTC
Permalink
Post by silverdr
Post by Peter Schepers
I have been working very hard over the past few years improving 64Copy,
especially wrt the more difficult to work with formats like G64, but have
gotten no feedback. I've rewritten the entire 6502 disassembler to make it
likely the most powerful available on a DOS platform... no feedback. Does
64Copy work that well?
It is probably partly due to the fact that booting DOS or something
similar is a very cumbersome task for many people.
Since 64Copy runs perfectly from a Windows 2000/XP/2003 DOS vdm, and does
not require booting to a native DOS environment, I find this reasoning
very questionable. Is this a view that people have about DOS tools in
general, or simply a lack of knowledge about the capabilities of the DOS
vdm?
Post by silverdr
I eventually managed
to boot an environment, in which I could run both SC and 64Copy but I
immediately lost all my regular comfort and connectivity and, and...
Thus, even if it worked, it wasn't really usable when compared to my
current setup where I can do many things in parallel: check the info
from the net, analyse code, develop, access my cvs repositories, test on
both emulator and the real h/w very quickly due to things like
cbm4linux, c2n232 and some others...
Only necessary for Star Commander due to timing considerations for drive
communications, so don't lump the two programs together. Do your
conversion, and come back to your everyday environment for the rest.
64Copy will work everywhere.

---------------------------------------------------------------------------
Peter Schepers, | Author of : 64COPY, The C64 EMU file converter
Info Systems & Technology | http://ist.uwaterloo.ca/~schepers/personal.html
University of Waterloo, | My opinion is not likely that of the
Waterloo, Ontario, Canada | University, its employees, or anybody
(519) 888-4567 ext 2456 | on this planet. Too bad!
Joe Forster/STA
2005-05-19 16:26:13 UTC
Permalink
Hi guys,
Post by Peter Schepers
Post by silverdr
It is probably partly due to the fact that booting DOS or something
similar is a very cumbersome task for many people.
Since 64Copy runs perfectly from a Windows 2000/XP/2003 DOS vdm, and does
not require booting to a native DOS environment
As for the Commander, launch it with the "/nolpt" command line option and
there you go without any problems under any Windows but without the ability
to access Commodore drives, of course... Bye,

Joe
--
KOVÁCS Balázs alias Joe Forster/STA ***@c64.org; http://sta.c64.org
Don't E-mail spam, HTML or uncompressed files! More contacts on homepage
silverdr
2005-05-19 22:34:30 UTC
Permalink
Post by Peter Schepers
Post by silverdr
Post by Peter Schepers
I have been working very hard over the past few years improving 64Copy,
especially wrt the more difficult to work with formats like G64, but have
gotten no feedback. I've rewritten the entire 6502 disassembler to make it
likely the most powerful available on a DOS platform... no feedback. Does
64Copy work that well?
It is probably partly due to the fact that booting DOS or something
similar is a very cumbersome task for many people.
Since 64Copy runs perfectly from a Windows 2000/XP/2003 DOS vdm, and does
not require booting to a native DOS environment, I find this reasoning
very questionable. Is this a view that people have about DOS tools in
general, or simply a lack of knowledge about the capabilities of the DOS
vdm?
Possibly a well-tuned Windows setup would give good comfort with
connectivity and all the modern devtools but even then running a crucial
app in DOS env is just not of today's standards. There is possibly many
good CP/M or CP/M86 apps out there which don't get used anymore for
similar reasons. It's not about your app being bad or something. It's
just that IMHO both you and Joe severely hinder your flagships'
usability by sticking to the obsolete (almost from day one, BTW)
operating environment and not developing it further, towards
cross-platform portability.
Post by Peter Schepers
Post by silverdr
I eventually managed
to boot an environment, in which I could run both SC and 64Copy but I
immediately lost all my regular comfort and connectivity and, and...
Thus, even if it worked, it wasn't really usable when compared to my
current setup where I can do many things in parallel: check the info
from the net, analyse code, develop, access my cvs repositories, test on
both emulator and the real h/w very quickly due to things like
cbm4linux, c2n232 and some others...
Only necessary for Star Commander due to timing considerations for drive
communications, so don't lump the two programs together.
Necessary for both. Either native or at least emulated DOS environment
(Star Commander can be run in the DOS vdm too).
Post by Peter Schepers
Do your
conversion, and come back to your everyday environment for the rest.
64Copy will work everywhere.
It doesn't work natively on any of my machines here with the exception
of one x86 box, which I have to either boot into DOS or run a DOSbox or
DOSemu on it before I can start any of BOTH of the above tools. Please
don't get me wrong. I very much appreciate the work you did. I
especially went through a very tedious (in my case) process of preparing
a bootable DOS environment only to be able to run 64Copy AND Star
Commander - just in case. But I can't really make a daily use of any of
those. Alright - I might be the very single person on this group who
doesn't run neither DOS nor Windows for daily computer work. I might be
the very uncommon exception so I can't say it for all but I only say
what I believe might be the case/reason you get so little feedback. It
is the reason in my (even if very exceptional) case.
Cameron Kaiser
2005-05-20 03:17:02 UTC
Permalink
Post by silverdr
Alright - I might be the very single person on this group who
doesn't run neither DOS nor Windows for daily computer work.
You aren't, of course.

--
Cameron Kaiser * ***@floodgap.com * posting with a Commodore 128
personal page: http://www.armory.com/%7Espectre/
** Computer Workshops: games, productivity software and more for C64/128! **
** http://www.armory.com/%7Espectre/cwi/ **
silverdr
2005-05-20 09:27:32 UTC
Permalink
Post by Cameron Kaiser
Post by silverdr
Alright - I might be the very single person on this group who
doesn't run neither DOS nor Windows for daily computer work.
You aren't, of course.
Sorry Cameron! Of course I didn't forget you and I knew you run
something else but didn't know that you don't have Windows next to it... ;-)
Jurgen Haan
2005-05-20 12:13:24 UTC
Permalink
Post by Cameron Kaiser
Post by silverdr
Alright - I might be the very single person on this group who
doesn't run neither DOS nor Windows for daily computer work.
You aren't, of course.
--
Dos? Windows?

Huh? As well as at the company where I work as the place where I
(occasionaly) live I don't use any windows/dos oriented machines.
Only Un*x based. (except for the machine that runs World of Warcraft ;P
I might aswell put wow in startup there)

But I don't know if it works, but perhaps you can try win4lin or wine
for running the app. As far as I know, the can use the LPT. (and they
both have a 16bit dos api). Wasn't dosbox supposed to have the ability
to communicate with the LPT?

Worst case scenario: vmware

I myself use an old 486 laptop for my 1541 <-> PC transfers, 486 equiped
with dos /w tcp, runs with no problems. For me that's the best solution,
get an old pc compatible device somewhere and install dos with a tcp stack.
1541 -> laptop -ftp> Linux workstation.

-R-
Michael Klein
2005-05-20 12:32:13 UTC
Permalink
Post by Jurgen Haan
Dos? Windows?
Huh? As well as at the company where I work as the place where I
(occasionaly) live I don't use any windows/dos oriented machines.
Only Un*x based.
I wish I could say that as well ;-) Have to use a W2K problem at work,
although I spent 99% of my time with cygwin's XFree86 in fullscreen
mode.
Post by Jurgen Haan
But I don't know if it works, but perhaps you can try win4lin or wine
for running the app. As far as I know, the can use the LPT. (and they
both have a 16bit dos api). Wasn't dosbox supposed to have the ability
to communicate with the LPT?
Worst case scenario: vmware
I myself use an old 486 laptop for my 1541 <-> PC transfers, 486 equiped
with dos /w tcp, runs with no problems. For me that's the best solution,
get an old pc compatible device somewhere and install dos with a tcp stack.
1541 -> laptop -ftp> Linux workstation.
Any particular reason why you don't use cbm4linux?

<plug>
http://www.lb.shuttle.de/puffin/cbm4linux/
</plug>

1541->Linux workstation ;-)
--
Michael

Linux skua 2.6.8-skua #1 Wed Nov 24 18:28:20 CET 2004 i686 GNU/Linux
Jurgen Haan
2005-05-20 13:37:42 UTC
Permalink
Post by Michael Klein
Any particular reason why you don't use cbm4linux?
Yeah... Broken LPT :D

-R-
Lars Haugseth
2005-05-20 14:45:07 UTC
Permalink
* Jurgen Haan <***@fake.dom> wrote:
|
| Michael Klein wrote:
| > Any particular reason why you don't use cbm4linux?
| >
|
| Yeah... Broken LPT :D

Any IEC <-> USB cable/drivers/software projects going on?
--
Lars Haugseth
MagerValp
2005-05-21 07:13:01 UTC
Permalink
LH> Any IEC <-> USB cable/drivers/software projects going on?

There's Jim Brain's VIP, which would work with a USB RS-232 port.
--
___ . . . . . + . . o
_|___|_ + . + . + . Per Olofsson, arkadspelare
o-o . . . o + ***@cling.gu.se
- + + . http://www.cling.gu.se/~cl3polof/
Peter Schepers
2005-05-20 10:52:42 UTC
Permalink
Post by silverdr
Post by Peter Schepers
Since 64Copy runs perfectly from a Windows 2000/XP/2003 DOS vdm, and does
not require booting to a native DOS environment, I find this reasoning
very questionable. Is this a view that people have about DOS tools in
general, or simply a lack of knowledge about the capabilities of the DOS
vdm?
Possibly a well-tuned Windows setup would give good comfort with
connectivity and all the modern devtools but even then running a crucial
app in DOS env is just not of today's standards.
Your opinion. There are those here who don't run Windows (yes Cameron,
that includes you) but instead have Mac OSX or some *nix flavor, etc. I
can't control that. 64COPY only uses the typical INT calls (no DOS
extenders) so if DOSEMU is available but it doesn't work that's out of my
control and complain to the authors of DOSEMU..
Post by silverdr
It's not about your app being bad or something. It's
just that IMHO both you and Joe severely hinder your flagships'
usability by sticking to the obsolete (almost from day one, BTW)
operating environment and not developing it further, towards
cross-platform portability.
Then write your own app that does what Joes and mine does and that solves
all your problems. We wrote ours when the emu scene was fresh, and Windows
3.1 was becoming tha OS of choice. I _hated_ Windows then and refused to
run it, choosing at the time to go with OS/2.

I designed 64COPY as a low-level hard disk recovery tool which required
only DOS to function and that mandate hasn't changed. It's my tool and I
still use it that way. While a Windows version would be nice, I do not
have the time to learn C++, nor the Windows API, nor the time to convert
all the source code.
Post by silverdr
Post by Peter Schepers
Post by silverdr
I eventually managed
to boot an environment, in which I could run both SC and 64Copy but I
immediately lost all my regular comfort and connectivity and, and...
Thus, even if it worked, it wasn't really usable when compared to my
current setup where I can do many things in parallel: check the info
from the net, analyse code, develop, access my cvs repositories, test on
both emulator and the real h/w very quickly due to things like
cbm4linux, c2n232 and some others...
Only necessary for Star Commander due to timing considerations for drive
communications, so don't lump the two programs together.
Necessary for both. Either native or at least emulated DOS environment
(Star Commander can be run in the DOS vdm too).
Necessary for you, as I did state that 64COPY works from the Windows DOS
VDM, and real DOS. Not necessary for those running some Windows platform.
If you choose to use something else that requires DOSEMU, then you're on
your own. I can't fix that.

Yes, Star Commander can run from a VMD, as Joe stated how, but since Star
Commanders forte is drive communications running it from a DOS VDM hardly
seems very useful.
Post by silverdr
Post by Peter Schepers
Do your
conversion, and come back to your everyday environment for the rest.
64Copy will work everywhere.
It doesn't work natively on any of my machines here with the exception
of one x86 box, which I have to either boot into DOS or run a DOSbox or
DOSemu on it before I can start any of BOTH of the above tools. Please
don't get me wrong. I very much appreciate the work you did. I
especially went through a very tedious (in my case) process of preparing
a bootable DOS environment only to be able to run 64Copy AND Star
Commander - just in case. But I can't really make a daily use of any of
those. Alright - I might be the very single person on this group who
doesn't run neither DOS nor Windows for daily computer work. I might be
the very uncommon exception so I can't say it for all but I only say
what I believe might be the case/reason you get so little feedback. It
is the reason in my (even if very exceptional) case.
You haven't stated what OS you use, but it appears to be some type of *NIX
(MAC OS? or Linux). My first parahraph stated compatibility with Windows
VDM and real DOS. Outside of that I have little to no control to make it
work.

Something that really bothers me about this posting... Silverdr, you never
bothered to take the time send me any private email outlining this
problem, and what happens when you try to run 64COPY. Instead you chose to
come out and air your laundry here... bad form.

I have included troubleshooting code into 64COPY to help me track down
bugs by logging where I am in the code as things happen. If 64COPY works
even partially in DOSEMU, there's a possibility something can be found
when running it in trace mode to see where it stop.

Something else... I never said that 64COPY works "natively", I said it
worked perfectly in a Windows DOS VDM environment. Native would be a real
Windows app, which it is not. You keep throwing the "native" term around
incorrectly.

---------------------------------------------------------------------------
Peter Schepers, | Author of : 64COPY, The C64 EMU file converter
Info Systems & Technology | http://ist.uwaterloo.ca/~schepers/personal.html
University of Waterloo, | My opinion is not likely that of the
Waterloo, Ontario, Canada | University, its employees, or anybody
(519) 888-4567 ext 2456 | on this planet. Too bad!
silverdr
2005-05-20 12:39:07 UTC
Permalink
Post by Peter Schepers
You haven't stated what OS you use, but it appears to be some type of
*NIX (MAC OS? or Linux).
A good couple of. Mostly unixalikes, including but not limiting to
GNU/Linux and OS X
Post by Peter Schepers
My first parahraph stated compatibility with Windows VDM and real
DOS. Outside of that I have little to no control to make it work.
And I only wanted to point your attention to the fact that running even
best routines inside a limiting environment becomes limiting factor for
the whole program, no matter how brillliant might it be. It is you who
have the control to either make it work outside of DOSbox or not.
Post by Peter Schepers
Something that really bothers me about this posting... Silverdr, you
never bothered to take the time send me any private email
Except the one that I wrote to you asking about the possibilities of
opening the program up so as to make open ports possible. AFAIR in
response I received a clear statement that your code isn't really meant
for public (or something very similar in meaning).
Post by Peter Schepers
outlining this problem, and what happens when you try to run 64COPY.
It works in its limiting DOS cage. And the reason I once wrote to you
was exactly because I saw potential in your program, which could be much
better utilised once freed from the DOS limits.
Post by Peter Schepers
Instead you chose to come out and air your laundry here... bad form.
I though that it was you who was wondering about little feedback you
receive and I thought I gave you one reason to think about.

I really start to believe that my expression abilities in English are
highly incapacitated :-(

Did everybody receive it in the same way (that I "aired my laundry" here)?

[...]
Post by Peter Schepers
Something else... I never said that 64COPY works "natively", I said
it worked perfectly in a Windows DOS VDM environment.
Of course it doesn't work "natively". And that's the limiting factor I
wrote about. It's a great and potent engine but it can only be run in a
Citroen 2CV and many people don't want to drive 2CV even with the best
engine around (while some do - and say it's the most beautiful and
comfortable car ever, yet their number is very small ;-) because the
rest is too limiting.
Post by Peter Schepers
Native would be a real Windows app, which it is not.
Even better it would be a real cross-platform app (capable of being run
natively on all modern platforms - including Windows), which it is also not.
Post by Peter Schepers
You keep throwing the "native" term around incorrectly.
I tend to disagree and I suggest EOT. Your app, your code, your right to
listen to anyone's opinions/suggestions or not, as well as to decide if
you let your app die along with DOS or you give it a second chance.

Regards from my side.
Peter Schepers
2005-05-20 19:40:27 UTC
Permalink
Post by silverdr
Post by Peter Schepers
My first parahraph stated compatibility with Windows VDM and real
DOS. Outside of that I have little to no control to make it work.
And I only wanted to point your attention to the fact that running even
best routines inside a limiting environment becomes limiting factor for
the whole program, no matter how brillliant might it be. It is you who
have the control to either make it work outside of DOSbox or not.
I do understand what you are asking... I don't think you understand the
scope of what someone would be getting themselves into. Let me
summarize...

Doing a simple "wc -l" on my source directories, I find to my astonishment
that I have ~2.5 million lines in my .C and .H files. Sheeeit, thats a lot
of coding! I've never stopped developing this program since I started, and
I've had to make this much code fit into 640K... quite a feat so far.
Believe me, I would _love_ to take parts of this to Windows or
name-your-OS-here, especially the Disassembler which by itself totals over
500,000 lines (not including the shared windowing code, several hundred
thousand more).

Now, say I decide to release this monstrosity. What happens then? Even if
someone else decided to convert part of it, I would still be developing
and improving under DOS, leaving the "converted" version behind each time
I release. The only way things will really change is if 64COPY because
abandonware, and I walked completely away. I do not have the time or
inclination to learn how to program for other OS's, and I also have no
intention to walk away from it. I still have big updates planned. See my
dilemma?

Think about Star Commander... Joe released the source code some time ago
(read a few years now) and has _anything_ happened to it as far as
porting?

Question: how would you approach making my program multi-platform, while
keeping up with my changes and additions, and not inconviencing me in my
development?
Post by silverdr
Post by Peter Schepers
Something that really bothers me about this posting... Silverdr, you
never bothered to take the time send me any private email
Except the one that I wrote to you asking about the possibilities of
opening the program up so as to make open ports possible. AFAIR in
response I received a clear statement that your code isn't really meant
for public (or something very similar in meaning).
And that was all you asked, and that was how I responded. You didn't say
what problems you were having getting it to run, even in a DOSEMU
environment. If it runs, then there's nothing wrong.

Unless you can answer the question from above, then there's not much else
to talk about.
Post by silverdr
Post by Peter Schepers
Something else... I never said that 64COPY works "natively", I said
it worked perfectly in a Windows DOS VDM environment.
Of course it doesn't work "natively". And that's the limiting factor I
wrote about. It's a great and potent engine but it can only be run in a
Citroen 2CV and many people don't want to drive 2CV even with the best
engine around (while some do - and say it's the most beautiful and
comfortable car ever, yet their number is very small ;-) because the
rest is too limiting.
It would seem that you give DOS too little credit for what it can do,
because it is not GUI based. I still give it lots of credit. Besides, I
don't know what a Citroen is.
Post by silverdr
Even better it would be a real cross-platform app (capable of being run
natively on all modern platforms - including Windows), which it is also not.
Once again, how?
Post by silverdr
I tend to disagree and I suggest EOT. Your app, your code, your right to
listen to anyone's opinions/suggestions or not, as well as to decide if
you let your app die along with DOS or you give it a second chance.
Keep in mind that Microsoft was intending to remove the DOS VDM capability
(along with Win16, POSIX, OS/2, etc) from the next gen of Windows
(Longhorn). This, from what I read and heard recently, was reversed and
has been put back. However, if this did happen, I would be stuck as there
would be no more development under DOS. At that point I would look to
either learning to code under Windows, or release the source and walking
away. The first option would be my first pick.

---------------------------------------------------------------------------
Peter Schepers, | Author of : 64COPY, The C64 EMU file converter
Info Systems & Technology | http://ist.uwaterloo.ca/~schepers/personal.html
University of Waterloo, | My opinion is not likely that of the
Waterloo, Ontario, Canada | University, its employees, or anybody
(519) 888-4567 ext 2456 | on this planet. Too bad!
silverdr
2005-05-21 09:09:46 UTC
Permalink
OK. Peter, I think I already wrote too much on the matter. I originally
only wanted to point your attention to the possibility that the lack of
feedback might come from the fact that there is an increasing number of
people who find dealing with DOS too cumbersome and that might be the
reason why your app doesn't get enough deserved attention. I understand
your dilemma as you wrote and the explanations you gave tell a lot. If
you yourself have no wish to move towards any cross-platform environment
with your development then of course I understand that pure source
release would have only limited impact on the possible further
development. Of course someone could use some interesting parts here and
there but it would require you to drive and coordinate things in order
to push it forward. The same I believe applies to Joe's app. I may
believe that some algorithms could have been used or analysed by
somebody, which is also good, but this of course doesn't drive the
further development.

Good luck and please excuse me if I unintentionally wrote something harsh.

silverdr
silverdr
2005-05-21 09:15:56 UTC
Permalink
Peter Schepers wrote:

[...]
Post by Peter Schepers
Keep in mind that Microsoft was intending to remove the DOS VDM capability
(along with Win16, POSIX, OS/2, etc) from the next gen of Windows
(Longhorn). This, from what I read and heard recently, was reversed and
has been put back. However, if this did happen, I would be stuck as there
would be no more development under DOS. At that point I would look to
either learning to code under Windows, or release the source and walking
away. The first option would be my first pick.
P.S. Have you thought about e.g. (n)curses? Could it be close enough to
the text based DOS environment that most parts of your app wouldn't need
major rewriting, except the presentation, while immediately giving the
chance to run it on all modern platforms, including Windows?

Just a thought...
Joe Forster/STA
2005-05-20 14:46:34 UTC
Permalink
Hi silverdr,

If you wrote some application and someone started criticizing it the way
you're criticizing ours, you'd understand how sad it makes us...

Back in 1993-1994, when we started our projects, there wasn't even Windows
(in a useful and widely-spread form). There was only DOS. (I'm speaking
about home PC's, not the super-PC's of those times, or Amigas, Macintoshes
or mainframes.) I studied Modula-2 at the university, which is a fucked up
branch of Pascal; Peter, as he said, didn't study programming. :-) It was
pretty obvious to start coding a DOS software; I did in Pascal, Peter did
it in C. There was nothing wrong about it.

You _are_ definitely right that, today, DOS software is becoming obsolete.
However, I never wanted to "waste" my time with porting the Commander into
a multi-platform tool; Peter is at a great advantage at this point, as C
inherently is more portable than Pascal. Also, perhaps, someone - more
comfortable with non-DOS environments - could've/should've volunteered to
start porting the code while we continue adding functionality (!)...

As a result, we have two DOS applications that run fine in a Windows DOS
shell or in Linux dosemu. I'd like to stress that obsoleteness does not
mean uselessness! Also, it really makes me sad that people prefer the
completely unintuitive _and_ hard-to-use graphical Windows Explorer rather
than the well-designed, intuitive user interface of _any_ Commander-clone.
(And, yes, I'm using a text-based Commander-clone, called FAR Manager, in
Windows... My family members and colleagues haven't even opened the
necessary Windows windows to execute a task when I'm already done with FAR
Manager... They're/You're wasting their/your time, I'm not.)

And, perhaps hurting your feelings similarly as you hurt ours, let me ask
you: if you think a software from 1993-1994 is obsolete _now_, why do you
bother at all with _any_ software for a platform that became obsolete
already around 1993-1994?!

Joe
--
KOVÁCS Balázs alias Joe Forster/STA ***@c64.org; http://sta.c64.org
Don't E-mail spam, HTML or uncompressed files! More contacts on homepage
silverdr
2005-05-20 18:02:19 UTC
Permalink
Post by Joe Forster/STA
Hi silverdr,
If you wrote some application and someone started criticizing it the way
you're criticizing ours, you'd understand how sad it makes us...
I sincerely apologize if I made you sad. I truly meant not to. And to be
completely frank - it is quite a paradox. I wrote what I wrote actually
not because I wanted to contemptuously criticise or humiliate your work.
What is so paradoxical, is the fact that it is quite the contrary: I
value both of your apps very high. So high as to make me dedicate low
capacity harddrive (so that DOS can still work on it), buy harddrive
racks, so that I can easily swap the drives, buy the DOS licence (just
in case as I have the machine in an office environment here and I had
limited success with FreeDOS) and spend quite a bit of time to make it
all work. The more paradoxical thing is that I even bothered to write
all that just because I cared to check the true potential and the amount
of work you needed to put into making the apps what they are today. And
I believe that it would be a great pity to let it pass away - yet my
intentions are perceived differently.
Post by Joe Forster/STA
Back in 1993-1994, when we started our projects, there wasn't even Windows
(in a useful and widely-spread form). There was only DOS. (I'm speaking
about home PC's, not the super-PC's of those times, or Amigas, Macintoshes
or mainframes.) I studied Modula-2 at the university, which is a fucked up
branch of Pascal; Peter, as he said, didn't study programming. :-) It was
pretty obvious to start coding a DOS software; I did in Pascal, Peter did
it in C. There was nothing wrong about it.
I agree.
Post by Joe Forster/STA
You _are_ definitely right that, today, DOS software is becoming obsolete.
However, I never wanted to "waste" my time with porting the Commander into
a multi-platform tool; Peter is at a great advantage at this point, as C
inherently is more portable than Pascal. Also, perhaps, someone - more
comfortable with non-DOS environments - could've/should've volunteered to
start porting the code while we continue adding functionality (!)...
But this is exactly what I am suggesting! Open it up. AFAIK you don't
claim any patents or trade secrets on SC. I guess the same applies to
Peter.
Post by Joe Forster/STA
As a result, we have two DOS applications that run fine in a Windows DOS
shell or in Linux dosemu. I'd like to stress that obsoleteness does not
mean uselessness!
And I perfectly agree! I wouldn't waste a single bit of my time to
discuss all this if they were useless. It just makes me somewhat sad
that they don't get more and more (even if relatively) use but rather
less and less. How long will it be until Microsoft drops the DOS vdms
from their future Windows? Speculations? Yes, but isn't that just possible?
Post by Joe Forster/STA
Also, it really makes me sad that people prefer the
completely unintuitive _and_ hard-to-use graphical Windows Explorer rather
than the well-designed, intuitive user interface of _any_ Commander-clone.
Well, here I am not exactly in line with you. While I also very much
agree that Windows Explorer is far from being highly efficient (the same
applies to many well-known filemanagers: Apple's Finder, KDE's
Konqueror, GNOME's Nautilus ...) I still don't find commander-style to
be the only and best choice. Anyway that's a completely different story.
Post by Joe Forster/STA
(And, yes, I'm using a text-based Commander-clone, called FAR Manager, in
Windows... My family members and colleagues haven't even opened the
necessary Windows windows to execute a task when I'm already done with FAR
Manager... They're/You're wasting their/your time, I'm not.)
I know many people who use commander-style filemanagers in Windows. The
most often I see "Total Commander" (I believe that's the name) and
there's nothing wrong with it. Their choice.
Post by Joe Forster/STA
And, perhaps hurting your feelings similarly as you hurt ours, let me ask
you: if you think a software from 1993-1994 is obsolete _now_, why do you
bother at all with _any_ software for a platform that became obsolete
already around 1993-1994?!
Once more I apologize if I unintentionally hurt yours and Peter's feelings.

As for your question: In the late eighties and early nineties I wrote
several apps. Some of them were found to be even good enough to bring me
a good money and make me proud that it was me who did it. Today I guess
almost nobody uses my Finaltape, MultiDrawer, LogoPainter etc... but if
today somebody said to me "develop it further or open it up becasue
otherwise your app won't survive long", I wouldn't feel hurt I guess. I
would rather be happy that someone still took time to check what it's
worth and found it interesting enough to care for its future. Where do
you believe would the Linux kernel be if Linus once said "I made it
first and it's mine, even if I don't make money on it. period."? And
more to answer you - I just don't know why I still "waste" my time to do
something for the 8bit CBMs from time to time, do you? Tell me if you
do, please ;-) But again: I didn't say your (and Peter's) software
is/was obsolete but only that it requires an obsolete environment to be
run, which limits its applicability and will limit it even more in the
future, effectively making the software obsolete _as a result_ ... If
you wish to give your babies a new life - set them free. I don't say
that someone will immediately start developing it further but at least
there is a chance. If you don't do it - you don't give it this chance.
While there is not much value left in my apps for the 8bit machines,
there is still very much left in yours. This can still be preserved and
extended if you either port it yourself or give a chance for others to
do it.

I can only hope that my intentions are clear with what I wrote above. In
any case, if there are two ways of understanding it and one of them is
making you believe I am being contemptuous or humiliating - I certainly
mean the other one ;-)

Regards.

silverdr
White Flame (aka David Holz)
2005-05-20 04:30:23 UTC
Permalink
Post by silverdr
It is probably partly due to the fact that booting DOS or something
similar is a very cumbersome task for many people. I eventually managed
to boot an environment, in which I could run both SC and 64Copy but I
immediately lost all my regular comfort and connectivity and, and...
um, I use 64copy all the time from DOS windows under Win2k. Works
perfectly. Although I do use c1541 (from VICE) to create .d64s scripted
from makefiles, I use 64copy for all other copying of files into/out from
.d64s and .d81s.
--
White Flame (aka David Holz)
http://www.white-flame.com/
(spamblock in effect)
silverdr
2005-05-20 09:35:31 UTC
Permalink
Post by White Flame (aka David Holz)
Post by silverdr
It is probably partly due to the fact that booting DOS or something
similar is a very cumbersome task for many people. I eventually managed
to boot an environment, in which I could run both SC and 64Copy but I
immediately lost all my regular comfort and connectivity and, and...
um, I use 64copy all the time from DOS windows under Win2k. Works
perfectly.
With Windows being your primary working environment, I guess?
Post by White Flame (aka David Holz)
Although I do use c1541 (from VICE) to create .d64s scripted
from makefiles,
I do the same, plus I write the files to the images with -write
Post by White Flame (aka David Holz)
I use 64copy for all other copying of files into/out from
.d64s and .d81s.
For that purpose I mostly use Power64. Drag'n drop operations as
provided by it are very convenient IMHO. What I am missing is a kind of
interactive disassembler, which would make the code analysis/reversing
more comfortable.
Peter Schepers
2005-05-20 10:54:42 UTC
Permalink
Post by silverdr
For that purpose I mostly use Power64. Drag'n drop operations as
provided by it are very convenient IMHO. What I am missing is a kind of
interactive disassembler, which would make the code analysis/reversing
more comfortable.
Then it really is too bad that 64COPY doesn't work for you, in your
environment, as the latest version has a very powerful interactive
disassembler.

---------------------------------------------------------------------------
Peter Schepers, | Author of : 64COPY, The C64 EMU file converter
Info Systems & Technology | http://ist.uwaterloo.ca/~schepers/personal.html
University of Waterloo, | My opinion is not likely that of the
Waterloo, Ontario, Canada | University, its employees, or anybody
(519) 888-4567 ext 2456 | on this planet. Too bad!
silverdr
2005-05-20 12:45:27 UTC
Permalink
Post by Peter Schepers
Post by silverdr
For that purpose I mostly use Power64. Drag'n drop operations as
provided by it are very convenient IMHO. What I am missing is a kind of
interactive disassembler, which would make the code analysis/reversing
more comfortable.
Then it really is too bad that 64COPY doesn't work for you, in your
environment, as the latest version has a very powerful interactive
disassembler.
That's exactly (beside some smaller functions) what made me write to
you. I know it's there. I even tested it with DOS bootable drive but I
can't use it comfortably in the long run.
White Flame (aka David Holz)
2005-05-17 23:18:41 UTC
Permalink
Post by Peter Schepers
After a lengthy debugging cycle for 64COPY 4.2a1, I have decided to
release the full version of 64COPY. The biggest change is the complete
rewrite of the 6502 disassembler, along with a much improved and memory
Did you ever think about adding support for .d2m images? I've got a .d2m
backup that I made that I'd like to grab some files off of. I know the CMD
filesystem has a couple more layers than .d64/d71/d81 and thus ups the
complexity some, but it'd be handy.
--
White Flame (aka David Holz)
http://www.white-flame.com/
(spamblock in effect)
Peter Schepers
2005-05-18 02:23:23 UTC
Permalink
Post by White Flame (aka David Holz)
Post by Peter Schepers
After a lengthy debugging cycle for 64COPY 4.2a1, I have decided to
release the full version of 64COPY. The biggest change is the complete
rewrite of the 6502 disassembler, along with a much improved and memory
Did you ever think about adding support for .d2m images? I've got a .d2m
backup that I made that I'd like to grab some files off of. I know the CMD
filesystem has a couple more layers than .d64/d71/d81 and thus ups the
complexity some, but it'd be handy.
It's partially implemented, but it is a very complex beast. I ran into
some problems (due to the way I coded things over the years) and had to
stop. I've been busy coding up other improvements, and don't really
consider the D2M format to be too critical.

In case you missed it, I _did_ include code/data separation into the
disassembler in the final 4.2 release.

---------------------------------------------------------------------------
Peter Schepers, | Author of : 64COPY, The C64 EMU file converter
Info Systems & Technology | http://ist.uwaterloo.ca/~schepers/personal.html
University of Waterloo, | My opinion is not likely that of the
Waterloo, Ontario, Canada | University, its employees, or anybody
(519) 888-4567 ext 6347 | on this planet. Too bad!
White Flame (aka David Holz)
2005-05-19 03:32:22 UTC
Permalink
Post by Peter Schepers
It's partially implemented, but it is a very complex beast. I ran into
some problems (due to the way I coded things over the years) and had to
stop. I've been busy coding up other improvements, and don't really
consider the D2M format to be too critical.
Yeah, I still have my 3.5" disk, but my FD2000 and other things are in
storage. Hopefully I can get the data off in one piece soon.
Post by Peter Schepers
In case you missed it, I _did_ include code/data separation into the
disassembler in the final 4.2 release.
heh, cool. I'll have to do some disasming when I get some time. :)
--
White Flame (aka David Holz)
http://www.white-flame.com/
(spamblock in effect)
Continue reading on narkive:
Loading...