Senta que lá vem história

Como todo bom gamer, não me contento em socar o último chefe e sair falando na escola (hoje em dia é twiter, né?) “ZEREI/TERMINEI/FECHEI MAIS UM JOGO”. Pq? A mágica está nos detalhes! Os detalhes que muitas vezes não percebemos quando jogamos pela primeira vez. Aquele canto que não serviu pra NADA durante o jogo, mas que estava lá para ser explorado.

Qual apaixonado por games que terminou Super Mario World e não fez questão de conseguir os 100%? Ou quis passar todas as fases do “ESPECIAL” que não tinham relação alguma com o final do jogo?

Quem já jogou The Legend Of Zelda: Ocarina Of Time e não quis pegar as 100 gold skultullas mesmo sabendo que os rupees ilimitados (que vc tem direito ao final da quest) não valem o esforço?

Mesmo sentindo ausência da mágica nos jogos atuais, ainda não consigo “aposentar” um jogo logo após terminá-lo.

Atualmente faço questão de TER o video-game para poder jogá-lo (adquiri um Super Nintendo recentemente e já estou cotando um Megadrive), mas é impossível comprar todos os cartuchos, até pq alguns nem são comercializados hj em dia (Atari, Nintendinho etc). Então, como todo gamer que possui um computador e sabe da existência dos emuladores (ZSNES!), baixei muitos jogos e terminei cada um deles.

Antes de continuar, queria deixar claro que não sou a favor da pirataria, apesar não ser completamente contra (tudo é relativo…).

Quem conhece um, sabe que a maior virtude do programador é a curiosidade. É claro que não fiquei apenas no “Load Rom/Save State/Load State” do ZSNES. Com o tempo fui descobrindo cada funcionalidade e o que me chamou a atenção foram os códigos que podiam ser inseridos para modificar a jogabilidade ou algum estado do jogo. Testei centenas de códigos em dezenas de jogos e chegou uma hora que não tinha como não me perguntar: como um código esquisito daquele (na época eu não sabia o que era base hexadecimal) podia fazer tanto “estrago” no jogo? E eu sabia que não podia ser nada projetado/previsto pelos programadores do jogo, pois não eram códigos digitados no controle (como uma sequencia de botões), ou inseridos no menu “cheat”.

Nesa fase, fiquei apenas na curiosidade mesmo, pois o material online sobre o asusnto era escasso e meu acesso à internet, mto raro. Tempos depois, qdo comprei o jogo Diablo (o 1 mesmo) e descobri que era possível jogar com outras pessoas na internet, passei várias madrugadas (contava os minutos antes das 00:00h para poder conectar) jogando com os, como diria o bomba, “amiguinhos virtuais“. Até que um gringo filho de uma borboleta entrou na minha “sala“, zerou todos meus stats e removeu todos os meus itens. Não que eu não tenha chutado o cachorro por isso, mas ao passar o susto (raiva, ódio e outros sentimentos sem nome), fui procurar saber sobre códigos/trapaças para Diablo (o termo cheater era novidade pra mim). Qual não foi minha surpresa ao descobrir que o tal programinha BoBaFeTT’s Diablo Trainer podia editar, não só os stats e itens, como podia acrescentar itens que nem mesmo existiam no jogo. Aquela curiosidade sobre como funcionavam os códigos no emulador ZSENS voltou repentinamente, somada ao incrivel fato de poder adicionar elementos que o jogo não possuia originalmente. Devo ter ficado uns 2 dias sem dormir para poder testar todas as opções e armas.

[OFF] Btw, até hj não sei se desligaram os servidores de Diablo I ou se me baniram da Battle.net mesmo u.u [/OFF]

Como nesse tempo eu já havia começado a programar, eu sabia que os stats, pontos de vida e mana estavam armazenados em variáveis e que o cheater, de alguma forma, alterava essas variáveis. Mas também não passou disso, pois muitos conceitos importantes ainda não me eram claros. Como um processo consegue “modificar” a memória de outro?

Então comecei a estudar o comportamento de outros cheaters, como o editor de saves de pokemon para gameboy, ou um executável modificado do jogo freecell que permitia mover qualquer carta para qualquer lugar. Cada um deles funcionando de uma forma diferente.

Aí, veio um amigão da escola e me convenceu de que eu só ia conseguir fazer esse tipo de coisa quando eu programasse fluentemente em Assembly e pudesse fazer qlq coisa em C. O que NÃO é verdade!!!

Depois disso, só voltei a me interessar pelo assunto uns 5 anos depois.
Em 2004 ou 2005 (não lembro) criei copiei e compilei um cheater em Visual Basic 6 para um MMORPG-modinha da época. Como eu apenas modifiquei alguns fontes que peguei na internet, não entendia completamente o que estava acontecendo. Ao ler artigos sobre o assunto e estudar o fonte, entendi que o código simplesmente modificava alguns dados que estavam armazenados na memória utilizada pelo jogo… há! é assim que aquele maldito bobafeet funcionava então!

