10 regras da NASA para desenvolver código seguro.

Recentemente postei nas comunidades GDMSX do FaceBook e do G+ um texto bem interessantante sobre algumas dicas da NASA de como desenvolver código seguro.

Isso é muito interessante principalmente para aqueles que desenvolvem código para sistemas/dispositivos que nunca pode se dar ao luxo de uma exceção não tratada ou um core dump, comuns no mundo UNIX ou os famosos GPF’s bem conhecidos para programadores do mundo Windows.

Alguns membros da comunidade GDMSX me pediram para traduzir, então eu decidi fazer uma tradução livre, com algumas considerações pessoais que estão marcadas no texto como “(*) Notas do tradutor” 🙂 .

Vamos ao texto.

10 regras da NASA para desenvolver código seguro.

NASA Computers
NASA Computers

A NASA tem escrito software de missão crítica para a exploração espacial por décadas e agora a organização está transformando esses guias de programação em um padrão de desenvolvimento de software da indústria.

O laboratório de propulsão a jato da NASA para softwares confiáveis (JPL), recentemente publicou um conjunto de guias de programação (code guidelines), “Potência de 10 – Regras para o desenvolvimento seguro de código crítico“. O autor do texto, o cientista chefe Gerard J. Holzmann, explicou que a quantidade de codificação existente é inconsistente e cheia de regras arbitrarias, raramente permitindo tarefas essenciais como verificação de conformidade de código baseado em ferramentas de checagem de código. Os guias existentes, ele disse, inundam os programadores com regras vagas, diminuindo a qualidade do código da maioria das aplicações críticas.

