Re: Digest for zoomfloppy-users@googlegroups.com - 5 updates in 1 topic

[John Saller]

Wow! Thanks! I will try it when I can, everything is in boxes now. I always had a problem with  --drive-type=15XX so used -d 
Have you tried  "cbmctrl command 8 N0:NAME,ID"  for format?

The only problem with opencbm I have is it doesn't support MSD drives. The parallel port is most needed but wont work with MSD.
Thanks

On Wed, Oct 15, 2025 at 6:42 PM <zoomflop...@googlegroups.com> wrote:

zoomflop...@googlegroups.com

Google Groups

Topic digest
View all topics

• Digest for zoomflop...@googlegroups.com - 1 update in 1 topic - 5 Updates

Digest for zoomflop...@googlegroups.com - 1 update in 1 topic

John Saller <bestde...@gmail.com>: Oct 15 09:05AM -0700 I never had any luck with imgcopy with a 1581! I use cbmcopy -w -d 1581 -fD 8 .test.d81 or Read a file called cbmfile from drive 8 and store its binary value into the file file.bin, automatically selecting the fastest transfer method cbmcopy -r -d 1581 8 cbmfile -o file.bin

John Saller <bestde...@gmail.com>: Oct 15 09:28AM -0700 I use 1581CP54 for full 1581 disk copies which is a pain but it is fast and accurate.

John Saller <bestde...@gmail.com>: Oct 15 09:30AM -0700 I never had any luck with imgcopy with a 1581! I use cbmcopy -w -d 1581 -fD 8 test.d81 or Read a file called cbmfile from drive 8 and store its binary value into the file file.bin, automatically selecting the fastest transfer method cbmcopy -r -d 1581 8 cbmfile -o file.bin

Dan Gahlinger <dgah...@gmail.com>: Oct 15 01:26PM -0400 well I have a reliable workaround, but it uses the greaseweazle rather than zoomfloppy so you'd need a greaseweazle (v4 or newer) and you'll need a PC 720k floppy drive and cable   the command I use is:   gw read --tracks "c=0-81:h=1" --retries 10 --revs 5 --format commodore.1581 3disk200.d81   the retries and revs give it the best possible chance to read data from the disk the "h=1" tells it to only read head 1, as it's a 720k disk not a 1.44MB if you try it without this, image creation will fail. this seems to be just how greaseweazle does it.   I'll give your cbmcopy commands a try as well, I'm also going to try imgcopy with a 1571 drive   I used to use imgcopy with 1541, 1571 and 1581 in the past, long ago, but don't know why 1541 and 1581 are failing now. I'm curious to see what happens whey I try with a 1571 drive these days   would be nice to figure out what's going on with it   and yeah, 1581CP54 is highly problematic, it's old DOS, so virtualbox, dosbox, QEMU, PC86, etc but then you have to configure all the USB passthrough stuff, which is a pain or an old DOS PC, which is equally problematic.     -- Greetings from somewhere in the space-time continuum,   Dan.

Dan Gahlinger <dgah...@gmail.com>: Oct 15 05:21PM -0400 I finally got zoomfloppy to work with a 1581 drive   John, try this out, here's the command I used:   imgcopy -v --no-warp -ts2 --drive-type=1581 8 testing.d81   still outstanding:   as of now, I can't find any way to create a D71 image with zoomfloppy I tested with a 1571 drive and I get this error message:   [Fatal] invalid drive or image type   it's the exact same error as with a 1541 drive this is using --drive-type=1541 or --drive-type=1571 even using that same command line from the 1581 and changing the drive type, same fatal error   so hopefully Spiro can give some guidance on what I'm doing wrong, etc   Dan.     -- Greetings from somewhere in the space-time continuum,   Dan.

Back to top

You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to zoomfloppy-use...@googlegroups.com.

[John Saller]

Have you tried to copy a double-sided disk from a 1571 drive 9 to image.d71, using serial1 transfer method and only reading the blocks which are marked as used in the BAM: d64copy-2-B--transfer=serial1 9 image.d71?

