tedplay is a Commodore family music player primarily focusing on the 264 line, but supporting the following formats:
  • plain PRG
  • PSID/RSID format
  • C8M, a new versatile 8-bit computer music file format

tedplay implements a plus/4 virtual machine complete with full CPU and TED chip emulation. Therefore it theoretically supports all imaginable music code.


There are two versions of the player: a barebone command line and a Windows GUI one, written with the fantastic WTL ( The first versions relies on the Simple Directmedia Layer ( for sound output. Two further Windows GUI versions can be compiled from the source: one with SDL sound and one with the default DirectSound.


  • virtual machine with full 8501 CPU emulation
  • full Commodore 16 and plus/4 (264 family) TED music support
  • full Commodore 64 SID chip support (both 6581 and 8580)
  • support of PRG, PSID, RSID and C8M music formats
  • playlists
  • volume setting
  • channel mute
  • adjustable speed
  • adjustable replay sample rate
  • adjustable replay buffer length
  • system wide hotkey to skip between tracks


Windows GUI version

There should really be nothing new in case you have ever used a media player... which you very likely did considering the type of the player and the age it implies.

The settings are saved in the registry. The following keys are added to HKEY_CURRENT_USER\Software\Gaia\WinTedPlay:
  • AutoSkipInterval : auto skips between tracks in the given seconds (0 means no auto-skip)
  • BufferLengthInMsec : length of the replay buffer in millisec. The length might get adjusted by the audio driver to align with buffer restrictions. Default is 100 ms, decrease it in case you have a fast computer and want more responsiveness to music controls. Increase the size of the buffer in case the sound clicks or gets distorted. The exact buffer length might get overruled by the specific audio drive to accomodate for different buffer length restrictions.
  • DisableSID : flag telling whether SID chip emulation should be disabled or not
  • FilterOrder : sets the windowed sinc FIR filter's order (increase to improve audio quality, decrease to improve performance)
  • SampleRate : the sampling frequency for replay. Increasing it will improve sound quality, since the TED frequency is higher than what most sound cards are capable of. Decrease the frequency if you have a slow computer, increase if you want better quality audio.
  • ShowPlayList : a simple flag that tells whether the playlist window is visible on startup or not.
Since version 1.1 it is possible to use system wide hotkeys to skip to the next/previous module. Use the Ctrl+Alt (alternatively Alt Gr on some specific keyboards) and the right or left arrow to skip back and forth among tracks.

In case the audio "clicks" try increasing the buffer length (requires restart). Alternatively you can also disable SID emulation.


tedplay comes in two variants: a minimal console and a Windows GUI one.

Windows GUI version

Compiling the Windows GUI version requires:
  • a capable C++ compiler, such as:
    • the MinGW compiler with appropriate Windows headers
    • the free Visual C++ Express (2005 or above) and the Windows SDK
  • the Windows Template Library
  • the Simple Directmedia Layer - this dependency may be lifted later on

Console version

The console version can theoretically be complied to any platform (Linux/BSDs/Mac/Windows etc.) that has SDL ported to it. Simply include all source and header files into your project that are in the root source folder.

C8M format


Cbm8m is (C) 2012 Levente Hársfalvi. This chapter is distributed under the Creative Commons by-sa (Attribute-ShareAlike) license In short, you can adapt, share, make commercial use of this work, as long as it is attributed, and modified works are distributed alike.


Cbm8m is a container format. It encapsulates native Commodore music program and data binary dumps, adding complementary technical and administrative information.

Cbm8m can be thought of as an expansion of well established ideas and practices of the High Voltage SID Collection, together with the PSID fileformat in particular, albeit in the form of a completely new structure.

The format builds around three, general principles.
  1. It should be an uniform 8-bit music archive format, as far as system similarities and differences permit.
  2. Archive files should be playable on the tunes' respective original platforms as far as system resources allow.
  3. And last, the format should provide some means to ease the administrative work of 8-bit Commodore music archival projects.

As to what the files are supposed to store, the definition strongly relies on HVSC's established practices.

Cbm8m files use the c8m file extension.


  • Support for all 8-bit Commodore platforms by a common logical structure. Platform support is implemented as sets of (platform setting specific) flags.
  • Three-level logical structure: single global tune definition, one or more subtune definitions, and one or more binary definitions with respective binary dumps.
  • Subtune definitions are mapped to binary dump / init parameter pairs. An arbitrary subtune order can be arranged, mapping subtune description blocks to subtunes of a set of separate binary dumps, ie. on the level of the container file's structure.
  • Each levels of the structure are composed of a set of information fields. These fields can be flags, integer numbers, and texts. Generally, flags are assigned flag names.
  • Flags usually sign specialities, either hardware requirements or configuration (thus their dependence on platform setting).
  • Numeric fields are usually technical parameters (number of subtunes, init address, init parameter and so on), they can be 4, 8, 16, 32 bits wide. Logically, they're interpreted either as 0- or 1-based numbers (0..255 or 1..256, and so on).
  • Textual fields represent human readable information. In cbm8m, all textual fields are UTF-8 encoded strings of technically arbitrary length. Logically, this part absolutely relies on definitions taken from the P/RSID file format and HVSC's SID Tune Information List (to get a good overview of them, it might be a good idea to take a look at HVSC's guidelines first).
  • Uncommon to music archive formats, cbm8m has (supposedly equivalent) textual and binary representations. Texts can be hand-edited, and given a text based representation, music archive projects can benefit from using version control systems (that help keeping track of new tunes, modifications, releases). Binary files potentially provide small filesize and interpretability on small systems.
  • Most of the fields have purposely selected default values and corresponding interpretations, that is, if definition for some particular fields are absent, the structure still behaves consistently. Almost all fields of the text version, and a selected set for the binary version are optional. This simplifies work and (especially for the binary form) reduces filesize.

Last edited Sep 27, 2014 at 9:39 PM by calmopyrin, version 23


No comments yet.