Pop!Art VGM Player for MSX

Is known by the brazilian MSX community about the development of Pop!Art VGM player that I’m working on since middle 2014.

Some practical results about Pop!Art were reported in 2014 by one of the most important retrocomputing blogs in Brazil, the Retrocomputaria+ blog and by the biggest brazilian MSX community on FaceBook, the MSX Brasil Oficial.

Pop!Art VGM player already supports all existing chips on the MSX platform, like Konami SCC (K051649), PSG (AY8910), FM (YM2413), SFG01/05(YM2151), OPL3/OPL4 and the Philips Music Module (Y8950).

Note: Some months after I presented some Pop!Art results, another excellent VGM Player (VGMPLAY by Grauw) was released.

My first motivation to start this development was only for fun and also to start learning about how sound chips works. The second motivation was to start a big project in chiptune’s scene.

In fact to get information about these old chips was the biggest challenge because some of them just can be found on manufacturer’s data-sheet that sometimes are poorly written and with a small percentage of useful information.

In most cases these datasheet information are confused so the best alternative to these poor data-sheets are the Linux sound cards drivers source code.
After reading these drivers source code, I got some specific details about how several of these chips really work.

Custom chips like Konami SCC don’t have any data-sheets but fortunately are well documented by the international MSX community and sources like BiFi’s website were my main information source.

Another big source of information for MSX developers in general is the MSX Assembly Pages (brought by the same author of VGMPLAY, Grauw) that in my opinion is the best source of information for developers who want to make useful and cool things for MSX computers.

Presenting Pop!Art

Pop!Art is an original software made using Turbo Pascal 3, almost 97% of it’s code is written in Pascal, with some parts written in Z80 ASM. If you want to compile it’s source code and modify it, feel free because the source code was released under GPLv3 and can be reached at OldSkoolTech SVN’s repositories on SourceForge.net.

It is compatible with Borland Turbo Pascal 3.0 (CP/M80-MSXDOS), Turbo Pascal 3.3f from MSX Club Enschede, (MSXDOS 1 & 2), and it also can be ported to others newer Pascal compilers, like FreePascal (Lazarus) and maybe newer versions of Delphi compiler.

The source code is fully commented and several parts of Pop!Art software were incorporated to the framework that I’m developing since I had started the development of the MSXDUMP in 1995 (best known as PopolonY2k Framework).

This framework can deal with several technologies present on MSX architecture, like IDE device handling, MSXDOS and MSXBIOS function calls and direct console handling.

Pop!Art introduces some important features in the framework, like support to Z80 interrupts, all MSX sound chips handling (K051649 aka SCC, YM2413 aka FM, YM2151 aka SFG01/05, OPL3/OPL4, Y8950 aka Philips Music Module, AY8910 aka PSG) and a better and accurate “wait” routines that can deal with resolutions below 50Hz or 60Hz, fixing time errors caused by songs with “tempo” below these resolutions (50Hz or 60Hz), that minimizes any standard deviation.

The current Pop!Art engine also supports all existing chips for the MSX platform and in future, newer chips supported by the VGM format similar to any existing on MSX platform will be added to the Pop!Art engine.

The VGM file format

VGM, aka Video Game Music, is a logging format based on GYM format which is another video game format used specifically to store Sega Mega Drive (Genesis) songs, but contrary to GYM, the VGM format can be used with several other chips different to Mega Drive sound chip. The first version of VGM was released in 2005 and after this release, six new format specifications were released until the current 1.70.

Another curiosity about VGM is that the format was very popular with Winamp users because this music player was the first player capable of playing VGM songs through a plugin specially created for it.

GD3 tag format

The VGM format has a GD3 metadata present in file header specification. The GD3 format is the same format used by MP3 files to store several tracks information, like author, song name and so on.

Pop!Art VGM Support

Pop!Art supports all VGM version’s format, since 1.0 to 1.70 and the GD3 tag format is partially implemented in Pop!Art engine but will be finished in future releases.

The VGM format contains all data samples sent to the sound chips using a speed rate of 41,000 samples per second, so your library must be very fast and precise to deal with VGM files in an accurate way and basically just assembly codes can reach this performance using all of the chip’s power….right ???

Hummm…..maybe not.

Turbo Pascal

I’m really thinking to start writing code to MSX using modern compilers, like SDCC C compiler, which is known to be one of the most powerful and optimized compilers for small devices, but I have written a lot of code to the old Turbo Pascal 3 for CP-M80/MSX for years and my framework has increased a lot its capabilities to handle several standard devices present in MSX world.

Turbo Pascal

In fact I’m using this good, but not so optimized compiler, to learn about new optimization techniques and about the Turbo Pascal internals. And also how to avoid not optimized coding style when you’re programming for machines with low resources. Maybe in the future I can write a new, modern and optimized Pascal compiler (maybe a cross-compiler) for MSX machines, but this is another dream.

When I started writing this article in 2015, FreePascal compiler was not an alternative because it lacked Z80 binary generation support, but since beginning 2020 FreePascal started supporting Z80 platform.


Borland Turbo Pascal 3.0 is an impressive compiler because it is a very fast compiler but unfortunately there are several things that were created to be generic and problem solving in a generic way are known to be slower than a more specialized code generation.

I’m dedicated to improve my framework to be so generic as possible but sometimes I’ll need to be more specific to resolve big performance problems using Turbo Pascal code instead using assembly code.

The small list below can help programmers who are thinking start coding in Turbo Pascal, C and another language different of ASM.

1) In Pascal avoid nested functions – This kind of structured feature is not optimized in Turbo Pascal 3;

2) In any high level language with floating point builtin data types support, like Pascal and C, try to avoid real time processing using these floating point types (float/double in C and Real in Pascal).
These data types can deal with an “excellent” precision but is known that when you have, or want, an “excellent” precision, the processor will pay the price for this precision, so avoid floating point real time operations if is possible. Sometimes this can be done performing some data pre-processing or using fixed point, instead floating point;

3) Use integer instead floating point data and byte instead of Integer data, depending on numeric range, for the same reason of previous item;

4) Try “think” your application in JUMP TABLES, instead nested IF’s or even switch-case (case-of for Pascal programmers);

5) Read this article before coding http://www.popolony2k.com.br/?p=2402

NOTE ABOUT THE 5th ITEM: I’m using GOTO in small pieces of code, because old compilers like Turbo Pascal 3 are very antique, so features like “break” and “continue”, widely used in loop iterations, can be “simulated” by using GOTO.

PopolonY2k framework

As I wrote at the beginning of this text that I’m working on a framework fully written in Turbo Pascal, with some parts in ASM, since I released the MSX DUMP (part of MSX Disk Doctor suite). I thought that this framework was optimized but I was completely wrong, because there’s no framework or any other piece of code which the performance can be measured when discs and slow devices are used by these codes.

So when I tested this framework using my MSX Turbo R machine, everything seemed to be 100% ok and fast, but when I tested the same code on a MSX, running a slower Z80 processor, some problems started to be more visible, then fixing these problems and keep everything working fast using a Z80 in the same way like a R800 processor is a hard work.

