https://sourceforge.net/p/opencbm/bugs/41/

When using a 1571 disk drive at device ID 9 which is currently switched to 1541 mode (default reset state), the following command execution series leads to a "29, disk id mismatch,00,00" error:

cbmforng -s -x 9 disk,id
cbmctrl command 9 "UJ"
cbmctrl command 9 "U0>H0"
cbmctrl command 9 "U0>M1"
cbmctrl command 9 "N:LONG1571REFORMAT,LR"
cbmctrl status 9

The 1571's native mode formatting process stops after the first side instead of formatting the second side. This misbehavior seems to be induced by the cbmforng command.

If the cbmforng command is replaced by cbmformat, the 1571 mode long format behaves normally. Also, when the device is reset with "cbmctrl reset" after cbmforng has been executed, the 1571 long format behaves normally. Somehow cbmforng seems to not shut down properly so that a memory location which is not used in a 1541 remains at a value that causes the misbehavior, when the floppy acts as native 1571. Even more the cold start command "UJ" seems not to be able to properly initialise that memory cell. Another possibility is that cbmforng uses some hardware properties that aren't reset with "UJ", but only with a hardware reset.

Womo

A workaround to fix this problem is to execute cbmforng in 1571 native mode before the 1571 long format command, e.g.:

cbmforng -s -x 9 disk,id
cbmctrl command 9 "UJ"
cbmctrl command 9 "U0>H0"
cbmctrl command 9 "U0>M1"
cbmforng -b 18 -e 18 -s 9 unformat,uf
cbmctrl command 9 "N:LONG1571REFORMAT,LR"
cbmctrl status 9

Womo

The workaround is not fully working yet, especially when a D71 image should be transferred to the freshly formatted disk with d64copy. After the dummy call to cbmforng, the floppy needs to be initialised:

cbmforng -s -x 9 disk,id
cbmctrl command 9 "UJ"
cbmctrl command 9 "U0>H0"
cbmctrl command 9 "U0>M1"
cbmforng -b 18 -e 18 -s 9 unformat,uf
cbmctrl command 9 I
cbmctrl command 9 "N:LONG1571REFORMAT,LR"
d64copy -2 image-file_1571.d71 9
cbmctrl status 9

Womo

Compiling on Debian Buster, kernel 4.19.0-6-amd64 (Linux XXX 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20) x86_64 GNU/Linux), the compilation fails:
make[2]: Entering directory '/usr/src/linux-headers-4.19.0-6-amd64' CC [M] /home/spiro/Work/cbm/opencbm.git/opencbm/sys/linux/cbm_module.o /home/spiro/Work/cbm/opencbm.git/opencbm/sys/linux/cbm_module.c: In function ‘wait_for_listener’: /home/spiro/Work/cbm/opencbm.git/opencbm/sys/linux/cbm_module.c:364:30: error: implicit declaration of function ‘signal_pending’; did you mean ‘timer_pending’? [-Werror=implicit-function-declaration] while (cbm_irq_count && !signal_pending(current)) ^~~~~~~~~~~~~~ timer_pending cc1: some warnings being treated as errors

Trying to install the xa1541 plugin (which includes the non-USB xa1541 and xm1541 cables), the installation fails. In the output, you can find the following file:

Copying '.\cbm4wdm.sys' to 'C:\WINDOWS\system32\DRIVERS\cbm4wdm.sys' FAILED!

(Note that the paths can differ!)

This is an issue with the install.cmd script, as it forgets to copy the cbm4wdm.sys before running instcbm.exe

This issue has been fixed with commit f2bab60.

To fix this issue with the 0.4.99.99 binary package, replaced the install.cmd file with the version you get from here:
https://github.com/OpenCBM/OpenCBM/blob/master/opencbm/WINDOWS/install.cmd

The problem has been independantly reported by Charles Campbell and Ashley Powell.

All the autodetection rules should be enhanced in a way
so that they don't only check, if a decent feature is
present, but if it is valid and/or working, too.

Concretely I want d64copy to check, if an autodetected
parallel cable is working 100%, before it is used. I
the autodetection finds that the cable has got some
failure, it should print otu a warnign and fall back to
the next capable transer mechanism.

At my test environment it happened that there was a
1541 disk drive with a somewhat blown VIA chip the
parallel cable was connected to. I didn't recognize
this and thought d64copy got a software problem (bug).
Then I checked with MNib and this one told me a "Code
verify: FAILED" which brought me to the idea that the
parallel cable is not working.

In case of the parallel cable it should be enough for
the validness detection, if the four values:
55/AA/00/FF are transmitted, or 5A/0F/A5/F0, or ...

A somewhat slow method is attached as a patch to detectxp1541.c.

This is to document the core idea only, this implementation is a bit too slow, because it does each and every device port access with single M-W commands. It would be better to write some custom drive code to do:

a) hardware detection (memory mapping, 1541 vs. 1541C vs. 1571)
b) port chip detection (VIA, CIA, PIA 6821)
c) parallel cable test with custom IEC bus signalling

File Added: detectxp1541_in+out.patch

Taken over from https://sourceforge.net/p/opencbm/feature-requests/16/:

With the number of supported commands growing in
cbmctrl, it might be useful to think about extendings
its ability to become a whole subshell.

A subshell beside the command oriented nature it
currently is, a subshell comparable to the one of the
c1541 utility out of the VICE package.

