gryf/uc1541

uc1541 is a virtual filesystem for Midnight Commander. This extfs provides an access to disk image files for the Commodore VIC20/C64/C128. It requires the utility c1541 that comes bundled with Vice, the emulator for the VIC20, C64, C128 and other computers made by Commodore.

Midnight Commander virtual filesystem for C64 disks

This extfs provides an access to disk image files for the Commodore VIC20/C64/C128 for Midnight Commander. It requires the utility c1541 that comes bundled with Vice, the emulator for the VIC20, C64, C128 and other computers made by Commodore.

Features

• View, remove, copy files in and out of the image,
• Support for read from and write to d64, d71 and d81 images,
• Gzipped disk images support,
• On fly characters remapping (see below).

Remarks

Due to different way of representing file entries on regular Commodore disk images, there could be issues with filenames that are transfered from/to the image. Following rules was applied to represent a single file entry:

1. An extension is attached to the end of a filename depending on a file type. Possible extensions are: prg, del, seq, usr and rel.
2. Every non-ASCII character (which could be some of characters specific to PET-ASCII, or be a control character) will be replaced by dot (.), since c1541 program will list them that way.
3. Every slash character (/) will be replaced by pipe character (|).
4. Leading space will be replaced by tilda (~).

While copying from disk image to filesystem, filenames will be stored as they are seen on a listing.

While copying from filesystem to disk image, filename conversion will be done:

1. Every $ and * characters will be replaced by question mark (?)
2. Every pipe (|) and backslash (\) characters will be replaced by slash (/)
3. Every tilde (~) will be replaced by a space
4. prg extension will be truncated

Representation of a directory can be sometimes confusing - in case when one copied file without extension it stays there in such form, till next access (after flushing VFS). Also file sizes are not accurate, since directory entries in CBM format have sizes stored as 256 bytes blocks.

Screens below shows how it looks like on real C64 machine and its representation on Midnight Commander listing.

In media directory you can find the test.d6z gzip compressed D64 image file.

Rquirements

• Python 3.6 or higher (checked recently with 3.11)
• Vice installation (c1541 program in path)

Installation

• copy uc1541 to ~/.local/share/mc/extfs.d/
• add or change entry for files handle in ~/.config/mc/mc.ext:

# Disk images for Commodore computers (VIC20, C64, C128)
[d64]
Regex=\.(d64|d71|d81)$
RegexIgnoreCase=true
Open=%cd %p/uc1541://
View=%view{ascii} c1541 %f -list

[d6z]
Regex=\.(d[678]z)$
RegexIgnoreCase=true
Open=%cd %p/uc1541://
View=%view{ascii} t=$(mktemp); zcat %f > ${t}; c1541 ${t} -list 2>/dev/null; rm ${t}

Configuration

Here are specific for this script variable, which while set, can influence script behaviour:

• UC1541_DEBUG - if set, uc1541 will produce log in /tmp/uc1541.log file.
• UC1541_VERBOSE - if set, script will be more verbose, i.e. error messages form c1541 program will be passed to Midnight Commander, so that user will be aware of error cause if any.
• UC1541_HIDE_DEL - if set, no DEL entries will be shown.

Changelog

• 3.6 Fixed line matcher for directory entries.
• 3.5 Drop Python2 support.
• 3.4 Code cleanup. Removed dummy logger class and sys.args based argument parsing.
• 3.3 Added support for .d71 and .d81 disk images.
• 3.2 Changed shebang to python executable instead of python3
• 3.1 Argparse on Python3 have different behaviour, where if no subcommand is provided, it will pass anyway. Fixed.
• 3.0 Added beta quality Python3 support
• 2.8 Treat non standard discs a bit better
• 2.7 Added support for gzipped disk images
• 2.6 Added mkdir and run handling (or rather lack of handling :). Minor refactoring.
• 2.5 Fixed bug with filenames started with a '-' sign.
• 2.4 Fixed endless loop bug for reading directory in Python implemented directory reader.
• 2.3 Re added and missing method _correct_fname used for writing files into d64 image.
• 2.2 Fixed bug(?) with unusual sector end (marked as sector 0, not 255), causing endless directory reading on random locations.
• 2.1 Fixed bug with filenames containing slash.
• 2.0 Added reading raw D64 image, and mapping for jokers. Now it is possible to read files with PET-ASCII/control sequences in filenames. Working with d64 images only. Added workaround for space at the beginning of the filename.
• 1.2 Added configuration env variables: UC1541_VERBOSE and UC1541_HIDE_DEL. First one, if set to any value, will cause that error messages from c1541 program will be redirected as a failure messages visible in MC. The other variable, when set to any value, cause del entries to be not shown in the lister.
• 1.1 Added protect bits, added failsafe for argparse module
• 1.0 Initial release

License

This software is licensed under 3-clause BSD license. See LICENSE file for details.

uc1541's Issues

Fix display of about any image please

I tried several d64/d81/d71 images and MANY MANY are shown as empty or loose files compared to a c1541 output.
In this version this virtual filesystem cannot be seen as usable in ANY way - definately.

May sound like a biased rant but you are free to try. Packaging this with midnight commander should be be forbidden and punished.

After putting the latest checkout to /usr/lib/mc/extfs.d/uc1541 (not to forget "apt install python-is-python3" on an uptodate Debian 12 system) opening

http://ftp.pokefinder.org/tmp/wizball.d64

shows no files.

Logging:
2023-11-17 22:18:06,040 DEBUG 621 - Script params: ['/usr/lib/mc/extfs.d/uc1541', 'list', '/Data/torr/wizball.d64']
2023-11-17 22:18:06,049 DEBUG 157 _go_to_next_sector - Going to the track: 18, 1
2023-11-17 22:18:06,049 DEBUG 183 _go_to_next_sector - Next track: 0,255
2023-11-17 22:18:06,049 DEBUG 138 _map_filename - string: b'WIZBALL+12CH/REM''' mapped to: wizball+12ch/rem''
2023-11-17 22:18:06,049 DEBUG 138 _map_filename - string: b'WIZBALL HIGH/REM''' mapped to: wizball high/rem''
2023-11-17 22:18:06,049 DEBUG 153 _go_to_next_sector - End of directory
2023-11-17 22:18:06,049 INFO 379 list - List contents of /Data/torr/wizball.d64
2023-11-17 22:18:06,050 DEBUG 543 _call_command - executing command: c1541 -attach /Data/torr/wizball.d64 -list

Whats wrong here? Even though I find an attempt at replacing "/" with a PIPE VERY wrong, it doesnt even seem to happen here.

Some quick looks at d81 images show "lost files" as well. Shrug? WHY? Is a single made up test.d6z really enough for valid testing and actually shipping to many users?

Really - SO many images show up as wrong - its horrible.

I may be super-biased as I am related to the VICE project but this is in no way better than the old bash stuff.

Proper addition of uc1541 to recent MC versions

The current readme.md of the project has:

regex/.([dD]64|[dD]6[zZ]|[dD]71|[dD]7[zZ]|[dD]81|[dD]8[zZ])$

Recent MC installations require:

Regex=.([dD]64|[dD]6[zZ]|[dD]71|[dD]7[zZ]|[dD]81|[dD]8[zZ])$

though. Probably could even be extended to CMD FD images further but that regex is surely better than the MC system wide default which seems to handle D64 only.
Sorry - didnt find since which MC version the Regex statement changed to "=".

Is it time to go python3?

The plugin does not work with a regular Debian installation unless you have installed the package python-is-python3. From its description:

"Starting with the Debian 11 (bullseye) and Ubuntu 20.04 LTS (focal)
releases, all python packages use explicit python3 or python2
interpreter and do not use unversioned /usr/bin/python at all. Some
third-party code is now predominantly python3 based, yet may use
/usr/bin/python.

This is a convenience package which ships a symlink to point
the /usr/bin/python interpreter at the current default python3. It may
improve compatibility with other modern systems, whilst breaking some
obsolete or 3rd-party software.

No packages may declare dependencies on this package."

python2 is deprecated now by many distributions. Maybe it is a good idea to switch to python3, so it will work out of the box for modern distros?

can you add .d71 .d81 .lnx support in python

not an issue :)
as c1541 already handle decompression of it, it would be nice