I'm writing an emulator with an HTTP API that could usefully accept C64 .PRG files as the request body of a POST request. This means it has to be able to detect such files by their MIME type: POST requests don't come with a file name (just a request body and the body's MIME type), so there no extension that the server can check, and the .PRG format is really not amenable to auto-detection.

I will make up a new vnd MIME type if necessary, but I'd rather use an existing one if there is one - however I had difficulty finding anything via Google.


There is no official recognized mime type but there are already some other applications using the standard way of defining private types as application/x-*. For example

application/x-c64-cartridge for C64 Cartridge files (.CRT)

application/x-c64-program for C64 program files (.PRG)

application/x-c64-datadiskfor C64 floppy (data only/single side) (.D64)

application/x-c64-rawdisk C64 Floppy Disk(raw/single side) (.G64)

application/x-c64-snapshot for C64 Snapshot files (.S64)

audio/x-sid for SID audio files (.SID)

If you realy want to define something of your own you must stay with the well defined way of mime type generation, as defined by RFC 2045/46. This application falls for sure within the reserved top media type of application, as this is a binary and application specific format. See RFC2046 Section 3 Type 5. The subtype then should follow the rules of an x-token as described in Section 5.1 of RFC2045.

A quick search did show some other Commodore related types like application/d64, application/x-d64,application/x-cbm-d64, application/t64, application/x-t64, application/x-cbm-t64 but they seem somewhat less desirable. Then again, there are maybe thousands of C64 freaks out there creating their own definitions :))

  • 1
    Thanks. Which applications support this? (Also note that x- is deprecated and types with the x- prefix are no longer part of the unregistered tree!) – Tom Seddon Feb 11 '18 at 22:22
  • After figuring out the right Google search syntax: c64emulator.111mb.de/… mentions application/x-c64-program. Good enough for me, and I'll just put up with the x- prefix. – Tom Seddon Feb 11 '18 at 22:28
  • RFC6838 is 'just' a best practice recomendation, not a standard like 2045/46. Ofc, you're always free to go thru the IANA registration procedure to make up a new standard type. Personally I'd rather spend the time with the project and use established standards. the way they are made. – Raffzahn Feb 11 '18 at 22:40
  • 1
    cbm makes much more sense than c64: a PRG is a capture of a file, not a piece of media, and Commodore used the same layout for files across its 8-bit line. PET software is often found as PRGs. Vic-20 software is often found as PRGs (confusingly including cartridges, which tend to have been captured by saving as a file). C16+4 software is often found as PRGs. Etc. Ditto D64 and G64 are floppy images which may contain software for any Commodore GCR platform. Nothing about most of those files strictly implies the C64. If research suggests MIME types still aren't codified, I'd avoid c64. – Tommy Feb 12 '18 at 16:38
  • 1
    @Raffzahn speaking as one of those that has at any time implemented support for TZX, I agree but hate myself for doing so. – Tommy Feb 12 '18 at 22:38

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.