For blank .d71 I use vice.

[Dan Gahlinger]

MSD drives don't use parallel 

That's not a parallel port 

Yeah I know, it's confusing.

The standard zoomfloppy won't work either 

You need a zoomfloppy with the additional port option

I think it's IEEE-488 if memory serves

When you buy a zoomfloppy it's an extra add on option that's not selected by default 

You have to select it and add it.

I have two zoomfloppy 

One is standard 

And the other has the additional port

However there's an additional wrinkle to all this

Even with the correct port, I have no idea how you're actually supposed to use it

I'll test 1571 with -d and see what happens 

Greetings from somewhere in the space-time continuum,

Dan.

--
You received this message because you are subscribed to the Google Groups "ZoomFloppy Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zoomfloppy-use...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/zoomfloppy-users/CADe2EEs%3DXOTjXSb33PiCRSMNGN%3DerPWm13Jf%2BZs73ss0EXgGnw%40mail.gmail.com.

[Dan Gahlinger]

yeah, imgcopy with -d 1571 or -d 1541 gives me the same error:

[Fatal] invalid drive or image type

perhaps telling is that if you use -d=1571 or -d=1541 you get this error:

[Fatal] unknown drive type.
Try 'imgcopy' --help for more information.

I tried looking at the source code for imgcopy but I can't figure it out

[Dan Gahlinger]

getting closer to narrowing down the issue,
for some reason, when using 1541 or 1571 it sets the block_count to 0 which is clearly wrong:

imgcopy -vvvvvv -d 1571 8 random.d64
[Debug] transfer mode is 0
[Debug] decided to use transfer mode 1
[Debug] block count: 0

[Fatal] invalid drive or image type

[Dan Gahlinger]

For Spiro! I think I've found it, but I'm NOT a C coder, so I'm just going by what I've found
i traced the code back and it's all in opencbm/libimgcopy/imgcopy.c

line 389 specifically:
for(i = 1; i <= settings->max_tracks; i++)

imgcopy uses max_tracks as part of the calculation to set block_count
but max_tracks for 1541 and 1571 never appear to be set,
according to the code back at line 362 block, and specifically lines 382 and 383 you have:
case D64: /* FALL THROUGH */
case D71: /* FALL THROUGH */

And also, while D64_TRACKS and D71_TRACKS gets set (not directly which might be another issue)
none of the following ever appear to be set: D64_CAT_TRACK, D64_BAM_TRACK, D71_CAT_TRACK and D71_BAM_TRACK

thus the block_count remains at 0, and the program gives the fatal error
as near as I can tell anyhow.

[John Saller]

I have the  IEEE-488 option and the IEEE-488 cable. It doesn't work because the software looks for each drive programmed into the software and we can not get anyone to add MSD in.

I have an IEEE-488 card which works great on the c64 and c128 but it is easier to use vice which doesn't use Jiffydos either. Thank goodness fast serial works with the 1571 and 1581.

IEEE-488 is called a parallel interface because it is an 8-bit parallel bus designed to transfer data simultaneously across multiple lines. It is also widely known by its other names: GPIB (General-Purpose Interface Bus) and HP-IB (Hewlett-Packard Interface Bus). 

On Thu, Oct 16, 2025 at 6:42 PM <zoomflop...@googlegroups.com> wrote:

zoomflop...@googlegroups.com

Google Groups

Topic digest
View all topics

• Digest for zoomflop...@googlegroups.com - 5 updates in 1 topic - 5 Updates

Digest for zoomflop...@googlegroups.com - 5 updates in 1 topic

John Saller <bestde...@gmail.com>: Oct 16 08:08AM -0700

Wow! Thanks! I will try it when I can, everything is in boxes now. I always had a problem with --drive-type=15XX so used -d Have you tried "cbmctrl command 8 N0:NAME,ID" for format? The only problem with opencbm I have is it doesn't support MSD drives. The parallel port is most needed but wont work with MSD. Thanks