“Projetos mais sérios de desenvolvimento de software usam guias de codificação,” escreveu Holzmann. “Esses guias destinam-se a firmar as regras básicas para o qual o software está sendo escrito: como ele deveria ser estruturado e quais características da linguagem deveriam e não deveriam ser usadas. Curiosamente, existe um pouco de consenso sobre o que é um bom padrão de codificação.”

 Holzmann definiu 10 regras rígidas para o desenvolvimento de software, tendo em mente a segurança do código. As regras foram especificamente escritas levando em consideração a linguagem C (uma linguagem recomendada pela NASA devido a sua longa história no desenvolvimento de software crítico e seguro e também pelo extensivo suporte de ferramentas a essa linguagem como por exemplo analisadores de código, depuradores, ferramentas de testes, dentre outras), embora essas regras possam ser facilmente generalizadas para codificação em qualquer outra linguagem, principalmente as que tem forte similaridade com C no nível de estruturação, como é o caso de Pascal e suas variantes.

  1.  Restrinja toda a construção de seu código a um fluxo de controle muito simples. Não use declarações GOTO, construções com setjmp ou longjmp, ou recursividade direta ou indireta;

    (*) Nota do tradutor:
    Quanto ao GOTO não é preciso nem escrever muito a seu respeito pois um de seus “males”, que é o de deixar o código confuso através de saltos incondicionais, já são amplamente conhecidos ao longo dos anos. O mesmo acontece com a dupla setjmp/longjmp que causam o mesmo efeito do GOTO, mas infelizmente esse recurso ainda é muito defendido por programadores experientes de C que muitas vezes se recusam a abandoná-los.
    Quanto à recursividade direta ou indireta, realmente essas tornam o código mais complexo entretanto por diversas vezes o seu código pode se tornar mais eficaz do que utilizando métodos tradicionais para resolução de um problema. Um exemplo é o algoritmo de multiplicação reconhecidamente veloz conhecido como algoritmo de Karatsuba e que é recursivo.
    Eu particularmente sugiro que se utilize métodos recursivos pequenos e de baixa complexidade, pois dessa forma pode-se evitar possíveis pontos de falhas que são invisíveis na maioria das vezes em tempo de desenvolvimento, mas que são comuns em uma situação de missão crítica.
    Quando se optar por implementar métodos recursivos, tenha em mente que a cobertura de seus testes unitários deverá ser extremamente abrangente a ponto de se testar as mínimas situações de falha.

  2. Todos os loops devem ter um limite superior fixo. Isso deve ser trivial para uma ferramenta de checagem que prove, estaticamente, que um dado limite no número de iterações não pode ser excedido. Se o limite do loop não puder ser comprovado estaticamente, a regra é considerada violada. Caso os limites sejam violados, o método deverá disparar um assert a ser verificado pelo chamador.

    (*) Nota do tradutor:
    Essa regra pode ser checada através da implementação de testes unitários com os devidos cenários mapeados.

  3. Não use alocação dinâmica de memória após a inicialização.

    (*) Nota do tradutor
    Realmente alocação dinâmica em linguagens que não são gerenciadas por um Garbage Collector é algo crítico e que deve ser utilizado de maneira cuidadosa, principalmente para principiantes no desenvolvimento de software. No artigo original, o autor cita diversos dos problemas conhecidos em se utilizar alocação dinâmica como a não liberação de recursos corretamente, o que causam os famosos vazamentos de memória ou memory leaks, e também cita sobre o cuidado de não ultrapassar os limites da memória alocada, esse último sendo também um problema quando se está usando memória alocada estaticamente em C.
    Entretanto existem casos que a alocação dinâmica é necessária e não há como escapar, nesses casos o mais comum a se fazer é alocar o buffer desejado em um ponto único, fazer toda e qualquer referência a esse buffer através de ponteiros passados para as funções que irão manipulá-lo e por fim liberá-lo nesse mesmo ponto único em que foi alocado, de preferência. Dessa forma você restringe toda a construção de seu código a um fluxo de controle muito simples, que é exatamente o primeiro item sugerido por esse guideline.
    Muitos dos desenvolvedores de softwares novatos sequer tem conhecimento de problemas de fragmentação de memória, decorrentes do abuso excessivo de alocação e liberação dinâmica de memória, principalmente em dispositivos de missão crítica que geralmente são hardwares embarcados dedicados e com recursos limitadíssimos de memória e armazenamento.

  4. Nenhuma função deve ser tão extensa que não possa ser impressa em uma única folha de papel (em uma referência ao formato padrão com uma linha por instrução e uma linha por declaração). Tipicamente isso significa não mais do que 60 linhas de código por função.

    (*) Nota do tradutor
    Manter o código com poucas linhas por função é sempre uma excelente prática pois facilita na manutenção do mesmo, entretanto algumas vezes principalmente em se tratando de código que gerencia máquinas de estado complexas, é melhor que a função fique um pouco maior do que as 60 linhas sugeridas ao invés de quebrá-las em mais funções para que comporte as 60 linhas, pois se ganha em performance, uma vez que se reduz o custo das passagens de parâmetros entre funções, ainda mais em se tratando de passagem de parâmetros de grandes estruturas por valor, que nesse caso é também uma péssima prática e que deveria ser substituída por passagem por referência ou ponteiro. Em linguagens orientadas a objeto, a regra de 60 linhas por método (função) é mais plausível e fácil de se atingir por conta da capacidade de encapsulamento dessas linguagens.

  5. A quantidade de asserts por função deve ser de no mínimo duas por função. Asserts não devem causar nenhum efeito colateral no código e deveriam ser definidos como testes booleanos.

    (*) Nota do tradutor
    Linguagens com um rico pré-processador como são C e C++ são propensas a inserção de asserts que estarão ativos dependendo do modelo de compilação em que o  binário/executável foi gerado, com isso pode-se gerar compilações de software específicas para testes.

  6. Dados devem ser declarados no menor nível de escopo possível.

    (*) Nota do tradutor
    O uso de variáveis globais é algo que vem sendo desestimulado no decorrer dos anos, pois é reconhecido que manter os dados encapsulados em escopos cada vez menores é um grande facilitador na hora de se descobrir bugs ou realizar qualquer tipo de manutenção ou melhorias no código, então declarar variáveis específicas de cada escopo é uma boa prática de programação.

  7. Cada função chamadora deve checar o retorno de funções não void (que retornam valores) e a validade dos parâmetros devem ser checadas dentro de cada função.

    (*) Nota do tradutor
    Isso é algo óbvio……bom, pelo menos deveria ser 🙂 .

  8. Uso de pré-processador deve ser limitado a inclusão de arquivos header e definição simples de macros. Macros complexas como as recursivas e com listas de argumentos variáveis, devem ser evitadas.

    (*) Nota do tradutor No texto original o autor descreve que o uso de macros de compilação condicional é algo dúbio entretanto não pode ser sempre ignorado. Eu concordo plenamente com a ideia de que não pode ser ignorado, uma vez que sempre tivemos diversas plataformas diferentes e dominantes na história da computação moderna, e o uso do pré-processador para se ter suporte a compilação condicional é uma excelente técnica que tem possibilitado manter um código portátil entre as diversas plataformas que vão desde os diversos sistemas operacionais disponíveis em PC’s até aos diversos dispositivos mobile existentes hoje.

  9. O uso de ponteiros deve ser restrito. Especificamente, não mais do que um nível de deferenciação é permitido. Operações de deferenciação de ponteiro não podem estar escondidas em macros ou dentro de declarações typedef. Ponteiros de função não são permitidos.

    (*) Nota do tradutor.
    Talvez esse seja o mais polêmico item do guia. Operações com ponteiros são algumas vezes complexas dependendo do nível de deferenciação. São raros os casos em que é necessário o uso de ponteiros duplos ou triplos, entretanto pode ser evitado e sugiro que seja evitado.
    Quanto ao uso de macros para deixar a deferenciação mais “limpa e clara”, para mim isso tem um nome e se chama “armadilha”. Fuja de quaisquer construções que “escondam” a complexidade de alguma operação, e essa regra não deve ser considerada apenas nas operações de ponteiros.
    Entretanto há ressalvas quanto ao uso de typedefs na declaração de um tipo ponteiro,  como por exemplo as definições de ponteiros para funções amplamente utilizadas nas API’s do Windows e UNIXes em geral, nesse caso não há como escapar uma vez que esses sistemas operacionais fazem uso extensivo de callbacks para proporcionar respostas a eventos requeridos e necessários para a aplicação do usuário.
    Quanto a proibição de ponteiros para função, talvez para a maioria das aplicações comuns de desktop seu uso realmente não seja necessário, entretanto para aplicações de missão crítica embarcadas como as que utilizam algum kernel real-time, como por exemplo o uC de Jean Labrosse e que fazem extenso uso de ponteiros para função para implementar as diversas tasks da aplicação do usuário, o uso de ponteiro de função é algo bem comum.
    A construção de softwares kernel real-time é repleta de ponteiros de função, até mesmo para proporcionar uma abstração de tasks, timers dentre outras estruturas típicas desse tipo de software.

  10. Todo código deve ser compilável desde o primeiro dia de desenvolvimento, com todos warnings do compilador ativados. Todo código deve compilar com essa configuração, sem gerar nenhum warning ou erro. Todo código deve ser checado diariamente com pelo menos um – de preferência mais do que um – excelente analisador de código estático (o que ele cita como analisador estado-da-arte), e a análise deve passar sem warning algum.

    (*) Nota do tradutor
    Quanto ao detalhe dos warnings de compilação, acredito que já seja bem comum em grandes projetos, entretanto a parte do analisador “estado-da-arte”, não creio que sequer mercados corporativos em países avançados a utilizem, exceto empresas de altíssima tecnologia que dependam de que seus softwares funcionem 24×7 ou de forma embarcada em algum dispositivo.

 Holzmann incluiu diversos comentários no documento original para cada uma das regras descritas acima, mas a essência do documento é que quando as regras forem utilizadas em conjunto, garantam um fluxo claro e transparente que tornem fácil a construção, testes e análise de código amplamente aceitos como livres de falhas. A JPL tem desenvolvido softwares automatizados para missões espaciais como a Mars Curiosity and a Voyager, e o laboratório já está usando essas regras em uma base experimental para escrever software de missão crítica.

