First tests, CBMXfer

[sjgray]

Hi all,

My ZoomFloppy arrived and I am testing my CBMXfer program (btw, thanks
for the plug in the user's guide!).

I am using Win7 Pro 64-bit on a Dell XPS Core i7 desktop as my
development machine. Initial installation was a little problematic as
I got "driver failed to install" when plugging it in for the first
time. A manual driver install was needed. BTW, there should be a note
in the docs to make sure OpenCBM installer is run from the C: drive,
since the BAT file fails to specify the drive letter in the copy
commands. I tried installing from a network drive and the opencbm
directory got copied there...

After copying a few exe's into the CBMXfer folder I was able to get a
directory from my 1541-II drive, so everything seems to be
communicating. However, when I try copying a PRG file to the drive it
hangs. If I turn the drive off and back on I can see that the file
copied ok.

Has anyone else experienced this problem?

BTW, I found a few bugs in CBMXfer that need to be fixed (ie: copying
files with "/" in the name), and I am hoping to release an update that
is ZoomFloppy-friendly in the future. If anyone finds any problems
with CBMXfer please post them here, or contact me via email and I will
do what I can.

Steve

[Nate Lawson]

On 2/1/2011 9:23 AM, sjgray wrote:
> My ZoomFloppy arrived and I am testing my CBMXfer program (btw, thanks
> for the plug in the user's guide!).
>
> I am using Win7 Pro 64-bit on a Dell XPS Core i7 desktop as my
> development machine. Initial installation was a little problematic as
> I got "driver failed to install" when plugging it in for the first
> time. A manual driver install was needed.

Never seen that. You have to follow the steps of selecting the .inf file
and then the 64-bit drivers are installed.

> BTW, there should be a note
> in the docs to make sure OpenCBM installer is run from the C: drive,
> since the BAT file fails to specify the drive letter in the copy
> commands. I tried installing from a network drive and the opencbm
> directory got copied there...

Well, it's an unsolveable conflict. Someone else wanted it to default to
current drive so he could install on D:. The right answer is to build a
real installer, but that's outside my area of expertise.

I have already update the script to tell you that it installs to the
current drive, so that will be in the next release.

> After copying a few exe's into the CBMXfer folder I was able to get a
> directory from my 1541-II drive, so everything seems to be
> communicating. However, when I try copying a PRG file to the drive it
> hangs. If I turn the drive off and back on I can see that the file
> copied ok.
>
> Has anyone else experienced this problem?

The cbmread/cbmwrite commands have known race conditions in them. I
haven't seen problems, but for other people, they have seen some
lockups. It's better to create a d64 on the local hard drive and then
get/put files to it, then write the whole d64 to a floppy with d64copy
or nibwrite. Whole-disk transfers are not a problem.

The OpenCBM team has indicated they may fix libcbmtransfer in the
future, but I have no idea on timeline. Perhaps that's a worthwhile
bounty now that more people are depending on OpenCBM.

> BTW, I found a few bugs in CBMXfer that need to be fixed (ie: copying
> files with "/" in the name), and I am hoping to release an update that
> is ZoomFloppy-friendly in the future. If anyone finds any problems
> with CBMXfer please post them here, or contact me via email and I will
> do what I can.

Great, thanks for maintaining the GUI.

--
Nate

[Steve Gray]

----- Original Message ----
> From: Nate Lawson <na...@root.org>
> To: zoomflop...@googlegroups.com
> Sent: Tue, February 1, 2011 2:22:50 PM
> Subject: Re: First tests, CBMXfer
>
> On 2/1/2011 9:23 AM, sjgray wrote:
> > My ZoomFloppy arrived and I am testing my CBMXfer program (btw, thanks
> > for the plug in the user's guide!).
> >
> > I am using Win7 Pro 64-bit on a Dell XPS Core i7 desktop as my
> > development machine. Initial installation was a little problematic as
> > I got "driver failed to install" when plugging it in for the first
> > time. A manual driver install was needed.
>
> Never seen that. You have to follow the steps of selecting the .inf file
> and then the 64-bit drivers are installed.

I never got the dialog box to select a driver, just the error popup from the
system tray.

> > BTW, there should be a note
> > in the docs to make sure OpenCBM installer is run from the C: drive,
> > since the BAT file fails to specify the drive letter in the copy
> > commands. I tried installing from a network drive and the opencbm
> > directory got copied there...
>
> Well, it's an unsolveable conflict. Someone else wanted it to default to
> current drive so he could install on D:. The right answer is to build a
> real installer, but that's outside my area of expertise.
< 
> I have already update the script to tell you that it installs to the
> current drive, so that will be in the next release.

Understandable. I was just momentarily confused ;-)

 
> >  After copying a few exe's into the CBMXfer folder I was able to get a
> > directory from my 1541-II drive, so everything seems to be
> > communicating. However, when I try copying a PRG file to the drive it
> > hangs. If I turn the drive off and back on I can see that the file
> > copied ok.
> >
> > Has anyone else experienced this problem?
>
> The cbmread/cbmwrite commands have known race conditions in them. I
> haven't seen problems, but for other people, they have seen some
> lockups. It's better to create a d64 on the local hard drive and then
> get/put files to it, then write the whole d64 to a floppy with d64copy
> or nibwrite. Whole-disk transfers are not a problem.

I am finding that the problem occurs on write but not on read.

> The OpenCBM team has indicated they may fix libcbmtransfer in the
> future, but I have no idea on timeline. Perhaps that's a worthwhile
> bounty now that more people are depending on OpenCBM.
>
> > BTW, I found a few bugs in CBMXfer that need to be fixed (ie: copying
> > files with "/" in the name), and I am hoping to release an update that
> > is ZoomFloppy-friendly in the future. If anyone finds any problems
> > with CBMXfer please post them here, or contact me via email and I will
> > do what I can.
>
> Great, thanks for maintaining the GUI.

Thanks for a great product!

> --
> Nate
> 

Perhaps I should ask the opencbm people, but I figure I'll throw this out
for fun....

What is the feasability of using BOTH an X-cable and Zoom Floppy USB cable on
the same system? Is it possible? If so should it be supported in CBMXfer? Plus,
I've never used a parallel speeder cable... is this something I should look into
supporting as well, or do people use command-line mostly?

Steve 

[Aknight]

Just want to point out that I am using CBMxfer v0.28, and I am
experiencing unrecoverable hangs with certain disks. I actually
started a thread about it yesterday (Transfer Hangs). I think the
conclusion we are coming to is that disks with errors are not handled
gracefully. I end up having to unplug/replug the ZF to get the
operation to reset.

I'd like to put forth a question: Obviously cbmxfer functionality
should be priority, but is it possible to at some point add metadata
fields to the .d64 format such that things like year, notes, etc are
possible to be contained within the one file?

[Gerrit Hansen]

Am 01.02.2011 20:46, schrieb Steve Gray:
[...]

> What is the feasability of using BOTH an X-cable and Zoom Floppy USB cable on
> the same system? Is it possible? If so should it be supported in CBMXfer? Plus,
> I've never used a parallel speeder cable... is this something I should look into
> supporting as well, or do people use command-line mostly?

Well, I'd certainly be happy if you could support that, and I dream of a
gui for those nibtools also but that would be a bit too much I guess.
;-) Anyway thank you for a great gui, my first test on ZoomFloppy was
with cbmxfer and I had no problems transferring a .d64.

Gerrit

[Steve Gray]

Hi,

----- Original Message ----
> From: Aknight <akni...@gmail.com>
> To: ZoomFloppy Users <zoomflop...@googlegroups.com>
> Sent: Tue, February 1, 2011 2:55:30 PM
> Subject: Re: First tests, CBMXfer
>

> Just want to point out that I am using CBMxfer v0.28, and I am
> experiencing unrecoverable hangs with certain disks. I actually
> started a thread about it yesterday (Transfer Hangs). I think the
> conclusion we are coming to is that disks with errors are not handled
> gracefully. I end up having to unplug/replug the ZF to get the
> operation to reset.

Well, I'm planning to do a little debugging to find out if this is something I
can detect/correct, but if it turns out that the command-line utility or driver
are just hung then there might not be much I can do. Obviously a GUI just makes
things easier to use and I am at the mercy of the underlying code. That said I'm
willing to try working around any issues if possible.

BTW, I am able to just power off the drive to get it to come back to life.
CBMXfer doesn't crash/abort and the file appears to be copied properly. I don't
experience any head knocking or error light, but at this point I have only tried
the 1541-II.

 
> I'd like to put forth a question: Obviously cbmxfer functionality
> should be priority, but is it possible to at some point add metadata
> fields to the .d64 format such that things like year, notes, etc are
> possible to be contained within the one file?

I'm not an expert on the D64 format, but perhaps additional data could be
appended to the end somehow, but there would be no guarantee that the data
wouldn't cause problems with all D64 utilties. It would probably be easier to
add a separate TAG file with that info. I'm sure it wouldn't take that much to
have CBMXfer look for and update such a tag file.

Steve 

[Jim Brain]

What would be the advantage of supporting both? If you have a ZF, then
you have the ability to run anything the X cable could do, no?

Jim

--
Jim Brain, Brain Innovations
br...@jbrain.com
www.jbrain.com
www.jbrain.net (eStore)

[Jim Brain]

On 2/1/2011 2:14 PM, Steve Gray wrote:
> Hi,
>
>
>
> ----- Original Message ----
>> From: Aknight<akni...@gmail.com>
>> To: ZoomFloppy Users<zoomflop...@googlegroups.com>
>> Sent: Tue, February 1, 2011 2:55:30 PM
>> Subject: Re: First tests, CBMXfer
>>
>> Just want to point out that I am using CBMxfer v0.28, and I am
>> experiencing unrecoverable hangs with certain disks. I actually
>> started a thread about it yesterday (Transfer Hangs). I think the
>> conclusion we are coming to is that disks with errors are not handled
>> gracefully. I end up having to unplug/replug the ZF to get the
>> operation to reset.
> Well, I'm planning to do a little debugging to find out if this is something I
> can detect/correct, but if it turns out that the command-line utility or driver
> are just hung then there might not be much I can do. Obviously a GUI just makes
> things easier to use and I am at the mercy of the underlying code. That said I'm
> willing to try working around any issues if possible.

Is there an DLL/Shared Library that you can call directly? Or, isn;t
there some way Unix tools deal with this so Gnome/KDE GUIs can control
in minute detail the command line tools they sit on top of?

> BTW, I am able to just power off the drive to get it to come back to life.
> CBMXfer doesn't crash/abort and the file appears to be copied properly. I don't
> experience any head knocking or error light, but at this point I have only tried
> the 1541-II.

Jim

[Steve Gray]

Steve

I wouldn't say support for nib tools would be too difficult, but I currently have no way to test. If you are willing to test, I could build a version of cbmxfer for you. Would two additional transfer buttons in the middle be best? What command line options would you need? Can you list some typical commands?

Steve

[Gerrit Hansen]

Am 02.02.2011 01:57, schrieb Jim Brain:
> On 2/1/2011 2:04 PM, Gerrit Hansen wrote:
>> Am 01.02.2011 20:46, schrieb Steve Gray:
>> [...]
>>> What is the feasability of using BOTH an X-cable and Zoom Floppy USB
>>> cable on
>>> the same system? Is it possible? If so should it be supported in
>>> CBMXfer? Plus,
>>> I've never used a parallel speeder cable... is this something I
>>> should look into
>>> supporting as well, or do people use command-line mostly?
>>
>> Well, I'd certainly be happy if you could support that, and I dream of
>> a gui for those nibtools also but that would be a bit too much I
>> guess. ;-) Anyway thank you for a great gui, my first test on
>> ZoomFloppy was with cbmxfer and I had no problems transferring a .d64.
>>
>> Gerrit
> What would be the advantage of supporting both? If you have a ZF, then
> you have the ability to run anything the X cable could do, no?

Yes, of course, I just mean having a GUI like CBMXfer supporting nibble
transfer. Of course I can always use the command line nibtools iteslf.
Was just a suggestion to Steve, sorry if I got it somehow confused.

Gerrit