Maybe such a subshell could be made to read out its
command from a file specified with:
cbmctrl -c <cmdfile>

Compilation dies here:

_make[2]: Entering directory `/opt/local/var/macports/build/Users_alien_ports_emulators_opencbm/opencbm/work/code/xu1541/lib'
cc -I/opt/local/include -I/opt/local/include/ -g -Wall -pedantic -I../include/ -c -o close.o close.c
In file included from close.c:1:
../include/xu1541lib.h:57:8: error: unknown type name 'libusb_device_handle'
extern libusb_device_handle * xu1541lib_find(void);
^
../include/xu1541lib.h:58:8: error: unknown type name 'libusb_device_handle'
extern libusb_device_handle * xu1541lib_find_in_bootmode(unsigned int *p_soft_bootloader_mode);
^
../include/xu1541lib.h:59:47: error: unknown type name 'libusb_device_handle'
extern void xu1541lib_close(libusb_device_handle *handle);
^
../include/xu1541lib.h:60:57: error: unknown type name 'libusb_device_handle'
extern int xu1541lib_get_device_info(libusb_device_handle *handle, xu1541_device_info_t *device_info, unsigned int device_info_length);
^
../include/xu1541lib.h:61:61: error: unknown type name 'libusb_device_handle'
extern void xu1541lib_display_device_info(libusb_device_handle *handle);
^
../include/xu1541lib.h:62:63: error: unknown type name 'libusb_device_handle'
extern int xu1541lib_is_in_bootloader_mode(libusb_device_handle *handle);
^
../include/xu1541lib.h:63:46: error: unknown type name 'libusb_device_handle'
extern void xu1541lib_wait(libusb_device_handle *handle);
^
../include/xu1541lib.h:64:58: error: unknown type name 'libusb_device_handle'
extern int xu1541lib_set_to_boot_mode(libusb_device_handle *handle);
^
../include/xu1541lib.h:65:54: error: unknown type name 'libusb_device_handle'
extern int xu1541lib_get_pagesize(libusb_device_handle *handle);
^
close.c:9:22: error: unknown type name 'libusb_device_handle'
void xu1541lib_close(libusb_device_handle *handle) {
^
close.c:11:13: warning: implicit declaration of function 'libusb_release_interface' is invalid in C99 [-Wimplicit-function-declaration]
int ret = libusb_release_interface(handle, 0);
^
close.c:12:14: error: use of undeclared identifier 'LIBUSB_SUCCESS'
if (ret != LIBUSB_SUCCESS) {
^
close.c:13:40: warning: implicit declaration of function 'libusb_error_name' is invalid in C99 [-Wimplicit-function-declaration]
fprintf(stderr, "USB error: %s\n", libusb_error_name(ret));
^
close.c:13:40: warning: format specifies type 'char *' but the argument has type 'int' [-Wformat]
fprintf(stderr, "USB error: %s\n", libusb_error_name(ret));
~~ ^~~~~~~~~~~~~~~~~~~~~~
%d
close.c:17:3: warning: implicit declaration of function 'libusb_close' is invalid in C99 [-Wimplicit-function-declaration]
libusb_close(handle);
^
4 warnings and 11 errors generated.

The issue has to do something with the fact that wrong/no headers are included.

"libusb_device_handle" function is found in "/opt/local/include/libusb-1.0/libusb.h" but NOT in "/opt/local/include/usb.h"

As you can see "cc..." is totally missing the -DHAVE_LIBUSB=1 -DHAVE_LIBUSB1=1 -DHAVE_LIBUSB_1_0=1 stuff....thus "../include/xu1541lib.h" does not include anything:

#if HAVE_LIBUSB0
#include <usb.h>
#elif HAVE_LIBUSB1
#include <libusb.h>
#endif

Taken over from https://sourceforge.net/p/opencbm/feature-requests/18/:

Extending OpenCBM so that it can also emulate a floppy would be nice. AFAIK 64HDD does this, but this program is neither open source nor available for Linux.

Emulating a floppy would especially be handy for development on the C64DTV.

Hello,

this is already on my own TODO list, but I am not totally sure if it will be possible taking into account the PC's restrictions.

Spiro

Moved over from https://sourceforge.net/p/opencbm/feature-requests/26/:

Add infrastructure and implement a way to give the user more thorough error texts.

cf. #42 and https://sourceforge.net/p/opencbm/bugs/18/

Same issue for cbmformat as for cbmforng.

Taken over from https://sourceforge.net/p/opencbm/feature-requests/21/:

As OpenCBM installs into /usr/local/bin/, document that this has to be in the path. Additionally, add a warning into the Makefile if it determines that /usr/local/bin/ is not in the path.

Taken over from https://sourceforge.net/p/opencbm/feature-requests/17/:

cbmctrl may support a wider range of devices in the
future, namely paritions and subdirectories of CMD
drives and the Commodore 1581 disk drive.

Either two dedicated commands for partitions (1581 as
well as CMD devs) and subdirectories may be created or
one combined command for both (e.g. cd).

Further the directory command action dir may be
extended to show the contents of named subdirectories
or paritions (either 1581 or CMD ones).

Taken over from https://sourceforge.net/p/opencbm/feature-requests/19/:

In a discussion on the CC65 mailing list, one came up with ideas for further improvements to the concept of constructing a shared C/ASM header file with macro definitions:

Steve Davison wrote there:

[....] However I have a number of suggestions that could make it far more legible and usable:

    Instead of _CMT(str) macro consuming str, how about a _CMT() mac that turns the just inserts a ';' or a '//' ?
    In order to be more than a parlor trick, I think you would have to have a full, standard set of macros, a la OCTETDECL, that are predefined in a library. Lets everyone speak the same language, and avoids a lot of reinvention.
    (..continued..) The language-specific macro defines should not be duplicated in every file that needs an .idh include, they should be in the .idh file itself. More encapsulated, less clutter, less prone to errors.
    Further, they wouldn't actually be defined in the .idh files themselves; the .idh would simply include the standard macro library as described above. The really neat part is that getting the definitions for the appropriate language could be accomplished using Christian's method.
    [...]
    //////// THIS IS COOL... /////////
    If you haven't done it already, take Christian's duplicitous header code and look at it with syntax highlighting, both C and assembler. It's kinda like turning on 2 different neon signs that are under camouflage.

Prior the Steve's mail, Christian Grössler wrote:

;/ include file for assembler & C
; * Christian Groessler
; /

;/ Avoid double inclusion in C /
;/
.if 0
;/
ifndef C_AND_ASM_INCLUDED
define C_AND_ASM_INCLUDED

;/
.endif
;/

;/ some constants
; / enum MY_CONSTANTS { /
MY_CONSTANT_1 = 123 ; / MY_CONSTANT_1 = 123, /
MY_CONSTANT_2 = 456 ; / MY_CONSTANT_2 = 456, /
; / };

;/ a structure
.struct MY_STRUCT ; / typedef struct MY_STRUCT
{ /
MEMBER1 .word 2 ; / unsigned short
MEMBER1[2]; /
MEMBER2 .byte 2 ; / unsigned char
MEMBER2[2]; /
.endstruct ; / } MY_STRUCT_T;

;/
.if 0
;/
endif // C_AND_ASM_INCLUDED

;/
.endif
;/
;/ End of Include file /

The neat trick of Christian's code is using the ";". In CA65-Assembler this introduces an until-the-end-of-the-line comment. In C, at the very most places an additional ";" does not have any futher syntactical or semantical meaning. Therefore the ";" can be used to hide things from the assmebler in one-line comments. In native C these lines are not hidden and therefore can introduce special pre-process definitions to the C compiler; here to hide ASM instructions from the C compiler. And so on...

Womo

Hello,

After getting OpenCBM to build on OS X, I managed to find my ZoomFloppy board and plugged it in. The LED is lit however it doesn't seem to be detected by any of the various utilities. From a bit of googling, I found I can set XUM1541_DEBUG=3 to increase the debugging. Here's what I get:

$ cbmctrl detect
[XUM1541] scanning usb ...
[XUM1541] scanning bus 001
[XUM1541] device 05ac:8007 at 000-05ac-8007-09-ff
[XUM1541] scanning bus 002
[XUM1541] device 05ac:8007 at 000-05ac-8007-09-ff
error: no xum1541 device found
An error occurred opening OpenCBM, aborting...

The weird thing is my Mac can see the ZoomFloppy USB device:

I have the ZoomFloppy directly attached, albeit with a USB C to A adapter as I have only C ports. Any ideas what else I can try?

Moved over from https://sourceforge.net/p/opencbm/feature-requests/27/:

Currently, the tape tools (opencbm/tape/) rely on a Windows environment to even compile. For example, opencbm/tap/lib/cap/cap.h even includes Windows.h.

Reorganise the code so that the tools compile on Windows and on other platforms.

For the FreeBSD ports, I have the need to build plugin-xa1541 in isolation. So far, this worked with something like this:

gmake CC=cc SUBDIRS_PLUGIN_XA1541=opencbm/lib/plugin/xa1541 plugin-xa1541
gmake CC=cc SUBDIRS_PLUGIN_XA1541=opencbm/lib/plugin/xa1541 install-plugin-xa1541

Now, I assume after b8af366 -- this also builds and installs the opencbm lib. I could work around by just deleting these unwanted files after staging, but that's not the best solution. Is the dependency causing this really needed to correctly support parallel make? I have to admit I only partially understand your build system :)

The reason for this need is that application packages should never include a kernel module, and as this plugin depends on the kernel module, I end up with 3 packages -- opencbm itself, the kernel module and the xa1541 plugin. I assume a simple way to build it in isolation would come handy for Linux packagers as well.

While analyzing the situation, I found there are some things in SUBDIRS_OPTIONAL, I assume they are never built by default? Should I attempt to package them as well, and is there some documentation on their purpose?

Thanks and BR,
Felix

Moved from https://sourceforge.net/p/opencbm/feature-requests/5/:

In a code snippet that I wrote sometime in 1998 I sent
the basic idea of a disk change detector to Joe
Forster, whose code later found its way into cbm4win.
In my original proposion the 6502 floppy code stub
could do some signalling via the IEC bus lines CLOCK
and DATA with the states:

'old disk is in'
'new disk is in'
'disk is out'

and
'unknown status'

cbmctrl detect now could make use of such a stub
implementation with the user features:

cbmctrl detect (wait for a disk exchange)
cbmctrl detect chg (same as before, default)
cbmctrl detect in (wait, until any disk is
inserted, either the old
one or a new one)
cbmctrl detect out (wait until the currently
inserted disk is removed)

Joe changed the stub routine to tell the internal state
via protocoll routine instead of only signalling via
the DATA and CLOCK lines, but I long forgot the exact
reason, why he did so.

https://sourceforge.net/p/opencbm/bugs/17/

After analysing an issue with cbmforng at an users 1571,
it was concluded that again the "1571 mysteries" bug
occured. For more read:

http://listserver.jonet.org/mailman/private/cbm4win/2005-May/000699.html
http://www.softwolves.pp.se/misc/arkiv/cbm-hackers/10/10471.html

Although cbmforng (as well as cbmformat) got fixes
included for such a case, it seems that there is not
enough delay between switching back from writing into
read mode again.

But I don't want to give even bigger delays as a general
fix, since it makes cbmforng slower and slower on all
drives, the 1541, 1541-II, 1570 and 1571cr too. On
these the fix not needed at all.

Another possibility for a fix may be to do that delay
on-demand only. Only then, when the verifier detects
that the wrong or a corrupted SYNC makr is read back, it
does delay for a complete sector (header with data
block) and tries the test again...
This will become somewhat difficult to code but may
worth a try.

Question: is the xum1541cfg in this OpenCBM repo a distinct fork from https://github.com/silverdr/xum1541cfg ? It seems that other version includes a devinfo command that this one does not. If it is distinct, can/should improvements from that other repo be merged here? Thank you.

https://sourceforge.net/p/opencbm/bugs/44/

Reading PRG files of file sizes 1 or 2 produces with e.g. "cbmcopy -@xum1541 -v -r 9 file-1-byte" (PRG file) creates a file of size 4 on the host side. Beside the single byte contained within the PRG file, the bytes 0x00 0x02 and then again the first byte are appended.

Currently only PRG files were tested, no investigations were done, if this also happens with SEQ files or what's the result, when a PRG file is opened as SEQ file or read by using other parameters changed (alternative secondary address or so).

Presumably this bug has something to do with PRG load addresses. On the other side, writing such 1-byte files or 2-byte files from the host to disk does work fine as verified with a d64copy dump and checking the contents with a HEX editor.

As discussed in the cbm4win developers mailing list,
check out (private access only):

http://listserver.jonet.org/mailman/private/cbm4win/2006-March/000912.html
http://listserver.jonet.org/mailman/private/cbm4win/2006-March/000914.html

In short:

Start transferring the first sector for the
first track by sending it to the floppy
The floppy code has some "bookholder" (?)
code, where it denotes, which sector number
is transferred last
The floppy write the block to disk
The host just sends the next sector with the
predefined interleave, even if the factor is
not adjusted to its best

The floppy code now constantly reads the tracks
sector headers and looks for the right number.

If the currently read sector number is
not the right one:
read out the sector number
maybe decode it fully along with
other data from the sector header
send the sector data and maybe other
values back to the host
on the host:
do a decent calculation to
determine the new best interleave
value; make use of cushioning
If the currently read sector number is
the right one, write the block data to
disk and report either
simply an OK status
the sector number of the just written
sector (same as above)

an interleave adaption value of +-0
(similar to OK status)

Bookholding of how many times the interleave
factor had to be adjusted up and/or down may
lead to a more or less stable value that a)
will not be adapted any further and b) gives
the best overall performance over the whole
disk transfer, even if sometimes a sector is
just missed because of a slightly too small
interleave factor value.

Do express interleave values as radians.
Alternatively make use of the modulo operation
Maybe let the code decide to throw away a just
transferred block, if the right sector to write
that data to was just missed, because that could
be faster in respect to the whole transfer.

Is there something like this:

1 iec to connect to a real c64
1 usb to connect to a pc.

purpose:
let the pc to emulate a drive or printer so the C64 things there's is a 1541 connectd.. in this way saving from the C64 will just create G64 or similar disks and it would even be possible to share directories from a pc.

I was thinking that maybe an ftdi232r is all that is needed...

any thoughts?

Make the cbmctrl detect more flexible:
https://sourceforge.net/p/opencbm/bugs/16/

This weekend, I ported the kernel module to FreeBSD and was hoping not to touch any other code, which unfortunately didn't work because of the way ioctls are used:

1. All ioctls are defined as operations without data (only _IO() macros are used, no _IOW(), _IOR(), _IOWR()) and calls that need to pass data to the driver just do it without declaring it. While this seems to work on Linux, in FreeBSD, the data isn't received at the driver side.
2. For reading data from the driver, the ioctl() return value is used. This doesn't work on FreeBSD either, ioctl() will only return 0 or -1 with errno set.

So, In my ported driver, I defined the ioctls correctly and adapted the code in the plugin. It works, but it would be much nicer to have them defined correctly upstream. Of course, the Linux module would need some changes for this as well. I can't do them myself because I have no Linux machine on metal for testing right now. But I could prepare a patch for the plugin code which someone with a Linux machine could apply and adapt the driver there?

Finally, the parburst calls read and write directly to/from userspace memory. AFAIK, this won't work on all architectures, so I'd like to change this as well by having an in-kernel buffer that's large enough -- what do you think about that?

For anyone interested, here's the ported driver: https://github.com/Zirias/opencbm-driver-freebsd -- but as explained above, it will only work with a patched OpenCBM right now.

I've just discovered that if I run cbmctrl detect it will segfault if I don't have a ZoomFloppy connected:

$ cbmctrl detect
error: no xum1541 device found
Segmentation fault: 11

I've tried to compile it with debugging symbols enabled but I'm having a hard time getting GDB on my Mac to find any debugging symbols. It might be easier to try and reproduce this on a Linux machine.

First of all, thank you guys for pulling my FreeBSD-specific patches so quickly :) I just updated the FreeBSD ports for OpenCBM here:
https://www.freshports.org/comms/opencbm/
https://www.freshports.org/comms/opencbm-kmod/
https://www.freshports.org/comms/opencbm-plugin-xa1541/

The ports (and official packages built from them) are confirmed to work fine by a few people. So, I would suggest to change the docs to recommend using them for FreeBSD. The main reason is, for the average user, building and installing from official ports is a lot easier :) If you have any comments on them or think I did something wrong, please let me know. I will do my best to keep these ports always up to date!

Furthermore, the docs currently claim that on FreeBSD, only USB cables are supported. This is no longer true -- at least for me, it works fine with an XMP-1541 cable connected to my trusty old 1541 :) Although I still don't know whether anyone other than me ever tried so far, I'd suggest to change this in the docs as well. As soon as my package builder finishes another large build, I'll check myself whether it still works fine on 0.4.99.102, but I'm pretty sure it will :)

I'm not creating a pull request for this as I really don't want to mess with other people's docs! So, just take it as a suggestion.

The ZoomTape readme.txt (section 6) links to the old OpenCBM repo.

Latest OpenCBM

ops@laptop ~/projects/OpenCBM $ git log -1
commit ef2f1f1a250efab16d87103c3dfb29187b662328 (HEAD -> master, upstream/master,    origin/master, origin/HEAD)
Author: Spiro Trikaliotis <[email protected]>
Date:   Sun May 17 21:39:19 2020 +0200

  Add -Werror, calm all warnings

gcc version 9.3.0 gives me this error:

gcc -g -I..//libcbmcopy -O2 -Wall -Werror -I../include -I../include/LINUX -DPREFIX="/usr/local" -DOPENCBM_CONFIG_FILE="/etc/opencbm.conf" -fstack-protector -D_FORTIFY_SOURCE=2 -o main.o -c main.c
In file included from /usr/include/string.h:495,
from main.c:18:
In function ‘strncpy’,
inlined from ‘main’ at main.c:498:33:
/usr/include/bits/string_fortified.h:106:10: error: ‘__builtin_strncpy’ output may be truncated copying 16 bytes from a string of length 16 [-Werror=stringop-truncation]
106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make[1]: *** [../LINUX/prgrules.make:53: main.o] Error 1
make[1]: Leaving directory '/home/ops/projects/OpenCBM/opencbm/cbmcopy'
make: *** [LINUX/Makefile:69: BUILDSYSTEM.opencbm/cbmcopy.all] Error 2

see https://sourceforge.net/p/opencbm/patches/16/.

Has to be checked if everything is still valid, and the latest changes have to be added.

https://sourceforge.net/p/opencbm/bugs/52/

Hello,

i have found a problem in the send_byte function, that in some cases it doesn't wait for DATA_IN(ACK) from Drive, btw. DATA_IN will not be resetted so fast:

--- opencbm-0.4.2a/sys/libiec/sendbyte.c 2006-03-09 18:31:35.000000000 +0100
+++ opencbm-0.4.2a-fix/sys/libiec/sendbyte.c 2013-04-23 23:38:36.000000000 +0200
@@ -83,10 +83,11 @@
cbmiec_release_irq(Pdx);
PERF_EVENT_VERBOSE(0x1059, 0);

• for(i=0; (i<libiec_global_timeouts.T_17_Times) && !(ack=CBMIEC_GET(PP_DATA_IN)); i++)

• for(i=0; (i<libiec_global_timeouts.T_17_Times); i++)
  {
  PERF_EVENT_VERBOSE(0x105A, 0);
  cbmiec_udelay(libiec_global_timeouts.T_17_SEND_FRAME_HANDSHAKE_T_F);

•    if (ack=CBMIEC_GET(PP_DATA_IN)) break;
  

  }
  PERF_EVENT_VERBOSE(0x105B, 0);

Also discussed http://www.forum64.de/wbb3/board2-c64-alles-rund-um-den-brotkasten/board107-sonstiges/board6-daten-bertragung/p732140-opencbm-timeout-bugfix-windowsumsetzung-gesucht-war-xa1541-will-nicht-so-recht/#post732140

For linux i have allready fixed and testet it very well, but for windows i dont't have any programming experience, so i'm not able to build it new. Maybe you can build us a new windows version including this fix.

Many Thanks!

Regards

kbr

Hello,

I am not convinced that this is actually a fix to a bug, or if your transistors are just too slow.

Anyway, I will investigate on this. Can you also send me the Linux version of your patch?

Spiro

Ok, let's name it an enhancement to use cheeper transistors, but at this time you have to wait at least 100µs for the BETWEEN BYTE TIME, so it doesn't hurt to wait at least 100µs after releasing DATA.

Here the linux fix:

--- opencbm-0.4.2a/sys/linux/cbm_module.c 2007-11-11 18:16:54.000000000 +0100
+++ opencbm-0.4.2a-fix/sys/linux/cbm_module.c 2013-04-23 00:35:33.000000000 +0200
@@ -344,8 +344,9 @@
}
local_irq_restore(flags);

•   for( i = 0; (i < 20) && !(ack=GET(DATA_IN)); i++ ) {
  

•           udelay(100);
  

•   for( i = 0; (i < 20); i++ ) {   // wait at least once
  

•           udelay(100);            // to give DATA_IN time to release
  

•           if (ack=GET(DATA_IN)) break;
    }
  
    DPRINTK("ack=%d\n", ack);
  

Many thanks in advance!

https://sourceforge.net/p/opencbm/bugs/33/

In parallel to the reported "1571 mysteries" bug for the OpenCBM formatters, there seems to exist similar behavior, when the formatters are used with a 1541-II disk drive that contains a mechanism from JPN Corp. See also:

http://sourceforge.net/tracker/index.php?func=detail&aid=1467581&group_id=122047&atid=692219
http://sourceforge.net/tracker/index.php?func=detail&aid=1467583&group_id=122047&atid=692219

With the 1541-II (JPN Corp.) and either cbmformat or cbmforng, the formatting process produces "SYNC fail" conditions for several tracks. This leads to many repetitions. Mostly the disk format is aborted after 5 such failures.

This was tested with one 1541-II mainboard and two different JPN Corp. mechanisms connected to that board.

With the 1541-II (JPN Corp.) the bug can be worked around by giving the "-c" option. No other options has a similar influence on the error result.

In contrast, the 1571 mysteries bug could be worked around by using the "-o" option. Therefore it is suspected that the real source for the 1541-II (JPN Corp.) bug is different to the one from the 1571 drives.

Today I got another 1541-II with JPN Corp. mechanism, here it is named "Digital Systems Inc., model: DS-50F". The formatting failure symptoms are as following:

With the next generation formatter, the process fails as described above with:
cbmforng -sx 8 disk,id (aborts somewhere at track 24)
cbmforng -vsx 8 disk,id (aborts after track 16)
cbmforng -vosx 8 disk,id (aborts after track 28)

Formatting ends without abort for higher retry counts:
cbmforng -vsx -r 20 8 disk,id

The old generation formatter works better and does not abort with this mechanism, but several tracks need a second formatting try:
cbmformat -vpsx 8 disk,id (no abort)
cbmformat -vopsx 8 disk,id (no abort)
cbmformat -psx 8 disk,id

I just updated my system to Ubuntu 20.04. Now I get crashes with the latest OpenCBM from github

ops@s761:~/OpenCBM$ git log -1
commit 52d435cfbdc33569d6d4bba1271ce9ed757edf05 (HEAD -> master, origin/master, origin/HEAD)
Author: Spiro Trikaliotis <[email protected]>
Date:   Sat May 16 23:32:14 2020 +0200

Works OK

ops@s761:~/OpenCBM$ cbmctrl status 9
00, ok,00,00

Works OK

ops@s761:~/OpenCBM$ cbmctrl dir 9
0 ."test/demo 12/84 " 84 2a
11   "how to use"       prg   
8    "how part two"     prg  
8    "header change"    prg  
409 blocks free.             
00, ok,00,00

Crash

ops@s761:~/OpenCBM$ cbmctrl detect
*** stack smashing detected ***: terminated
Aborted (core dumped)

Crash

ops@s761:~/OpenCBM$ d64copy 9 image.d64
*** stack smashing detected ***: terminated
Aborted (core dumped)

I can't get d64copy to work with the latest OpenCBM. I'm using XM1541 cable on 64 bit Linux Machine.

d64copy 9 image.d64 just hangs and the following messages can be found from system log:

May 20 17:59:30 laptop kernel: cbm_write: device not present
May 20 17:59:30 laptop kernel: cbm_write: device not present
May 20 17:59:30 laptop kernel: cbm_write: device not present
May 20 17:59:30 laptop kernel: cbm_write: device not present
May 20 17:59:30 laptop kernel: cbm_write: device not present
May 20 17:59:30 laptop kernel: cbm_write: device not present
May 20 17:59:30 laptop kernel: cbm_write: device not present
May 20 17:59:30 laptop kernel: cbm_write: device not present
May 20 17:59:30 laptop kernel: cbm_write: device not present
May 20 17:59:30 laptop kernel: cbm_write: device not present
May 20 17:59:30 laptop kernel: cbm_write: device not present
May 20 17:59:30 laptop kernel: cbm_write: I/O error
May 20 17:59:30 laptop kernel: cbm_write: I/O error
May 20 17:59:30 laptop kernel: cbm_write: device not present
May 20 17:59:30 laptop kernel: cbm_write: device not present
May 20 17:59:30 laptop kernel: cbm_write: device not present
May 20 17:59:30 laptop kernel: cbm_write: device not present
May 20 17:59:30 laptop kernel: cbm_write: device not present
May 20 17:59:30 laptop kernel: cbm_write: device not present
May 20 17:59:30 laptop kernel: cbm_write: device not present

Other commands like cbmctrl detect, cbmctrl status 9 and cbmctrl dir 9 work fine.

I'm preparing the updated FreeBSD port for 0.4.99.103 (good news, so far it seems no single patch will be necessary!) and I'm wondering whether this in the description is still correct:

WWW: http://opencbm.sourceforge.net/

Right now, it redirects to another page (should I reference that directly), but it still shows 0.4.99.99 as the latest version, therefore I'm not sure about it? Thanks for your input :)

Taken over from https://sourceforge.net/p/opencbm/feature-requests/13/:

cbmcopy should support wildcards ("*" and "?") itself
instead of relying on the shell in doing it.

At least I would like to see, that cbmcopy gets able to
handle filename at Commodore device with wildcards.
This is needed because no host shell system would be
able to expand wildcards for files on external devices.
And if implementing wildcard support for external
device why not completing wildcard support for local
files too?

I have to admit that such behaviour would end up in
such ugly stuff comparable to unzip, where you have to
quote strings with wildcards in it when you are working
on unixoide systems. But I would appreciate it much.
Maybe we could use some free PCRE library (perl
compatible regular expressions)?

Group changed to "far future" and priority lowered to 3,
because cbmcopy should be rewritten from scratch to use
d64copy-alike block getter/setter routines and do all the
file handling stuff on its own. Maybe this feature can be
integrated with such a rewrite.

Moved from https://sourceforge.net/p/opencbm/feature-requests/6/:

Now that cbm4win / cbm4linx is able to automagically
select an appropriate transfer protocol by detecting
several parameters like:

• is a parallel cable connected
• is more than one device connected on the same bus
• is the device supported by any of the impemented
  turbo loaders

we normally would not need the dedicated transfer
protocol selection swicthes anymore.

But there are cases where a user may want to select
another turbo protocol or even the original IEC protocol.

In such cases the autodetection can and should be used
to warn the user, if a dedicated turbo protocol cannot
be used with a decent cable/dreive configuration. Maybe
the warning could be made an error even more.

The tittle says it all.
I have to find out if I can use libwdi to solve this issue.

Taking over this part from the SF tracker no. 48:
https://sourceforge.net/p/opencbm/bugs/48/

Taken over from https://sourceforge.net/p/opencbm/feature-requests/25/:

From http://www.forum64.de/index.php?thread/65795-an-alle-die-mit-vice-arbeiten-oder-sonst-einem-emulator/&postID=1031196#post1031196:

Be able to re-read a track on an existing image. In case an error occurs in a block that was previously read correctly, leave that block as is.
This is interesting especially in case of damaged disks, where one wants to retry specific blocks until they can be read.

Using the bundled Portfile (and changing the git URL from git://git.code.sf.net/p/opencbm/code to https://github.com/OpenCBM/OpenCBM.git) I'm unable to get things to build. It seems to be failing on xum1541cfg:

...
:info:build /Applications/Xcode.app/Contents/Developer/usr/bin/make -C xum1541cfg -f LINUX/Makefile all
:info:build make[1]: Entering directory `/opt/local/var/macports/build/_Users_matt_Documents_ports_emulators_opencbm/opencbm/work/code/xum1541cfg'
:info:build gcc -g -O2 -Wall -I../include -I../include/LINUX -DPREFIX=\"/opt/local\" -DOPENCBM_CONFIG_FILE=\"/opt/local/etc/opencbm.conf\"  -g -I /opt/local/include -I dfu-programmer-0.5.4/src -Wall -o main.o -c main.c
:info:build main.c:33:10: fatal error: 'usb.h' file not found
:info:build #include "usb.h"
:info:build          ^
:info:build 1 error generated.
:info:build make[1]: *** [main.o] Error 1
:info:build make[1]: Leaving directory `/opt/local/var/macports/build/_Users_matt_Documents_ports_emulators_opencbm/opencbm/work/code/xum1541cfg'
:info:build make: *** [BUILDSYSTEM.xum1541cfg.all] Error 2

This works:
make -j1 -f LINUX/Makefile opencbm plugin-xum1541 plugin-xu1541
This doesn't:
make -j8 -f LINUX/Makefile opencbm plugin-xum1541 plugin-xu1541

It fails with:

(...)
make[1]: Leaving directory '/home/user/test/opencbm/OpenCBM/opencbm/libtrans'
gcc -g -O2 -Wall -I../include -I../include/LINUX -DPREFIX=\"/usr/local\" -DOPENCBM_CONFIG_FILE=\"/etc/opencbm.conf\"  -o ../libd64copy/s2.o -c ../libd64copy/s2.c
gcc cbmctrl.o pport.o -o cbmctrl -L../lib -L../arch/linux -L../libmisc -lopencbm -larch -lmisc
/usr/bin/ld: ../libmisc/libmisc.a(getpluginaddress.lo): in function `plugin_load':
getpluginaddress.c:(.text+0x10): undefined reference to `dlopen'
/usr/bin/ld: getpluginaddress.c:(.text+0x18): undefined reference to `dlerror'
/usr/bin/ld: ../libmisc/libmisc.a(getpluginaddress.lo): in function `plugin_get_address':
getpluginaddress.c:(.text+0x51): undefined reference to `dlsym'
/usr/bin/ld: ../libmisc/libmisc.a(getpluginaddress.lo): in function `plugin_unload':
getpluginaddress.c:(.text+0x61): undefined reference to `dlclose'
collect2: error: ld returned 1 exit status
make[1]: *** [../LINUX/prgrules.make:61: cbmctrl] Error 1

