Bom, esse é um mini-post bem rápido apenas para lembrar que no último dia 27 de Junho, o MSX fez 28 anos de idade e o site do UOL Jogos fez um vídeo bem interessante sobre essa plataforma de computadores que é sempre lembrada pelos seus games, principalmente os clássicos como Metal Gear, Nemesis, Vampire Killer (aka CastleVania) entre outros mais.
Espero que gostem, realmente ficou muito bom e com um excelente detalhamento da história.
Esse ano é um bom ano para o MSX no cenário nacional. Na parte de hardware sempre pudemos contar com produtores que estão sempre ativos construindo “antigas” novas tecnologias para nossas máquinas e algumas vezes construindo até novas máquinas do zero, ou quase do zero, como é o caso dos kit’s de conversão ou até mesmo motherboardsMSX, “zero bala”, para adaptação em gabinetes de PC ou em antigos Experts e HotBits.
Pois bem o cenário de hardware é bem ativo, algumas vezes dá uma descansada mas sempre se levanta com novidades, porém o mesmo não acontece com software desde a época de ouro do MSX, no Brasil. Para falar a verdade, apesar dos muitos softwares escritos originalmente em nosso País, creio que o desenvolvimento de software nunca foi um sucesso em nosso País, independente da plataforma utilizada.
Felizmente nos últimos anos, o Brasil tem começado a colher os frutos da formação de profissionais nas décadas de 70, passando pelos 80 e chegando até os 90 e para mim é inevitável que o País se torne referência em software nos próximos 10 anos, pois os profissionais de software sofreram muito ao viver as épocas em que eram “generalistas“, ou seja, podiam fazer tudo na área de tecnologia.
Por um lado ser generalista é ruim, pois não nos especializamos em um nicho de mercado, que de certa forma nos tornaria mais caros no nicho escolhido, mas analisando de uma maneira mais ampla e aberta, com certeza chegaremos a conclusão de que é isso que nos torna melhores arquitetos de software do que outros pelo mundo afora, uma vez que pensar em tudo e criar abstrações para esse “tudo”, só pode fazer quem já viveu uma situação de atuar no “todo”. 🙂
Mas é claro que só poderemos ser uma potência em software se o governo federal também fizer a parte dele que é, proporcionar uma boa infra-estrutura de ensino para os nossos jovens, e futuros profissionais. Atualmente o mérito é individual e apenas do povo brasileiro, através dos esforços dos pais (não confundir com País) e avós dessa geração que citei anteriormente, que foram os investidores dessa geração que aí está.
Voltando ao software, recentemente adquiri um lote de coisas para MSX, que vão desde hardwares e softwares a diversas revistas, incluindo MSX Magazine e outras revistas, que só tratavam de software em seu conteúdo, cada uma com mais de 100 páginas só de softwares escritos em diversas linguagens (MSX-BASIC, Prolog, ADA, C, ASM, …) , tudo da década de 80.
Revistas de MSX japonesas.
Pois bem, olhando esse material todo apenas tive a confirmação do porque os melhores games e softwares eram feitos no Japão. Simplesmente porque, aliado ao fato deles desenvolverem grandes softwares, eles desenvolviam conhecimento e difundiam em massa e ainda obtinham lucro com isso. Essas revistas tem tanto conteúdo técnico de qualidade, que eles são aplicáveis em qualquer plataforma atual e talvez todo esse conhecimento explique o porque de ainda existir diversos grupos construindo coisas para MSX no Japão e Europa e também para outras plataformas como C64, NES, SNES, Sega Genesis (aka Mega Drive), entre outros.
20 e tantos anos depois…..
…muitos dos que viveram aquela época, hoje nem trabalham com software ou na área técnica, entretanto a grande maioria das pessoas daquela geração e que hoje estão no mercado de trabalho, ou trabalha com um computador ou pelo menos o utiliza como ferramenta no dia-a-dia e para entretenimento.
Dentre essas pessoas encontramos, Designers e Web Designers, Programadores, Músicos, Gamers, entusiastas de tecnologia, enfim, muitos de nós, desenvolveu bastante suas capacidades técnicas nos computadores pessoais, desde a épocas passadas.
Podemos dizer que, hoje, somos muito mais capazes de realizar proezas técnicas diversas, com muito mais facilidade e qualidade do que naquela época e também baseado nesse raciocínio posso dizer que se fosse possível voltar no tempo, com o conhecimento que temos hoje, poderíamos ao menos fazer frente aos dominadores do conhecimento da época. A situação seria ainda melhor se conseguíssemos construir coisas utilizando recursos computacionais modernos, como os que temos hoje. Com certeza seria um diferencial.
Não é muito difícil encontrar grupos, ao redor do mundo, que tem um ponto de vista similar ao que citei anteriormente, veja o caso do pessoal da Relevo Video Games, que desde 2009 vem lançando games originais para plataformas MSX e ZX-Spectrum, com qualidade excepcional, como é o caso do excelente e já consagrado Invasion of the Zombie Monsters, que é um game de 32Kb com gráficos, musicas e jogabilidade superior a muitos dos clássicos da época de ouro dessas plataformas e, serei ousado, superior a muitos games da mesma categoria feitos para plataformas mais atuais como Android e iPhone.
Capa do game Invasion of the Zombie Monsters
Ao acompanhar o nascimento de grupos como o pessoal da Relevo, que começou fazendo games para plataformas antigas e que já ensaiam lançamentos para outros dispositivos Mobile, acredito que o Brasil pode e tem potencial técnico, criativo e artístico para desenvolver projetos similares aos da Relevo.
Vale a pena lembrar que a Relevo Video Games é certamente um reflexo e fruto do investimento dos espanhois no desenvolvimento de video-games, iniciado na década de 80 onde empresas como Dinamic Software e Opera Soft, desenvolviam games para MSX & ZX-Spectrum, na grande maioria das vezes inferiores aos japoneses, porém era uma época de busca do Know-How necessário para fazer frente aos japoneses na arte dos games no futuro.
Bom, se passaram 20 e poucos anos e finalmente podemos dizer que os espanhóis fazem frente a qualquer outro player no mercado de video-games, haja vista que os próprios japoneses começam a entregar o desenvolvimento técnico de suas consagradas franquias, como CastleVania (aka Vampire Killer para os MSXzeiros), a empresas espanholas.
CastleVania – Lords of Shadow, mostra o sucesso espanhol no desenvolvimento de games, iniciado na década de 80, uma vez que uma franquia de origem japonesa e que ao longo dos anos sempre fora desenvolvida em solo japonês e exclusivamente por japoneses, dessa vez é produzida em “terras” espanholas, através da Mercury Steam, só demonstra que o investimento de longo prazo é sempre a melhor opção.
Enquanto isso no Brasil…
…ainda engatinhamos no desenvolvimento de games e softwares para consumo do publico em geral, porém já começamos a ser reconhecidos em algumas áreas, pelo menos como um país potencial em desenvolvimento de software, apesar do mercado ser reconhecidamente inexplorado.
Desde cedo eu sempre acreditei que jogar video-games, era algo fenomenal pelo ponto de vista do aprendizado mas quando eu falava isso para um adulto na época, lá pelos anos 1980, não chegava a ser motivo de chacota mas o pessoal mais velho simplesmente ignorava a minha opinião, mais pela diferença entre gerações, entretanto por situações como essa, talvez, tenhamos perdido muito dos futuros profissionais que não chegaram a acontecer para o mercado de desenvolvimento de games.
Sempre acreditei que o simples fato de assistir alguém jogando já era o suficiente para fazer a cabeça pipocar as ideias, pois é necessário técnica apurada e conhecimento de algoritmos otimizados e também ser pelo menos um bom programador para se construir produtos de qualidade. Com o tempo percebi que jogar poderia ser mais produtivo para os que seguiram a carreira de desenvolvimento de software e design, do que para a grande maioria que estava apenas interessada em jogar.
Bom, como sou persistente e raramente jogo a toalha de primeira, fiquei muito feliz ao ler essa noticia no TechTudo, onde o autor descreve sobre um evento ocorrido em 25 de fevereiro desse ano (2011), denominado “O Mercado de Games e Aplicativos no Brasil” e também esse outro artigo, também no TechTudo, que vai de encontro exatamente ao que penso, onde o bom produtor de jogos deve ser um auto-didata, deve gostar de aprender e desenvolver coisas novas sempre, saber algumas linguagens e principalmente jogar MUITO !!!
Outra coisa bem legal que o autor cita é sobre, criar um grupo de estudo sobre games, que discuta ideias, técnicas, converse, extrapole as discussões, ou seja, desenvolva as ideias e as transforme em realidade, desenvolvendo novas técnicas e tecnologias, criando ferramentas, pois tudo isso gera a experiência necessária para o desenvolvimento de produtores em potencial para o mercado de games.
É bom saber que um grupo de estudos e desenvolvimento é um bom inicio e melhor ainda é saber que já temos um que está a pleno vapor, desenvolvendo um projeto de um RPG para MSX 2.0, totalmente feito em MSX-BASIC, com suporte a som de qualidade, compatível com placas FM do MSX (Panasonic FM-PAC, Tecnobytes FM-Stereo, …) e com toda capacidade de cores e gráficos que esses micros tem e que pouco foram aproveitados pelos desenvolvedores brasileiros da época.
Esse grupo, que ainda não tem nome, é composto por músicos, designers e programadores que viveram, ou não, a época de ouro do MSX e basicamente vem interagindo e desenvolvendo todo o game apenas em conversas por MSN e também na comunidade MSX-Brasil, no Orkut, que de maneira natural se tornou a “casa” do jogo, podendo ter seu desenvolvimento acompanhado aqui nessa discussão.
O nome do jogo é Visitantes – Experimento Sombrio e até o momento, diversas técnicas já foram desenvolvidas, como as de conversão de música MIDI para o MSX, conforme descrito na série MusicA – Tocando MIDI no MSX I, II, III e IV.
Grande parte do código do engine responsável pela execução do RPG também está pronta, sendo que ainda está previsto o desenvolvimento do game editor, necessário para edição da interação com o usuário.
Claro que muitas outras técnicas e novidades estão a caminho e ainda é muito cedo para detalhar algo sobre esse desenvolvimento, porém a medida que o projeto avança, alguns snapshots serão lançados ao público, como o vídeo que já está disponível no YouTube, através desse primeiro making of do que está rolando no desenvolvimento do game.
Bom, eu acredito que esse essa iniciativa é não só inovadora do ponto de vista técnico mas também pelo fato de comprovar que a internet é um meio produtivo que dissemina a idéia de que não importa mais o local onde as pessoas estão e sim o que elas podem fazer de onde elas já estão. 🙂
Espero que em breve tenhamos um mercado potencial no desenvolvimento de jogos no Brasil e espero um dia poder colher frutos disso mas enquanto isso….mãos na massa….tenho algumas coisas para terminar aqui 🙂
Após um pequeno intervalo, retorno com uma informação extraordinária em todos os sentidos pois eu, que pretendia fazer mais um artigo com testes e análise de performance dos dispositivos compatíveis com IDE‘s para MSX, fui surpreendido por um e-mail com excelente feedback do amigo de lista MSXBR-L, Alexandre Antoniutti Passos, que também é o criador e mantenedor do também excelente projeto MSX Livros.
Esse feedback me fez colocar a mão na massa e desenvolver esse add-on para o artigo original.
Por e-mail, ele me passou que realizou alguns testes com HD‘s e DVD‘s de alguns fabricantes, com sucesso no funcionamento, e que descrevo abaixo:
COMPATIBLE DEVICES
Gravadores de DVD
Marca : LG Modelo : GSA-4167B
Marca : AOpen Modelo : DSW1812P
Hard Disks
Marca : Toshiba Capacidade : 80GB Modelo : mk8025gas
Marca : IBM Capacidade : 12.07GB Modelo : DARA-212000
Abaixo também algumas fotos dos CompactFlash testados, das marcas DaneElec 1Gb e Kigston 512Mb.
Uma informação importante que o Antoniutti passou foi que utilizando a IDE Tecnobytes com um adaptador CF-IDE específico, ele teve problemas de reconhecimento do dispositivo CompactFlash, similar ao que experimentei enquanto escrevia o artigo Dossiê Storage Devices – Parte II (Compact Flash).
O adaptador CF-IDE testado por ele é vendido na DealExtreme, por U$2.62, conforme pode ser verificado no link do produto.
Analisando os comentários dos compradores no site do revendedor, percebi que, apesar da satisfação com o produto, a grande maioria das pessoas reclamou da velocidade de transferência obtida com o uso desse adaptador.
Como no caso do meu adaptador, esse produto tem suporte a DMA33 (UDMA), então esses comentários sobre a sua baixa performance me deixaram um pouco ressabiado quanto a qualidade do produto, uma vez que, com esse suporte a UDMA, o mesmo não deveria ter problemas de performance e essa qualidade, ou falta dela, pode ser o que causa instabilidade quando utilizado junto com a IDE Tecnobytes.
Talvez a qualidade dos adaptadores existentes no mercado, justifiquem o pessoal da Sunrise ter vendido, até uns poucos meses atrás, adaptadores CF-IDE para uso em conjunto com suas interfaces IDE, sendo que o negócio deles é fazer somente a interface e que nesse caso pode ter a sua qualidade contestada ou afetada por conta de produtos de terceiros com baixa qualidade.
Bom, apesar de ter gostado bastante das informações recebidas sobre novas marcas e dispositivos testados, para mim, o mais interessante do feedback, foi o Casemod feito por ele e que integra um dispositivo de DVD a um adaptador de CF-IDE, tudo isso envolvido em um case de drive DDX, demonstrando a criatividade e cuidado do autor em deixar um produto mais atual, que é o drive de DVD, com o estilo e espirito do MSX, ao colocá-lo em um case de drive DDX.
Melhor do que falar ou escrever é mostrar, então segue abaixo as imagens do trabalho realizado bem como o resultado final.
Aproveito para agradecer pelo feedback do Alexandre Antoniutti, bem como as imagens cedidas de todo esse excelente trabalho realizado e deixo desde já as portas sempre abertas ao Antoniutti e a quem mais queira contribuir com suas experiências no universo MSX ou qualquer outro Universo paralelo.
O mercado nacional de hardware para MSX está bastante movimentado nos últimos 3 anos, sob minha percepção, pois são construídos pelos produtores independentes, muitas novidades bem interessantes para os saudosistas, hobbistas e entusiastas, como esse que vos escreve.
A coisa está tão boa para o MSX aqui no Brasil, que no momento em que escrevo esse review, estou me deliciando com os mais de 20Mb de arquivos MOD, que baixei a noite passada e que o meu Panasonic A1WX MSX 2+ ficou um bom tempo descompactando, onde os reproduzo agora através da minha OPL4 Shockwave, uma placa Moonsound-like e que finalmente podemos adquirir aqui no Brasil graças a produção de Ricardo Oazem da Tecnobytes.
E por falar em Tecnobytes……
….para quem não se lembra, ou sabe, é uma produtora de hardware para MSX que vem desenvolvendo e comercializando coisas desde a década de 80/90 e que produziu naquela época uma placa compatível com as Panasonic FM-Pac, a famosa FM-Stereo.
E desde aquela época já percebemos o diferencial nas produções da Tecnobytes, que desenvolve produtos completamente compatíveis com os lançados no mercado internacional porém sempre com uma inovação extra, no caso da FM-Stereo, a característica Stereo dessa placa e sua qualidade sonora superior a FM-PAC original.
Bom, se inovação é a praia dos produtos da Tecnobytes, é bom sempre esperar algo diferenciado vindo deles e no caso da interface IDE o maior benefício, para mim, foi a possibilidade de colocar o MSX no mesmo patamar de armazenamento existente no mundo dos PC’s, considerando as devidas proporções, o que no final me tira o peso psicológico de que não estou vivendo e sim sobrevivendo no mundo MSX.
E por falar em sobrevivência….
…nós sobrevivemos……
….durante anos e anos com nossos disquetes e que mais tarde se transformaram em imagens .dsk para emuladores, como os fMSX, OpenMSX e BlueMSX e graças aos BBS e a internet, esses programas também “sobreviveram” até os dias atuais.
Ganhamos tempo suficiente para conseguir desenvolver tecnologia e adequar os nossos MSX aos padrões mais atuais de armazenamento de dados, como as interfaces IDE.
Tecnobytes ATA IDE Interface
Interface IDE não é algo novo no mundo MSX, pois já existe desde o final dos anos 90, através do produtor internacional de hardware para MSX, a Sunrise. No Brasil uma interface similar já foi produzida e comercializada pela ACVS, que é um outro player que está, digamos, um pouco inativo no cenário MSX nos últimos anos e por último temos a Tecnobytes, que vem produzindo hardware de forma mais constante, bem como produzindo algumas peças de hardware em edição limitada, como o caso das OPL4Shockwave e V9990 PowerGraph.
Sobre a IDE da Tecnobytes anotei algumas características, após alguns meses de uso, descritas abaixo:
Possibilidade de utilização de dispositivos baseados em memória flash, ou Compact Flash.
Pelo fato de ser uma interface Sunrise-like, tem compatibilidade total com os softwares produzidos para a interface da Sunrise, que são muitos, bem como podemos aproveitar qualquer especificação de funções da BIOS dessas interfaces, disponível na internet, para escrever softwares utilitários para essa interface.
Possibilidade de atualização de BIOS, como a nova 2.50 (beta) que está saindo do forno do Laboratório da Tecnobytes, segundo informações do próprio Ricardo Oazem através da lista MSXBR-L.
.
Limites das IDE’s no MSX.
WARNING
Apesar de possível o uso de dispositivos com qualquer capacidade nas interfaces IDE para MSX (Sunrise-like), existem limitações quanto ao número de partições que essas interfaces podem endereçar no MSX, que chega ao valor máximo de 31 partições.
O sistema operacional do MSX (MSXDOS) também tem limitação de trabalhar com FAT12 que por sua vez pode endereçar até 32Mb, ou seja, poderíamos endereçar o máximo de 31 partições com 32Mb, totalizando aproximadamente 1Gb, ou seja, dispositivos com 2Gb, 4Gb, ou 6Gb não seriam aproveitados em sua totalidade.
Porém existe a possibilidade de utilização do MSXDOS2, que com o devido patch aplicado, poderá suportar partições com FAT16, aumentando assim a capacidade de endereçamento do sistema operacional, que passará suportar partições de até 2Gb. Infelizmente, esse patch é um software residente que deve ser carregado após o boot do sistema operacional, ou seja, você deverá ter pelo menos uma partição com FAT12 configurada em seu disco, para a carga inicial do sistema operacional, podendo deixar as demais com FAT16, por exemplo, possibilitando assim o uso completo de dispositivos acima de 2Gb até aproximadamente 60Gb.
Acredito que a versão 2.44 do MSXDOS2, liberada pelo pessoal da TNI conforme esse anuncio, suporte FAT16 nativamente sem a necessidade de softwares residentes, porém ainda não testei.
Apesar de existir a possibilidade de utilização da IDE com o MSXDOS, na prática sua utilização fica limitada pela falta de capacidade de manipulação de sub-diretórios por esse sistema operacional e também pelo fato do número máximo de arquivos possíveis por diretório no MSXDOS ser 512, e como o MSXDOS suporta 1 diretório apenas, logo temos um total de 512 arquivos possíveis em um dispositivo conectado à controladora IDE.
Mas quem em sã consciência irá utilizar um dispositivo de 1Gb, 2Gb, 4Gb ou 8Gb para armazenar 512 arquivos apenas ???
TIP
Existe a possibilidade de se burlar essa limitação do número de diretórios no MSXDOS e existe alguns comandos externos, cd.com, rd.com, md.com, que foram desenvolvidos e explicados em um artigo da Revista CPU na metade da década de 90, e que adicionam essa capacidade de manipulação de sub-diretórios no MSXDOS.
Entretanto, como esses comandos não são comandos built-in do sistema operacional, sua utilização requer malabarismos que praticamente impossibilitam o seu uso nesse sistema operacional, por isso ao utilizar uma IDE, prefira o MSXDOS2, que já possui todos os requisitos para manipulação de dispositivos de grande capacidade que uma interface IDE proporciona ao MSX.
Testes de compatibilidade
Realizei testes de compatibilidade com diversos dispositivos IDE, utilizando a interface ATA IDE Tecnobytes e o resultado dos testes estão descritos abaixo.
HARDWARE HOTFIX !!! IMPORTANTE !!!!
No dia 02/02/2011 a Tecnobytes, através de Ricardo Oazem, liberou na MSXBR-L um HotFix que corrige um problema de detecção de alguns dispositivos IDE, principalmente HD‘s.
Para as interfaces ATA IDE Tecnobytes construídas antes dessa data, o HotFix deve ser aplicado caso o usuário dessas interfaces estejam enfrentando problemas na detecção de dispositivos IDE.
No anúncio, o fabricante informou que caso o usuário não se sinta seguro de fazer o HotFix, basta enviar a interface a ele que a alteração será realizada.
O custo do capacitor cerâmico utilizado no HotFix, foi de R$0,10 (10 centavos) e o tempo que levei para aplicar esse Patch, foi de 1 minuto, ou seja, é muito simples.
WARNING2 Apesar do MSX nem sonhar com transferências disponíveis a dispositivos IDE UDMA (Ultra DMA), que chegam a no mínimo 33mb/s, todos os testes realizados com dispositivos que utilizam cabo IDE (Hard Disks, CDROM‘s, etc, …), antes do HotFix da Interface, só funcionaramquando utilizado um cabo UDMA (80 vias), sendo que quando testados com um cabo de 40 vias, esses dispositivos sequer foram reconhecidos.
Após o HotFix da Interface, os dispositivos passaram a funcionar com cabos IDE de 40 vias.
Teste de compatibilidade com Hard Disks.
Dispositivos HD’s são um dos principais motivos da existência do padrão IDE e também por muito tempo foi o sonho de consumo dos usuários de plataformas antigas da década de 80 e apesar de existir hoje dispositivos mais modernos e compactos, há ainda uma grande procura, no mercado, por Hard DisksIDE. Por esse motivo, realizei alguns testes com alguns HD‘s disponíveis na minha bancada de testes.
São eles:
Quantum Fireball 500Mb.
Quantum Fireball lct 20.4Gb.
Western Digital 160Gb SATA com adaptadores SATA->IDE.
.
Antes do HotFix da interface, apenas o Fireball 500Mb havia sido reconhecido, formatado e utilizado na interface IDETecnobytes e embora o Western Digital 160Gb SATA tenha sido apenas um teste despretensioso onde eu já esperava o seu não funcionamento, pois o mesmo é instável até mesmo quando utilizado com adaptadores SATA->IDE no PC, a surpresa ficou quanto ao não reconhecimento e funcionamento do Quantum Fireball lct 20.4Gb, entretanto esse mesmo dispositivo funcionou após o HotFix disponibilizado pela Tecnobytes, confome descrito anteriormente.
WARNING3
Em teoria as IDESunrise-Like suportam qualquer Hard Disk, até mesmo os de 160Gb, porém na prática, conforme explicado anteriormente, essas interfaces só conseguem endereçar aproximadamente 60Gb desse dispositivo, devido as limitações do número de partições dessas interfaces, aliado ao limite de tamanho das partições FAT(12/16) do sistema operacional MSXDOS/MSXDOS2.
Teste de compatibilidade com CDROM’s.
Apesar de existir dispositivos de CDROM compatíveis com o padrão IDE e todos esses, em teoria, ter compatibilidade garantida com a IDE da Tecnobytes, resolvi fazer alguns testes com 2 modelos que estavam disponíveis aqui em minha bancada de testes.
São eles:
LG RW 16x~40x.
CDROM Genérico 56X (Xing-Ling).
.
WARNING4
Antes do HotFix da interface, esses dois dispositivos foram reconhecidos apenas quando utilizados com um cabo IDE 80 vias (UDMA) e após o HotFix, os mesmos funcionaram com cabos IDE 40 vias.
Fiz alguns testes, utilizando o pacote do MSXDOS2 e utilitários que está disponível no tutorial de instalação e configuração para IDE‘s Sunrise-Like no site da MSX Pró e após executar o comando IDECDEX.COM, o CDROM ficou mapeado como drive C: em meu MSX e a partir daí consegui navegar em diversos CD‘s de dados, validando assim o funcionamento desses dispositivos de CDROM na IDE Tecnobytes.
Teste de compatibilidade com DiskOnChip.
Um dispositivo bastante incomum, mas que testei também na interface IDE da Tecnobytes, foi o DiskOnChip IDE.
Para quem não conhece, o DiskOnChip é uma tecnologia de Flash Disks desenvolvida pela empresa Israelense M-Systems, conhecida por ser a pioneira no desenvolvimento da tecnologia SSD e que no inicio dos anos 2000 foi adquirida pela SanDisk, empresa líder em tecnologia de armazenamento em memórias Flash.
Existem diversos tipos de DiskOnChip, que vão desde chips que podem ser integrados a dispositivos embarcados, até DiskOnChip já integrados a uma interface IDE, podendo ser conectados a PC‘s comuns, mas que geralmente são utilizados em dispositivos embarcados com arquitetura de PC comum, como por exemplo placas PC/104 e SBC (Single Board Computer).
Fiz um teste utilizando o meu DiskOnChip de 256Mb com a interface IDE Tecnobytes e a mesma não reconheceu esse dispositivo. Não fiz nenhuma pesquisa técnica sobre as capacidades da interface IDE presente no DiskOnChipM-Systems que possuo, em busca de algum requisito mínimo desse dispositivo e também não consultei os limites da Interface IDE da Tecnobytes em busca alguma incompatibilidade entre a mesma e dispositivos desse tipo.
Caso a IDE Tecnobytes conseguisse reconhecer esse dispositivo, existiria um outro impecilho para seu uso no MSX, uma vez que DiskOnChip utilizam um FileSystem específico denominado TrueFFS, cuja implementação da camada gerenciadora de FileSystem do sistema operacional hospedeiro deve estar disponível para que se tenha acesso a dispositivos DiskOnChip, o que já acontece nos Sistemas Operacionais, Linux, Windows e todos os BSD‘s existentes.
Teste de compatibilidade com Compact Flash.
Eu me aprofundei nos testes da IDE com dispositivos Compact Flash e cheguei a conclusão que , além de mais confiáveis e rápidos, os CF’s no MSX terão menos problemas de reconhecimento pela IDE no MSX do que qualquer outro dispositivo.
Quando iniciei minha bateria de testes com dispositivos Compact Flash na IDETecnobytes em meus MSX, fiquei receoso de que algumas marcas pudessem não funcionar devido alguma limitação tanto por parte da IDE quanto por parte do Compact Flash, porém após fazer um estudo para escrever a segunda parte do Dossiê Storage Devices – Compact Flash, percebi que os Compact Flash, principalmente os mais modernos, são dispositivos extremamente inteligentes e que suportam diversos modos de operação, tanto como dispositivos USB ou IDE, suportando modos de transferência de dados mais rápidos UDMA ou mais lentos PIO, …… e independente de um Compact Flash ter suporte a UDMA e o MSX nem sonhar com uma taxa de transferência próxima de um dispositivo UDMA (mínimo de 33Mb/s), os Compact Flash, devem suportar modos que possibilitem o seu acesso por dispositivos mais antigos, segundo as especificações atuais da Compact Flash Association, ou seja, por enquanto teoricamente, todo e qualquer Compact Flash que você adquirir, deverá funcionar em sua interface IDE.
Segue a lista de dispositivos Compact Flash que utilizei e testei com minha interface ATA IDE Tecnobytes:
Transcend 4Gb UDMA;
Dane-Elec 8Gb;
Dane-Elec 2Gb;
Memory Technology Company 256Mb;
.
De todos, o melhor que achei foi o Transcend 4Gb UDMA, pois me pareceu mais veloz do que os demais. Não fiz nenhum benchmark entre os Compact Flash, tarefa que deixarei para a segunda parte desse review, então a “medida” foi apenas baseada na percepção “visual“.
O Dane-Elec de 8Gb é o que está rodando oficialmente em meu micro, devido a seu tamanho de 8Gb.
Passeando pela Santa Efigênia em São Paulo, encontrei um SanDisk de 32Gb UDMA que deve ser uma obra prima, pois são os inventores do Compact Flash. Devo admitir que “formigou” a mão para comprar….
Segue abaixo outros dispositivos de Compact Flash que obtive feedback por parte de usuários de IDE (Tecnobytes, ACVS, Sunrise) de MSX e que me reportaram funcionar bem.
SanDisk Exteme III 2Gb;
Kingston 4Gb;
Kingston 1Gb;
.
Para mim essa questão da compatibilidade está desmistificada e acredito que todas as marcas atuais funcionem bem com a Interface ATA IDE da Tecnobytes e talvez com as demais baseadas em Sunrise, porém fique atento ao adaptador de Compact Flash.
A maioria dos adaptadores de Compact Flash atuais tem suporte a DMA, que a grosso modo é a presença de alguns pinos que interligam a IDE e o PCMCIA do Compact Flash possibilitando a transferência de dados via DMA, que é bem mais rápida em hosts que suportam DMA.
Infelizmente suporte a DMA não é a realidade para interfaces conectadas aos slots de expansão no MSX, entretanto percebi que todos os adaptadores de Compact Flash que tem suporte a DMA tem uma qualidade melhor e funcionam 100% com a interface ATA IDE Tecnobytes, quando se está utilizando dispositivos Compact Flash com suporte a UDMA, como o Transcend 4Gb UDMA.
Outros adaptadores CF->IDE sem suporte a DMA, causaram instabilidade no I/O, truncando os arquivos, quando utilizados com Compact Flash UDMA (Transcend 4Gb UDMA).
TIP
A ausência do suporte a DMA no adaptador não influencia em nada o uso de dispositivos Compact Flash não UDMA no MSX, porém ao utilizar um Compact FlashUDMA com adaptadores sem suporte a DMA, percebi que foi o diferencial para o inicio de falhas nas operações de I/O.
Acredito estar relacionado apenas a qualidade superior dos adaptadores com suporte a DMA frente aos que não tem suporte a DMA.
Lembrando que, caso você queira utilizar um Compact FlashUDMA em hosts que suportam UDMA (PC, etc ….), o primeiro requisito do adaptador é que tenha suporte a DMA e o segundo é que seja compatível com dispositivos UDMA. Logo a minha sugestão é a seguinte, compre adaptadores que tem a inscrição DMA em uma, ou nas duas, de suas faces, pois é mais seguro que funcione estável em dispositivos Compact Flash com ou sem suporte a UDMA. Caso tenha a especificação do produto em mãos, verifique também se o adaptador tem suporte a UDMA.
Notícias do Front:
Boas notícias quanto ao desenvolvimento de produtos baseados em tecnologia IDE pela Tecnobytes, pois o próprio autor já informou em um anúncio na lista MSXBR-L, que está desenvolvendo uma nova BIOS (2.50 beta) e que a mesma possibilitará suporte a FAT16 nativo, ou seja, em breve não necessitaremos da FAT12 para dar o boot na IDE, para mim esse é um primeiro passo para a FAT32.
Outra excelente notícia é que juntamente com a nova BIOS, teremos uma Memory Mapper, de fabricação da Tecnobytes, que é imprescindível para o uso da IDE devido ao MSXDOS2 necessitar da mesma, o que dá aos possuidores de MSX2 e MSX2+, sem Memory Mapper, a possibilidade de ampliação do potêncial dessas máquinas.
Como senão fosse suficiente todas essas boas notícias, essa nova Mapper também funcionará em MSX1. Isso mesmo, Memory Mapper no MSX1 sem a necessidade de alterações no hardware ou atualização da BIOS do MSX…….sim, aqueles HotBit’s e Expert’s que temos guardados e quase esquecidos em nossos armários, poderão ter um dispositivo IDE e mais memória do que os eternos 64Kb.
Só nos resta aguardar mais um pouco.
Sugestões ao autor do produto:
A minha sugestão é única e simples. Os conectores IDE nos hosts geralmente vem com um pino a menos, no centro do conector, sendo que os cabos IDE, incluindo todos UDMA (80 vias), também vem com esse pino coberto no conector do cabo, o que muitos constumam chamar de mata-burro.
Pois bem, a IDE da Tecnobytes, não vem com esse pino faltando em seu conector, como na maioria dos hosts (PC’s, etc, …), o que termina obrigando a quem vai trabalhar com dispositivos que utilizam cabo IDE (CDROM, HD, …) a furar esse pino, no cabo IDE, uma vez que o mesmo está coberto, evitando assim qualquer dano à interface IDE quando se está utilizando um cabo desse tipo, ou seja, todos UDMA de 80 vias.
Finalizando….
…deixo aqui meus agradecimentos aos seguintes amigos da lista MSXBR-L que ajudaram compartilhando informações sobre seus Compact Flash e Adaptadores.
Antonio Sanches Parra – Pelo report, com imagens, relatando que seu Compact Flash Kingston 1Gb funcionou de maneira instável com os 2 adaptadores sem suporte a DMA, causando truncamento dos arquivos gravados no Compact Flash, sendo que o mesmo Compact Flash funcionou perfeitamente em outro adaptador com suporte a DMA.
Daniel Campos – Pelo report relatando a instabilidade no funcionamento de seu conversor SD->CF, tendo os mesmos problemas de truncamento de arquivos, relatados pelo Antonio Sanches Parra e também pelo report em que relatou que seu adaptador SD SDHC MMC para IDE 3.5″ funcionou corretamente na interface Tecnobytes.
Silvio Borges – Pelo HotFix feito na IDE da Tecnobytes e por ter disponibilizado a informação ao fabricante, que repassou a todos os usuários.
.
Bom, por enquanto fico por aqui, sendo que reservei para a segunda parte dessa análise, um teste comparativo de performance dos diversos meios que podemos utilizar na IDE Tecnobytes ou qualquer outra interface IDE Sunrise-Like.
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:
MML Parser;
MML Compiler;
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.
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.
Associação dos canais físicos da máquina (FM, PSG e SCC) com os lógicos (conteúdo MML);
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. ;
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:
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.
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.
