New 2.0 software release

[Nate Lawson]

I've just uploaded a new release of both OpenCBM and the ZoomFloppy firmware. It should be considered a beta that has had light testing. I'm looking for wider testing of these items:

- New nibread/nibwrite serial nibbling with a 1571 (credit Arnd Menge). It works for many 1571 drives, but not others.
- New IEEE-488 support (credit Thomas Winkler). It appears to be stable -- no known issues.
- Windows 2000 support. Should work there, although not yet tested. Mac and Windows 7 tested fine.
- General regression testing with various drives and usage

There's a new firmware update tool included to make this super easy. As always, read the included manual before charging into this.

http://root.org/~nate/c64/ZoomFloppy-Manual-2.0.pdf
http://root.org/~nate/c64/opencbm-ZoomFloppy-2.0-i386.zip

Mac/Linux users can build the firmware update tool from source. I haven't had time to integrate this into OpenCBM but am not averse to someone doing that work.

Full release notes in the README.txt:
v2.0 (2011/9/24) -- Many improvements and bugfixes.
* Add support for IEEE-488 drives.
Implemented by Thomas Winkler.
* Add experimental support for 1571 serial nibbling via the SRQ protocol.
Now you don't need a parallel cable with a 1571. Implemented by Arnd Menge.
* Add support for low-level drive analysis with a 1541 index-hole sensor.
This works only on drives with a parallel port and nibtools.
* Bugfix: cbmcopy -r or cbmread now no longer hangs at the end of a transfer
* Bugfix: don't reset the bus twice if previous command was interrupted and
this command is "cbmctrl reset".
* Bugfix: increase reset time to 100 ms to be sure all drives are reset.
* Linux build fix for more modern kernels

This release is in conjunction with ECCC 2011, which is wrapping up today. Congrats guys and hope everyone had a great time!

Thanks,
Nate

[Scott]

Nate, you rock! Thank you!!

[Nate Lawson]

On Sep 25, 2011, at 2:59 PM, Nate Lawson wrote:

> I've just uploaded a new release of both OpenCBM and the ZoomFloppy firmware. It should be considered a beta that has had light testing. I'm looking for wider testing of these items:
>
> - New nibread/nibwrite serial nibbling with a 1571 (credit Arnd Menge). It works for many 1571 drives, but not others.
> - New IEEE-488 support (credit Thomas Winkler). It appears to be stable -- no known issues.
> - Windows 2000 support. Should work there, although not yet tested. Mac and Windows 7 tested fine.
> - General regression testing with various drives and usage
>
> There's a new firmware update tool included to make this super easy. As always, read the included manual before charging into this.
>
> http://root.org/~nate/c64/ZoomFloppy-Manual-2.0.pdf
> http://root.org/~nate/c64/opencbm-ZoomFloppy-2.0-i386.zip

I've thought about this a bit more and think there may be a slight hiccup. I'm sick right now so I can't fix it but there's a workaround.

If you're using the existing ZF driver and run the updater tool, you may get a "device not recognized" popup for an "Atmel DFU" device. If you see this, just follow the instructions in the manual to install the ZoomFloppy driver for it as well. Then re-run the firmware update tool.

Another solution is to uninstall the old ZF driver from Device Manager before installing the new one. Then you won't have this issue.

If you're installing from scratch, you'll not have any issues I don't think.

Thanks,
-Nate

[Diddl]

How wonderful news! Will test it this week. Is there also S3 support
in OpenCBM.dll?


About ZIP: D82copy is dead, IMGCOPY works fine for D80, D81 and D82.


/Tommy

[Alexander Oberhuber]

Nate Lawson schrieb am 23:59 25.9.2011 :
>I've just uploaded a new release of both OpenCBM and the ZoomFloppy
>firmware. It should be considered a beta that has had light testing.
>I'm looking for wider testing of these items:
>
>- New nibread/nibwrite serial nibbling with a 1571 (credit Arnd
>Menge). It works for many 1571 drives, but not others.
>- New IEEE-488 support (credit Thomas Winkler). It appears to be
>stable -- no known issues.
>- Windows 2000 support. Should work there, although not yet tested.
>Mac and Windows 7 tested fine.
>- General regression testing with various drives and usage
>
>There's a new firmware update tool included to make this super easy.
>As always, read the included manual before charging into this.

This is great news!
Questions: a) How fast is the 1571 now in reading a normal
("1541-dos")-CBM diskside and transfering it to the PC?
b) What command line do I need to tell the cbmcopy tool to use the
SQR nibbling now?