This framework was started 20 years ago, when I was leaving the university and in those days I just wrote code for old devices like, disk drives and some generic code code to access the MSXBIOS and MSXDOS (1).
When I restarted coding this framework in 2011, I quickly improved it by adding features to access new devices, like Sunrise IDE devices, Network socket API, UNAPI and RS232 support are still WIP (Work in Progress).

Bellow is the list of all features present on this framework

1) FOUNDATION MODULES – New modules to make Turbo Pascal “more compatible” with new Turbo Pascal releases. New features like Big Integer handling;

2) MSX INTERNALS MODULES – MSX related functions and information (e.g. MSX System Variables);

3) BIOS MODULES – MSX BIOS functions by category;

4) MSXDOS (1 & 2) MODULES – MSX DOS functions;

5) SLOT MANAGEMENT – Functions related to slot manipulation;

6) INTERRUPT HANDLING – Functions to enable interrupt vector function handling using Turbo Pascal;

7) COMMUNICATION – Functions related to communication (RS232 (Work in progress), Sockets);

8) COMMUNICATION DRIVERS – Drivers written to support the Sockets implementation above. Support to OPTONET cards;

9) UNAPI FRAMEWORK – Support to UNAPI framework in Turbo Pascal (Work in progress);

10) SOUND CHIP DRIVERS – Drivers for all sound chips found on MSX standard;

11) VGM PLAYER FRAMEWORK – Functions to play songs in VGM format;

12) IDE SUNRISE-LIKE FRAMEWORK – Functions to handle Sunrise-like IDE devices;

13) USER INTERFACE AND OPTIMIZED CONSOLE MODULES – New functions to increase the speed of console applications and to handle user interface;

14) UNIT TEST FRAMEWORKPopolonY2k TEST SUITE (PTEST) – Functions providing UNIT tests capabilities for Turbo Pascal 3 projects (widely used in the Big Integer implementation);

An updated framework features list can be reached here.

Pop!Art features list

  1. VGM file support (1.0 up to 1.70 – some commands are still disabled. eg. non MSX existing chip commands);
  2. Memory Mapper support (VGM files longer than 64Kb can be loaded and played);
  3. MSXDOS2 only support (sub-directories access). Maybe MSXDOS1 will be supported in future releases;
  4. AY8910 support;
  5. YM2413 support;
  6. YM2151 (SFG 01/05) support;
  7. Y8950 (Philips Music Module) support;
  8. YMF278 (OPL4) support;
  9. K051649 (SCC) support;

Known Pop!Art missing features in this release (0.0).

  1. VGZ file support (in fact is VGM inside a .tar.gz file);
  2. MSXDOS1 support;

Pop!Art memory layout

The application memory layout is described below:

  1. $0000-$3FFF – MSXDOS CP/M-80 + Turbo Pascal runtime workspace;
  2. $4000-$7FFF – Application object code;
  3. $8000-$BFFF – VGM Song data (16Kb memory mapped paged system);
  4. $C000-$FFFF – Unused;

Pop!Art in action

After writing a long story and mainly a lot of technical stuff, it is time to play some song using Pop!Art finally after 5 years 🙂

Check the video below where I explain technical details about how Pop!Art works internally.

Pop!Art in action (portuguese video only)

Downloading Pop!Art

Pop!Art binaries can be downloaded here, https://sourceforge.net/projects/oldskooltech/files/MSX/Pop%21Art/

Enter the version directory you want (e.g v0.0, etc) and download a preferred compressed file (pop_art_v_?_?.zip or pop_art_v_?_?.lhz).

After downloading and decompressing the chosen file, popvgm.com and popplay.chn files will be extracted, put them together in the same directory and then execute popvgm.com.

These files are the two main modules of Pop!Art described below.

  • popvgm.com is the VGM loader;
  • popplay.chn is the VGM player itself.

Hidden gems

Unfortunately all Turbo Pascal 3.x for MSX, both Borland and MSX Club Enschede, are too old products and are both an one pass compiler, so generated binaries are not so optimized as newer compilers like Free Pascal compiler.

Borland did an excellent work when decided create a powerful runtime not just placing the biggest part of standard library there but all comparison test routines are placed there too.

Using this model, the amount of binary code generated by the compiler was decreased considerably but on the other hand they sacrificed performance with this strategy.

I realized that all If’s in the main Pop!Art streaming routine was jumping to the respectives runtime routines and this behavior was decreasing performance a lot, so after a long time think about this problem finally I decided to change the Borland Turbo Pascal 3.0 binary by adding an extra pre-processing compiler directive to generate inline code for all comparison routines and consider Integer (-32768 .. 32767) like Word/Unsigned int (0 .. 65535).

But changing this behavior could turn specific code written to this specific Turbo Pascal version, incompatible with both Borland and MSX Club Enschede, so instead using the standard compiler directive {$ }, I created an extended compiler directive {% } that is considered by Borland and MSX Club Enschede Turbo Pascal as a regular comment but for my modified Turbo Pascal version is an extended compiler directive.

The first extended directive is {%W} and is a scoped directive, so to activate the starting scope the programmer must start with {%W+} and finish the scope with {%W-}.

This will inform the compiler to treat comparison routines as unsigned integer and generating inline code from starting point {%W+} to ending point {%W-}.

Below a small piece of Pop!Art code using this technique:

Procedure __MoveMapper16BitData{( __pSndChipArrayParms : Pointer )};
    If( nCurrentStreamPos < __ctMapperBufferEndAddr ) Then
      __pSndChipArrayParms := Ptr( nCurrentStreamPos );
      nCurrentStreamPos := nCurrentStreamPos + 2;

      (* Direct jump to command processing routine *)
      Inline( $2A/nFnJmpAddr   { LD HL,(nFnJmpAddr) }
              /$E9             { JP (HL)            } );
      __pSndChipArrayParms := Ptr( Addr( aSndBuffer ) );
      aSndBuffer[0] := Mem[nCurrentStreamPos];
      aSndBuffer[1] := Mem[nCurrentStreamPos];
      nCurrentStreamPos := Succ( nCurrentStreamPos );

      (* Direct jump to command processing routine *)
      Inline( $2A/nFnJmpAddr   { LD HL,(nFnJmpAddr) }
              /$E9             { JP (HL)            } );

All comparison structures below are covered by this extended directive:

  • While .. Do
  • Repeat .. Until
  • If… Then … Else


Pop!Art can still be considered a work in progress and soon some extra and useful features will be added to it’s core engine, like:

  • Add support to VGZ (compressed VGM) file format;
  • Chip sound drivers improvement, adding chip specific extra features still not implemented;
  • Core engine speed optimization (improving Turbo Pascal performance);
  • Add full support to VGM 1.70;

So, I hope you enjoy Pop!Art and thanks for reading.


MusicA – Tocando MIDI no MSX – Parte IV

Após um pequeno período de descanso desde o último post, retorno finalmente para a conclusão da série que descreve como converter um arquivo MIDI para o MSX, bem como  técnicas utilizadas tocar musica no MSX em geral.

Quando iniciei a pesquisa para converter MIDI para o MSX, eu esperava conseguir ferramentas 100% prontas para executar essa tarefa, porém após conseguir o 3MLEditor e o MusicA, eu já estava conformado de que teria que criar pelo menos uma ferramenta para auxiliar no processo de conversão, o que realmente aconteceu.