[Gerrit Hansen]

Am 02.02.2011 17:48, schrieb Steve Gray:
>
>
> Steve
>
>
> On Feb 1, 2011, at 3:04 PM, Gerrit Hansen <fire...@animexx.de

When I have a working device again I would certainly like to test it for
you. I'd say buttons in the middle are ok, but for command line options
I'd had to work with nibtools a bit more. The thing is I have only a
normal X-Cable right now and I don't want to buy the ones with parallel
port support, that's what I bought ZoomFloppy for.

Gerrit

[Spiro Trikaliotis]

Hellom

* On Tue, Feb 01, 2011 at 06:57:24PM -0600 Jim Brain wrote:

> What would be the advantage of supporting both? If you have a ZF, then
> you have the ability to run anything the X cable could do, no?

At least for me (debugging), I am using both variants. (In fact, it is
xu1541 and xa1541 currently, but you get the point.)

Thus, if I would use a GUI, it would help to be able to choose which to
use.

Note also that the XA1541 and XM1541 might have a small advantage when
it comes to timing. The ZF had to make some stunts in order to hide this
difference, so it is (almost?) non-observable, but it is there.

Regards,
Spiro.

--
Spiro R. Trikaliotis http://opencbm.sf.net/
http://www.trikaliotis.net/ http://www.viceteam.org/

[Nate Lawson]

On 2/1/2011 11:46 AM, Steve Gray wrote:
>>> After copying a few exe's into the CBMXfer folder I was able to get a
>>> directory from my 1541-II drive, so everything seems to be
>>> communicating. However, when I try copying a PRG file to the drive it
>>> hangs. If I turn the drive off and back on I can see that the file
>>> copied ok.
>>>
>>> Has anyone else experienced this problem?
>>
>> The cbmread/cbmwrite commands have known race conditions in them. I
>> haven't seen problems, but for other people, they have seen some
>> lockups. It's better to create a d64 on the local hard drive and then
>> get/put files to it, then write the whole d64 to a floppy with d64copy
>> or nibwrite. Whole-disk transfers are not a problem.
>
> I am finding that the problem occurs on write but not on read.

It's worth looking into eventually. It's possible we could do something
in the ZF firmware to try to work around the race conditions in
libcbmtransfer (adding delays).

One of our testers says the 1581 is fine with a mass cbmwrite test. It
must have different timings.

> Perhaps I should ask the opencbm people, but I figure I'll throw this out
> for fun....
>
> What is the feasability of using BOTH an X-cable and Zoom Floppy USB cable on
> the same system? Is it possible? If so should it be supported in CBMXfer? Plus,
> I've never used a parallel speeder cable... is this something I should look into
> supporting as well, or do people use command-line mostly?

Sure it's possible. You can also have multiple ZoomFloppy adapters in
use with the same PC. Just use the -@ flag to direct requests to the
right adapter.

Example: d64copy -@xum1541:1 8 disk.d64

The number after the colon is the EEPROM id, default 0. We'll add an
option to the config utility for changing that id more easily.

--
Nate

[Nate Lawson]

On 2/1/2011 12:14 PM, Steve Gray wrote:
>> From: Aknight <akni...@gmail.com>

>>
>> Just want to point out that I am using CBMxfer v0.28, and I am
>> experiencing unrecoverable hangs with certain disks. I actually
>> started a thread about it yesterday (Transfer Hangs). I think the
>> conclusion we are coming to is that disks with errors are not handled
>> gracefully. I end up having to unplug/replug the ZF to get the
>> operation to reset.
>
> Well, I'm planning to do a little debugging to find out if this is something I
> can detect/correct, but if it turns out that the command-line utility or driver
> are just hung then there might not be much I can do. Obviously a GUI just makes
> things easier to use and I am at the mercy of the underlying code. That said I'm
> willing to try working around any issues if possible.
>
> BTW, I am able to just power off the drive to get it to come back to life.
> CBMXfer doesn't crash/abort and the file appears to be copied properly. I don't
> experience any head knocking or error light, but at this point I have only tried
> the 1541-II.

If you abort the current running subprocess (d64copy) and then the user
restarts it, the ZF will transparently reset the IEC bus and start the
new command. I've tested this quite thoroughly.

You don't have to power off the drive, just run the next command. If
you're using libd64copy directly, then you need to create your own
thread and kill it off via the GUI. Same basic idea, just via threads
instead of processes.

--
Nate

[Nate Lawson]

I'd suggest making it just a checkbox ("Use nibbler"). This would modify
whether the read/write disk image options use d64copy or nibtools. You
might want some checkboxes for addl output formats as well (d64/g64 in
addition to always generating a .nib).

You can run the nibtools without having a parallel cable in order to see
their usage. Just don't specify any args.

Typical usage:
nibread a.nib
nibconv a.nib a.d64
nibwrite a.nib

--
Nate

[Nate Lawson]

On 2/1/2011 4:57 PM, Jim Brain wrote:
> On 2/1/2011 2:04 PM, Gerrit Hansen wrote:
>> Am 01.02.2011 20:46, schrieb Steve Gray:
>> [...]
>>> What is the feasability of using BOTH an X-cable and Zoom Floppy USB
>>> cable on
>>> the same system? Is it possible? If so should it be supported in
>>> CBMXfer? Plus,
>>> I've never used a parallel speeder cable... is this something I
>>> should look into
>>> supporting as well, or do people use command-line mostly?
>>
>> Well, I'd certainly be happy if you could support that, and I dream of
>> a gui for those nibtools also but that would be a bit too much I
>> guess. ;-) Anyway thank you for a great gui, my first test on
>> ZoomFloppy was with cbmxfer and I had no problems transferring a .d64.
>>
>> Gerrit
>
> What would be the advantage of supporting both? If you have a ZF, then
> you have the ability to run anything the X cable could do, no?

OpenCBM already supports both using the -@ flag. So you can do at the
same time:

d64copy -@xa1541 8 a.d64
d64copy -@xum1541 8 a.d64

This will start a read of two images at the same time, both from drive 8
on the respective adapters (XA1541 and ZoomFloppy). Note you cannot
access two drives at the same time on the same adapter.

--
Nate

[Jim Brain]

On 2/2/2011 12:42 PM, Spiro Trikaliotis wrote:
> Hellom
>
> * On Tue, Feb 01, 2011 at 06:57:24PM -0600 Jim Brain wrote:
>
>> What would be the advantage of supporting both? If you have a ZF, then
>> you have the ability to run anything the X cable could do, no?
> At least for me (debugging), I am using both variants. (In fact, it is
> xu1541 and xa1541 currently, but you get the point.)

As long as the support does not adversely affect the codebase, I will
concede. But, if it does adversely impact the codebase, I don't think
debugging is enough of a reason to continue support.

>
> Note also that the XA1541 and XM1541 might have a small advantage when
> it comes to timing. The ZF had to make some stunts in order to hide this
> difference, so it is (almost?) non-observable, but it is there.

THis, though, it most interesting. Can you clarify? Is this something
that the solution can address in the future, or is it a function of the
way xum1541 works?

Jim

[Nate Lawson]

I assume he's just saying that the low latency of the LPT port (1 us per
line(s) flipped) is better in some cases than the ZF's USB bulk transfer
+ lines flipped at 0.125 us).

We do try to overlap transfers between the floppy and USB via the
USB-DMA engine in the mcu, but it's always going to be slightly slower
than a low-latency interface direct from host to drive. This is because
USB has more overhead and latency.

The LPT port is on the way out and since we do just fine with USB, this
is not an important distinction. I think OpenCBM should keep supporting
the LPT adapters since they still work and there is a decent installed
base. But new users should switch to USB.

--
Nate

[Jim Brain]

On 2/2/2011 8:02 PM, Nate Lawson wrote:
>
> The LPT port is on the way out and since we do just fine with USB, this
> is not an important distinction. I think OpenCBM should keep supporting
> the LPT adapters since they still work and there is a decent installed
> base. But new users should switch to USB.
>

I'm not suggesting parport support should be removed, I just don't think
the use cases for needing support for both at the same time should be
kept if the cost to maintain the code adversely impacts development.

[Steve Gray]

Hi Nate,

> I'd suggest making it just a checkbox ("Use nibbler"). This would modify
> whether the read/write disk image options use d64copy or nibtools. You
> might want some checkboxes for addl output formats as well (d64/g64 in
> addition to always generating a .nib).

I'm just starting to read the NIBTOOLS docs, so excuse me if these are silly
questions...

- Are NIB and G64 formats the same, or does NIBTOOLS pick the format based on
the file extension?
- How are 1571 disks handled differently than 1541 disks?
     IE: we have D64 and D71... how is NIB differentiated? By file size or some
internal structure?
     Will NIBTOOLS read/write D71 files?
- Are D64 files created with NIBTOOLS the same as those created by D64COPY? If
so, why would I use NIB?
- Default end track seems to be 41, but later doc cautions against using more
than 40 tracks?...
- Is -@ supported in NIBTOOLS?

 
> You can run the nibtools without having a parallel cable in order to see
> their usage. Just don't specify any args.
>
> Typical usage:
> nibread a.nib
> nibconv a.nib a.d64
> nibwrite a.nib
>
> --
> Nate

Thanks for helping me understand...

Steve

[Chris McBride]

NIB and G64 are similar (but different) Both of these formats save the raw
GCR data.
D64 and D71 save the actual bytes. That is the first byte of D64 is the
first byte of track 1 sector 0 (and will be the track/sector pointer to the
next sector)

D71 will be twice as big as D64. While NIB and G64 will be much larger (as
it is the raw GCR format)

Unfortunately all of these types are essentially differentiated by the
extension. Although you can make some pretty good educated guesses based on
the file size and the content.

I don't know anything about Nibtools, but if it produces a d64 it should be
the same file as one produced as d64copy.
Why should you use one over the other? Cause one is easier to use? One is
faster? Looks better? Smells better? You are more used to one over the
other?

You need to run nibtools to generate a nib file. Because NIB files reproduce
the disk much more accurately than .d64's it can deal with errors on the
disk and some copy protected programs can then be run on an emulator.

If you have originals you should NIB them. If you have regular homemade
disks you can probably get away with using just .d64s/d71s. The advantage of
d64/d71 over .NIB is more programs support them and they are smaller.

-----Original Message-----
From: Steve Gray
Sent: Wednesday, February 02, 2011 7:18 PM
To: zoomflop...@googlegroups.com
Subject: Re: First tests, CBMXfer

[Spiro Trikaliotis]

Hello,

* On Wed, Feb 02, 2011 at 08:18:54PM -0600 Jim Brain wrote:
> On 2/2/2011 8:02 PM, Nate Lawson wrote:
>>
>> The LPT port is on the way out and since we do just fine with USB, this
>> is not an important distinction. I think OpenCBM should keep supporting
>> the LPT adapters since they still work and there is a decent installed
>> base. But new users should switch to USB.
>>
> I'm not suggesting parport support should be removed, I just don't think
> the use cases for needing support for both at the same time should be
> kept if the cost to maintain the code adversely impacts development.

The plugin concept was invented exactly for this (being able to use
xa1541, xu1541, now xum1541, and, possibly, the xs1541 if someone writes
a plugin.

The mechanism is already there in the underlying software (OPenCBM). For
cbmxfer, it is only adding ONE (!) command-line switch (-@xa1541,
-@xu1541, -@xum1541) in order to make it work.

I doubt it will "adversely impact development".

[Spiro Trikaliotis]

Hello,

* On Wed, Feb 02, 2011 at 06:02:34PM -0800 Nate Lawson wrote:
> On 2/2/2011 5:15 PM, Jim Brain wrote:
> > On 2/2/2011 12:42 PM, Spiro Trikaliotis wrote:
> >> Note also that the XA1541 and XM1541 might have a small advantage when
> >> it comes to timing. The ZF had to make some stunts in order to hide this
> >> difference, so it is (almost?) non-observable, but it is there.

[...]

> I assume he's just saying that the low latency of the LPT port (1 us per
> line(s) flipped) is better in some cases than the ZF's USB bulk transfer
> + lines flipped at 0.125 us).

Yes, that's what I wanted to say.

> We do try to overlap transfers between the floppy and USB via the
> USB-DMA engine in the mcu, but it's always going to be slightly slower
> than a low-latency interface direct from host to drive. This is because
> USB has more overhead and latency.

This is what I meant with "stunts".

> The LPT port is on the way out

...

and that's the reason why I think the xum1541/ZF is a very important
step - even more important than the xu1541, btw.

However, the xu1541 was a. the first step to show that it is possible
with USB, and b. the reason to install the infrastructure which made the
xum1541 possible so quickly.

[Gene Buckle]

I got in the 15 pin cable needed for the parallel mod on my 1571
yesterday. It's six feet long and I'm wondering if that is going to cause
signal latency or impedance issues.

Would I be better served custom crafting a much shorter cable?

g.

--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.simpits.org/geneb - The Me-109F/X Project

ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://www.scarletdme.org - Get it _today_!

Political correctness is a doctrine, fostered by a delusional, illogical
minority, and rabidly promoted by an unscrupulous mainstream media, which
holds forth the proposition that it is entirely possible to pick up a turd
by the clean end.

[Nate Lawson]

On 2/2/2011 6:18 PM, Jim Brain wrote:
> On 2/2/2011 8:02 PM, Nate Lawson wrote:
>>
>> The LPT port is on the way out and since we do just fine with USB, this
>> is not an important distinction. I think OpenCBM should keep supporting
>> the LPT adapters since they still work and there is a decent installed
>> base. But new users should switch to USB.
>>
> I'm not suggesting parport support should be removed, I just don't think
> the use cases for needing support for both at the same time should be
> kept if the cost to maintain the code adversely impacts development.

I see. No, there is no difficulty in keeping this. It's just the general
plugin intermediary code, which is useful and not a maintenance problem.

--
Nate

[Nate Lawson]

On 2/3/2011 6:06 AM, Gene Buckle wrote:
> I got in the 15 pin cable needed for the parallel mod on my 1571
> yesterday. It's six feet long and I'm wondering if that is going to
> cause signal latency or impedance issues.
>
> Would I be better served custom crafting a much shorter cable?

That should be fine. The data rate is 40 KB/s parallel, which you can
think of as similar to a 56 Kbit/s modem (modulo crosstalk between lines).

The most important thing is to not run it too close to power lines and
maybe use shielded wire if that's possible. But any cable, even alarm
wire, is probably fine at 6 ft or less.

--
Nate

[Gene Buckle]

It's a commercially manufactured cable, so it should have some kind of
shield on it. Thanks Nate. Now I just have to get my enclosure made. :)

[Jim Brain]

I understand better now. Initially, I thought the request was for this:

<cbmcommand> -@xa1541 copy 8 something.d64 -@xum1541 copy 9 something.d64

All on one line. I thought the command switch parsing, the need for the
code to juggle two simultaneous sessions with two adapters, etc. was of
dubious value.

But:

<command> -@xa1541....
<command> -@xum1541...

Is, as you say, a side benefit of offering the ability to choose the
plugin specifically, and the plugin is not hardcoded. I have no issues
with this.

[Nate Lawson]

On 2/2/2011 9:39 PM, Chris McBride wrote:
> NIB and G64 are similar (but different) Both of these formats save the
> raw GCR data.
> D64 and D71 save the actual bytes. That is the first byte of D64 is the
> first byte of track 1 sector 0 (and will be the track/sector pointer to
> the next sector)

Correct. D64 assumes sectors are DOS-formatted and thus does not contain
any metadata (trailer gap, sync bytes).

> I don't know anything about Nibtools, but if it produces a d64 it should
> be the same file as one produced as d64copy.

nibtools can produce a d64 directly, but I think it's always best to
create a .nib and then use nibconv to down-convert it to a d64. That way
you have the most information possible. nibconv can also do .nib -> .g64
for emulator use.

> Why should you use one over the other? Cause one is easier to use? One
> is faster? Looks better? Smells better? You are more used to one over
> the other?
>
> You need to run nibtools to generate a nib file. Because NIB files
> reproduce the disk much more accurately than .d64's it can deal with
> errors on the disk and some copy protected programs can then be run on
> an emulator.
>
> If you have originals you should NIB them. If you have regular homemade
> disks you can probably get away with using just .d64s/d71s. The
> advantage of d64/d71 over .NIB is more programs support them and they
> are smaller.

nibtools is also much faster than even d64copy with a parallel cable.

> - How are 1571 disks handled differently than 1541 disks?
> IE: we have D64 and D71... how is NIB differentiated? By file size
> or some
> internal structure?
> Will NIBTOOLS read/write D71 files?

I don't know the answers to the above. It does not create D71 files as
far as I know.

> - Are D64 files created with NIBTOOLS the same as those created by
> D64COPY? If
> so, why would I use NIB?

Yes, they are identical. In fact, one way to test nibtools is to write a
disk with d64copy, then nibread it and convert to d64. They should be
bytewise identical if no write/read errors.

> - Default end track seems to be 41, but later doc cautions against using
> more
> than 40 tracks?...

41 is ok. It's 42 that causes head seek problems.

> - Is -@ supported in NIBTOOLS?

Not yet. I hope Pete will add that support.

--
Nate

[Pete Rittwage]

On Thu, Feb 3, 2011 at 1:57 PM, Nate Lawson <na...@root.org> wrote:

> I don't know anything about Nibtools, but if it produces a d64 it should
> be the same file as one produced as d64copy.

nibtools can produce a d64 directly, but I think it's always best to
create a .nib and then use nibconv to down-convert it to a d64. That way
you have the most information possible. nibconv can also do .nib -> .g64
for emulator use.

I removed the ability for nibread to create a D64 directly, because that is not the point of it- it made no sense.  You can always create a NIB (or NBZ, which is the default, and just LZ-like compression of NIB data) and then convert to D64, but this loses the original GCR data.  Keeping the NIB is wise, should you ever want to process it differently in the future. 

D64 is "lossy", G64 is still "lossy", but much less so.  nibconv tries to find the "seams" of the track and stich them back together, and can perform alignment, processing, and compression of the data, which may be needed for emulation or remastering to disk.

There is also NB2, which is only for extreme cases- it contains 3 rotation samples of each halftrack, at each density setting.  I only use this for analysis.

Pete
 

[Steve Gray]

Pete,

 

Perhaps keeping it in strickly for the speed benefit and the flexibilty of using one command for multiple formats (similar to how CBMXfer will integrate OpenCBM, VICE, CBMLink, and Nibtools into one interface)...

 

I have been working on a major update to CBMXfer to support nibtools and I am about 95% complete functionality-wise. Just doing some work on cleaning up the code and testing.

 

Steve

From: Pete Rittwage <ritt...@gmail.com>
To: zoomflop...@googlegroups.com
Sent: Sat, February 5, 2011 2:57:25 PM
Subject: Re: First tests, CBMXfer

[Gene Buckle]

The source disk is Adventure Creator by UXB.

Y:\Commodore\nib_files\07Feb11>nibread -d8 -e50 -v adventure-creator.nib

nibread - Commodore 1541/1571 disk image nibbler
(C) 2004-2010 Peter Rittwage
C64 Preservation Project
http://c64preservation.com
Revision 485 - (Built Jan 13 2011 18:02:16)

* Forcing default density
* Read retries set to 50
* Simple track match (crude verify)

Drive Version: 73,JIFFYDOS 6.0 1571,00,00
Drive type: 1571
Bumping...
Initializing
Uploading floppy-side code...
Starting custom drive code...
Passed basic parallel port checks.

18.0: {DEFAULT }(2)
Cosmetic Disk ID: 'SP'
Format Disk ID: 'SP'

1.0: {DEFAULT }(3) H 7837
{DEFAULT }(3) H 7828 [99% GCR Match]
2.0: {DEFAULT }(3) 0 [Unformatted Track]
3.0: {DEFAULT }(3) 0 [Unformatted Track]
4.0: {DEFAULT }(3) 0 [Unformatted Track]
5.0: {DEFAULT }(3) USB error in read data(0028BA70, 8192):
libusb0-dll:err [_us
b_reap_async] reaping request failed, win error: A device attached to the
system
is not functioning.

0 [Unformatted Track] USB error in write cmd: libusb0-dll:err
[submit_async] sub
mitting request failed, win error: The system cannot find the file
specified.

USB error in xum1541_ioctl cmd: libusb0-dll:err [submit_async] submitting
reques
t failed, win error: The system cannot find the file specified.

USB error in write cmd: libusb0-dll:err [submit_async] submitting request
failed
, win error: The system cannot find the file specified.

Resetting drive...
USB error in xum1541_control_msg: libusb0-dll:err [control_msg] sending
control
message failed, win error: The device does not recognize the command.

USB error in write cmd: libusb0-dll:err [submit_async] submitting request
failed
, win error: The device does not recognize the command.

Resetting drive...
USB error in xum1541_control_msg: libusb0-dll:err [control_msg] sending
control
message failed, win error: The device does not recognize the command.

USB error in write cmd: libusb0-dll:err [submit_async] submitting request
failed
, win error: The device does not recognize the command.

Resetting drive...
USB error in xum1541_control_msg: libusb0-dll:err [control_msg] sending
control
message failed, win error: The device does not recognize the command.

USB error in write cmd: libusb0-dll:err [submit_async] submitting request
failed
, win error: The device does not recognize the command.

Resetting drive...
USB error in xum1541_control_msg: libusb0-dll:err [control_msg] sending
control
message failed, win error: The device does not recognize the command.

USB error in write cmd: libusb0-dll:err [submit_async] submitting request
failed
, win error: The device does not recognize the command.

Resetting drive...
USB error in xum1541_control_msg: libusb0-dll:err [control_msg] sending
control
message failed, win error: The device does not recognize the command.

USB error in write cmd: libusb0-dll:err [submit_async] submitting request
failed
, win error: The device does not recognize the command.

Resetting drive...
USB error in xum1541_control_msg: libusb0-dll:err [control_msg] sending
control
message failed, win error: The device does not recognize the command.

USB error in write cmd: libusb0-dll:err [submit_async] submitting request
failed
, win error: The device does not recognize the command.

Resetting drive...
USB error in xum1541_control_msg: libusb0-dll:err [control_msg] sending
control
message failed, win error: The device does not recognize the command.

USB error in write cmd: libusb0-dll:err [submit_async] submitting request
failed
, win error: The device does not recognize the command.

Resetting drive...
USB error in xum1541_control_msg: libusb0-dll:err [control_msg] sending
control
message failed, win error: The device does not recognize the command.

USB error in write cmd: libusb0-dll:err [submit_async] submitting request
failed
, win error: The device does not recognize the command.

Resetting drive...
USB error in xum1541_control_msg: libusb0-dll:err [control_msg] sending
control
message failed, win error: The device does not recognize the command.

USB error in write cmd: libusb0-dll:err [submit_async] submitting request
failed
, win error: The device does not recognize the command.

Resetting drive...
USB error in xum1541_control_msg: libusb0-dll:err [control_msg] sending
control
message failed, win error: The device does not recognize the command.

USB error in write cmd: libusb0-dll:err [submit_async] submitting request
failed
, win error: The device does not recognize the command.

Resetting drive...
USB error in xum1541_control_msg: libusb0-dll:err [control_msg] sending
control
message failed, win error: The device does not recognize the command.

USB error in write cmd: libusb0-dll:err [submit_async] submitting request
failed
, win error: The device does not recognize the command.

Resetting drive...
USB error in xum1541_control_msg: libusb0-dll:err [control_msg] sending
control
message failed, win error: The device does not recognize the command.

USB error in write cmd: libusb0-dll:err [submit_async] submitting request
failed
, win error: The device does not recognize the command.

Resetting drive...
USB error in xum1541_control_msg: libusb0-dll:err [control_msg] sending
control
message failed, win error: The device does not recognize the command.

USB error in write cmd: libusb0-dll:err [submit_async] submitting request
failed
, win error: The device does not recognize the command.

^C
Y:\Commodore\nib_files\07Feb11>

Y:\Commodore\nib_files\07Feb11>