Running the same command again seems to finish the compilation.

https://sourceforge.net/p/opencbm/bugs/62/ - see attachment there!

From
http://www.forum64.de/index.php?thread/65795-an-alle-die-mit-vice-arbeiten-oder-sonst-einem-emulator/&postID=1031780#post1031780

When reading broken disks with a XU1541, the following happens:

usb errors are shown on the screen
the resulting image contains broken data that does not seem to be anyhow related to the data that is read

It is unclear if the errors only happen with the XU1541, or also with the XUM1541 and/or XA1541.

d64copy -t original gives me many read errors. d64copy -t serial1 and d64copy -t serial2 work ok with the same disk.

Moved from https://sourceforge.net/p/opencbm/feature-requests/8/:

As proposed by Spiro, bigger amounts of code within the
drivers of cbm4linux and cbm4win should be
restructured, so that common parts of the code base can
be shared between these two.

Since this requires many restructurations, it should be
scheduled for the overnext release version.

A short suggestion to merge nibtools source code and include its binaries with builds of OpenCBM.
One depends on each other and with all the issues at the moment on Windows, USB2/USB3 missing device with libusb1 etc. it gets harder to understand where problems lies on.

Hello,

I hope I am not taking advantage of this list should it be only for bugs while this might sounds more like a support call. So have followed the instructions to compile and install on an old Linux Slackaware 14.1 distro with a parallel port. To cut the long story short once I do:

