Voltron assembles from five lions. The Valkyrie in Macross folds from a fighter jet into a battle-ready mecha. The Autobots have been telling us for forty years that there’s “more than meets the eye.” Transformation is one of gaming and animation’s oldest tricks — take something familiar, and reveal it was always capable of becoming something bigger.
That’s also, more or less, the plot of Caravellius.
The ship that started it all
Back in 2021, I set out to build a shoot-’em-up called Caravellius — the Caravela, an old-world sailing ship, transforms into a spaceship to defend Earth from a Venusian invasion. Here’s the first footage of it taking shape:
Caravellius — early build
I made one deliberate, slightly stubborn decision going in: I wasn’t going to reach for an existing engine. I wanted to actually understand how games get built — cameras, collision, sprites, tile maps, all of it — by writing the plumbing myself.
Two candidates stood out for the actual graphics primitives: raylib and SDL. Rather than pick one and hard-wire the whole game to it, I built a boundary between “my game logic” and “whatever draws the pixels” from day one. If I ever wanted to swap the backend later, I shouldn’t have to rewrite the game to do it.
That boundary is what eventually became sunlight.
The engine transforms
About three months in, sunlight had grown enough of its own identity — map rendering, collision, sprites, sound, a scripting layer — that it stopped feeling like “part of Caravellius” and started feeling like its own thing. So I split it out into its own repository.
That’s the Voltron moment, if you squint: the pieces that had been quietly doing their job inside Caravellius assembled into something that could stand on its own.
Here’s a later look at Caravellius, running on top of that separated engine, with updated art and music:
Caravellius — updated build
Since the split, sunlight has kept leveling up on its own track — a real CI pipeline building it on Linux, macOS, and Windows on every change; a proper unit test suite; five sample projects showing off map rendering, animated sprites, collision, gamepad input, and a scripted “stage intro” cutscene; generated API docs; and, as of this week, its first tagged release, v0.1.0 — with prebuilt packages for all three platforms attached automatically the moment the tag goes up.
The next form
Here’s where the transformation keeps going. sunlight isn’t just Caravellius’s engine anymore — it’s now the rendering backend for Scarab, a new game engine I’m building that adds Lua scripting on top. Where sunlight handles the “how do pixels get on screen and what happens when two things collide,” Scarab is meant to let game logic live in Lua instead of C++.
It’s the same shape as the Caravela becoming a spaceship: the thing underneath didn’t get thrown away when it transformed. It got carried forward into something that could do more.
sunlight is open source under the zlib license — the repo, docs, and the v0.1.0 release are all up on GitHub if you want to see how a ship-turned-spaceship’s engine turned out:
Finalmente após algum período longe do desenvolvimento de software para MSX, decidi voltar ao game unindo o útil mundo do IoT ao agradável universo de retrocomputing através do nosso querido e amado MSX.
Como se trata de um tema atual, rico de informações e possibilidades, decidi escrever dois artigos sendo esse aqui o primeiro que é mais introdutório e o segundo será mais prático, descrevendo o passo-a-passo de como usar toda a tecnologia envolvida nesse pequeno projeto.
Não é a primeira vez que me aventuro na área de comunicação no MSX, pois há 10 anos atrás (passou o tempo e nem percebi) escrevi sobre Networking no MSX através de 2 artigos intitulados MSX Networking e MSX Networking – Developers, developers, developers, developers, … respectivamente e que na época tiveram boa receptividade na comunidade MSX.
Nesses posts apresentei tecnologias como a interface de rede para MSX denominada ObsoNET e a interface que estava sendo desenvolvida na comunidade MSX na época e que não tinha nome e que eu intitulei como OptoNET e desde então é reconhecida como OptoNET, inclusive teve uma versão Wi-Fi da mesma e que usa ESP8266.
No ultimo artigo inclusive liberei a implementação de uma abstração de Network Socket para uso em aplicações escritas em Turbo Pascal 3 no MSX, bem como a implementação de um driver para OptoNET sendo assim possível a sua programação em Pascal usando essa abstração.
Nesse interim adquiri quase tudo o que pude referente a comunicação, desde as diversas placas de rede existentes para MSX como a excelente Gr8Net de Eugeny Brychkov (from Russia with love), DenYoNet da Sunrise, até interfaces RS-232 como a Fast Harukaze e a CT-80NET da Gradiente.
Comecei a desenvolver muita coisa para RS-232 utilizando a BIOS padronizada pelo consorcio MSX mas infelizmente paralisei seu desenvolvimento em um estágio bem avançado, o mesmo tendo acontecido com o desenvolvimento das rotinas para uso da ObsoNET que também está quase no mesmo estágio de conclusão das rotinas de RS-232 e que esse ano, ambas as implementações certamente serão concluídas e assim teremos mais uma importante feature na PopolonY2k Framework Library.
Pois bem, há quase 10 anos tenho essas duas interfaces RS-232, Fast Harukaze e a Gradiente CT-80NET e arrisco a dizer que a possibilidade de programar softwares de comunicação para MSX foi o que me fez a voltar a ser bastante atuante na comunidade (isso lá no início dos anos 2000) e que principalmente foi um tópico que me fez a querer ter um MSX real (agora também os sintetizados via FPGA) para colocar meus planos em prática.
RS-232 – O inicio de tudo
O RS-232, também conhecido como RS-232C, é um protocolo padrão de mercado criado no final dos anos 60, mais especificamente em 1969 e que teve seu uso amplamente difundido para o público técnico e de uso geral principalmente nos anos 80 com o advento da computação pessoal difundida pelos mais diversos PC`’s de 8, 16 e 32 Bits da época, atravessando o tempo e chegando aos dispositivos IoT dos dias atuais, como Arduino e Raspberry Pi.
LoRa – Um protocolo serial via wireless
A comunicação avançou muito nos últimos anos e com todo esse avanço tivemos diversas tecnologias criadas que vão desde comunicação via Ethernet cabeada, até WiFi, o que chamamos de comunicação Wireless ou sem fio.
Apesar do bom e velho RS-232C e suas variantes como a RS-485 terem sido desenvolvidos principalmente para operar utilizando cabos, não é recente a sua utilização via wireless através de dispositivos especialmente projetados para lidar com as caraterísticas especiais de uma comunicação sem fio.
Nesse universo e principalmente devido ao grande avanço das tecnologias de Internet Of Things (IoT), muita coisa nova tem sido desenvolvida, principalmente através da união de grandes players de tecnologia, que por sua vez tem ajudado a criar padrões para utilização no universo IoT.
É nesse cenário nasce a Lora Alliance, que é uma organização sem fins lucrativos responsável pela criação, especificação de tecnologias baseadas em LoRa.
Mas que raios é esse LoRa afinal ?
LoRa é um protocolo de comunicação via rádio que significa Long Range (Longo alcance), ou seja, é um protocolo para envio de informações a longas distâncias, onde se tem relatos de comunicação entre 2 pontos a uma distância de até 15Km.
É lógico que depende de vários fatores, como visada (Line of Sight) dentre outros que podem interferir no alcance, porém só o fato de existir essa possibilidade de comunicação a longas distâncias já torna LoRa muito interessante para uso em diversas aplicações como já vem sendo utilizado pelo agronegócio para monitoria de equipamentos em fazendas que na maioria dos casos é um ambiente propício para esse tipo de aplicação
Apesar da grande distância que um dispositivo LoRa pode proporcionar, nem tudo são flores sendo a principal desvantagem a baixa velocidade pois a comunicação entre dispositivos LoRa é extremamente lenta, impossibilitando o seu uso em transmissões com grande volume de dados como áudio e vídeo por exemplo.
Esse é um dos principais motivos pelos quais as informações trafegadas entre dispositivos LoRa, estar restrita a envio de dados de telemetria ou aplicações onde baixa latência não é o principal requisito.
LoRa possui duas topologias de operação, sendo elas Point-to-Point e Network, essa última de fato é uma espécie de Broadcasting, além de variantes como a LoRaWan capaz de colocar um dispositivo LoRa na internet, o que foge um pouco do escopo desse post portanto vamos explorá-la em um post futuro.
Dispositivos LoRa na prática
Na prática temos uma infinidade de dispositivos LoRa desenvolvidos por diversos fabricantes e embora exista uma certa padronização no nível de sinal, frequência de rádio e afins, não há uma padronização na interface de software com LoRa, com isso cada fabricante de dispositivos LoRa está criando sua própria abstração de comunicação com seus dispositivos.
A fabricante REYAX, é a que melhor se adaptou e está usando comandos AT, padrão da Hayes criado para comunicação via modem que se tornou padrão de facto sendo amplamente utilizado pela industria desde os anos 80 bem como pela própria REYAX em seu RYLR998, o que torna esse dispositivo um dos mais “padronizados” em nível de software no mercado.
Dentre os diversos fabricantes, um dos mais “famosos” é a chinesa EBYTE, que possui diversos modelos de módulos LoRa, todos bem parecidos visualmente e operacionalmente entre si, apenas mudando especificações técnicas talvez relacionadas a potência e consumo por exemplo. O módulo que utilizo nos experimentos com MSX e IoT é exatamente esse da imagem, o E220-900T22D.
Tanto o módulo LoRa da REYAX, quanto o da EBYTE, tem sua interface física de comunicação baseada em UARTTTL serial e no caso dos módulos da EBYTE eles tem um protocolo binário bem simples para setup do módulo LoRa e que está disponível quando o módulo está operando em modo de setup/configuração.
Infelizmente a documentação do módulo da EBYTE não é muito clara e gera algumas duvidas que nos induz a pensar que a documentação está errada ou o módulo não funciona, entretanto após pesquisar outros sites e vídeos sobre esses módulos da EBYTE percebi mesmo que essa documentação é só mau escrita mesmo e que o módulo funciona corretamente e de fato ele é mais simples do que eu imaginava, não necessitando conhecer algum protocolo específico para sua operação (exceto quando você está em modo de setup/configuração do módulo).
Bom, acredito que após essa longa introdução sobre comunicação, dispositivos seriais e LoRa, podemos começar a colocar a mão na massa e ver como usar os dispositivos LoRa e principalmente como utilizá-los através de um computador MSX.
Como eu já citei inicialmente, esse é o primeiro artigo introdutório e no próximo descreveremos tecnicamente os detalhes e possibilidades de integração de dispositivos LoRa no MSX ou em outras tecnologias como Arduino, Raspberry Pi, etc.
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.
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).
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 theseresolutions (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);
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 FRAMEWORK – PopolonY2k 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
VGM file support (1.0 up to 1.70 – some commands are still disabled. eg. non MSX existing chip commands);
Memory Mapper support (VGM files longer than 64Kb can be loaded and played);
MSXDOS2 only support (sub-directories access). Maybe MSXDOS1 will be supported in future releases;
AY8910 support;
YM2413 support;
YM2151 (SFG 01/05) support;
Y8950 (Philips Music Module) support;
YMF278 (OPL4) support;
K051649 (SCC) support;
KnownPop!Art missingfeatures in this release (0.0).
VGZ file support (in fact is VGM inside a .tar.gz file);
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;
Antes de mais nada eu quero deixar aqui o meu agradecimento pelo feedback recebido sobre o primeiro post da série sobre Networking no MSX, pois a movimentação e receptividade do publico já a colocam como uma das mais lidas desde que lancei o blog, então fica aqui o meu . obrigado a todos :).
OptoNet Card.
Quem acompanha de perto as novidades da comunidade local do MSX, sabe que no ano passado o Luis Fernando Luca, iniciou o desenvolvimento de uma placa multi-função que conta com interface de rede ethernet, interface serial e também entrada para cartão micro SD.
Pois bem, os avanços feitos por ele e relatados nas principais listas de discussão nacionais de MSX, já haviam deixado a comunidade bastante empolgada, principalmente depois do primeiro vídeo dos testes onde o próprio Luca junto do Fábio Belavenuto, demonstraram dois MSX conversando através de um chat escrito em MSX-BASIC, utilizado nos testes, conforme pode ser visto nesse post aqui.
Alguns meses depois o Luca informou, nas listas, o seu interesse em lançar um lote de sua placa, “para desenvolvedores”, pois dessa forma seria possível detectar e corrigir problemas na placa, bem como fazer melhorias no hardware e por ultimo, proporcionar novos desenvolvimentos de software para essa placa. Então, da mesma forma como fiz quando a TecnoBytes lançou a sua Obsonet, corri para adquirir a minha e assim começar a desenvolver coisas legais para a OptoNet e também ajudar em tudo mais o que eu puder em seu desenvolvimento.
OptoNet card + MSX TurboR A1ST
A engenharia de software
Placa nas mãos, férias do trabalho, era hora de arregaçar as mangas e começar a me divertir um pouco com a OptoNet. Já no primeiro dia testei o funcionamento da plaquinha utilizando os samples disponibilizados pelo Luca em seu site e em 15 minutos já havia planejado a minha estratégia para desenvolver softwares para a OptoNet sem que ficasse algo específico só para essa placa, pois até o momento que escrevo esse post, a OptoNet não conta com BIOS alguma e nada que a compatibilize com a UNAPI, que é o “padrão de facto” para Networking no MSX.
Então para que todo o software escrito para a OptoNet não ficasse disponível somente para essa placa, eu precisaria escrever uma abstração de sockets, de tal forma que eu pudesse especificar qual device driver utilizar no momento da criação do socket de rede, dessa forma eu poderia ter um device driver para a OptoNet e futuramente um device driver para dispositivos baseados em UNAPI, compatibilizando assim os softwares escritos para a OptoNet com as placas UNAPI compliance, como Obsonet e DenyoNet.
DenyoNet UNAPI compatible card
Infelizmente o MSX-DOS é um sistema operacional muito antigo e desprovido de uma camada abstrata para device drivers, como podemos ver em sistemas operacionais mais modernos, incluindo o pai do MSX-DOS, o MS-DOS em suas versões mais modernas, conforme pode ser lido aqui no site da Dr.Dobs sobre como adicionar device drivers ao MS-DOS.
Então para “burlar” essa deficiencia do sistema operacional, uma abstração foi escrita de tal forma a definir uma interface para dispositivos que suportam comunicação de dados e uma implementação que gerencia o registro dos device drivers bem como seu e fluxo de funcionamento pela aplicação.
Software layers
Com base nessas idéias eu já tinha todos os requisitos prontos para começar a escrever uma abstração de qualidade, bem como um primeiro device driver a ser utilizado como um test case para essa idéia toda, assim em um dia ininterrupto de trabalho eu já tinha tanto a abstração de sockets, quanto odevice driver para a OptoNet, implementados e com isso o framework que estou desenvolvendo em paralelo às ferramentas disponibilizadas por mim nos ultimos meses, por exemplo o MSXDUMP, agora tem suporte a funções de comunicação em rede, seja ela ethernet, Serial ou JoyNet, bastando apenas criar os device drivers específicos para cada uma dessas possibilidades existentes e inclusive outras que poderão vir no futuro :).
How it works
O principal objetivo da abstração de sockets é a simplicidade, aliado ao poder de qualquer implementação de sockets existente em qualquer plataforma com mais memória e poder de processamento. Abaixo segue um exemplo de como abrir uma conexão com outra ponta, enviar e receber dados utilizando a implementação de sockets desenvolvida.
{$v- c- u- a+ r-}
{$i types.pas}
{$i funcptr.pas}
{$i sockdefs.pas} (* Socket structures *)
{$i socket.pas} (* Socket abstract implementation *)
{$i helpstr.pas}
{$i optonet.pas} (* OptoNet low level functions and driver *)
(* implementation for socket support *)
(*
* Main block
*)
Var
packet : TSocketPacket;
socket : TSocket;
strData : TString;
Begin
{ Initialize the socket to use the OPTONET driver }
InitSocket( socket, Addr( OptoNetDrvSocketInit ) );
{ Socket configuration }
socket.strIPAddress := '192.168.1.1'; { The IP address to connect }
socket.nPort := 8080; { The port to connect }
(* The OPTONET CARD, actually, support ONLY UDP connection.
* When the firmware to support TCP connection,
* the SOCK_STREAM option will be available
*)
socket.Connection.SocketType := SOCK_DGRAM;
strData := 'THIS IS THE PACKET DATA TO SEND';
If( SocketConnect( socket ) = SocketSuccess ) Then
Begin
{ Packet data buffer configuration }
packet.pData := Ptr( Addr( strData ) ); { Weird TP3 pointer deference }
packet.nSize := Length( strData ) + 1; { + 1 for the first byte containing}
{ the size of the String }
{ Send the packet to another peer }
If( SocketSendPacket( socket, packet ) <> SocketSuccess ) Then
WriteLn( 'Error to send the packet to peer.' );
{ Receive the packet from another peer }
If( SocketRecvPacket( socket, packet ) <> SocketSuccess ) Then
WriteLn( 'Error to receive the packet from peer.' );
If( SocketDisconnect( socket ) <> SocketSuccess ) Then
WriteLn( 'Error to disconnect from peer.' );
End
Else
WriteLn( 'Error to connect to the specified address:port.' );
End.
O código acima contém tudo o que precisamos para Conectar -> Enviar um pacote -> Receber um pacote -> Desconectar e apesar do UDP ser um protocolo ConnectionLess, eu optei por fazer o device driver da OptoNet necessitar de um Connect pois o firmware da OptoNet necessita de algumas chamadas que explicitamente fazem algumas limpezas em seus buffers internos no momento em que vamos setar o IP e porta de conexão, então ao forçar um Connect para comunicação via UDP, ficamos com a falsa impressão de que UDP tem uma conexão estabelecida, tudo isso apenas para evitar de a cada Send ou Receive seja feito esse mesmo procedimento de limpeza explicita de buffer no firmware, o que acarretaria em uma perda forçada de pacotes com o modelo implementado atualmente no firmware.
Lembrando que isso são apenas impressões de um desenvolvedor de software de comunicação, de como um modelo de comunicação deveria ser, segundo os padrões já estabelecidos na industria de software, por isso, quando fizermos todos os ajustes necessários no firmware, para que o mesmo esteja adequado a esses padrões, certamente o modelo implementado pelo device driver implementado para a OptoNet, será ajustado para ficar de acordo com o padrão de comunicação UDP universalmente conhecido e aceito pelos desenvolvedores de software de comunicação.
No driver da OptoNet, o Disconnect é meramente ilustrativo, pois na versão final do device driver, ele não será aceito em conexões UDP, bem como o Connect.
Manifest Network Tools
Após a implementação do device driver e da abstração de sockets, faltava “apenas” criar aplicações que fizessem uso real de todo o potêncial dessa nova peça do framework.
A partir daí sairam as duas primeiras ferramentas de uma Suite que denominei de Manifest Network Tools, sendo essas ferramentas parte de um file transfer (SEND.COM e RECV.COM), capaz de fazer a transferência de arquivos entre máquinas MSX, utilizando UDP, com garantia de entrega pois apesar de UDP ser um protocolo que não garante a entrega de pacotes, implementei um protocolo simples baseado em ACK, que garante que todos os pacotes foram entregues a seu destino.
Send file transfer (Manifest Network Tool)
A operação das ferramentas é simples e basta apenas iniciar o RECV.COM na máquina que irá receber o arquivo e o SEND.COM na máquina que irá enviar o arquivo e aguardar o envio do arquivo até o destino. Cada uma das ferramentas tem um controle de fluxo, Timeout e numero de tentativas de recepção de pacotes, antes de reportar falha na conexão.
Cada uma das opções de linha de comando é explicada na própria tela de help das ferramentas e que também descrevo abaixo:
OPÇÕES DE LINHA DE COMANDO
-h Mostra o Help da aplicação; -a <ip_address> Especifica o endereço IP de cada ponta que irá estabelecer comunicação. O RECV.COM deve especificar o IP de onde está o SEND.COM e vice-versa; -p <port_number> Especifica o número da porta a se conectar ou que estará escutando (no caso do RECV.COM);
Recv file transfer (Manifest Network Tool)
Infelizmente os testes, tanto do RECV.COM quanto do SEND.COM, foram feitos utilizando um MSX e um PC, pois não tenho 2 placas OptoNet, entretanto utilizando um cliente similar que criei no Linux para o PC, pude testar vários casos e otimizar o SEND.COM e o RECV.COM no MSX, mas ainda é necessário fazer um teste real entre 2 MSX enviando e recebendo dados através dessas ferramentas, o que poderá ser feito agora pela comunidade de MSX e que já possui a OptoNet :).
Known Bugs
Infelizmente nem tudo é um mar de rosas e alguns bugs foram detectados por mim, tanto na OptoNet, quanto nas ferramentas que criei.
Alguns problemas encontrados na OptoNet:
Percebi que ao utilizar a velocidade máxima do MSX para enviar comandos para a placa, a mesma trava, sendo necessário desligar o MSX, uma vez que o PIC é um circuito a parte e um simples reboot no MSX não é suficiente para resetar o PIC. Nesse caso eu tentei dar sleeps entre as chamadas à OptoNet (na camada do device driver) para evitar os travamentos, entretanto mesmo assim a comunicação fica instável e também mais lenta devido aos sleeps. Quando resolvermos isso, irei remover os sleeps e teremos um driver mais rápido e estável.
No TurboR há constantes travamentos na máquina, algumas vezes durante o uso e outras no boot (Necessito testar em outros TurboR’s que tenho aqui);
Em máquinas com impressora embutida (ex: National FS4700) a comunicação com a placa fica instável, apenas consegue enviar comandos para a placa mas não recebe;
No HitBit HB-T7 (com modem interno) a placa não recebeu nem enviou nenhum pacote, me passando a impressão de que não está funcionando nesse micro. O Emiliano Fraga, no GDMSX, me reportou que no HitBit dele a placa também não funcionou, então acredito que o problema esteja relacionado com os HitBit’s de maneira geral, mas necessita de mais fontes de informação para se confirmar isso;
Alguns problemas das ferramentas SEND.COM e RECV.COM:
Adicionar parâmetros para que o usuário possa definir o Timeout da comunicação e número de tentativas (retries);
Adicionar o conceito de sessão às ferramentas, pois hoje é possivel que mais de um cliente (SEND.COM) se conecte a um servidor (RECV.COM), causando danos na comunicação e consequentemente no arquivo enviado;
Onde baixar os fontes e os binários.
No ultimo domingo, liberei silenciosamente no repositório do Old Skool Tech, os fontes e binários da Suite Manifest Network Tools v0.0, onde eu estava apenas aguardando esse post para fazer o anuncio oficial :).
Bom, acredito que estamos caminhando bem rápido e em breve teremos cada vez mais, versões estáveis, tanto da OptoNet quanto das ferramentas que a utilizam.
Esse ano tem sido bem dificil de manter uma certa constância nos posts em meu blog, entretanto essa demora toda tem um bom motivo que é justamente a quantidade de projetos que tenho me envolvido nos ultimos meses, sendo a maioria projetos de software e junto desses projetos tenho acumulado informações e conhecimento suficientes para abastecer o blog por pelo menos uns 2 anos sem ter que desenvolver nada de novo :).
Early days
No mundo da computação existem muitas áreas que eu gosto de pesquisar, adquirir e disponibilizar conhecimento sobre uma determinada tecnologia ou ciência que acho interessante. É justamente por seguir essa linha de raciocínio que há aproximadamente 12 anos atrás eu iniciei um projeto voltado a pesquisa e desenvolvimento de protocolos de comunicação, visando o desenvolvimento de soluções servidoras, desktops clients e micro-dispositivos em geral, assim, no inicio de 2001 nascia o projeto PlanetaMessenger.org, com o intuito de desenvolver tecnologias para comunicação de dados utilizando qualquer meio de transporte.
Hoje, código do PlanetaMessenger.org é utilizado por diversos outros clientes e gateways de instant messengers, bem como servidores de chat e projetos open source ao redor do planeta :).
PlanetaMesseger.org Main Window (v0.3)
O conhecimento e experiências adquiridos nesse desenvolvimento me abriram algumas portas, nos anos seguintes, para trabalhar com clientes nacionais e internacionais e também em outros projetos open source bem reconhecidos, como o simulador de vôo FlightGear onde entrei para a lista de contribuidores do projeto em 2006, após ter feito melhorias no módulo de streaming JPEG do simulador, que na época demorava algo em torno de 1 minuto para fazer a transferência, pela rede local, de um bloco de 320×200 e após as melhorias o mesmo streaming JPEG era realizado, pela mesma rede, na taxa de 24fps de uma área de 1024×768, da janela do simulador….agora dá para assistir um DVD através desse streaming :).
Bom, após muito tempo participando da comunidade MSX internacionalatuando como tradutor no MSX Resource Center até aproximadamente meados 2006, finalmente em 2010 decidi dar inicio a esse blog onde escreveria sobre tudo o que gosto, relacionado a tecnologia, e o meu principal foco desde então tem sido o MSX.
Desde o meu “recomeço” no mundo MSX eu estava procurando algo relacionado a comunicação de dados para assim começar a brincar com o que eu já faço e gosto de fazer desde o final da década de 90 e inicio de 2000, tanto que em um dos meus primeiros posts do blog, citei sobre a existência da NoWind, que é uma interface USB capaz de conectar o MSX a um PC, sendo que a característica que mais me chamou a atenção nessa placa foi a possibilidade de comunicação com o PC através do dispositivo AUX: que fica disponível também no MSX-BASIC, tornando possível uma comunicação entre um MSX e um PC, programáticamente.
Nessa época eu já havia adquirido alguns dispositivos de comunicação, como MODEM DDX, Interface Serial Gradiente e duas interfaces obscuras de comunicação, HB-3000, da Epcom, tudo visando um dia iniciar, também no MSX, o desenvolvimento de softwares e ferramentas de comunicação de dados, mas falatava algo mais “moderno” e atual nessa brincadeira toda.
O MSX na rede
O conceito de comunicação em rede ou Computer Networks, no universo MSX, não é algo recente, sendo explorado desde a década de 80, passando pela década de 90 quase despercebido, tendo se estabelecido como algo real e “padronizado” somente em meados dos anos 2000.
BBS – Bulletin board system
A primeira onda de comunicação de dados e computação em rede, utilizados em “massa” aqui no Brasil, veio através dos BBS que proporcionavam conexão entre computadores e usuários através de um servidor central, onde ali poderiam trocar e-mails, conversar em chat, fazer upload e download de arquivos, tudo isso utilizando um dispositivo especifico denominado modem, junto com uma linha telefônica, que era o meio por onde as informações trafegavam entre os micros. No Brasil os principais BBS estavam localizados no eixo Rio-São Paulo, sendo o Mandic BBS o mais famoso deles, entretanto existe uma citação sobre o BDI BBS, que acredito ser do Rio de Janeiro e que me fez deixar o link disponível aqui pelo óbvio motivo do texto ter uma forte ligação com a história do MSX :).
Joynet
Me lembro de acompanhar, lá por 1998/99, uma certa euforia na comunidade internacional pela “descoberta” de uma possibilidade de comunicação entre computadores MSX, que na verdade havia sido desenterrada dos “longinquos” anos 80, quando algumas empresas japonesas de jogos e softwares desenvolveram um método de comunicação entre computadores MSX, utilizando apenas cabos conectados através das portas de joystick.
Essa “especificação” de rede ficou conhecida como JoyNet e rendeu a implementação de diversos novos softwares bem como a possibilidade de uso da “nova rede” com os softwares antigos, incluindo os jogos antigos já existentes. A desvantagem é que não há uma BIOS que padronize o acesso aos “dispositivos” conectados.
F1 Spirit 3D Special – Um dos jogos do início da década de 90 a utilizar a JoyNet
Ethernet cards
Placas ethernet, wired ou Wi-Fi, são bastante comuns no universo dos PC’s já faz algum tempo, sendo um dispositivo padrão da maioria das MotherBoards atuais. Infelizmente essa tecnologia é algo “recente” para a maioria dos computadores antigos, principalmente os de 8 bits, apenas há pouco tempo.
No mundo de retrocomputing é sempre complicado fazer a integração entre o novo e o antigo, o que me lembra muito um outro computador denominado “ser humano” :), entretanto o que é dificil geralmente é mais instigante e desafiador, sendo esse um fator desafiador para muitas pessoas, eu incluso.
No universo MSX a dificuldade em integrar o novo ao antigo não difere de nenhum outro ambiente carente de recursos de memória e processamento e talvez por isso tenha demorado um pouco até que tivessemos algo realmente funcional e perfeitamente integrado ao padrão MSX quando o assunto é ethernet card, uma vez que se trata não só de um desenvolvimento de hardware isolado mas também uma definição da camada de software necessária para que existam softwares para o novo dispositivo, ou seja, não existe sucesso senão houver um trabalho conjunto e gradativo entre as duas pontas.
Me lembro que a primeira vez que eu ouvi falar de ethernet no MSX, foi lá por 1998 ou 1999, e se tratava de um trabalho de graduação de algum aluno de uma universidade americana, acho que era um espanhol que estudava nos EUA , enfim, o fato é que ele e mais alguns colegas estavam trabalhando tanto no hardware quanto no software necessários para o trabalho de gradução. Infelizmente perdi o link sobre esse trabalho mas achei algumas páginas no cache do Google sobre um projeto similar e que acredito ser o mesmo, só que com uma modificação referente a integração desse trabalho com o UZIX.
E por falar em UZIX, não posso deixar de citar que se trata do primeiro maior trabalho em software relativo a conectividade no MSX, pois reconhecidamente houve muito desenvolvimento, por parte do autor, para conectar o MSX à redes usando qualquer pedaço de hardware existente na época. E só estou citando os recursos de comunicação, sem contar as demais características desse sistema operacional, como a possibilidade de multi-tasking, no MSX.
Me lembro que no inicio de 2002, um pouco depois de lançar a versão 0.0 do PlanetaMessenger.org, eu entrei em contato com o autor do UZIX em busca de informações sobre a camada de comunicação do sistema com a finalidade de escrever uma versão light do PlanetaMessenger.org para esse sistema operacional. Infelizmente eu pouco parava em meu escritório, naquela época, e não tinha tempo para qualquer outro projeto, mesmo que infinitamente menor.
UZIX – UNIX implementation for MSX
Obsonet
A “primeira” tentativa de sucesso que colocou o MSX em rede utilizando uma ethernet card e de acordo com as especificações sugeridas pelo padrão MSX, foi reconhecidamente a Obsonet e foi feita pelo projetista de hardware Daniel Berdugo, com participação do reconhecido desenvolvedor de softwares e padrões para a plataforma MSX, KonamiMan (Nestor Soriano), desenvolvendo a BIOS, Stack IP (InterNestor Lite) e demais softwares de rede.
Obsonet original de 2004
No Brasil a TecnoBytes Classic Computers chegou a lançar um lote da Obsonet entre 2011 e 2012 e ainda lança constantes fornadas de sua placa Obsonet, assim como faz para os demais produtos de seu portfólio. Na época desse tão aguardado lançamento (pelo menos por mim), fiquei tão empolgado que adquiri, logo de cara, 4 placas Obsonet da TecnoBytes, placas essas que são tão primordiais no uso diário do meu MSX, quanto uma placa IDE.
Bom, esse foi o primeiro de muitos posts que pretendo fazer sobre Networking no MSX, sendo que os demais vou começar a dar foco nos detalhes técnicos, principalmente relacionados a desenvolvimento de software utilizando toda tecnologia de comunicação de dados disponível no MSX, uma vez o mercado nacional de desenvolvimento de software e hardware para MSX, relacionado a comunicação dados em rede, está bastante movimentado devido ao recente lançamento, para desenvolvedores, da nova placa do Luis Fernando Luca, placa essa que já apelidei de OptoNet.
Mas vamos dar um passo de cada vez, vamos deixar um pouquinho de informação para o próximo post :).