John Saller <bestde...@gmail.com>: Oct 16 08:29AM -0700

Have you tried to copy a double-sided disk from a 1571 drive 9 to image.d71, using serial1 transfer method and only reading the blocks which are marked as used in the BAM: d64copy-2-B--transfer=serial1 9 image.d71? For blank .d71 I use vice.

Dan Gahlinger <dgah...@gmail.com>: Oct 16 12:24PM -0400

MSD drives don't use parallel That's not a parallel port   Yeah I know, it's confusing.   The standard zoomfloppy won't work either You need a zoomfloppy with the additional port option I think it's IEEE-488 if memory serves   When you buy a zoomfloppy it's an extra add on option that's not selected by default You have to select it and add it.   I have two zoomfloppy One is standard And the other has the additional port   However there's an additional wrinkle to all this   Even with the correct port, I have no idea how you're actually supposed to use it   I'll test 1571 with -d and see what happens   Greetings from somewhere in the space-time continuum,   Dan.

Dan Gahlinger <dgah...@gmail.com>: Oct 16 01:00PM -0400

yeah, imgcopy with -d 1571 or -d 1541 gives me the same error:   [Fatal] invalid drive or image type   perhaps telling is that if you use -d=1571 or -d=1541 you get this error:   [Fatal] unknown drive type. Try 'imgcopy' --help for more information.   I tried looking at the source code for imgcopy but I can't figure it out

-- Greetings from somewhere in the space-time continuum,   Dan.

Dan Gahlinger <dgah...@gmail.com>: Oct 16 02:05PM -0400

getting closer to narrowing down the issue, for some reason, when using 1541 or 1571 it sets the block_count to 0 which is clearly wrong:   imgcopy -vvvvvv -d 1571 8 random.d64 [Debug] transfer mode is 0 [Debug] decided to use transfer mode 1 [Debug] block count: 0 [Fatal] invalid drive or image type

-- Greetings from somewhere in the space-time continuum,   Dan.

Back to top

[Dan Gahlinger]

yeah, for some reason I keep thinking it's SERIAL. augh

anyhow, if you ever happen to come across the M/L or macro source code for the MSD drive ROMS
please send me a link or email directly

I know it's off-topic, but we've been looking for those for a while
we have the ROMS, that's not the problem, but getting the code is what we're after

me personally I'm trying to see if it's possible to adapt a Fast Hack'em copier parameter for the MSD-2
to work with a ramboard or super card plus

but two problems: need that source code and need to figure out what the parameter is actually doing.
both very difficult problems.

And in the mean time, I'm going to keep trying to get D71 images to work with imgcopy
I used it in the past, so I'm not sure what happened.
now imgcopy won't even work with a 1571 at all, or 1541 either.

I found another block in the imgcopy.c code with "FALL THROUGH" instead of actual code.
but, and I'll keep emphasizing this: I'm NOT a coder, so I could be way off.
that code is in opencbm/libimgcopy/imgcopy.c around lines 300-400 there's two blocks of "FALL THROUGH"
for 1541 and 1571 drives.
the block count doesn't get calculated, but even before that it doesn't process the drive type properly.
I was bale to bludgeon the code enough to get it to spit out (paraphrasing): "(INFO) drive 8 (unknown)" which should show the drive type, but doesn't, for some reason.
of course my code tampering caused the block count to go to 2430 which is impossibly huge.
again, I have no idea what I'm doing with C code, so I backed out my changes and reverted to clean install.

Speaking of which: Spiro, there's a minor "bug" in dfu_bool.h you use "true" and "false" the compile fails.
this is a really easy fix, I changed "true" to "dfu_true" and "false" to "dfu_false" and compile worked.
again: I'm not a coder, do not use my suggestions directly unless they are verified.

--

You received this message because you are subscribed to the Google Groups "ZoomFloppy Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zoomfloppy-use...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/zoomfloppy-users/CADe2EEvxV4HtGtvzWHkdzAvxHRZU_SQpfQ8nz_xssiw9t29mXw%40mail.gmail.com.

