Guru Meditation: Amiblitz – Parte 4: Pong

PARTE 4

Posts anteriores sobre esse assunto:

• Parte 1
• Parte 2
• Parte 3

Salve pessoal!

E lá vamos nós, a todo vapor, para a quarta parte de nosso “mini-curso”.  Nesse post vamos fazer um esboço do famoso jogo Pong! Dessa vez vou começar de forma diferente. Primeiro vou postar um vídeo do jogo rodando para em seguida explicar e analisar as linhas de código.

Pong

Agora que vocês já assistiram ao vídeo, vamos à algumas considerações:

O objetivo do post é demonstrar algumas técnicas e facilitar o aprendizado de quem está querendo se aventurar no AB. Não pretendo publicar o jogo completo. Seriam muitas linhas de código, tanto para eu programar, quanto para explicar, algo praticamente inviável. O importante é aprender o conceito, pegar as dicas e depois continuar com as próprias pernas, ou melhor, com as próprias mãos :-D.

Outro ponto que vale a pena mencionar é quanto a aparência dos exemplos que tenho postado. Mais uma vez não estou muito preocupado com isso. Repito, o importante é o conceito. E não pense que só dá pra fazer esses jogos com baixa resolução com o AB! É possível criar jogos em alta-resolução, AGA e até para placas RTG.

Sobre o jogo

O Pong dispensa apresentações. Nesse exemplo, algumas funcionalidades não estão implementadas, como a parte de pontuação, efeitos sonoros, níveis de dificuldade entre outros detalhes menores. Apenas a título de informação, para que fosse possível filmar com uma das mãos e mover os bastões com a outra, tive que diminuir a velocidade da bola, o que deixou o jogo consideravelmente menos divertido (mais do que já é) :-D.

Aprendendo a jogar, quer dizer, a programar…

Esse exemplo pode parecer simples, mas já inclui alguns conceitos interessantes, como o limite da área de jogo e um dos mais importantes: a colisão entre objetos! Colisões?! Sim! Toda vez que dois ou mais objetos da tela se sobrepõem ocorre uma colisão. No nosso exemplo, isso acontece principalmente quando a bola bate (colide) com os bastões. Veremos também como impedir que o bastão saia da tela e como fazer a bola rebater nas bordas superior e inferior da tela.

Vamos ao código!

Mesmo sem implementar o jogo por inteiro, já temos uma quantidade razoável de linhas e por esse motivo precisei dividir a imagem com as linhas de código em duas partes. As linhas que já estão com comentários no código ou com comandos que já vimos nos posts anteriores, eu não vou explicar, a menos que exista algo importante que mereça ser mencionado.

Pong: parte 1/2

LoadPalette

Depois de criar os dois BitMaps, o próximo passo foi carregar as imagens que serão utilizadas no jogo, assim como o arquivo com as informações de cores, ou como são mais conhecidos: Palette. A maioria dos programas gráficos permite que você grave num arquivo as informações sobre as cores da imagem. E foi isso que eu fiz no PPaint depois de desenhar o “campo” de jogo do nosso Pong. Essa Palette (PongPalette.col) foi armazenada sob o índice 0 (zero).

Os arquivos de imagens utilizados no jogo

Usaremos dois arquivos com imagens no nosso jogo. O primeiro, Campo.IFF, é uma imagem de 320×240 para servir de background para o nosso jogo. O segundo arquivo, PongShapes.IFF, contém o desenho da bola e dos bastões. É desse aquivo que serão extraídos os Shapes que logo em seguida são convertidos em Sprites, tudo com uma Palette de apenas 4 cores.

Liberando memória

Depois de carregar as imagens e os Sprites, os arquivos “de origem” não tem mais utilidade. Então com o comando Free, retiramos esses objetos da memória. Em seguida, entramos no modo BLITZ, setamos o Slice e associamos a Palette 0 a ele com o comando Use. Dessa forma as cores, teoricamente  (sim, existem ainda outros fatores que podem atrapalhar),  serão exibidas corretamente durante a execução do programa.

A partir daí até o comando Show, não há qualquer novidade ou bicho de sete cabeças. Apenas atribuições com o devido comentário direto no código.

Pong: parte 2/2

Laço principal

Na segunda parte do código ficaram as coisas mais interessantes. Pra começar, dentro do laço principal, são exibidos os três Sprites nas coordenadas setadas anteriormente. Na sequencia temos o tratamento de movimentação dos bastões. Eu mantive as teclas direcionais para movimentar ambos os bastões. Calma! Eu seu que você achou isso esquisito, mas foi uma forma que achei de conseguir movimentá-los com apenas uma das mãos e conseguir filmar ao mesmo tempo pra fazer o vídeo do início do post :-D. Numa versão “final”, as teclas de movimentação deveriam ser escolhidas com um pouquinho mais critério :-D, ou ainda, prever a utilização de joysticks. Um detalhe que eu esqueci de comentar no post passado, mas também ninguém reclamou ou questionou (será que alguém leu? :-() foi quanto as atribuições. Por exemplo: y1 -2. Esse tipo de comando equivale a: y1=y1-2. Só pra ficar registrado.

Mantendo os bastões dentro da tela

Os quatro IF´s que vêm a seguir, servem pra manter os bastões dentro da tela. Mas por quê y1 >= 210 e não y1 >= 240 (que é o limite da tela)? Se não informarmos nada diferente ao programa, o ponto de referência de um objeto é sempre o canto superior esquerdo do mesmo (existem formas de se alterar isso). No caso dos bastões, se olharmos a criação dos seus Shapes no início do código, eles tem 5 pixels de largura por 30 de altura. Então temos que levar essas medidas em conta sempre que formos comparar a colisão com o lado direito e a parte inferior dos objetos, somando a sua largura e altura respectivamente. Nesse caso especificamente, eu testei se y1 era maior ou igual a 210, que somados aos 30 pixels de altura do bastão, resultam nos 240 pixels da tela e faço o bastão parar de se mover. Já pra testar os limites na margem superior, eu não preciso somar nada, pois o ponto de referência já fica no ponto zero do objeto. O teste fica simples assim: y1 <=0. Por que <=0 e não =0? Por que se eu estiver usando um multiplicador pra mover o bastão mais rápido, pode acontecer dele passar do zero e a condição não será verdadeira e o bastão continuará subindo, o que não é o nosso desejo.

Movimento da bola

xb e yb, como descrito anteriormente, são as coordenadas da bola na tela. Pra saber pra onde a bola vai, temos as variáveis dxb (direção do eixo x: negativo pra esquerda e positivo pra direita) e dyb (direção do eixo y: negativo pra cima e positivo pra baixo). Pra dar uma incrementada, criei ainda as variáveis vxb e vyb, que representam a velocidade (ou o passo) com que a bola se movimentará.

O IF a seguir (if xb>=320 OR xb<=0), serve para verificar se a bola passou dos limites da tela, ou seja, não foi rebatida. Se isso acontecer,  a bola é recolocada em jogo, a partir do centro da tela e na direção oposta que estava se movendo na hora do “gol”. Se alguém se animar a incrementar o código, aqui seria o local adequado para computar os pontos dos jogadores.

E tome IF…

Vamos analisar o próximo comando: If yb>=235 OR yb <=0 Then dyb*-1. O que ele faz é bem simples, “rebate” a bola toda vez que ela chega na borda superior ou inferior da tela. Isso é feito multiplicando dyb por -1, ou seja, inverto a direção da bola no eixo y sempre que qualquer uma dessas condições for verdadeira.

SpriteHit – rebatendo a bola!

Para implementar rebatida da bola pelo bastão, vamos usar um recurso diferente: SpriteHit. Esse comando verifica a cada ciclo do programa se houve uma colisão entre os Sprites especificados. Por exemplo: SpriteHit(0, xb, yb, 1, x1, y1) vai retornar TRUE, se o Sprite 0, de coordenadas xb, yb (que por um acaso é a bola), colidir com o Sprite 1, de coordenadas x1, y1 (que por um acaso é o bastão 1). Com esse comando (sensacional), tudo que eu preciso fazer é testar se a bola colidiu com um dos bastões e inverter as direções dos eixos x e y da mesma. Simples assim!

Vale ressaltar que SpriteHit só checa colisão de Sprite com Sprite. Existem outras formas de testar colisões de Shapes com Shapes e ainda entre Sprites e Shapes!

Mas isso fica para um próximo post…

Guru Meditation: Amiblitz – Parte 3: Um pouco de interação pra animar!

Posts anteriores sobre esse assunto:

• Parte 1
• Parte 2

Continuando com nosso “mini-curso”, dessa vez vou mostrar um exemplo que vai permitir a interação do usuário com o programa. Será possível movimentar um objeto na tela utilizando as teclas direcionais. Coisa simples, mas que já vai dar “uma luz” aos novos Blitzers (é como o pessoal “das zuropa” chama quem programa nessa linguagem) ;-).

Escolhi essa abordagem de trabalhar com exemplos por achar mais dinâmica e agregar conhecimento de todos os níveis ao mesmo tempo. É possível ver desde uma atribuição simples de um valor à uma variável até a movimentação de um objeto na tela, ao passo que se fosse um curso tradicional estaríamos olhando os tipos de variáveis ou estruturas de repetição, o que provavelmente tornaria o post pouco interessante pra maioria dos leitores.

Vamos ao código do segundo exemplo:

Exemplo – Aula 02

Logo de cara temos o comando BitMap que já explicamos no post anterior. Mas dessa vez são dois! O primeiro BitMap terá uma palete de 32 cores (nesse exemplo isso não faz a menor diferença, mas serve para mostrar que posso ter BitMaps com diferente número de cores (falaremos sobre palete de cores mais pra frente) e será o nosso background para o “jogo” (jogo? menos Ritcho, menos… :-D). Como não desenhei nada nesse BitMap, ele aparecerá preto mesmo. Já o segundo BitMap (índice 1), tem uma palete de apenas 4 cores e isso tem uma razão.

LoadBitMap

O comando LoadBitMap, como é de se supor, carrega uma imagem no BitMap, cujo índice foi informado no primeiro parâmetro (no caso, 1). O caminho completo do arquivo vem logo em seguida.

GetaShape

Na linha a seguir, temos o comando GetaShape. Shape é um dos tipos de objetos gráficos que podemos trabalhar no AB. Mas como movimentar um Shape requer um pouco mais de conhecimento, vamos apenas no ater ao que o comando faz: GetaShape i,x,y,w,h literalmente copia um retângulo do BitMap, a partir das coordenas x e y, com largura w, altura h e armazena no Shape de índice i. Neste exemplo, o Shape 0 (zero), vai ser um quadrado de 20 x 20 pixels, iniciando no canto superior esquerdo do BitMap (o,o), extraído da imagem Bola.IFF. Nessa mesma linha, temos um “;” (ponto e vírgula) seguido de um texto livre. Essa é a forma de inserir comentários em um código AB.

Conteúdo do arquivo Bola.IFF no PPaint

GetaSprite

Sprite já nos parece um pouco mais familiar, não é mesmo? Para conseguir um Sprite, precisamos primeiro de um Shape e foi “só” por isso que usamos o comando GetShape anteriormente. Existem algumas técnicas e dicas interessantes que eu aprendi na marra e que aos poucos vou passar pra vocês. Eu já desenvolvi um programa que pega o arquivo com os  as imagens que quero usar no meu “jogo” e ele extrai automaticamente os Shapes e guarda em um arquivo de Shapes (sim, existe isso) ou ainda grava em disco, cada um deles, individualmente. Isso evita que tenhamos que ler um arquivo com o BitMap todo para extrair os Shapes durante o carregamento do jogo. Basta carregar o(s) Shape(s) direto!

Voltando ao GetaSprite

O GetaSprite é bem simples. Os seus únicos parâmetros são os índices do Sprite a ser criado e do Shape de onde ele vai se originar. Apesar de iguais no conteúdo, a forma como são tratados é completamente de diferente.

Lembra que eu falei que tinha um motivo para o segundo BitMap ter apenas 4 cores? E a resposta está no Sprite. Ele só pode ter 4 ou 16 cores (na verdade o BitMap de onde ele for extraído deve ter uma profundidade de cor de 2 ou 4 bits). Então se você tentar extrair um Sprite a partir de um Shape que não tenha essas características de cor, vai dar erro… Depois de criado o Sprite, podemos liberar a memória utilizada pelo Shape. Acabei esquecendo de acrescentar esse comando ao código, mas não faltará oportunidade nos próximos exemplos.

Use BitMap 0

Depois de extrair o nosso objeto para do BitMap 1, podemos “apontar” para o BitMap 0, que é onde o nosso objeto vai se movimentar. E é isso que o comando Use BitMap faz.

BLITZ

Já falamos também sobre o comando BLITZ no post passado, mas aqui cabe um comentário interessante: Reparem que o acesso à disco para carregar a imagem Bola.IFF (LoadBitMap) é executado antes do comando BLITZ. E tem que ser assim! Não é possível acessar o disco depois que executamos o comando BLITZ, já que o sistema operacional fica “desabilitado” a partir desse momento.

BlitzKeys On

Escolhi usar o teclado para mover o nosso personagem “bola”, e para isso ser possível, precisamos habilitar a leitura do teclado através do comando BlitzKeys On.

While…Wend

Depois de uma série de inicializações de variáveis, começa o nosso “laço” principal do programa. Dessa vez optei pelo While..Wend. Existem duas grandes diferenças entre o While e o Repeat (utilizado no exemplo anterior):

No Repeat o teste lógico é feito no final do laço enquanto no While isso é feito no início. Por esse motivo, a segunda diferença é que, com certeza, utilizando o Repeat, os comandos internos ao laço serão executados pelo menos uma vez, enquanto no While isso pode não acontecer.

Dito isso, vamos ver o que temos dentro dessa estrutura de repetição!

ShowSprite

Esse comando exibe o Sprite especificado, no caso o Sprite 0 (zero), nas coordenadas x e y utilizando o canal de Sprite 1. Canal de Sprite??? Mais pra frente falaremos sobre isso com mais detalhes, mas por hora, podemos adiantar que existem 8 canais de Sprites numerados de 0 a 7 e que dentre outras funções, o número do canal utilizado pode influenciar se um Sprite aparecerá sobre ou sob outros objetos. Mas isso não é importante… ainda!

RawKeys

O que temos a seguir é uma série de “IF´s” responsáveis pela movimentação do objeto na tela e mais um “IF” para encerrar o programa. Podemos interpretar o termo RawKey como um código de cada tecla. E é por esse código que vamos nos referir para verificar se determinada tecla foi pressionada.

RawKeys

Por exemplo, a linha de comando If RawStatus($45) Then End, traduzida, seria algo como: Se a tecla ESC (repare na figura acima e compare com o mapa dos teclados abaixo) for pressionada, então, finalize o programa.

Mapa do teclado americano (US)

Mapa do teclado francês (FR)

Mapa do teclado alemão (DE)

Fica fácil então pra entender os outros “IF´s”, que testam as teclas direcionais, cujos códigos são $4C, $4D, $4E e $4F, e somam ou subtraem 1 pixel da coordenada correspondente do Sprite. Simples não é?

VWait

O último comando “novo” do código é o VWait. E ele é muito importante! Quem tiver a oportunidade de testar o código acima, tente executá-lo sem o VWait pra ver o resultado… VWait faz o programa aguardar o chamado “próximo branco vertical”. Esse comando é especialmente importante em animações e jogos, pois ele é responsável por sincronizar as mudanças na tela com a velocidade real de atualização do monitor (“refresh rate”).

Vamos ver como ficou?

Abaixo um vídeo do programinha sendo executado. Pode não parecer muita coisa, mas já vimos o básico para começar um joguinho!

Testando o programa.

Até o próximo post!

Guru Meditation: Amiblitz – Parte 2: Hello Word?! No!

O Amiblitz é uma linguagem de programação compilada e oriunda do Basic. Mas assim como o C e outras linguagens, no Amiblitz nós podemos incluir bibliotecas e rotinas externas e ampliar a gama de comandos e funções. Existe biblioteca pra quase tudo. O AB (vou chamá-lo assim agora pra não ficar toda hora escrevendo Amiblitz) não consegue carregar JPG, somente IFF? Não tem problema. Já existe uma biblioteca que permite isso e muitas outras coisas! Às vezes fico pensando quanta gente louca (mais louca que eu) existe por aí… 😀

Logo que carregamos o AB3, o que vemos é isso aqui:

IDE do Amiblitz3

Um trabalho sensacional… diga-se de passagem. Tem debugger, visualizador de variáveis, editor com várias opções de configuração, help contextual, “autocompletar” pra comandos e funções (um versão simplificada do intellisense) entre outras funcionalidades bem legais!

O modo BLITZ

Apesar de muito se falar sobre o desenvolvimento de jogos quando se pensa no AB, ele é uma linguagem completa, com várias bibliotecas para construir qualquer tipo de programa, inclusive jogos :-D.

Nessa série de artigos que pretendo escrever, vou tentar facilitar a vida de quem está começando. Eu pesquisei bastante, troquei mensagens com a galera da Alemanha (que é uma das mais ativas, porém hoje mais voltada para a produção de jogos e aplicativos para os Amigas NG) e bati a cabeça algumas vezes para conseguir resolver e até entender algumas coisas. E ainda há muito que aprender!

Muitos incrédulos devem pensar: “Como um jogo escrito em Basic pode ficar rápido o suficiente?” Bem, além de compilado, o AB tem um comando interessante (BLITZ), que quando executado, “by-passa” o sistema operacional e acessa diretamente os chips customizados. É isso mesmo, você fala direto com o hardware através de comandos específicos e muitas vezes complexos. Não é possível nem acessar o disco nesse modo (já que isso depende do sistema operacional).

E como as chamadas não passam pelo OS, se você fizer besteira, já sabe o que acontece né? Guru Meditation pra você, principalmente se estiver no AB2. No AB3, eles conseguiram fazer um sistema de recuperação que muitas vezes salva o programador de uma fria. Eu disse muitas vezes, mas nem sempre! A regra básica é, sempre salve o código antes de executá-lo… É possível configurar o AB de forma que ele sempre salve o programa quando você mandar compilar o código.

Vamos ver como isso funciona!

Nada de Hello World! 😉

Vamos a um exemplo prático, só pra dar uma animada, mas nada de Hello World né? Isso pode ser feito com um simples Print (lembre que isso aqui é Basic!). Também não pretendo tratar dos outros modos de criação de programas. Vou focar basicamente na criação de jogos. Esse código funciona tanto no BlitzBasic2, quanto no Amiblitz2 e obviamente no Amiblitz3.

Mas Ritcho… cadê o Hello World?!?!?! Esquece isso rapaz! 😀

Pra compilar e executar é só acessar o menu de compilação ou escolher, por exemplo o atalho A (tecla Amiga direita) + B. Esse atalho, salva, compila e executa o programa.

Agora vamos dar uma olhada no código. Não tem nada de complicado e o efeito é bem interessante.

1. BLITZ – “Liga” o modo Blitz
2. Bitmap 0,320, DispHeight, 5 – Esse comando cria um bitmap com as características que você informar. Nesse caso, o 0 (zero), é o índice desse bitmap (logicamente que você pode ter mais de 1 bitmap). 320 é a largura da tela em pixels. DispHeight é um função que retorna a altura da tela em pixels. Sendo assim você não precisa se preocupar se o Amiga é PAL ou NTSC. Por fim, o 5 informa a “profundidade” de cores: 2^5 = 32 cores. Mais pra frente veremos que o fato da máquina ser AGA ou não influencia muito nesse ponto e em alguns outros. Mas vamos com calma…
3. Slice 0, 42, 5 – Imagine o Slice como sendo uma janela e o bitmap a tela atrás dessa janela. Você só vai ver a parte do bitmap que o Slice permitir. Por exemplo: Você pode ter um background de 1024×252 e um Slice de 320×252, que poderá ser movido lateralmente dando a impressão que o background está se movendo, num Scroll horizontal. Mais uma vez… vamos com calma! O comando Slice tem uma forma simples, que é essa, e uma forma completa que veremos em breve. O 0 (zero) corresponde ao índice do Slice (sim podemos ter mais de um Slice  – jogos multiplayer por exemplo, precisam de um Slice pra cada jogador). O 42 é uma coordenada de hardware (lembre-se que estamos acessando o hardware diretamente, então coisas meio esquisitas como essa vão aparecer pelo caminho) que corresponde ao canto superior esquerdo da tela. Qualquer valor acima disso, desloca o Slice para baixo e vice-versa. Por fim, o 5, assim como no Bitmap, refere-se ao número de cores.
4. Show 0 – Exibe o Bitmap criado (0 é o índice do bitmap).
5. Repeat…Until – Esse “laço” repete todas as instruções, pelo menos uma vez e até que a condição estabelecida seja verdadeira. No caso, JoyB(0)>0 (o botão esquerdo do mouse seja pressionado).
6. A série de comandos RND (randomico), gera aleatoriamente, coordenadas x, y, o tamanho e a cor (c) do quadrado que será desenhado com o comando Boxf.
7. Boxf – Desenha retângulos preenchidos (o f é de fill), nas coordenadas x e y, com largura e alturas e cor (c).

O efeito gerado de vários quadrados sendo desenhados na tela com uma velocidade impressionante é bem legal. Aqui um vídeo com o resultado. A qualidade não está boa, mas dá pra ter uma ideia.

Saída do programa.

Espero que tenham gostado. Pelo menos foi um pouco mais do que um simples “Hello World”.

Fiquem à vontade para enviar comentários, dúvidas e sugestões.

Grande abraço!

UC – A4000 – Finalmente Pronto!

Olá pessoal!

Finalmente terminei o que seria a primeira grande fase de upgrades e customização do A4000. Vou tentar condensar aqui tudo que foi feito. Talvez eu não chegue no nível de detalhe que eu gostaria inicialmente, mas vocês poderão ter uma ideia de tudo que foi feito. E podem ter certeza que muito tempo foi gasto em cada detalhe.

O micro ficou muito tempo desmontado, havia muitas coisas à fazer, faltavam alguns itens e também faltava definir se algumas alterações seriam realmente realizadas. No fim das contas o que acelerou o processo de montagem do A4000 foi o fato de querer utilizar o Amiblitz3. Eu inicialmente pensei em usar em um dos A1200´s. Como eu só estava com um deles montado e a ACA1230 já tinha chegado, instalei o programa e fui tentar executá-lo. Nesse momento descobri a necessidade de MMU/FPU, coisa que a ACA não tem :-/. Eu poderia usar outra aceleradora, mas aproveitei esse contratempo como motivação para montar o A4000. E assim o fiz!

Frente do Gabinete:

A frente do gabinete já estava praticamente pronta. Mas depois que resolvi colocar a ventoinha frontal, era necessário prover uma entrada de ar. Fiz três cortes no gabinete, no mesmo sentido das faixas inferiores. Logicamente que eu não ia deixar o acabamento assim…

Frente do gabinete agora com as entradas de ar.

Lá fui eu, lixar, aplicar primer e pintar a frente novamente. E ainda tive que fazer isso uma terceira vez. Um maldito mosquito posou na frente com a tinta ainda fresca. Coisas da vida… Quem mandou não ter uma estufa :-D.

Depois de furar a frente do gabinete, tive que fazer  tudo de novo. Lixar, aplicar primer e pintar…

Ventoinha frontal instalada. A entrada de ar fica exatamente na direção dessa ventoinha.

A fonte:

Outra modificação que eu fiquei com muita dúvida se levava à frente ou não era quanto ao botão de power. Quem já viu o A4000 por dentro, sabe como é. Quem nunca viu vou tentar explicar. O botão de power tem uma haste de plástico comprida. Quando você aperta o botão, essa haste, pressiona o “switch de power” lá trás na fonte. Como agora a fonte tem um sistema “soft-touch”, como nos PC´s com fonte ATX, resolvi retirar esse botão e usar um também “soft-touch”. Agora pra ligar, é só dar um toque no botão e pra desligar é só segurar o botão por alguns instantes. Existe ainda a opção de desligar o Amiga por um comando via AmigaOS. O sistema foi bem bolado. Como quase ninguém usa uma terceira unidade de disquete (externa obviamente), esse programinha, quando executado no AmigaOS, envia um sinal exatamente para o “pino de referência” da terceira unidade de disco flexível (também conhecido como disquete :-p). Existe agora um fio soldado deste pino para a plaquinha de controle da fonte ATX. Ou seja, esse sinal entra na plaquinha e o programinha gravado no PIC, faz o seu trabalho. Simples assim!

Fonte quase pronta. Tela instalada, tudo pintado.

Já o gabinete da fonte, foi devidamente pintado. O corte que eu havia feito, ganhou uma tela de auto-falante automotivo (com os maiores furos que eu pude encontrar). A plaquinha de controle da fonte tem um LED bi-color que indica quando a fonte está pronta para ligar ou está em “stand-by”. Mesmo que seja praticamente impossível ver o LED com o gabinete fechado, resolvi colocar o LED aparente na fonte. Pelo menos vou poder vê-lo quando estiver com o micro aberto para mais alguma modificação ou manutenção. Tá bem, tá bem… a verdade mesmo é que eu queria ver como ia ficar o LED saindo pelo ex-furo de fixação da ventoinha… No fim, ficou legalzinho :-D.

Plaquinha de controle “ATX” instalada com direito inclusive a LED. O fio verde perto da placa mãe, liga a plaquinha de controle ATX ao pino do conector de drive externo.

Pré-Montagem:

Com a fonte finalizada e instalada, era hora de começar a pré-montagem. Instalei a placa mãe, a aceleradora (no A4000 o processador sempre fica numa placa separada, que nada mais é que uma aceleradora), memórias, placa filha (a que fica “em pé” com os slots), Indivision MK2, placa de rede, placa de vídeo RTG, unidades de disco (drive de 3.5″ e DVD) e pra completar um controlador de temperatura e ventoinhas.

Montagem em andamento.

Montagem em andamento.

Montagem em andamento.

Montagem em andamento.

Aqui nesse ponto tenho que ressaltar alguns itens que eu realmente gostei. O gerenciador de temperatura e ventoinhas pode parecer exagero, mas sinceramente não acho que seja. Além de ficar bonito, dar um ar de modernidade, os sensores de temperatura são realmente úteis! São ao todo 3 sensores e 3 ventoinhas controladas por ele. Coloquei um sensor no processador principal, outro no core da placa de vídeo RTG e o último na Indivision. Como não tem espaço pra colocar um cooler próximo à Indivision, ela foi a que apresentou a maior temperatura! Passando de 40º com facilidade, ainda mais com o gabinete fechado.

Utilizei então um daqueles exaustores que ficam presos à baia traseira. Isso resolveu o problema de aquecimento da Indivision. Sem o sensor, eu apenas poderia supor que ela estava aquecendo. O problema disso tudo é que o A4000 ficou com um monte de ventoinhas! Mas tudo bem. A fonte aguenta e ele não ficou tão barulhento assim. Tá pelo menos no mesmo nível que o meu PC.

Detalhe da Indivision MK2 e acima o exaustor.

Detalhe do espaço entre as placas, a Indivision e o exaustor.

Por falar nisso! O gerenciador de ventoinhas tem um microfone e um “v.u.” de LED´s pra medir se seu micro está muito barulhento. O “problema” é que o microfone é tão sensível que ele capta qualquer som. Se tiver uma música tocando ele capta e aí já era.

O outro ponto a destacar é o DVD. Este item foi um presente do meu grande amigo Marcelo Pires! E o DVD é simplesmente lindo, slim e não tem gaveta, ou seja, é igual ao utilizado nos carros. Por ser slim, sobrou espaço pra colocar um HD de notebook logo abaixo dele. E por falar em HD…

Detalhe do DVD, drive, controlador de temperatura e o novo “led” de power.

Detalhe do sensor de temperatura no chip de vídeo da placa RTG. Coloquei um mini dissipador pra ajudar.

O dilema dos HD´s:

Esse A4000 veio com um HD de 3.5″, ou seja, do tamanho “normal”, instalado junto aos drives no “berço” frontal. Pensei inicialmente em usar esse mesmo HD, pois ele já estava prontinho, tudo funcionando. Mas ele não poderia ficar mais ali. Eu teria que colocá-lo entre a fonte e a placa filha, que é outro local comum para a instalação do HD no A4000. Mas eu não tinha o berço para colocá-lo nessa posição. Fabriquei então um berço com os restos de uma carcaça de fonte. Mas não fiquei satisfeito. Eu queria mesmo era usar um HD de notebook. Preparei então um novo HD no WinUAE, testei no Amiga e funcionou de primeira. Nesse meio tempo, conversando com o Marcelo Pires, ele me deu a ideia de usar um HD SCSI. Não que o HD SCSI vá ser muito mais rápido, mas pro Amiga, o mais importante é liberar o processador da tarefa de ficar “controlando/esperando” a IDE. Consegui então um HD SCSI. Que bicho barulhento! Parecia um motor de dentista amplificado.

Apertado, muito apertado!

Interface IDE “desfiada” pra facilitar a manobra. E a do drive também!

Panorâmica…

Aí veio a grande dica do Marcelo. “Usa um adaptador IDE/SCSI”. Lá fui eu catar um treco desses. Consegui um no eBay. Não é muito barato, é difícil de achar, mas valeu a pena! Com ele, eu posso ligar um HD IDE numa interface SCSI! E não é que funcionou?? Depois de baixar o manual da minha aceleradora e configurar os jumpers para fazer o micro bootar pela SCSI, o HDzinho de notebook funcionou como se fora um SCSI. E o micro ficou bem mais rápido, justamente por deixar o processador mais livre. Mas tenho que confessar que ficou um coisa meio esquisita… quanto fio!!!! Fio da interface SCSI, adaptador SCSI/IDE e adaptador IDE3.5/2.5. Pois é, adaptador no adaptador. Mas funciona muito bem. Mais pra frente vou tentar melhorar isso e eliminar o adaptador de 3,5″<->2,5″. Por hora está ótimo! Faltava ainda ligar o DVD. Esse teve que ficar na IDE mesmo. Pelo menos ela já está atualizada e trabalhando em PIO2. Desfiei a interface IDE em blocos de 5 fios para poder manobrá-los melhor e ocuparem menos espaço, além de não prejudicar o fluxo de ar no gabinete. E com isso, pelo menos por enquanto, é o fim do dilema dos HD´s.

Indivision MK2 + Placa de Vídeo RTG:

Se tem um periférico sensacional no Amiga, ele se chama Indivision! Com ela é possível utilizar monitores de PC sem ficar se matando atrás de um monitor que possa funcionar à 15Khz… Mas uma plaquinha RTG não é nada mal! Essa que estou utilizando, uma GVP Spectrum 28/24 de 1MB, não é uma placa TOP, mas atende perfeitamente! Posso usar o WB com uma resolução de 800×600 (por exemplo), com 16Bit de cores confortavelmente, ou seja, com boa velocidade. Dá pra usar até 24bits nessa resolução, mas a performance começa a cair.

Vejam as opções:

Resolution	Depth	Frequency
1600 x 1200	8	64Hz
1280 x 1024	8	92Hz
1152 x 900	8	65Hz
1024 x 768	8	79Hz
1152 x 900	16	72Hz
1024 x 768	16	86Hz
800 x 600	16	81Hz
800 x 600	24	49Hz
640 x 480	24	59Hz

Outro ponto legal é o “pass-through”. Eu não preciso ficar comutando o monitor entre as entradas de vídeo. Eu ligo a saída da Indivision MK2 (DVI com um adaptador DVI/VGA) na entrada da Spectrum e a saída desta vai para o monitor. Ou seja, não importa se o vídeo está sendo gerado pela Indivision ou pela Spectrum, ele será exibido sem problemas e numa  única saída!

Detalhe da traseira do A4000. Dá pra ver os conectores da Indivision e da Spectrum.

Pra fechar, eu procurei uma placa velha de PC que tivesse saída DVI, retirei o “espelho” e utilizei pra fixar o conector DVI da Indivision na traseira do A4000.

O teclado:

Eu já estava com esse projeto de pintar o A4K de preto a muito tempo e por isso, sempre que achava um teclado de CDTV à venda, tentava comprar. Mas utilizar o teclado do CDTV num A4000, ao contrário do que possa parecer, não é plug&play. Aliás, se você conseguir fazer isso, certamente vai queimá-lo… O teclado do A4000 tem um conector Mini-DIN6, enquanto o do CDTV é um Mini-DIN5. Só por aí você já não vai conseguir plugá-lo, pois o pino guia não vai permitir. A solução é simples. Você pode até fazer um conversor e utilizá-lo externamente, mas a solução mais correta, nem chega a penalizar o teclado. Basta abri-lo, soltar os fios do conector (isso mesmo, não precisa soldar nem cortar nada) e inverter os dois fios da ponta (1 e 4) e os dois centrais (2 e 3). Pronto, agora você tem um teclado de A4000, só que preto! 😉 Ainda falta um último detalhe: É preciso retirar o pino guia do conector.

Teclado do CDTV. Testado e aprovado.

Como dá pra ver na imagem, eu substitui a chave de bloqueio do teclado (quem usa isso?????) por um botão com LED azul pra combinar com o controlador de temperatura. Por hora estou usando apenas como LED de POWER, mas esse botão futuramente vai ser, ou um chaveador de vídeo (caso esse micro ganhe uma Mediator com uma Voodoo), ou um botão de reset… Ainda não sei. Por enquanto estou apenas curtindo \o/.

Mais algumas imagens do micro “finalizado” e no final um vídeo dele funcionando!

Por enquanto é só 😉

Grande abraço!

Finalmente montado!

O descanso do guerreiro :-D.

Ficou legalzinho 😉

1,2,3 testando!

Guru Meditation: Amiblitz – Parte 1

Salve Pessoal!

Depois de um longo inverno, quer dizer, o inverno ainda vem aí, mas depois de um longo e conturbado período, estou tentando retomar os blogs que eu escrevo. E tem muita coisa pra contar…

Nesse post vou falar um pouco sobre a linguagem de programação Amiblitz que atualmente está na sua 3ª versão. Essa linguagem é um Basic com cara de C. A base é o velho e bom Basic, mas com recursos e velocidade que lembram muito o C!

Essa linguagem nada mais é que a evolução do famoso BlitzBasic, que nos áureos tempos, “brigava” com o AMOS pela atenção de quem queria desenvolver jogos de maneira até bem prática para o Amiga. Mas o tempo passou, o BlitzBasic para o Amiga, parou na 2ª edição e seguiu o seu caminho no PC. Mas o pessoal que produzia o BlitzBasic (Acid Software), viu que algumas pessoas ainda usavam e queriam melhorias na versão para Amiga. Eles então, liberaram o código fonte de todo o programa (compiladores etc…) e um grupo de usuários Amiga passou a atualizá-lo, criar novas funções e inclusive uma IDE com ótimos recursos! A única ressalva era que não poderiam usar o nome BlitzBasic. Surgia aí o Amiblitz!

E não é que o Amiblitz é bem legal de usar?!

Antes de falar mais sobre como ele funciona e demostrar alguns exemplos de comandos e rotinas (farei isso nos próximos posts), vou deixar alguns vídeos bem capengas de testes que eu fiz nas horas vagas. Inicialmente utilizei o Amiblitz2 e por fim, no último vídeo, utilizei o Amiblitz3 (demorei um pouco até conseguir fazê-lo funcionar direito, mas valeu a pena!).

Teste1: Este é um exemplo que vem no manual do Amiblitz2. Apenas copiei e executei. É um exemplo interessante, pois demonstra como utilizar o recurso “DualPlayField”

Teste2: Aqui, mais uma vez utilizando o Amibliz2 num Amiga600 acelerado, comecei a fazer um “demo” de um jogo de nave que desenhei no DPaintIV. Eu ainda estava apanhando um pouco do programa e não consegui carregar a palete de cores corretamente. Por isso a nave está com essas cores loucas…

Teste3: Praticamente o mesmo do teste anterior, mas já brincando com “upgrades” na nave, adicionei um “escudo”.

Teste4: Dessa vez, já no Amiblitz3 e utilizando o Amiga4000 (precisa ter MMU/FPU pra rodar o Amiblitz3), comecei um novo projeto. Estou montando o background pelo método “tile”, a rotina de tiro, colisão e scroll já implementadas e finalmente me entendendo com a palete de cores :-D.

Se a galera se animar… posso tentar dar uma ajuda e moldar os posts num “mini-curso” para quem quiser começar a brincar e programar também. Atenção! Isso não é uma promessa! 😉

A600 “ACA620” x A600 “S628” – Round 1: Fight!

Eu havia “prometido” a algum tempo atrás comparar o desempenho do Amiga 600 equipado com a aceleradora de baixo custo Fúria S628 com um Amiga 600 original. Acontece que mês passado eu recebi uma outra aceleradora também para o A600, dessa vez a novíssima ACA020.

Então pensei: E por quê não? Vou comparar o A600 Furioso com um A600 Individual. Pode parecer “covardia” comparar um 68020 com um 68000, mas… e daí né? 😀

Vamos às especificações principais de cada sistema:

A600 ACA020 e A600 S628

No meu canto esquerdo…

Commodore Amiga 600 + ACA020EC

• 1MB de ChipRAM
• CF Card 4GB
• Adaptador de CF by Kipper2K interno
• ACA020EC
  • CPU MC68EC020
  • 16,67Mhz (dados do fabricante)
  • 10.8MB + 5MB de FastAM máxima de 32 bits com zero waitstate (utilizei apenas os primeiros 5MB autoconfiguráveis de RAM nesse “round”)
• Monitor LG1721A utilizando um adaptador RGB

No meu canto direito…

Commodore Amiga 600 + Fúria S628

• 2MB ChipRAM  – A604 na trapdoor
• CF Card 4GB
• Adaptador de CF 90º
• Fúria S628
  • CPU MC68SEC000AA20
  • 28Mhz (dados do fabricante)
  • 2MB de FastRAM, sendo 1.5MB disponíveis para o sistema, não autoconfiguráveis
• Monitor Philips 170S utilizando uma Indivision ECS

Os dois CF´s foram preparados no emulador com exatamente o mesmo conteúdo e número de partições. Vocês devem lembrar que o “A600F” utilizava um HD, mas troquei para que a comparação fique mais justa nesse ponto, já que a velocidade de leitura de disco é algo que pesa muito nas comparações de boot e carga de programas.

Antes de partimos para os testes, vale ressaltar algumas alterações que precisaram ser feitas para que a ACA entrasse no A600 PAL-M (o pessoal da Individual Computers nem deve saber que eles existem!). Acabei tendo que fazer algo parecido no F628 para que o adaptador de CF de 90º ficasse bem encaixado também.

A alteração foi bastante simples. Apenas desloquei um componente do circuito de PAL-M (um capacitor variável). Já para encaixar o adaptador de CF tive que mexer em dois capacitores. Fotos por favor! 😉

Capacitor variável na posição original (componente amarelo)

Componente na nova posição.

Agora sim! ACA020EC e adaptador de CF confortavelmente instalados.

Uma limpeza no 68000 antes de encaixar a ACA vai bem né?

Are you ready?! Fight!

Nada melhor pra começar esse duelo do que um teste de velocidade de boot! Então que seja dada a largada!

A600 ACA020EC vs A600 S628

ACA 0  x  1 Fúria

Agora, utilizando o famoso SysInfo, vamos dar uma olhada no desempenho geral de cada um deles:

ACA620EC

S628

A versão com a aceleradora 020 é pouco mais que 6 vezes mais rápido que um A600 original, enquanto o Furioso é cerca de 5 vezes mais veloz. O primeiro teve um desempenho de 3.39MIPS contra 2.93MIPS. Uma curiosidade foi que ambos tiveram a velocidade aferida maior que a divulgada pelos fabricantes. Enquanto a ACA de divulgados 16.67Mhz teve como resultado 17.6Mhz, a Fúria, cujo valor original é de 28Mhz, atingiu 28.9Mhz. Nada mau! Mas no fim, nenhuma  surpresa no resultado.

ACA 1  x  1 Fúria

E pra fechar o primeiro round, que tal um teste de acesso a disco? Ainda utilizando o SysInfo, testei a velocidade de leitura na primeira partição de cada um dos Amigas. Vamos aos resultados:

ACA020EC

S628

Foi por pouco, mas a Fúria foi mais rápida que a ACA nesse quesito! Pra tirar qualquer dúvida, inverti o CF entre as máquinas e com pequenas diferenças nos números a vitória em todas as medições foi da Fúria.

E pra quem achou que esse comparativo seria apenas pra “cumprir” tabela, pois a vitória da ACA seria esmagadora… espere que e ainda tem muito mais a se testar e algumas surpresas pela frente!

Por hora, vantagem para a Fúria com 2 a 1 no placar. Que venha o segundo round! 

Upgrade: A600

E vamos a mais um Upgrade no LabRitcho e novamente com o A600!

 

Indivision ECS instalada sobre a A604

Dessa vez o A600 ganhou uma Indivision ECS, plaquinha que permite a utilização de monitores VGA. Essa plaquinha é bem versátil no que se diz respeito a utilização, já que eu posso instalá-la no A500, A600, A1000, A2000 e A3000. Logicamente que em alguns casos eu preciso de algum outro acessório. No A600, por exemplo, eu preciso de uma A603 ou A604 (expansão de memória). Como esse A600 já está com uma A604, foi só abrir o micro e espetar a Indivision.

Aterramento feito, hora de testar!

Uma caraterística interessante dessa placa é que se você instalar uma segunda Indivision ECS (basta plugar uma sobre a outra), e utilizar dois monitores com o Amiga exibindo imagens diferentes (obviamente). Não vejo muita utilidade pra isso no momento, mas merece pelo menos o comentário.

Funcionando perfeitamente!

Por enquanto eu estou usando o cabo flat com o conector VGA saindo pela porta de expansão inferior, passando por baixo do gabinete e saindo atrás do micro. O próximo passo é retirar a caixinha do RF e colocar o conector VGA no seu lugar.

Agora esse A600 ficou completamente utilizável! Ele virou, pelo menos por enquanto, minha máquina principal como plataforma de desenvolvimento. Sim! Estou fazendo uns programinhas de teste. Pretendo falar mais sobre isso num post exclusivo.

Testando em outro monitor.

Veredito?!

Compra mais que recomendada para quem tem um Amiga OCS ou ECS! Dê adeus aos monitores de 15Khz 😉

Upgrade: A1000

O Amiga 1000

AMIGA 1000: “Insira o kickstart disk!”

Esse Amiga é sensacional! Não é o mais rápido nem o mais poderoso, muito pelo contrário, mas com certeza é um dos mais bonitos e bem feitos dentre todos os Amigas. Os cuidados e os detalhes impressionam, ainda mais se pensarmos que ele foi fabricado em 1985. O engraçado é que, da forma como foi produzido, com os slots para expansões podendo ser acessados sem a necessidade de se abrir o gabinete, provavelmente só o próprio pessoal da fábrica e das assistências técnicas, teriam o prazer de olhar seu interior recheado de capricho.

A parte interna da tampa têm as assinaturas em relevo do pessoal que participou do desenvolvimento.

Da tampa com “autógrafos” em relevo às presilhas que evitam que os parafusos quebrem o plástico se apertados em excesso, é um prazer olhar o interior desse micro. Esse exemplar em especial, parece nunca ter sido aberto, já que não encontrei em nenhum lugar, marcas de “dois apertos” de parafusos ou coisas do gênero. A placa mãe, limpa como nunca vi num micro dessa idade, tem alguns chips com contatos banhados a ouro.

Chip “soquetado” banhado a outro. Nunca tinha visto…

O drive de disquetes com direito a aterramento, é preso com parafusos esquisitos, mas que facilitam sua retirada, já que ficam bem “fundo” no gabinete. Pra onde eu olhava, gostava mais ainda do Amiga 1000. O teclado de cabo “destacável” com plugues de telefone padrão americano (RJ11) tem o melhor toque de todos que já experimentei, sem exageros! Uma pena não ser um teclado profissional, mas isso tem uma explicação. Tanto ele quando o gabinete foram desenhados de forma que, quando não estivesse em uso, o teclado pudesse ficar acomodado na “garagem” projetada sob medida. Pequenos detalhes que me fizeram gostar ainda mais desse Amiga.

Detalhe da parte de baixo: A “garagem” para o teclado. O conector da fonte também fica “escondido”.

Upgrade 1: IDE + CF Card Adapter

IDE com os CF´s. Pronto para uso!

O primeiro upgrade que eu testei nem precisava abrir o micro. Bastava encaixá-lo na porta de expansão lateral. Um interface IDE com um adaptador para CF “duplo”. Funcionou como um relógio suíço. A única “penalidade” é que ela não tem auto-boot, ou seja, eu ainda preciso de um disquete para dar a partida no micro. Mas sinceramente, no Amiga 1000 isso não é problema nenhum. O Amiga 1000 não tem o kickstart gravado numa eprom internamente como nos outros Amigas, então é normal que tenhamos que colocar um disquete com o kickstart para ele dar a partida (antes do disco do sistema).

IDE “em ação”.

E o melhor de tudo é que o Tom (usuário gringo que fabricou essa IDE) enviou junto com a IDE os discos já preparados para que o boot seja dado e tudo seja carregado sem qualquer trabalho! Ele mandou ainda um disquete caso eu queira usar essa interface no A500 (sim essa IDE também é compatível com o A500). Muito legal!

Detalhe da lista de Volumes montados no sistema.

É dar o boot com o disquete no drive e esperar. O sistema carrega tudo direitinho e depois é só usar. Ele ainda mandou um dos CF´s formatado em FAT para que eu use como “vai-e-vem” de arquivos de dados com o PC. E eu nem preciso me preocupar com nada no AmigaOS, ele já mandou tudo configurado. Esse cara é bom!

Tela do sistema durante o boot.

Upgrade 2: 8Mb FastRAM

Essa “plaquinha” aí adiciona 8Mb de FastRAM ao A1000 (ou A500).

O segundo upgrade deu um pouquinho mais de trabalho. Tive que abrir o micro, desmontar as proteções metálicas até chegar ao processador. Depois foi só sacar o 68000, espetá-lo na plaquinha e voltar com ele pro lugar. Tudo muito simples! Quem fez essa expansão? O Tom! Esse cara é sinistro :-D.

Processador (MC68000) e a expansão de memória.

Agora o A1000 ficou totalmente usável! Memória à vontade (ele já veio com uma expansão de 256Kb totalizando 512Kb de ChipRAM) e IDE pra carregar os programas sem o stress dos disquetes. Não precisa nem de scandoubler, a saída de vídeo composto tem uma qualidade tão boa que não sinto falta de uma Indivision.

Memória instalada. Ela fica entre o processador e a placa mãe.

Esse é um micro que, a menos que surja algo muito interessante por aí, não precisa de mais nada. É só ligar e viajar de volta no tempo ao ano de 1985, só que com IDE e mais memória 😀

E seguem mais algumas fotos… Abraço!

Essa parte metálica é a expansão de 256Kb de ChipRAM.

Detalhe do interior do A1000. Incrivelmente novo!

Parafusos que fixam o drive. Esquisitos porém funcionais.

Detalhe da proteção para não quebrar o plástico ao apertar o parafuso da tampa!

Tela do WB1.3 logo depois de carregado.

Mais uma tela do sistema. Já veio com tudo isso pronto. Show!

Até o DOpus já veio instalado.

Memória disponível.

Outro programinha para checar a memória…

Desligou o micro? Teclado na “garagem” e até a próxima! Only Amiga… 😉

 

Kickstart: A600 Fúria!

Inaugurando a sessão que chamei de “Kickstart”, onde uma primeira análise ainda superficial ou até uma apresentação de um hardware ou software serão descritos, eu vos apresento o A600 Fúria.

O Amiga 600

Amiga 600 “NOS”

Esse A600 é um “NOS” (New Old Stock”) que foi vendido aos montes algum tempo atrás. Eu já havia trocado os capacitores, aliás foi umas das primeiras coisas que fiz nesse micro e felizmente não encontrei nenhum vazamento ou trilha rompida. Ele também já estava com uma A604 (expansão de memória de 1MB totalizando 2MB de ChipRAM). Pra ele ficar legal de usar, principalmente com o WHDLoad, faltava uma unidade de disco (CF ou HD) e alguma FastRAM (ou “SlowRAM”). Procurando por algumas opções, acabei conhecendo a Fúria S628.

Fúria S628

Fúria S628 já instalada.

A S628 é uma aceleradora com processador MC68SEC000AA20 (versão de baixo custo do Motorola MC68000), com 2MB de FastRAM rodando a 28Mhz! A instalação não é o que podemos chamar de plug&play, já que é necessário soldar três fios (dois de aterramento e um de referência de clock), mas tudo extremamente simples.

Conversando com o criador, Boris (Boboo nos fóruns), ele me recomendou usar um cooler próximo à aceleradora para manter a estabilidade do funcionamento, afinal, um 68000 rodando a 28Mhz (28.9Mhz segundo o SysInfo) é de se esperar que o bichinho esquente mesmo.

Ventoinha instalada seguindo as dicas do fabricante.

Seguindo a dica do Boris, coloquei um cooler próximo ao conector PCMCIA e bem ao lado da FÚRIA. O resultado foi muito bom. O fluxo de ar passa sob a aceleradora e conseguiu mantê-la estável e sem qualquer indício de superaquecimento. Usei um cooler que eu já tinha. Tive que fazer algumas pequenas mudanças, como um chanfro próximo à aceleradora para que ele coubesse.

Pra fechar, preparei um HD no emulador e instalei no A600. Aqui um pequeno problema, mas normal num micro tão pequeno. Com a FÚRIA instalada, não é possível usar o “berço” pro HD, então tive que colocá-lo em outra posição, nada muito problemático.

Conjunto montado. Hora de testar!

Primeiras impressões

Ao ligar já se nota o ganho de performance. Mesmo com um sistema mais incrementado, como as versões do ClassicWB, o AmigaOS “sobe” rapidamente e o uso é bem mais agradável. Claro que a memória extra ajuda, mas nesse caso vou dar crédito ao conjunto. Ainda faltam alguns ajustes e também programas para que eu possa fazer um bateria de testes mais interessante com esse micro. Nesse primeiro contato, por exemplo, eu nem estava contando com os 2MB de FastRAM. Como a versão da ROM é a “2.5”, para que a memória fique disponível, é necessário usar esse programinha aqui http://dl.dropbox.com/u/939939/Furia/FuriaS628_AddRAM.lha e depois setá-lo no StartupSequence (C:AutoAddRAM >NIL:). Simples assim…

Pra completar, existe ainda uma expansão de memória (8MB) que pode ser conectada diretamente ao slot da Fúria! Infelizmente, quando eu fiz a encomenda, não havia nenhum item disponível para venda. Nesse momento, o Boris está trabalhando numa nova aceleradora, dessa vez baseada no 68020, e depois que ela estiver pronta, fabricará mais alguns módulos de memória.

Expansão de memória. Ficou faltando…

No próximo post sobre esse assunto, farei um comparativo entre dois A600, sendo um “original” e outro Furioso 😉

Abraços!

News – A1200 G-REX

A1200 (R)Evolution

Muitos usuários já ouviram falar da Mediator. Uma placa muito interessante que permite a utilização de placas PCI no Amiga. Placas de vídeo, áudio, USB, rede entre outras, podem ser utilizadas. Logicamente que não é qualquer placa, ela precisa ser compatível, ou seja, tem que ter os drivers para funcionar no Amiga. É a placa desse tipo com o maior suporte, tem uma grande variedade de placas compatíveis e ainda é fabricada até hoje pela ELBOX (http://elbox.com/).

G-REX 1200 – Existe ainda a versão para o A4K

O que um número bem menor de usuários sabe é que existem ainda outros dois “concorrentes” da Mediator: a Prometheus e a G-REX. Essa última, apesar do suporte mais acanhado em termos de drivers, o que consequentemente limita o número de placas PCI compatíveis, é considerada a mais rápida de todas. A G-REX não é mais fabricada, mas consegui uma em ótimo estado com o meu Amigo Mugo e o melhor: A última versão! (existiram duas versões, a primeira só tinha DMA em um dos 5 slots PCI, já a última versão tem essa característica nos dois primeiros slots).

Parafernália montada para os testes.

Mas não é qualquer Amiga que pode usar uma G-REX. Tem que ser uma Amiga com uma aceleradora PPC! Então o eleito para essa “brincadeira” foi o meu xodó, o A1200 que comprei zero km no curto período que a PCI (agora não é o barramento e sim uma empresa!)  fabricou o Amiga aqui no Brasil na década de 90.

O sistema reconhecia a Voodoo, mas ainda demorou um pouco até eu conseguir fazer tudo funcionar direito!

Mas nem tudo são flores…

A G-REX é manhosa. Reza a lenda que ela não funciona se a sua PPC for revisão zero. Baixei um programa chamado BoardType do próprio site da G-REX (que ainda funciona e muito bem!) e rodei pra descobrir a revisão da minha PPC. Resultado: Revisão zero! Confesso que naquele minuto fiquei desanimado ao quadrado. Conversei com o Mugo e ele disse que não era bem assim e que eu deveria continuar os testes.

Panorâmica da confusão que ficou o LabRitcho.

E lá vamos nós!

Montei então uma senhora gambiarra com a placa do A1200, a PPC, a G-REX, uma fonte ATX de PC, uma placa Voodoo3000 (que eu tinha guardado a milênios) e dois monitores conectados, um na Voodoo e outro na porta RGB original do Amiga (retirei a Indivision provisoriamente). Até o drive eu conectei, já que o primeiro passo, antes de qualquer coisa, é atualizar a bios da PPC e pra fazer isso tem que ser por disco.

Imagem gerada pela Voodoo3000. Muitos riscos e interferências.

Com a BIOS atualizada, o passo seguinte foi ligar o Amiga com a tecla ESC pressionada para acessar o menu de configuração da PPC. Show! Placas reconhecidas. Até agora tudo bem, apesar disso não ser determinante para saber se iria funcionar. Dei o boot e a imagem aparecia em ambos os monitores, com problemas de cor e resolução, mas apareciam. Comecei então a rodar alguns outros programas para conferir se as placas estavam sendo reconhecidas. E sim, estavam! Contive a euforia e continuei os testes…

Com a Voodoo5000. Imagem perfeita!

Tudo isso que estou narrando em algumas linhas, levou cerca de uma semana de testes. Tem muita coisa que nem me lembro mais. Baixei vários drivers e aplicativos. Muitos emails trocados com o Mugo até conseguir fazer a coisa funcionar.

Maravilha! Agora sim. Driver de vídeo instalado e funcionando!

Depois que eu confirmei que era possível SIM usar a G-REX com uma PPC rev zero, duas coisas ainda me incomodavam:

1- A imagem da Voodoo3 estava com vários riscos desde o boot;

2- O sistema não estava estável. Alguns travamentos ocorriam.

Sobre o item 1 o que eu descobri foi que a Voodoo3 está com algum problema. Pra tirar qualquer dúvida, instalei a Voodoo3 num PC e a imagem também ficou péssima. Peguei uma Voodoo5 que estava guardando para usar no A4000, instalei na G-REX e a imagem ficou espetacular! Mas por que não usar a Voodoo5? A G-REX não tem suporte a aceleração 3D para a Voodoo5 apenas para a versão 3. Por hora vou usar a VD5, mas em breve trocarei por uma VD3.

Cheguei trocar os capacitores, desmontar o dissipador de calor da VD3, substituir a pasta térmica, e ainda coloquei um ventilador apontado pra ele, mas nada disso surtiu efeito. Tem mais coisa errada ali.

Capacitores e pasta térmica trocadas, mas nenhuma melhora na Voodoo3000.

O segundo item foi totalmente resolvido depois que, a partir de (mais) uma dica do Mugo, utilizei o conector de força do drive como entrada secundária de energia. Isso mesmo! Liguei um conector de força da fonte ATX no lugar onde sairia a energia pro drive. Com isso o micro funcionou por várias horas sem qualquer problema. Outra providência foi improvisar um cooler na bancada para refrescar a cuca da PPC.

Configurando a resolução para usar no Workbench.

A segunda semana de testes foi para fazer a placa de som funcionar. Bati bastante a cabeça e troquei mais uns 10 emails com o Marcelo até conseguir entender e solucionar os problemas. A satisfação do dever cumprido veio quando eu consegui fazer o ADoom rodar na PPC com a VD5 (ainda sem aceleração 3D). Sensacional. Pena que eu esqueci de tirar uma foto…

Imagem simplesmente sensacional!

Definitivamente, montar e fazer funcionar uma G-REX não é uma tarefa das mais triviais, mas depois de tanta diversão, era hora de desmontar toda a parafernália, afinal, ainda tem um monte de coisas me esperando para terminar.

Obviamente que o A1200 não poderá mais habitar seu gabinete original (infelizmente), mas eu já tenho um, ou melhor, dois gabinetes torre para montar, adaptar, cortar e emendar para colocar o A1200 com a G-REX. Ainda falta testar e configurar a placa de rede (mas agora só vou fazer isso com o micro já no gabinete) e esperar chegar a Voodoo3000.

Ah é… falta um tal de tempo livre também :-p.

Mas tudo bem.

Devagar e sempre!