LOAD "$",8
SEARCHING FOR $
LOADING
READY.
LIST
0 "DR.J/DELYSID    " DJ 2A
0 "================" DEL
0 "   DR.J/DELYSID " DEL
0 "================" DEL
3 "CRACKTRO        " PRG
6 "HRTRAINER       " PRG
1 "NOTE            " PRG
664 BLOCKS FREE.
╔════════════╗
║ ♠♣♥♦▲▼◄► ║
║ █▄▀▌▐░▒▓  ║
╚════════════╝
$ txt2dirart game.d64 \
    --from-text art.txt \
    -o release.d64

My tools

Small tools I wrote for myself, which turned out to be useful to other people too. All open source, all free.

txt2dirart

One text file in, one disk with directory art out

Version 1.0.2 Windows / Linux / Python MIT
A disk directory with art in it, listed on a real Commodore 64

What the drive prints after LOAD"$",8:

    0 "DR.J/DELYSID    " DJ 2A
    0 "================" del
    0 "   DR.J/DELYSID " del
    0 "================" del
    3 "CRACKTRO        " prg
    6 "HRTRAINER       " prg
    1 "NOTE            " prg

The listing draws a picture. The files still load.

What directory art is

A 1541 directory is a chain of 32-byte entries living on track 18. Each entry has a file type, a start sector, a 16-character name and a block count.

Write an entry whose type is a closed DEL with a block count of zero, and the drive lists it like any other entry, but it owns no sectors, points at no data, and loading it does nothing. It is a free row of 16 characters in the listing. Sixteen characters wide, as many rows as track 18 has room for. That is your canvas.

The scene has been doing this since the eighties. This tool just makes it scriptable.

Why I wrote it

I wanted directory art on a demo disk and could not find a comfortable way to do it from the command line. The existing options either ask you to draw by hand inside a graphical disk editor, or touch the files already sitting on the disk. So I wrote my own. One text file in, one D64 out, and the files that were on the disk load afterwards exactly as they did before.

No dependencies and no install. The Windows and Linux binaries need nothing on the machine, not even Python.

tap2pdf

One tape in, one honest dossier about what is on it out

Version 1.0 Windows / Linux / Python MIT
A tape dossier: verification report, verdict and tape map

And what it prints to the terminal with --nfo:

VERIFICATION
------------
TAP signature                  PASS
Pulse stream integrity         PASS
CBM block checksums            PASS
First copy vs repeat           PASS
Turbo region integrity         NOT CHECKED
    the format is unidentified, so
    there is no checksum model to
    verify it against

A check that did not run never counts as a pass.

What it does

A .tap file is a stream of pulses. You cannot look at one and tell what is stored on it, whether it is intact, or whether it will load at all. tap2pdf reads the tape and writes a dossier: a verification report, a tape map, a memory map, and the files with their load addresses. As HTML, and with --pdf as an A4 PDF.

The honesty rule

The dossier never names something it has not established. A turbo region it does not recognise is written as an unidentified turbo loader, with its pulse count and duration, not as "probably Novaload". A check that did not run is never rendered as a pass: NOT CHECKED is a result in its own right, and it carries its reason. Even a flawless tape refuses a clean bill of health while anything is still unchecked.

A dossier that confidently gives you the wrong name sends you hunting in the wrong place for two hours. Better that it tells you it does not know.