modprobe -v cbm

1. I get the 1541 drive light flash
2. And the log is:
   `Jun 25 16:16:35 puppypc10743 user.warn kernel: cbm_init: using active (XA1541) cable (auto), irq 7

Jun 25 16:16:35 puppypc10743 user.warn kernel: cbm: resetting devices

Jun 25 16:16:35 puppypc10743 user.warn kernel: cbm: waiting for free bus...

Jun 25 16:16:36 puppypc10743 user.warn kernel: cbm: bus is free!`

So long so good. If I issue cbtctl rest then I am getting "cbm: quitting because of time out" and this is fat a I have been. I am wondering if I need to compile with -DDIRECT_PORT_ACCESS

My lsmod is giving me:
parport_pc 20273 1
parport 24249 2 cbm,parport_pc

/etc/modules.conf
alias parport_lowlevel parport_pc

Any idea as what am I missing will be greatly appreciated.

Kind Regards
Yiannis

Hi, after last update that was working but with assertion failed error, now version 0.4.99.102 give me those errors:
iMacports % cbmctrl detect

USB error: LIBUSB_ERROR_OTHER
libusb/xum1541:20/11: Operation timed out

*Note i'm using Pi1541 but was working fine previously

https://sourceforge.net/p/opencbm/bugs/36/

