Contents

VERSION 0.4.99.104 (Jan 23rd, 2022)

  • new: xum1541cfg: add bootloader command
  • new: cbmctrl add low-level IEC line handling (ireset, uireset, atn, uatn, data, udata)
  • new: xum1541 firmware version 8 for PROMICRO boards with various fixes and additions (SRQ nibbling, bootloader)
  • new: xum1541 firmware split into supported and unsupported devices; new make target "unsupported"
  • new: xum1541 firmware and plugin: include compilation details
  • new: xu1541 firmware: Generated combined bootloader and firmware hex files for easier initial setup
  • fix: Windows installation could not update the installed driver for xu1541 or xum1541 devices. Fixed, update works now.
  • fix: xum1541 firmware: fix IEC_SRQ setting/unsetting which resulted in unpredictable behaviour
  • change: cbmcopy: don't filter user-provided local output filenames
  • change: Various fixes for newer compilers (gcc) and platforms (Linux 5.x)
  • change: change devmodel for parport driver to allow compilation with newer versions (Linux)
  • change: do not build plugins that are not needed

VERSION 0.4.99.103 (Jul 14th, 2020)

  • xum1541: Severel USB fixes
  • Windows: install.cmd fix OS detection

VERSION 0.4.99.102 (Jun 22nd, 2020)

  • xum1541: Severel USB fixes
  • Windows: install.cmd fixes; add XP support; fix installation from directories with SPACEs in their name
  • all: fix some install issues

VERSION 0.4.99.101 (Jun 13th, 2020)

  • xum1541: Severel USB fixes
  • Windows: install.cmd fixes

VERSION 0.4.99.100 (Jun 11th, 2020)

  • all: add testlines
  • all: add more fingerprints for floppy device detections
  • all: Fixed some portability issues
  • all: use libusb1 if it is available
  • all: fix crash if no xum1541 was present
  • cbmctrl: Add to upload and download robustness.
  • Linux: Use FORTIFY and -fstack-protector to find code issues
  • Windows: remove iA64 (Itanium) target
  • Windows: install.cmd to install OpenCBM, plugin and drivers at once, with proper uninstallation for 'Software' control center
  • documentation: misc. updates and fixes
  • xa1541: Do not try to compile kernel module if sources are missing
  • xum1541: Add PROMICRO and TEENSY2 firmwares (UNSUPPORTED!)
  • xum1541: New firmware v08; OpenCBM will also happily use v07
  • xum1541+xu1541: Do not try to compile if libusb is missing
  • FreeBSD/xa1541: New kernel module
  • Linux/xa1541: Fix compilation for newer kernels
  • Linux/xum1541+xu1541: Give rights to the currently active user
  • MacOS/xu1541: Fix usb_echo_test
  • xum1541cfg: new command 'devinfo'
  • xum1541: firmware v08:
    • make 2031(LP) work by fixing an issue of the IEEE protocol implementation
    • Remove jitter in SRQ writing that caused errors on new compilers when SRQ nibbling
  • cbmctrl: 'detect' checks parallel cable with test patterns; minimum and maximum device numbers to be checked can be given now; document --verbose/-v
  • cbmctrl: 'dir' did not handle the device number correctly. Allow for filespec. Add --petscii option; more verbose on failure

The installation is covered in the manual. Please check it in order to uninstall OpenCBM.

VERSION 0.4.99.99 (RC) (September 5th, 2017)

Fixed the xum1541cfg.exe tool for Windows, which was a totally wrong, old tool before.

The installation is covered in the manual. Please check it in order to uninstall OpenCBM.

VERSION 0.4.99.98 (BETA STAGE!) (January 13th, 2016)

Mainly documentation updates, some small fixes, Windows installation changed.

The installation is covered in the manual. Please check it in order to uninstall OpenCBM.

Update of instructions (March 6th, 2014)

The instructions for compilation on Linux and MacOS were wrong. Fixed them.

VERSION 0.4.99.97 (ALPHA STAGE!) (April 7th, 2014)

Some small fixes, especially for Mac OS X compatibility.

VERSION 0.4.99.96a (ALPHA STAGE!) (April 7th, 2014)

I did the same mistake again as with 0.4.99.95 and 0.4.99.95a. I had to find out that I did not generate a release for quite some time. I have made a mistake again. It seems I must automate the dist generation again, so it works with my current setup.

The source package provided for 0.4.99.96 did not compile, because parts of the build infrastructure were missing. I replaced the source package by a version 0.4.99.96a, which compiles now.

