Wednesday, March 6, 2019

RC2019/03 -- All About The Data

My project for RC2019/03 is to write a chip tune player for the Tandy Color Computer (CoCo) that utilizes the SN76489 chip on the Game Master Cartridge (GMC). This is not a tool for creation but a utility for consumption. So, what will it consume?

VGM Files


The VGM file format is capable of representing audio intended for a variety of audio devices, most of which are generally in the category of programmable sound generators. Information about which chips are supported by a given VGM file is encoded in that VGM file. A quick glance at the format specification reveals lots of details about decoding such files. At the very least, supporting VGM files only for the SN76489 will require not only ignoring much of this information, but also knowing which bits of information can be safely ignored. Moreover, part of the information in a VGM file for the SN76489 indicates not only the proper rate for updating register values but also the input clock rate used to calibrate those register values.

Writing a tool merely to simplify a VGM file's data for playback would be worthy of it's own RetroChallenge project! Fortunately for me, someone has already provided a tool which does exactly that -- vgm-convertor is a "Python script for processing SN76489 PSG based VGM files". Along with being able to adjust the SN76489 data not only for different clock input values (including the 4 MHz used by both the BBC Micro and the GMC) but also for several different playback rates (including both 50 and 60 Hz), vgm-convertor is able to output a "raw" data format that is very easy to parse for playback. At least for now, processing VGM files with vgm-convertor will be a requirement for users of this CoCo chiptune player.

Simple Playback


Let's walk through my ROM-based player to get a feel for the overall task at hand. The program starts with some simple housekeeping (e.g. relocating the stack, setting-up interrupts, and clearing the screen), and then it silences the SN76489 tone and noise channels. (These default to being active when the power is applied to the chip, so it makes sense to turn them off.) The program then enables sound output from the cartridge to play through the CoCo. Finally, the program copies part of itself from ROM to RAM. (The copy from ROM to RAM is necessary since the program allows for music data to cross ROM bank boundaries. If the program is executing from ROM when a bank switch occurs, then the program would disappear from the address space and cause a crash.)

This program has to know in advance how many songs are represented in the song data that is part of the program. That number is used to control a loop in which each song is played in sequence. For each song, the title and author information is retrieved from the song data and displayed on the CoCo screen while the song is played. The remaining song data for each song defines the sequence of tone and noise channel settings, which are read from the song data and written to the SN76489 during the timing defined by the horizontal sync interrupt period. The only other notable bit of the program is the bounds checking done after each read of song data. This is used to determine when to switch to the next ROM bank.

This program has been used for a number of small demonstrations of the audio capabilities of the GMC, most notably at CoCoFEST! and on a variety of YouTube videos.

Assessment


As it stands the software described is sufficient to allow me to download a VGM file, to convert it for use on the GMC, and to build a ROM image that will play the song in question. This works fine for demonstrating the hardware, but it is a bit tedious for chiptune enjoyment. Processing VGM files with vgm-convertor may be a necessity, but building and using ROM images for every song or small group of songs is too awkward for normal use.

Instead I want to write something for the CoCo to load song data from a diskette (or diskette image). The file handling might be done in BASIC, or maybe not. The player will need to be modified to match the file handling and it might benefit from other feature additions (e.g. fast-forward and rewind). If you have any other suggestions, then feel free to offer them in the comments below.

So, still interested in where this is going? If so, then you will definitely need to stay tuned...

No comments:

Post a Comment