17

I'm looking for some (command-line) tools that can transfer host files on a Unix or Linux machine to and from Commodore .D64, .D71 and similar image files in CP/M format. The particular use case I have now is a friend who's got a Commodore 128 and an Ultimate II+ or something similar and we want to develop CP/M software and copy the .COM files to an image so we can test them out on a real Commodore 128.

Note that this must be fully (and ideally, easily) scriptable from the command line so that my build system can automatically generate the final images as part of building the source code. If it isn't obvious how to do this with your suggested tools, it would be helpful to provide some Bash or Bourne shell code that shows how to do it.

I've found a few Windows programs, but very little Unix stuff. So far I've found only CTools 0.4 from this web page, which claims to build under Unix, but the compile fails with being unable to find new.h, which appears to be a Windows-only header file, so I'm not sure what's up with that.

Answers giving commonly-used CP/M or Commodore image manipulation programs that have been tested not to work (so that people don't go wasting time trying to make them work) are also welcome. Bonus points if you can explain why these programs can't be tweaked to work with the Commodore CP/M format.

Improve this question
3
  • 3
    Just FYI, the 1571 does not use Commodore's own disk GCR format in CP/M mode. Rather than that, it has an extra WD1770 disk controller chip that handles standard MFM disks. So it can read disks created by a standard 360KB dual-head double density PC disk drive. So you don't need to create a D71 image.
    – Janka
    Commented Nov 10 at 2:03
  • Ah, that makes sense. Perhaps you could post an answer showing how to use cpmtools or similar to create and put things on to such a disk image?
    – cjs
    Commented Nov 10 at 8:45
  • What ctools does is crumpling the sector lineup of D71 images that way so it maps to plain MFM disks. You can see that from that a complicated mapping is done for MFM (C128) disks and no mapping is done for GCR (C64) disks. — Skip that D71 step completely and produce plain MFM disks with bog standard 40 tracks and nine 512 byte sectors per track with a PC 5¼" disk drive.
    – Janka
    Commented Nov 10 at 22:56

5 Answers 5

Reset to default
25

CTools does work on modern Unix systems, but needs some modifications to build with modern C++ compilers (which seems fair, after all it’s only 27 years old).

Michael Steil has a modified version that compiles without problems (excepting warnings) in his GitHub repo mist64/ctools.

If you want to fix the original code yourself:

  • new.h isn’t a Windows header, it’s obsolete (but still shipped as new.h in Windows C++ compilers); it provided set_new_handler which is now in std and declared in new. To fix that, edit err.cc, replace #include <new.h> with #include <new>, and set_new_handler with std::set_new_handler.

  • tools.cc tries to convert a const char * to non-const without an explicit cast; add one on line 304:

    t = (char *) strrchr(filename, '/');

  • makefile.unx also tries to use regular cc to link, which fails with C++ programs requiring libstdc++; to fix that, run

    make -f makefile.unx CC=g++

    (assuming you’re using g++).

Improve this answer
2
  • 4
    Lol, I just read the question went down the rabbit hole doing all the above, came here triumphantly to post an answer to find that there was already one in the first place. Well done!
    – Andrew Savinykh
    Commented Nov 5 at 4:59
  • 7
    Apparently doing this work is quite popular, because Michael Steil also did it a while back: github.com/mist64/ctools . (I've just tested it, and it compiles fine on Debian 12 with just cd src && make.)
    – cjs
    Commented Nov 5 at 13:09
5

On Debian, there is a cpmtools package:

$ apt-cache show cpmtools
Package: cpmtools
Version: 2.23-4
Installed-Size: 493
Maintainer: Bdale Garbee <[email protected]>
Architecture: amd64
Depends: libc6 (>= 2.34), libdsk4 (>= 1.5.4+dfsg), libncurses6 (>= 6), libtinfo6 (>= 6)
Description-en: Tools to access CP/M file systems
 This package allows access to CP/M file systems similar to the well-known
 mtools package, which accesses MSDOS file systems.
 .
 All CP/M file system features are supported.

The upstream source is here.

Not sure how well this will work with Commodore disk images, basically you need a plain file that represents the blocks (or a device like a floppy).

Edit: After looking at the code for bios.cc in ctools, it looks like the Commodore CP/M formats have some irregular mapping of CP/M blocks to tracks/sectors, which won't work in cpmtools even for raw disk formats, without inserting some similar kind of translation into the code.

Leaving this answer here nevertheless for information.

Improve this answer
8
  • I looked at cpmtools and saw no entry for any Commodore formats in the diskdefs file.
    – cjs
    Commented Nov 5 at 11:17
  • That's why I wrote "I don't know how well this will work". It looks like D71 is a "raw" format, so one could probably add some entry there, if the Commodore CP/M layout is documented somewhere. If you can put a D71 file online somewhere I can give it a try.
    – dirkt
    Commented Nov 5 at 11:52
  • 1
    @cjs If the Commodore file system format is problematic, another way to develop programs may be to use qemu (which has some z80 emulation addons (of varying quality)) to boot the Commodore's CP/M OS. This might be more work initially (if the z80 emul doesn't support basic Commodore physical devices) but gives a possible fallback approach if all else fails.
    – Craig Estey
    Commented Nov 5 at 20:43
  • 2
    If I were in that position, I'd write a libdsk driver that presented the .D64 / .D71 (etc) file as a raw disk image containing only the sectors used by CP/M, and then have cpmtools access it through libdsk.
    – john_e
    Commented Nov 5 at 21:28
  • 1
    @cjs it's not only the varying number (which wouldn't matter if everything was consecutive, though skew handling becomes difficult), it also skips areas that having meaning in the CBM format. As I wrote, irregular.
    – dirkt
    Commented Nov 6 at 17:15