[Spiro Trikaliotis]

Hello,

* On Fri, Oct 17, 2025 at 05:05:40AM -0400 Dan Gahlinger wrote:
> For Spiro! I think I've found it, but I'm NOT a C coder, so I'm just going by
> what I've found

I think I found your bug: You are using imgcopy in the first place. That
tool is extremely unreliable and buggy...

It should have never been included in any opencbm version.

Please, do not use imgcopy, but use d64copy instead (for 1541, 1570 and
1571 drives). For 1581, imgcopy does not work reliably, either.


Unfortunately, the author of imgcopy lost interest, so it is there in a
half-working, but mostly half-non-working state now.

Regards,
Spiro

--
Spiro R. Trikaliotis
https://spiro.trikaliotis.net/

[Dan Gahlinger]

Spiro

d64copy can't create d71 images 

At least according to the program

I kind of suspected  this was the case

The imgcopy source code is a convoluted mess - to me as a non coder

It doesn't appear to properly parse the 1571 option

I got imgcopy working with 1581 drive making d81 images reliably,  seems very stable but you have to use extra command line options 

I tried to go back to older version but tje code seems the same 

My only concern now is d71 image creation specifically  

Greetings from somewhere in the space-time continuum,

Dan.

--
You received this message because you are subscribed to the Google Groups "ZoomFloppy Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zoomfloppy-use...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/zoomfloppy-users/aPZVAvwGrxzqL4rf%40hermes.local.trikaliotis.net.

[Spiro Trikaliotis]

Hello Dan,

* On Mon, Oct 20, 2025 at 12:50:49PM -0400 Dan Gahlinger wrote:
>
> d64copy can't create d71 images

That's wrong, it can.

Have you tried the "-2" (or "--two-sided") option?

If it does not work with that, can you give me the exact command-line
you pass to d64copy in order to create a d71 image, as well as the
output?

> I kind of suspected  this was the case
> The imgcopy source code is a convoluted mess - to me as a non coder

d64copy is not very good. imgcopy took it, copied it over and over and
made it even worse.

> I got imgcopy working with 1581 drive making d81 images reliably,  seems very
> stable but you have to use extra command line options 

imgcopy sometimes tries to use a "serial3" protocol, that does not
exist!

Unfortunately, the implementation of that protocol seems to be
non-existent.

[Dan Gahlinger]

Spiro,
Aha, so the d64 description line is misleading
"Copy .d64 disk images to a CBM-1541 or compatible drive and vice versa"

the option to make D71 images from a 1571 drive is:

d64copy --drive-type=1571 -2 8 test.d71

the description is why I never dug into trying d64copy
though the 1571 drive option and the -2 option were a bit, odd...

Mystery solved for D71 disks
thank you!

So as of now imgcopy is only useful for 1581 drives and disks
here's my working, apparently stable command line
in case you need it:

imgcopy --no-warp -ts2 --drive-type=1581 8 test.d81

it's the way I've gotten it to work, reliably, so it's what I use.

I tried d64copy with a 1581 and it doesn't work, it just hangs,
and it reports the drive as a 1571 for some weird reason

d64copy -vvvvvv --drive-type=1581 8 test.d81

[Debug] transfer mode is 0

[Debug] decided to use transfer mode 3
[Info] drive 08 (1571): 00, OK,00,00

however, I'm very confident my imcopy command line should be reliable for 1581 disks

--

[Dan Gahlinger]

yeah, as in my other message, I got d64copy to work with d71 images finally

then for fun I tried d64copy on a 1581, and that did not go well
it tries serial mode 3 there as well
but it detects the 1581 as a 1571 drive, which is bizarre

you'll see my working imgcopy command line for 1581 in that message
so far, for hundreds of disks, it's been stable.

Dan.

--
You received this message because you are subscribed to the Google Groups "ZoomFloppy Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zoomfloppy-use...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/zoomfloppy-users/aPZqLtcGvDh-VxTg%40hermes.local.trikaliotis.net.

--