[Nate Lawson]

On 2/9/2011 7:25 PM, Gene Buckle wrote:
> The source disk is Adventure Creator by UXB.

c64preservation.com gives 2 protection schemes for this disk, both
error-based:

* checks e5 on t18s18
* checks errors on t3

Neither is on track 5, where the device resets.

> Y:\Commodore\nib_files\07Feb11>nibread -d8 -e50 -v adventure-creator.nib
>
> nibread - Commodore 1541/1571 disk image nibbler
> (C) 2004-2010 Peter Rittwage
> C64 Preservation Project
> http://c64preservation.com
> Revision 485 - (Built Jan 13 2011 18:02:16)
>
> * Forcing default density
> * Read retries set to 50
> * Simple track match (crude verify)

Any reason why you're forcing default density? The density detection
code is pretty good.

I think you mean "-D8" (capital D) to select a device number. 8 is the
default so you can also just leave off this flag. Try again with the
proper flag here.

> Drive Version: 73,JIFFYDOS 6.0 1571,00,00

I don't think JD makes a difference, but noting that in case I can't
reproduce it.

> 18.0: {DEFAULT }(2)
> Cosmetic Disk ID: 'SP'
> Format Disk ID: 'SP'
>
> 1.0: {DEFAULT }(3) H 7837
> {DEFAULT }(3) H 7828 [99% GCR Match]
> 2.0: {DEFAULT }(3) 0 [Unformatted Track]
> 3.0: {DEFAULT }(3) 0 [Unformatted Track]
> 4.0: {DEFAULT }(3) 0 [Unformatted Track]
> 5.0: {DEFAULT }(3) USB error in read data(0028BA70, 8192):
> libusb0-dll:err [_us
> b_reap_async] reaping request failed, win error: A device attached to
> the system
> is not functioning.
>

Track 5 times out during the call to read the 8 KB track at once. Why is
it not returning the track data in time? Try skipping this track by
adding the -S6 flag. This will start on track 6. If it works, try -S4
and see if anything changes.

--
Nate

[Gene Buckle]

On Wed, 9 Feb 2011, Nate Lawson wrote:

> On 2/9/2011 7:25 PM, Gene Buckle wrote:
>> The source disk is Adventure Creator by UXB.
>
> c64preservation.com gives 2 protection schemes for this disk, both
> error-based:
>
> * checks e5 on t18s18
> * checks errors on t3
>
> Neither is on track 5, where the device resets.
>
>> Y:\Commodore\nib_files\07Feb11>nibread -d8 -e50 -v adventure-creator.nib
>>
>> nibread - Commodore 1541/1571 disk image nibbler
>> (C) 2004-2010 Peter Rittwage
>> C64 Preservation Project
>> http://c64preservation.com
>> Revision 485 - (Built Jan 13 2011 18:02:16)
>>
>> * Forcing default density
>> * Read retries set to 50
>> * Simple track match (crude verify)
>
> Any reason why you're forcing default density? The density detection
> code is pretty good.
>

"crude verify".

> I think you mean "-D8" (capital D) to select a device number. 8 is the
> default so you can also just leave off this flag. Try again with the
> proper flag here.
>

Ok. Note that if "-d" isn't a valid flag, the software should've bitched
about it. I've also got a huge problem with the exit message being
"Bailing out..." when there's been no failure, but that's besides the
point.

>> 1.0: {DEFAULT }(3) H 7837
>> {DEFAULT }(3) H 7828 [99% GCR Match]
>> 2.0: {DEFAULT }(3) 0 [Unformatted Track]
>> 3.0: {DEFAULT }(3) 0 [Unformatted Track]
>> 4.0: {DEFAULT }(3) 0 [Unformatted Track]
>> 5.0: {DEFAULT }(3) USB error in read data(0028BA70, 8192):
>> libusb0-dll:err [_us
>> b_reap_async] reaping request failed, win error: A device attached to
>> the system
>> is not functioning.
>>
>
> Track 5 times out during the call to read the 8 KB track at once. Why is
> it not returning the track data in time? Try skipping this track by
> adding the -S6 flag. This will start on track 6. If it works, try -S4
> and see if anything changes.

I'll give it a shot tonight. As to the "why", if I knew that, I would
have just told you to begin with.

g.

[Nate Lawson]

On 2/10/2011 6:00 AM, Gene Buckle wrote:
> On Wed, 9 Feb 2011, Nate Lawson wrote:
>>> * Forcing default density
>>> * Read retries set to 50
>>> * Simple track match (crude verify)
>>
>> Any reason why you're forcing default density? The density detection
>> code is pretty good.
>>
> "crude verify".

I don't understand. You're saying you had to pass "-d" (selects default
density instead of auto-detect) in order to use the verify option (-v)?

>> I think you mean "-D8" (capital D) to select a device number. 8 is the
>> default so you can also just leave off this flag. Try again with the
>> proper flag here.
>>
> Ok. Note that if "-d" isn't a valid flag, the software should've
> bitched about it. I've also got a huge problem with the exit message
> being "Bailing out..." when there's been no failure, but that's besides
> the point.

Agreed. nibtools does not use getopt.c and so has poor command line
error handling.

>>> 1.0: {DEFAULT }(3) H 7837
>>> {DEFAULT }(3) H 7828 [99% GCR Match]
>>> 2.0: {DEFAULT }(3) 0 [Unformatted Track]
>>> 3.0: {DEFAULT }(3) 0 [Unformatted Track]
>>> 4.0: {DEFAULT }(3) 0 [Unformatted Track]
>>> 5.0: {DEFAULT }(3) USB error in read data(0028BA70, 8192):
>>> libusb0-dll:err [_us
>>> b_reap_async] reaping request failed, win error: A device attached to
>>> the system
>>> is not functioning.
>>
>> Track 5 times out during the call to read the 8 KB track at once. Why is
>> it not returning the track data in time? Try skipping this track by
>> adding the -S6 flag. This will start on track 6. If it works, try -S4
>> and see if anything changes.
>
> I'll give it a shot tonight. As to the "why", if I knew that, I would
> have just told you to begin with.

Ok, thanks. The "why" is just rhetorical -- I didn't expect an answer.

--
Nate

[Pete Rittwage]

On Wed, Feb 9, 2011 at 10:25 PM, Gene Buckle <ge...@deltasoft.com> wrote:

The source disk is Adventure Creator by UXB.


Y:\Commodore\nib_files\07Feb11>nibread -d8 -e50 -v adventure-creator.nib

nibread - Commodore 1541/1571 disk image nibbler
(C) 2004-2010 Peter Rittwage
C64 Preservation Project
http://c64preservation.com
Revision 485 - (Built Jan 13 2011 18:02:16)

* Forcing default density

if you turn off density detection and a track appears with no sync marks, it can lock forever (and trigger watchdog) because it waits for a sync mark that never occurs.  Part of the density testing is to check whether the track is all sync, or no sync.  

Anyway, just don't use -d - it isn't needed and was not intended for protected disks or disks that aren't 100% standard CBM-DOS.  It was intended for batch reading of unprotected disks, as it was requested by someone doing a large archive that wanted to shave a few seconds off the process.

-
Pete Rittwage
C64 Preservation Project

[Gene Buckle]

I just re-tried the same disk, this time with the only command line
parameter being -e50 and it didn't crash.

Here's the log:

(Built Jan 13 2011 18:02:16) 'nibread -e50 adventure-creator.nib '
1.0: (3) 7830 (7830)
2.0: (2 NOSYNC!) 0 [Unformatted Track] (0)
3.0: (2 NOSYNC!) 0 [Unformatted Track] (0)
4.0: (2 NOSYNC!) 0 [Unformatted Track] (0)
5.0: (2 NOSYNC!) 0 [Unformatted Track] (0)
6.0: (2 NOSYNC!) 0 [Unformatted Track] (0)
7.0: (2 NOSYNC!) 0 [Unformatted Track] (0)
8.0: (2 NOSYNC!) 0 [Unformatted Track] (0)
9.0: (2 NOSYNC!) 0 [Unformatted Track] (0)
10.0: (2 NOSYNC!) 0 [Unformatted Track] (0)
11.0: (2 NOSYNC!) 0 [Unformatted Track] (0)
12.0: (2 NOSYNC!) 0 [Unformatted Track] (0)
13.0: (3) 7830 (7830)
14.0: (3) 7833 (7833)
15.0: (3) 7834 (7834)
16.0: (3) 7829 (7829)
17.0: (3) 7827 (bad/weak:2) (7827)
18.0: (2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7171 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7171 [E5S18]
(2) 7170 [E5S18]
(2) 7171 [E5S18]
(2) 7170 [E5S18]
(2) 7171 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18]
(2) 7170 [E5S18][E5S18] (7170)
19.0: (2) 7170 (7170)
20.0: (2) 0 [Unformatted Track] (0)
21.0: (2 NOSYNC!) 0 [Unformatted Track] (0)
22.0: (2 NOSYNC!) 0 [Unformatted Track] (0)
23.0: (2 NOSYNC!) 0 [Unformatted Track] (0)
24.0: (2 NOSYNC!) 0 [Unformatted Track] (0)
25.0: (1 NOSYNC!) 0 [Unformatted Track] (0)
26.0: (1 NOSYNC!) 0 [Unformatted Track] (0)
27.0: (1 NOSYNC!) 0 [Unformatted Track] (0)
28.0: (1 NOSYNC!) 0 [Unformatted Track] (0)
29.0: (1 NOSYNC!) 0 [Unformatted Track] (0)
30.0: (1 NOSYNC!) 0 [Unformatted Track] (0)
31.0: (1 NOSYNC!) 0 [Unformatted Track] (0)
32.0: (1 NOSYNC!) 0 [Unformatted Track] (0)
33.0: (1 NOSYNC!) 0 [Unformatted Track] (0)
34.0: (1 NOSYNC!) 0 [Unformatted Track] (0)
35.0: (1 NOSYNC!) 0 [Unformatted Track] (0)
36.0: (1 NOSYNC!) 0 [Unformatted Track] (0)
37.0: (1 NOSYNC!) 0 [Unformatted Track] (0)
38.0: (1 NOSYNC!) 0 [Unformatted Track] (0)
39.0: (1 NOSYNC!) 0 [Unformatted Track] (0)
40.0: (1 NOSYNC!) 0 [Unformatted Track] (0)
41.0: (1 NOSYNC!) 0 [Unformatted Track] (0)

[Pete Rittwage]

Looks good- it appears you have a different version of this than we have archived.  Please send me you original images!  :)

(pe...@c64preservation.com)

-

[Gene Buckle]

On Thu, 10 Feb 2011, Pete Rittwage wrote:

> Looks good- it appears you have a different version of this than we have
> archived. Please send me you original images! :)
>

It's entirely possible that the disk is just trashed, but at some point
all of the nibble images and their logs will be made available for
download. I probably have at least another 200 originals and probably
400-500 copies to image.

g.

[Nate Lawson]

On 2/10/2011 6:28 PM, Gene Buckle wrote:
> On Thu, 10 Feb 2011, Pete Rittwage wrote:
>
>> Looks good- it appears you have a different version of this than we have
>> archived. Please send me you original images! :)
>
> It's entirely possible that the disk is just trashed, but at some point
> all of the nibble images and their logs will be made available for
> download. I probably have at least another 200 originals and probably
> 400-500 copies to image.

This is exactly the reason why I've spent a decent amount of hobby time
over several years to implement this device. I hope everyone floods Pete
with images and we finally archive some of those rarities that will
disappear some day.

So if you like the ZoomFloppy, say "thanks" by sending him images!

--
Nate

[Nate Lawson]

On 2/10/2011 5:56 PM, Gene Buckle wrote:
> I just re-tried the same disk, this time with the only command line
> parameter being -e50 and it didn't crash.

Great, looks like a good read as far as the log goes.

> Here's the log:
>
> (Built Jan 13 2011 18:02:16) 'nibread -e50 adventure-creator.nib '
> 1.0: (3) 7830 (7830)
> 2.0: (2 NOSYNC!) 0 [Unformatted Track] (0)
> 3.0: (2 NOSYNC!) 0 [Unformatted Track] (0)
> 4.0: (2 NOSYNC!) 0 [Unformatted Track] (0)
> 5.0: (2 NOSYNC!) 0 [Unformatted Track] (0)

