Chronicle Queue – A microsecond messaging framework

É chover no molhado citar que o mundo da computação se reinventa, avança e expande para novos modelos e tecnologias a cada ano, entretanto, para aqueles um pouco mais “experientes” na área de TI, é perceptível que nos últimos 10 anos um mercado, antes adormecido, tem ressurgido de uma forma que talvez se assemelhe ao boom causado com o surgimento da microinformática em meados dos anos 70.

Estou me referindo a computação de alta performance, onde tudo era desenvolvido de tal forma a se extrair a capacidade máxima das tecnologias existentes da época, uma vez que a própria tecnologia avançava de maneira mais lenta devido às limitações da própria época, obrigando os programadores a pensar em como economizar ciclos e estados de máquina.

A grande limitação, naqueles dias, estava relacionada à memórias de maneira geral, sejam voláteis (RAM) ou não voláteis (ROM, hard disks, Flash memories), sendo esses dispositivos caríssimos, até pouco tempo. Só para se ter uma ideia, em 1980 nos EUA, um hard disk de 26MB custava em média U$5.000 e 64KB de memória RAM custava em média U$405,00.

Memória RAM versus Hard disks

Historicamente as memórias RAM sempre estiveram muito a frente dos hard disks na questão de velocidade de E/S, mas por outro lado o custo por megabyte dos hard disks e a grande capacidade desses dispositivos sempre o colocaram à frente das memórias RAM no quesito capacidade de armazenamento.

Com o avanço e barateamento das tecnologias de armazenamento voláteis e não voláteis, aliado ao aumento gradativo do poder dos processadores, esse cenário mudou fazendo com que novas indústrias de tecnologia surgissem e despontassem para o mundo em pouquíssimo tempo.

Algumas delas tem seu “negócio” fortemente embasado no processamento em memória RAM, como é o caso de empresas desenvolvedoras de engines para jogos, já outras nem precisam de performance extrema sendo seu foco mesmo a venda de sua capacidade de armazenamento não volátil, como o DropBox por exemplo.

Entretanto existem aquelas empresas que necessitam de capacidade e performance extremas nos dispositivos voláteis (RAM) e nos não voláteis (hard disks), como por exemplo redes sociais, sites de busca, sites de comparação de preços, dentre outras que trabalham com informações dinâmicas e em grande quantidade.

Nesse cenário de alta capacidade de armazenamento e performance, aliado ao uso de tecnologias disponíveis nos diversos sistemas operacionais modernos, surgem tecnologias que utilizam as mais variadas técnicas computacionais já conhecidas dos pioneiros da alta performance de décadas passadas.

Chronicle Queue

Chronicle Queue é um componente de IPC (inter-process communication), open source, escrito em Java, que possibilita a transferência de grandes quantidades de dados em alta performance, entre threads, processos e máquinas, com persistência de dados em disco. Segundo a página do projeto no GitHub o Chronicle Queue é definido como “Micro second messaging that stores everything to disk“.

O grande segredo da performance do Chronicle Queue é que ele trabalha justamente utilizando estruturas simples porém rápidas tal qual as utilizadas por diversas aplicações nos primórdios da computação, que necessitavam armazenar e recuperar dados com uma performance aceitável e o faziam utilizando índices otimizados que apontam direto para o dado real no arquivo de dados em disco, entretanto ao contrário das antigas tecnologias, agora os arquivos de dados podem ser manipulados utilizando mecanismos de memory-mapping existente nos sistemas operacionais modernos, otimizando assim a performance das operações de E/S em disco.

Arquitetura e modos de operação

A interface básica de funcionamento da arquitetura do Chronicle Queue é bem simplista, com algumas poucas variações do modo de funcionamento, sendo restrito a um componente de escrita na fila, denominado Appender (producer) e um outro de leitura, denominado Tailer (consumer).

Dentro desse modelo, que é basicamente o tradicional pattern producer-consumer, o Chronicle Queue pode operar em modo sequencial (FIFO) ou aleatório, quando operando como Tailer e apenas em modo sequencial quando em modo Appender.

