DEV Community: Marlow Haspert

Los registros de la Commodore64

Marlow Haspert — Tue, 12 Jul 2022 00:50:09 +0000

Introducción

Si nos hemos decidido a aprender a programar en el llamado "lenguaje de máquina" de la Commodore 64, en seguida nos encontraremos con algo llamado registros.

En la disciplina de arquitectura de computadoras se llama registros a memoria muy rápida, usada para ejecutar programas y operaciones de forma eficiente. El propósito de tener registros es poder consultar rápidamente datos para ser procesados por el CPU, incluso más rápidamente que accediendo a través de la memoria RAM.

Registros de la C64

A - Acumulador

En el lenguaje de máquina se hace referencia a él simplemente como A y es utilizado principalmente para operaciones aritméticas y lógicas. El resultado de este tipo de operaciones se guarda en este registro y muchas instrucciones hacen referencia a él de forma implícita, o de forma semi-implícita.

; Ejemplo: Sumar 2+3
lda #02     ; guardar 2 en A (explicito)
add #03     ; agregar 3 al valor guardado en A (implicito)
sta $C000   ; guardar el resultado en la direccion de memoria $C000 (explicito)

X - Registro Indice X

Es utilizado para cargarle valores que luego seran utilizados como un offset para una determinada dirección de memoria. Esto es útil para recorrer direcciones de memoria consecutivas en ciclos.

Modo de direccionamiento absoluto indizado por X (Absolute Indexed by X Addressing)

En este modo de direccionamiento, la dirección en cuestión se crea a partir de la locación de 16 bits más el contenido del registro X. Por ejemplo, la instrucción

lda $0400, x

carga el valor de la locación $0405 cuando el registro X tiene el valor #$05.

Modo de direccionamiento indirecto indizado(Indirect Indexed Addressing)

Muy similar al anterior, con la diferencia que la dirección de base será guardada en la memoria y por lo tanto accedida de forma indirecta.

Y - Registro Indice Y

Tiene un uso analogo al del registro X, y los mismos modos de direccionamiento. Sin embargo puede utilizarse en conjunto con el acumulador para hacer cosas que necesitan 16 bits de espacio.

PC - Program counter

Tambien conocido como puntero de instrucciones, es el único registro de 16 bits en la CPU 6510 y guarda la dirección de memoria de la instrucción que está siendo actualmente ejecutada en la C64. Se puede modificar el valor del PC utilizando instrucciones como jumping o branching. Cuando el CPU ejecuta una instrucción de la memoria, el PC es incrementado de forma automática.

P - Registro de estado P

Es un registro de 8bits, pero su valor no se considera en su totalidad. En su lugar, hay que mirar cada uno de sus bits de forma individual como si fueran banderas. Para manipular estas banderas, es importante conocer sobre bit-masking.

Recursos

What are C64 registers
Different classes of CPU registers
Addressing Modes

Builds desde Unity en la nube(sin salir de GitHub) ☁️🔧 [2/3]

Marlow Haspert — Mon, 02 May 2022 16:47:18 +0000

Introducción

En el post anterior de esta serie, vimos una introduccion a las GitHub Actions y tambien maquetamos lo que sera nuestro workflow para esta serie de posts.

Asi habia quedado:

Modelo mental

Agregaremos dos nuevos jobs a nuestro workflow. Estos se ejecutaran luego del build.
El primero de esos jobs, copia la build que expusimos como artifact en el paso anterior a un servidor FTP.
El segundo job, manda un mensaje a Discord una vez que la copia al FTP se realizo correctamente.

Manos a la obra

Como ya nos familiarizamos con el pipeline de las GitHub Actions en el post anterior, voy a dejar mas abajo el esqueleto del workflow terminado exceptuando el detalle del codigo para el job de build.

Copiar al FTP

En este caso, usaremos el action dist-to-ftp que se encuentra disponible en el Marketplace de GitHub Actions.

Para guardar de forma segura la URL de nuestro FTP, asi como sus accesos usaremos secrets. Los secretos pueden configurarse en GitHub a nivel de repositorio en Settings -> Secrets -> Actions.

Mandar un mensaje a Discord

De nuevo usaremos una accion disponible en el marketplace, esta vez action-discord. Leyendo su documentacion nos encontramos con que primero debemos configurar un WebHook para un canal en nuestro servidor Discord. Esto puede hacerse siguiendo los pasos dados en su propia documentacion.

Una vez que creamos nuestro webhook, guardaremos nuevamente estos valores como secrets a nivel del repositorio.

Wrap up