Passou um tempo, o cheater já estava famoso aqui na minha cidade e muitas lan-houses passaram a usá-lo. Esses “bons jogadores” sempre pediam para adicionar algum feature, tipo que o cheater possa jogar sozinho enquanto ele vê um video educativo no www.***tube.com. Mas tudo bem, moleques de 12 anos não precisam saber a diferença entre cheater e bot
O final infeliz dessa história eu deixo pra outro post.

Com as atualizações constantes do jogo, eu tb precisava atualizar os endereços de memória modificados pelo cheater, então as coisas começaram a fazer mais sentido. Utilizava o ArtMoney pra escanear a memória do jogo e atualizava a lista de endereços, coisa simples. Nesse processo de escanear e procurar novos endereços, comecei a perceber que vários outros locais armazenavam informações úteis para futuras funções do cheater. E com toda a curiosidade que um programador deve ter, fucei em cada canto do jogo para descobrir mais sobre o funcionamento do mesmo.

E meu cheater?

Pra que serviu toda essa lengalenga? Pra deixar claro que não adianta copiar e compilar os códigos postados aqui. Talvez vc consiga fazer um cheater lecalzinho pra algum jogo, mas só isso. Pra aprender, vc PRECISA ter a curiosidade. A curiosidade matou o gato, mas ensinou ele a utilizar mto bem as outras 6 vidas.

Então, no próximo post vou tentar passar o pouco que sei sobre o tipo de cheater que eu considero mais fácil: os que editam a memória.

Para quem não sabe, Boost.Asio é uma biblioteca multiplataforma (cross-platform) para programação de rede/comunicação (network) e operações de entrada e saída em baixo nível (low-level I/O) que oferece, aos desenvolvedores, um modelo consistente e assíncrono.

(Essa definição foi descaradamente traduzida da encontrada no site oficial)

Então, o que eu posso fazer com isso?

Você pode, por exemplo, usar sockets (TCP, UDP e ICMP), Timers e criar/manipular portas seriais.

Mas eu sei fazer isso! É só incluir o winsock.h e… no linux é fácil tb…

Não ter que se preocupar com o startup e cleanup do Winsock e não ter que colocar 8463763 #ifdef’s no meio do código já é um bom motivo para usar Boost.Asio. Se vc escrever “socket.read_some(…);“, vai funcionar em qualquer plataforma suportada (Win32/64, Linux kernel 2.4+, Solaris, Mac OS X 10.4+).

Beleza! Cadê os exemplos?

Antes disso, para não ficar perdido, é necessário entender como o Boost.Asio trabalha. Ao inves de oferecer um modelo genérico aproximado ao que há de comum entre as várias plataformas, a biblioteca apresenta uma nova proposta: para efetuar operações de entrada e saída seu programa precisa de, no mínimo, um objeto io_service (boost::asio::io_service). O objeto io_service funciona como um intermediário entre o seu software e o sistema operacional. Overhead? Tenha certeza que o boost faz esse intermédio da forma mais eficiente possível e, até hoje, nunca vi ninguém reclamando sobre o desempenho da biblioteca. A imagem abaixo (que foi retirada do site oficial) mostra o funcionamento do Boost.Asio para operações síncrona:

1 – O programa inicia a conexão chamando o objeto i/o (socket, por exemplo);

2 – O objeto i/o encaminha a requisição de conexão para o objeto io_service;

3 – O objeto io_service faz uma chamada ao sistema operacional para realizar a conexão;

4 – O sistema operacional retorna um resultado para o objeto io_service;

5 – O objeto io_service “traduz” qualquer erro resultante na operação e retorna ao objeto i/o;

6 – O objeto i/o retorna o resultado para o programa.

.

.

.

.

.

O modelo para operações assíncronas é representado pelo diagrama ao lado:

Ao invés de esperar cada etapa do modelo síncrono, aqui podemos passar uma função handler que será chamada assim que a operação for concluída, independente da ocorrência de erros.

As três primeiras etapas são praticamente idênticas ao modelo anterior (do ponto de vista do usuário/programador):

1 – O programa inicia a conexão chamando o objeto i/o (socket, por exemplo);

2 – O objeto i/o encaminha a requisição de conexão para o objeto io_service;

3 – O objeto io_service faz uma chamada ao sistema operacional para realizar a conexão;

Após as etapas indicadas, o sistema operacional indica o resultado da operação colocando-o em uma fila que será lida pelo objeto io_service, que por sua vez “traduz” qualquer mensagem de erro e chama a função handler passada como parâmetro pelo programa.

É importante comentar que, para que o objeto io_service possa tratar as tarefas/operações assíncronas pendentes, é necessário chamar io_service::run().

A função io_service::run() retornará assim que não houver mais tarefa assíncronas pendentes.

Okay! Então eu crio um objeto io_service e já era?

Aí é que está a grande maravilha do modelo proposto: usando vários objetos io_service (um em cada thread) e dividindo as operações entre eles, permitimos ao sistema operacional também dividí-las entre os vários núcleo disponíveis!

Tá… e os exemplos?

Timer

Para um wait síncrono (só retorna depois de completo):

#include <iostream>
#include <boost/asio.hpp>

using boost::asio::io_service;
using boost::asio::deadline_timer;

int main(int ac, char ** av)
{
    io_service ios;

    deadline_timer t(ios);
    t.expires_from_now(boost::posix_time::seconds(5));

    std::cout << "Esperando 5 segundos..." << std::endl;

    t.wait();

    std::cout << "Continua..." << std::endl;
    return 0;
}

Para um timer assíncrono, precisamos de um handler:

void handler(boost::system::error_code & ec)
{
	if(ec)
		//erro
	else
		//ok
}

Então, podemos usar o wait assíncrono:

t.expires_from_now(boost::posix_time::milliseconds(400));
t.async_wait(handler);
ios.run();

Um exemplo de timer assíncrono:

#include <iostream>
#include <boost/asio.hpp>
#include <boost/bind.hpp>

using boost::asio::io_service;
using boost::asio::deadline_timer;

void handler(int segundo, boost::system::error_code & ec)
{
	if(!ec)
		std::cout << "Esperando... " << segundo << std::endl;
}

int main(int ac, char ** av)
{
	io_service ios;

	for(int i = 1; i <= 5; i++)
	{
		deadline_timer * t = new deadline_timer(ios);
		t->expires_from_now(boost::posix_time::seconds(i));
		t->async_wait(boost::bind(&handler, i, boost::asio::placeholders::error));
	}

	ios.run();

	std::cout << "Continua..." << std::endl;
	return 0;
}

Repare que não me preocupei em manter uma referência para os objetos criados dinamicamente (para apagá-los posteriormente), pois o programa é terminado logo após o retorno do último timer assíncrono.

Socket

Um exemplo simples de socket (tcp) que se conecta ao site:

#include <iostream>
#include <boost/asio.hpp>

using boost::asio::io_service;
using boost::asio::ip::tcp;

int main(int ac, char ** av)
{
    io_service ios;

    tcp::socket sck(ios);
    tcp::endpoint endp(boost::asio::ip::address::from_string("64.191.3.101"), 80);

    try
    {
        sck.connect(endp);
        std::cout << "Conectado!" << std::endl;
    }
    catch(boost::system::system_error & error)
    {
        std::cout << "Erro ao conectar: " << error.what() << std::endl;
    }

    std::cout << "Continua..." << std::endl;
    return 0;
}

Ou um resolver:

#include <iostream>
#include <boost/asio.hpp>

using boost::asio::io_service;
using boost::asio::ip::tcp;

int main(int ac, char ** av)
{
    io_service ios;

    tcp::resolver resolver(ios);
    tcp::resolver::query query("blog.delarco.com.br", "http");
    tcp::resolver::iterator iter = resolver.resolve(query);
    tcp::resolver::iterator end;

    while (iter != end)
    {
        tcp::endpoint endpoint = *iter++;
        std::cout << endpoint << std::endl;
    }

    return 0;
}

Para testar um loop distribuído, resolvi criar uma função que calcula a multiplicação entre duas matrizes, colocando o resultado em uma terceira matriz (MC = MA * MB):

const int MATRIX_SIZE = 1000;

int MA[MATRIX_SIZE][MATRIX_SIZE];
int MB[MATRIX_SIZE][MATRIX_SIZE];
int MC[MATRIX_SIZE][MATRIX_SIZE];

void multi()
{
    int soma;

    //percorre cada linha de MA
    for(int j = 0; j < MATRIX_SIZE; j++)
    {
        //percorre cada coluna de MB
        for(int i = 0; i < MATRIX_SIZE; i++, soma = 0)
        {
            //calcula
            for(int k = 0; k < MATRIX_SIZE; k++)
            {
                soma += MA[j][k] * MB[k][i];
            }

            //coloca resoltado na matriz MC
            MC[j][i] = soma;
        }
    }
}

int main(int ac, char **av)
{
    multi();
    return 0;
}

Como o teste consiste em melhorar o desempenho do cálculo, não me dei ao trabalho de iniciar os elementos das matrizes e nem de verificar se o resultado está correto.

Executando o código anterior, o Code::Blocks retornou a mensagem:

Process returned 0 (0×0)   execution time : 23.509 s
Press any key to continue.

Lembrando que executei a compilação debug sem nenhum tipo de otimização. Com certeza a release seria muito mais rápida.

Quem lembra das aulas de matemática do colegial, sabe que o cálculo de cada elemento resultante (MC) independe do cálculo de elementos anteriores. O laço for está de acordo com as restrições impostas pela API, então, pq não dividir a tarefa em várias threads?

const int MATRIX_SIZE = 1000;

int MA[MATRIX_SIZE][MATRIX_SIZE];
int MB[MATRIX_SIZE][MATRIX_SIZE];
int MC[MATRIX_SIZE][MATRIX_SIZE];

void multi()
{
    //percorre cada linha de MA
    #pragma omp parallel for
    for(int j = 0; j < MATRIX_SIZE; j++)
    {
        //percorre cada coluna de MB
        for(int i = 0; i < MATRIX_SIZE; i++)
        {
            int soma = 0;

            //calcula
            for(int k = 0; k < MATRIX_SIZE; k++)
            {
                soma += MA[j][k] * MB[k][i];
            }

            //coloca resoltado na matriz MC
            MC[j][i] = soma;
        }
    }
}

int main(int ac, char **av)
{
    multi();
    return 0;
}

Repare que, além do #pragma omp parallel for adicionado antes do primeiro loop, outras mudanças foram feitas para adaptar o código:

• A variável soma foi removida do começo da função e declarada dentro do segundo for, para evitar que seja compartilhada entre as threads;
• Não é mais necessário zerar a variável soma no corpo do segundo for;

Executando o código modificado, obtive o seguinte resultado:

Process returned 0 (0×0)   execution time : 7.129 s
Press any key to continue.

Isso corresponde a, praticamente, um terço do tempo necessário para calcular pelo método tradicional. Surpreso? Requisitando 20 threads para executar o loop, obtive um resultado melhor ainda:

Process returned 0 (0×0)   execution time : 6.692 s
Press any key to continue.

Okay, a diferença não é gritante, mas num sistema onde o desempenho é um faor crítico, esses ms podem fazer toda a diferença.

Agora que vc já conseguiu compilar o “Hello World” do primeiro post, vamos fazer bom uso do processamento distribuído nos nossos laços da repetição.

Primeiramente, vc deve entender que, na programação com OpenMP, temos variáveis (parte da memória) compartilhadas e privates.

Quê?!

No exemplo abaixo, a variável a é visível para todas as threads que executarão a tarefa do bloco. Já a variável b possui uma cópia exclusiva em cada thread, ou seja, cada thread possui sua variável b.

void some_function()
{
    int a = 0;

    #pragma omp parallel
    {
        int b = 1;
    }
}

Okay, entendi… e daí?

Por enquanto, leve em conta que saber disso pode evitar várias dores de cabeça.

Usando OpenMP nos laços de repetição

Para tal operação, definimos a seguinte linha antes do nosso for:

#pragma omp parallel for

Ficando assim:

#pragma omp parallel for
for(int i = 0; i < 10; i++)
{
    printf("iteration %d on thread %d\n", i, omp_get_thread_num());
}

O resultado é:

Nesse exemplo, as iterações do for serão divididas em várias threads (na minha execução, 3 threads). O número de threads corresponde ao número padrão ou o valor que vc definiu com omp_set_num_threads(num_threads). Para não ter o trabalho de chamar a função em cada parte do código que vc deseja alterar o número de threads, a seguinte sintaxe é permitida:

#pragma omp parallel for num_threads(NUM_THREADS)

Onde NUM_THREADS corresponde ao número de threads que devem executar a tarefa.

Se o exemplo anterior for modificado para:

#pragma omp parallel for num_threads(2)
for(int i = 0; i < 10; i++)
{
    printf("iteration %d on thread %d\n", i, omp_get_thread_num());
}

Então o loop vai ser dividido em, no máximo, duas threads como mostra o resultado:

Como podemos notar, apenas as threads de ID 0 e 1 executam o for.

Repare que as iterações não são executadas em ordem, então leve em conta que se uma iteração depende de outra, como na soma de médias num vetor de alunos, por exemplo (existe um jeito de fazer isso, vou explicar mais pra frente), vc terá problemas.

A API OpenMP impõe  as seguintes restrições no uso de loops paralelos:

1. A variável que controla o loop (no caso anterior, i) deve ser do tipo signed integer;
2. A operação de comparação no corpo for deve ser do tipo loop_variable <, <=, >, >= integer_invariável;
3. A terceira expressão do corpo for deve ser do tipo que incrementa (x++) ou decrementa (x- -);
4. Se a operação de comparação usar os operadores < ou <=, então a variável de controle deve ser incrementada a cada iteração. No caso contrário, se forem utilizados os operadores > ou >=, então a variável de controle deve ser decrementada a cada iteração;
5. O loop deve consistir em um único bloco de código, sem jumps (goto, por exemplo) para fora do loop. Como exceção, podemos usar exit() que finaliza a aplicação e não apenas a thread em questão. Caso vc utilize um break ou goto, esses devem levar a algum lugar DENTRO do loop e não fora. O mesmo vale para exceptions, que devem ser tratadas dentro do loop e não fora dele;

Para deixar mais claro aquele conceito de memória compartilhada e private, temos o exemplo abaixo que não é válido, pois a variável temp é compartilhada por todas as threads, ou seja, enquanto a thread de ID 0 escreve um valor X e espera ler esse valor algumas instruções adiante, a thread de ID 1 escreve um valor Y no mesmo endereço de memória:

int a[4] = {1, 2, 4, 8};
int temp;

#pragma omp parallel for
for(int i = 0; i < 4; i++)
{
    temp = a[i];
}