Modelo tradicional do Chronicle Queue (producer-consumer)

O Chronicle Queue, além do suporte à filas diretamente acessadas via os arquivos físicos da mesma, também possui outros modos de operação interessantes, dentre eles um modo de fila acessado via TCP/IP, ou seja, diversos Tailers conectados a uma fila via um Appender TCP, o que de fato diminui a performance de processamento das filas mas que por outro lado permite toda a facilidade de inter-process communication do Chronicle Queue, expandindo-a, uma vez que abre possibilidade de comunicação entre máquinas diferentes.

Outra característica do Chronicle Queue é que, diferente das estruturas IPC presentes nos sistemas operacionais modernos, todos os dados trafegados pela fila são persistidos em disco e com isso é possível utilizar a própria fila Chronicle como um sistema de journaling, podendo ser usado para recuperação do sistema em caso de uma eventual queda (crash).

Source Code

A simplicidade de uso e operação do Chronicle, por parte do programador é uma de suas principais características, conforme verificado no exemplo abaixo:

try (ChronicleQueue queue = ChronicleQueueBuilder.single("queue-dir").build()) {
    // Obtain an ExcerptAppender
    ExcerptAppender appender = queue.acquireAppender();

    // write - {msg: TestMessage}
    appender.writeDocument(w -> w.write(() -> "msg").text("TestMessage"));

    // write - TestMessage
    appender.writeText("TestMessage");

    ExcerptTailer tailer = queue.createTailer();

    tailer.readDocument(w -> System.out.println("msg: " + w.read(()->"msg").text()));

    assertEquals("TestMessage", tailer.readText());
}

O código acima demonstra 1 Appender escrevendo e 1 Tailer consumindo na mesma Thread, para fins de demonstração, entretanto a disposição desses producers-consumers pode estar da forma como melhor se adequar ao modelo da aplicação que está sendo desenvolvida, podendo o producer estar em um processo e o consumer em outro, em Threads separadas ou até em máquinas separadas.

Por ser um projeto enxuto, bem estruturado e que utiliza muito bem os recursos computacionais sejam do sistema operacional ou de estruturas de dados internas do projeto, o Chronicle Queue garante uma boa performance e confiabilidade, além de uma vasta comunidade trabalhando em atualizações e melhorias do projeto.

Ainda assim, é possível ter um suporte “enterprise” por parte do grupo que o desenvolve, o que o torna um projeto de vida longa no mercado e comunidade, além da segurança de continuidade e suporte necessário ao ambiente corporativo.

Conclusão

Apesar de bastante resumido, esse artigo visa demonstrar a importância desse retorno às origens da computação, principalmente considerando o atual momento onde vivemos a febre de computação distribuída, vide BlockChain e da necessidade de processamento de dados em grande escala, vide BigData.

Entretanto, para que esses conceitos se tornem realidade, muitas tecnologias de base e que muitas vezes sequer aparecem no desenvolvimento desses conceitos, precisam ser muito bem desenvolvidas, otimizadas e principalmente que sejam confiáveis, portanto vale a pena investir um tempo utilizando tecnologias abertas como o Chronicle Queue.

[]’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

GDMSX no Telegram

A última semana aqui no Brasil foi bastante movimentada nas diversas redes sociais, por conta do bloqueio do aplicativo WhatsApp por um juiz de São Bernardo do Campo.

Entretanto há algum tempo já existe uma alternativa, extremamente superior, com interface muito mais bonita e mais fácil de usar, com protocolo e API abertos sendo altamente integrável com qualquer coisa que você possa e venha imaginar, dependendo apenas da sua criatividade, além de ser Open Source.

Estou falando do Telegram, que é o mais forte concorrente do WhatsApp e pelo simples fato de ser desenvolvedor de tecnologias de mensagens instantâneas, estou utilizando-o há algum tempo afim de conhecer alternativas abertas, concorrentes ao WhatsApp.

Telegram logo

Telegram Logo

Realmente é um excelente software, muito completo e com versões para Windows, MacOSX e Linux, além das versões mobile disponíveis para Android, iPhone e Windows Phone. Com tudo isso, além dos grupos que também existem no WhatsApp, o Telegram tem uma feature extra imbatível que são os canais.

