Software posible.

Ya que hablé tanto de las especificaciones técnicas de nuestra conceptual consola, quiero hablar del posible catálogo que se puede lograr con los controles.
He dicho que tendrá dos pads como la Wonderswan, un stick como la Neo Geo Pocket, y los clásicos botones B, A, Start, y Select; lo que nos servirá para cualquier juego que se nos ocurra (o si necesitamos más, la imaginación nos dirá cómo adaptarnos). Veamos un vistazo a qué se puede lograr:

Plataformas

Sería cómodo con cualquiera de los esquemas jugar a un plataformero. Imagina haciendo un salto recto largo con cualquiera de los pads-botones independientes y/o haciendo saltos diagonales con el stick. Es incluso perfecto para jugar en vertical/horizontal.
Y sería buena oportunidad para crear una mascota que nos represente a partir de un juego de plataformas. Así que cuando el proyecto crezca... apúntense.

Peleas

Este es el género favorito de la Neo Geo Pocket, y de nuestro stick. Hubo juegos de pelea en Wonderswan, pero la palanca será nuestra mejor opción a la hora de hacer nuestros especiales, rodar, saltar cortamente, y otras habilidades.

Shooters

Nótese que está Judgement Silversword: juego hecho en WonderWitch (kit para programadores amateur de Wonderswan). El juego usa los dos pads de una manera creativa (en sí está basado en el legendario shooter Radiant Silvergun).
Añadamos el stick para mover aquella espada, y tenemos un arsenal todavía más alto, y el botón de "escudo" (un tanto inútil a mi gusto) podrá ser usado para otra arma.
En shooters horizontales (como R-Type, Gradius, etc.), hagamos un enfoque más minimalista. Tenemos los botones B y A que podemos usar para: disparo y bomba respectivamente. ¿La nave? ¿Qué tal un jóven montado en un dragón como Dragon Breed de iRem que puede ser el escudo de nuestro héroe?

RPG's


Seeeh... la oleada Pokemon fue algo que hizo de la Game Boy/GB Color el rey de la colina por un gran tiempo hasta que le pasó el trono a la Game Boy Advance.
Un RPG es fácil de programar, pero difícil de diseñar. Y también es muy expandible.
Un RPG no tiene reglas definidas de cómo debería ser. Unos hacen los RPG's sin sistemas de pelea, otros los hacen Dungeon Crawlers, gente se centra en la historia, y otro staff se centra en los acertijos.
Es el género más versátil existente; y el que peor podría salir de ser mal ejecutado. Imagina un proyecto ambicioso con ideas nunca antes probadas, pero que de ser mal puestas, sale un producto sin mucha alma.
Intenta hacer tu RPG sencillo. Y cuando tengas una base sólida para saber qué hacer con tus ideas, es hora de arriesgarse.

Discutiendo sobre sonido.

Una de las metas más importantes es mantener a los fans de sus respectivas consolas felices entre sí en vez de provocar flamewars. Y una de las peleas más amargas toma lugar en el campo de los chips de sonido.
Por eso, yo te pregunto: ¿te gustaría tener un sonido metalizado como el de una NES/GameBoy con filtros de SID de Commodore 64? ¿Quieres oir esas ondas tan distintivas y los patrones de ruido del chip POKEY de las computadoras de 8-bits de Atari a la vez que quieres tener una frecuencia fija? ¿O sencillamente quieres algo similar a tu consola favorita pero con más voces?

Y por último y no muy referente a las demás preguntas: ¿es posible activar 12 canales PCM estereo de 4 bits de una capacidad de 10 a 35000 KHz sonando en armonía sin afectar mucho la duración de la batería?

Un PCM (siglas de pulse-code modulation) no produce un sonido por sí mismo por defecto; sólo se encarga de pasar las ondas que el usuario mismo hizo llamadas "samples". Eso hace que un archivo pese más de lo normal (a menos de que sea un archivo modular, pronto tocaré ese punto) pero a cambio produce un sonido muchísimo más natural.
Claro que no es la meta que queremos; el punto es que suene como un sintetizador de sonido. Y hay un formato musical (llamado AHX) hecho por un programador de Amiga que precisamente se encargaba de que las 4 voces PCM de la computadora formaran un sonido parecido al de una Commodore 64 que no soporta samples. Y eso me inspiró a idear (mas no crear, aún no tengo el conocimiento de programar en gran escala) un formato que pudiera imitar cada sonido de los sistemas ya mencionados (he aquí la razón de las preguntas que sonaban a sueño guajiro).

