Giter VIP home page Giter VIP logo

nibtools's Introduction

OpenCBM

Win 7/8/10, and Linux/i386/AMD64 kernel driver and development library to control serial CBM devices, such as the Commodore 1541 disk drive, connected to the PC's parallel port via a XM1541 or XA1541 cable. Fast disk copier included. Successor of cbm4linux. Also supports the XU1541 and the XUM1541 devices (a.k.a. "ZoomFloppy").

What is OpenCBM?

The popular Commodore 8-bit home-computers like the C-64 and the VIC-20 are using a custom serial bus to talk to attached devices (disk drive, printer). This proprietary serial bus protocol is not natively supported by modern hard- or software.

OpenCBM provides an interface to this so-called IEC bus at the level of simple TALK and LISTEN commands, similar to the one provided by the Commodore kernel routines. Additionally, some higher and lower level bus control is available as well, allowing for full control of the bus.

The CBM serial devices are connected to the PC either to the parallel port via an XM1541 or XA1541 cable and, optionally, an XP1541 or XP1571 add-on cable. Alternatively, more modern USB cable solutions like XU1541 or XUM1541 (a.k.a. ZoomFloppy) are supported.

OpenCBM has a plugin concept which allows to additionally add custom build cables.

OpenCBM can be used on PCs on Linux and Windows (all cables). Additioanlly, USB based cables are supported on FreeBSD and on Mac OS X.

Supported Operating Systems

OpenCBM supports the following operating systems:

  • For USB based cables: Any Linux, FreeBSD or MacOS X variant that support libusb-1.0 should be supported. Linux, FreeBSD and Mac OS X have been explicitly tested. For compatibility reasons, also libusb-0.1 is supported at the moment, but that support will be dropped in sme future version.
  • For parallel port based cables: Linux 5.x, 4.x, 3.x and 2.6 variants, FreeBSD 11.x and newer. Linux 2.0, 2.2 and 2.4 might still work, but have not been tested for ages. For Linux, i386 and AMD64 architectures are supported.
  • For parallel port based as well as USB based cables: Windows NT 4.0, 2000, XP and Server 2003, Vista, 7 and 8. For USB based cables, NT 4.0 is not supported, though. The i386 architecture a.k.a "x86" ("32 bit") is fully supported; additionally, 64 bit Windows ("x64", "x86_64") versions are supported. Itanium-based Windows ("iA64") are not supported anymore, though.

Supported CBM hardware

Currently, opencbm supports the following CBM devices:

  • VIC 1541, VIC 1540 (all variants, including clones)
  • VIC 1570, VIC 1571 (including the 1571CR and the 1571 inside of a C128DCR)
  • VIC 1581 (not with d64copy ( d64copy), not with cbmformat ( cbmformat) or cbmforng ( cbmforng))
  • other CBM IEC drives, printers, and compatibles (only with cbmctrl ( cbmctrl))
  • VIC 8250, 8050, 4040, 2031, SFD 1001, and possibly other IEEE drives with an IEC to IEEE converter (for example, IEC2IEEE from Jochen Adler, cf. http://www.nlq.de/, or with a ZoomFloppy extension that lets you use IEEE devices directly.
  • VIC 1530 (a.k.a. C2N) tape device, and VIC 1531 with an appropriate adapter; both are supported by ZoomTape, only.

Further reading

The current manual, including installation instructions, can be read online at http://opencbm.trikaliotis.net/.

A Doxygen output of the sources (for developers) (still work-in-progress) can be found at http://opencbm.trikaliotis.net/doxygen/.

The mailing lists of OpenCBM can be found at https://sourceforge.net/p/opencbm/mailman/.

Bug tracker are available at https://github.com/OpenCBM/OpenCBM/issues

Contributions

We explicitly welcome outside contributors. If you feel like you can add to the projects, feel free to ask.

Maintainers

@spiro-trikaliotis, @go4retro.

License

OpenCBM is published under the GPLv2.

nibtools's People

Stargazers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Watchers

avatar avatar avatar avatar avatar

Forkers

hartkopp ataru-moroboshi pokefinder-org commodore-bench ozw1z5rd ajunlonglive dverbeeck bhase gneiss15

nibtools's Issues

rig_tracks function causing destruction of the track data following a "short" track

The rig_tracks function checks for tracks being shorter than the respective track capacity, and then attempts to fill up the short track with 0x55 bytes up to the track's capacity.

However, there is a mistake in the size/count argument for the memset invocation:

if(track_length[track] < capacity[track_density[track]&3])
{
	memset(track_buffer + (track*NIB_TRACK_LENGTH) + track_length[track], 0x55, capacity[track_density[track]&3]);
	//printf("Padded %d bytes\n", capacity[track_density[track]&3]-track_length[track]);
	track_length[track] = capacity[track_density[track]&3];
}

The size/count argument should be capacity[track_density[track]&3] - track_length[track] instead of just capacity[track_density[track]&3]. The commented out printf statement got it right... ;-)

libusb_error_io

Hi,

I am experiencing problems using the nibtools. On every operation (reading or writing) I get this error:

USB error in xum1541_wait_status: LIBUSB_ERROR_IO
USB error in xum1541_ioctl cmd: LIBUSB_ERROR_OTHER

I am running the tools with macOS (Big Sur 11.4) on an intel Mac. I am Using a Teensy-based XUM1541 interface with a 1570 floppy.
I have the latest openCBM-Package installed, which works fine.

I installed nibtools with this guide:

brew install cc65
svn co [email protected]:OpenCBM/nibtools.git
cd nibtools.git/trunk
make -f GNU/Makefile linux
cp nibread /usr/local/bin
cp nibwrite /usr/local/bin
cp nibconv /usr/local/bin
cp nibscan /usr/local/bin
cp nibrepair /usr/local/bin
cp nibsrqtest /usr/local/bin

Before I get the error following infos show up:

nibread - Commodore 1541/1571 disk image nibbler
(C) Peter Rittwage
http://c64preservation.com
Built Jun 8 2021 22:15:35

Drive Version: 73,CBM DOS V3.0 1570,00,00
Drive type: 1571
Bumping...
Initializing
Sending 1571 SRQ support code...
Uploading floppy-side code ($0454 bytes, $300-$754)...done.
Starting custom drive code...Started!
Testing communication...done.
Passed basic communication test.

The drive starts spinning and stays spinning until I do a cbmctrl reset.

nibconv does not support half-tracks when output is a NIB file

When converting a G64 to NIB format with nibconv, half-tracks in the G64 file are read, but they are ignored when writing the data out to a NIB file.
Curiously, i found this in nibconv.c:

nibtools/nibconv.c

Lines 187 to 199 in 2fbb49f

else if ((compare_extension(outname, "NBZ"))||(compare_extension(outname, "NIB")))
{
if(skip_halftracks) track_inc = 1;
else track_inc = 2; /* yes, I know it's reversed */
/* handle cases of making NIB from other formats for testing */
if( (compare_extension(inname, "D64")) ||
(compare_extension(inname, "G64")))
{
rig_tracks(track_buffer, track_density, track_length, track_alignment);
}
if(!(file_buffer_size = write_nib(file_buffer, track_buffer, track_density, track_length))) exit(0);

Since the value of skip_halftracks will always be 0 (there is no skip_halftracks assignment in the entire source code for nibconv aside from the initial zero value assignment in the main method) and neither rig_tracks nor write_nib altering track_inc, nibconv will never write half-tracks when the output file format is NIB/NBZ.

The source comment says that's intentional, but i honestly can't understand what the reasoning behind this is. Whether half-tracks should be skipped should depend either on the input file being a D64, or being a G64 file with all file offsets for half-tracks being 0x0000, or more fundamentally (and logically more sound, imo) should depend on all half-tracks having a length of 0 in the track_length array, i believe.

I would have made a pull request, but that source comment makes me hesitate, as i can't shake the feeling that this comment might be an indication of an ongoing larger code overhaul that has not been committed to GitHub yet...

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.