Aproveitando a onda Telegram que assolou o Brasil, após a queda do WhatsApp, aproveitei para criar mais um branch do GDMSX, no formato canal do Telegram, podendo ser acessado nesse link, ou buscando por gdmsx na lista de canais do Telegram.

Posso dizer que há tempos eu não ficava tão empolgado com um software de mensagens instantâneas como estou com o Telegram.

Long live to Telegram. 🙂

[]’s
PopolonY2k

Print Friendly, PDF & Email

Desenvolvendo com OpenMSX

Acredito que toda, ou grande parte da comunidade MSX conheça o excelente emulador OpenMSX, principalmente os usuários de Linux e MacOSX.

Bom, confesso que depois de voltar a ativa no mundo MSX, eu utilizo uma máquina real em 100% do meu tempo desenvolvendo coisas, até porque não jogo no MSX há anos. Entretanto desde o último ano, não tenho conseguido tempo para estar à frente da minha máquina de desenvolvimento preferida, que é o meu MSX TurboR A1ST com 1MB de RAM, IDE Tecnobytes com 8GB de Compact Flash, Expansor de slots ACVS, placa de rede Obsonet Tecnobytes, dentre outras coisas que estão conectadas nessa máquina.

Desde o início dos anos 2000, senão me engano lá por 2002 ou 2003, quando a “batalha de emuladores” era mais intensa entre os RuMSX, ParaMSX, fMSX e seus mais diversos sabores, duas opções “definitivas” começaram a se fundamentar no meio da comunidade MSX mundial e hoje reinam absolutas em sua preferência.

Estou falando do BlueMSX e do OpenMSX.

BlueMSX LogoBlueMSX logo

Usei muito o BlueMSX, principalmente quando jogava no emulador, mas como desenvolvedor, percebi desde cedo que o OpenMSX se tratava de um projeto mais aberto e poderoso no que diz respeito a sua utilização no desenvolvimento de novos projetos, sejam de hardware ou de software, além do fato de seu projeto ser extremamente bem feito, com um código muito bem escrito e documentado, além de ser multiplataforma.

openmsxOpenMSX logo

OpenMSX como plataforma de desenvolvimento.

Além de já ter sido vastamente utilizado como plataforma para desenvolvimento de hardware, em projetos como o MSXARM, o OpenMSX é uma excelente plataforma de desenvolvimento de software, principalmente pelo fato do mesmo emular quase todos (ou todos) os dispositivos que podem ser conectados a um MSX real, como os famosos LaserDiscs, por exemplo.

Por esse motivo e também incentivado pela série que vem sendo escrita no site de Javier Lavanderia, sobre programação para MSX utilizando MSX C, eu decidi que era hora de testar o nível de compatibilidade do OpenMSX, bem como todas as capacidades desse emulador, no desenvolvimento de novos projetos para MSX.

OpenMSX console

O OpenMSX possui um console embutido, que você ativa toda vez que pressiona F10 e a partir daí, em paralelo com a emulação, é possível interagir com a máquina utilizando um conjunto extenso de comandos disponíveis no emulador, conforme pode ser visto nesse link aqui.

Inclusive, via comandos Tcl, você pode controlar o emulador utilizando uma interface através de alguns meios de comunicação disponíveis no emulador, como pipes, named pipes, a saída padrão (stdio), TCP Sockets e UNIX domain sockets, ou seja, é um emulador modular ao extremo, permitindo até que você escreva seu próprio launcher, caso não esteja satisfeito com o OpenMSX Catapult, que para mim poderia ter sua interface tão poderosa e até mais do que a do emulador BlueMSX por exemplo.

Abaixo segue um excelente vídeo demonstrando essa integração do OpenMSX com Tcl/Tk, através do console de Tcl embutido nesse emulador.

Integrando OpenMSX com Tcl

Preparando seu disco.

Apresentado o console do OpenMSX, agora vale a pena citar um comando muito especial e poderoso, o diskmanipulator.