There's where it crashed before.

> 18.0: (2) 7170 [E5S18]
> (2) 7170 [E5S18]
> (2) 7170 [E5S18]

There's the protection, E5 on t18/s18.

--
Nate

[Gene Buckle]

My understanding is that images sent his way are not made available to
anyone else. I'm not doing all this work in order to see it vanish in a
black hole. I'll make the images available for download to anyone that
wants them. With any luck I'll get the first few batches posted this
weekend. The first is all Commodore branded media...

[Pete Rittwage]

They are available to other projects (GameBase, mainly) but I cannot allow downloads since I am not the copyright holder.  You are certainly welcome to make yours available yourself in that way.

-Pete

[Steve Gray]

Hi All,

 

I have posted a PRE-RELEASE of my CBMXfer 0.30.

 

There is support for NIBTOOLS reading and writing, and I am looking for people who can try it and provide feedback for me. I do not have a drive with a parallel cable so am unable to test the nibtools features myself. I do have a parallel cable on order from Peter Schepers.

 

In the meantime any comments or suggestions are welcome. Please let me know if you like the new look.

 

http://www.6502.org/users/sjgray/software/cbmxfer/cbmxfer.html

 

Steve

[Gerrit Hansen]

Am 10.02.2011 04:25, schrieb Gene Buckle:
> SB error in xum1541_control_msg: libusb0-dll:err [control_msg] sending
> control
> message failed, win error: The device does not recognize the command.

That's funny, I had exactly the same error-looping when trying nibwrite!
I'm glad to know it wasn't only me after all.

Gerrit

[Gerrit Hansen]

Hi!

Thank you very much, didn't expect that to happen really after my vague
suggestion. Well looks good to me so far but I'm unable to test as you
know. Will do that as soon as I'm able to again.

Gerrit

Am 11.02.2011 18:01, schrieb Steve Gray:
> Hi All,
> I have posted a PRE-RELEASE of my CBMXfer 0.30.
> There is support for NIBTOOLS reading and writing, and I am looking for
> people who can try it and provide feedback for me. I do not have a drive
> with a parallel cable so am unable to test the nibtools features myself.
> I do have a parallel cable on order from Peter Schepers.
> In the meantime any comments or suggestions are welcome. Please let me
> know if you like the new look.
> http://www.6502.org/users/sjgray/software/cbmxfer/cbmxfer.html
> Steve
>
>

> *From:* Steve Gray <sjg...@rogers.com>
> *To:* zoomflop...@googlegroups.com
> *Sent:* Tue, February 8, 2011 10:33:02 AM
> *Subject:* Re: First tests, CBMXfer

>
> Pete,
> Perhaps keeping it in strickly for the speed benefit and the
> flexibilty of using one command for multiple formats (similar to how
> CBMXfer will integrate OpenCBM, VICE, CBMLink, and Nibtools into one
> interface)...
> I have been working on a major update to CBMXfer to support nibtools
> and I am about 95% complete functionality-wise. Just doing some work
> on cleaning up the code and testing.
> Steve
>
>

> *From:* Pete Rittwage <ritt...@gmail.com>
> *To:* zoomflop...@googlegroups.com
> *Sent:* Sat, February 5, 2011 2:57:25 PM
> *Subject:* Re: First tests, CBMXfer

[Steve Gray]

Any feedback is appreciated, so even if you play with some of the other features
for now that's great.

Some things I am considering working on:

* Progress bar for copy operations. I will probably have to monitor the output
somehow taking into account the various options and assuming no errors.
* Cancel button for copy operations. Not sure how I will do this in VB6...
* Separate X-Cable and Zoom Floppy windows. Currently I do NOT add the -@
command to specify the cable. not sure what demand there is for this.
* Additional ML disassembler options. Perhaps converting known addresses to
labels (ie: JSR PRINT) and labelling destinations of branch instructions.
* Better support for C64 characters in BASIC viewer.
* Support for additional BASIC dialects (ie: Simon's BASIC)
* Support for 1581 directories
* Additional CBMLink options
* File and conversion options... unlynx, picture conversions, nibconvert...

Of course, feedback will determine what gets done ;-)

Steve

----- Original Message ----
> From: Gerrit Hansen <fire...@animexx.de>
> To: zoomflop...@googlegroups.com
> Sent: Fri, February 11, 2011 1:21:06 PM
> Subject: Re: First tests, CBMXfer
>

[Gene Buckle]

http://www.geneb.org/cbm_disks/nib_images/

There's roughly 300 images there. Have at guys. Pass 'em around and let
folks know where they can be downloaded.

g.

[Klotz]

Hi Steve.

First of all thanks for adding nibtools support to cbmxfer. Much
appreciated!
I did only a few tests now and creating nib files seem to work
flawlessly. But the option 'create G64' doesn't work for me. First I
have to change the filename from nib to g64. Floppy motor starts for a
second and then stops again. No result. If I do not rename the file
from nib to g64 I'm just getting another nib, without a g64. Didn't test
the option 'create D64'.
What I'd like to see is to create both, nib and g64, in one row if
possible. Like doing a nibread and afterwards perform a nibconv with the
same filename (except file-extension of course). Would this be possible?
Thanks for your effort.

Regards,
Christoph

[Steve Gray]

Christoph,

Thanks for the feedback. I will check the G64 option code. I had the three
options created before I heard D64 support was removed. I don't have experience
with nib files. Do most people create nib then convert to G64 or D64, or do they
make G64 directly? I can change the radio buttons to check boxes, nibread the
disk then do nibconv to G64 and/or D64 if checked, then delete the nib file if
it is not checked.

Do you have an opinion about the nib option checkboxes? do I need
more/different?

Steve

----- Original Message ----
> From: Klotz <psycho...@gmx.de>
> To: zoomflop...@googlegroups.com

[Nate Lawson]

On 2/12/2011 5:46 AM, Steve Gray wrote:
> Christoph,
>
> Thanks for the feedback. I will check the G64 option code. I had the three
> options created before I heard D64 support was removed. I don't have experience
> with nib files. Do most people create nib then convert to G64 or D64, or do they
> make G64 directly? I can change the radio buttons to check boxes, nibread the
> disk then do nibconv to G64 and/or D64 if checked, then delete the nib file if
> it is not checked.

nibread foo.nib # Creates the .nib file
nibconv foo.nib foo.g64 # creates g64 from nib
nibconv foo.nib foo.d64 # creates d64 from nib, lossy

I don't know anyone who creates g64 directly, best to use nib first.

--
Nate

[Nate Lawson]

Please give details of your nibwrite problem. What disk were you
writing? Where did it fail?

--
Nate

[Gerrit Hansen]

I honestly don't remember, sorry. It had the above error message looping
at some time with every .nib file write I tried and it happened right
where the tool made a 'reset device' or something like that I think.
But keep in mind that my ZF was unusable shortly after that as I told
here before, so maybe it's connected to that and this error was just
another symptom of the same problem with my ZF itself after all, I don't
know for sure.

Gerrit

[DMackey]

On Feb 11, 9:23 am, Gene Buckle <ge...@deltasoft.com> wrote:
> On Thu, 10 Feb 2011, Nate Lawson wrote:
> > On 2/10/2011 6:28 PM, Gene Buckle wrote:
> >> On Thu, 10 Feb 2011, Pete Rittwage wrote:
>
>
> My understanding is that images sent his way are not made available to
> anyone else.  I'm not doing all this work in order to see it vanish in a
> black hole.  I'll make the images available for download to anyone that
> wants them.  With any luck I'll get the first few batches posted this
> weekend.  The first is all Commodore branded media...

Gene, Much appreciated.

<Other comment removed....>

[Nate Lawson]

Oh, sorry. Yes, I think this is a completely separate matter and your ZF
got zapped somehow. Have you contacted Jim for a replacement?

--
Nate

[Steve Gray]

Thanks. I have changed CBMXfer to do this now, and will prepare another
pre-release. Do I need to do anything special for "NBZ" format?
Should I have separate option switches for reading and writing?

Steve

----- Original Message ----
> From: Nate Lawson <na...@root.org>
> To: zoomflop...@googlegroups.com
> Sent: Sat, February 12, 2011 1:01:58 PM
> Subject: Re: First tests, CBMXfer
>

[Nate Lawson]

nbz is just gzipped nib. I personally don't like it so I just write a
.nib and then if I have a bunch, zip them up. But you can write out .nbz
instead of .nib if you want.

nibread and nibwrite do have different options, but you don't need to
export too many of them to start with. The only one you probably need is
"-D9" (or 10, etc.) for selecting an alternate device. That and "-e40"
or whatever for nibread (increase error retry count from 10).

-Nate

[Steve Gray]

Hi,

----- Original Message ----
> From: Nate Lawson <na...@root.org>
> To: zoomflop...@googlegroups.com
> Sent: Sat, February 12, 2011 7:25:36 PM
> Subject: Re: First tests, CBMXfer
>

> nbz is just gzipped nib. I personally don't like it so I just write a
> .nib and then if I have a bunch, zip them up. But you can write out .nbz
> instead of .nib if you want.

So just changing the extension passed to nibread will select it, or do I need a
switch?

> nibread and nibwrite do have different options, but you don't need to
> export too many of them to start with. The only one you probably need is
> "-D9" (or 10, etc.) for selecting an alternate device. That and "-e40"
> or whatever for nibread (increase error retry count from 10).

The device is already specified even if D8. There is an additional option string
area where you can specify any switches you want, but do you think -e should be
a pre-defined check-box option? I tried to include checkboxes for any options
that were simple on/off type switches and left the options with parameters as
something you can add in the textbox area.
 
Steve

[Nate Lawson]

On 2/12/2011 4:37 PM, Steve Gray wrote:
>> From: Nate Lawson <na...@root.org>

>>
>> nbz is just gzipped nib. I personally don't like it so I just write a
>> .nib and then if I have a bunch, zip them up. But you can write out .nbz
>> instead of .nib if you want.
>
> So just changing the extension passed to nibread will select it, or do I need a
> switch?

Yes.

>> nibread and nibwrite do have different options, but you don't need to
>> export too many of them to start with. The only one you probably need is
>> "-D9" (or 10, etc.) for selecting an alternate device. That and "-e40"
>> or whatever for nibread (increase error retry count from 10).
>
> The device is already specified even if D8. There is an additional option string
> area where you can specify any switches you want, but do you think -e should be
> a pre-defined check-box option? I tried to include checkboxes for any options
> that were simple on/off type switches and left the options with parameters as
> something you can add in the textbox area.

That is fine for now. Error retry count is common enough due to bad
disks that you may want to make it its own textbox in the settings area
or something. Suggestion:

Error retries: 10

The user can edit it to be something other than 10 if they want. The -e
flag only matters for nibread.

--
Nate

[Gerrit Hansen]

Yes, we agreed that I sent him mine so he could take a look at it.

Gerrit

[Steve Gray]

Hi,

I have released CBMXfer 0.30 pr2. This version is a little more stable and now
supports NIB/NBZ creation followed by conversion to G64/D64, and has the -e
retries option. I am still getting the hang of things. You can click on a NIB
file then click "view" and it will convert to D64 (after prompting) so you can
view the directory and/or tranfer files from within. 

I am still looking for additional testers and feedback...
http://www.6502.org/users/sjgray/software/cbmxfer/cbmxfer.html

Steve

----- Original Message ----
> From: Steve Gray <sjg...@rogers.com>
> To: zoomflop...@googlegroups.com
> Sent: Sat, February 12, 2011 7:37:56 PM
> Subject: Re: First tests, CBMXfer
>

[Gene Buckle]

I was informed yesterday by a user on the #c64friends IRC channel that I
shouldn't use nibread on non-protected disks. Some kind of corruption
could occur.

Is there any basis in fact to this? If so, what's the issue?

FYI, I uploaded another 150+ images yesterday - they're in 11feb11-2.
http://www.geneb.org/cbm_disks/nib_images