Si vamos a la pestaña de Actions tal y como en el post anterior, podemos correr nuevamente el workflow y chequear su ejecucion.
Si todo resulto bien, cuando el build se realice y se copie exitosamente al FTP, recibiremos un mensaje en nuestro canal de discord con un link que apunta a la nueva version.

La imagen de cabecera es de Natasha Remarchuk

Builds desde Unity en la nube (sin salir de GitHub) ☁️🔧[1/3]

Marlow Haspert — Tue, 25 Jan 2022 02:06:02 +0000

Introducción

Desde que empecé a meterme en el mundo del gamedev, un poco empecé también a sentir un vacío. Ese vacío en realidad era la falta de herramientas para la desarrolladora que trabaja usando Unity como motor y que estaba acostumbrada a que en las grandes software factories lxs devs estén obligadxs a cumplir con un montón de estándares y de chequeos automáticos.

Este es el primero de una serie de tres posts en donde espero poder compartirles de forma sencilla pero no acotada, el workflow que estamos actualmente utilizando en el estudio para buildear y publicar a un servidor local un proyecto en WebGL

Es tambien una serie de textos que decido encarar en castellano como resultado de una decision politica y que tiene un tono (demasiado) personal porque no encontre otra forma de escribir.
Asi que espero que ante cualquier duda o comentario no duden en dar su feedback :) y sin mas dilaciones empecemos por el principio...

GitHub Actions

GitHub Actions es una plataforma de integración y entregas continuas que forma parte del entorno GitHub y permite a los usuarios automatizar sus procesos de build, test y deployment. No está destinado únicamente a DevOps, ya que los workflows creados se pueden ejecutar como respuesta a distintos eventos que suceden en el repositorio o dispararlos on-demand. Un workflow es un proceso automatizado y configurable que ejecuta uno o más jobs. Se definen en un archivo YAML, que se pushea al repositorio como cualquier otro archivo. Para conocer más sobre GitHub actions, se puede consultar la documentación oficial

GameCI

Investigando un poco las acciones disponibles en el marketplace oficial de GitHub, me encontré con una comunidad que tiene como objetivo facilitar la incorporación de técnicas de integración continua de alta calidad a proyectos de videojuegos. Se llama GameCI y vamos a estar utilizando algunos de los workflows que proveen.

Modelo mental

Vamos a tener un workflow que consta de tres pasos (jobs)

Hacer el build desde Unity: nuestro ejecutable se expondrá como un artifact que puede ser consumido luego por otros jobs.
Publicar nuestro juego: vamos a copiar la build que esta guardada como artifact, a un servidor FTP
Notificación: enviaremos un mensaje por Discord con un link que apunte a la versión publicada

Manos a la obra

La documentacion oficial de la action que utilizaremos esta disponible online.

De hecho, un requerimiento a la hora de ejecutar una de estas actions es primero obtener una licencia de Unity que sea valida para nuestro ambiente. Recordemos que la nube no es mas que la computadora de alguien mas, así que tendremos que registrar la instancia de Unity que va a estar corriendo en el contenedor del job de GitHub con una licencia valida. Para eso, se pueden seguir los siguientes pasos de la guía oficial. Una vez hecho esto -se necesita una única vez por repositorio- podrás seguir leyendo sin problemas :)

Como dijimos antes, un workflow consta de diversos jobs. Entonces, en un principio vamos a comenzar definiendo un archivo build.yml en la carpeta .github. Podemos editar directamente desde el navegador, y de esa manera definir lo siguiente:

name: Build project
on: 
  workflow_dispatch:
jobs:
  buildForWebGL:

De esta manera, definimos que nuestro workflow se llamara "Build project", pueda ser ejecutado on demand y que contenga un job llamado "buildForWebGL".

Debajo, detallo el workflow con el job completo:

Los steps, basicamente definen la serie de pasos que van a ejecutarse dentro de nuestro job de forma ordenada. Cuando los ejecutamos se ven de forma mas amigable :)

A destacarse entonces en este job es que, el nombre de la variable

${{ secrets.UNITY_LICENSE }}

en este caso UNITY_LICENSE debera coincidir con la que creamos a nivel de repositorio en el paso de activar Unity.

Si ahora vamos a la pestaña Actions de nuestro repositorio, podremos encontrar y ejecutar nuestro workflow, siguiendo los pasos que detalla la imagen de abajo.

Una vez ejecutado, podrán ver que como resultado nuestro workflow produjo un artifact que puede ser descargado (es la build en WebGL, lista para copiar al FTP). En los próximos posts, vamos a explorar como automatizar ese paso.

Misc

Sonaba en mi cabeza:

La imagen de cabecera es de Natasha Remarchuk

Estilo de código para principiantes

Marlow Haspert — Thu, 23 Apr 2020 00:58:31 +0000

Las buenas prácticas y el estilo de código, son dos cosas con las que nos empezamos a chocar muy temprano en el camino de programar. Seas autodidacta, estudiante, hobbysta o vivas de escribir software, alguna vez seguro te encontraste con el hecho de seguir una "buena práctica" o una "guía de estilo".

Me acuerdo que cuando cursaba en la universidad, que es donde me encontré por primera vez con la programación, muchas veces nos marcaban reglas a la hora de escribir código, pero muchas veces las seguía sin cuestionarme mucho su sentido. Recién después de empezar a trabajar como desarrolladora, entendí que esas reglas eran estándares en el mundo profesional. También me pareció que funcionaba de manera similar a cuando esperamos que la planchita nueva que compramos por internet, traiga el mismo enchufe que el que tenemos en casa.

Por eso mi idea con este post, es contarle a aquellas personas que recién están aprendiendo a programar y todavía no entienden muy bien el "por qué" de esas prácticas un poco de su impacto en la vida diaria profesional. Una de las "buenas prácticas" que veremos más a menudo es la de escribir "código prolijo" más allá del estándar o metodología con la que esto se asegure. Uno de los aspectos de la prolijidad, es el estilo.

El estilo de código es literalmente cómo se ve el código que escribimos. Eso depende de cómo hayamos aprendido a programar, cómo lo hagamos habitualmente y de algunos gustos particulares. Es decir, que cómo se ve nuestro código es, en definitiva, una característica muy personal.

Sin embargo, si nos vamos a dedicar a la programación, tenemos que tener muy en cuenta que el código, aunque en nuestro imaginario parezca que no, está hecho por y para humanos. Entendemos que programar consta de un proceso que tiene varias capas: la de más arriba es nuestro código, y la de más abajo lo que entiende la computadora. Las capas del medio como la compilación, llevan la información en ambos sentidos, pero sobre todo hacen de soporte para que la capa de más arriba exista. Porque la necesitamos. Como humanos, necesitamos que los programas que escribimos lo estén de una forma en la que nos sea posible leerlos, pensarlos y escribirlos con más facilidad.

Los lenguajes de programación nacen siempre como respuesta a esa necesidad (y que no estemos escribiendo ceros y unos en un teclado como locos es una de sus consecuencias), pero al mismo tiempo no son el límite del alcance de la legibilidad. Así como mediante las reglas de gramática entendemos el lenguaje español, pero a la vez lo adaptamos a nuestras necesidades comunicativas (con regionalismos, "ahre" y otros), en el modo de usar lenguajes de programación pasa algo similar.

La programación suele ser una actividad muy social (aunque muchas veces parezca lo contrario) en donde el código que nos dedicamos a producir, tiene que ser leído por otros humanos (por ejemplo, nuestros compañeros de equipo en un juego grande), o incluso por una versión futura de nosotros mismos. De la misma manera que después de volver de las vacaciones de invierno no nos acordábamos en qué tema habíamos quedado la última clase de matemática, nos cuesta tiempo valioso acordarnos de la lógica que estábamos pensando cuando escribimos ese pedazo de código hace tres meses y que ahora tenemos que revisar porque el cliente encontró un error. También es muy común la práctica de revisar el código de tus compañeros antes de “guardarlo” definitivamente para que lo entiendan y traten de detectar errores.

Para facilitar esta forma de comunicación, es decir, de escribir un código más legible, cada equipo de trabajo especifica una serie de reglas de estilo de código que deben cumplirse. Algunas de ellas son específicas de un lenguaje en particular, y otras son adoptadas como estándares internos. Es como cuando en una oficina todos se ponen de acuerdo de dejar los cubiertos con el mango para arriba en el escurridor, así cuando una persona va a agarrar un cuchillo sin prestar toda la atención del mundo, no se corta.

Por eso creo que es importante que a la hora de familiarizarse con ciertas herramientas de trabajo que se utilizan en la vida laboral, el aprender a unificar estilos de código y seguir guías es algo a lo que se le debe prestar atención. Pero que, lejos de casarse con un estilo de código en particular, nos permita ser capaces de encontrar herramientas que funciona bien para nuestro escenario y nos permiten comunicarnos de la mejor forma posible. Al principio, cuando recién nos adentramos al mundo de la programación puede parecernos abrumador o innecesario, pero ir internalizando el uso de estilos de código sin duda nos va a ser muy útil durante nuestra carrera.