Resumidamente, o diskmanipulator é capaz de criar imagens de disco bem como gerenciar seu conteúdo. As imagens criadas são compatíveis com FAT12 e FAT16 e poderão ser utilizadas no OpenMSX como floppy disks comuns e também como hard disks  IDE.

OpenMSXOpenMSX console

A página de instruções do diskmanipulator contém diversas explicações de como criar imagens para discos flexíveis de 720Kb, discos rígidos com partições de FAT12 e FAT16, bem como instruções de como importar dados para esses discos a partir do disco local da máquina host em que o OpenMSX está sendo executado.

Como o objetivo desse post é justamente apresentar o OpenMSX como uma plataforma real para desenvolvimento de softwares para MSX, então preparei um disco com duas partições, sendo a primeira FAT12 e outra FAT16, com diversos softwares específicos para o desenvolvimento de software no MSX. Segue abaixo a lista do que atualmente está contido no disco criado e pronto para usar:

DRIVE A: (FAT12)

MSXDOS2 operating system compatible

[DEV]     (Editors, compilers, assemblers and general purpose development tools)
—|———[M80] (Microsoft/ASCII – Z80 Assembler)
—|———[DEVPAC80] (HiSoft Z80 Assembler)
—|———[TP33] (MSX Computer club Turbo Pascal 3.3 compiler)
—|———[TP3] (Borland Turbo Pascal 3.00A compiler)
—|———[TED] (MSX2.0 and higher Text Editor)
—|———[APED] (MSX2.0 and higher Text Editor)
—|———[TOR] (MSX1&2 text editor)

DRIVE B: (FAT16)

[PROJECTS]   (Projects source code)
——-|—-[PASCAL] (Turbo Pascal compatible source code)
——-|———|
——-|———|——[PCX]  (Source code for PCX file format handling)
——-|———|——[INLASS] (Turbo Pascal Inline assembler)
——-|———|——[MKINL] (Another Turbo Pascal Inline assembler)
——-|———|——[PMLINK] (Another Turbo Pascal Inline assembler)
——-|———|——[INLINE] (Another Turbo Pascal Inline assembler)
——-|———|——GRAPH.INC (Graphical library for MSX)
——-|———|——PARSE.INC (Command line parameter parser)

Lembrando que essa é apenas uma configuração de disco inicial em que ainda estou trabalhando, portanto no futuro certamente serão adicionados a esse hard disk, os pacotes do MSXC (1 e 2), HiSoftC, dentre outras excelentes ferramentas destinadas ao desenvolvimento de software para o MSX.

Baixando e usando o hard disk

O harddisk citado acima, pode ser encontrado nessa URL aqui, e de fato é um compartilhamento de minha pasta do DropBox que deixo disponível à comunidade. Os arquivos dessa URL serão atualizados com o tempo, visando a adição de novos compiladores e ferramentas de desenvolvimento para a plataforma MSX.

Nesse mesmo link você encontrará dois arquivos, os quais descrevo abaixo:

dev_hd.dsk -A imagem de 64MB com as duas partições (A: FAT12 e B: FAT16) pronta para uso no OpenMSX;
dev_hd.tcl  – Script Tcl utilizado para dar boot no OpenMSX, usando a imagem de disco acima;
Passos para utilização do disco no OpenMSX:
    1. Baixe esses dois arquivos em qualquer diretório de sua máquina. O único ponto de atenção a ser tomado é que esses dois arquivos devem estar no mesmo diretório pois o script TCL <dev_hd.tcl>, busca pela imagem do hard disk no mesmo diretório em que o script está sendo executado;
    1. Abra o OpenMSX utilizando a sua configuração de máquina preferida;
    1. Com o OpenMSX rodando, pressione a tecla F10, para invocar o console Tcl do OpenMSX;
    1. Já na tela do console, digite o comando abaixo:
      source <caminho_onde_você_baixou_a_imagem_de_disco_e_o_arquivo_tcl/dev_hd.tcl>
    1. Pressione <ENTER>
  1. Divirta-se 🙂

Pronto, o seu OpenMSX irá reiniciar já fazendo boot com a imagem de hard disk que você baixou no link acima.

Isso é apenas uma pequenina amostra do potencial desse que, para mim, é o melhor e mais completo emulador da plataforma MSX, na atualidade.

Fiquem antenados nos novos updates da imagem de disco, que disponibilizei no link do Dropbox.

[]’s
PopolonY2k

Referência na internet

OpenMSX home
http://openmsx.org/

Linux (Wikipedia)
https://en.wikipedia.org/wiki/Linux

MacOSX (Wikipedia)
https://en.wikipedia.org/wiki/OS_X

RuMSX home
http://www.lexlechz.at/en/software/RuMSX.html

ParaMSX (MSX.org)
http://www.msx.org/news/emulation/en/paramsx-048b

fMSX home
http://fms.komkon.org/fMSX/

BlueMSX home
http://www.bluemsx.com/

MSXARM primeiro teste de hardware (PopolonY2k Rulezz)
http://www.popolony2k.com.br/?p=2074

LaserDisc (Wikipedia)
https://en.wikipedia.org/wiki/LaserDisc

Relearning MSX (Lavanderia.net)
http://www.lavandeira.net/relearning-msx/

OpenMSX console commands.
http://openmsx.org/manual/commands.html

Tcl Tk home
https://www.tcl.tk/

Controlling OpenMSX
http://openmsx.org/manual/openmsx-control.html

Pipe communication
http://www2.cs.uregina.ca/~hamilton/courses/330/notes/unix/pipes/pipes.html

Named Pipes (Wikipedia)
https://en.wikipedia.org/wiki/Named_pipe

Network socket (Wikipedia)
https://en.wikipedia.org/wiki/Network_socket

UNIX domain sockets
https://en.wikipedia.org/wiki/Unix_domain_socket

DiskManipulator (OpenMSX)
http://openmsx.org/manual/diskmanipulator.html

PopolonY2k’s OpenMSX development hard disk (DropBox sharing)
https://www.dropbox.com/sh/smo2dz1kwl6wvfm/AAAYfFbZGjoksmoIRE4TlwPGa?dl=0

DropBox website
http://www.dropbox.com

Print Friendly, PDF & Email

Computer made music

Chiptune is a music category that has grown over the last few years and it is composed often by musicians, users and fans of old computers. This new music category is growing thanks to a generation whose childhood was affected in some way by computers.

Those who were born in the 70‘s and 80’s know exactly what about I’m writing, because in those days anyone who could get any kind of computer now was able to remember the magic behind it’s sounds and songs created for those machines.

If you lived those magic days, brands like Commodore, Apple, Texas, Philips are familiar to you and some systems and computers standards like C64, AppleII, Amiga, Spectrum, Amstrad CPC and MSX in some way have had some importance and maybe influenced you in your career or hobby.

Today several mainstream artists have been submitting their songs to be produced by producers that were influenced by C64 game made songs and by Amiga demosceners artists. The most famous example of this influence is a recent scandal involving the well known producer Timbaland that has been accused of plagiarism by Amiga computer fans, when he worked for Nelly Furtado’s album, Loose, released in 2006.

Comparing both songs

This is a well known story and in fact Timbaland revealed to have plagiarized some elements of several Amiga’s composers including the demoscener artist Janne Suni (a.k.a Tempest). One of the songs plagiarized by Timbaland was composed by Tempest for the Oldskool Music competition (Assembly 2000) which occurred in 2000 in Helsinki, Finland and reached the first place in the competition.

Nice try Timbaland 🙁
.

To be continued...

[]’s
PopolonY2k

Reference

ChipTune (Wikipedia)
http://en.wikipedia.org/wiki/Chiptune

Timbaland (Wikipedia)
http://en.wikipedia.org/wiki/Timbaland

Nelly Furtado (Wikipedia)
http://en.wikipedia.org/wiki/Nelly_Furtado

Timbaland Plagiarism controversy (Wikipedia)
http://en.wikipedia.org/wiki/Timbaland_plagiarism_controversy

Print Friendly, PDF & Email