Para um resultado correto, o ideal seria declarar a variável temp dentro do laço for:

int a[4] = {1, 2, 4, 8};

#pragma omp parallel for
for(int i = 0; i < 4; i++)
{
    int temp;
    temp = a[i];
}

Reductions

Nos permite compartilhar uma variável sem que sua integridade seja comprometida pela concorrência entre threads. Veja o exemplo:

int notas[10] = {7, 4, 8, 3, 6, 9, 10, 1, 2, 5};
int soma = 0;

#pragma omp parallel for
for(int i = 0; i < 10; i++)
{
    soma += notas[i];
}

printf("soma = %d\n", soma);

Não podemos garantir que a soma seja 55, pois todas as threads estão usando a mesma variável. Criar um lock? Não é necessário, pois a API nos permite fazer da seguinte forma:

int notas[10] = {7, 4, 8, 3, 6, 9, 10, 1, 2, 5};
int soma = 0;

#pragma omp parallel for reduction(+:soma)
for(int i = 0; i < 10; i++)
{
    soma += notas[i];
}

printf("soma = %d\n", soma);

Nos bastidores, o OpenMP cria uma variável private soma para cada thread e, ao final, soma todas e coloca o valor na variável compartilhada (global) soma. Então vc pode ter certeza que o valor de soma é o esperado.

As outras operações disponíveis são:

• + (adição): a variável private inicia com o valor 0;
• - (subtração): a variável private inicia com o valor 0;
• * (multiplicação): a variável private inicia com o valor 1;
• & (operador AND): a variável private inicia com o valor ~0;
• | (operador OR): a variável private inicia com o valor 0;
• ^ (operador OR exclusivo): a variável private inicia com o valor 0;
• && (operador condicional AND): a variável private inicia com o valor 1;
• || (operador condicional OR): a variável private inicia com o valor 0;

A segunda parte eu deixo para outro post

Quem nunca teve vontade de ver um software próprio (nem que seja um “Hello World”) rodando num console de verdade ou mesmo num emulador?

Em 2007 me interessei pelo assunto, particularmente em relação ao PS2 e comecei a pesquisar. Em um ou dois dias, já tinha um “Hello World” rodando pelo pendrive e… bom, desisti de fazer algo realmente útil. Não pela dificuldade ou preguiça de ler sobre o hardware-alvo, mas pelo simples fato de que eu não tinha nenhuma proposta inovadora. Se vc levar em conta a enorme quantidade de homebrews disponíveis, vai chegar à mesma conclusão, ou então vai pensar: há! vou fazer um jogo ultra-mega-blaster-fodástico! E duas horas depois vai desistir, pq as ferramentas FREE disponíveis não são tão user friendly quanto vc gostaria (ou comparadas às oficiais, que podem custar seu rim esquerdo).

Esse é o meu ponto de vista, mas se vc acha que vale à pena programar para um console de quase 10 anos, pode começar fuçando nas minhas principais referências para esse post:

• http://ps2dev.org/
• http://ps2dev.ofcode.com/
• http://lukasz.dk/

Recomendo a última referência, pois você encontrará muito material útil (uma ótima introdução à arquitetura do console, exemplos e até um port de doom para PS2).

Beleza então, meu cadê o Hello World?

Para começar a brincar com o seu PS2, primeiro será necessário baixar o PS2SDK no site http://ps2dev.ofcode.com/. Lá vc encontrará duas opções:

• PS2sdk Win32 Full Installation: contém o compilador (GCC) e as bibliotecas que fornecem as funções básicas para acessar a maioria dos  dispositivos e funções do console;
• PS2sdk Win32 Full + ofcode libs: possui tudo que o item anterior dispõe, com a adição de algumas bibliotecas extras E alguns utensílios que serão úteis na hora de testar seu homebrew (pcsx2, que é um emulador de PS2 para PC e o cdgen, que é utilizado para gerar ISO’s que rodem no seu console).

Levando em conta a diferença entre o tamanho dos instaladores, é claro que você vai baixar o segundo item, clicando aqui.

Instalando o PS2sdk

Okay, você baixou o arquivo, ele possui 44.0 MB e não está corrompido, correto? Creio que qualquer pessoa com uma experiência mínima em computadores (que saiba ligar, por exemplo) consiga instalar. Por via das dúvidas:

• Execute o instalador e escolha a língua. Eu prefiro inglês
• Clique em “Next” e selecione a opção “Full”, então, “Next”
• Selecione o local de instalação e clique em “Install” e, ao finalizar a instalação, em “Finish”
• Agora, abra o arquivo ps2setup.bat (que está no diretório de instalação do PS2sdk) com o bloco de notas e adicione um “cmd” ao final, ficando assim

Compilando os exemplos do PS2SDK

Executando o ps2setup.bat com um duplo clique fará um prompt de comando surgir. Através desse prompt podemos compilar alguns exemplos que são instalados com o SDK. Entre no sub-diretório ps2sdk\samples (creio que vc sabe alguns comandos básicos do DOS) e escolha seu exemplo. Para começar, o exemplo mais simples: hello! Então, entre no sub-diretório hello (diretório_de_instalação_\ps2sdk\samples\hello) e digite “make” (sem aspas).