- Primero: que sea un archivo de módulos. Un módulo en programación es un un bonche de instrucciones que se puede llamar a cualquier momento. Será fácil hacer loops musicales (para que no termine la música abruptamente, o cambie según el momento); y ocupará menos espacio (aún con samples), significando: más composiciones dinámicas, más efectos de sonido, y más espacio para guardar otras cosas en juego.

- Segundo: ya mencionado, que se le diga matemáticamente cómo ha de sonar (si es una onda cuadrada, pulso, triángulo, sierra, ruido, etc.), a qué frecuencia, con cuanta distorsión, etc. Claro que podríamos dar soporte a un máximo de 16 samples de 4-bits (una cantidad menor a la de nuestras NES y GameBoy). Eso a parte de darnos un "buffette retro", todavía será más ligero.

Ahora, pensemos en cada probabilidad.

PD: Sé que hago un énfasis exagerado en guardar espacio. Traumas de niño con ver que mis "dibujitos" en Paint no dejaban a mis hermanos guardar su trabajo a gusto.

Primer boceto.

Es algo básico, pero puede servir como referencia.



Uploaded with ImageShack.us

NOTA PERSONAL: Se parece más a una SwanCrystal.

J1 vs. AVR: Pila contra registros

La comparativa puede sonar ridícula, después de todo; uno es un chip hecho en Verilog, y el otro es un chip hecho desde 0, aunque hay implementaciones libres en FPGA con su código mostrado.
Podrían haber más chips rondando que me podrían dar un buen poder mas duración de 48 horas con dos baterías AA, pero estos procesadores mencionados me llaman la atención por sus características:
- Una densidad de código lo suficientemente grande como para guardar un RPG que se puede acabar en 40 horas acumuladas en un espacio de 24 megabits aproximadamente (más pequeño todavía en un J1)
- Amigables con lenguajes de alto nivel de abstracción (J1 con Forth especialmente, AVR con C especialmente), y tienen un ensamblador muy entendible (aunque repito: Forth puede ser el ensamblador fácilmente de J1).
- Ambos pueden ser tan poderosos como para cargar todo un juego de una resolución de NES sin ninguna ayuda de chips externos (visto en el Uzebox que usa AVR).

Ahora bien, hay diferencias notables en sus arquitecturas que nos pueden afectar con la tarea de realizar juegos.
En esta entrada se hablará a continuación de la principal diferencia entre estos CPU's:
- J1 es un procesador de pila: todos los números, instrucciones, y operandos se manejan en una pila grande de datos que nos puede regresar el resultado.
La ventaja de los procesadores de pila es la densidad de código tan grande que tienen. Como dije antes: un RPG terminable en 48 horas y 7 finales (como Chrono Trigger) puede ser muy pequeño en J1.
Otra ventaja es que es muy fácil de fabricar, usar, y modificar en caso de que el proyecto tenga éxito y se pueda fabricar en masa dentro de un ASIC.
La desventaja es que muchas veces se necesitaría más instrucciones para tener un trabajo hecho. Eso podría aumentar el tamaño del código, si bien no negar la bendición de la densidad de código anteriormente dicha. Todo dependerá del lenguaje que usemos, y por supuesto; del programador.
Otra desventaja es el límte de cuánta información puede contener. Si llega a romperse, puede comprometerse el hardware a romperse físicamente o a quemarse. O en el más leve de los casos, una mala instrucción podría llevar al sistema abajo (recordemos que cuando mucho son dos pilas con diferente propósito) y tener que apagarlo/prenderlo más de una vez.
Un punto mejorable en el J1 sería tener unas cuantas instrucciones de 8-bits. En caso de que no necesitemos tanta memoria o sea una tarea simple lo que se tenga que lograr, una instrucción de 8-bits (valga la redundancia) podría ser una buena opción.
- AVR es un procesador RISC de registros: los registros son cajas pequeñas que nos guardan una pequeña porción de información. Nuestro procesador AVR tiene 32 registros de 8-bits usables para todo fin, y soporta punteros (esenciales a la hora de programar C).
La ventaja de los procesadores de registros es su seguridad. Un registro dañado no dañará a otros, y se puede recuperar con las medidas adecuadas (bloques try/catch/finally, TRY/EXCEPT ON/FINALLY, etc.). En un sistema operativo completo (o incluso una BIOS sencilla), eso es sumamente vital; no querremos tener un mensaje de error mientras estemos en el momento más emocionante de nuestro juego ya sea por un código mal escrito.
Otra ventaja es que se necesitarían menos instrucciones para tener un trabajo andando. La productividad aumenta de esa manera. Añadamos que las instrucciones de AVR son ortogonales: son independientes una de otra, y no causarán efectos colaterales (que algún valor cambie sospechosamente, por ejemplo); es algo no muy común en los RISC.
La desventaja es la densidad de código. Si bien un AVR produce ejecutables compilados más pequeños que otros procesadores (de hecho, es de los pocos RISC que logran subvertir la típica desventaja de programas pesados), no se compara todavía a un J1.
Y eso conlleva a la segunda desventaja: no es muy eficiente en su uso de RAM comparado con J1. Ya hemos visto a la Uzebox que con sólo 4 KB SRAM puede manejar gráficas de calidad de NES junto con un sonido decente; es aún limitado para lo que queremos (al menos, el autor desea gráficas dignas de una SuperGrafx en una resolución menor).
El precio de los AVR's "fijos" (que no están hechos dentro de un FPGA, ASIC, etc.) directo de Atmel en sí es barato; no debería superar los USD$3.50.

Esto cubre la primera de muchas partes del por qué me estoy decidiendo entre un AVR o un J1. Si tienen una sugerencia para otro procesador de 8-16 bits, cuéntenme para considerarlo.
Gracias.

Especificaciones hasta ahora. (Sujeto a modificaciones)

Pantalla: LCD de 224 * 152 pixeles con una paleta de 4096 colores, volteable como la Wonderswan. Tamaño en pulgadas aún no decidido.
CPU: Debatible. Entre las opciones se encuentran un AVR de 8-bits, o hacer todo un chip nuevo en un FPGA a partir del diseño de un J1.
Número de botones:
- 2 D-Pads a lado izquierdo de la consola y un stick digital al centro.
- Al lado derecho, estarán los botones B y A.
- Cuatro pequeños botones (dos a cada lado) harán la función del dúo Start y Select. ¿Para qué? Recordemos que al igual que la Wonderswan, nuestra Hack Gear se jugará vertical y horizontalmente. Dos botones con una misma función y una diferente locación son posibles, y personalmente me da flojera levantar el pulgar derecho lejos de los botones B y A. ;)
GPU/Soundchip: Igual, estoy pensando en un Gameduino. El código está disponible para poder modificarlo a la necesidad.

Comunicando un fetish, o haciendo realidad un deseo.

En la internet, es posible encontrarse de todo, y de no ser por ella; tal vez nunca hubiera sabido de la existencia de dos joyas del hardware portatil recreativo: la Neo Geo Pocket y la Wonderswan. ¿Por qué no combinar los atributos de cada una de ellas?
Tenían ideas que nunca se vieron en otras máquinas portátiles de recreación, y varios de sus juegos eran grandiosos. ¿Por qué no hacer un "ejercicio retro" de concepción?
Así mismo, varios chicos han estado haciendo sus propios sistemas (Uze con su Uzebox , EvilMadScientists con su Meggy Jr., entre otros genios que han podido materializar sus ideas), lo cual me incentivó a crear este blog para detallar cómo sería mi consola de tener el capital y el conocimiento adecuados para plasmar mis conceptos y sueños al plástico y silicona.


Vean qué las destaca de las demás


Ya sé cuántos botones tendrá, pero será difícil decidir el hardware interno. Dicho esto, a investigar.