Como já vimos nos últimos posts, conseguimos converter um arquivo MIDI para um arquivo MML proprietário gerado pelo 3MLEditor e também conhecemos o formato MSD, que é o arquivo MML aceito pelo MusicA, que por sua vez converte o MSD para o formato aceito por muitos replayers de MSX, o BGM (Background Music).

Mas ficou um buraco no processo, entre gerar o MML pelo 3MLEditor e transportá-lo ao MusicA, e é justamente aí que entra um componente importante no processo de conversão, que é o mml2msd compiler.

mml2msd Compiler

O mml2msd compiler foi criado justamente para compilar o MML gerado no formato proprietário do 3MLEditor, convertendo-o para o formato MSD aceito pelo MusicA, inclusive aplicando todos os filtros necessários para que os dados MML gerados sejam compatíveis com o MusicA, pois conforme eu escrevi no segundo artigo da série, o MML não é um padrão de facto, logo, existem diferenças no MML entre programas e plataformas diferentes.

Voltando ao mml2msd compiler, essa ferramenta é um compilador de linha de comando criada em C++ ANSI, sendo seu código compilável em qualquer sistema que disponha de um compilador C++ ANSI compatível, o que a torna disponível para praticamente qualquer sistema operacional e plataforma existente na atualidade, como MacOSX, Linux, Windows, Solaris, *BSD (FreeBSD, NetBSD e OpenBSD), dentre outras.


A ferramenta foi construída com técnicas de orientação a objetos, que permitem sua expansão de maneira simples e de forma que possamos reutilizar grande parte de seu código para criação de novas ferramentas no futuro.

Após o término dessa ferramenta, chegamos a um engine de conversão, cujo processo está dividido em 3 partes:

  1. MML Parser;
  2. MML Compiler;
  3. MML Linker;


MML Parser & MML Compiler

O MML parser é o responsável por identificar cada seção do arquivo MML de entrada e Tokenizar essa informação em uma arvore em memória e para isso utilizei o uso extensivo de containers STL (Standard Template Library) de forma que os dados recebidos do parser são pré-processados e compilados nesses containers, ficando organizados e prontos para o processo de linkagem no formato do objeto final.

