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.

https://wiki.freepascal.org/Z80

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 )};
  Begin
    {%W+}
    If( nCurrentStreamPos < __ctMapperBufferEndAddr ) Then
    {%W-}
    Begin
      __pSndChipArrayParms := Ptr( nCurrentStreamPos );
      nCurrentStreamPos := nCurrentStreamPos + 2;

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

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

All comparison structures below are covered by this extended directive:

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

Conclusion

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.

[]’s
PopolonY2k

Featured project – Aleste Gaiden Cartridge (MSX Brasil Oficial)

Depois de um longo período de silêncio, devido a um período de muito trabalho não relacionado a coisas legais, finalmente retorno com novidades, principalmente porque apesar do blog estar um pouco silencioso não significa que trabalhos em background não estão sendo desenvolvidos, muito pelo contrário pois essas horas de silêncio significam que muita coisa legal está sendo feita 🙂

Vamos deixar as outras coisas legais para outros posts pois o objetivo desse post aqui é mostrar um cartucho desenvolvido por uma das maiores comunidades de MSX no Facebook, que é a MSX Brasil Oficial, comunidade essa onde sou um dos fundadores e também um dos moderadores.

O projeto se iniciou nas conversas entre Erwin Brasil, um dos fundadores e também um dos moderadores da MSX Brasil Oficial com o Sergio Augusto Vladisauskis um dos membros mais atuantes da comunidade MSX nacional. Após algum tempo o Sergio entrou em contato comigo perguntando sobre a compatibilidade de uma ROM do jogo para MSX2, Aleste Gaiden, que havia sido gerada pelo software do Vincent Van Dam, o DSK2ROM.

Um problema havia sido detectado no som FM da ROM gerada, quando executada nos MSX TurboR operando em modo R800, causando sons estranhos e modificando completamente a musica para ruídos nada agradáveis de se ouvir. Ao testar essa ROM em um dos meus MSX TurboR, naquele dia, eu não sabia que estaria entrando de maneira intensa no desenvolvimento desse projeto.

Após testar essa ROM e concluir que tínhamos um problema, chegamos a conclusão que estava relacionado ao modo R800 pois eu havia testado a mesma ROM no MSX TurboR mas em modo Z80, bootando a máquina pressionando a tecla 1 e tudo havia funcionado perfeitamente, então para corrigir isso deveríamos inserir uma rotina que chaveasse o funcionamento dessas máquinas para o modo Z80, na inicialização do jogo.

Como as notícias correm rápido demais em um ambiente comunitário forte e principalmente com muita gente boa interagindo entre si, então em poucos minutos um dos membros da comunidade MSX bem conhecido pelo seu alto conhecimento da plataforma MSX, o Julio Lemos, entrou em contato comigo já com uma ROM modificada para esse fim e como era de se esperar, essa ROM funcionou perfeitamente.

Apesar desse contratempo tudo caminhava muito bem e os cartuchos MegaFlashROM começavam a ser produzidos para que enfim a ROM pudesse ser gravada e entregue aos participantes patrocinadores do projeto. Mas o pior estava por vir e nesse momento mais uma vez o Sergio me informou que a ROM do Aleste Gaiden não funcionava nessa MegaFlashROM 512Kb, apesar de rodar muitos jogos MegaROM, incluindo MetalGear2 e Goonies ‘R’ Good Enough, ambos de 512Kb, de mesma capacidade da ROM do Aleste Gaiden.

Marcamos, eu, Sergio e sua noiva, Cristina Simões e também o Rogério Matte (MSX ARM) no Shopping Light no centro de São Paulo, onde o Sergio me levou uma versão dessa MegaFlashROM 512Kb, com todos os chips soquetados afim de que pudéssemos modificá-la, caso fosse necessário, mas olhando a descrição da MegaFlashROM na própria plaquinha, dizia MegaFlashROM Konami4, o que já indicava uma pista do “problemão” que teríamos que resolver.

Não dá apara avançar nas explicações sem antes falar sobre a…

…DSK2ROM

O projeto DSK2ROM apesar de ser excelente e complexo tem um conceito bastante simples, ele simplesmente adiciona uma DISKBIOS modificada para “enxergar” a mapper da MegaFlashROM como se fosse um disco, mas infelizmente a DSK2ROM não suporta mapper Konami4 e para chegar a essa conclusão eu havia iniciado um trabalho de desenvolvimento de um novo gravador de flash para a MegaFlashROM que seria o responsável de patchear o software e DISKBIOS corretamente para a mapper Konami4, desenvolvi então o DSK2FLASH e fiz alguns testes com o jogo Aleste 1, que também não funcionava nessa mesma MegaFlashROM Konami4, entretanto cheguei a conclusão que o trabalho em cima da DISKBIOS seria bem demorado e que se o pessoal concordasse eu começaria os trabalhos em cima disso, mas não seria algo imediato e levaria talvez alguns meses até que tudo estivesse concluído.

O pessoal do projeto concordou em esperar mais um tempo até que eu tivesse tudo concluído mas nesse momento o inesperado aconteceu novamente. Como as notícias correm rápido e até mesmo porque depois que expliquei tecnicamente, exatamente, o que precisaríamos fazer para ter o Aleste Gaiden rodando nessa MegaFlashROM K4, algumas horas após expor esse fato na lista dos participantes do projeto, eu recebi um email do Marcelo Zoffy que eu conheci naquele exato momento em que lia aquele email mas que já de entrada havia ganho minha apreciação, admiração e respeito.

No email ele me dizia que havia feito exatamente o que eu precisava, inclusive já tinha uma ROM do Aleste Gaiden preparada para rodar na MegaFlasgROM Konami4, mas que só havia testado em um OpenMSX e nunca em um MSX real, ROM essa que estava inclusa em anexo no email. Nem precisa dizer que testei essa ROM correndo em vários MSX, desde MSX2 importados, MSX TurboR e também no ZemmixNeo, todos funcionando 100% e de primeira.

Agradeci ao Marcelo Zoffy, prometi que enviaria um cartucho novinho para ele assim que o mesmo estivesse pronto, peguei a ROM enviada por ele reenviei ao Julio Lemos para que ele aplicasse a sua modificação que chaveia o modo de operação para Z80 nos MSX TurboR e em 1 semana já tínhamos tudo pronto para lançar os cartuchos.

Após tudo isso, o Sergio correu para produzir, testar e corrigir eventuais problemas nas plaquinhas de MegaFlashROM já com os cartuchos transparentes, bem como Erwin finalizou a arte dos adesivos que estampam a frente dos cartuchos do Aleste Gaiden, que podem ser apreciadas nas fotos abaixo 🙂

Me lembro que há uns 3 anos atrás eu lancei o concurso Pop!Dev, visando premiar o desenvolvimento de software para MegaRAM, na época, onde o prêmio seria justamente uma MegaRAM 2MB. Infelizmente não houveram participantes nesse concurso e o mesmo foi cancelado alguns meses depois.

Felizmente ao participar de iniciativas como essa, onde membros da comunidade estão realmente focados em fazer algo acontecer, me faz repensar o relançamento do Pop!Dev novamente, sob outros moldes.

Posso afirmar que os vencedores do Pop!Dev do Aleste Gaiden, foram Marcelo Zoffy e Julio Lemos 🙂

Conforme prometido, tanto o Marcelo Zoffy, quanto o Julio Lemos, receberam 1 cartucho do Aleste Gaiden cada um deles pela grandiosa ajuda nesse projeto, pois sem eles talvez a ROM utilizada não fosse a do Aleste Gaiden, conforme pensado originalmente.

Agradeço também ao Sergio, que como um dos pais do projeto demonstrou uma grande capacidade e agilidade de “movimentação”, pois sabemos que em projetos desse tipo é necessário alguém com essa força em fazer a coisa acontecer, bem como ao Erwin pelas ideias e arte do cartucho e também a todos os que patrocinaram o projeto, sem vocês ele não teria acontecido nessa proporção em que aconteceu.

[]’s
PopolonY2k

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.

Tecnologia

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 {
  TOKEN_TYPE_UNKNOWN = 0,
  TOKEN_TYPE_SECTION,
  TOKEN_TYPE_DATA,
  TOKEN_TYPE_BLANK,
  TOKEN_TYPE_ONE_LINE_REMARKS,
  TOKEN_TYPE_MULTI_LINES_REMARKS,
  TOKEN_TYPE_OPEN_MULTI_LINES_REMARKS,
  TOKEN_TYPE_CLOSE_MULTI_LINES_REMARKS
};
/**
  * Data types enumeration.
  */
enum TokenDataType {
  DATA_TYPE_UNKNOWN = 0,
  DATA_TYPE_KEY_VALUE,
  DATA_TYPE_VALUE
};
/**
  * 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
;

FM1=C1,CH1
FM2=C1,CH2
FM3=C1,CH3
FM4=
FM5=
FM6=
FMR=
FM7=
FM8=
FM9=
PSG1=
PSG2=
PSG3=
SCC1=
SCC2=
SCC3=
SCC4=
SCC5=

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

C1=T200
CH1
=T200V8>E16G+16C+16E16V10<A16>C+16V14<G+16>C+16<A16F+16E16A16>E16G+16C+16E16V10<A16>C+16V14<G+16>C+16<A16F+16E16A16R8A.
CH2
=V14R1.R32C-16F+.F+32
CH3
=V14R1.<F+16>D.D16

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.

Filtros

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:

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>

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.

Conclusão.

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.

[]’s

PopolonY2k

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
http://www.popolony2k.com.br/?p=742

MusicA – Tocando MIDI no MSX – Parte III
http://www.popolony2k.com.br/?p=808

The Ultimate PPMCK MML reference
http://woolyss.com/chipmusic/chipmusic-mml/ppmck_guide.php

SiOPMML reference
http://mmltalks.appspot.com/document/siopm_mml_ref_05_e.html

Old Skool Tech – Old School Technology
http://sourceforge.net/projects/oldskooltech/

Regular Expressions (Regex)
http://en.wikipedia.org/wiki/Regular_expression

Standard Template Library (STL)
http://en.wikipedia.org/wiki/Standard_Template_Library

Boost C++ Libraries
http://www.boost.org/

Minimalist GNU for Windows (MinGW)
http://www.mingw.org/Windows

GCC – The GNU Compiler Collection
http://gcc.gnu.org/

Alexander Stepanov
http://en.wikipedia.org/wiki/Alexander_Stepanov

MusicA – Tocando MIDI no MSX – Parte III

Continuando a série de artigos sobre musica no MSX, vou apresentar a vocês um software bem interessante que descobri em minha busca por uma maneira de converter MIDI para o MSX, estou falando do MusicAMSX Music Editor/Player.

Existe pouco registro sobre a autoria do MusicA na internet, porém analisando internamente os binários desse software, descobri que o mesmo pode ter sido feito na Holanda, antes de 1992, devido a strings encontradas com texto no idioma desse País e também devido a diversos samples possuir em seus comentários o ano de 1992 com textos em holandês.

A única certeza é que um dos Players presentes no disco do MusicA foi feito em 1996 pelo japonês, Keiichi Kuroda. O outro Player do MusicA parece ser de origem holandesa, porém não sei se é original do MusicA editor ou se foi adicionado ao pacote, mas com certeza o conjunto deve ter sido montado por algum entusiasta no decorrer dos anos. Infelizmente não há site oficial para nenhum desses softwares.

O pessoal da Nerlaska Studio, da Espanha e que faz softwares, principalmente games para diversas plataformas entre elas o MSX, desenvolveu um Editor baseado no MusicA, para Windows que na verdade é um plugin para o BlueMSX, onde o mesmo parece utilizar o MML do MSX-BASIC, através do comando PLAY.

Voltando ao MusicA, a característica mais interessante desse software é que ele suporta quase tudo o que existe em tecnologia de hardware musical para o MSX, ou seja, com o MusicA podemos ter as seguintes possibilidades sonoras:

  • 3 Canais de som PSG;
  • 9 Canais de som FM;
  • 5 Canais de som SCC;

.

Tudo isso totaliza incríveis 17 canais de sons, o que nos possibilita criar composições superiores a qualquer uma existente no MSX hoje, sem contar as que utilizam a MoonSound é claro.

Ou seja, exceto pela ausência de suporte a placas MoonSound-like, o MusicA suporta tudo o que já foi lançado em matéria de hardware para o MSX, o que o torna um dos mais bem sucedidos lançamentos em matéria de software musical para o MSX dos últimos anos e ainda devemos considerar o fato de que com o MusicA, podemos escrever musicas que utilizam apenas os 3 canais do PSG, ou seja, podemos compor e converter musicas MIDI para tocar em um MSX 1, sem a necessidade de alguma placa mais moderna.

O MusicA é composto por duas peças fundamentais para o nosso processo de conversão de MIDI para o MSX, que é o MML Editor e o BGM RePlayer.

Vamos falar a seguir sobre os dois modos de operação do MusicA.

MusicA MML Editor.

O modo de edição do MusicA se trata de um poderoso editor feito para quem está disposto a trilhar o caminho da construção e edição de composições diretamente em MML. Com ele você pode escrever comandos MML, como os descritos na parte 2 dessa série, e a partir daí executar e buscar erros nas músicas, ou até mesmo editar e corrigir imperfeições em trechos da composição.

O editor do MusicA grava o seu MML em um formato próprio (texto), com a extensão .MSD. Esse arquivo, assim como o MML gerado pelo 3MLEditor, é o código fonte que contém toda a música em formato MML, pronta para ser editada e executada no software.

Além disso,  é no editor que você tem acesso ao modo de compilação do MML para o formato BGM, que é aceito pelo KINROU5 BGM Replayer do MusicA.

Segue abaixo um exemplo de um arquivo MSD aceito pelo MusicA:

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

;
; Channels definitions
;

FM1=C1,CH1
FM2=C1,CH2
FM3=C1,CH3
FM4=
FM5=
FM6=
FMR=
FM7=
FM8=
FM9=
PSG1=
PSG2=
PSG3=
SCC1=
SCC2=
SCC3=
SCC4=
SCC5=

;
; User custom MML definitions
;

C1=T200

;
; Channels MML content
;

CH1=T200V8>E16G+16C+16E16V10<A16>C+16V14<G+16>C+16<A16F+16E16A16>E16G+16C+16E16V10<A16>C+16V14<G+16>C+16<A16F+16E16A16R8A.
CH2=V14R1.R32C-16F+.F+32
CH3=V14R1.<F+16>D.D16

TIP

O arquivo MSD é dividido basicamente em duas seções:

  • Definição dos canais, organizados entre canais FM, PSG e SCC.
  • Definição das variáveis com o conteúdo MML a ser executado pelos canais.

MusicA - Editor

A imagem acima mostra a tela do editor do MusicA com um arquivo MSD, que é o formato MML padrão do MusicA, carregado e pronto para edição/execução.

Segue abaixo alguns atalhos de teclas aceitos pelo editor do MusicA:

  • F1 – Posiciona cursor no inicio do arquivo editado;
  • F2 – Posiciona cursor no final do arquivo editado;
  • F5 – Compila e executa o MML corrente no editor;
  • F3 – Pára execução do MML corrente no editor;
  • ESC – Aciona menu de opções do Editor (Manipulação de blocos de texto, opções de disco, configuração de canais);

.

Ao entrar nas opções de disco do menu principal (ESC -> D), temos as seguintes opções disponíveis:

  • ESC) QUIT – Volta ao Editor do MusicA;
  • 1) load MUSIC – Lê um arquivo MSD, que é o código fonte do MML, aceito pelo MusicA;
  • 2) load VOICE – Lê um arquivo de instrumentos do MusicA;
  • 3) save MUSIC – Salva arquivo (MSD) editado no momento;
  • 4) save VOICE – Salva arquivo de voz carregado no momento;
  • 5) save BGM – Compila o arquivo MSD e salva para o formato BGM (BackGround Music);

.

Após a edição de sua partitura MML, é claro que você desejará gravar o resultado de seu trabalho, então o menu de disco será amplamente utilizado, inclusive para compilar o MML do editor para um arquivo BGM, que é o arquivo utilizado pelo BGM Replayer, o que é feito pela opção 5 do menu de discos.

Apesar do editor aparentar ser simples, se trata de uma excelente ferramenta para criação de melodias para o MSX, porém nada melhor do que compor com instrumentos musicais reais aliado a possibilidade de edição profissional através softwares existentes na plataforma PC, então acredito que a utilização do editor do MusicA, será util apenas para que o arquivo MSD, seja convertido para BGM para que possamos utilizá-lo no MSX-BASIC, caso você não queira utilizar nada em BASIC, poderá utilizar o editor do MusicA apenas como um Player de áudio 🙂 .

Mas se você quer mesmo é desenvolver alguma musica para utilizar fora do editor do MusicA, então você precisa conhecer as duas opções de BGM Replayers que estão presentes no pacote do MusicA.

KINROU5 BGM Replayer.

Bom, estamos avançando e conhecendo cada vez mais algumas ferramentas úteis no MSX (e fora dele) que nos  possibilita ter musica de qualidade nessa plataforma de computadores.

Já sabemos o que é MML, como conveter MIDI para um formato MML proprietário do software 3MLEditor, também sabemos sobre como utilizar MML no MSX através do comando PLAY do MSX-BASIC e também conhecemos o editor de MML, chamado MusicA, que é similar ao 3MLEditor, mas que trabalha com um formato próprietário, que é o MSD.

Sabemos também que o editor do MusicA pode compilar o formato próprio (MSD) e convertê-lo para o formato BGM, que é utilizado em muitos jogos de MSX.

Mas fica a pergunta no ar. Como utilizar esse “bendito” BGM no MSX-BASIC, principalmente em meus jogos e programas ?

Existem dois players presentes no pacote compactado do MusicA, que pode ser obtido nesse site aqui, cujo funcionamento vou explicar a seguir.

O primeiro player está na imagem de disco 720K chamada datafunk.dsk e ao inserir essa imagem no seu emulador ou gravá-la em disquete de 3/12” para utilização em um MSX real, você terá acesso aos arquivos binários do KINROU5 , bem como alguns arquivos em BASIC que servem como exemplo de utilização das músicas BGM presentes  também no disco.

Segue abaixo as informações sobre cada um desses módulos, bem como sobre as funcionalidades programáveis do KINROU5, via MSX-BASIC.

Arquivos do Kinrou5 BGM Player

 

FILES “*.*”

  • REPLAY.BIN, GBAS07.SYS, GBAS07.LDR, KINROU05.DRV –  Esses arquivos juntos compõe o Player que poderá ser utilizado pelos seus programas em MSX-BASIC;
  • *.MSD – São arquivos MML aceitos pelo MusicA Editor e não tem funcionalidade fora desse programa, ou seja, é apenas um arquivo texto comum com conteúdo MML;
  • *.BGM – São arquivos de musica aceitos pelo player;
  • AUTOEXEC.BAS, NTSCFUNK.BAS – Código MSX-BASIC com exemplos de utilização dos comandos do player;
  • DATAFUNK.FLP – Sem uso conhecido;

Segue abaixo um programa MSX-BASIC que coloca o player em ação:

MSX-BASIC source code

10 COLOR 15,1
20 CLEAR:DEFINT A-Z
30 BLOAD“gbas07.ldr”,R
40 CMD LOAD (“datafunk.bgm”)
50 CMD PLAY
60 CLS:RESTORE
70 PRINT “DataFunk  ”
80 PRINT
90 PRINT
100 PRINT
110 PRINT “FMPAC + PSG”
120 PRINT
130 PRINT
140 PRINT”  press q to stop”
150 IF INKEY$=“q” THEN 170
160 GOTO 150
170 CMD STOP
180 CMD
190 CLS

Preste atenção na linha 30, onde é carregado o player através do comando BLOAD “gbas07.ldr”,R. Não se esqueça que os demais binários do player, conforme descrito anteriormente, são necessários para o funcionamento do mesmo, pois o GBAS07.LDR, é quem carrega esses arquivos.

O restante do “truque” continua na linha 40, onde o player aproveitou a palavra reservada, CMD do MSX-BASIC, adicionou a rotina do player ali para que pudessemos, através do MSX-BASIC, comandar suas ações.

Abaixo eu deixo o texto retirado do MSX Technical Handbook e que descreve como implementar funções adicionais ao MSX-BASIC utilizando essa palavra reservada.

TIP (In English please)

4.3 Making New Commands

In MSX the reserved words “CMD” and “IPL” are currently unused and by changing the pointers to these words (FE0DH and FE03H) to jump to your own assembly language routine, new commands can be built.

Os parâmetros aceitos pelo player via CMD são os seguintes:

  • LOAD( “NOME_ARQ.BGM”) – Carrega um arquivo BGM para execução;
  • PLAY – Inicia a execução da música BGM;
  • STOP – Pára a execução da música BGM;

.

É bem simples assim e com um pouco de traquejo, podemos até fazer um programa que crie excelentes interfaces com o usuário.

REPLAY.BIN

O outro player é o REPLAY.BIN que está presente no disco principal do MusicA (musica.dsk) possibilita, assim como o KINROU5, a integração com o MSX-BASIC. Segue abaixo um código MSX-BASIC, retirado do próprio pacote do MusicA (LOADMUS.BAS), que poderá ser utilizado como exemplo de utilização desse player.

MSX-BASIC source code

10 CLEAR 200,&HA5B6 : DEFINT A-Z : DIM A(1)
20 BLOAD“REPLAY.BIN”:BLOAD“KNIGHT.BGM”
30
40 DEFUSR0=&HCE00:‘ Init muziekdata
50 DEFUSR1=&HCE03:‘ Start muziek (a=usr(xx):xx=adres muziek)
60 DEFUSR2=&HCE06:‘ Stop muziek
70 DEFUSR3=&HCE09:‘ Fade controller (a=usr(xx):xx=volume)
80 DEFUSR4=&HCE0C:‘ PSG kanalen aan/uit?? (a=usr(xx):xx=kanalen keuze)
90
100 RESTORE190:FOR A=&HAFF7 TO &HAFFF:READ F : POKE A,F : NEXTA
110 A=USR0(0):A=USR3(4)
120 A(0)=0
130 A(1)=&HA5B7: ‘ Beginadres muziekstuk
140 A=USR1(VARPTR(A(0)))
150 FOR W=0 TO 8:A=USR3(PEEK(&HAFF7+W)):FOR P = 1 TO 60 : NEXT P : NEXT W : ‘FADE IN
160 FOR W=8 TO 0 STEP -1 : A=USR3(PEEK(&HAFF7+W)):FOR P=1 TO 60 : NEXT P : NEXT W : ‘FADE OUT
170 PRINT“A=USR2(0) ‘Stopt de muziek” : END
180 ‘ Data fade in
190 DATA 4,5,6,2,13,3,12,14,15

Ao contrário da facilidade do código MSX-BASIC do KINROU5, o REPLAY.BIN é um pouco mais complicado de se programar, porém existe a vantagem dos efeitos FADE ON/OFF.

Na linha 20 BLOAD“REPLAY.BIN”:BLOAD“KNIGHT.BGM”, temos a carga do binário do REPLAY.BIN juntamente com o arquivo de música, KINGHT.BGM.

A partir daí, as linhas 40 até 80, definem as rotinas desse Replayer, com as possibilidades de PLAY (linha 50), STOP (linha 60), controladores de Fade On/Off ( linha 70).

Esse replayer é bastante poderoso porém existe um ponto de instabilidade que causa o travamento da máquina e ocorre quando você tenta carregar outra musica no replayer sem parar a música que está em execução, ou seja, certifique-se de chamar a rotina que pára a música, no caso do exemplo acima com a chamada a USR2(0), antes de carregar outra música.

Conclusão

Estamos no fim da terceira parte dessa série de artigos sobre música no MSX e já temos compreensão de grande parte do processo de transporte de uma música MIDI para o MSX, porém faltou uma peça aí no meio do caminho que é um procedimento para transformar arquivos em formato MML, gerados pelo 3MLEditor, para os arquivos MSD suportados pelo MusicA para enfim convertê-los em BGM e acessá-los pelo MSX-BASIC ou qualquer outro software que suporte esse formato.

O último artigo da série irá explicar sobre o  compilador de linha de comando que desenvolvi, denominado mml2msd, e que é capaz de converter arquivos MML para MSD, aplicando diversos filtros de conversão em cima do MML original, afim de que o MML final (MSD), seja compreensível pelo MusicA, uma vez que o MML aceito por esse software não é 100% compatível com o gerado pelo 3MLEditor.

Bom, vou ficando por aqui e brevemente estarei liberando o último artigo da série, sobre música no MSX.

Aguardem as novidades e, repetindo as sábias palavras do jovem mestre intergaláctico, o ET Bilu, principalmente que busquem conhecimento 🙂 .

[]’s

PopolonY2k

Referências na internet

MusicA Tools
http://www.nerlaska.com/msx/musica.html

MusicA – Download
http://woolyss.com/chipmusic/chipmusic-mml/MuSICA.zip

MML Resources
http://woolyss.com/chipmusic-mml.php

Nerlaska Studio
http://www.nerlaska.com

Konami SCC
http://en.wikipedia.org/wiki/Konami_SCC

MoonSound Wikipedia
http://en.wikipedia.org/wiki/Moonsound

MusicA – Tocando MIDI no MSX – Parte II
http://www.popolony2k.com.br/?p=742

Takamichi’s Konami and other MSX Music Resources
http://www.msxnet.org/gtinter/konamuus.htm

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.

MSX-BASIC code:

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:

MSX-BASIC code

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.

WARNING:

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:

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

[Channel1]
//Ý’聄MIDIÝ’聄DLS‚‰¹Ž¿„
//ƒ}ƒrƒmƒM‚ÌMP3ƒtƒHƒ‹ƒ_“à‚Ì
//MSXspirit.dls‚ðŽw’肵‚Ä‚­‚¾‚³‚¢

//Ž©ì‚Æ‹U‚ç‚È‚¢•”„‚ç‚È‚¢‚Å‚­‚¾‚³‚¢
//ƒ}ƒrƒmƒM“à‚ł̉‰‘t‚Í‚²Ž©—R‚É

//‡}—pƒƒgƒ«ƒRƒsƒy‚Å
//MML@v15aaa>a
//http://cure.chu.jp

//Œ·ŠyŠíƒŠƒ…[ƒg„§

t200v8
>e16g+16c+16e16v10<a16>c+16v14<g+16>c+16<a16f+16e16a16

>e16g+16c+16e16v10<a16>c+16v14<g+16>c+16<a16f+16e16a16r8a.
[Channel2]
v14r1.r32c-16f+.&f+32
[Channel3]
v14r1.<f+16>d.&d16

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:

MSX-BASIC code:

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.

[]’s

PopolonY2k

Referências na internet

Meridian – MIDI editor/player para MSX.

http://www.opl4.nl/

MML – Music Macro Language

http://en.wikipedia.org/wiki/Music_Macro_Language

Protocolo MIDI

http://pt.wikipedia.org/wiki/MIDI

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

http://msxlivros.blogspot.com/

Maximum MIDI Toolkit

http://www.maxmidi.com/

3MLEditor (3MLE)

http://3ml.jp//

MSX Music Editor/Player

http://www.nerlaska.com/msx/musica.html

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