[Peter Rittwage]

SRQ is only supported in nibread/nibwrite, not the standard OpenCBM toolset.  The switch to enable it is "-s"

-
Pete Rittwage
C64 Preservation Project
http://c64preservation.com

[Alexander Oberhuber]

Peter Rittwage schrieb am 16:17 26.9.2011 :
>SRQ is only supported in nibread/nibwrite, not the standard OpenCBM
>toolset. The switch to enable it is "-s"

I upgraded the firmware, upgraded the software and drivers, attached
my 1571, used the following commandline:

nibread.exe -s -D8 -I -d -e5 -k -E35 testfile.nib

Now it transfers a diskside in 13.5 seconds! And lets me transfer
several disks in a batch! Hooray!!!
Thanks a lot!

[Nate Lawson]

That's great, but I don't recommend a lot of those switches for ordinary users and protected disks. For example, it limits the last track to 35 whereas some protections go up to 40. Also, the default density flag causes problems on protected disks. But that's a very fast transfer approach for unprotected disks.

So for other 1571 users archiving disks, please keep the flags to just "-s" and maybe "-e50" if a disk has lots of errors. The latter causes it to retry to be sure an error is really there wasn't just a transient issue.

-Nate

[Nate Lawson]

No, I didn't import S3 yet. I'd like to give you more time to settle it and debug.

Can you tell me more about the d82copy problem? I don't have a IEEE drive so I couldn't test it. But I didn't change anything in there from stock OpenCBM git. Maybe you're saying that d82copy should not be built and people should just use imgcopy?

-Nate

[Jim Brain]

On 9/26/2011 10:43 AM, Nate Lawson wrote:
> Can you tell me more about the d82copy problem? I don't have a IEEE drive so I couldn't test it. But I didn't change anything in there from stock OpenCBM git. Maybe you're saying that d82copy should not be built and people should just use imgcopy?

I read it as the latter.

Jim

[Nate Lawson]

On Sep 26, 2011, at 8:43 AM, Nate Lawson wrote:
> No, I didn't import S3 yet. I'd like to give you more time to settle it and debug.
>
> Can you tell me more about the d82copy problem? I don't have a IEEE drive so I couldn't test it. But I didn't change anything in there from stock OpenCBM git. Maybe you're saying that d82copy should not be built and people should just use imgcopy?
>
> -Nate
>
> On Sep 26, 2011, at 12:55 AM, Diddl wrote:
>
>> How wonderful news! Will test it this week. Is there also S3 support
>> in OpenCBM.dll?
>>
>>
>> About ZIP: D82copy is dead, IMGCOPY works fine for D80, D81 and D82.

I don't see imgcopy in OpenCBM git. Do you have a patch for it somewhere? I guess this might be part of your S3 work?

Are you saying d82copy won't work at all, or just that it will be changing to imgcopy in the future? The latter is ok since we can do more frequent releases now that we have a firmware update tool.

-Nate

[Pontus Berg]

Nate, you are an iconic hero for your efforts here, so don't get me wrong for going amok here.

This drives me totally bananas. Tried uninstalling the old drivers and installing the new ones. Don't know why it chose to fight back but, it did.

Eventually it did work at one time and then I tried running the firmware updater.

Call me triggerhappy but I don't read through the documentation from A to Z and then do stuff. I fire away and read as I go along. I can hence tell you that on the instructions under "Update your firmware" finding "You should turn off all connected drives before running the update utility" as the last piece of advice works REALLY poorly on me. I only read this after going down like a lead zeppelin on the previous steps :-(

Now my device manager reports "Amtel firmware update device (ATmega32U2).

Now what?

/Pontus

2011/9/25 Nate Lawson <na...@root.org>

--
/Pontus Berg
 Mobile: +46 735 405099

 Skype: BacchusBerg

 ICQ: 109686

[Nate Lawson]

Heh, thanks for the (kind?) words.

What that means is that your ZoomFloppy is awaiting updates. Just re-run the firmware updater and it will write/verify the new firmware.

In particular, there are two phases to the update process. Phase 1 finds a ZoomFloppy, checks its reported version and the firmware file's version, and then sends it a command to go into update (DFU) mode. Phase 2 is a normal DFU update, where the firmware is erased, written, and verified, then the ZoomFloppy is reset back into its normal mode.

If something happens between Phase 1 and 2, you can just re-run the updater. It will look for ZF devices, find none, then look for DFU devices of the appropriate CPU type. If it finds one, it goes ahead and updates it as per Phase 2.

The updater tool may need some tweaking or additional delays added between Phase 1 and 2 because the OS needs to re-probe the "new" device on that port. Right now, I have the code try 30 times, waiting 1 second per try in between. If it doesn't find a DFU device after that, it gives up.

On Mac/Linux, which don't have to install a USB driver in order to access the "new" device, things work quickly and reliably. On Windows, you may need to re-run it a few times in some cases. It works for me on Windows 7 without having to re-run, but people have different speeds of computers, etc.

-Nate

[Pontus Berg]

If it's a prerequisite to shut off the drive(s) connected, can I suggest a check for this as a step within step 1, before going into DFU mode?

Running the command again won't play :-(

C:\OpenCBM>firmware-update.bat

finding and preparing device for update...

warning: no xum1541 found, continuing to look for devices in DFU mode

error: no devices found to update

... And then "Press any key to continue..." but in Swedish

Running it five times in a row makes no difference....

/Pontus

2011/9/26 Nate Lawson <na...@root.org>

[Pontus Berg]

OK, sorry to bother you all again but it seems the issue at hand was that that I tried running this from the USB port of my DELL screen.

Using one of the ports on the PC made update work properly and after reading ;-) I realise it was safe to run the updater again to validate the installation and this time it also reports back that the firmware it wants to install is not newer than the one already in place.

I do hope I am now back in business, and that I eventually can also run this over parallel.

Many thanks fort the effort!

/Pontus

2011/9/26 Pontus Berg <pon...@berg.to>

[Nate Lawson]

Thanks for the report. I'll reorder the instructions as you suggest.

I did successfully test both parallel read/write so you should be fine. You should be able to use this device through your monitor's USB.

I think what happened is that the new driver didn't overwrite the new. When you plugged it into a new port, you got the new driver as well. I will add a step to the manual to ask people to uninstall the old driver first, then this should work fine.

-Nate

[Nate Lawson]

Shutting off the drives is more for safety. I have successfully run updates with drives attached and on.

-Nate

[Thomas Winkler]

D82COPY should work. But we spoke about to give up d82copy and support only new imgcopy. And make a stub for d64copy,


Imgcopy is not finished yet. Currently ist supports D80, D82 and D81 only. But it solves many bugs from D82COPY, so it is better not to use D82COPY but IMGCOPY instead of.


I could send you IMGCOPY if you want, but I think it is better to integrate D64COPY first.

2011/9/26 Nate Lawson <na...@root.org>

[Nate Lawson]

Ok, thanks for the update. Perhaps someone else can integrate imgcopy and S3. But if not, I may do it.

[Jani]

Hello Zoomfloppy users.

Thank Nate for the updates, excellent work!

A question that might be a little off topic, but does this version of opencbm work with the "old" X* cables ?. I have zoomfloppy but also a couple of machines with XMP-cables.

Regards

Jani

---

From: Nate Lawson <na...@root.org>
To: ZoomFloppy Users <zoomflop...@googlegroups.com>
Sent: Sunday, September 25, 2011 11:59 PM

Subject: New 2.0 software release

[Nate Lawson]

It should work for that, although I haven't tested it. I did make sure to build all the device drivers, etc.

On Sep 27, 2011, at 1:44 PM, Jani wrote:

> Hello Zoomfloppy users.
> Thank Nate for the updates, excellent work!
>
> A question that might be a little off topic, but does this version of opencbm work with the "old" X* cables ?. I have zoomfloppy but also a couple of machines with XMP-cables.
>
> Regards
> Jani
>

[Peter Rittwage]

It does work, but you have to reinstall without the "xum1541" first.

instcbm -r
instcbm
instcbm xum1541

Both will then work.  By default, it will use the Zoom, so to use parallel you would issue the '-@' switch, like this:

nibread image.nib - read from drive attached to Zoom
nibread -@xa1541 image.nib  - read from drive attached to parallel

-Pete

[Spiro Trikaliotis]

Hello,

* On Tue, Sep 27, 2011 at 05:07:51PM -0400 Peter Rittwage wrote:
> It does work, but you have to reinstall without the "xum1541" first.
> instcbm -r
> instcbm
> instcbm xum1541
> Both will then work.

To be more precise: The last two lines can be replaced by

instcbm xum1541 xa1541

to make the xum1541 default, or

instcbm xa1541 xum1541

to make the xa1541 default.

In fact, "instcbm" without any parameter installs the plugins
("drivers") for the xa1541, the xu1541 and the xum1541. The default is
then defined by alphabetical order: That is, without parameters, the
xa1541 is the default.