Algumas tarefas de pré-processamento são feitas durante o parsing do MML de entrada, como por exemplo ignorar comentário de uma linha ( // ) ou de multiplas colunas ( /*   */ ). O MML do 3MLEditor não suporta comentários de multiplas linhas.

Como o formato MML do 3MLEditor é bem simples e geralmente é composto por seções e dados que podem organizados através do pair <Key, Value>, então não foi complicado explicitar isso utilizando as seguintes estruturas em C++ (STL), que definem exatamente os canais e seu código MML associado, bem como algumas estruturas com features adicionais do compilador, como por exemplo a possibilidade do usuário adicionar seu próprio código MML customizado no objeto convertido final.

C++ source code

  * Token types enumeration.
enum TokenType {
  * Data types enumeration.
enum TokenDataType {
  * New definitions types for use with framework.
struct stToken {
  TokenDataType type;
  string                       strKey;
  string                       strValue;
typedef set<int> ChannelSet;
typedef map<int, string> ChannelMap;
typedef map<stToken*, ChannelSet*> CustomMMLMap;
typedef vector<stToken*> TokenVector;
typedef map<stToken*, TokenVector*> TokenVectorMap;

O processo de conversão em nenhum momento, seja no parsing e compilação das informações ou na linkagem, não requer nenhuma técnica de recursividade, principalmente pelo formato de entrada (MML) ser simples. Entretanto o objeto final (MSD) é um pouco mais complicado, uma vez que é um formato baseado em duas seções, sendo a primeira a de definições da estrutura dos canais físicos de som e ordem de execução dos comandos MML e a segunda que descreve o conteúdo dos comandos MML que serão executados pelos canais físicos.

MML Linker

Uma vez com toda a árvore de comandos <canais/comandos> MML carregados em memória, nos resta apenas transferir seu conteúdo para o objeto destino, no caso um arquivo no formato MSD, aceito pelo MusicA.

O processo consiste em uma montagem de dois passos.

  1. Associação dos canais físicos da máquina (FM, PSG e SCC) com os lógicos (conteúdo MML);
  2. Associação dos canais lógicos ao seu respectivo conteúdo MML;


O que resulta no seguinte arquivo MSD, conforme exemplo abaixo:

MusicA MSD Format

; MSD file generated by mml2msd compiler.
; CopyLeft (c) since 2011 by PlanetaMessenger.org.

; Associação dos canais físicos aos lógicos


; Associação dos canais lógicos aos dados MML


Conforme citado anteriormente, o conteúdo MML aceito pelo MusicA não é 100% compatível com com gerado pelo 3MLEditor e também com o do MSX-BASIC, por isso durante esse processo de linkagem é feito um pós-processamento no conteúdo gerado para compatibilizar o MML gerado.


O MusicA não suporta algumas sequências de MML que geralmente são aceitas pelo 3MLEditor e também pelo MSX-BASIC, sendo algumas dessas sequencias inexistentes no MusicA e outras que considerando um pouco de teoria de musical, podem ser substituídas por uma sequência que as torna musicalmente compatível.

O processo de busca de tais sequências no código MML é na maioria das vezes complexo e suscetível a erros, podendo resultar em funcionamento indesejado do software bem como geração de dados indesejáveis ao formato final, por isso considerei bastante a utilização de expressões regulares durante o desenvolvimeto desse software.

O Regex, ou regular expressions, é uma tecnologia perfeita a ser utilizada no processo de busca e substituição de sequências MML inválidas e existem diversas bibliotecas feitas em C++ que implementam o engine para processamento de expressões regulares e a mais famosa delas é a Boost.

Boost é uma biblioteca escrita em C++ e que contempla uma infinidade de novos containers e algorítmos desenvolvidos com base na idéia de Alexander Stepanov e sua STL. O pacote regex da Boost é perfeito para o trabalho de busca e substituição que necessitamos, porém eu iniciei o desenvolvimento desse software utilizando a ferramenta BloodShed DevC++, que é uma IDE de código fonte aberto, para Windows, e que usa o compilador gcc via MinGW, mas ao tentar ajustar essa ferramenta para utilização do Boost percebi que, assim como eu, muitas pessoas tem dificuldades de integração dessa biblioteca com essa IDE. Na verdade a grande maioria da Boost é composta apenas de templates escritas apenas nos headers (.h) da biblioteca e se você tentar utilizar esses templates no DevC++, não terá problemas, porém o regex é um dos poucos módulos da Boost que tem código fonte (.cpp) fora dos headers e com isso que necessta que o host compiler seja configurado para incluir referência a biblioteca regex (.lib) do Boost.

Li em alguns foruns, que algumas pessoas conseguiram trabalhar com Boost no DevC++, porém decidi não gastar muito tempo com isso e temporariamente decidi não utilizar regex nem o Boost e vou deixar essa melhoria no código para uma futura versão do mml2msd, com isso fiz minhas rotinas de busca e substituição todas baseadas na STL mesmo, basicamente utilizando std::string.

Abaixo, uma lista do que não é suportado e o que foi subsitituído por uma sequencia compatível.

C++ Source Code

 * Apply filter to Ampersand (&) character.
 * & after numbers is not possible;
 * & after dot (.) is not possible;
 * @param strToken The data to apply filter;
void ThreeML :: AmpersandFilter( string &strToken );

 * Combine two quarter notes together.
 * @param strToken The MML data to filter;
 * Thanks to The Ultimate PPMCK MML reference.
 * http://woolyss.com/chipmusic/chipmusic-mml/ppmck_guide.php
 * and to SiOPMML reference.
 * http://mmltalks.appspot.com/document/siopm_mml_ref_05_e.html
void ThreeML :: CombineQuarterNotesFilter( string &strToken );

 * Apply filter to Less-than (<) character.
 * Two << cannot be in sequence;
 * @param strToken The data to apply filter;
void ThreeML :: OctaveLowerFilter( string &strToken );

 * Apply filter to Dot (.) character.
 * . after L(n) is not possible;
 * @param strToken The data to apply filter;
void ThreeML :: DotFilter( string &strToken );

 * Apply filter to Tilde (~) character, removing it;
 * @param strToken The data to apply filter;
void ThreeML :: TildeFilter( string &strToken );

 * Filter for invalid volume MML tag. Some MML sequences
 * is higher than MSD (MusicA) supports, then this will
 * be updated for maximum value accepted by MSD format (15).
 * @param strToken The data to apply filter;
void ThreeML :: InvalidVolumeFilter( string &strToken );

 * Filter all instruments of token, removing it from
 * sequence.
 * @param strToken The data to apply filter;
void ThreeML :: InstrumentsFilter( string &strToken );

Ainda estou estudando algumas possibilidades em cima desses filtros, como por exemplo o OctaveLowerFilter, pois acredito que os casos de MML inválidos que peguei talvez sejam porque, nesses casos, o MML original esteja fazendo uma tentativa de retornar 1 oitava que esteja fora da faixa do teclado virtual do MSX ou apenas do MusicA, por isso o mml2msd ainda está em desenvolvimento e ainda teremos algumas versões do mesmo pelos próximos meses, para afinar esses filtros do compilador.

Limitações da primeira versão e melhorias futuras.

A maior limitação do mm2msd é que ainda não estou tratando os canais de percussão, ou seja, ainda não temos uma conversão com o devido tratamento para os canais de bateria e ritmo. Se fosse uma conversão de MML para MSX-BASIC, seria mais tranquilo pois a única conversão necessária seria criar uma tabela de conversão dos instrumentos aceitos pelo MIDI para os aceitos pelo FM do MSX, entretando em se tratando de MusicA, a maneira como ele trata o ritmo é algo particular e que ainda estou mapeando para ajustar o compilador de forma que o mesmo possa transformar essa infomação, possibilitando assim que o MusicA execute os canais de ritmo corretamente, então, posso dizer que já está na lista de melhorias como prioridade.

Outra melhoria que pretendo liberar na próxima versão é a possibilidade de se incrementar o tempo utilizando um incremento especificado pelo usuário, com unidade em BPM (Batidas Por Minuto), ou seja, se uma música tem originalmente o tempo de 20BPM, poderemos desejar que o tempo da música, após a conversão, sejá de 80BPM por exemplo, para isso será necessário especificar, no momento da conversão, o valor a ser incrementado, no caso 60BPM, ao tempo, então a música convertida será executada nesse novo tempo. Isso é muito importante pois existem músicas em que determinados canais estão setados com um tempo X e outros com um tempo Y, ou seja, se tentarmos aumentar ou diminuir a velocidade da música por um processo de conversão manual no MML original, estamos propensos a inserir erros na execução da música.

mm2msd in action

Como já foi descrito anteriormente, o mml2msd é uma ferramenta de linha de comando, portanto em ambiente Windows poderá ser utilizada via cmd e nos UNIX, em geral, através do console comum a esses sistemas.

Segue abaixo tela de ajuda (help) do mml2msd, que mostra todas as opções do compilador. Essa tela de ajuda aparece caso o usuário chame o mml2msd sem parâmetro algum, ou passando a opção -h (mml2msd -h).

mml2msd MML Compiler. CopyLeft (c) since 2011 by PlanetaMessenger.org Vrs. 0.0
Usage mml2msd [-ft][-v][-ac][-acf filename][-of filename][-ri][-h] input_file_name
Optional parameters:
-ft Try to find the tempo on source MML and add it to all channels on destination file.
-v Turn on verbose mode.
-ac Add custom MML to beginning of all channels on destination file.
-acf Add custom MML to beginning of all channels based on content of file specified by parameter filename. See about how to make a custom MML file.
-of Output to file specified by filename.
-ri Generate destination file without the instruments of source MML.
-rc Remove generated comments on destination MML.
-h Show this help screen. How to make a custom MML file.

If you want to use a custom MML file to each channel of source that you’re converting, just create a file with the following format:

FM1=<Custom_MML_command> FM2=<Custom_MML_command> FM3=<Custom_MML_command> FM4=<Custom_MML_command> FM5=<Custom_MML_command> FM6=<Custom_MML_command> FMR=<Custom_MML_command> FM8=<Custom_MML_command> FM9=<Custom_MML_command> PSG1=<Custom_MML_command> PSG2=<Custom_MML_command> PSG3=<Custom_MML_command> SCC1=<Custom_MML_command> SCC2=<Custom_MML_command> SCC3=<Custom_MML_command> SCC4=<Custom_MML_command> SCC5=<Custom_MML_command> Where <Custom_MML_command>
is the MML that you want add to beginning of each specified channel.
mml2msd was developed by PopolonY2k for PlanetaMessenger.org.
For new versions please visit http://sourceforge.net/projects/oldskooltech/
Software information at http://www.popolony2k.com.br
Project home at http://www.planetamessenger.org

A forma de operação mais simplista do mml2msd é chamá-lo da seguinte forma pela linha de comando:

popolony2k@ZanacEx:~$ mml2msd nome_arq.mml

No exemplo acima o compilador abre o arquivo .mml passado por parâmetro gerando um arquivo de saída com o mesmo nome do arquivo de entrada acrescido da extensão .msd.

Operando na forma minimalista, o mml2msd tentará converter o MML da forma mais fiel possível, entretanto o MusicA tem algumas diferenças, principalmente relativas ao tempo da melodia, e por isso existem parâmetros adicionais no mml2msd que possibilitam controlar algumas opções na geração do arquivo final de maneira mais avançada.

Segue abaixo a descrição dos parâmetros opcionais do mml2msd (opção -h):

[-ft]  Try to find the tempo on source MML and add it to all channels on destination file.

Essa opção tenta encontrar o tempo a ser utilizado por todos os canais da música convertida. É importante pois no MusicA cada canal deve ter seu tempo configurado, o que não acontece no MML original, geralmente esse tempo é o mesmo do primeiro canal da melodia.

[-v]   Turn on verbose mode.

Liga o modo verboso, ou seja, todos os prints do sistema estão ativados com essa opção. Ótima para debug.

[-ac]  Add custom MML to beginning of all channels on destination file.

Permite que a adição de comando MML customizados, no inicio de todos os canais.

Ex: mml2msd -ac v10 arq_mml.mml

Ótimo para configuração dos canais, quando todos compartilham a mesma configuração, por exemplo volume ou tempo.

[-acf] Add custom MML to beginning of all channels based on content of file specified by parameter filename.

Assim como a opção -ac acima, a opção -acf permite adição de código MML customizado no inicio dos canais, porém essa opção permite que essa tarefa seja feita a partir de um arquivo de entrada.

Ex: mml2msd -acf arquivo_entrada arq_mml.mml

O arquivo que contém o código MML de entrada (arquivo_entrada) deve ser um arquivo texto no seguinte formato:


Onde cada um dos canais físicos (FM1…FM<n>, SCC1…SCC<n>, PSG1…PSG<n>) poderá ter um código MML associado que será adicionado no inicio de cada canal especificado no arquivo MSD final.

[-of]  Output to file specified by filename.

Especifica o nome do arquivo de saída, permitindo assim que o nome do mesmo seja diferente do arquivo de entrada.

[-ri]  Generate destination file without the instruments of source MML.

Permite que se retire os instrumentos do arquivo final, ou seja, ao utilizar essa opção a melodia ficará com os instrumentos default para todos os canais. Essa opção tem alguma utilidade na versão 0.0 do mml2msd pois essa versão ainda não possui tabela de conversão de instrumentos, logo, os instrumentos do MIDI original poderão não ser os mesmos quando transportados para o MSX.

[-rc]  Remove generated comments on destination MML.

O mml2msd adiciona, por default, comentários entre seções dentro do MSD gerado, para desabilitar essa feature chame o compilador com essa opção ativada.

[-h]   Show this help screen

Mostra a tela de ajuda com as opções acima.

Código fonte

O código do mml2msd já está liberado sob licença GPLv3 em sua versão 0.0, no repositório do Old Skool Tech, com os seguintes endereços para download:


A versão em desenvolvimento está disponível no SVN do projeto e daqui 1 ou 2 meses teremos novas features adicionadas a essa ferramenta bem como a construção de uma outra que é o mml2basic, que transformará o MML do 3MLEditor para código MSX-BASIC, prontinho para executar no MSX.

Também na versão que está no SVN já existe um makefile (Makefile.unix) que possibilita a compilação e geração de binários do mml2msd, para as plataformas UNIX em geral, logo já é possível utilizar o software nos Linux, *BSD, Solaris, etc. A partir da próxima versão vou liberar uma distribuição de binário da ferramenta para o sistema operacional Linux, na área de download do projeto.


Finalmente chego ao final dessa série em que o resultado foi muito gratificante de escrever e compartilhar, principalmente depois de todas essas pesquisas feitas desde o final do ano passado e principalmente depois de perceber que temos muito que fazer no MSX, que tem um terreno fértil e muitas vezes inexplorado no quesito software.

Infelizmente não temos muita gente na ativa desenvolvendo softwares para MSX, máquina essa que acho excelente para aprender ainda nos dias atuais, principalmente para quem deseja se aprofundar na área de software para sistemas embarcados, onde o MSX compartilha muita coisa com os sistemas embarcados atuais. Então quem está no mundo MSX pode fazer a diferença e por isso brevemente pretendo continuar o desenvolvimento de softwares musicais para MSX e minhas pretensões se expandem para a construção de um Player para PC que seja capaz de converter MIDI diretamente para MSD ou até mesmo BGM e também um replayer para MSX que suporte além de FM, PSG e SCC, também a opção MoonSound.

Ou seja, temos bastante coisa para aprender e compartilhar.

Um abraço a todos e fiquem antenados nesse blog pois vem mais coisa pela frente…..temos um ano inteiro para desbravar o universo MSX.



Todos os 4 artigos da série MusicA – Tocando MIDI no MSX são dedicados a Mãe e Professora de Musica Lêda Campos Ferreira.

Obrigado por tudo

Referência na internet

MusicA – Tocando MIDI no MSX – Parte II

MusicA – Tocando MIDI no MSX – Parte III

The Ultimate PPMCK MML reference

SiOPMML reference

Old Skool Tech – Old School Technology

Regular Expressions (Regex)

Standard Template Library (STL)

Boost C++ Libraries

Minimalist GNU for Windows (MinGW)

GCC – The GNU Compiler Collection

Alexander Stepanov

MusicA – Tocando MIDI no MSX – Parte II

Conforme prometido no post anterior, vamos começar a destrinchar o processo de conversão de MIDI para algo que MSX consiga tocar.

Para quem não sabe, MIDI (Musical Instrument Digital Interface) é um padrão de comunicação entre instrumentos musicais e que permite o intercambio de informações entre dispositivos musicais eletrônicos, sejam esses diferentes entre sí ou até mesmo de fabricantes diferentes.

Vou reproduzir abaixo o texto da Wikipedia que descreve com exatidão sobre o MIDI e sua origem.

Diferentemente de outros formatos (como o formato WAV e MP3), um arquivo MIDI não contém o áudio propriamente dito, e sim as instruções para produzi-lo, ou seja, é basicamente uma partitura digitalizada. Essas instruções definem os instrumentos, notas, timbres, ritmos, efeitos e outras características que serão utilizadas por um sintetizador para a geração dos eventos musicais.

Até a década de 70, a comunicação entre instrumentos musicais era algo impraticável. Foi quando um grupo de fabricantes (os mais conhecidos da época) desenvolveu o padrão MIDI (Musical Instrument Digital Interface). Este padrão permite o envio de mensagens de controle entre instrumentos eletrônicos digitais ou analógicos, e é, portanto, uma representação de eventos e não de som digitalizado.

A escolha pelo MIDI foi justamente pelo fato do mesmo ser um padrão bem estabelecido e respeitado por todos os fabricantes de instrumentos musicais e também pelo fato de existir diversos softwares para PC capazes de editar, manipular e aperfeiçoar um trabalho em MIDI, pois a excelência desses softwares para PC ajudam a garantir a qualidade de execução do MIDI em qualquer plataforma, incluindo o MSX, que é carente de softwares desse tipo.

No universo MSX é conhecido que no MSX Turbo-R A1GT, a última versão de MSX lançada, existe a capacidade de manipulação de MIDI, ou seja, esse computador é um dispositivo MIDI-Compatible, podendo se comunicar com instrumentos musicais externos e executar musicas MIDI, através de extensões em seu hardware, além de  uma ROM com extensões em software para utilização de toda capacidade MIDI desse computador.

OBS: Como desejamos desenvolver softwares que rodem a partir da plataforma MSX 2.0, esse MSX (Turbo-R A1GT) não pode ser considerado como base, apesar das capacidades e facilidades que o mesmo possui para gerenciar e se comunicar com dispositivos MIDI.

Mas um MSX 2.0 é capaz de tocar MIDI ?

Bom, eu tenho conhecimento de alguns softwares que são reconhecidos por tocar  e possibilitar a edição de MIDI diretamente no MSX, sem alguma conversão (???), como é o caso do Meridian, porém na prática os altos requisitos de hardware para a utilização do mesmo (512Kb Memory Mapper) o torna inviável para a maioria das máquinas  padrão (64Kb RAM), sem contar a impossibilidade de utilização pelo MSX-BASIC.

O que fazer então para que possamos usufruir do poder do MIDI no PC e transporta-lo ao MSX ?

A primeira coisa é estabelecer os requisitos mínimos de nossa plataforma para que, a partir daí, possamos começar a estudar essa plataforma e buscar soluções para esse ambiente conhecido.

Vamos à lista de requisitos mínimos da plataforma desejada:

  1. MSX 2.0;
  2. 64Kb RAM;
  3. Possibilidade de utilização de placas de som FM-PAC;
  4. Possibilidade de utilização de instrumentos modernos para composição das músicas;
  5. Possibilidade de edição da composição, podendo ajustar possíveis imperfeições;
  6. Possibilidade de execução das composições no MSX-BASIC;
  7. Possibilidade de transporte das composições para o MSX;


Bom, os itens 1 e 2 são básicos e não necessitam de maiores explicações, ou seja, é um requisito obrigatório pois queremos desenvolver algo para MSX 2.0 com 64Kb e não existe mais possibilidade de discussão sobre esses pontos.

O item 3 também é uma possibilidade muito interessante, embora não obrigatória.

O ítem 4 também é um fato consumado, pois se quisermos qualidade profissional nas composições, então devemos contemplar a possibilidade para utilização de equipamentos profissionais e para isso nada melhor do que a utilização de um protocolo bem estabelecido e aceito por todos os instrumentos, que possuem capacidade de comunicação com o mundo externo, que é o protocolo MIDI.

No item 5, mais um motivo para utilização do MIDI, pois o mesmo possui uma riqueza de softwares para PC, que possibilitam sua edição e aperfeiçoamento nessa plataforma.

Quanto aos itens 6 e 7……….ops……..

Enquanto perambulavamos pelo mundo dos instrumentos músicias e também no mundo dos PC‘s estava tudo perfeito, pois esses sistemas possuem riqueza de softwares musicais, porém ao entrar no mundo musical da plataforma  MSX, percebemos um universo desconhecido a ser explorado e desenvolvido.

MSX – Um universo musical desconhecido ?

Já conhecemos muito bem os requisitos mínimos de nossa plataforma, resta agora conhecer mais profundamente essa plataforma e uma das coisas que sabemos de imediato é que, tirando o Turbo-R A1GT, os MSX anteriores não possuem extensões MIDI builtin.

Até existem placas MIDI para um MSX anterior ao Turbo-R A1GT, porém são raras e certamente é um limitador para as nossas ambições de conquista do mundo 🙂 , logo estão fora de cogitação.

Como  resolver esse impasse ?

Bom, existem duas maneiras para resolver esse problema.

  1. A primeira é implementar o protocolo MIDI nós mesmos para os MSX anteriores ao Turbo R A1GT;
  2. Aprofundar um pouco mais nas estruturas internas do MSX afim de buscar alguma coisa “pronta“.


A primeira opção é linda para qualquer programador que adora desenvolver protocolos, como é o meu caso, porém nesse caso não posso me esquecer de que estou no meio de um desenvolvimento de um game e que os resultados do desenvolvimento devem ser menos demorados possíveis, para que não possamos perder o “pique“, por isso, pelo menos por enquanto, eu descartei essa possibilidade.

Só nos resta então analisar a segunda opção.….

….e é o que exatamente vamos começar a destrinchar.

Me lembro que na década de 80 eu lia aquele manual do HotBit de cabo a rabo em busca de informações técnicas e principalmente para aprender mais sobre a capacidade gráfica do MSX.

Não foram poucas as vezes que também digitei diversos exemplos sobre os comandos voltados para sons e músicas,  SOUND e PLAY do MSX-BASIC, pois eu adorava a capacidade sonora do MSX, principalmente os efeitos de percussão (bateria) que poderiam ser conseguidos pelo PSG dessa máquina, até comecei a fazer uma bateria eletrônica utilizando as portas de joystick dessa máquina, lá pelos anos de 1992, mas isso já é uma outra história.

O comando SOUND, no manual de BASIC do HotBit, era descrito superficialmente, sendo que um detalhamento de suas características estavam melhor descritas no Manual do Usuário do HotBit, por isso nunca me interessei em me aprofundar nesse comando, apesar de saber, na época, que se tratava de um comando poderoso e que você poderia escrever dados diretamente nos registradores do PSG e com isso obter um controle maior sobre o processador de som do MSX.

Já o comando PLAY era tratado pelo mesmo manual de uma maneira menos superficial, descrevendo em detalhes a Macro Linguagem Musical aceita pelo comando para compor uma música utilizando toda uma sintaxe simples baseada em letras, números e simbolos para descrever as notas musicais e compor a partitura que o MSX irá executar.

Macro Linguagem Musical, ……hummmm………..

Foi só continuar pesquisando sobre a tal Macro Linguagem Musical do MSX para chegar ao termo original, Music Macro Language, ou apenas MML.

MML – Music Macro Language

A Music Macro Language, ou MML, é originária dos interpretadores BASIC da Microsoft, bastante comuns e populares no final da década de 70 e durante toda a década de 80 e meados de 90.

A MML consiste de uma linguagem musical de alto  nível, onde as notas musicais são descritas por letras, sendo elas A, B, C, D, E, F, G que correspondem às notas Dó, Ré, Mi, Fá, Sol, Lá e , respectivamente.

A partir daí você tem uma série de macro instruções que utilizados em conjunto, formam a partitura utilizada pelo computador na execução de uma musica.

Segue abaixo a descrição de alguns comandos MML:

  • A até G – Especifica as notas músicais, que correspondem de até , em um teclado ou piano real;
  • T<n> – Especifica o tempo da música, em batidas por minuto, por exemplo T28, especifica o tempo de 28 BPM para um determinado canal;
  • < > – Utilizados para avançar uma oitava (>), ou voltar uma oitava (<) no teclado musical virtual do MSX;
  • @<n> – Especifica o instrumento a ser utilizado pelo canal de execução. Ex: @10;
  • V<n> – Especifica o volume de um canal. Ex: V15;


Esses comandos são repassados, via MSX-BASIC, ao processador de áudio do computador através de strings no comando PLAY.


10 A$=“T10V15ABCDEFG”
20 PLAY A$

Dessa forma podemos, com facilidade, especificar partituras completas que serão executadas por um computador que entende MML.

O MSX é um dos melhores computadores de 8 bits, e também o mais mal aproveitado, no quesito software musical, pois o mesmo possui diversas extensões de hardware, padronizadas e não padronizadas, que são capazes de estender a capacidade desse computador podendo fazer frente, pelo menos no hardware, aos computadores atuais.

Se considerarmos um computador MSX 2.0, equipado com uma placa FM-PAC interna ou externa, contamos aí com um belo dispositivo, capaz de gerenciar até 9 canais simultâneos e ainda MIDI Compatible, pelo menos na questão de hardware.

Gerenciar 9 canais simultâneos, requer um pouco mais de traquejo tanto por parte do hardware, quanto pelo programador porém utilizando a MML é possível diminuir essa complexidade consideravelmente.

Vejamos por exemplo o caso de uma música com 5 canais simultâneos em MML:


10 DIM A$(5)
20 CALL MUSIC(0,0,1,1,1,1,1,1,1) : REM *** 9 Canais para som, sem percussão
30 A$(1) = “ABCDEF”
40 A$(2) = “GFDEC”
50 A$(3) = “GGGGG”
60 A$(4) = “ABABAB”
70 A$(5) = “DEDEDEDE”
80 PLAY #3, A$(1), A$(2), A$(3), A$(4), A$(5)

Ou seja, podemos fazer excelentes melodias em MSX-BASIC, desde que cada canal não tenha mais do que 255 caracteres na string MML, limite esse da capacidade de uma string do MSX-BASIC.

Com todas essas informações descobri que MML é muito utilizada na composição de músicas para NES e Super NES, sendo utilizada até os dias de hoje por grupos que ainda desenvolvem jogos para essas plataformas e existe ainda um ferramental grandioso que auxilia os músicos na criação de composições para games desenvolvidos para essas plataformas, o que faz do MML muito popular no Japão.


Em minhas pesquisas encontrei muito material para NES e Super NES e descobri também que por não se tratar de um padrão de facto, os códigos MML não são obrigatoriamente compatíveis entre as diversas plataformas e algumas vezes nem entre softwares em uma mesma plataforma.

Precisamos agora arrumar um jeito de converter um arquivo MIDI para MML, para que assim possamos cumprir a meta 6 de nossos requisitos mínimos, que é a possibilidade de execução da composição via MSX-BASIC, conforme citado anteriormente.

Após pesquisar a internet inteira 🙂 em busca de um software com essa capacidade, eu estava chegando a conclusão de que eu teria que implementar um Player que entendesse pelo menos o protocolo MIDI e quem sabe no futuro tentar uma conversão de General MIDI, para MML. Inclusive já estava estudando novamente o livro Maximum MIDI que adquiri em 2000, justamente quando eu estava cogitando, naquela época, enfim, concluir a minha bateria eletrônica de 1992, mas isso é outra história.

Nesse momento encontrei em um site japonês, não poderia ser diferente, parte da solução para o problema da conversão de MIDI para MML, o 3MLEditor, ou apenas 3MLE.

3ML Editor

Esse editor é simplesmente fenomenal para o que precisamos, pois ele é capaz de importar MIDI e salvar em um formato próprio, que é na verdade um arquivo texto que contém os canais juntamente com comandos MML.

3MLE - 3MLEditor

Segue abaixo um exemplo de um MML gerado pelo 3MLE:

Title =
Source =
TimeBase = 32
TimeSignatureNN = 4
TimeSignatureDD = 4
Instrument1 = 128
Instrument2 = 128
Instrument3 = 128
TrackName1 = Track1
TrackName2 = Track2
TrackName3 = Track3







Apesar de, aparentemente, o arquivo acima ainda ser complexo, quem conhece um pouco de MML sabe identificar o conteúdo MML no mesmo, bem como os canais para tentar extrair alguma coisa,  e principalmente quem conhece o protocolo MIDI internamente sabe que esse arquivo MML acima é muito mais amigavel do que qualquer MIDI e seus timers, eventos, sysex, etc etc etc….

Uma das coisas que aprendi nesse intervalo de tempo em que estou escrevendo ferramentas para manipular MML, foi como identificar o MML gerado pelo 3MLE e uma das primeiras coisas que ele faz é configurar o tempo da melodia para todos os canais e na maioria das vezes esse tempo está no primeiro canal e deve ser sempre setado em todos os canais, nesse caso T200.

Segue abaixo um exemplo de uma conversão manual, para o MSX-BASIC, desse arquivo MML gerado pelo 3MLE:


10 CLS
20 REM
30 REM ******* MML definition ********
40 REM
50 DIM A$(2)
60 T$=“t200” : REM *** Tempo de todos os canais ***
70 A$(1)=“v8>e16g+16c+16e16v10<a16>c+16v14<g+16>c+16<a16f+16e16a16”
80 A$(2)=“>e16g+16c+16e16v10<a16>c+16v14<g+16>c+16<a16f+16e16a16r8a.”
90 B$=“v14r1.r32c-16f+.&f+32”
100 C$=“v14r1.<f+16>d.&d16”
110 REM
120 REM **** Start play MML ****
130 REM
140 PLAY #2,T$, T$, T$
150 PLAY #2,A$(1)+A$(2),B$,C$

Essa é a forma mais simples de converter um MML gerado pelo 3MLE, para o MSX-BASIC, porém nem tudo são flores pois existem algumas restrições, conforme citarei abaixo, e outras que citarei nos artigos seguintes:

  1. Devido a limitação de 255 bytes por linha no MSX-BASIC, é impossível escrever um canal inteiro com musicas MML que ultrapassam esse limite, devendo o programador escrever rotinas para bufferização de comandos MML, por canal e em MSX-BASIC;
  2. O MML gerado pelo 3MLE tem um bom nível de compatibilidade com o MML do MSX-BASIC, porém há restrições em alguns comandos e por isso desenvolvi um compilador, que será apresentado no último artigo, que corrige essas inconsistências gerando um MML 100% compatível com o MSX.
  3. Alto grau de complexidade para desenvolver um player, codificado em MSX-BASIC, utilizável em outros projetos;


Bom, vou finalizando a parte 2 dessa série de artigos que estou escrevendo sobre musica  no MSX. No próximo artigo escreverei sobre uma outra peça bem interessante que descobri no universo MML que estamos desbravando, que é um editor chamado MusicA e que também entende MML, sendo esse capaz de compilar um MML para o famoso formato, BGM, amplamente utilizado em jogos no MSX.

Por fim, no ultimo capítulo da série vou apresentar o compilador que automatiza a conversão e compatibiliza possíveis códigos MML inválidos para o utilização no MusicA.

Fique antenado….já, já tem mais.



Referências na internet

Meridian – MIDI editor/player para MSX.


MML – Music Macro Language


Protocolo MIDI


Projeto MSX Livros – O maior acervo de livros escaneados para MSX da internet.


Maximum MIDI Toolkit


3MLEditor (3MLE)


MSX Music Editor/Player


  1. Possibilidade de utilização via MSX-BASIC;

MusicA – Tocando MIDI no MSX – Parte I

Não preciso nem citar as diversas fontes de estudos que demonstram que a música é capaz de transformar o “estado de espírito” das pessoas, isso é um fato e principalmente um fato que comprovamos em nossos diversos anos de jogatinas no MSX pois existem jogos excelentes cuja trilha sonora ou é pífia ou inexistente e com isso os mesmos passam despercebidos pela maioria dos usuários dessas máquinas.

Já outros são lembrados e cultuados até os dias de hoje, é o caso de games como Penguin Adventure, Snatcher/SD Snatcher, Fray, a série Xak, a série Nemesis/Gradius, a série Aleste dentre outros que, para mim, tiveram grande parte de seu sucesso creditado a suas trilhas sonoras e serei mais ousado ainda, 50% do sucesso desses clássicos deveria ser creditado a essas trilhas sonoras.

Isso pode ser percebido através da importância que as produtoras de games da época davam à suas produções sonoras tanto que existiam, já naquela época, equipes de compositores dedicados a seus games, diferente de muitos dos pioneiros da produção de games que trabalhavam apenas a parte de técnicas de programação, ou a parte gráfica, deixando a parte sonora resumida a blip’s e blop’s.

E exemplo mais conhecido é da famosa produtora de games para o MSX e para outras plataformas até os dias de hoje, a Konami, que possuia já na década de 80 uma equipe de músicos especializada nas músicas de seus títulos, denominada Konami Kukeiha Club, que foi a equipe responsável pela maioria das músicas dos games lançados pela Konami na maioria das plataformas em que a produtora lançava seus títulos naquela época.

O assunto, produção musical, é tão sério que o sucesso do departamento musical da Konami inspirou a criação de um outro grupo, o Kuheika Club, formados por membros da Konami Kukeiha Club (Chiptune) e que tocavam muitas das musicas compostas por eles mesmos para os games da Konami mas com instrumentação real. Algumas piratohouses brasileiras da época vendiam fitas cassete, com os trabalhos da Kuheka Club, que pelo que me parece eram lançados pela própria Konami em CD no Japão, eu mesmo adquirir alguns cassetes (ou apenas K7) dessas piratohouses lá por 1989/1990.

A realidade do MSX no Brasil

…após o término de sua fabricação no cenário nacional, principalmente na parte de software, é quase tão ruim quanto na época de ouro do MSX, pois poderíamos ter feito muito mais coisas do que fizemos.

Felizmente os True Hackers na parte de hardware ainda continuaram ativos e produzindo inovações em hardware para MSX, dentre eles cito Ricardo Oazem (Tecnobytes) e Ademir Carchano (ACVS), o que nos dá uma sobrevida na parte de hardware.

Na parte de software devemos considerar que na decada de 80 o fator falta de conhecimento pesava bastante, pois a própria micro-informática ainda engatinhava naquela época, mas o tempo mudou e as pessoas engajadas no universo MSX na época, e que detém um maior conhecimento hoje, talvez não queiram mais saber de ouvir falar em MSX, nem pelo saudosismo.

Nesse cenário obscuro percebemos que fazer ferramentas para MSX é um terreno fértil aqui no Brasil e o MSX é um plataforma excelente para exercitarmos boas práticas para desenvolver produtos que tenham muitos recursos de software com poucos recursos de hardware, o que é exatamente a praia daqueles que desejam se aventurar em desenvolvimento para sistemas embarcados.

Apesar de estarmos muito atrasados nesse cenário do universo MSX, nunca é tarde para começar e foi por isso que lancei o projeto Old Skool Tech no Sourceforge.net, que é onde estou recuperando os fontes de alguns softwares que fiz para MSX na década de 80/90, bem como para deixar ali registrado todo e qualquer novo desenvolvimento realizado, a partir daqui, para o MSX e outras plataformas antigas.

Musica no MSX

Voltando ao foco sobre musica no MSX, vale ressaltar que um MSX original (MSX 1) é dotado de capacidades sonoras bem avançadas, não só para a época mas também nos dias atuais, haja vista trabalhos realizados por grupos especializados em fazer músicas para computadores antigos (MSX, ZX Spectrum, Commodore 64, …). Esse tipo de música é conhecida por Chiptune e existem alguns grupos que se destacam nesse cenário, como 8BitPeople.

A grande maioria desses computadores antigos, exceto o C64 que tinha o SID 6581, tinham como seu processador de áudio o chip da General Instruments, o AY-3-8910, que possui 3 canais de som, porém o MSX possui algumas vantagens pois possui extensões padronizadas como o MSX-MUSIC com chips FM OPPL YM2413 e algumas outras mais interessantes ainda como a MoonSound com o seu impressionante YMF278 OPL4 e todo esse conjunto, acredito eu que, transforma o MSX na melhor plataforma sonora de 8 bits existente.

Porém, nenhuma dessas peças de hardware tem valor se não houver nada para controla-las, principalmente senão existir uma forma de reprograma-las a medida que nossas necessidades aumentam e é no momento que chegamos nessa encruzilhada que percebemos que o MSX no cenário internacional está bem servido de grupos que desenvolvem ou desenvolveram ferramentas que tiram proveito ao máximo dessa excelente plataforma, como é o exemplo de grupos como Bandwagon, TeddyWareZ, The New Image (TNI), dentre outros diversos.

A maioria desses demos nasceu devido a algum incentivo externo recebido e que disparou o desenvolvimento dos mesmos. No caso dos demos da Bandwagon, é conhecido que esse grupo participou de diversas competições de demos de 1Kb a 8Kb, competindo com diversas plataformas  diferentes e venceu a grande maioria (senão todas), ou seja, o incentivo era a competição.

Recentemente após algumas discussões no Orkut, surgiu a idéia de desenvolver um jogo para MSX 2.0, que utilizasse a capacidade gráfica e sonora dessas máquinas, incluindo a possibilidade de tocar musicas FM-based (FM-Pac, FM-Stereo, ….). A discussão em torno dessa idéia foi crescendo e  o desenvolvimento atualmente é mantido na comunidade do Orkut, MSX-Brasil, com discussões sobre o andamento do projeto aqui nessa thread.

Esse era o incentivo necessário para se desenvolver alguma coisa para o MSX, aqui no Brasil, que estava faltando e o suficiente para eu perceber que diversas técnicas e ferramentas poderão sair daí, dentre elas:

  1. Técnicas de manipulação de gráficos;
  2. Ferramentas gráficas;
  3. Técnicas para execução de musicas em dispositivos com recursos limitados;
  4. Ferramentas musicais;
  5. Técnicas de desenvolvimento para dispositivos com recursos limitados;
  6. Ferramentas de compactação de dados.
  7. Técnicas de otimização de sistemas para dispositivos com recursos limitados;


Ou seja, tem muita tecnologia que poderá ser desenvolvida com o incentivo desse projeto e digo mais…..já começou a ser desenvolvida e com resultados.

O primeiro resultado positivo foi o processo de conversão de músicas MIDI e que agora podem ser convertidas e tocadas no MSX, e é exatamente sobre isso que estarei escrevendo os próximos 3 artigos dessa série de 4 artigos.

Vou explicar sobre os softwares utilizados no PC e que futuramente tentarei desenvolver para PC e MSX, bem como sobre o compilador que  já  desenvolvi para PC e que é utilizado no processo de conversão. Por fim, o processo final de conversão que é feito no MSX bem como a utilização de um Replayer para MSX que executa a música convertida.

Fiquem antenados e espero que a partir daí surjam novos softwares para MSX ou até mesmo ferramentas de apoio feitas para PC e que possibilitem a utilização extrema do hardware do MSX.


Referências na internet.

Blip, blop for the masses.


Comunidade MSX Brasil no Orkut.


%d bloggers like this: