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

Print Friendly, PDF & Email

Featured project – Aleste Gaiden – Part II (Box)

Já é de conhecimento de grande parte da comunidade MSX nacional e internacional, que recentemente foi desenvolvido no Brasil um port para cartucho do jogo Aleste Gaiden, feito pela comunidade brasileira através da MSX Brasil Oficial no FaceBook, jogo esse originalmente apenas disponível em disquete.

Eu já havia descrito aqui mesmo no blog através desse outro artigo aqui, os detalhes de como o projeto fora desenvolvido e as dificuldades enfrentadas no decorrer de seu desenvolvimento, entretanto antes da finalização da confecção dos cartuchos os participantes iniciaram uma conversação paralela visando a confecção de uma caixa personalizada para os cartuchos, deixando assim o projeto ainda mais “glamouroso”.

Ao contrário de 30 anos atrás, quando eramos apenas a geração de adolescentes que iria mandar no mundo, hoje somos programadores, artistas, empresários, designers, diagramadores, professores, já experientes que formam essa comunidade heterogênea que realmente faz a diferença.

Propaganda da Gradiente (1985) – A geração que vai mandar

Um dos caras que está mandando e está mandando muito bem 🙂 é o Ricardo Wilmers da RWS Print Solutions, também um dos membros bem atuantes da comunidade MSX, Apple II e de retrocomputação em geral.

Ele foi o responsável pela criação das caixas do cartucho Aleste Gaiden, cujo resultado ficou excelente, conforme pode ser visto nas imagens abaixo:

Como todos sabemos, a comunidade tem trabalhado para disponibilizar novos lançamentos, adaptações e relançamentos de software e hardware da forma mais barata e acessível a todos da comunidade, então a maioria desses trabalhos são feitos pelo prazer em sua grande maioria.

Entretanto de alguma forma esses trabalhos dão um retorno imediato ou até mesmo futuro seja por um trabalho contratado por algum membro da própria comunidade, para um outro fim profissional ou até mesmo pessoal, então deixo aqui os dados profissionais do Ricardo Wilmers, que recebi com o box e o cartão de sua empresa, a RWS Print Solutions, que conforme descrito no em seu cartão é especializada em Impressão Off-Set, Impressão Digital, Editoração Eletrônica, cópias preto e branco e coloridas, encadernações e tudo mais relacionado a essa área de impressão.

RWS Print Solutions
Rua Catolândia, 143 – 02839-000 – Freguesia do Ó – SP – Tel (11) 98182-4614
rwsgraph@gmail.com
Ricardo Wilmers Siqueira

Para finalizar deixo registrado aqui que, assim como feito anteriormente, o Marcelo Zoffy e o Júlio Lemos que foram imprescindíveis para a conclusão desse projeto e que já haviam sido presenteados com 1 cartucho cada um, também receberam esse Box feito pela RWS print solutions.

Que venham outros projetos.

[]’s
PopolonY2k

Print Friendly, PDF & Email

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

Print Friendly, PDF & Email

COVOX Speech Thing

Apesar do blog estar silencioso nos últimos meses, isso não é sinal de que não estou trabalhando em algo novo. Na verdade tenho trabalhado nos últimos 2 meses em diversos projetos paralelos, sendo alguns relacionados ao MSX e outros nem tanto.

É de conhecimento de grande parte da comunidade MSXzeira que estou desenvolvendo um Player de música, chamado Pop!Art e que no atual estágio de desenvolvimento o mesmo já é compatível com todos, ou a maioria, dos chips existentes para a plataforma MSX, conforme noticiado aqui no blog do Retrocomputaria.

Pois bem, após diversos feedbacks da comunidade brasileira, um comentário em especial do meu amigo Eliazer Kosciuk me fez iniciar um outro projeto paralelo cujo o resultado final certamente será adicionado ao desenvolvimento do Pop!Art.

Estou me referindo ao suporte a COVOX Speech Thing, que é um dispositivo muito antigo e que fez algum sucesso nos EUA, na década de 80 até o inicio dos anos 90, mas que eu realmente não conhecia até então.

De fato o COVOX é um DAC de 8Bits bem primitivo mas capaz de mostrar excelentes resultados, tornando-o bem atrativo na época, considerando custo/benefício, uma vez que as placas de som eram itens estupidamente caros.