Se tudo ocorrer bem, um arquivo hello.elf (um hello.o também) deve ser criado dentro do diretório hello. O .elf é o seu executável!

Uhull! Já tenho meu Hello World no hello.elf!!! Tá… mas o que eu faço com isso?

Testando seu homebrew

Existem várias maneiras de rodar seu .elf. Meu PS2 foi desbloqueado com um DMS4 Pro, que não faz p**** nenhuma, mas com o ToxicOS instalado, permite “navegar” em todos dispositivos de armazenamento (DVD, CD, pendrive, memory card etc) e executar qualquer software que você tenha gravado:

Screen inicial do ToxicOS:

Opções:

Acessando o dispositivo mass (storage):

Então, se vc possui um modchip que permita tal operação, grave o hello.elf no seu pendrive e execute no seu PS2. No meu caso, comecei testando o exemplo math3d.elf, eis o resultado:

Se vc não faz idéia do que é um modchip e só sabe que seu playstation é destravado, vc pode gravar o homebrew em um CD ou DVD (eu gravei num CDRW e deu certo) para testar. É claro que não vai funcionar se vc gravar o arquivo .elf diretamente na mídia e é para isso que serve o cdgenPS2.exe que está no diretório tools na pasta de instalação do PS2sdk.

Criando uma imagem com o cdgenPS2

Abra o cdgenPS2.exe e arraste o seu .elf para a lista que contém os campos NAME, LBA, SIZE ETC.

Agora clique no botão IMG (o do ícone de CD), dê um nome para o sua imagem e grave num CD.

Okay, vc chegou até aqui mas não possui um PlayStation2 para testar seu homebrew. Então, vc tem a opção de utilizar um emulador.

O emulador PCSX2

Além do cdgenPS2, a pasta tools possui o pcsx2-0.8.1, que é um emulador de PS2 para PC (o melhor, se eu não me engano). O único problema é que ele não vem com uma bios padrão, mas isso é fácil de achar no google ou vc pode ler meu post sobre RAR’s escondidos em JPG’s e baixar ESSA imagem (11 MB) ;x

Ao executar o emulador pela primeira vez, tenha certeza que vc selecionou a bios ocidental mais recente (USA v02.00+). No menu File, selecione a opção “Open ELF File” e escolha o seu .elf. Não sei bem o pq, mas o emulador pede para que vc selecione outro arquivo. Selecione a imagem gerada no cdgenPS2 e o seu Hello World será executado.

Exemplos e homebrews que eu rodei no meu PS2:

graph.elf

snes station

doom

blade (carrega e mostra um modelo .md2)

PS2 Asteroids

Hoje em dia é normal ouvir do vendedor “Esse computador é ótimo! Tem 4 GB de RAM e é um Core Duo!“. Apesar de, na maioria das vezes, a pessoa nem fazer idéia do que diabos é um Core Duo. Mas tudo bem, esse é o papel do vendedor, certo? É claro que qualquer entendido sabe que isso não qualifica o produto como “bom“, longe disso, temos que levar em conta muitos outros detalhes que pessoas que não são da área não entendem.

Com a chegada dos processadores de múltiplos núcleos, o marketing direcionou-se à  esse fator e esqueceu de que memória cache e barramento contam MUITO no desempenho. A maioria das pessoas não entendem, por exemplo, que um processador de 2 núcleos de 2.0 GHz NÃO significa 4.0 GHz ou que um sistema operacional de 32 bits não aproveita as vantagens do hardware de 64 bits.

O que me deixa triste é ouvir esse tipo de  enganação picaretagem de amigos/conhecidos da faculdade ( Tecnologia em Informática com Ênfase em Gestão de Negócios – FATEC Rio Preto). By the way, não quero desmerecer a faculdade, pois devo muito à vários professores que tiveram a paciência de aguentar alunos como eu e o bomba.

Antes de entrar no assunto principal, entenda que não adianta ter um processador com 487564764 núcleos se o software não sabe como utilizá-los, okay?

Como recentemente adquiri um Phenom X3 (é, 3 núcleos) resolvi descobrir como aproveitar todo esse poder. Com uma busca aqui e uma ali (no oráculo), trago o que aprendi.

OpenMP?

O OpenMP (Open Multi-Processing) é uma API aberta para programação paralela. De acordo com o site oficial:

A API OpenMP auxilia na programação multiplataforma, paralela e com memória compartilhada em C/C++ e Fortran em todas as arquiteturas, incluindo plataformas Unix e Windows NT. Constituída por um grupo de grandes empresas de hardware e software, o OpenMP é um modelo portável e escalável que oferece ao programador uma interface flexível para o desenvolvimento de aplicações paralelas visando desktop até supercomputadores.

A tradução no olhômetro ficou um lixo, mas dá pra ter uma idéia do que se trata.