Note: This source package contains one directory "in front" in the directory that was included beforehand. Thus, you have directories opencbm/, xu1541 and xum1541 (besides others) side by side.

In order to compile these sources, you have to change into the opencbm/ directory and compile from there.

VERSION 0.4.99.96 (ALPHA STAGE!) (March 23rd, 2014)

I was asked to generate a new version of OpenCBM that includes imgcopy. Voilà, here it is.

VERSION 0.4.99.95b (ALPHA STAGE!) (February 6th, 2014)

Again, I had to find out that I did not generate a release for quite some time. I have made a mistake again. The source package provided for 0.4.99.95 did not compile, because parts of the build infrastructure were missing. I replaced the source package by a version 0.4.99.95b, which compiles now.

Note: This source package contains one directory "in front" in the directory that was included beforehand. Thus, you have directories opencbm/, xu1541 and xum1541 (besides others) side by side.

In order to compile these sources, you have to change into the opencbm/ directory and compile from there.

Thus, the net result is now: We have binary releases for Windows 0.4.99.95a, and source release 0.4.99.95b. Oh, and we still have the version 0.4.99.95.

The sources are identical, that is, 0.4.99.95b can be used to compile 0.4.99.95a, and 0.4.99.95. So, please do not complain that there is no binary distribution of 0.4.99.95b available, or that the sources for 0.4.99.95a would be missing.

VERSION 0.4.99.95a (ALPHA STAGE!) (February 5th, 2014)

Removed the compiled version of xum1541cfg.exe. The version provided was heaviliy outdated and does not resemble the latest development. Furthermore, any instructions you might have read about xum1541cfg.exe did not apply to the version provided here.

To get the accurate version that actually works, use the one provided in the ZoomFloppy Win32 install package instead.

VERSION 0.4.99.95 (ALPHA STAGE!) (January 31st, 2014)

Some fixes, ZoomFloppy driver updated.

More specifically:

  • Add debugging output for Unixoids.
  • Fix crashes due to buggy command line parsing code. This prevented running OpenCBM tools on the Raspberry Pi.
  • Some small build environment changes
  • No silent failing of plugin loading: If plugin loading fails, do not crash or output nothing, but output an error message.
  • More explicit debugging output for plugin initialization failures (CHECKED build only)
  • Detect Windows 7, 8 and 8.1
  • New tool cbmlinetester for (very) basic cable debugging
  • build system: do not build xa1541 by default anymore.
  • Add additional locations for opencbm.conf to allow local (non-root, non-admin) installatio
  • Add ZoomTape (1530/1531 tape drive support), adding cap2tap, tap2cap, tapcontrol, tapview, tapread and tapwrite tools.
  • MacOS X/FreeBSD: Use 'wheel' group for root (instead of 'root')
  • Windows:
    • instcbm: fix a crash
    • user *must* specify a plugin name now
  • FreeBSD: Move configuration files to /usr/local/etc
  • Fix erroneous comments: install paths instead of build paths should be shown in opencbm.conf
  • Rework/Fixes for Linux build system to allow compilation for more platforms, and for better parallelization.
  • fixed link-order problem of shared libs (libusb) with newer binutils (2.22, used e.g. in Ubuntu) which resulted in failure to run xu1541 and xum1541 devices.
  • Linux/Unixoids: User can specify a new environment variable OPENCBM_HOME to tell where the /etc/opencbm.conf file resides (at: ${OPENCBM_HOME}/etc/opencbm.conf)

VERSION 0.4.99.94 (ALPHA STAGE!) (January 27th, 2012)

Many, many fixes and installation is easier now.

VERSION 0.4.99.89 (ALPHA STAGE!) (September 17th, 2010)

Installation of all plugins on Windows and Linux should work.

VERSION 0.4.0.80 (ALPHA STAGE!) (March 8th, 2009)

NOTE: This software is in a early state, although its main parts are working. However, not all parts are working as they should.

This version has been given out to some people who want to test it. Unfortunately, I did not have the time to update this page yet.

You should not edit the opencbm.conf file anymore, neither on Windows, nor on Linux. If you want to use this version, please write me a mail, and I will explain it to you. This text would be a good basis for an update of this page. ;)

VERSION 0.4.0.62 (ALPHA STAGE!) (May 6th, 2007)

NOTE: This software is in a VERY early state. Parts are not yet working as they should. Do not use this version unless you really, really want to test the software.

This version fixes a nasty bug which prevented tools using the old APIs to work. (for example, flash, morse, but also mnib/nibtools did not work.)

VERSION 0.4.0.60 (ALPHA STAGE!) (May 1st, 2007)

Additionally to the 0.4.0.51 version, this version added --adapter/-@ command-line options to cbmctrl, cbmcopy, d64copy, cbmformat, cbmforng, and cbmrpm41. This options is not yet shown in the help, but it is there.
You can use it this option to select the plugin. That is, "-@ xu1541" selects the xu1541, "-@ xa1541" selects the xa1541 plugin, respecively. Of course, for this to take effect, they have to be available in the /etc/opencbm.conf file. The name is the one that is specified between in the [...] lines.
There is also the possibility to specify a port number. Take, for example, you have two parallel ports. Then you can specify -@ xa1541:1 for LPT1, and -@ xa1541:2 for LPT2.
If this parameter is ommitted, the default value of the opencbm.conf file will be used.

The API functions cbm_open_driver() and cbm_get_driver_name() are obsolete now. use the newer cbm_open_driver_ex() and cbm_ger_driver_name_ex() functions instead. They let you specify the adapter in the same format as --adapter/-@. You can give a NULL pointer, in which case the default adapter will be used.
Note: These new APIs are not yet available in the VDD. This is still to be done.

The 0.4.0.51 version added support for the XU1541 cable, which was invented and implemented by Till Harbaum.

Note: I did not take much time to update this site, this, some information may be outdated!

Installation

The installation is covered in the manual. Please check it in order to uninstall OpenCBM.

VERSION 0.4.0 (Apr 28th, 2006)

This release adds some functions, as well as bug fixes to cbm4win. Additionally, it is a release for cbm4linux. Have a look at the changes.

This project is hosted on github.com. Thanks for the service.

Introduction to cbm4win

What is cbm4win?

cbm4win is a port of cbm4linux to Windows. It allows for access to a VIC 1540, 1541, 1570, 1571, or even 1581 floppy drive from the PC on Windows NT, 2000 and XP.

What can I do with cbm4win?

The most important things you can do is to copy D64 or D71 images from a real drive to the PC, or from the PC to a real drive with the help of d64copy. Furthermore, you can copy single files in both directions, too. Some more tools (for example, cbmctrl) are given, too.

Is there 3rd party support for cbm4win?

VICE will have support for cbm4win in the next version. There is an internal version of YAPE which supports cbm4win, too. Other people have already showed interest in supporting cbm4win in their products, too.

What hardware is needed in order to use cbm4win?

Of course, you need a PC running Windows NT, 2000, XP, or 2003. Furthermore, you need a real drive, like the VIC 1540, 1541, 1570, 1571, or 1581 (1581 not fully supported). Then, you need an XA1541, XM1541, XAP1541 or XMP1541 cable in order to connect the driver with the PC.

Where can I find a list of frequently asked questions (FAQ)?

Simply go to the end of this web page, or use the link.

History

The following history applies to the various versions of CBM4WIN

v0.4.0 (April 28th, 2006)

The changelog is no longer maintained here. It can be found at changes

v0.1.0a (May 29th, 2005)

This version fixes some errors. Some of them are SECURITY ISSUES, thus, I highly recommend upgrading to that version.
Furthermore, d64copy wrote d64 files which were "wrong" if there were errors on the disk.
Another issue is a fixed performance problems, which occurred especially with multiprocessor machines (SMP) or Hyperthreading machines (HT), but also with NT4.

In more detail, the following changes have been applied from 0.1.0:

  • drivers (cbm4wdm.sys/cbm4nt.sys):
    • performance fix for some machines, especially SMP, HT, and NT4. This fixes #1070112.
    • Allow for specifying the cable type via the registry (instead of auto-detecting).
  • cbmctrl:
    • Fixed 2 format string vulnerabilities
    • Do not allocate a 64KB buffer on the stack anymore which might allow for a stack overflow.
  • instcbm:
    • Do not allocate a 128KB buffer on the stack anymore which might allow for a stack overflow.
    • Fixed 3 "off-by-one" buffer accesses, resulting in access to non-allocated memory.
    • Fixed some more possible accesses to uninitialized variable.
  • d64copy:
    • Make sure image is correctly closed when aborted with Ctrl+C. This fixes #1083877.
    • When writing error codes into a file (for d64 with error map), make sure the jobcode is written ($01-$0F) instead of the DOS error code (18 and higher). This fixes #1188112.
  • cbmcopy:
    • Fixed rare shutdown problem. This fixes #1070076 for cbmcopy.
  • cbmformat:
    • New drive routine with probing. This fixes #1066199.
  • all:
    • a misplaced if() statement could lead to access of uninitialized variable space. Fixed that.
    • Error in debugging output could result in multiple evaluations of some functions. Fixed that.