I have tested d64copy, StarCommand & WarpCopy.

StarCommand & WarpCopy writes ALL error-bytes to
the d64-file.

d64copy does NOT write all error-bytes... only some
of them. (Possible missing the sectors with crc-error)

Please fix this problem, as it looks like
the releases on a d64 are working - but are NOT!!!

Hello,

I have already seen your (?) thread on http://noname.c64.org/csdb/forums/?roomid=10&topicid=63348. I even tried to answer you, but until now, I was not able to register there.

It would be good to be able to investigate the bug by having a working example. Unfortunately, in the thread at CSDB , I can read that you do not own mnib. Thus, you cannot send me a .g64 or .nib file, right?

Either way, it would help me if you could send me a .D64 as generated by d64copy, and a D64 as generated by another tool.

Is the generated D64 from d64copy always exactly the same, or are there differences when running d64copy multiple times?

It would also help if you could me if this problem persists if the option --nowarp is selected. Could you please also test with all the transfer options (-ts1, -ts2), with --warp or --nowarp?

Regards,
Spiro

Since a while there is now a nibtools image added with a certain number of disk errors. Have a look at:

opencbm\internal\testsuite\errored41.txt
opencbm\internal\testsuite\errored41.nib

With this test set we are now able to find out why d64copy (presumable the 6502 code) does overlook some of the existing error type conditions

Taken over from https://sourceforge.net/p/opencbm/feature-requests/24/:

From http://www.forum64.de/index.php?thread/65795-an-alle-die-mit-vice-arbeiten-oder-sonst-einem-emulator/&postID=1031196#post1031196:

Be able to read a specific block only, instead of reading complete tracks. This is interesting especially in case of damager disks, where one wants to retry specific blocks until they can be read.

Taken over from https://sourceforge.net/p/opencbm/feature-requests/20/:

Just wondering if some sort of progress bar could be added into Gui4Cbm4win so when a D64 image is being written it shows some sort of progress bar with Track/Sector counts?

There are two issues:

First: Noone is actually working on Gui4cbm4win anymore - at least, not on the version on this page. I do not even have a development environment for it, so, I cannot do anything on it.

Second: gui4cbm4win uses the OpenCBM tools in a very dump way. I cannt envision a way how this could be accomplished in the first place. OTOH, I have to admit that I never looked into the gui4cbm4win code, thus, it might be easier than I believe.

I will keep this open in case someone wants to work on it, but I cannot promise you anything, I am sorry.

Spiro

I have written a new GUI for the OpenCBM tools. You can find it at http://c64.mvgrafx.net

Every time a issue a command with cbmctrl after it perform the operation correctly on xum1541, this error is displayed every time:

Assertion failed: (config >= 0 && config <= UINT8_MAX), function darwin_set_configuration, file os/darwin_usb.c, line 1260.