Beleza, nunca ouvi falar. Vale a pena alocar recursos (tempo) para aprender?

Saiba que essa API (pelo menos a especificação) existe desde 1997, sendo os membros permanentes do Architecture Review Board (ARB):

• AMD (David Leibs)
• Cray (James Beyer)
• Fujitsu (Matthijs van Waveren)
• HP (Uriel Schafer)
• IBM (Kelvin Li)
• Intel (Sanjiv Shah)
• NEC (Kazuhiro Kusano)
• The Portland Group, Inc. (Michael Wolfe)
• SGI (Lori Gilbert)
• Sun Microsystems (Nawal Copty)
• Microsoft (-)

(Retirado do site oficial)

Convencido(a)?

Instalando o OpenMP

É simples, você não instala.

Como assim?

Você DEVE ter um compilador que tenha o OpenMP implementado.

E o meu compilador implementa?

Aqui vc pode ver a lista de compiladores que disponibilizam o recurso. Como, provavelmente, vc usa:

• Visual C++ 2008: apenas a versão Professional (ou sei lá o nome da versão que não seja a Express) possui os headers necessários. ACHO que se vc copiar os headers da versão paga para a Express, irá funcionar;
• Code::Blocks (MinGW): apenas nas versões (do gcc) 4.3.2 ou superiores.

Baixei o MinGW mais recente no site oficial e instalei para usar com o Code::Blocks. Porém, a versão do gcc era a 3.4.alguma-coisa e é claro, não funcionou pois não possuia os headers necessários.

Então, resolvi instalar logo o TDM’s GCC/MinGW que é uma build não oficial dos binários mais recentes do GCC. Faça o download do instalador mais recente e, na hora da instalação, escolha o diretório MinGW que está dentro do diretório de instalação do seu Code::Blocks (no meu caso, E:\CodeBlocks\MinGW):

Clique em “Next >” e selecione um mirror:

Clique em “Next >” e selecione apenas os componentes que deseja instalar. No meu caso, deixei como está (todos):

Após selecionar os componentes, clique em “Install” e espere a extração dos arquivos terminar.

Hello World!

Se tudo estiver certo, então será possível compilar o “Hello World” abaixo:

#include <omp.h>
#include <stdio.h>

int main()
{
#pragma omp parallel
printf("Hello! (from thread %d, num. threads %d)\n",
omp_get_thread_num(),
omp_get_num_threads());
}

Antes de tentar rodar o exemplo, precisamos definir a compile-time flag -fopenmp para que o compilador saiba que o projeto utiliza o OpenMP. Se vc compilar pelo prompt de comando diretamente com o GCC, basta adicionar o parâmetro -fopenmp, ficando assim:

gcc.exe hello_world.c -o hello_world.exe -fopenmp

Já no Code::Blocks, vc também precisa linkar a libgomp.dll.a e ter o arquivo libgomp-1.dll na pasta BIN do seu compilador ou na pasta do seu projeto. Então, faça assim:

• Selecione a opção “Build options…” no menu “Project” do Code::Blocks;
• Na lista da esquerda, selecione o seu projeto (o 1º item, não o Debug, nem o Release);
• Procure a aba “Other options” dentro da aba “Compiler settings”. Adicione a flag -fopenmp;
  
• Agora selecione a aba “Linker settings” e adicione o arquivo libgomp.dll.a. Na minha instalação, esse arquivo estava no diretório “E:\CodeBlocks\MinGW\lib\gcc\mingw32\4.4.1\“;
• É importante que vc linke o arquivo libgomp.dll.a e não o libgomp.a;
• O projeto já pode ser compilado, mas para que funcione, será necessário copiar o arquivo libgomp-1.dll para o diretório do seu executável. Assim como a lib, o diretório em que esse arquivo pode ser encontrado não é tão trivial. Na minha instalação, encontrei em “E:\CodeBlocks\MinGW\lib\gcc\mingw32\bin“;
• Creio que não é necessário explicar a parte de copiar o arquivo (CTRL + C, CTRL + V, a mesma coisa que vc usa para fazer os trabalhos da faculdade).

Btw, GOMP é o projeto que implementou o OpenMP nos compiladores C, C++ e Fortran do GNU Compiler Collection.

Pronto, o Hello World deve (ou deveria) mostrar algumas mensagens “Hello!” com o ID da thread em que está sendo executado, seguido do número de threads. Aqui tive o seguinte resultado:

Mas por que 3 threads? Porque esse é o número padrão para a variável ambiente OMP_NUM_THREADS (na minha implementação, pelo menos). Para definir o número de threads, chame a função omp_set_num_threads(num_threads). Então, o “Hello World” modificado ficaria assim:

#include <omp.h>
 #include <stdio.h>

 int main()
 {
 omp_set_num_threads(10);

 #pragma omp parallel
 printf("Hello! (from thread %d, num. threads %d)\n",
 omp_get_thread_num(),
 omp_get_num_threads());
 }

Agora vc verá 10 mensagens “Hello!”.