[Nate Lawson]

On 2/14/2011 11:34 AM, Gene Buckle wrote:
> I was informed yesterday by a user on the #c64friends IRC channel that I
> shouldn't use nibread on non-protected disks. Some kind of corruption
> could occur.
>
> Is there any basis in fact to this? If so, what's the issue?

No, there is no problem with this. nibread is faster than even parallel
d64copy and the resulting d64 is identical.

> FYI, I uploaded another 150+ images yesterday - they're in 11feb11-2.
> http://www.geneb.org/cbm_disks/nib_images

Great, thanks.

--
Nate

[Gene Buckle]

On Mon, 14 Feb 2011, Nate Lawson wrote:

> On 2/14/2011 11:34 AM, Gene Buckle wrote:
>> I was informed yesterday by a user on the #c64friends IRC channel that I
>> shouldn't use nibread on non-protected disks. Some kind of corruption
>> could occur.
>>
>> Is there any basis in fact to this? If so, what's the issue?
>
> No, there is no problem with this. nibread is faster than even parallel
> d64copy and the resulting d64 is identical.
>

Ahh, ok. Thanks.

>> FYI, I uploaded another 150+ images yesterday - they're in 11feb11-2.
>> http://www.geneb.org/cbm_disks/nib_images
>
> Great, thanks.

You're quite welcome. I'm happy to do it. Nothing like feeding 27-25
year old disks to a 25 year old drive. :) Fortunately I've got plenty of
spare drives if I manage to shove the current one of this mortal coil. :)

Best guess, I've probably got 400 or so "regular" disks to dive through.
After those are done, I'd be willing to scan media that folks can't do
themselves for whatever reason.

[Klotz]

Hi,
I've just tested the 0.30 pr2 and unfortunately it doesn't work here. In
the options I checked boxes for creating both nib and g64. And then I
start transfering. Enter filename (without extension) and off we go.
Everything seems to work, floppy sounds like doing a nib. And when it
comes to the end of transfering, where nibread does the drive-reset (I
guess) CBMxfer gives an error message: "Sorry, it appears the
'C:\folder\folder\xxxx.nib' file was not created"
But both log and nib have been created in that folder.

Christoph

[Steve Gray]

Hi Christoph,

So you are saying the NIB and LOG file are created, but that the program
indicates that the NIB is not there. Did you "refresh" the files list. Does the
commandline look correct? Hmm... obviously the process aborts before
NIBCONV'ing to G64, but it's strange that it cannot see the file....  I
appreciate the feedback. I am still waiting for my parallel cable to arrive.
I'll take another look, unfortunately without the cable I can't create a NIB to
test..

Do the NIBTools options look flexible enough? Any other thoughts, not
necessarily on the nibtools features?

Steve

----- Original Message ----
> From: Klotz <psycho...@gmx.de>
> To: zoomflop...@googlegroups.com

[Nate Lawson]

On 2/18/2011 2:14 PM, Steve Gray wrote:
> I'll take another look, unfortunately without the cable I can't create a NIB to
> test..

You can always create a test build that just does "copy nul foo.nib" to
test the logic.

--
Nate

[Steve Gray]

Nate,

This seems like a timing thing. Yes, I can create a dummy NIB but that won't
simulate the exact shell process. It seems the shell is returning before the
process is complete. Either that or my routine to check for files is wrong...
sometimes there's too many darn quotes on the command line and maybe they are
passed in by mistake. That's why I was asking if the commandline looks correct.

Steve

----- Original Message ----
> From: Nate Lawson <na...@root.org>
> To: zoomflop...@googlegroups.com
> Sent: Fri, February 18, 2011 5:30:18 PM
> Subject: Re: First tests, CBMXfer
>

[Steve Gray]

Well, I discovered if I copy a file called "dummy.nib" then go through the
motions of creating an image with the same name the invisible CMD output window
is stuck at an "overwrite(y/n)?" prompt. That leads to the discovery that there
is no automatic overwritting option for nibread... so I need to check for file
exist then prompt for overwriting and delete the file if necessary. Silly things
like that... oh the joys of shelling out to commandline utiltities ;-)

Found a few more problems with nib options not getting set properly, extra
spaces in the command lines, etc.... anyway, will try to put together prerelease
V3 later tonight if I have time.

Steve

----- Original Message ----
> From: Nate Lawson <na...@root.org>
> To: zoomflop...@googlegroups.com
> Sent: Fri, February 18, 2011 5:30:18 PM
> Subject: Re: First tests, CBMXfer
>

[Steve Gray]

Hi All,

Ok, release 3 is up. I'm hoping this will work... ;-)

Also, for those 2 or 3 users of the 1581 drive... Partitions are now supported
in the x-cable window. You can select a partition and return to root partition.
Note: you won't see the option buttons until you read in a 1581 directory.

[Nate Lawson]

Ah. Yeah, nibtools is really inflexible and should really be using
getopt(), not this hand-rolled parsing. In particular, you should be
careful of:

* Don't put a space between flag and arg ("-D8", not "-D 8")
* Prompts to overwrite but no -f flag or equivalent to override this
* Some flags can cause read problems (e.g., nibread -d) on some disks

[Klotz]

Hi Steve.

When I'm trying to make a nib-file I'm getting 'Run-time error 53: file
not found' after I entered the filename. No drive activity at all.

[Steve Gray]

I must have disabled error checking somewhere by mistake. That shouldnt happen. Does cbmxfer close completely after that?

Just to be sure though, do you have nib read.exe and nibconv.exe in the cbmxfer directory? Could you enable logging and tell me if the nibread command gets written to the log.

Steve

[Klotz]

Yes, all files are in the same folder and nibread command is not written
to the log. And you are right, cbmxfer closes after that.

[Gene Buckle]

http://www.geneb.org/cbm_disks/nib_images - another 274 images in the
14feb11 directory. Enjoy!

[Nate Lawson]

Gene, a few comments based on browsing these. Thanks for all your work.

* Can you at least add a .zip of the files in each dir? That would save
you some bandwidth.

* Some images read on Feb 6 and some of Feb 7 are bad because of the
"-d8" flag. The "-d" flag only works on CBM-formatted disks, not
protected ones. Feb 4 is ok because all of those are unprotected (except
Deadline, dunno).

Beachhead is bad (lots of "Non-CBM (4a/E2)(4a/E2)" on regular tracks)
Family Feud is fine (no protection)
Paperback Writer is questionable.

Easiest would be to grep through the .log files for '-d8' and reimage
any protected titles in that list.

* Some of your dir listings failed. For example, feb 14 54.txt:
"74,drive not ready,00,00". This disk seems to be unformatted (blank)
based on the .log file. Others: 62.txt, 82, 192, and 277.

http://www.geneb.org/cbm_disks/nib_images/14feb11/0054.log

You might want to grep through those .txt files and redo any dir
listings that have an error or remove blank images.

Thanks!

[Gene Buckle]

On Sat, 19 Feb 2011, Nate Lawson wrote:

> Gene, a few comments based on browsing these. Thanks for all your work.
>
> * Can you at least add a .zip of the files in each dir? That would save
> you some bandwidth.
>

I'll see if I can find some time to do that.

> * Some images read on Feb 6 and some of Feb 7 are bad because of the
> "-d8" flag. The "-d" flag only works on CBM-formatted disks, not
> protected ones. Feb 4 is ok because all of those are unprotected (except
> Deadline, dunno).
>

FFFFFFFFFFUUUUUUUU.....

> Easiest would be to grep through the .log files for '-d8' and reimage
> any protected titles in that list.
>

Yargh. Ok. :)

If the disk has a full name instead of a number, it's been scanned from an
original, labeled disk. I assumed that all of those were copy protected.
I'm going to be hugely un-amused if I have to reimage all of them.
Granted, it's my fault for mis-reading the options, but in my haste, I
never would have thought it worked the way it did - using -d for one thing
and -D to assign the drive letter is Hugely F*cking Stupid. Period.
I'll take half the blame. :D

> * Some of your dir listings failed. For example, feb 14 54.txt:
> "74,drive not ready,00,00". This disk seems to be unformatted (blank)
> based on the .log file. Others: 62.txt, 82, 192, and 277.
>
> http://www.geneb.org/cbm_disks/nib_images/14feb11/0054.log
>
> You might want to grep through those .txt files and redo any dir
> listings that have an error or remove blank images.
>

They'll just be deleted. I have NO idea what disk matches what number. I
would check the images to make sure that they're indeed bad - there were
times that I re-used a disk number if the one originally fed to the drive
was shedding oxide (a few of those in this batch) or were otherwise
un-usable.

[Nate Lawson]

On 2/19/2011 9:42 AM, Gene Buckle wrote:
> On Sat, 19 Feb 2011, Nate Lawson wrote:
>> * Some images read on Feb 6 and some of Feb 7 are bad because of the
>> "-d8" flag. The "-d" flag only works on CBM-formatted disks, not
>> protected ones. Feb 4 is ok because all of those are unprotected (except
>> Deadline, dunno).
>>

>> Easiest would be to grep through the .log files for '-d8' and reimage
>> any protected titles in that list.
>>
> Yargh. Ok. :)
>
> If the disk has a full name instead of a number, it's been scanned from
> an original, labeled disk. I assumed that all of those were copy
> protected. I'm going to be hugely un-amused if I have to reimage all of

You can tell pretty easily by scanning the .log file. If it is 35 tracks
only (tracks 36+ unformatted) and 100% GCR match, no errors, then it is
likely unprotected. Good examples:

http://www.geneb.org/cbm_disks/nib_images/06feb11/2-on-one-hunter-patrol-and-ad-infinitum.log
http://www.geneb.org/cbm_disks/nib_images/06feb11/action-thrillers.log

This is probably protected. Note track 36 and 18 errors.

http://www.geneb.org/cbm_disks/nib_images/06feb11/championship-boxing.log

Definitely protected, need reimaging:

http://www.geneb.org/cbm_disks/nib_images/06feb11/ms-pacman1.log
http://www.geneb.org/cbm_disks/nib_images/06feb11/pole-position.log
http://www.geneb.org/cbm_disks/nib_images/06feb11/robocop.log

If it has lots of "Non-CBM", it is questionable and should probably just
be reimaged:

http://www.geneb.org/cbm_disks/nib_images/06feb11/2-on-one-bmx-trials-and-1985.log

For that title, it's likely these are just unused garbage and the real
data is tracks 10-35, but no way to tell easily.

Also questionable. The error on t31 is probably just bad media but could
be error-based protection. This is probably a good image though.

http://www.geneb.org/cbm_disks/nib_images/06feb11/double-dare-side1.log

Also some images appear to be truncated. This was probably the watchdog
resetting your ZF:

http://www.geneb.org/cbm_disks/nib_images/06feb11/wheel-of-fortune-side-1.log

All the above are just a few examples; I didn't exhaustively review things.

> them. Granted, it's my fault for mis-reading the options, but in my
> haste, I never would have thought it worked the way it did - using -d
> for one thing and -D to assign the drive letter is Hugely F*cking
> Stupid. Period.
> I'll take half the blame. :D

Yeah, I've been harassing Peter to add getopt.c

>> * Some of your dir listings failed. For example, feb 14 54.txt:
>> "74,drive not ready,00,00". This disk seems to be unformatted (blank)
>> based on the .log file. Others: 62.txt, 82, 192, and 277.
>>
>> http://www.geneb.org/cbm_disks/nib_images/14feb11/0054.log
>>
>> You might want to grep through those .txt files and redo any dir
>> listings that have an error or remove blank images.
>>
> They'll just be deleted. I have NO idea what disk matches what number.
> I would check the images to make sure that they're indeed bad - there
> were times that I re-used a disk number if the one originally fed to the
> drive was shedding oxide (a few of those in this batch) or were
> otherwise un-usable.

Deleting is fine. The cited images just look blank.

--
Nate

[Steve Gray]

Yes, I had commented out some error trapping. I've made a quick 3B version. Can
you give it a try?

Steve

----- Original Message ----
> From: Klotz <psycho...@gmx.de>
> To: zoomflop...@googlegroups.com

[Alexander Oberhuber]

Nate Lawson schrieb am 18:24 19.02.2011 :

>Paperback Writer is questionable.

I know the protection very well. It has a foreign disk format with 1
sync per track.
Do you need another image? I have the original.
Tell me what command line to "prefer" to get a "proper" image.

ATT

[Nate Lawson]

No flags or just "-e50". That increases the error retry count, which may
be necessary for marginal media. I've had that work where the default
(10 I think) did not.

--
Nate

[Steve Gray]

Hi All,

I finally got my parallel cable and installed it in one of my 1541 drives. Had
to fix a couple other minor bugs but it is now tested and working with the Zoom
Floppy and NIBTOOLS!!!  I have released CBMXfer 0.30PR4. Please give it a try.

http://www.6502.org/users/sjgray/software/cbmxfer/cbmxfer.html

I will be working on updating the documentation now that the features are
stabilizing. If you have comments/feedback please email me or post them here or
on Lemon64.

Steve

PS: I was disappointed that NIBTOOLS commands do not write output until all is
complete. This means I am unable to provide a progress bar like I can for D64's
made with "d64copy.exe".... sorry

[Nate Lawson]

On 2/22/2011 9:54 PM, Steve Gray wrote:
> I finally got my parallel cable and installed it in one of my 1541 drives. Had
> to fix a couple other minor bugs but it is now tested and working with the Zoom
> Floppy and NIBTOOLS!!! I have released CBMXfer 0.30PR4. Please give it a try.
>
> http://www.6502.org/users/sjgray/software/cbmxfer/cbmxfer.html

Great stuff, thanks for the work!

> PS: I was disappointed that NIBTOOLS commands do not write output until all is
> complete. This means I am unable to provide a progress bar like I can for D64's
> made with "d64copy.exe".... sorry

I think it may use printf, which is buffered. All it would need to do is
fcntl to set unbuffered on stdout.

--
Nate

[Steve Gray]

Hi,

Just a note to say I've posted the "official" CBMXfer 0.30 release (no longer
pre-release) on my web page. I hope everyone likes it. This release now includes
support for all Vice 2.3 emulators, and includes a new image tab in the viewer
to view many Commodore picture formats. Of course, Nibtools is fully supported.

As usual, feedback, complaints, comments, feature requests are welcome.

Steve

----- Original Message ----
> From: Nate Lawson <na...@root.org>
> To: zoomflop...@googlegroups.com
> Sent: Wed, February 23, 2011 3:31:23 AM
> Subject: Re: First tests, CBMXfer
>

[Nate Lawson]

Thanks for all your work on this!

[Steve Gray]

You're welcome. This was an interesting update for me. I learned some new things
along the way. So far not much feedback regarding features or bugs so I hope at
least a few people find it useful... ;-)

Steve

----- Original Message ----
> From: Nate Lawson <na...@root.org>
> To: zoomflop...@googlegroups.com
> Sent: Sun, March 20, 2011 3:09:55 PM
> Subject: Re: First tests, CBMXfer
>

[Steve Gray]

Hi All,

Just a status update... I finally have the IEEE connector installed on my ZF,
have flashed the firmware, and updated OpenCBM. I'm happy to report I made my
first D82 image using CBMXfer and an SFD-1001 drive tonight. I am currently
figuring out all the options for the new commandline D82copy and adding
additional code to determine what drive is connected etc.  If anyone is
interested in trying the latest CBMXfer test-builds drop me a line.

[Nate Lawson]

FYI, we've not yet officially released the new version of the IEEE code.
In particular, I plan to provide a standalone firmware upgrade utility
to make upgrades a one-step process.

Anyone who upgrades their firmware via the developer route is
responsible for fixing it themselves if the upgrade doesn't work. I
don't want to support people having to short various connectors together
to fix half-flashed boards.

So if you're not willing to be responsible for fixing any problems with
updating to development firmware, don't upgrade until an official
release is provided.

Thanks,
Nate

--
Nate

[Steve Gray]

Good advice. Yes, firmware upgrades can be tricky. I'm hoping to get a little jump-start with cbmxfer so hopefully it will be ready in time for the official release. Diddl was nice enough to help me past a few roadblocks, so it will definitely be easier with a dedicated updated utility.

Steve

[zapposh]

Hi,

I have the exact same issue with certain disks. 

All seems to be running fine until the end of creating the .nib, but in the end the error message "cbmxfer sorry it appears the xxx.nib file was not created" pops up.

No files are actually created as the tool aborts the process.

zapp

[me...@gmx-topmail.de]

Hi zapp.

 

Have you ever tried it without cbmxfer, i.e. directly calling nibread from the commandline? There is probably more or other debug output there that could help find the problem.

 

Kind regards

 

Arnd

 

Gesendet: Samstag, 06. April 2013 um 11:37 Uhr
Von: zapposh <zap...@gmail.com>
An: zoomflop...@googlegroups.com
Betreff: Re: First tests, CBMXfer

--
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.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[BPM Marketing]

Hi Arnd,

Thanks for your reply. I have never tried it yet from the commandline. I will give it a go and post how that went.

Kind regards,

zapp

--
You received this message because you are subscribed to a topic in the Google Groups "ZoomFloppy Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/zoomfloppy-users/lgFBaNauv9A/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to zoomfloppy-use...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Cordialement, Mit freundlichen Grüssen, Best Regards,

--

Sebastian Kostka

Online Marketing Voodoo

 

www.bpm-lux.com | www.rt-log.com

E mark...@bpm-lux.com

 

BPM 100.000 | RT-Log S.A. | 34, rue Gabriel Lippmann | L-5365 Munsbach | Luxembourg

 

R.C. B 100254 Luxembourg - VAT Nr. LU-20059679

MD Robert G. Thiemann

[Sebastian Kostka]

Hi,

Made a very simple run from the command line. As before, works fine with 99% of the disks. Here is a case where is does not:

C:\opencbm\bin>nibread -s kermit

nibread - Commodore 1541/1571 disk image nibbler

(C) C64 Preservation Project

http://c64preservation.com

Revision 528 - Built Sep 24 2011 22:38:17

* Use 1571 SRQ Support

Drive Version: 73,CBM DOS V3.0 1571,00,00

Drive type: 1571

Bumping...

Initializing

Sending 1571 SRQ support code...

Uploading floppy-side code...done.

Starting custom drive code...Started!

Testing communication...done.

Passed initial communication test.

Testing code upload...done.

Passed code verification test.

Passed all basic port checks.

18.0: (2)

Cosmetic Disk ID: 'GJ'

Format Disk ID: 'GJ'

 1.0: (3) H 7798

 2.0: (3) H 7797 (bad/weak:1)

 3.0: (3) H 7800

 4.0: (3) H 7810

 5.0: (3) H 7792

 6.0: (3) H 7803

 7.0: (3) H 7795

 8.0: (3) H 7790

 9.0: (3) H 7816

10.0: (3) H 7798

11.0: (3) H 7798 (bad/weak:1)

12.0: (3) H 7806

13.0: (3) H 7801

14.0: (3) H 7812

15.0: (3) H 7799

16.0: (3) H 7793

17.0: (3) H 7803 [E5S13][E5S15]

      (3) H 7801 [E5S13]

      (3) H 7801 [E5S13][E5S15]

      (3) H 7805 [E5S13]

      (3) H 7801 [E5S13][E5S15]

      (3) H 7801 [E5S13]

      (3) H 7802 [E5S13][E5S15]

      (3) H 7803 [E5S13]

      (3) H 7804 [E5S13][E5S15]

      (3) H 7802 [E5S13][E5S15]

      (3) H 7802 [E5S13][E5S15](bad/weak:4)

18.0: (2) H 6963

19.0: (2) H 6958

20.0: (2) H 6958

21.0: (2) H 6967

22.0: (2) H 6956 [E5S10]

      (2) H 6957 [E5S10]

      (2) H 6956 [E5S10]

      (2) H 6954 [E5S10]

      (2) H 6956 [E5S10]

      (2) H 6957 [E5S10]

      (2) H 6956 [E5S10]

      (2) H 6954 [E5S10]

      (2) H 6957 [E5S10]

      (2) H 6958 [E5S10]

      (2) H 6956 [E5S10](bad/weak:1)

23.0: (2) H 6959

24.0: (2) H 6954

25.0: (1) H 6577

26.0: (1) H 6582

27.0: (1) H 6584

28.0: (1) H 6584

29.0: (1) H 6579

30.0: (1) H 6576

31.0: (0) H 6225

32.0: (0) H 6254

33.0: (0) H 6241

34.0: (0) H 6247

35.0: (0) H 6234

36.0: (0!=2) H/S/R 8192 Long Read! [NDOS]

      (0!=2) H/S/R 8192 Long Read! [NDOS] (bad/weak:140)

37.0: USB error in xum1541_wait_status: libusb0-dll:err [_usb_reap_async] reapin

g request failed, win error: A device attached to the system is not functioning.

USB error in write cmd: libusb0-dll:err [_usb_reap_async] reaping request failed

, win error: A device attached to the system is not functioning.

Resetting drive...

USB error in xum1541_control_msg: libusb0-dll:err [control_msg] sending control

message failed, win error: A device attached to the system is not functioning.

On Sat, Apr 6, 2013 at 11:56 AM, <me...@gmx-topmail.de> wrote:

--
You received this message because you are subscribed to a topic in the Google Groups "ZoomFloppy Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/zoomfloppy-users/lgFBaNauv9A/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to zoomfloppy-use...@googlegroups.com.

[Peter Rittwage]

Nate and Arnd,

It appears that some kind of arrangement of unformatted data will cause a too-long delay somewhere and catch the ZoomFloppy watchdog?

-Pete

[me...@gmx-topmail.de]

Hi zapp,

 

you are using nibtools 528. Could you please download the latest revision 575 and try again?

 

Kind regards

 

Arnd

 

 

Gesendet: Samstag, 06. April 2013 um 16:05 Uhr
Von: "Sebastian Kostka" <zap...@gmail.com>

[Sebastian Kostka]

Thanks so much, it works with revision 575! It was the killer tracks.

Here is what the log looks like now with the same disk and same settings:

C:\opencbm\bin>nibread -s kermit

nibread - Commodore 1541/1571 disk image nibbler

(C) Peter Rittwage and the rest of the C64 Preservation Project team

http://c64preservation.com

Revision 2012 - Built Feb 23 2013 12:34:47

* Use 1571 SRQ Support

Drive Version: 73,CBM DOS V3.0 1571,00,00

Drive type: 1571

Bumping...

Initializing

Sending 1571 SRQ support code...

Uploading floppy-side code ($0427 bytes, $300-$727)...done.

Starting custom drive code...Started!

Testing communication...done.

Passed initial communication test.

Testing code upload...done.

Passed code verification test.

Passed all basic port checks.

18.0: (2)

Cosmetic Disk ID: '??'

Format Disk ID: 'GJ'

 1.0: (3) H/S 7797 [CBM OK]

 2.0: (3) H/S 7797 [CBM OK] (weakgcr:1)

 3.0: (3) H/S 7800 [CBM OK]

 4.0: (3) H/S 7808 [CBM OK]

 5.0: (3) H/S 7795 [CBM OK]

 6.0: (3) H/S 7807 [CBM OK]

 7.0: (3) H/S 7797 [CBM OK]

 8.0: (3) H/S 7790 [CBM OK]

 9.0: (3) H/S 7812 [CBM OK]

10.0: (3) H/S 7798 [CBM OK]

11.0: (3) H/S 7800 [CBM OK] (weakgcr:1)

12.0: (3) H/S 7809 [CBM OK]

13.0: (3) H/S 7801 [CBM OK]

14.0: (3) H/S 7806 [CBM OK]

15.0: (3) H/S 7803 [CBM OK]

16.0: (3) H/S 7792 [CBM OK]

17.0: (3) H/S 7804 [E5S13][E5S15]

      (3) H/S 7802 [E5S13]

      (3) H/S 7800 [E5S13][E5S15]

      (3) H/S 7801 [E5S13]

      (3) H/S 7801 [E5S13]

      (3) H/S 7801 [E5S13][E5S15]

      (3) H/S 7806 [E5S13]

      (3) H/S 7804 [E5S13]

      (3) H/S 7802 [E5S13]

      (3) H/S 7801 [E5S13]

      (3) H/S 7805 [E5S13] (weakgcr:1)

18.0: (2) H/S 6961 [CBM OK]

19.0: (2) H/S 6956 [CBM OK]

20.0: (2) H/S 6959 [CBM OK]

21.0: (2) H/S 6970 [CBM OK]

22.0: (2) H/S 6957 [E5S10]

      (2) H/S 6957 [E5S10]

      (2) H/S 6960 [E5S10]

      (2) H/S 6956 [E5S10]

      (2) H/S 6954 [E5S10]

      (2) H/S 6955 [E5S10]

      (2) H/S 6954 [E5S10]

      (2) H/S 6958 [E5S10]

      (2) H/S 6957 [E5S10]

      (2) H/S 6955 [E5S10]

      (2) H/S 6957 [E5S10] (weakgcr:1)

23.0: (2) H/S 6966 [CBM OK]

24.0: (2) H/S 6953 [CBM OK]

25.0: (1) H/S 6580 [CBM OK]

26.0: (1) H/S 6583 [CBM OK]

27.0: (1) H/S 6577 [CBM OK]

28.0: (1) H/S 6586 [CBM OK]

29.0: (1) H/S 6580 [CBM OK]

30.0: (1) H/S 6575 [CBM OK]

31.0: (0) H/S 6225 [CBM OK]

32.0: (0) H/S 6254 [CBM OK]

33.0: (0) H/S 6241 [CBM OK]

34.0: (0) H/S 6247 [CBM OK]

35.0: (0) H/S 6234 [CBM OK]

36.0: (0!=2) H/S/R 8192 Long Read! [NDOS]

      (0!=2) H/S/R 8192 Long Read! [NDOS]  (weakgcr:215)

37.0: (0!=2 KILLER) [Killer Track]

38.0: (1!=2 KILLER) [Killer Track]

39.0: (0!=2 KILLER) [Killer Track]

40.0: (0!=2) H/S/R 8192 Long Read! [NDOS]

      (0!=2) H/S/R 8192 Long Read! [NDOS]  (weakgcr:18)

41.0: (2 NOSYNC!) 0 [Unformatted Track]

Converting to NIB format...

Successfully parsed data to NIB format

Successfully saved file kermit.nbz

Resetting drive...

Cleaning up...

C:\opencbm\bin> 

Best regards,

zapp

[me...@gmx-topmail.de]

Hi Sebastian,

 

glad it works. Thank you for your feedback.

 

Kind regards

 

Arnd

 

Gesendet: Samstag, 06. April 2013 um 17:26 Uhr

Von: "Sebastian Kostka" <zap...@gmail.com>
An: zoomflop...@googlegroups.com

Betreff: Re: Re: First tests, CBMXfer

[Nate Lawson]

Yes, as Arnd pointed out that was fixed in a newer version of the 1571-SRQ protocol.

-Nate

[Sebastian Kostka]

Hi again,

I now have a similar problem (perhaps the same problem in fact. At least the error message I'm getting is the same as in the older nibtools release) in the recent nibtools version, with a different disk.

Here is the log.

Thanks

Sebastian

ps.: the error message is the same even without any of these options: -e[50] -s -V

C:\opencbm\bin>nibread -e[50] -s -V -k  1942

nibread - Commodore 1541/1571 disk image nibbler

(C) Peter Rittwage and the rest of the C64 Preservation Project team

http://c64preservation.com

Revision 2012 - Built Feb 23 2013 12:34:47

* Read retries set to 0

* Use 1571 SRQ Support

* Verbose mode on

* Disabling read of 'killer' tracks

Drive Version: 73,CBM DOS V3.0 1571,00,00

Drive type: 1571

Bumping...

Initializing

Sending 1571 SRQ support code...

Uploading floppy-side code ($0427 bytes, $300-$727)...done.

Starting custom drive code...Started!

Testing communication...done.

Passed initial communication test.

Testing code upload...done.

Passed code verification test.

Passed all basic port checks.

18.0: (2) [+D]

Cosmetic Disk ID: '☺☺'

Format Disk ID: '02'

 1.0: (3) [+D]H/S {cycle:5255a5654b9ca6}{sec0=4479;len=361} {gap=4479;len=453) (

sec0=gap) {align:525535294b9ca6}7782 [CBM OK] (weakgcr:1)

 2.0: (3) H/S {cycle:52552549529ca6}{sec0=7046;len=361} {gap=7046;len=453) (sec0

=gap) {align:5254a529529ca6}7783 [CBM OK]

 3.0: (3) H/S {cycle:5256b5a9539ca6}{sec0=1913;len=361} {gap=1913;len=453) (sec0

=gap) {align:5254b529539ca6}7782 [CBM OK]

 4.0: (3) H/S {cycle:525555654e9ca6}{sec0=4481;len=361} {gap=4481;len=453) (sec0

=gap) {align:525565294e9ca6}7782 [CBM OK]

 5.0: (3) H/S {cycle:5254f5494f9ca6}{sec0=7046;len=361} {gap=7046;len=453) (sec0

=gap) {align:525575294f9ca6}7783 [CBM OK]

 6.0: (3) H/S {cycle:5256e5a9569ca6}{sec0=1914;len=361} {gap=1914;len=453) (sec0

=gap) {align:5254e529569ca6}7781 [CBM OK]

 7.0: (3) H/S {cycle:5254d565579ca6}{sec0=4481;len=361} {gap=4481;len=453) (sec0

=gap) {align:5254f529579ca6}7782 [CBM OK] (weakgcr:1)

 8.0: (3) H/S {cycle:52549549499ca6}{sec0=7047;len=361} {gap=7047;len=453) (sec0

=gap) {align:5255a529499ca6}7784 [CBM OK]

 9.0: (3) H/S {cycle:5257b5a9599ca6}{sec0=1914;len=361} {gap=1914;len=453) (sec0

=gap) {align:5255b529599ca6}7783 [CBM OK] (weakgcr:1)

10.0: (3) H/S {cycle:5254b5655a9ca6}{sec0=4482;len=361} {gap=4482;len=453) (sec0

=gap) {align:525495295a9ca6}7784 [CBM OK] (weakgcr:1)

11.0: (3) H/S {cycle:5255b5495b9ca6}{sec0=7045;len=361} {gap=7045;len=453) (sec0

=gap) {align:525595295b9ca6}7782 [CBM OK]

12.0: (3) H/S {cycle:5257e5a94d9ca6}{sec0=1916;len=361} {gap=1916;len=453) (sec0

=gap) {align:5255e5294d9ca6}7783 [CBM OK]

13.0: (3) H/S {cycle:525565655d9ca6}{sec0=4479;len=361} {gap=4479;len=453) (sec0

=gap) {align:525555295d9ca6}7781 [CBM OK]

14.0: (3) H/S {cycle:5255e5495e9ca6}{sec0=7046;len=361} {gap=7046;len=453) (sec0

=gap) {align:5254d5295e9ca6}7784 [CBM OK] (weakgcr:1)

15.0: (3) H/S {cycle:5257d5a9559ca6}{sec0=1914;len=361} {gap=1914;len=453) (sec0

=gap) {align:5255d529559ca6}7779 [CBM OK]

16.0: (3) H/S {cycle:5257b5656a9ca6}{sec0=4477;len=361} {gap=4477;len=453) (sec0

=gap) {align:525725296a9ca6}7778 [CBM OK]

17.0: (3) H/S {cycle:5256b5496b9ca6}{sec0=7042;len=361} {gap=7042;len=453) (sec0

=gap) {align:525735296b9ca6}7779 [CBM OK] (weakgcr:1)

18.0: (2) [+D]H/S {cycle:52575555729ca6}{sec0=1515;len=361} {gap=1515;len=434) (

sec0=gap) {align:5256a529729ca6}6947 [CBM OK]

19.0: (2) H/S {cycle:5257a56d739ca6}{sec0=2961;len=361} {gap=2961;len=434) (sec0

=gap) {align:5256b529739ca6}6945 [CBM OK] (weakgcr:1)

20.0: (2) H/S {cycle:5256b55d6e9ca6}{sec0=4410;len=361} {gap=4410;len=435) (sec0

=gap) {align:525765296e9ca6}6949 [CBM OK]

21.0: (2) H/S {cycle:5256e54d6f9ca6}{sec0=5858;len=361} {gap=5858;len=435) (sec0

=gap) {align:525775296f9ca6}6949 [CBM OK] (weakgcr:1)

22.0: (2) H/S {cycle:525565c9769ca6}{sec0=0430;len=361} {gap=0430;len=434) (sec0

=gap) {align:5256e529769ca6}6947 [CBM OK]

23.0: (2) H/S {cycle:5257b579779ca6}{sec0=1878;len=361} {gap=1878;len=435) (sec0

=gap) {align:5256f529779ca6}6947 [CBM OK] (weakgcr:1)

24.0: (2) H/S {cycle:5256a569699ca6}{sec0=3324;len=361} {gap=3324;len=435) (sec0

=gap) {align:5257a529699ca6}6949 [CBM OK] (weakgcr:1)

25.0: (1) [+D]H/S {cycle:5256d55d799ca6}{sec0=4037;len=361} {gap=4037;len=431) (

sec0=gap) {align:5257b529799ca6}6569 [CBM OK] (weakgcr:1)

26.0: (1) H/S {cycle:5256d5397a9ca6}{sec0=5117;len=361} {gap=5117;len=430) (sec0

=gap) {align:525695297a9ca6}6569 [CBM OK]

27.0: (1) H/S {cycle:5257b5497b9ca6}{sec0=5844;len=361} {gap=5844;len=431) (sec0

=gap) {align:525795297b9ca6}6571 [CBM OK]

28.0: (1) H/S {cycle:5257e5296d9ca6}{sec0=6565;len=361} {gap=6565;len=430) (sec0

=gap) {align:5257e5296d9ca6}6570 [CBM OK]

29.0: (1) H/S {cycle:525555a97d9ca6}{sec0=0786;len=361} {gap=0786;len=430) (sec0

=gap) {align:525755297d9ca6}6567 [CBM OK]

30.0: (1) H/S {cycle:525725797e9ca6}{sec0=1510;len=361} {gap=1510;len=430) (sec0

=gap) {align:5256d5297e9ca6}6570 [CBM OK]

31.0: (0) [+D]H/S {cycle:5256b535759ca6}{sec0=1882;len=361} {gap=1882;len=442) (

sec0=gap) {align:5257d529759ca6}6218 [CBM OK]

32.0: (0) H/S {cycle:5265956e4a9ca6}{sec0=2243;len=361} {gap=2243;len=442) (sec0

=gap) {align:5265252a4a9ca6}6218 [CBM OK]

33.0: (0) H/S {cycle:5265956a4b9ca6}{sec0=2604;len=361} {gap=2604;len=442) (sec0

=gap) {align:5265352a4b9ca6}6218 [CBM OK]

34.0: (0) H/S {cycle:52659566529ca6}{sec0=2965;len=361} {gap=2965;len=442) (sec0

=gap) {align:5264a52a529ca6}6218 [CBM OK]

35.0: (0) H/S {cycle:52659526539ca6}{sec0=3326;len=361} {gap=3326;len=442) (sec0

=gap) {align:5264b52a539ca6}6218 [CBM OK]

36.0: (2 KILLER) [Killer Track]

37.0: USB error in xum1541_wait_status: libusb0-dll:err [_usb_reap_async] reapin

g request failed, win error: A device attached to the system is not functioning.

USB error in write cmd: libusb0-dll:err [_usb_reap_async] reaping request failed

, win error: A device attached to the system is not functioning.

Resetting drive...

USB error in xum1541_control_msg: libusb0-dll:err [control_msg] sending control

message failed, win error: A device attached to the system is not functioning.

C:\opencbm\bin>

[Nate Lawson]

What is the name of the disk and is it commercial? Is it 1942 the game?

I think you can work around this by removing the '-k' flag. Just "nibread -s 1942.nib"

-Nate