December 6th, 2004

Added a section for Frequently asked questions (FAQ) on this web site.

v0.1.0 (November 28th, 2004)

The following changes have been applied from 0.0.12:

  • cbmctrl detect (and the function cbm_identify() which is used in the API) left one byte in the command buffer. Because of this, a cbmctrl status command afterwards returned nothing. Fixed this.
  • Added documentation how to build the source packages. See doc\COMPILE.TXT file.

Download

You can download the Windows version of OpenCBM (a.k.a. cbm4win) 0.4.99.104 (RC) from https://spiro.trikaliotis.net/download/opencbm-0.4.99.104/opencbm-0.4.99.104.zip (i386, and AMD64).

Acknowledgements, thanks and links

Cbm4win is heavily based on cbm4linux, written by Michael Klein. Cbm4linux itself uses work from Star Commander, written by KOVÁCS Balázs a.k.a. "Joe Forster". I like to thank both for their steady help and their patience.

The xu1541 work as done by Till Harbaum.

Furthermore, I want to thank the following people:

  • Michael Klein for cbm4linux and many discussions. I do not know if I would have started this project without this.
  • KOVÁCS Balázs a.k.a. "Joe Forster" for Star Commander, his advice, and for giving me cables for free to work on this project;
  • Wolfgang Moser for steady discussions, testing, and bug reports, as well as giving me some more needed equipment;
  • all of my testers for steady tests, reports, and discussions.

Contact, bug tracking, mailing lists

Feel free to contact me if you have questions, suggestions, or you just want to confirm that something does work or does not. Specifically, if you are using cables not specified above, or drives not specified above, I would like to hear if CBM4WIN works with this combo.

More specifically, I have setup a project page on sourceforge. If you want to submit bug reports, I would be thank you for submitting to the bug tracking system over there. There are even two mailing lists available for announcements and for user discussions.

If you want to contact me directly, just contact me at cbm4win@trikaliotis.net, or go to my homepage at https://spiro.trikaliotis.net/.

Frequently asked questions (FAQ)

Many thanks to Wolfgang Moser for maintaining the FAQ!

Hardware related

Cable related

Q: Is there any reason why you're not supporting the quasi standard XE1541 cable?

A: See answer to the next questions

Q: Why are the X1541 or XE1541 cables not supported?

A: Technical implications prevent reliable use of these cable types.