In fact, doing an

instcbm --adapter=xum1541

or the equivalent short form

instcbm -@xum1541

will also install all three plugins, but make the xum1541 the default
one.

Also note: If someone has the xum1541 already installed (via "instcbm
xum1541"), he can additionally install the xa1541 by issuing an "instcbm
xa1541". That is, installing the plugins adds them to the current
config. Likewise, instcbm --remove xa1541 will remove the xa1541 only,
leaving any other plugin intact.

One additional note: The xa1541 plugin is responsible for the xa1541
cable, the xm1541 cable, the xap1541 and the xmp1541. Don't be fooled by
the name, it is all handled by the same plugin!

> By default, it will use the Zoom, so to use
> parallel you would issue the '-@' switch, like this:
> nibread image.nib - read from drive attached to Zoom
> nibread -@xa1541 image.nib - read from drive attached to parallel

Exactly. The -@ switch should work for all tools (but: Note that instcbm
uses it a little bit differently, to set the default adapter.)

Regards,
Spiro.

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

[TomL_12953]

On Sep 25, 4:59 pm, Nate Lawson <n...@root.org> wrote:
> I've just uploaded a new release of both OpenCBM and the ZoomFloppy firmware. It should be considered a beta that has had light testing. I'm looking for wider testing of these items:
>

I downloaded it and can't run instcbm at all. I get "Installer for
OpenCBM Parallel Port Driver has stopped working"
I have Win 7 Ultimate 64-bit and no parallel port. Will I have to
install one? If so it will have to be in a PCIe slot.
I have the ZoomFloppy on a USB port (the driver for that installed
correctly).

Tom L

[TomL_12953]

> I downloaded it and can't run instcbm at all. I get "Installer for

I tried the xa1541 xu1541 and xum1541 parameters and now when I use no
parameters I get:

C:\opencbm\bin>instcbm
Working directory = 'C:\opencbm\bin\',
system directory = 'C:\Windows\system32\',
driver directory = 'C:\Windows\system32\DRIVERS\'.
Using plugin: 'xa1541' with filename 'opencbm-xa1541.dll'.
++++ Install: 'xa1541' with filename 'opencbm-xa1541.dll'.
Copying '.\opencbm-xa1541.dll' to 'C:\Windows\system32\opencbm-
xa1541.dll'
Copying '.\cbm4wdm.sys' to 'C:\Windows\system32\DRIVERS\cbm4wdm.sys'
Copying '.\cbm4nt.sys' to 'C:\Windows\system32\DRIVERS\cbm4nt.sys'
Could not get address of
opencbm.dll::opencbm_plugin_install_plugin_data()Could
not get address of opencbm.dll::opencbm_plugin_install_generic().

[Nate Lawson]

Use the install.bat, not instcbm directly. This is described in the included pdf manual.

If you must use instcbm, you have to be override the default of the xa1541 (lpt driver):

instcbm xum1541

[TomL_12953]

On Nov 17, 12:28 am, Nate Lawson <n...@root.org> wrote:
> Use the install.bat, not instcbm directly. This is described in the included pdf manual.
>
> If you must use instcbm, you have to be override the default of the xa1541 (lpt driver):
>
> instcbm xum1541
>

Thanks for the reply. Now I get this:

C:\opencbm\bin>instcbm xum1541

Working directory = 'C:\opencbm\bin\',
system directory = 'C:\Windows\system32\',
driver directory = 'C:\Windows\system32\DRIVERS\'.

Using plugin: 'xum1541' with filename 'opencbm-xum1541.dll'.
++++ Install: 'xum1541' with filename 'opencbm-xum1541.dll'.
Copying '.\opencbm-xum1541.dll' to 'C:\Windows\system32\opencbm-
xum1541.dll'

Could not get address of
opencbm.dll::opencbm_plugin_install_plugin_data()Could
not get address of opencbm.dll::opencbm_plugin_install_generic().

Tom L

[Nate Lawson]

Stop using instcbm. Uninstall what you've got so far. Use install.bat

-Nate

[TomL_12953]

>
> Stop using instcbm. Uninstall what you've got so far. Use install.bat
>
> -Nate

I tried instcbm -r but all I get is

Error processing command line arguments

[TomL_12953]

Finally! I found the problem. When I uninstalled an older version
there were still files in SYSWOW64 that I forgot to delete.
Now I'm using the ZoomFloppy with GUI4CBM4WIN and VICE (32-bit only!)
with no problem. Thanks for your patience!