Depois de um período de animação suspensa, Nick Marentes voltou a avançar no desenvolvimento deste jogo para CoCo 3. Mas o mais legal de tudo não é o produto final, e sim o blog do desenvolvimento onde ele narra todas as mumunhas de programar para o CoCo 3.
Continue lendo Retomado o desenvolvimento do Popstar Pilot!
Arquivo da tag: programação
Uma iniciativa legal para os anormais que gostam de Assembler
Nosso colega Rudolf “MSX SJC” Gutlich iniciou um blog dedicado a desenvolvimento de jogos em Assembly Z80 para o MSX. Começando do básico do básico (que é pra não ter desculpa que é muito difícil de aprender) o projeto de um jogo “de carrinho” bem simples.
Programação assembly… “like a boss”
Estava fazendo uns testes de código em MSX-DOS e experimentando como chamar a BIOS a partir do ambiente e… opa! Melhor explicar uma coisa importante antes.
No MSX, quando estamos no BASIC a memória tem o seguinte leiaute:
0x0000 - 0x7FFF : BIOS e MSX-BASIC 0x8000 - 0xFFFF : RAM (32Kib)
Ou seja uns 32KiB de ROM estão lá ocupando 50% do espaço de endereçamento que o Z80 entende e chama de “mundo”.
Mas quando estamos no MSX-DOS a memória fica assim:
0x0000-0xFFFF : RAM (64Kib)
Mas como se faz para acessar a BIOS já que ela “desapareceu” da vista do Z80?
Fractal para quem precisa de fractal
À guisa de (falei bonito agora, hein?) continuação do post sobre cartões SMS em mainframes, Ken Shirriff ficou sabendo que havia um IBM 1401 funcional no Computer History Museum e lá foi-se ele pra brincar com a criança. Brincar do que? Ora, de fazer um programa para imprimir o Conjunto de Mandelbrot. Em que linguagem? Assembler em cartões perfurados, claro, porque linguagem de alto nível, monitor e teclado são para os fracos.
Mas calma que a história não acaba por aí…
Continue lendo Fractal para quem precisa de fractal
Não arranque os cabelos
Um conselho universal e atemporal para aqueles que desenvolvem software. Esta página é do manual de programação do ZX80 por Steve Vickers (clique para ampliar):
Traduzindo o fluxograma:
Iniciar → Escrever programa com o mínimo possível de bugs → Testar programa → Funciona perfeitamente? Sim: Terminar. Não: → Não arranque os cabelos → Ache os bugs → Conserte-os, introduzindo o mínimo possível de bugs novos → Voltar para “Testar programa”
Programando no C64, 25 anos depois
O argentino Ricardo Quesada resolveu fazer um comparativo sobre o que se usava para programar em um C64 no final da década de 1980 (e começo da de 1990) com aquilo que está disponível (ferramentas, informação e até as facilidades de se ter uma TV PAL/NTSC) ao “programador médio” hoje em dia. Leitura bem interessante pra quem quer programar em máquinas clássicas e também perder os preconceitos sobre a compilação cruzada.
De passagem, ele menciona um ecossistema piratohouse portenho que me parece intrigantemente similar ao de outro país, não sei qual…
Programação em Assembler: Quem te viu, quem te vê.
Se você, assim como eu, programou em Assembler na era clássica, provavelmente já se sentiu assim:
Meu modelo mental de CPUs ficou parado nos anos 80: basicamente, caixas que fazem aritmética, lógica, manipulação de bits, e carregam e colocam coisas na memória. Tenho uma vaga consciência de vários progressos, como instruções vetoriais (SIMD) e a ideia das CPUs terem suporte a virtualização (mas não faço ideia do que isso significa na prática).
Que avanços legais eu perdi? O que as CPUs de hoje podem fazer que as do ano passado não podiam? Ou do retrasado, ou de 5, 10 anos atrás? O que mais me interessa são capacidades que o programador tem que aproveitar manualmente (ou que precisam de reprojeto dos ambientes de programação) para poderem ser utilizadas, e portanto podem não estar sendo utilizadas no momento. Acho que isso não inclui coisas como SMT/Hyper-threading, mas honestamente não tenho certeza. Também me interesso em coisas que as CPUs atuais não podem fazer, mas as do futuro próximo poderão.
Foi essa a pergunta que David Albert fez, e Dan Luu resolveu respondê-la. Leitura obrigatória para qualquer assembleiro que se preze. Leia aqui.
Programador: não leia isto a não ser que você queira perder totalmente a fé na Humanidade.
Para ser mais específico, não clique aqui. Hoje é Quarta-Feira de Cinzas, acabaram as desculpas para levar na flauta, e você não precisa de mais motivos para ficar deprimido. Depois não diga que eu não avisei.
Pelo lado bom, mostra que nem todas as coisas horríveis do Windows são culpa da Microsoft. Só algumas.
(Retirado deste livro.)
Fritadeira Elétrica Considered Harmful
Ela pode até desestruturar seu programa, mas por ser de ar quente não aumentará seu colesterol. Agora a escolha é sua!
Continue lendo Fritadeira Elétrica Considered Harmful
Até mais, Dr Dobbs!
Houve um tempo em que eu achava que acabaria enveredando pelo caminho do desenvolvimento de software. Apesar de parecer o contrário, minha formação é de Bacharel em Matemática (posteriormente Mestre em Computação Científica e Licenciado em Matemática, mas aí são outros 500), logo não fui obrigado pela graduação a virar um garoto de programa. Mas sempre fui curioso quanto ao assunto, achava que poderia encontrar algo que pudesse ser empregado em códigos no meu micro do coração (precisa dizer qual?), e nas minhas idas às bibliotecas (coisa antiquada, não?), conheci e encontrei a Dr. Dobb’s Journal, uma revista para programadores. E nela li e xeroquei um monte de artigos, sobre morphing, computação gráfica, programação funcional, computação distribuída e mais um monte de coisas, já que “um dia poderão ser úteis“.