If I want to transfer to a VIC drive, the drive is allowed to block the transfer for as long as it needs (the so-called "listener hold off", T_H in the C64 Programmer's Reference Guide). If the drive is ready, it signals this with the DATA line. The controller - in this case the PC - has to react to this in not more than T_NE, "non-eoi response", with setting CLK active. T_NE is rather short, it must not exceed 200 us. Typically, it should be something around 40 us. If the controller exceeds this 200 us bound, the listener - the drive - thinks that we wanted to signal an End-Of-Information, thus, there is no more data. For the PC to be able to cope with that very low time bound, there are two options:

  1. busy waiting
  2. use interrupt

No. 1, busy waiting, is not really an option. If we would do this, then we would have to monopolize the whole machine for the whole time. That is, you would not be able to hear music, work with MS Word, or even abort the transfer! Now, what would happen if the drive does not answer at all, for example, because it crashed? Well, yes, your PC would not be usable at all, thus, you would have to reboot that one, too. (This is not entirely true: Switching the drive off and on would help, too).

OTOH, if we use the interrupt, this is not a problem anymore. When the driver signals DATA, the parallel port generates an interrupt. In the interrupt routine, we react to this by setting CLK, and then, we wake up the (sleeping) main routine, which does the rest of the work. This way, we do not monopolize the whole CPU of the PC, which is very good in terms of overall stability of the system.

Now, the PC's parallel port cannot generate an interrupt on every line. With an XE cable, it can generate an interrupt on a RESET - this does not make much sense, does it? Because of this, the XM cable exchanges RESET and DATA w.r.t. the XE cable. This way, using an XM cable, the DATA line can generate interrupts, as needed.

Thus, to sum it up: It is very unlikely that an XE cable will ever be supported.

Q: Can a XE1541 cable be converted into a XM1541 cable and how is this done?

A: Yes, a XE1541 can easily be converted into a XM1541 cable

  • You only need to exchange lines 5 and 6 (RESET and DATA) at the DIN-Plug side of your XE1541 cable to convert it into a XM1541.
  • You also might consider building an adaptor, which just consists of two DIN plugs (one male, one female) which crosses the lines 5 and 6 (RESET and DATA). This way, you have a XE1541 if you operate your cable without the adaptor, or a XM1541 if it is operated with the adaptor.
  • The same idea (for being operated with an XEP adaptor) is available at The Commodore serial cable, twisted version

By the way, as easy as converting a XE1541 cable into a XM1541 is converting a XM1541 into a XE1541 with the very same methods described above.

Software problems

Installation issues

Q: cbm4win refuses to work on my machine, what can I do?

A: Try enabling the "Legacy Plug+Play Detection" for the parallel port. It was reported that on a Sony Vaio laptop with Windows 2000 installed, cbm4win could be installed without a problem, but none of the commands affected the connected 1541 disk drive in any way. Different parallel port settings in the BIOS were double checked without any help. The reporting user found that enabling the "Legacy Plug+Play Detection" for the LPT port helped to establish the communication with cbm4win and the connected disk drive.

To enable "Legacy Plug+Play detection" for your LPT port, where the 1541 disk drive is connected to (with a XM1541 or XA1541 cable), follow these steps:

  • Log in as administrator
  • Right click on "My Computer"->"Properties"
  • Select the "Hardware" tab
  • Click to "Device Manager"
  • Open the "Ports (COM and LPT)" tree
  • Right click on "LPT1"->"Properties" (or the LPT port you are using for cbm4win)
  • Select the "Port Settings" tab
  • Enable the "Enable Legacy Plug+Play Detection" checkbox by clicking onto it
  • Clock the "Apply" button to activate this setting

This may not help in any circumstances. From the user's report it is known that this was only needed for his Sony Vaio laptop. Other machines which also run Windows 2000 do not need this.

Using the tools

Q: Where are all the commands listed that can be used with cbm4win?

A: Please refer to the cbm4linux.txt manual in the "doc" directory. Alternatively you may visit the cbm4linux 0.3.2 Users Guide, since proper user documentation for cbm4win is not available yet.

Q: Where can I find a description for all the subcommands and options of the different tools (cbmctrl, d64copy, cbmcopy, cbmformat, instcbm)?

A: Each of the user commands above knows the option "--help", which explains parameters and subcommands in short, e.g.: "cbmctrl --help"

Q: But if I enter the command "cbmctrl --help", then a black window opens for a second or so and disappears immediately. I can't read any of the informations, what is going wrong here?

A: You need to open a dedicated command line console (a.k.a. "DOS-console").

What did you do? Entering the command "cbmctrl --help" via the Start->Execute dialog? Please enter the command "cmd" within this dialog box. This opens a dedicated command window. Change into the directory, where you extracted the cbm4win tools (if you didn't place them into Windows' search path) and enter e.g. the command "cbmctrl --help" within the console window.

(NEW: July 4, 2005) Q: cbmctrl and other commands work fine. Anyway, whenever I use d64copy or cbmcopy with --transfer=parallel, the transfer hangs.

A: For using the parallel transfer options, you need to own an XP1541 companion cable additionally to your XA1541 or XM1541 cable. The parallel transfer will not work without that cable. Thus, to be able to transfer data, use serial2 (if you have only one attached drive simultaneously) or serial1 (in any other case).

External links

Here, I will start adding additional links to useful software which is related to cbm4win. For a start, there is just one:

Where to buy ready cables?

If you want to use cbm4win, you need an XA1541 active cable or an XM1541 multitasking cable, as mentioned above. I do not manufacture them or sell them. Anyway, as a service, I list shops where these cables can be bought. Please, do NOT understand this as a suggestion from me to buy them there. These are just starting points. I am not aligned to anyone there, nor do I have any profit if you buy any cable there. I do not know most shops myself, thus, I cannot tell you about the quality of the cables or delivery times. If you need to buy a cable, please pick a shop which you think you can trust. Think yourself!

  • The X1541 shop. This is Joe Forster's shop. In fact, this is where I got my 2nd XA1541 and my XP1541 cable from. There is also a German section as well as the USA/Canada section of this shop available. Here, you can get all types of cables.
  • In the PC section of DoD's shop, you can get X1541 and XE1541 cables (which do NOT work with cbm4win!) and the XM1541 cable. In fact, he is the manufacturer of the cables from Protovision-Online.
  • There is a hardware shop over at http://www.commodore16.com/ which sells XE1541, XM1541 and XA1541 cables.