É só isso?

Não. Apesar de simples, o exemplo anterior usa eficientemente todos os núcleos disponíveis, de forma transparente. Pode parecer que não houve um grande ganho no desempenho, mas com alguns testes vamos ver que a programação multicore pode otimizar de forma significativa o aplicativo.

Para que o post não fique cansativo, deixo o resto para semana que vem.

Fonte: OpenMP.org

3.17 KB

76.9 KB

Aparentemente só o tamanho, mas ao abrir a segunda imagem com o WinRAR, vc vai encontrar algo além do italiano bigodudo.

Como isso é possível? Coisa mais simples do mundo:

Que jogar um monte de bytes (arquivo) no final de outro monte de bytes (outro arquivo) é possível, tudo bem, todo mundo já sabia. O que eu não sabia era que o WinRAR conseguia achar o trecho compactado sem saber exatamente onde ele começa. Com certeza deve existir alguma flag que indica onde fica esse trecho. Okay, deixo a parte nerd do post para outra hora.

Tá, legal… e dái?

Veja bem, isso não serve pra p**** nenhuma, certo? Errado!
A internet é uma terra sem lei, mas algumas pessoas insistem em tentar controlar o que vc faz ou deixa de fazer. Então, alguma mente desocupada teve a, diga-se de passagem, ótima idéia de camuflar conteúdo ilegal em imagens inocentes e hospedar em um desses serviços de armazenagem grátis (como o imageshack.us).

Pode não parecer muita coisa, pois vc baixa seus filmes educativos por torrent, mas com os grandes trackers indo pro saco uma hora a festa acaba (ou fica mais difícil de arrumar convite).

Okay, vc tá dizendo que eu posso baixar Doom 4 camuflado num JPG? É impossível ter um JPG de 10+ GB hospedado, qualquer imbecil vai perceber que não se trata de uma imagem.

Correto, mas e se esses GB’s fossem divididos em pequenas partes de, vamos supor, 2 MB cada… e cada uma dessas partes fosse hospedada como uma imagem diferente? No final, só será necessário “juntar” os pedaços para assistir o novo episódio de House.

É claro que um software gerenciando tudo isso deixaria as coisas mais fáceis, mas não conheço nenhum =/
Por isso comecei um projeto simples (iShare, em C#) que faz o básico:

• Divide o arquivo-alvo em quantas partes de tamanho Y (especificado pelo usuário) forem necessárias;
• Adiciona uma imagem random no começo de cada parte;
• Armazena as imagens em algum serviço online, ou disco virtual;
• Cria uma lista de links para as imagens que compõem o arquivo-alvo;
• Baixa as imagens;
• Remove as imagens, deixando só as partes;
• “Junta” as partes.

Pena que parei com o projeto antes de terminar os itens listados em vermelho. Se houver interesse, posto o source pra quem quiser terminar.

Para quem for utilizar essa técnica, uma dica é utilizar o Wordpress, fiz um teste a um ano e a imagem de 7.5 MB está lá até hoje. Quem quiser testar, baixe essa imagem (clique com o botão direito e em Salvar link…), depois tente abrir com o WinRAR.

Enfim, como faço a gambiarra?

O modo mais simples é:

• Copie a imagem que vc deseja usar para camuflar o seu RAR para seu C:\
  
• Copie seu RAR que será camuflado para seu C:\
• Escolha um nome para a imagem que será criada contando o RAR (gambiarra.jpg ou gambi.jpg, para os íntimos)
• Abra o menu Iniciar e clique em Executar e digite “cmd”, sem aspas
• Clique em Ok e um prompt de comando aparecerá
  
• Digite: copy /b c:\<sua_imagem.jpg> + c:\<seu_rar.rar> c:\gambi.jpg

No case, se sua imagem original tem o nome A.JPG e seu RAR tem o nome B.JPG, ficaria: copy /b C:\A.JPG + C:\B.RAR C:|GAMBI.JPG

Para quem programa em C:

#include <stdio.h>

int main(int ac, char ** av)
{
    FILE *jpg, *rar, *out;
    char c;

    jpg = fopen("./arquivo.jpg", "rb");
    rar = fopen("./arquivo.rar", "rb");
    out = fopen("./imagem.jpg",  "wb");

    while(!feof(jpg))
        fputc(fgetc(jpg), out);

    while(!feof(rar))
        fputc(fgetc(rar), out);

    fclose(jpg);
    fclose(rar);
    fclose(out);
}

Ou para quem programa em VB (5 ou 6):

sub main()

Dim f1() As Byte
Dim f2() As Byte

Open ".\arquivo.jpg" For Binary As #1
ReDim f1(LOF(1))
Get #1, , f1
Close #1

Open ".\arquivo.rar" For Binary As #1
ReDim f2(LOF(1))
Get #1, , f2
Close #1

Open ".\imagem.jpg" For Binary As #1
Put #1, , f1
Put #1, , f2
Close #1

Por enquanto, para músicas e ROM’s de Super Nintendo, funciona muito bem