Holzmann acredita que seguir as regras da NASA minuciosamente, pode diminuir a carga sobre os desenvolvedores e levar a uma melhor segurança e clareza do código.

“Se as regras parecerem draconianas no inicio, tenha em mente que elas foram criadas para que se possa checar códigos onde a sua vida pode depender muito de que haja precisão: código utilizado para controlar o avião em que você voa, a usina nuclear a poucas milhas de onde você vive, as aeronaves que carregam os astronautas em órbita”, escreve ele.

“As regras agem como o cinto de segurança em seu carro: Inicialmente eles parecem ser um pouco desconfortáveis, mas depois de um tempo seu uso se torna natural e não usá-los se torna inimaginável.”

O texto acima foi traduzido do original que pode encontrado no link do site SDTimes abaixo:

http://sdtimes.com/nasas-10-rules-developing-safety-critical-code/

[]’s
PopolonY2k

MSX Sunrise-like IDE devices programming

Since I wrote my first post about IDE devices (Sunrise-like) on MSX computers, I’ve been thinking to write a new post about this subject.

Well, the MSX community already knows about my last efforts to develop disk tools for MSX computers and how I’m spending some energy to build a framework that will help the development of new software compatible with IDE (Sunrise-Like) devices.

In the last year I finished my first project using MSX IDE standard. The result was the creation of a disk editor known as MSXDUMP.

In conjunction with MSXDUMP, an important part of the framework has been developed. It is responsible to perform the access between the high level software layer and the low level hardware layer.

Of course this piece of my framework was possible thanks to the work done by Sunrise team, long time ago when they wrote the IDE BIOS containing all low level calls available to the software programmer.

Also it is possible to write software for Sunrise-like IDE devices using direct access through I/O ports dedicated to this device, but in this case the work would be very hard and unnecessary because the IDE BIOS routines cover everything needed by the device.

For this reason, this article won’t cover direct access.

A world without standard

In the 80’s the software industry was very primitive and the software developers seemed to be living in a wild jungle with several kinds of hardware to program and control. With different hardware standards those days were very hard for developers, considering the lack of software standardization in this primitive industry.

Everything was focused on hardware for the most part of existing standards found in the 80’s. The MSX was the first attempt, in the 8 bit world, to join the hardware with the software to act like the operating systems do today.

Then the concept of BIOS functions, generally introduced through a cartridge, was born with MSX computers and with it came the almost infinite expansibility of the MSX standard.

The Sunrise IDE BIOS

When I got my first Tecnobytes ATA/IDE interface, that was a Sunrise compatible interface manufactured in Brazil by Tecnobytes Classic Computers, for the first time I could understand the workings and limitations of this device.

Tecnobytes ATA IDE Sunrise-like interface

The big part of the device’s limitation is related to the software’s inherent lack for this device. This was the reason why I started to study Sunrise compatible device internals.

Fortunately the current Brazilian MSX community has been the best since MSX was introduced here in the 80’s and thanks to the internet we can find all the information needed to know most details about this device.

I want to cite and thank Ricardo Oazem of Tecnobytes Classic Computers who provided me all technical details including documents and source code about I/O ports and BIOS functions of Sunrise IDE.

All technical information found in this article is compatible with any Sunrise-like IDE devices, like, Sunrise, Tecnobytes and Carchano IDE.

IDE Sunrise-like interface by Carchano.
IDE Sunrise-like interface by Carchano.

Inside the BIOS

After a long period studying the source code of the Sunrise BIOS and the documents found on the Sunrise website, I finally understood how it works in details.

Functions versioning

Internally the IDE has some addresses dedicated to versioning and a IDE signature, like described below.

Const
      ctDefaultWrkspcPage     = 3;     { Default workspace slot page }
      ctIDENotFound           = 255;   { IDE not found }
      ctBIOSMajorVerAddr      = $7FB6; { BIOS major version address }
      ctBIOSMinorVerAddr      = $7FB7; { BIOS minor version address }
      ctBIOSRevisionAddr      = $7FB8; { BIOS revision version address }
      ctIDESignatureAddr      = $7F80; { IDE signature address }

(* Workspace BIOS Call Routines *)
      ctBIOSGetDriveFieldAddr = $7FBF; { Get drive field address }

The first operation to do is to discover what slot the IDE is connected to. This can be done using the address &H7F80 (IDE signature address) for each slot/sub-slot of MSX, looking for the bytes ‘I’ followed by ‘D’ and ‘#’, until you find it.

After discovering the slot that the IDE is connected to, you can get the BIOS version used by the interface. This is easily found at following addresses.

Const
      ctBIOSMajorVerAddr      = $7FB6; { BIOS major version address }
      ctBIOSMinorVerAddr      = $7FB7; { BIOS minor version address }
      ctBIOSRevisionAddr      = $7FB8; { BIOS revision version address }

Retrieving the BIOS version isn’t a mandatory step but is a good idea to check it. If you’re not sure about the existence of a feature provided by the BIOS of your device so this checking will be useful.

The Drive Field structure.

MSX computers are limited devices with low resources capacity, for this reason the MSX-DOS can handle just 8 simultaneous logical drives. The Sunrise IDE allocates 6 of these 8 logical drives, so the maximum capacity of simultaneous connected IDE devices is 6.

This allocated area for these 6 drives is a structure known as Drive Field. Each drive field contains the following structure below.

(*
 * Drive field definition. The size of drive fields is variable
 * and can change according BIOS version. The current rule is written
 * like below:
 * 8 for BIOS 1.9x and 2.xx;
 * > 8 for BIOS 3.xx and higher;
 * See idesys.txt for details
 *)
Type TDriveField = Record
  nDeviceCodeByte     : Byte;
  n24PartitionStart,                        { 24Bit absolute sector number }
  n24PartitionLenght  : TInt24;             { 24Bit sector (count - 1) }
  nAdditionalPartInfo,                      { Addition partition info }
  (* The two bytes below is reserved to BIOS 3.xx or higher *)
  nPartitionStart,                          { Partition start bit 24 to 31 }
  nPartitionLength    : Byte;               { Partition (lenght - 1) 24 to 31 }
End;

As you can see there are two bytes at the end of the structure above and in the “official” documentation of IDE, it says “RESERVED TO BIOS 3.xx OR HIGHER”. I suppose that these two bytes was put there for future use in FAT16 and FAT32 native support in the Sunrise IDE devices.

The WorkSpace

The Sunrise specification defines  an area that contains all the 6 DriveFields structures managed by the interface, plus another structure known as the DeviceInfoBytes, followed by an unused free space of 18 bytes.

This structure formed by 6 DriveFields + DeviceInfoBytes + Free space (18 bytes) is known as the IDE WorkSpace.

The IDE WorkSpace is filled at the machine start up and loads the first 6 partitions available to the IDE connected interface.

Const
(*
 * IDE interface Workspace allocate at boot process.
 * More details check idesys.txt file at this library
 * directory.
 *)
Type TIDEWorkspace = Record
  ptrDriveField      : Array[0..ctDriveFieldSize] Of PDriveField;
  ptrDeviceInfoBytes : PDeviceInfoBytes;
  ptrFreeSpace       : PFreeSpace;
End;

NOTE: It is possible to exchange the partition content pointed to a different DriveField just using the IDEPAR command line utility.
In a hypothetical situation where your drive letter B: points to the second partition in the disk, you could point this drive B: to another formatted partition higher than 6 crossing the limits imposed by the Sunrise interface.
This could be done using the IDEPAR utility, but it use is not covered by this article.

The DeviceInfoBytes structure

The DeviceInfoBytes structure is an important and useful area of the IDE WorkSpace because it contains some information about the physical device that is connected in the interface, like the number of heads from device master and slave, maximum of cylinders by sector on both, master and slave connected disks.

The structure is defined as shown below:

(*
 * Device info bytes definition.
 * 6 bytes for BIOS 1.9x and 2.xx.
 *)
Type TDeviceInfoBytes = Record
  nNumOfHeadsMaster,             { For ATA Devices }
  nNumOfHeadsSlave,              { For ATA Devices }
  nNumSectorsCylMaster,          { For ATA Devices }
  nNumSectorsCylSlave,           { For ATA Devices }
  nDeviceTypeMaster,
  nDeviceTypeSlave,
  nUndefined           : Byte;   { Undefined yet - don`t use them }
End;

Type PDeviceInfoBytes = ^TDeviceInfoBytes;  { TDeviceInfoBytes pointer type }

The new BIOS functions

The Sunrise interface introduces at least 4 new BIOS function calls that can be used by applications compatible with Sunrise devices.

ATAPI BIOS calls

The two first functions are listed below:

(* Sunrise-like IDE BIOS calls *)

Const     ctBIOSSelectATAPIDevice = $7FB9; { Select master or slave device }
          ctBIOSSendATAPIPacket   = $7FBC; { Send ATAPI to selected device }

These two functions are related to control ATA devices, like a CDROM, using the ATAPI command packets. An example is an application that commands the CDROM device to open the tray.

Sector I/O BIOS calls.

It is known that IDE devices can handle a mass storage with higher capacity than the old disk drives. In fact, old disk drives just can manage sectors from 0 (zero) to 65535 (the maximum value accepted by a 16 bit unsigned number).

Fortunately today we have some storage devices supporting megabytes, gigabytes and recently terabytes.

The Sunrise IDE interface brought the possibility of connecting with these higher capacity devices, but unfortunately the MSX-DOS BDOS functions and old softwares cannot handle the full capacity of these new devices.

Fortunately Sunrise already developed alternative I/O sector functions capable of managing devices that can handle a big amount of data.

Two new I/O functions were introduced into the IDE BIOS to do the sector’s handling using 24 bit unsigned numbers (0 to 16.777.215). These functions are listed below:

(* Sunrise-like IDE BIOS calls *)

Const     ctBIOSAbsSectorRead  = $7F89;  { Absolute sector read function  }
          ctBIOSAbsSectorWrite = $7F8C;  { Absolute sector write function }

These two functions should be used by applications that handle sector management instead the MSX-DOS BDOS functions ABSREAD (&H2F) and ABSWRIT (&H30), because the new functions support unsigned 24 bit sector’s handling instead the MSX-DOS old functions that support only 16 bit setor’s handling.

The Big Number library

The MSX computers can perform 16 bit operations directly and to use the new I/O functions provided by the BIOS, the programmers should provide a way for MSX perform 24 bit operations.

Fortunately I created a library (BigNumber) that can handle numbers of any size, since 8 bit, 16 bit, 24 bit, 32 bit to infinite bits.

This library can be found at OldSkoolTech and is fully written and compatible with Turbo Pascal 3 and has been used in my own softwares like the MSXDUMP 0.2, compatibles with Sunrise devices.

Well, I believe that this article could be an useful article to technicians and developers that are interested in creating new softwares to use the full capacity of Sunrise devices, so enjoy it !!

PopolonY2k

References

Análise da interface ATA IDE – Tecnobytes
http://www.popolony2k.com.br/?p=409

MSXDUMP v0.2 (final) liberado no SourceForge.net
http://www.popolony2k.com.br/?p=2125

Memory-mapped I/O ports
http://en.wikipedia.org/wiki/I/O_port

Tecnobytes Classic Computers
http://www.tecnobytes.com.br/

Sunrise for MSX home page
http://www.msx.ch/sunformsx/

MSX-DOS Wikipedia
http://en.wikipedia.org/wiki/MSX-DOS

Carchano MSX IDE interface
http://www.carchano.com.br/loja/

ATAPI packets (Wikipedia)
http://en.wikipedia.org/wiki/ATA_Packet_Interface

CP/M-BDOS (Wikipedia)
http://en.wikipedia.org/wiki/BDOS#BDOS

PopolonY2k’s BigNumber library at SourceForge.net
http://sourceforge.net/p/oldskooltech/code/HEAD/tree/msx/trunk/msxdos/pascal/bigint.pas

OldSkoolTech project (SourceForge.net)
http://sourceforge.net/projects/oldskooltech/

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

MSX Networking – Developers, developers, developers, developers….

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
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
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
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 o device 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
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
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:

  1. 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.
  2. 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);
  3. 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;
  4. 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:

  1. Adicionar parâmetros para que o usuário possa definir o Timeout da comunicação e número de tentativas (retries);
  2. 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 :).

http://sourceforge.net/projects/oldskooltech/files/MSX/Manifest%20Network%20Tools/v0.0/manifest-src.zip/download
Fontes (Zip)

http://sourceforge.net/projects/oldskooltech/files/MSX/Manifest%20Network%20Tools/v0.0/manifest-src.lhz/download
Fontes (Lhz) 

http://sourceforge.net/projects/oldskooltech/files/MSX/Manifest%20Network%20Tools/v0.0/manifest-bin.zip/download
Binários (Zip)

http://sourceforge.net/projects/oldskooltech/files/MSX/Manifest%20Network%20Tools/v0.0/manifest-bin.lhz/download
Binários (Lhz)

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.

Até os próximos posts.

[]’s
PopolonY2k

Referência na internet

MSX Networking (Parte I)
http://www.popolony2k.com.br/?p=2150

OptoTech card for MSX
http://www.optotech.net.br/fzanoto/msx.htm

MicroSD Card (Wikipedia)
http://pt.wikipedia.org/wiki/MicroSD

OptoNet chat (MSX-BASIC code)
http://www.optotech.net.br/fzanoto/CHAT_FB2.BAS

Video de demonstração de chat utilizando a OptoNet (Retrocomputaria Plus)
http://www.retrocomputaria.com.br/plus/?p=4606

TecnoBytes Classic Computers
http://www.tecnobytes.com.br/

Obsonet (MSX Resource Center)
http://www.msx.org/articles/obsonet

GDMSX (Desenvolvimento de software e coisas legais para MSX)
http://groups.google.com/group/gdmsx

Network sockets (Wikipedia)
http://en.wikipedia.org/wiki/Network_socket

Device driver (Wikipedia)
http://en.wikipedia.org/wiki/Device_driver

DenyoNet (Konamiman blog)
http://konamiman.blogspot.com.br/2010/03/denyonet.html

MSX-DOS (Wikipedia)
http://en.wikipedia.org/wiki/MSX-DOS

MS-DOS (Wikipedia)
https://en.wikipedia.org/wiki/MS-DOS

Writing device drivers for MS-DOS (Dr. Dobbs)
http://www.drdobbs.com/writing-ms-dos-device-drivers/184402277

Test Case (Wikipedia)
http://en.wikipedia.org/wiki/Test_case

MSXDUMP (PopolonY2k Rulezz)
http://www.popolony2k.com.br/?p=2125

ConnectionLess communication (Wikipedia)
http://en.wikipedia.org/wiki/Connectionless_communication

Acknowledgment (Data Networks – Wikipedia)
http://en.wikipedia.org/wiki/Acknowledgement_(data_networks)

Old Skool Tech (Sourceforge.net)
http://sourceforge.net/projects/oldskooltech/

MSX Networking

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.

Dessa empreitada surgiu o instant messenger homônimo com suporte a diversos plugins que possibilitam a conexão do PlanetaMessenger.org à diversas redes de IM como, MSN Messenger, Yahoo! Messenger, ICQ (OSCAR), ComVC (RIP), Jabber (XMPP) e AIM, de maneira unificada.

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 :).

PlanetaMessenger.org no Linux Mint
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 internacional atuando 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
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.

UNIX implementation for MSX
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 MSXKonamiMan (Nestor Soriano), desenvolvendo a BIOS, Stack IP (InterNestor Lite) e demais softwares de rede.

ObsoNet original de 2004
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.

TecnoBytes Obsonet caRD
TecnoBytes Classic Computers Obsonet card compatible

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 :).

 []’s
PopolonY2k

Referências na internet

Computer Network (Wikipedia)
http://en.wikipedia.org/wiki/Computer_network

BBS – Bulletin board system (Wikipedia)
http://en.wikipedia.org/wiki/Bulletin_board_system

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

História da Mandic (incluindo o BBS)
https://www.mandic.com.br/empresa/historia/

BDI BBS
http://www.bdibbs.com.br/bdi-bbs/bdibbs

A história do MSX na internet
http://www.marceloeiras.com.br/msxsite/msxint.htm

PlanetaMessenger.org – Universal Messenger
http://www.planetamessenger.org

Instant Messaging (Wikipedia)
http://en.wikipedia.org/wiki/Instant_messaging

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

MSN Messenger (Wikipedia)
http://en.wikipedia.org/wiki/Msn_messenger

Yahoo! Messenger protocol (Wikipedia)
http://en.wikipedia.org/wiki/Yahoo!_Messenger_Protocol

ICQ OSCAR Protocol (Wikipedia)
http://en.wikipedia.org/wiki/OSCAR_protocol

Anuncio do ComVC (UOL)
http://sobre.uol.com.br/ultnot/novidade/noticias/ult31012000066.jhtm

Jabber.org
http://xmpp.org/

XMPP
http://xmpp.org/

AIM Instant Messenger (Wikipedia)
http://en.wikipedia.org/wiki/AOL_Instant_Messenger

Open Source (Wikipedia)
http://en.wikipedia.org/wiki/Open_source

FlightGear
http://www.flightgear.org/

MSX Resource Center
http://www.msx.org

NoWind – Interface USB MSX/PC (PopolonY2k Rulezz)
http://www.popolony2k.com.br/?p=160

Gradiente
http://www.gradiente.com/

JoyNet (MSX Assembly Pages)
http://map.grauw.nl/resources/joynet/

Network interface controllers (Wikipedia)
https://en.wikipedia.org/wiki/Network_interface_controller

Wi-Fi (Wikipedia)
http://en.wikipedia.org/wiki/Wifi

8bit computers (Wikipedia)
https://en.wikipedia.org/wiki/8-bit

MSX Network Interface (Google web cache)
http://webcache.googleusercontent.com/search?q=cache:http://www.techborder.com/projects/MSXNIC/ReportMSX_Ethernet.html

UZIX (Sourceforge.net)
http://uzix.sourceforge.net/

Multi-Tasking (Wikipedia)
http://en.wikipedia.org/wiki/Multi-tasking

OBSONET (MSX Resource Center)
http://www.msx.org/articles/obsonet

Konamiman’s MSX page
http://www.konamiman.com/msx/msx-e.html

InterNestor Lite (KonamiMan’s web page)
http://www.konamiman.com/msx/msx-e.html#inl2

TecnoBytes Classic Computers
http://www.tecnobytes.com.br/

Análise da Interface ATA IDE – TecnoBytes (PopolonY2k Rulezz)
http://www.popolony2k.com.br/?p=409

OptoNet Card website
http://www.optotech.net.br/fzanoto/msx.htm

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