Pois bem, seguindo o tutorial do projeto GR8Bit para a construção de um COVOX, decidi construir esse dispositivo que é bem simples e fácil de ser construído, bastando ter alguma destreza com ferro de solda apenas. Abaixo segue as fotos da construção do COVOX, que no final de tudo coube no próprio invólucro do plugue DB25 da impressora.

My COVOX device (based on GR8Bit project's page)
My COVOX device (based on GR8Bit project’s page)

COVOX Speech Thing
COVOX Speech Thing

COVOX device finished.
COVOX device finished.

Female plug in the back of COVOX device.
Female plug in the back of COVOX device.

FastTracker 2.9

Infelizmente não houve tempo para concluir todas as fases de construção do projeto, que é o meu objetivo. E sobre projeto inteiro, quero dizer construir o dispositivo COVOX e também o software que a utiliza. A parte do hardware posso dizer que está 100% pronto mas o software sequer consegui desenvolver uma linha de código. Entretanto eu procurei na internet e descobri um software que é nada mais nada menos do que um dos music trackers mais famosos, senão for o mais famoso, uma vez que influenciou diversos outros que vieram depois.

Estou me referindo ao FastTracker 2 MOD player, que de fato é um MOD player compatível com as principais placas de som da época e também com dispositivos COVOX.

O FastTracker 2 e os dispositivos COVOX são tão conceituados, que ainda hoje são amplamente utilizados pelo movimento demoscene.


FastTracker 2 playing XENON2 (Bomb the Bass)

FastTracker 2 using my homemade COVOX device (Playing Turrican 2)

Nada mau para um software feito em Turbo Pascal 7 de meados da década de 90. 🙂

[]’s
PopolonY2k

Referências

Pop!Art no Retrocomputaria Plus
http://www.retrocomputaria.com.br/plus/?p=8015

COVOX Speech Thing (Wikipedia)
http://en.wikipedia.org/wiki/Covox_Speech_Thing

DAC (Wikipedia)
http://en.wikipedia.org/wiki/Digital-to-analog_converter

COVOX device by GR8Bit
http://kb.gr8bit.ru/KB0010/GR8BIT-KB0010-Adding-multimedia-capability-covox-device.html

Conectores DB (Wikipedia)
http://pt.wikipedia.org/wiki/Conector_DB

Music Tracker (Wikipedia)
http://en.wikipedia.org/wiki/Music_tracker

MOD Music File (Wikipedia)
http://en.wikipedia.org/wiki/Module_file

DemoScene (Wikipedia)
http://en.wikipedia.org/wiki/Demoscene

Turbo Pascal (Wikipedia)
http://en.wikipedia.org/wiki/Turbo_Pascal

Print Friendly, PDF & Email

MSXDUMP v0.2 (final) liberado no SourceForge.net

Finalmente após as previsões extremamente otimistas feitas no final do ano passado quando lancei a primeira versão do primeiro utilitário da suite MSX Disk Doctor (MSXDD), denominado MSXDUMP e que finalizaria o mesmo em dezembro de 2012, posso dizer que esse software está completamente pronto e funcional, incluindo o suporte a dispositivos de armazenamento em massa de grande capacidade (IDE) que eu havia prometido.

MSXDUMP 0.0 Main screen
MSXDUMP 0.2 Main screen

Com isso, o MSXDUMP v0.2 pode editar setores em dispositivos conectados à interfaces IDE Sunrise-like, de fabricantes como ACVS, Tecnobytes e lógicamente Sunrise.

Abaixo vou fazer uma compilação de algumas informações que já foram descritas nos posts anteriores sobre o MSXDUMP e que fazem mais sentido que estejam centralizadas nesse post final, uma vez que se trata da versão final estável do software e também porque existem modificações no comportamento de alguns parâmetros que foram redefinidos e não serão mais modificados a partir dessa versão.

Operação através do teclado

Com uma interface tradicional característica da maioria dos editores de setores, o MSXDUMP tem alguns poucos shortcuts que permitem ao usuário um completo controle sobre a edição de arquivos e setores.

Os shortcuts estão descritos logo abaixo:

  • SELECT – Alterna o modo de operação das setas direcionais. Quando em modo DISK, as setas direcionais podem avançar ou retroceder o ponteiro de setor/arquivo que está sendo editado. No modoEDIT, as setas direcionais podem se movimentar pelos dados exibidos na tela, permitindo assim a edição do buffer de memória que está sendo visualizado;
  • CTRL+S – Quando em modo DISK, essa combinação de teclas salva o conteúdo do buffer carregado;
  • CTRL+A – Quando em modo DISK, avança o ponteiro de setor/arquivo, carregando e exibindo os dados do setor lido. As direcionais UP e RIGHT, quando em modo DISK, tem a mesma função de CTRL+A;
  • CTRL+R – Quando em modo DISK, retrocede o ponteiro de setor/arquivo, carregando e exibindo os dados do setor lido. As direcionais DOWN e LEFT, quando em modo DISK, tem a mesma função de CTRL+R;
  • Direcionais UP, DOWN, LEFT, RIGHT – Quando em modo EDIT, podem ser utilizadas livremente para posicionar o cursor no dado a ser modificado;

ATENÇÃO:
O MSXDUMP não salva o conteúdo editado pelo usuário “automagicamente“, por isso, sempre que se editar dado, deve-se sair do modo de edição (através de SELECT) e salvar o buffer atual, antes de navegar para o próximo setor, senão a alteração será perdida ao se mudar de setor.

Parâmetros de startup por linha de comando.

O MSXDUMP pode ser iniciado com as seguintes opções de linha de comando.

-h Mostra a tela de help do MSXDUMP. Chamar o software com uma opção inválida ou sem parâmetros, também ativa a tela de help;

-f <filename> Essa opção especifica o nome do arquivo que se deseja editar, onde <filename> pode conter uma especificação completa da origem do arquivo, no formato drive:\path\filename, aceito pelo MSXDOS 2;

Ex (MSXDOS2): msxdump -f a:\MSXDD\MSXDUMP.PAS
Ex (MSXDOS): msxdump -f MSXDUMP.PAS

-d <drive> Essa opção especifica a unidade de disco dos setores a serem editados. Pode ser qualquer unidade de disco (A:, B:, C:, …., H:) aceita pelo MSX, incluindo dispositivos FLOPPY, IDE e RAMDISK;

Ex: msxdump -d a:

-s <sector_number> Essa opção especifica onde o ponteiro de setores será posicionado inicialmente para edição através do MSXDUMP. Um detalhe importante para o parâmetro -s <sector_number>, a partir dessa versão, é que número do setor especificado no parâmetro pode ser qualquer valor de zero até o limte máximo de um inteiro sem sinal (unsigned) de 24bits, nesse caso, 16777215.
Outro detalhe importante sobre o valor de <sector_number> é que o mesmo descreve o numero do setor de maneira relativa à partição apontada pela unidade especificada no parâmetro -d <drive>. Para discos conectados a uma IDE, onde geralmente existe mais de uma unidade mapeada a um unico dispositivo IDE, cada unidade inicia em um setor físico diferente de 1.

Considere um disco IDE com duas partições FAT12. A primeira partição (drive A:) inicia em 1 e a segunda partição (drive B:), digamos que por exemplo inicie em 65000.

Com base nesse cenário, caso o MSXDUMP seja chamado conforme exemplo abaixo:

Ex: msxdump -d b: -s 1

MSXDUMP irá posicionar o ponteiro do disco no setor físico relativo à posição inicial da unidade B:, ou seja, 65001.

-a Essa opção especifica que o valor apontado por <sector_number> será sempre absoluto, ou seja, se o parâmetro -a for chamado no startup, o valor de <sector_number> será interpretado como a posição absoluta no disco, independente da posição física do primeiro setor da unidade de disco especificada em -d <drive>;

Considerando o mesmo exemplo anterior, onde temos um disco IDE com duas partições FAT12. A primeira partição (drive A:) inicia em 1 e a segunda partição (drive B:), digamos que, por exemplo, inicie em 65000.

 Com base nesse cenário, caso o MSXDUMP seja chamado conforme descrito abaixo:

Ex: msxdump -d B: -s 1 -a

Na verdade o setor físico do disco será posicionado no primeiro setor do dispositivo IDE, ou seja, no setor 1 do drive A:, uma vez que estamos trabalhando no modo de apontamento absoluto.

OBS: O modo padrão de apontamento de setores do MSXDUMP é sempre relativo à posição fisica inicial do setor da unidade de disco selecionada, caso queira mudar para o modo absoluto, especificar a opção -a no startup da aplicação.

Código fonte

Juntamente com o MSXDUMP foi desenvolvido um Framework com funções que possibilitam acesso em alto nível a funcionalidades internas do MSX, como chamadas a funções da BIOS, funções do sistema operacional MSXDOS, MSXDOS2, chamadas à funções de baixo nível da IDE Sunrise-like, funções de matemáticas para manipulação de BigInt, o que possibilitou a manipulação de setores em 24Bits presente nas IDE Sunrise-like, dentre outras possibilidades que já estão disponíveis e outras que estão planejadas para futuros desenvolvimentos.

Os fontes foram desenvolvidos em Turbo Pascal 3 e Assembly Z80, estão completamente comentados e disponíveis no repositorio do projeto, o Old Skool Tech, sob licença GPLv3.

Apesar de ter otimizado o código visando um melhor aproveitamento de memória e velocidade, infelizmente não foi possível gerar um binário único, uma vez que o software foi pensado para funcionar em qualquer MSX com no mínimo 64Kb e MSXDOS.

No futuro pretendo otimizar mais o Framework e adicionar a possibilidade de trabalhar com módulos carregáveis, como nos sistemas operacionais modernos como Windows (.DLL) e Linux (.SO) e também adicionar suporte a detecção e uso de todas as memórias existentes no MSX, como Memory Mapper e Megaram.

Mas enquanto isso não acontece, precisei deixar o MSXDUMP em 3 binários separados, conforme descrevo abaixo:

MSXDUMP – Módulo base para edição de arquivos (MSXDOS e MSXDOS2);

MSXDUMPD – Módulo base para edição de setores (FLOPPY, IDE, …);

MSXDUMPHHelp do sistema;

Todos os módulos binários estão interconectados, ou seja, se por exemplo o módulo MSXDUMP for chamado com opções suportadas apenas pelo  MSXDUMPD, o primeiro chama o segundo repassando para esse o controle da operação.

Instalação

A instalação do MSXDUMP é simples, basta copiar todos os binários para uma pasta (no caso do MSXDOS2) e adicionar essa caminho na variável de ambiente PATH do MSXDOS2, conforme exemplo abaixo:

SET PATH=<suas definições de PATH aqui> B:\MSXDD 

Outro detalhe muito importante é definir uma variável de ambiente no AUTOEXEC.BAT do MSXDOS2, chamada MSXDD e setar essa variável com o caminho de onde está instalado o MSXDUMP e também onde estarão os futuros utilitários do MSX Disk doctor, conforme exemplo abaixo:

SET MSXDD=B:\MSXDD

Com isso os binários estarão interconectados e um poderá chamar o outro, conforme expliquei anteriormente.

Considerações finais e download.

Bom, realmente no ano passado e inicio desse ano dediquei bastante tempo nesse software e toda a base do Framework desenvolvido, entretanto agora é hora de colher os frutos desse trabalho pois daqui para frente os novos projetos serão cada vez mais fáceis de desenvolver, uma vez que a base já está criada e estará com novas features a cada novo lançamento.

Se tudo der certo, em breve teremos um dd, ScanDisk e um Defrag, para compor e ampliar a suite MSX Disk Doctor.

Segue abaixo os links para download do código fonte e binários do MSXDUMP v0.2.

MSXDUMP v0.2 – Código Fonte (Old Skool Tech – SourceForge.net)

http://sourceforge.net/projects/oldskooltech/files/MSX/MSXDD/v0.2/msxdd-src.zip/download  (Zip)
http://sourceforge.net/projects/oldskooltech/files/MSX/MSXDD/v0.2/msxdd-src.lzh/download  (Lzh)

MSXDUMP v0.2 – Binários (Old Skool Tech – SourceForge.net)

http://sourceforge.net/projects/oldskooltech/files/MSX/MSXDD/v0.2/msxdd-bin.zip/download  (Zip)
http://sourceforge.net/projects/oldskooltech/files/MSX/MSXDD/v0.2/msxdd-bin.lzh/download  (Lzh)

[]’s
PopolonY2k

Print Friendly, PDF & Email