1

Following my own advice, I've added support to LibDsk for .D64 disk images in both native and CP/M formats, and to mkp3fs to generate disks in C64 CP/M format.

It should now be possible to:

  • Build and install libdsk 1.5.21 or later.
  • Build and install taptools 1.1.3 or later.
  • Construct a C64 CP/M disk image with a command like mkp3fs -c64 -type d64cpm output.d64 program.com data.dat readme.txt

The new 'd64cpm' LibDsk backend will also allow cpmtools (if linked with LibDsk) to access D64 disk images containing Commodore 64 CP/M filesystems, using an entry in diskdefs like this:

diskdef c64cpm
  seclen 256
  tracks 34
  sectrk 17
  blocksize 1024
  maxdir 64
  boottrk 2
  os 2.2
  libdsk:format c64cpm
end

Adding the options -f c64cpm -T d64cpm to a cpmtools command line will then allow access to the CP/M filesystem within a D64 file - for example:

cpmls -f c64cpm -T d64cpm test.d64
Improve this answer
1
  • Brilliant! Thanks for all this work!
    – cjs
    Commented Nov 12 at 7:30
1

Use VICE and rdcbm21 (use may use lhasa for this archive) which reads CBM disks on 1541/1571 drives and transfer files to CP/M.

Improve this answer
4
  • 1
    I've clarified the question to add: "Note that this must be fully (and ideally, easily) scriptable from the command line so that my build system can automatically generate the final images as part of building the source code. If it isn't obvious how to do this with your suggested tools, it would be helpful to provide some Bash or Bourne shell code that shows how to do it."
    – cjs
    Commented Nov 6 at 4:46
  • @cjs Indeed, I don't know any scriptable C128 emulator.
    – Polluks
    Commented Nov 6 at 10:55
  • maybe some clarification as to what the rdcbm21 link is and how/where to use it, please? file tells me it's PMarc archive data [pm2], with "RDCBM21.COM"
    – scruss
    Commented Nov 6 at 18:53
  • PMARC is a CP/M archiver, so you would download PMAUTOAE from (eg) zimmers.net/anonftp/pub/cpm/archivers/index.html and run it under CP/M.
    – john_e
    Commented Nov 7 at 22:20
0

You don't need any of that D71 mumbo-jumbo as you want to use a real-world 1571 disk drive. Those drives have an additional WD1770 disk controller built in so they can read and write bog standard MFM disks formatted and written by a 360KB 5¼" PC disk drive.

So produce a CP/M disk with your PC disk drive as you would do for any other CP/M system. 40 tracks per side with nine 512 byte sectors per track should do the trick, otherwise 40 tracks per side with sixteen 256 byte sectors per track.

Improve this answer
10
  • I should have noted that I also need .D64 images, if that makes any difference to your answer. (I've updated the post.) The rest I don't quite understand: there are no actual floppy drives involved here: I'm producing an image file that's given to a device that emulates a CBM drive for a real C128. And your post doesn't give the details of what program and parameters I use to produce the correct format.
    – cjs
    Commented Nov 11 at 2:24
  • You wrote “I have now is a friend who's got a Commodore 128” and for CP/M mode that means they need the 1571 too (or a C128D with a built-in 1571 drive). Otherwise it's not going to work. The C128 CP/M mode uses special commands in the drive that utilize the WD1770 controller. The GCR controller is not used in CP/M mode.
    – Janka
    Commented Nov 11 at 9:49
  • So you need to produce MFM disks for the real thing. Standard 360KB double sided 40-track nine 512 byte sector disks. Same as for MS-DOS. With a PC disk drive. — If you want to do the same in an emulator that doesn't support plain MFM disk images but only D71 images, you have to produce special D71 disk images just for that particular emulator that this emulator unfolds as MFM disk images internally.
    – Janka
    Commented Nov 11 at 9:52
  • Ah, I got it. You want to use the Ultimate II instead of a 1571. I'm afraid this isn't going to work as it does not emulate the WD1770 MFM controller as far as I am informed.
    – Janka
    Commented Nov 11 at 9:57
  • I checked, and the Ultimate II+ with the latest firmware supports all the U0 burst commands so it should work. You have to check its documentation to find out how it expects the D71 images to be packed so that they unfold as MFM images internally.
    – Janka
    Commented Nov 11 at 10:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .